8.1. Firewall Architectures

Firewalls are not a "one size fits all" device. The policy they enforce on a network varies from organization to organization. Also, the manner in which they are used, maintained, and integrated into a network can vary wildly.

The first step in successfully deploying and using firewalls is proper placement of the firewalling devices. This requires understanding the existing network, the services running over the network, and the user requirements of the network. A good firewall administrator is also a good systems and network administrator. Multiple talents must be brought to bear to ensure that a firewall serves to enable secure data transactions while not hindering the operations of the users and systems.

Improper firewall architecture can cause a security problem even if the ruleset on the firewall is technically "correct." Attackers may be able to bypass the firewall due to improper placement. Or you may not be able to enforce the desired security policy due to the firewall's location. For example, if you're attempting to control access between the accounting network and administrative network in Figure 8-1, the existing firewall will be of no use.

Figure 8-1. Typical firewall setup

Further, if a firewall is overly intrusive in a network, there will be a tendency to place relaxed rules on the firewall to compensate. This is a difficult, yet common, situation for many security services; security is compromised for the sake of functionality. In order to ensure that your network is as secure as it can be, you must understand the options you have with respect to firewall architectures and deploy your systems accordingly.

8.1.1. Bump in the Wire

The simplest firewall architecture, termed bump in the wire, is shown in Figure 8-2. In this setup, the firewall is a choke point for all traffic coming into and leaving a network. This is a common configuration, as it provides a single point of administration and policy enforcement. It also requires only one firewalling device making this architecture relatively inexpensive to deploy.

Figure 8-2. Bump in the wire firewall architecture

However, in larger networks, such as that in Figure 8-1, there may not be fine-grained enough control over traffic on the network. Traffic between the accounting and administrative networks cannot be controlled. For this reason, the bump in the wire architecture is commonly used in small networks such as those found in home offices and small server farms. Commodity firewalls, such as those found embedded in DSL routers and wireless access points, are typically this kind of "one network in, one network out" device.

Still, a bump in the wire firewall may be useful at the very front of a large enterprise. While unable to enforce fine-grained access control, a perimeter firewall can filter out overtly malicious traffic from external sources. For instance, you may want to filter out all Windows NetBIOS traffic from entering your network. A bump in the wire firewall at the ingress point to your enterprise can ensure that NetBIOS traffic is completely stopped at your network edge. This setup allows the frontend firewall to handle the "low hanging fruit" while pushing finer-grained decisions to internal firewalls. This flies in the face of the security principle of denying all traffic except that traffic that is explicitly allowed. However, this principle can be difficult to enforce at busy border networks where what is and is not allowed is difficult to determine.

8.1.2. DMZ

Many networks, especially those in smaller organizations, are composed of two basic types of systems: workstations and servers. Workstations are used by staff to access internal resources, surf the Net, send instant messages, and so on. Workstations are generally clients and almost never require connections initiated from outside networks.

Servers are machines accessed by clients. In the case of a small office, a web and mail server may need to be accessed from both internal workstations and other clients on the Internet. Servers require different security policies: their services must be made available through a firewall rather than blocked. However, with this access comes risk. Opening up Internet connectivity for servers makes it possible for attackers outside the office network to break in. If a machine is compromised, ideally it can be quarantined from the rest of the network to prevent further damage.

The requirement for different server and workstation security policies leads us to a firewall architecture called a demilitarized zone, or DMZ. A DMZ is a line of demarcation; a region between an area controlled by one organization and an area controlled by another. A network DMZ, as shown in Figure 8-3, has a network segment that contains the external facing servers that exists between the "wild" external network (such as the Internet) and the protected internal network. Sometimes this is referred to as a three-legged firewall. This architecture allows for different policies to be applied to each network. It also enables the firewall to contain the servers in the event of a break-in. In general, the servers should never initiate a connection to the internal workstations. Adhering to the concept of default deny, the firewall policies can be configured to deny all connections from the server network to the workstation network. While an attacker may still be able to jump from one server to another (there is no firewall control between the servers on the server network in Figure 8-3), it's unlikely she will be able to directly compromise a host on the workstation network.

