It is possible to use a packet filtering system by itself as a firewall, as shown in Figure 6.1, using just a screening router to protect an entire network. This is a low-cost system, since you almost always need a router to connect to the Internet anyway, and you can simply configure packet filtering in that router. On the other hand, it’s not very flexible; you can permit or deny protocols by port number, but it’s hard to allow some operations while denying others in the same protocol, or to be sure that what’s coming in on a given port is actually the protocol you wanted to allow. In addition, it gives you no depth of defense. If the router is compromised, you have no further security.

Figure 6.1. Using a screening router to do packet filtering

A dual-homed host architecture is built around the dual-homed host computer, a computer that has at least two network interfaces. Such a host could act as a router between the networks these interfaces are attached to; it is capable of routing IP packets from one network to another. However, to use a dual-homed host as a firewall, you disable this routing function. Thus, IP packets from one network (e.g., the Internet) are not directly routed to the other network (e.g., the internal, protected network). Systems inside the firewall can communicate with the dual-homed host, and systems outside the firewall (on the Internet) can communicate with the dual-homed host, but these systems can’t communicate directly with each other. IP traffic between them is completely blocked.

Some variations on the dual-homed host architecture use IP to the Internet and some other network protocol (for instance, NetBEUI) on the internal network. This helps to enforce the separation between the two networks, making it less likely that host misconfigurations will let traffic slip from one interface to another, and also reducing the chance that if this does happen there will be vulnerable clients. However, it does not make a significant difference to the overall security of the firewall.

The network architecture for a dual-homed host firewall is pretty simple: the dual-homed host sits between, and is connected to, the Internet and the internal network. Figure 6.2 shows this architecture.

Figure 6.2. Dual-homed host architecture

Dual-homed hosts can provide a very high level of control. If you aren’t allowing packets to go between external and internal networks at all, you can be sure that any packet on the internal network that has an external source is evidence of some kind of security problem.

On the other hand, dual-homed hosts aren’t high-performance devices. A dual-homed host has more work to do for each connection than a packet filter does, and correspondingly needs more resources. A dual-homed host won’t support as much traffic as an equivalent packet filtering system.

Since a dual-homed host is a single point of failure, it’s important to make certain that its host security is absolutely impeccable. An attacker who can compromise the dual-homed host has full access to your site (no matter what protocols you are running). An attacker who crashes the dual-homed host has cut you off from the Internet. This makes dual-homed hosts inappropriate if being able to reach the Internet is critical to your business.

You are particularly vulnerable to problems with the host’s IP implementation, which can crash the machine or pass traffic through it. These problems exist with packet filtering routers as well, but they are less frequent and usually easier to fix. Architectures that involve multiple devices are usually more resilient because multiple different IP implementations are involved.

A dual-homed host can provide services only by proxying them, or by having users log into the dual-homed host directly. You want to avoid having users log into the dual-homed host directly. As we discuss in Chapter 10, user accounts present significant security problems by themselves. They present special problems on dual-homed hosts, where users may unexpectedly enable services you consider insecure. Furthermore, most users find it inconvenient to use a dual-homed host by logging into it.

Proxying is much less problematic but may not be available for all services you’re interested in. Chapter 9, discusses some workarounds for this situation, but they do not apply in every case. Using a dual-homed host as your only network connection actually slightly eases some problems with proxying; if the host pretends to be a router, it can intercept packets bound for the outside world and transparently proxy them without anybody else’s cooperation.

Proxying is much better at supporting outbound services (internal users using resources on the Internet) than inbound services (users on the Internet using resources on the internal network). In a dual-homed host configuration, you will normally have to provide services to the Internet by running them on the dual-homed host. This is not usually advisable because providing services to the Internet is risky, and the dual-homed host is a security-critical machine that you don’t want to put risky services on. It might be acceptable to put a minimally functional web server on the dual-homed host (for instance, one that was only capable of providing HTML files and had no active content features, additional protocols, or forms processing), but it would clearly be extremely dangerous to provide a normal web server there.

