Technical Analysis

Firewalls within Larger Security Context

Campus priority: "to protect and enhance the research environment that enables campus to address society's most pressing problems and concerns."

Campus Priorities,

Chancellor's Budget 2000-2001

A comprehensive security solution includes policy, authentication, access control, end-to-end encryption and intrusion detection among others. Good host security or system hardening (removing unneeded services, applying patches) is always required. Following the strategy of defense-in-depth, whereby multiple barriers are placed between attackers and system, firewalls can be a valuable tool. Further, their use is sometimes mandated by law or policy protecting student or medical records for example.

The Firewall Task Force has been examining different firewall designs and support models. The objective was to determine which designs were appropriate for the UC Berkeley campus and how they might be supported. While we feel that good host security practices are always the first and most important defense, for those departments who desire or require a firewall the options and recommendations are described here.

Key Concepts and Issues

Firewall Definition

A firewall system blocks, redirects, monitors or permits network connections between two networks, a public or unsecured network and a secure network. It could be a special purpose device that physically sits between the two networks or it could be a software package installed on an individual host to accomplish similar tasks for that host.

Firewalls can be used proactively, in that policies are defined ahead of time regarding which traffic will be allowed and which will be denied. In this mode it is generally more secure to disallow everything and then only permit the type of traffic that an organization explicitly intends to pass through the firewall.

Alternatively, firewalls can be used reactively. Ad-hoc policies are applied to deal with special situations in the moment. For example, to block a particular host, known to be the source of an ongoing attack, or to block a particular port used by a newly discovered attack until such time as the new vulnerability can be patched.

When considering firewall support models it may be necessary to distinguish between proactive and reactive uses.

Firewalls generally work by creating access-lists or policy clauses that define the kind of network traffic that will be permitted, logged, redirected or denied. These clauses can be made up of information from the IP packet header, such as one or more of the following:

source address or network block 

destination address or network block

source TCP or UDP port 

destination TCP or UDP port

connection status

More sophisticated firewalls may examine the content of the packet in order to apply access policy. The sum of these clauses is the firewall's rule-set and defines what traffic will be forwarded through the firewall and what will not.

Firewalls are designed to apply a defined access control policy and therefore require system and network expertise. The access control policy must be developed as part of a comprehensive security program; firewalls are not a cure-all for all security issues. They cannot protect against attacks that originate within the 'secure' network or that circumvent the firewall via tunnels or backdoors. They may not be effective at stopping every sort of attack, e.g., email viruses. Each permit clause reduces the firewall’s effectiveness and may leave the network or a host vulnerable. Firewalls do not reduce the need for adequate host security and system administration. The more hosts on the private or "secure" side of a firewall the weaker the firewall's policy and the less effective it is. The fewer the hosts and the more homogeneous the policy, the more effective the firewall.

Large Security Perimeters

In general, the larger the security perimeter, or the more hosts a firewall protects, the less effective it will be. A large number of open, heterogeneous systems are difficult to protect with perimeter defense systems such as firewalls. They are only successful if the attackers are outside the perimeter. With large security perimeters there is a risk that attackers will be inside. As a focus group participant put it, "I would be locking the foxes in the hen house. "This is known as the "Perimeter Protection Paradox":

The value of a firewall is proportional to the number of systems protected; however, the effectiveness of a firewall is inversely proportional to the number of systems protected. This is because the larger the number of systems behind the firewall, the more likely it is that one of those systems has been or is about to be compromised by attacks that are difficult or impossible to block at an enterprise firewall (e. g., email attachments or web server exploits). Once that happens, the organization is vulnerable to "insider" attacks, and the firewall is rendered ineffective against them. Moreover, large-perimeter or border firewalls must implement a "lowest common denominator" filtering policy. The larger the number of users or business units in an enterprise, the larger the number of different applications likely to be in use, and therefore the larger the number of "holes" that must be punched thru the firewall to permit operation of those applications. Obviously, the more holes in the firewall, the less effective it is.