Figure 8-3. DMZ firewall architecture

8.1.3. Spider

The DMZ architecture is driven by the need to enforce different policies and quarantine one network from another. This idea can be extended to encompass multiple networks connected to one firewall. A spider architecture allows one firewall to control traffic between many directly connected networks. In Figure 8-4, the firewall can control traffic between the accounting, administration, server, and wireless networks. Note the difference between this setup and the one in Figure 8-1. In a bump in the wire network, these internal systems would form a soft chewy center; all traffic between internal hosts would be allowed due to the lack of a firewall. In a spider architecture, access control decisions can be made on a much more local basis.

Figure 8-4. Spider firewall architecture

Conceptually, a spider architecture is not really different from a DMZ network with one physical firewall. It allows multiple network connections to be terminated into a single host. This allows an economy of scale where only one firewall is needed for multiple networks. The spider network in Figure 8-4 can be broken down and implemented in several firewalls as shown in Figure 8-5. This architecture obviously involves many more firewalls, to keep track of that can cause administrative overhead and very complicated routing tables and rulesets. However, be aware that a spider architecture may put all of your security and availability eggs in one basket. A single breach in security or a single hardware failure can cause dramatic problems. Also, on networks with large amounts of traffic, a firewall in a spider architecture will have to inspect a great deal of traffic. This could cause performance problems for the network.

Figure 8-5. Broken apart spider network

8.1.4. Transparent

There are times when, for various reasons, a firewall cannot be inserted in a standard way. Up until this point, the firewalls in each architecture have been on a layer 3 (i.e., subnet) boundary. That is, each interface on the firewall is on a different IP subnet. A firewall can actually be deployed so that it bridges between two interfaces and does not act as a gateway for the hosts on the network. This is known as a transparent firewall and is shown in Figure 8-6.

Figure 8-6. Transparent Firewall Architecture

Transparent firewalls are not often used; however, there are circumstances that arise where this architecture is a silver bullet. Transparent firewalls are common when it is necessary to maintain the existing network architecture (so as not to break a routing protocol or addressing scheme). They are also useful when a network has a very limited number of addresses but needs to perform firewalling between two types of hosts. In general, you'll know if you are in a situation that requires transparent firewalling.

8.1.5. Host

Firewalls have historically been a standalone network device. However, as attackers have become more sophisticated and users have become more mobile, standalone firewalls no longer fulfill users' security needs. A laptop may be protected from attacks when it is plugged directly into a corporate network and resides behind the corporate firewall. However, when the user goes to lunch with the laptop and uses a public WiFi hotspot, the corporate firewall is of no use whatsoever. In order to be protected, the laptop should run a host-based firewall.

Host-based firewalls run directly on an endpoint machine and come in many flavors. Windows XP has native firewalling capabilities. There are many third-party firewalls available such as ZoneAlarm and Checkpoint's personal firewall solutions. Of course, FreeBSD and OpenBSD's firewalls can be configured at both the network and the host level.

Host-based firewalls are great because they protect the host even when a network firewall is not available. They allow for extraordinarily fine-grained access control. However, running firewalls on every host can be administratively difficult. All the machines would have to have firewall policies pushed to them, and troubleshooting a problem would always involve checking the firewall configuration. Because of the operational expense of using host-based firewalls, many organizations limit their use to road-warriors, critical datacenter servers, and other machines with explicit need.

8.1.6. High Availability

So far, discussion has been limited to a single firewall at a given location within a network. While this is great for the purposes of outlining concepts, in reality, a single firewall creates a single point of failure for the connected networks. Firewalls can (and do) stop working due to hardware or software problems. Also, due to the nature of a firewall, a misconfiguration can cause a firewall to become unreachable. It's common to hear a firewall administrator blurt out an expletive after making a firewall rule change because she inadvertently locked herself out due to a ruleset problem.

Maintenance needs to be periodically performed on firewalls just like any other IT asset. Hardware needs to be upgraded, operating systems need to be patched, etc. Sometimes maintenance outages are overlooked and treated as a cost of doing business. However, these outages and general system failures don't need to result in a service disruption for networks attached to the firewall.