The screened subnet architecture we describe in a later section offers some extra options for providing new, untrusted, or inbound services (e.g., you can add a worthless machine to the screened subnet that provides only an untrusted service).

Many single-box firewalls actually provide some combination of proxying and packet filtering. This gives you many of the advantages of both; you can allow some protocols at high speed while still having detailed control. It also gives you many of the disadvantages of both; you are vulnerable to problems where protocols that you thought were forced through the proxies are simply passed on by the packet filters. In addition, you have all the normal risks of having only a single entity between you and the great outside world.

A screened host architecture is appropriate when:

The perimeter network is another layer of security, an additional network between the external network and your protected internal network. If an attacker successfully breaks into the outer reaches of your firewall, the perimeter net offers an additional layer of protection between that attacker and your internal systems.

Here’s an example of why a perimeter network can be helpful. In many network setups, it’s possible for any machine on a given network to see the traffic for every machine on that network. This is true for most Ethernet-based networks (and Ethernet is by far the most common local area networking technology in use today); it is also true for several other popular technologies, such as token ring and FDDI. Snoopers may succeed in picking up passwords by watching for those used during Telnet, FTP, and rlogin sessions. Even if passwords aren’t compromised, snoopers can still peek at the contents of sensitive files people may be accessing, interesting email they may be reading, and so on; the snooper can essentially “watch over the shoulder” of anyone using the network. A large number of tools are available that attackers use to do this sort of snooping and to conceal that it’s being done.

With a perimeter network, if someone breaks into a bastion host on the perimeter net, they’ll be able to snoop only on traffic on that net. All the traffic on the perimeter net should be either to or from the bastion host, or to or from the Internet. Because no strictly internal traffic (that is, traffic between two internal hosts, which is presumably sensitive or proprietary) passes over the perimeter net, internal traffic will be safe from prying eyes if the bastion host is compromised.

Obviously, traffic to and from the bastion host, or the external world, will still be visible. Part of the work in designing a firewall is ensuring that this traffic is not itself confidential enough that reading it will compromise your site as a whole.

With the screened subnet architecture, you attach a bastion host (or hosts) to the perimeter net; this host is the main point of contact for incoming connections from the outside world; for example:

and so on.

Outbound services (from internal clients to servers on the Internet) are handled in either of these ways:

In either case, packet filtering allows the bastion host to connect to, and accept connections from, hosts on the Internet; which hosts, and for what services, are dictated by the site’s security policy.

Much of what the bastion host does is act as proxy server for various services, either by running specialized proxy server software for particular protocols (such as HTTP or FTP), or by running standard servers for self-proxying protocols (such as SMTP).

Chapter 10, describes how to secure a bastion host, and the chapters in Part III, describe how to configure individual services to work with the firewall.

The interior router (sometimes called the choke router in firewalls literature) protects the internal network both from the Internet and from the perimeter net.

The interior router does most of the packet filtering for your firewall. It allows selected services outbound from the internal net to the Internet. These services are the services your site can safely support and safely provide using packet filtering rather than proxies. (Your site needs to establish its own definition of what “safe” means. You’ll have to consider your own needs, capabilities, and constraints; there is no one answer for all sites.) The services you allow might include outgoing HTTP, Telnet, FTP, and others, as appropriate for your own needs and concerns. (For detailed information on how you can use packet filtering to control these services, see Chapter 8.)

The services the interior router allows between your bastion host (on the perimeter net itself) and your internal net are not necessarily the same services the interior router allows between the Internet and your internal net. The reason for limiting the services between the bastion host and the internal network is to reduce the number of machines (and the number of services on those machines) that can be attacked from the bastion host, should it be compromised.