T. Gray, et al

Network Security Credo, Univ. of Washington, March 2002

http://staff.washington.edu/gray/papers/credo.html

In fact the area within the perimeter often called a "trust zone" is better thought of as a vulnerability zone [Gray, 2002].

Firewalls are not a Panacea

Firewalls are designed to block protocols from certain addresses. They cannot protect a system from what they are configured to let in. While this may seem obvious it is worth mentioning, an unpatched web server will not be protected by a firewall. If a server is intended to provide a particular service or application, then its firewall will allow that traffic through. While it might restrict which source IP addresses can access the server, the server will be vulnerable if that service can be compromised.

Systems are often compromised by simple means: administrative accounts with no passwords, user accounts with poorly chosen passwords.

Network Utility is degraded by Exceptions

Large networks can only be managed and operated by manageable number of people if the network utility is essentially consistent throughout the network. One of a kind exceptions to standard router or network device configuration, for example, access lists on individual router interfaces, dramatically increase the complexity of managing those devices. Special agreements with individual departments to manage or operate their part of the network differently increase management complexity and increase mean time to repair (MTTR) and can decrease network stability.

While exceptions are sometimes necessary their widespread use degrades the network utility for the entire campus community.

Network Address Translation (NAT) Issues

Firewalls may either "bridge" or "route" traffic. In the first case the firewall functions as a layer-2 network device and the IP subnet address space is the same on both sides of the firewall. Insertion or removal of a bridging firewall does not require any re-addressing of hosts. Routing firewalls have two different IP address spaces on the secure and public sides, and the firewall routes packets between them. In order to do this within the UCB campus network the firewall would either exchange routing information with UCB campus routers, or the campus routers would be configured with static routes to the firewall. Neither routing option is acceptable. Static routes are difficult to manage and do not scale; dynamic route exchange within the campus network can lead to route instabilities unless managed by a single entity. Therefore, a bridging or transparent firewall is always preferred.

As an alternative to routing public IP addresses firewalls may use Network Address Translation (NAT).  NAT is a firewall configuration option, used as an alternative when firewalls cannot operate in bridging or transparent mode.  NAT is used for IP address conservation and in this case for security.

Hosts on the secure network use private addresses. The firewall translates between private IP addresses ("local" or "non-routable" as defined by RFC 1918) and public IP addresses as packets traverse the firewall.  This packet forwarding behavior is transparent to the campus routers and will not interfere with their operation.  

In addition, NAT usually operates in a one-to-many mode, where one public IP address is mapped to many hosts and services behind the firewall, i.e., many private IP addresses. System and Network Security (SNS), the campus computer security office, has concerns about one-to-many NAT since SNS may be required to block an IP address for security reasons. This will have the very undesirable effect of blocking everything behind the NAT device. An alternative form of NAT is many-to-many, where every private IP address translates to a unique public IP address. The firewall is essentially an ARP proxy for every device behind the firewall. While this does nothing to conserve IP address space, something CNS normally encourages and is an advantage of one-to-many NAT, it does provide a workable Layer 3 alternative when a firewall cannot operate in transparent mode. Also note, NAT networks may not work well with some applications (if they embed the source IP address in the packet data for example) or can be difficult to manage for complicated inter-server communication due to the lack of internal DNS for the private IP addresses.

In summary, bridging or transparent firewalls are best. True Layer-3 routing of public IP address space cannot be supported. NAT is a workable option, with the caveat that, in the event of a security related host block, one to many NAT may result in many hosts being blocked.

Possible Firewall Implementations (Designs)

These designs enclose security perimeters that range from the entire campus to individual hosts. One design, the Secure Pen, is a one of a kind special case. It has a relatively small security perimeter.

Except where noted, (e. g., Entire Subnet - No Support, also known as "Private Network") CNS continues manages the network from the border to individual host's network connections, i.e., the wall jack. In fact the heart of the problem of implementing firewalls as a component of computer security, is how to use them without negatively impacting end-to-end network connectivity and utility.

