Variations on Firewall Architectures (Building Internet Firewalls, 2nd Edition)

6.5. Variations on Firewall Architectures

We've shown the most common firewall architectures in Figure 6-2 through Figure 6-8. However, there is a lot of variation in architectures. There is a good deal of flexibility in how you can configure and combine firewall components to best suit your hardware, your budget, and your security policy. This section describes some common variations and their benefits and drawbacks.

6.5.1. It's OK to Use Multiple Bastion Hosts

Although we tend to talk about a single bastion host in this book, it may make sense to use multiple bastion hosts in your firewall configuration, as we show in Figure 6-9. Reasons you might want to do this include performance, redundancy, and the need to separate data or servers.

Figure 6-9. Architecture using two bastion hosts

You might decide to have one bastion host handle the services that are important to your own users (such as SMTP servers, proxy servers, and so on), while another host handles the services that you provide to the Internet, but which your users don't care about (for example, your public web server). In this way, performance for your own users won't be dragged down by the activities of outside users.

You may have performance reasons to create multiple bastion hosts even if you don't provide services to the Internet. Some services, like Usenet news, are resource-intensive and easily separated from others. It's also possible to provide multiple bastion hosts with the same services for performance reasons, but it can be difficult to do load balancing. Most services need to be configured for particular servers, so creating multiple hosts for individual services works best if you can predict usage in advance.

How about redundancy? If your firewall configuration includes multiple bastion hosts, you might configure them for redundancy, so that if one fails, the services can be provided by another, but beware that only some services support this approach. For example, you might configure and designate multiple bastion hosts as DNS servers for your domain (via DNS NS [Name Server] records, which specify the name servers for a domain), or as SMTP servers (via DNS X [Mail Exchange] records, which specify what servers will accept mail for a given host or domain), or both. Then, if one of the bastion hosts is unavailable or overloaded, the DNS and SMTP activity will use the other as a fallback system.

You might also use multiple bastion hosts to keep the data sets of services from interfering with each other. In addition to the performance issues discussed earlier, there may be security reasons for this separation. For example, you might decide to provide one HTTP server for use by your customers over the Internet, and another for use by the general public. By providing two servers, you can offer different data to customers, and possibly better performance, by using a less loaded or more powerful machine.

You could also run your HTTP server and your anonymous FTP server on separate machines, to eliminate the possibility that one server could be used to compromise the other. (For a discussion of how this might be done, see the description of HTTP server vulnerabilities in Chapter 15, "The World Wide Web".)

6.5.2. It's OK to Merge the Interior Router and the Exterior Router

You can merge the interior and exterior routers into a single router, but only if you have a router sufficiently capable and flexible. In general, you need a router that allows you to specify both inbound and outbound filters on each interface. In Chapter 8, "Packet Filtering", we discuss what this means, and we describe the packet filtering problems that may arise with routers that have more than two interfaces and don't have this capability.

If you merge the interior and exterior routers, as we show in Figure 6-10, you'll still have a perimeter net (on one interface of the router) and a connection to your internal net (on another interface of the router). Some traffic would flow directly between the internal net and the Internet (the traffic that is permitted by the packet filtering rules set up for the router), and other traffic would flow between the perimeter net and the Internet, or the perimeter net and the internal net (the traffic that is handled by proxies).

Figure 6-10. Architecture using a merged interior and exterior router

This architecture, like the screened host architecture, creates a single point of failure. Since now only one router is between the inside and the outside, if that router is compromised, the entire site is compromised. In general, routers are easier to protect than hosts, but they are not impenetrable.

6.5.3. It's OK to Merge the Bastion Host and the Exterior Router

There might be cases in which you use a single dual-homed machine as both your bastion host and your exterior router. Here's an example: suppose you only have a dial-up SLIP or PPP connection to the Internet. In this case, you might run PPP on your bastion host, and let it act as both bastion host and exterior router. This is functionally equivalent to the three-machine configuration (bastion host, interior router, exterior router) described for the screened subnet architecture shown earlier in this chapter.

Using a dual-homed host to route traffic won't give you the performance or the flexibility of a dedicated router, but you don't need much of either for a single low-bandwidth connection. Depending on the operating system and software you're using, you may or may not have the ability to do packet filtering. Several of the available interface software packages have quite good packet filtering capabilities. However, because the exterior router doesn't have to do much packet filtering anyway, using an interface package that doesn't have good packet filtering capabilities is not that big a problem.