You should limit the services allowed between the bastion host and the internal net to just those that are actually needed, such as SMTP (so the bastion host can forward incoming email), DNS (so the bastion host can answer questions from internal machines, or ask them, depending on your configuration), and so on. You should further limit services, to the extent possible, by allowing them only to or from particular internal hosts; for example, SMTP might be limited only to connections between the bastion host and your internal mail server or servers. Pay careful attention to the security of those remaining internal hosts and services that can be contacted by the bastion host, because those hosts and services will be what an attacker goes after — indeed, will be all the attacker can go after — if the attacker manages to break in to your bastion host.

In theory, the exterior router (sometimes called the access router in firewalls literature) protects both the perimeter net and the internal net from the Internet. In practice, exterior routers tend to allow almost anything outbound from the perimeter net, and they generally do very little packet filtering. The packet filtering rules to protect internal machines would need to be essentially the same on both the interior router and the exterior router; if there’s an error in the rules that allows access to an attacker, the error will probably be present on both routers.

Frequently, the exterior router is provided by an external group (for example, your Internet provider), and your access to it may be limited. An external group that’s maintaining a router will probably be willing to put in a few general packet filtering rules but won’t want to maintain a complicated or frequently changing rule set. You also may not trust them as much as you trust your own routers. If the router breaks and they install a new one, are they going to remember to reinstall the filters? Are they even going to bother to mention that they replaced the router so that you know to check?

The only packet filtering rules that are really special on the exterior router are those that protect the machines on the perimeter net (that is, the bastion hosts and the internal router). Generally, however, not much protection is necessary, because the hosts on the perimeter net are protected primarily through host security (although redundancy never hurts).

The rest of the rules that you could put on the exterior router are duplicates of the rules on the interior router. These are the rules that prevent insecure traffic from going between internal hosts and the Internet. To support proxy services, where the interior router will let the internal hosts send some protocols as long as they are talking to the bastion host, the exterior router could let those protocols through as long as they are coming from the bastion host. These rules are desirable for an extra level of security, but they’re theoretically blocking only packets that can’t exist because they’ve already been blocked by the interior router. If they do exist, either the interior router has failed, or somebody has connected an unexpected host to the perimeter network.

So, what does the exterior router actually need to do? One of the security tasks that the exterior router can usefully perform — a task that usually can’t easily be done anywhere else — is the blocking of any incoming packets from the Internet that have forged source addresses. Such packets claim to have come from within the internal network but actually are coming in from the Internet.

The interior router could do this, but it can’t tell if packets that claim to be from the perimeter net are forged. While the perimeter net shouldn’t have anything fully trusted on it, it’s still going to be more trusted than the external universe; being able to forge packets from it will give an attacker most of the benefits of compromising the bastion host. The exterior router is at a clearer boundary. The interior router also can’t protect the systems on the perimeter net against forged packets. (We discuss forged packets in greater detail in Chapter 4.)

Another task that the exterior router can perform is to prevent IP packets containing inappropriate source addresses from leaving your network. All traffic leaving your network should come from one of your source addresses. If not, then either you have a serious configuration problem, or somebody is forging source addresses.

Although filtering inappropriate source addresses outbound doesn’t provide any network protection to you, it prevents an intruder from using your systems to launch certain types of attacks on other sites. If the exterior router is configured to alert you when forged source addresses are seen, this may be just the early warning alarm you need in order to detect a serious network problem. The practice of being a good network citizen may also be enough to keep the name of your site out of a possibly embarrassing news headline.

A screened subnet architecture is appropriate for most uses.

In a split-screened subnet, there is still a single interior router and an exterior router, but multiple networks are between the two routers. In general, the screened networks are connected to each other by one or more dual-homed hosts, not by yet another router.

Some sites use this architecture purely to provide defense in depth, protecting a proxy host with the routers. The routers provide protection from forgery, and protection from failures where the dual-homed host starts to route traffic. The dual-homed host provides finer controls on the connections than packet filtering. This is a belt-and-suspenders firewall, providing excellent multilayered protection, although it requires careful configuration on the dual-homed host to be sure you’re taking full advantage of the possibilities. (There’s no point in running simple, straight-through proxies.) Figure 6.5 shows this configuration.