Firewall management is performed by a proposed central Firewall Support Service (FSS) in some cases (Border, Secure Pen, and Entire Subnet - Full Support). In one case firewall management is shared between the FSS and the department (Entire Subnet - Shared Support). In all other cases the department or individual host's system administrator manages the firewall.

One requirement, "No routing" does not tend to distinguish between the designs, in that nearly all designs meet the requirement. Nonetheless, it is an extremely critical requirement and was maintained in our evaluations.

Border

In the typical corporate border firewall design, all hosts within the organization are considered secure. What operating system they run, the which applications are installed and how they are used are all covered by one or a small number of policies. The only publicly available servers are on the DMZ network or "extranet".

Figure 1 Typical Corporate Border Topology

This works well when all hosts within an organizations' network have the same configuration, are supported by the same department and include no publicly available servers.

In contrast the UC Berkeley network has multiple borders. The hosts within the campus network are not at all homogeneous and many run publicly available servers. The higher the number of hosts inside an organization, the more porous the border access policy must be and the less effective a border firewall will be.

Figure 2 Campus Backbone Topology

Of the educational institutions that responded to our questionnaire, only four use a border firewall and all of these have a relatively smaller user population and number of hosts within their campus network. The remaining 26 may do some border filtering, as does UC Berkeley, but do not use a border firewall.  Our current border filters are based on recommended best practices (RFC2827) for border filtering:

Certain multicast addresses and all source multicast addresses (224.0.0.0/4) inbound;

RFC1918 (private IP address space, i.e., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), destination or source IP, inbound or outbound;

Martian or invalid IP addresses, (e. g., source IP address 0.0.0.0), destination or source IP, inbound or outbound;

Link-local (169.254.0.0/16), localhost (127.0.0.0/8), destination or source IP, inbound and outbound;

Source IP equal to a UCB IP address, inbound;

Source IP not equal to a UCB IP address, outbound;

DHCP inbound;

SNMP, inbound and outbound;

TFTP, inbound and outbound.

Secure Pen

Figure 3 Secure Pen

A Secure Pen is operated centrally and houses critical systems. The service would function as a co-location facility for customers who wish to place their systems behind a centrally funded and managed firewall(s). Service includes physically secure location, power management, OS administrative services, monitoring, etc. The service would be designed to scale as it housed more systems. This would include sufficient network bandwidth, redundant network connectivity and redundant firewall service. Users interact with one group, which in turn coordinates with CNS or FSS as needed. Individual hosts or groups of hosts are secured using physical segments behind a firewall, or use of private VLANs within the switch behind firewall to segregate communication among pen-mates. The pen may include multiple firewalls both for purposes of bandwidth distribution and host-to-host isolation.

This design would be appropriate to protect highly critical servers and sensitive data. It provides a secure environment for organizations and department that lack the infrastructure or resources to manage a highly sensitive server. It would not be appropriate for departmental NT domain or file sharing servers.

A central, consistent, professional 24x7 service, is useful when a department is interested in a co-location or hosting service or has a small number of highly sensitive servers. Cost sharing across multiple organizations may enable acquisition of better and redundant hardware than individual departments could afford. Centralized management reduces cost of 24x7 operations and makes 24x7 operation possible for departments that cannot provide staffing for such activities.

However, the design may not be appropriate in all cases or for all departments. For example, the service would have a cost to the department. Also, operating system and other upgrades become more complex as they must be negotiated between department and Secure Pen provider. Hardware maintenance is also complicated as it is administered by Secure Pen provider but paid by department.

Entire Subnet

The next design is defined to mean that a firewall would protect all the host connections on one subnet. This design applies to shared 10Mb/s Ethernet or switched 10/100 Fast Ethernet networks.

Figure 4 Typical Switched 10/100 Fast Ethernet Network