High availability (HA) is a concept in which critical systems are designed, configured, and managed in a way to attempt to minimize downtime. In the scope of firewalls, this means having multiple firewalls, usually two, in a firewall deployment. For instance, Figure 8-7 is Figure 8-2 implemented with a highly available architecture.

Figure 8-7. HA firewall architecture

There are several modes of operation for highly available firewalls:

Hot-Cold

An HA firewall pair in Hot-Cold mode is the simplest HA setup. The hot machine acts as the primary firewall, actively passing and filtering packets. The cold machine has an initial configuration similar to the hot machine, but it has no ability to detect failure in the hot machine or even the configuration of the hot machine before it fails. An administrator must interact with a cold host to configure it and then place it in service. Hot-Cold can be thought of as "keeping a spare machine in the closet in case something breaks." From the author's experience, the time to return to normal operations in a Hot-Cold architecture can vary 15 minutes to 24 hours depending on how prepared an organization is to bring the cold host online.

Hot-Warm

Slightly more complex, a Hot-Warm architecture reduces the amount of time needed to bring the second machine online. The hot host is actively passing and filtering traffic. The warm host has a synchronized configuration with the hot host. This allows for an administrator to switch the warm host to primary firewall duties in 5 to 30 minutes. Still, a Hot-Warm setup does not automatically detect and handle failure.

Hot-Standby

In a Hot-Standby implementation, the second firewall is able to automatically take over in the event of a system failure. Configuration information is synchronized between the hot and standby hosts. Further, information regarding the health of each system is transmitted between them to allow the standby host to automatically bring itself online. Also, in more advanced setups, the firewalls exchange information regarding traffic going through the hot host. That way, if the standby host needs to take over, existing connections are maintained transparently.

Hot-Hot

Hot-Hot is the most advanced HA firewall architecture. In this mode, both firewalls are actively passing and filtering traffic utilizing synchronized configurations and traffic data. An external load balancer must be used to route a particular connection through one host or another. In the event of failure, all traffic is automatically rerouted to the other hot firewall.

The concept of high availability firewalling has been around for a number of years. However, until recently (OpenBSD 3.5 and FreeBSD 5.2.1), the open source BSD-based operating systems were not useable in a Hot-Standby or Hot-Hot firewall setups. Companies such as Nokia use BSDs for their core operating system and wrote their own high-availability code for use in their commercially available firewall appliances. Now, using publicly available software, administrators can deploy HA firewalls on both OpenBSD and FreeBSD.

Firewalls and Routing Protocols

A firewall is a network device. Historically, network devices have taken the form of routers and switches. These layer 3 (router) and layer 2 (Ethernet switch) devices often exchange information that is vital for a robust and available network. Routers will use routing protocols such as OSPF, RIP, and ISIS to pass routing information and handle link failure. Switches used protocols such as spanning trees to stop loops from forming.

A firewall is generally a layer 3 device. It takes the place a router would normally occupy. As such, firewalls tend to cause problems for network engineers. Where a router would normally participate in an OSPF network, for instance, a firewall is likely to not understand OSPF natively. This creates network boundaries that may result in large routing tables on the firewall and static routes having to be placed in routers pointing traffic through the firewalls.

Organizations constantly struggle with whether or not to allow firewalls to run routing protocols. It is possible to run routed or zebra to handle RIP, OSPF, and other routing protocols. The question becomes whether you should.

On one hand, it makes the network much easier to maintain if every layer 3 gateway is running a routing protocol. It minimizes outages due to link failure and does not require static routes to constantly be updated manually. On the other hand, a firewall as a security device should be relatively static and run as few services as possible. A routing protocol is one more thing to go wrong and one more service for an attacker to compromise.

At the end of the day, it's a decision that only you and your organization can make. Be realistic about the impact that not running a routing protocol will have on your day-to-day operations. Also, understand the risks your firewalls face and determine if you are willing to amplify your risk by running a routing daemon.