Figure 6.5. Split-screened subnet with dual-homed host

Others use this architecture to provide administrative access to machines that also provide service to the Internet. This allows administrators to use protocols that are too dangerous to allow to the Internet on a sensitive machine (for instance, the NT-native protocols used for remote User Manager and Performance Monitor use) without relying solely on the exterior router as protection. It also may be useful for performance reasons on machines making intense use of the network; it prevents administrative traffic from using bandwidth that could be used to serve user requests. Figure 6.6 shows this sort of architecture.

In fact, machines that can drive multiple high-speed network interfaces at full speed may benefit from having three network interfaces; one to speak to the external users, one to speak to the internal administrators, and one with no connections to other networks that is used for backups and/or communications among bastion hosts. Figure 6.8 shows this sort of architecture.

Figure 6.6. Split-screened subnet with no through traffic

In some cases you will want to have multiple, independent screened subnets, with separate exterior routers. Figure 6.7 shows this configuration.

Figure 6.7. Architecture using multiple perimeter nets (multiple firewalls)

You might put in multiple perimeter nets to provide redundancy. It doesn’t make much sense to pay for two connections to the Internet, and then run them both through the same router or routers. Putting in two exterior routers, two perimeter nets, and two interior routers ensures that no single point of failure is between you and the Internet.^[1]

You might also put in multiple perimeter nets for privacy, so that you can run moderately confidential data across one, and an Internet connection across the other. In that case, you might even attach both perimeter nets to the same interior router.

You might also want to use multiple perimeter nets to separate inbound services (services that you provide to the Internet, like publicly accessible web servers) from outbound services (services that allow your users to get to the Internet, like a caching web proxy). It is much easier to provide truly strong security to these functions if you separate them, and if you use a split perimeter net for the inbound services.

Having multiple perimeter nets is less risky than having multiple interior routers sharing the same internal net, but it’s still a maintenance headache. You will probably have multiple interior routers, presenting multiple possible points of compromise. Those routers must be watched very carefully to keep them enforcing appropriate security policies; if they both connect to the Internet, they need to enforce the same policy. Figure 6.8 shows the sort of firewall an Internet service provider might use, with many perimeter nets and multiple connections to the Internet.

Figure 6.8. An intricate firewall setup

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 MX [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.)

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, 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.

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

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.

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:

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) 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.

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:

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.

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, 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, and Chapter 12, 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:

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.

Laboratory and test networks are often the first networks that people consider separating from the rest of an organization via a firewall (usually as the result of some horrible experience where something escapes the laboratory and runs amok). Unless people are working on routers, this type of firewall can be quite simple. Neither a perimeter net nor a bastion host is needed, because there is no worry about snooping (all users are internal anyway), and you don’t need to provide many services (the machines are not people’s home machines). In most cases, you’ll want a packet filtering router that allows any connection inbound to the test network but only known safe connections from it. (What’s safe will depend on what the test network is playing with, rather than on the normal security considerations.)

In a few cases (for example, if you are testing bandwidth on the network), you may want to protect the test network from outside traffic that would invalidate tests, in which case you’ll deny inbound connections and allow outbound connections.

If you are testing routers, it’s probably wisest to use an entirely disconnected network; if you don’t do this, then at least prevent the firewall router from listening to routing updates from the test network. You can do this in a number of ways, depending on your network setup, what you’re testing, and what routers you have available. You might do any of the following:

If you have a number of test networks, you may find it best to set up a perimeter net for them and give each one a separate router onto the perimeter net, putting most of the packet filtering in the router between the perimeter and the main network. That way, if one test network crashes its router, the rest still have their normal connectivity.

If your testing involves external connections, the test network has to be treated as an external network itself; see Section 6.7.4, later in this chapter.

Test networks are dangerous but not necessarily less secure than other networks. Many organizations also have some networks that are intrinsically less secure than most. For example, a university may consider networks that run through student dormitories to be particularly insecure; a company may consider demonstration networks, porting labs, and customer training networks to be particularly insecure. Nevertheless, these insecure networks need more interaction with the rest of the organization than does a purely external network.