As depicted this is a switched 10/100 Fast Ethernet network, but shared 10Mb/s networks use this design as well, just replace the switches with hubs. Older coax 10Mb/s shared networks do not use this "star wired" topology but the fundamental placement of the firewall between the subnet and its default router is the same.

Figure 5 Firewall Placement Between Subnet and Router

Figure 5 depicts the same network with a firewall inserted in front of the entire subnet. The firewall is a bridging or transparent firewall. While it examines Layer 3 and higher IP packet information it operates as a Layer 2 network device. This means the IP address space on both the secure and non-secure sides of the firewall belongs to the same IP subnet. This has several advantages for network and firewall administrators.

This design is appropriate for applying departmental security policy (e. g., "no telnet") to all of a department's hosts. It would also be useful as a reactive tool, e.g., responding to vulnerabilities until patches can be applied. However, since the number of hosts behind the firewall may be significant, this model may not be sufficient by itself to protect critical servers and sensitive data. In order to obtain the greatest benefit of this design, the firewall administrator must do work up front to create overall security policy in order to create secure, "proactive" rule-set, one where traffic is denied by default and permitted if needed.

Entire Subnet Support Methods

This design has particular features that make its deployment and support complicated. Because of these complications the Firewall Task Force discussed four possible support methods for this design.

The impact of the firewalls in this design on normal network operations cannot be minimized. It will effect end-to-end communications in ways intended (applications blocked by firewall rule-set) and unintended (for example, misinterpreting out of sequence packets as a signature attack and incorrectly blocking them.) This interference will generate network trouble reports. While this potential exists in all firewall designs, in this design there is no easy way to trouble-shoot network connectivity irrespective of the firewall. There is no way to rule out the firewall as the source of the problem, short of removing the firewall altogether which obviously has its security drawbacks.

For those networks for which CNS has operational responsibility, the firewall sits topologically between devices, i.e., switches and hubs, that CNS manages and CNS Network Management facilities. That means the firewall has the potential to obstruct or impact network management (ongoing monitoring of devices for usage thresholds, remote software upgrades, etc.) and network operations (notification of port and interface errors and failures) and new installations (configuration upload, modification and download.) As with any exception to normal network configuration, a firewall in the middle of the network may adversely affect network operation and management, and reduce network stability. If this design is widely adopted across campus, this impact may be felt throughout the entire campus network, by users on other subnets, in other words those not enjoying the protection of the firewall.

Entire Subnet - Central support of Network and Firewall (Full Support)

Under this support method, a central, 24x7, professional group of firewall experts would manage and operate firewalls in this design. Departments would enjoy the protection of the firewall, work with the FSS to develop security policy and the firewall's rule-set, but would not directly administer the firewall.

While negative impacts on network management are still a risk they might be mitigated by the existence of the FSS. In addition to establishing hardware, software and configuration standards for firewall operations they would have standard configurations to support CNS network operations and management. And they would be available to CNS to assist with problem diagnosis and work with SNS to resolve security issues on participate in security reviews. The FSS could provide consistency across campus and might be able to provide 24x7 support more readily than department staff could. This design has an economy of scale and it would be appropriate when the department does not have the necessary in-house technical expertise. Most significantly the FSS will provide overall guidance on architecture and policy.

There is significant resistance to the idea of centrally funding a firewall management service. The cost would be significant, and the benefit limited to relatively few departments. Academic departments in particular are reluctant to rely on central services, due to fears of inflexibility and loss of local control. It is unrealistic to centrally fund a full-service firewall management service when other IT funding needs have not been met.

A recharge firewall management service would have difficulty finding enough business to support the necessary technical staff. At least 3 FTE would be needed, making the total cost somewhere in the neighborhood of $300,000. Given the results of our departmental survey and focus groups, we do not believe the current demand for a central recharge firewall management service could generate anything near this amount of income.

Entire Subnet - Central support of Network and Department support of Firewall (Mixed Support)