Unlike merging the interior and exterior routers, merging the bastion host with the exterior router, as shown in Figure 6-11, does not open significant new vulnerabilities. It does expose the bastion host further. In this architecture, the bastion host is more exposed to the Internet, protected only by whatever filtering (if any) its own interface package does, and you will need to take extra care to protect it.

Figure 6-11. Architecture using a merged bastion host and exterior router

6.5.4. It's Dangerous to Merge the Bastion Host and the Interior Router

While it is often acceptable to merge the bastion host and the exterior router, as we discussed in the previous section, it's not a good idea to merge the bastion host and the interior router, as we show in Figure 6-12. Doing so compromises your overall security.

The bastion host and the exterior router each perform distinct protective tasks; they complement each other but don't back each other up. The interior router functions in part as a backup to the two of them.

If you merge the bastion host and the interior router, you've changed the firewall configuration in a fundamental way. In the first case (with a separate bastion host and interior router), you have a screened subnet firewall architecture. With this type of configuration, the perimeter net for the bastion host doesn't carry any strictly internal traffic, so this traffic is protected from snooping even if the bastion host is successfully penetrated; to get at the internal network, the attacker still must get past the interior router. In the second case (with a merged bastion host and interior router), you have a screened host firewall architecture. With this type of configuration, if the bastion host is broken into, there's nothing left in the way of security between the bastion host and the internal network.

Figure 6-12. Architecture using a merged bastion host and interior router

One of the main purposes of the perimeter network is to prevent the bastion host from being able to snoop on internal traffic. Moving the bastion host to the interior router makes all of your internal traffic visible to it.

6.5.5. It's Dangerous to Use Multiple Interior Routers

Using multiple interior routers to connect your perimeter net to multiple parts of your internal net can cause a lot of problems and is generally a bad idea.

The basic problem is that the routing software on an internal system could decide that the fastest way to another internal system is via the perimeter net. If you're lucky, this approach simply won't work because it will be blocked by the packet filtering on one of the routers. If you're unlucky, it will work, and you'll have sensitive, strictly internal traffic flowing across your perimeter net, where it can be snooped on if somebody has managed to break in to the bastion host.

It's also difficult to keep multiple interior routers correctly configured. The interior router is the one with the most important and the most complex set of packet filters, and having two of them doubles your chances of getting the rule sets wrong.

Nevertheless, you may still end up wanting to do this. Figure 6-13 shows the basic architecture using multiple interior routers. On a large internal network, having a single interior router may be both a performance problem and a reliability problem. If you're trying to provide redundancy, that single point of failure is a major annoyance. In that case, the safest (and most redundant) thing to do is to set up each interior router to a separate perimeter net and exterior router; this configuration is discussed earlier in this chapter. This configuration is more complex and more expensive, but it increases both redundancy and performance, as well as making it highly unlikely that traffic will try to go between the interior routers (if the Internet is the shortest route between two parts of your internal network, you have much worse problems than most sites) and extraordinarily unlikely that it will succeed (four sets of packet filters are trying to keep it out).

Figure 6-13. Architecture using multiple interior routers

If performance problems alone are motivating you to look at multiple interior routers, it's hard to justify the expense of separate perimeter networks and exterior routers. In most cases, however, the interior router is not the performance bottleneck. If it is, then one of the following cases is occurring:

A lot of traffic going to the perimeter net is not then going to the external network.
Your exterior router is much faster than your interior router.

In the first case, you have probably misconfigured something; the perimeter net may take occasional traffic that isn't destined for the external world in some configurations (for example, DNS queries about external hosts when the information is cached), but that traffic should never be significant. In the second case, you should seriously consider upgrading the interior router to match the exterior router, instead of adding a second one.

Another reason for having multiple interior routers is that you have multiple internal networks, which have technical, organizational, or political reasons not to share a single router. The simplest way to accommodate these networks would be to give them separate interfaces on a single router, as shown in Figure 6-14. This complicates the router configuration considerably (how considerably depends a great deal on the router in question, as discussed in Chapter 8, "Packet Filtering") but doesn't produce the risks of a multiple interior router configuration. If there are too many networks for a single router, or if sharing a router is unpalatable for other reasons, consider making an internal backbone and connecting it to the perimeter network with a single router, as shown in Figure 6-15.

