A number of packet filtering routers are available, some good and some not so good. Almost every dedicated router supports packet filtering in some form. In addition, packet filtering packages are available for many general-purpose UNIX and PC platforms you might want to use as routers.
How do you choose the best packet filtering router for your site? This section outlines the most important capabilities a filtering router should have. You should determine which of these capabilities are important to you and select a filtering system that offers at least those capabilities.
Many people worry unnecessarily about packet filtering performance. In most Internet firewalls, in fact, the limiting factor on performance is the speed of your connection to the Internet, not the speed of the packet filtering system. The right question to ask about a packet filtering system is not "How fast is it?" The right question is "Is it fast enough for my needs?"
Internet connections are commonly either 56-Kb/s or 1.544-Mb/s (T1) lines. Packet filtering is a per-packet operation. Therefore, the smaller the packets, the more packets will be handled every second, and the more filtering decisions a packet filtering system will have to make every second. The smallest possible IP packet - a bare packet containing only an IP header and no data whatsoever - is 20 bytes (160 bits) long. Thus, a line capable of 56 Kb/s can carry at most 350 packets per second, and a line capable of 1.544 Mb/s (a T-1 line, for example) can carry at most 9,650 packets per second, as shown in the following table.
In fact, though, you will rarely see bare IP packets; there is always something in the data segment (e.g., a TCP , UDP , or ICMP packet). A typical packet crossing a firewall would be a TCP/IP packet because most Internet services are TCP -based. The minimum possible TCP/IP packet size, for a packet containing only the IP header and TCP header and no actual data, is 40 bytes, which cuts the maximum packet rates in half, to 175 packets per second for a 56-Kb/s line and 4825 packets per second for a 1.544-Mb/s line. Real packets containing real data are going to be larger still, reducing the packet-per-second rates still further.
These per-second packet rates are well within the capabilities of many of the packet filtering systems, both commercial and freely available off the Internet, that are available today. Some can go much faster.
Speed is likely to be more of an issue in a firewall that is internal to an organization's network. Such a firewall will need to run at LAN speeds, which are usually theoretically at least 10 Mb/s, and may be much higher. (Firewalls are not practical within a gigabit-per-second network at this point. Fortunately, from a firewalls perspective, such networks are rare at present.)
A firewall with more than two connections may also have higher speed requirements. With two connections, the maximum required speed is that of the slowest connection. With three connections, the required speed can rise. For example, if you put a second Internet connection onto an external router, it now needs to drive both at full speed if it's not going to be a limiting factor. If you put two internal networks onto it, it's going to need to achieve the higher LAN speed to route between the two internal networks.
Don't expect a single device to serve as your packet-filtering router and also to do something that's not part of your firewall. (You may have a device that's doing packet filtering and proxying, or packet filtering and selected bastion host services, or even all three.) In a practical sense, you should expect to be using a dedicated packet-filtering router. This doesn't mean you have to buy a single-purpose router, however. You might choose to use either a traditional, single-purpose router, or a general-purpose computer dedicated to routing. What are the pros and cons of each choice?
If you have a large number of networks or multiple protocols, you will probably need a single-purpose router. Routing packages for general-purpose computers usually do not have the speed or flexibility of single-purpose routers, and you may find you will need an inconveniently large machine to accommodate the necessary interface boards.
On the other hand, if you are filtering a single Internet link, you may not need to do any more than route IP packets between two Ethernets. This is well within the capabilities of a reasonable 486-based (or comparable) computer, and such a machine may well be cheaper than a single-purpose router. (It may even be free, if you already have one available within your organization.) Routing and filtering packages are available for MS-DOS and most variants of UNIX . (See Appendix B for information about available packages.)
Whatever device you use for your filtering router, firewalling should be all the router does. For example, if possible, don't use one device as both your filtering router and the backbone router that ties together multiple separate internal networks. Instead, use one device to tie together your internal networks and a separate (much smaller) device as your filtering router. The more complex the filtering router and its configuration, the more likely it is that you'll make a mistake in its configuration, which could have serious security implications. Filtering also has a significant speed impact on a router and may slow the router down to the point where it has difficulty achieving acceptable performance for the internal networks.
Some commercial firewall packages combine packet filtering with proxying on a machine that behaves like a single-purpose router. Others combine packet filtering with proxying or bastion host services on a high-powered general-purpose computer. This is fine, although it will increase your speed requirements. Don't expect to use a small machine to do this. Depending on what machines you have available, this may either be a good bargain (you buy a single large machine instead of multiple medium-sized ones) or a bad one (you buy a single large machine instead of adding a small machine to an existing configuration). As we've said in Chapter 4 , combining the bastion host with the external packet filter is a reasonable thing to do from a security perspective.
You want to be able to specify the rules for your packet filtering as simply as possible. Look for this feature in any device you select. From a conceptual point of view, packet filtering is complicated to begin with, and it's further complicated by the details and quirks of the various protocols. You don't want your packet filtering system to add any more complexity to the complications you already have to deal with.
In particular, you want to be able to specify rules at a fairly high level of abstraction. Avoid any packet filtering implementations that treat packets as simply unstructured arrays of bits and require you to state rules in terms of the offset and state of particular bits in the packet headers.
As we discussed before, you'll also probably want to be able to download the rules from another machine if you're using a single-purpose router. Nevertheless, you need a user interface that allows you to create and edit the rules without extreme pain, because you may periodically have to do so.
and similar information for any other protocols you're filtering on. Meta-packet information includes any information about the packet that the router knows, but that isn't in the headers themselves, e.g., which router interface the packet came in or is going out on. You want to be able to specify rules based on combinations of these header and meta-packet criteria.
For various reasons, many filtering products don't let you look at the TCP or UDP source port in making packet filtering decisions; they let you look only at the TCP or UDP destination port. This makes it impossible to specify certain kinds of filters. Some manufacturers who omit TCP / UDP source ports from packet filtering criteria maintain that such filtering isn't useful anyway, or that its proper use is "too dangerous" for customers to understand (because, as we've pointed out above, source port information is not reliable). We believe that this is a fallacy, and that such decisions are better left to well-informed customers.
Let's consider an example in which filters based on source port might be useful - access to Archie servers. As we discuss in Chapter 8 , Archie access presents some troublesome problems. The biggest is that the native Archie protocol is UDP -based, and at Internet firewalls UDP is generally blocked altogether (except for small "peepholes" for services such as DNS , NTP , and Archie). The reason for this blocking is usually to prevent outsiders from attacking RPC -based services like NIS/YP and NFS . Because RPC -based services don't run on fixed port numbers, you can't simply block access to the ports the RPC -based services run on (because you don't know what they are). Unlike TCP , UDP doesn't have ACK bits; thus, you can't do start-of-connection filtering. The packet filtering system can't tell, just by examining an incoming packet, whether that packet is a response from an external server to an internal client, or a command from an external client (possibly an attack program) to an internal server (such as NIS/YP or NFS ). With all of these obstacles, how, then, do you construct a rule set to allow Archie?
One of the characteristics of Archie is that there are only 20 or so Archie servers in the world. For performance reasons, your users will generally only want to talk to the handful of those servers that are "near" your site in the network topology (for example, there are only five servers in the United States). If you're willing to make certain assumptions about the security of the Archie servers (we discuss these in Chapter 8 ), you could enable Archie access for your users by allowing packets out to the Archie servers, and by allowing packets back in from the Archie servers (using source port filtering to determine this).
This is somewhat risky. If someone forges packets from port 1525 at an Archie server to an internal NFS server, they will succeed in getting responses from you. In order to do that, they need to guess that you might allow such packets, figure out an internal host address and the port that its NFS server is on, forge the packets, and intercept the answers. None of this is impossibly difficult for an attacker to do, although it's arguably more trouble than most attackers are willing to go to to attack most sites. Note that NFS packets normally fragment, and fragments are normally passed through packet filters, so they will probably succeed in getting some data (all but the first fragment of each NFS packet) even if your packet filter is smart enough to block outbound NFS by examining application-level protocol information. If you are facing determined attackers, this type of filtering is not sufficiently secure.
The following table shows a simple rule set that allows internal clients to interact with a known Archie server, and that disallows everything else. We assume that, for each packet, rules are evaluated in the order listed until a match is found; in that case, "Action" specifies what to do):
You want your packet filter to apply, in a predictable order, the rules you specify for it. By far the simplest order is the order in which you, the person configuring the router, specify the rules. Unfortunately, some products, instead of applying rules in the order you specify, try to reorder and merge rules to achieve greater efficiency in applying the rules. This causes several problems:
Let's consider an example. Imagine that you're in a corporation, working on a special project with a local university. Your corporate Class B network is 172.16 (i.e., your IP addresses are 172.16.0.0 through 172.16.255.255). The university owns Class A net 10 (i.e., their IP addresses are 10.0.0.0 through 10.255.255.255).
For the purposes of this project, you're linking your network directly to the university's, using a packet filtering router. You want to disallow all Internet access over this link (Internet access should go through your Internet firewall). Your special project with the university uses the 172.16.6 subnet of your Class B network (i.e., IP address 172.16.6.0 through 172.16.6.255). You want all subnets at the university to be able to access this project subnet. There is one eight-bit subnet at the university, the 10.1.99 subnet, that you know has a lot of hostile activity on it; you want to ensure that this subnet can only reach your project subnet.
How can you meet all these requirements? Specify the three packet filtering rules listed below. (In this example, we are considering only the rules for traffic incoming to your site; you'd need to set up corresponding rules for outgoing traffic.)
Now let's look at what happens in several different cases, depending on exactly how these rules are applied.
If the rules are applied in the order ABC - the same order specified by the user - the following table shows what happens with a variety of sample packets.
Thus, if the rules are applied in the order ABC , they accomplish what you want.
What would happen if the router reordered the rules by the number of significant bits in the source address, so that more specific rules are applied first? In other words, rules applying to more specific IP source addresses (i.e., rules that apply to a smaller range of source addresses) would be applied before rules applying to less specific IP source addresses? In this case, the rules would be applied in the order BAC .
Here are the same six sample packets, with the new outcomes if the rules are applied in the order BAC ; in bold face, we show how the actions differ from the previous case (in which rules are applied in the order specified by the user):
If the rules are applied in the order BAC , then packet 2, which should be permitted, is improperly denied by rule B. Now, denying something that should be permitted is safer than permitting something that should be denied, but it would be better if the filtering system simply did what you wanted it to do.
You can construct a similar example for systems that reorder rules based on the number of significant bits in the destination address, which is the most popular other reordering criteria.
If you consider this example carefully, you can see that the discussion about the hostile subnet, which is the reason for rule B, is redundant, and isn't necessary to achieve the desired results. Rule B is intended to limit the hostile subnet to accessing only your project subnet. Rule A, however, already restricts the entire university - including the hostile subnet - to accessing only your project subnet. If you omit rule B, then the rules will be applied in order AC regardless of whether or not the system reorders based on the number of significant bits in the IP source address. The tables below shows what happens in either case:
The point here is that getting filtering rules right is tricky. In this example, we are considering a relatively simple situation, and we've still managed to come up with a rule set that had a subtle error in it. Real-life rule sets are significantly more complex than these, and often include tens or hundreds of rules. Considering the implications and interactions of all those rules is nearly impossible, unless they are simply applied in the order specified. So-called "help" from a router, in the form of reordering rule sets, can easily turn an over-specified but working rule set into a nonworking rule set. You should make sure the packet filtering router you select doesn't reorder rule sets.
It's OK if the router does optimization, as long as the optimization doesn't change the effect of the rules. Pay close attention to what kind of optimizations your packet filtering implementation tries to do.
For maximum flexibility, capability, and performance, you want to be able to specify a separate rule set for incoming and outgoing packets on each interface. In this section, we'll show an example that demonstrates the problems you can run into with routers that aren't that flexible.
A limitation unfortunately shared by many packet filtering systems is that they let you examine packets only as they are leaving the system. This limitation leads to three problems:
Let's look at the first problem. If a router lets you look only at outgoing packets, then packets directed to the router itself are never subjected to packet filtering. The result is that the filtering doesn't protect the router itself. This is usually not too serious a problem, because there are typically few services on the router that could be attacked, and there are other ways to protect those services. Telnet is an example of a service that can be attacked in this way, but you can usually get around the routing problem by disabling the Telnet server, or by controlling from where it will accept incoming connections. SNMP is another commonly available and vulnerable service.
Now consider the second problem. If a router can only filter outgoing packets, it's difficult or impossible to detect forged packets being injected from the outside (that is, packets coming in from the outside, but which claim to have internal source addresses), as is illustrated in Figure 6.1 . Forgery detection is most easily done when the packet enters the router, on the inbound interface. Detecting forgeries on the outbound interface is complicated by packets generated by the router itself (which will have internal source addresses if the router itself has an internal address) and by legitimate internal packets mistakenly directed to the router (packets that should have been sent directly from their internal source to their internal destinations, but were instead sent to the filtering router, for instance by systems following a default route that leads to the filtering router).
The third problem with outbound-only filtering is that it can be difficult to configure packet filtering on such a router when it has more than two interfaces. If it has only two interfaces, then being able to do only outbound filtering on each interface is no big deal. There are only two paths through the router (from the first interface to the second, and vice versa). Packets going one way can be filtered as outgoing packets on one interface, while packets going the other way can be filtered as outgoing packets on the other interface. Consider, on the other hand, a router with four interfaces: one for the site's Internet connection, one for a finance network, and two for engineering networks. In such an environment, it wouldn't be unreasonable to want to impose the following policy:
Figure 6.9 illustrates this environment.
There are 12 paths through this router, from each of four interfaces to each of three other interfaces (in general, there are N * N-1 paths through an N-interface router). With an outbound-only filtering system, you would have to establish the following filtering on each interface:
Merging multiple filtering requirements in a single interface like this can be very tricky. Depending on the complexity of the filters and the flexibility of the filtering system, it may actually be impossible in some situations.
A more subtle problem with such a setup is that it imposes packet filtering overhead between the two engineering networks (which may result in a significant performance problem). With this setup, the router has to examine all the packets flowing between the two engineering nets, even though it will never decide to drop any of those packets.
Now look at the same scenario, assuming that the packet filtering system has both inbound and outbound filters. In this case, you could put:
What if a packet filtering system had inbound-only filters, rather than outbound-only filters? A system of this kind would address the first problem we described in this section: a router with inbound-only filters can be protected by its own filters. However, such a system would not address the second and more serious problem; you still have problems merging filtering rules on routers with more than two interfaces.
Make sure the packet filtering router gives you the option of logging all of the packets it drops. You want to know about any packets that are blocked by your packet filtering rules. These rules reflect your security policy and you want to know when somebody attempts to violate that policy. The simplest way to learn about these attempted violations is through such a log.
You'd also like to be able to log selected packets that were accepted. For example, you might want to log the start of each TCP connection. Logging all accepted packets is going to be too much data in normal operation, but may be worth it occasionally for debugging and for dealing with attacks in progress. Although you will probably be doing some logging at the packet destination, that logging won't work if the destination host has been compromised, and won't show packets that make it through the packet filter but don't have a valid destination. Those packets are interesting, because they may be probes from an attacker. Without information from the router, you won't have the complete picture of what the attacker is doing.
The logging should be flexible; the packet filter should give you the ability to log via syslog and to a console or a local file. It would also be helpful if the logging included the ability to generate SNMP traps on certain events.
An important part of establishing a firewall is convincing yourself (and others within your organization) that you've done the job right, and haven't overlooked anything. To do that, you need to be able to test and validate your configuration. Most of the packet filtering packages currently available have little or nothing in the way of testing and validation capabilities.
Testing and validation comes down to two related questions:
Unfortunately, with many products available today, both of these questions tend to be difficult to answer. In the few products that provide any kinds of testing capabilities, what the test says it will do with a given packet and what it actually does with such a packet are sometimes different, often because of subtle caching and optimization bugs. Some sites (and, we hope, some vendors!) have constructed filtering test beds, where they can generate test packets on one side of a filtering router and watch to see what comes through to the other side, but that's beyond the capabilities and resources of most sites. About the best you can do is pick something with a good reputation for not having many problems and good support for when it inevitably does have problems.