In this support method departments with in-house expertise manage the firewall. CNS however, continues to manage the network behind the firewall. This approach has several advantages for departments. They can update the firewall's rule-set themselves using existing staff and expertise. And departments know their own environments and security requirements best.

This approach has negative implications for campus network operations and certain aspects of campus security proportional to its rate of adoption. More decentralized management of firewalls necessitates more widespread training, including both technical training and the need to ensure that policies are well understood around campus. Even with this training the result may be inconsistent firewall management across campus. In a related vein, it is unlikely that, across the entire campus, departments will maintain consistent firewall hardware or software configuration.

This approach makes operation of the firewall and the network behind harder to manage. It complicates network operations (installations, upgrades, configuration modifications) and is more expensive for central support of the network; all departments feel this effect whether they have a firewall or not. These impacts are exacerbated as more departments opt for departmentally managed firewalls. In other words, it does not scale.

Also, in-house firewall expertise is required; many departments may not have technical staff able to handle the firewall management. And finally, CNS has serious concerns about being able to support this model.

Entire Subnet - Central Network support and Shared Firewall support (Shared Support)

In this support method, a mechanism is employed whereby the department has access to some management of the firewall, such as rule-set modification, pertinent alerts and log entries but the firewall is operated by the FSS.

Such a mechanism could be provided by a firewall that supports delegation of responsibility, or by a homegrown web interface that would allow the department to create rule sets and check logs without having full administrative access.

The FSS role includes software upgrades, hardware maintenance, monitoring, recommending ACLs, and administrative management. The department's role is to maintain its own ACLs, monitor its own alerts, and view its own usage reports.

This design attempts to combine some of the benefits of the other designs. It allows for economies of scale and overall guidance on architecture and policy, while still granting some control to departments. While combining benefits, it also combines problems.

Departments could still cause network problems with firewall changes, though not as easily as in the Mixed Support model. The funding issues of the central firewall support service would actually be exacerbated, because their workload would be shared with departments, potentially reducing the demand for recharge FTE (or the need for centrally-funded FTE).

Entire Subnet - Departmental support of Network and Firewall (No Support)

In this support method the department operates and supports both the network and the firewall. This is also known as a "Private Network". Most currently existing firewalls on campus are on a private network. Private networks require a significant amount of in-house technical expertise to manage, and a dedicated support staff willing to fix problems after-hours. This design would be appropriate only for departments with a technical staff able to manage the complexities of a firewalled network--most departments do not have access to that level of technical skill.

Departments that have the expertise could adopt this design. They would become responsible for installation, maintenance, and support of all of their network connections, as well as the firewall.

The advantages and disadvantages of such a decision are beyond the scope of this report; suffice it to say the prospect of operating a private network is larger than the issues involved in running a firewall. Departments considering moving to a private network should carefully weigh the advantages and disadvantages in consultation with CNS.

Entire Subnet Conclusion

The Task Force was unable to reach consensus on an appropriate support method for this design. Many felt that any of these options should be available according to what the department needed. Others felt that the prospect of a central network management with a department-managed firewall was unsupportable and too expensive for the campus as a whole.

Judging by internal survey results and results from our focus groups with campus system administrators; campus departments were evenly split as to which support method they preferred.

In the end, primarily because the design does not offer great security (security perimeter still too large), there are a viable alternatives and because the right way to support the design is neither easy nor clear, the Task Force is not recommending this design, irrespective of the support method.

Multiple Subnets

This design was included to cover cases where a large department has multiple subnets. The typical solution, and the one evaluated by the Firewall Task Force, is one where the department operates a routing firewall between its networks and the rest of the campus network. This has many drawbacks, chief among them a large security perimeter and a design that requires route exchange within the campus interior network. The subnets behind the routing firewall would be private networks, i.e., not supported by CNS.

Figure 6 Multiple Subnets with Routing Firewall