Figure 6-14. Multiple internal networks (separate interfaces in a single router)

Figure 6-15. Multiple internal networks (backbone architecture)

You may find that an effective way to accommodate different security policies among different internal networks is to attach them to the perimeter through separate routers (e.g., one network wants to allow connections that others consider insecure). In this case, the perimeter network should be the only interconnection between the internal networks; there should be no confidential traffic passing between them; and each internal network should treat the other as an untrusted, external network. This is likely to be extremely inconvenient for some users on each network, but anything else will either compromise the security of the site as a whole or remove the distinction that caused you to set up the two routers in the first place.

If you decide that you are willing to accept the risks of having multiple interior routers, you can minimize those risks by having all the interior routers managed by the same group (so conflicting security policies aren't being enforced). You should also keep a careful watch for internal traffic crossing the perimeter network and act promptly to cure the sources of it.

6.5.6. It's OK to Use Multiple Exterior Routers

In some cases, it makes sense to connect multiple exterior routers to the same perimeter net, as we show in Figure 6-16. Examples are:

You have multiple connections to the Internet (for example, through different service providers, for redundancy).
You have a connection to the Internet plus other connections to other sites.

In these cases, you might instead have one exterior router with multiple exterior network interfaces.

Figure 6-16. Architecture using multiple exterior routers

Attaching multiple exterior routers that go to the same external network (e.g., two different Internet providers) is not a significant security problem. They may have different filter sets, but that's not critical in exterior routers. There is twice the chance that one will be compromisable, but a compromise of an exterior router usually is not particularly threatening.

Things are more complex if the connections are to different places (for example, one is to the Internet and one is to a site you're collaborating with and need more bandwidth to). To figure out whether such an architecture makes sense in these cases, ask yourself this question: what traffic could someone see if they broke into a bastion host on this perimeter net? For example, if an attacker broke in, could he snoop on sensitive traffic between your site and a subsidiary or affiliate? If so, then you may want to think about installing multiple perimeter nets instead of multiple exterior routers on a single perimeter net. (This case is shown in the next section.)

Other significant problems are involved in setting up connections to external networks with which you have special relationships, which are discussed later in this chapter, in Section 6.7, "Internal Firewalls".

6.5.7. It's Dangerous to Use Both Screened Subnets and Screened Hosts

If you have a screened subnet, you should not allow connections from the Internet directly onto your internal networks. This may seem intuitively obvious (what's the point in having a screened subnet if you're not going to use it?), but you'd be surprised how many people end up making exceptions. These sorts of exceptions are extremely dangerous. Once you have a screened subnet, you're going to be concentrating your protections there, and it's almost impossible to properly protect both a screened subnet and a screened host on an internal network.

There are two common situations in which people ask for exceptions. First, people providing services to Internet users find that the interior router interferes with either administration of the services or communication between components (for instance, a web server that needs to talk to an internal database server). Second, people with tools for accessing new protocols (proxy servers for the latest multimedia 3D all-singing all-dancing tool, for instance) don't want to go to the trouble of putting them in somebody else's carefully protected space and are completely convinced that they're so safe you can just let traffic through to them.

Chapter 23, "Databases and Games", discusses the positioning of web servers and their associated components in detail, but the short summary is that putting the web server itself on the internal network is extremely risky, even if you are sure that only web traffic can get to it. If you are having problems allowing administrative protocols through, Chapter 11, "Unix and Linux Bastion Hosts", and Chapter 12, "Windows NT and Windows 2000 Bastion Hosts ", discuss methods for safely administering bastion hosts.

As for the theoretically safe brand-new protocols, there's a lot to consider before you hand over control of an experimental bastion host. Make sure that:

No other bastion hosts trust the experimental one.
The experimental bastion host cannot snoop on important network traffic.
The machine starts out in a secure configuration.
You will be able to detect break-ins on the experimental bastion host.

Then hand it over and let people play with it. It's better for them to experiment in a controlled way where you can keep an eye on them than to succeed in working around the firewall altogether. If you have the resources, you may want to put a separate screened subnet in place just for experimentation.