Networks like dormitory networks and porting labs, where external people have prolonged access and the ability to bring in their own tools, are really as insecure as completely external networks and should be treated that way. Either position them as a second external connection (a new connection on your exterior router or a new exterior router) or set up a separate perimeter network for them. The only advantage these networks offer over purely external networks is that you can specify particular software to be run on them, which means you can make use of encryption effectively.

External people may also be able to gain access to your internal network if you use wireless networking devices. These network devices provide more accessibility and less security than traditional fixed networking. In particular, they often have a range that extends outside of your physical building, and they provide little or no authentication. This can allow anyone who owns a compatible device to connect to your network by sitting in the parking lot or in an adjacent building. Even if the range of the wireless device does not extend outside of your facilities, they make it much harder to notice a visitor attempting to gain access to your network. Some wireless networking devices provide stronger authentication and encryption facilities that prevent eavesdropping and unauthorized access. In most cases, however, you should treat a wireless network as an untrusted network and place a firewall between it and the rest of your network.

Demonstration and training labs, where external people have relatively brief, supervised access and cannot bring in tools, can be more trusted (as long as you are sure that people really do have relatively brief, supervised access and cannot bring in tools!). You still need to use a packet filtering router or a dual-homed host to prevent confidential traffic from flowing across those networks. You will also want to limit those networks to connections to servers you consider secure. However, you may be willing to provide NFS service from particular servers, for example, which you wouldn’t do to a purely untrusted network. One of your main concerns should be preventing your trusted users from doing unsafe things while working on those networks (for example, logging into the machines on their desks and forgetting to log out again, or reading confidential electronic mail). This should be done with a combination of training and force (ensuring that the most insecure uses fail).

This is a place where a dual-homed host can be quite useful, even with no proxies on it; the number of people who need to use the host is probably small, and having to log into it will ensure that they see warning messages. The host will also be unable to provide some tempting but highly insecure services; for example, you won’t be able to run NFS except from the dual-homed host, and people won’t be able to mount their home machine’s filesystems.

Just as most organizations have points where they’re particularly insecure, most of them have points where they’re particularly security-conscious, such as:

Many countries have legal requirements for the protection of personal data, which are likely to apply to anywhere that employee, student, client, or patient records are kept. Some unclassified government work also requires extra protections.

Networks for doing classified work — at any level of classification — not only need to be more secure, but also need to meet all relevant government regulations. Generally speaking, they will have to be separated from unclassified networks. In any case, they are outside of the scope of this book. If you need to set one up, consult your security officer; traditional firewalls will not meet the requirements.^[2]

You can choose to meet your requirements for extra security either by encrypting traffic that passes over your regular internal networks, or by setting up separate networks for the secure traffic. Separate networks are technically easier as long as separate machines are on them. That is, if you have a secure research project that owns particular computers, and if people log into them to work on that project, it’s reasonably simple to set up a straightforward single-machine firewall (a packet filtering router, most likely). That firewall will treat your normal network as the insecure external universe. Because the lab machines probably don’t need many services, a bastion host is unnecessary, and a perimeter net is needed only for the most secret ventures.

If you are dealing with people whose day-to-day work is secure, and who don’t have separate machines for that work, a separate network becomes harder to implement. If you put their machines onto a more secure network, they can’t work easily with everybody else at the site, and they need a number of services. In this case, you’ll need a full bastion host and therefore probably a perimeter net to put it on. It’s tempting to connect their machines to two networks, the secure net and the insecure net, so they can transmit confidential data over one and participate with the rest of the site on the other, but this is a configuration nightmare. If they’re attached to both at once, each host is basically a dual-homed host firewall, with all the attendant maintenance problems. If they can be attached to only one at a time, things are more secure. However, configuring the machines is unpleasant for you, and moving back and forth is unpleasant for the user.