Note: an alternative that should be evaluated in the future would be to use a firewall on a trunk carrying the departments VLANs. In this design the department network is configured with different ports on the same switch to belonging in different subnets. The different subnet configurations within the switches are called virtual LANs, or VLANs. Connections between the switches (vertical wiring) then carry traffic for multiple subnets or VLANs. These connections are called trunks. Packets on a trunk connection are tagged with information indicating which subnet or VLAN they belong to, for decoding and forwarding at the other end of the trunk.

Figure 7 Theoretical Firewall on a VLAN trunk

A firewall capable of understanding VLAN tagging and trunks could monitor all subnets at once on the trunk between the campus router and the distribution switch. It is not known if a firewall exists that has this capability. In addition, this design still has the drawback of a very large security perimeter. While this design has promise and should be explored in the future, it is not the design that the Firewall Task Force evaluated. Instead we concentrated on the known possible design, i.e., Multiple Subnets with a Routing Firewall.

Hidden VLAN

In this design a CNS managed switch is configured with two VLANs. The switch cannot forward packets from one VLAN to another. Only a firewall connects the two VLANs. This design will work with a bridging or transparent firewall since traffic will not be forwarded between the secure/hidden VLAN and the non-secure VLAN except by the firewall bridge. Or, hosts on the "secure" VLAN can use private address space and the firewall uses NAT. If the switch is compromised the secure hosts are vulnerable.

Figure 8 Hidden VLAN within one switch

This design is appropriate when applying departmental policy (e. g., "no telnet") to a set of workstations, or protecting them from "script kiddy" break-ins. It is not appropriate for critical servers or sensitive data.

Figure 9 Hidden VLAN - All Switches 

The design could be modified to protect more connections within the subnet (Figure 9). In order to decrease vulnerability, the number of hosts on the non-secure VLAN, that is potentially vulnerable hosts, should be minimized as they could be used as stepping-stones to compromise the switches and therefore the entire design.

This design requires a modern, fully switched network; therefore, it cannot be implemented on a substantial portion of campus subnets. On fully switched networks, it would have the advantage of using existing infrastructure.

Most significantly it does not interfere with CNS management of network devices. It would still be possible for firewalls to cause problems that look like network errors and generate network trouble reports. However, because of the ease of moving individual connections from the secure to the non-secure portions of the network, with the system administrator's permission, problem resolution is made easier than with the Entire Subnet design.

Host Cluster

Figure 10 Host Cluster Design

Host-cluster firewalls are beyond the CNS supported network, and would not interfere with network operations or management of CNS network devices. They could interfere with network trouble-shooting to the protected end systems. However the Host Cluster firewall, and the systems behind it, could be unplugged from the CNS supported network wall jack so in order trouble-shoot that connection.

This design is appropriate for applying departmental policy (e. g., "no telnet") to a set of workstations, or protecting them from "script kiddy" break-ins. It is appropriate for servers clusters, and in fact is can be very robust security because the security perimeter in this design is small.

Personal

Personal firewalls, or host-based firewalls are applications that are installed on individual hosts and once configured protect that host from unauthorized access. In fact, many new operating systems are embedding firewalls into the OS. The firewall software would be configured by the department IT personnel or the individual host's administrator.

These are appropriate for added protection (defense in depth) or where nothing else is possible.  

It is easy to have as many profiles as there are hosts and ultimate control and configurability is available to the host's' user or administrator.  Software-based or personal firewall software does not interfere with management of CNS network devices.

However, it may be difficult for departmental IT personnel to centrally manage hundreds of personal firewall configurations. Unlike current virus protection personal firewall products do not include mechanisms for central management. This may result in a large population of distributed and/or uncontrolled firewall management and additional workload for users and support personnel. Some personal firewall products include central administrative tools, which may mitigate management issues for departments. And of course these products are constantly evolving. Without good central administration personal firewall software is a good comprehensive solution for an entire subnet.

Table of Contents

Appendix A