At a university, where there are sharp distinctions between different organizations, putting the registrar’s office and the financial people on secure networks, firewalled from the rest of the university, will probably work. At a company or government office, where most people work in the same environment, look into using encryption in your applications instead.

Sometimes, organizations come together for certain limited reasons, such as a joint project; they need to be able to share machines, data, and other resources for the duration of the project. For example, look at the decision of IBM and Apple to collaborate on the PowerPC; undertaking one joint project doesn’t mean that IBM and Apple have decided to merge their organizations or to open up all their operations to each other.

Although the two parties have decided to trust each other for the purposes of this project, they are still competitors. They want to protect most of their systems and information from each other. It isn’t just that they may distrust each other; it’s also that they can’t be sure how good the other’s security is. They don’t want to risk that an intruder into their partner’s system might, through this joint venture, find a route into their system as well. This security problem occurs even if the collaborators aren’t competitors.

You may also want to connect to an external company because it is an outside vendor to you. A number of services depend on information transfer, from shipping (you tell them what you want to ship; they tell you what happened to your shipment), to architecture (you give them specifications; they give you designs), to chip fabrication (you send them the chip design, they give you status on the fabrication process). These outside vendors are not competitors in any sense, but they frequently also work for competitors of yours. They are probably aware of confidentiality issues and try to protect the information they are supposed to have, to the best of their ability. On the other hand, if there are routing slip-ups, and data you’re not explicitly sending to them crosses their networks, they are probably going to be completely unconscious of it, and the data will be at risk.

This may seem far-fetched, but it turns out to be a fairly routine occurrence. One company was mystified to discover routes on its network for a competitor’s internal network, and still more baffled to discover traffic using these routes. It turned out that the shortest route between them and their competitor was through a common outside vendor. The traffic was not confidential because it was all traffic that would have gone through the Internet. On the other hand, the connection to the outside vendor was not treated as if it were an Internet connection (the outside vendor itself was not Internet-connected, and nobody had considered the possibility of its cross-connecting Internet-connected clients). Both companies had sudden, unexpected, and unprotected vulnerabilities.

An internal firewall limits exposure in such a situation. It provides a mechanism for sharing some resources, while protecting most of them. Before you set out to build an internal firewall, be sure you’re clear on what you want to share, protect, and accomplish. Ask these questions:

Exactly what you’re trying to accomplish, and what your security concerns are, will determine what firewall technologies are going to be useful to you.

Shared perimeter networks are a good way to approach joint networks. Each party can install its own router under its own control, onto a perimeter net between the two organizations. In some configurations, these two routers might be the only machines on the perimeter net, with no bastion host. If this is the case, then the “net” might simply be a high-speed serial line (e.g., a 56 Kbps or T1/E1 line) between the two routers, rather than an Ethernet or another type of local area network.

This is highly desirable with an outside vendor. Most of them are not networking wizards, and they may attempt to economize by connecting multiple clients to the same perimeter network. If the perimeter net is an Ethernet or something similar, any client that can get to its router on that perimeter network can see the traffic for all the clients on that perimeter network — which, with some providers, is almost guaranteed to be confidential information belonging to a competitor. Using a point-to-point connection as the “perimeter net” between the outside vendor and each client, rather than a shared multiclient perimeter net, will prevent them from doing this, even accidentally.

You might not actually need to place a bastion host on the perimeter network between two organizations. The decision about whether you need a bastion host depends on what services are required for your firewall and how much each organization trusts the other. Bastion hosts on the perimeter net are rarely required for relationships with outside vendors; usually you are sending data over one particular protocol and can adequately protect that as a screened host.

If the organizations have a reasonable amount of trust in each other (and, by extension, in each other’s security), it may be reasonable to establish the packet filters so that clients on the other side can connect to internal servers (such as SMTP and DNS servers) directly.

On the other hand, if the organizations distrust each other, they might each want to place their own bastion host, under their own control and management, on the perimeter net. Traffic would flow from one party’s internal systems, to their bastion host, to the other party’s bastion host, and finally to the other party’s internal systems.