 |  |
8.8. Choosing a Packet Filtering Router
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.
8.8.1. It Should Have Good Enough Packet Filtering Performance for Your Needs
any 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-Kbps or 1.544-Mbps (T-1) 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 Kbps can carry at most 350 packets per second, and a line capable of 1.544 Mbps (a T-1 line, for example) can carry at most 9,650 packets per second, as shown in the following table. (Cable modems and DSL are variable-rate technologies; depending on the provider, the price you're willing to pay, your location, and the number of other users, speeds may vary from a few hundred kilobits a second to tens of megabits. It's generally safe to assume that theoretical 10-base T speeds are an effective maximum for both.)
| Connection Type |
Bits/Second (Approximate) |
Packets/Second (20-byte Packets) |
Packets/Second (40-byte Packets) |
|---|---|---|---|
| V.32bis modem | 14,400 | 90 | 45 |
| V.90 modem or 56-Kbps leased line | 56,000 | 350 | 175 |
| ISDN | 128,000 | 800 | 400 |
| T-1 leased line | 1,544,000 | 9,650 | 4,825 |
| 10-base T or Ethernet (practical) | 3,000,000 | 18,750 | 9,375 |
| 10-base T or Ethernet (theoretical) | 10,000,000 | 62,500 | 31,250 |
| T-3 leased line | 45,000,000 | 281,250 | 140,625 |
| FDDI or 100-base T | 100,000,000 | 625,000 | 312,500 |
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-Kbps line and 4,825 packets per second for a 1.544-Mbps 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.
any manufacturers of firewalls cite speeds in Mbps in order to provide numbers that are comparable to network speeds. These numbers can be highly misleading because firewall performance is dependent on packets per second, not bits per second. Two firewalls that claim to process packets at exactly the same speed may show dramatically different bits per second rates, depending on the assumptions their manufacturers have made about average packet sizes. Ask for rates in packets per second, and compare that to data about your incoming packet rates. If this information is not directly available, insist on knowing what assumptions were made about packet sizes, so that you can make reasonable comparisons.
In addition, firewall performance depends on the complexity of packet filters. You should be sure that the speeds you are quoted are speeds with a reasonable filter set (some manufacturers quote the speed achieved with packet filtering enabled but no filters set, for instance). Stateful packet filtering, intelligent packet filtering, and reassembly of fragmented packets will all slow down performance.
Do not assume that firewall performance will depend on processor speed. The speed of a router (and a packet filter is just a special kind of router) tends to be much more dependent on other factors, including the amount of available memory, the performance of the network interfaces themselves, and the speed and bandwidth of internal connections. Upgrading a machine's processor often has little or no effect on its speed at processing network traffic.
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 local area network speeds, which are usually theoretically at least 10 Mbps, 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 fairly rare at present.) In addition, internal firewalls often require more complex filter sets and support for a larger number of protocols, which will further reduce their performance.
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 speed of those networks to route between them.
If you have a truly high-speed connection to the Internet (because you have a lot of internal Internet users, a lot of services that you're offering to the Internet, or both), router performance may be a real issue. In fact, many really large sites require more performance and more reliability than any single router can provide. In this situation, it's appropriate to worry a great deal about performance. The fewer routers you use to connect to the Internet, the better. Each independent Internet connection is another possible hole in your security. If you must use multiple routers, get the best performance you can, so as to use as few routers as possible. In some cases, this may require carefully designing your network so that you simplify the filtering rules on routers that have to support large amounts of traffic.
8.8.2. It Can Be a Single-Purpose Router or a General-Purpose Computer
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 that 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 will certainly 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 Windows NT and many other icrosoft operating systems, as well as most variants of Unix. (See Appendix B, "Tools" 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 6, "Firewall Architectures", combining the bastion host with the external packet filter is a reasonable thing to do from a security perspective.
8.8.3. It Should Allow Simple Specification of Rules
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.
On the other hand, you do not want the packet filter to entirely hide the details. You should also avoid packet filtering implementations that require you turn on protocols by name, without specifying exactly what ports this will allow in what directions.
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.
8.8.4. It Should Allow Rules Based on Any Header or Meta-Packet Criteria
You want to be able to specify rules based on any of the header information or meta-packet information available for your packets. Header information includes the following:
- IP source and destination address
- IP options
Protocol, such as TCP, UDP, or ICMP
TCP or UDP source and destination port
ICMP message type
Start-of-connection (ACK bit) information for TCP packets
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 previously, source port information is not reliable). We believe that this is a fallacy and that such decisions are better left to well-informed customers.
8.8.5. It Should Apply Rules in the Order Specified
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. (One innovative vendor even touts this as a user interface benefit, because you no longer have to worry about what order to specify the rules in!) This causes several problems:
- Reordering rules makes it difficult for you to figure out what's going on, and what the router is going to do with a particular set of filtering instructions. Configuring a packet filtering system is already complicated enough, without having a vendor add additional complications by merging and reordering rule sets.
- If any quirks or bugs are in the merging or reordering of rule sets (and there often are because it's something that's very difficult for the vendors to test), it becomes impossible to figure out what the system is going to do with a given set of filters.
- Most importantly, reordering rules can break a rule set that would work just fine if it had not been reordered.
[19]172.16 and 10 are both reserved network numbers, which no company or university could have. They're used for example purposes only. Not all the IP addresses in a network's range are valid host addresses; addresses where the host portion is all ones or all zeros are reserved and cannot be allocated to hosts, making the range of host addresses on 172.16 actually 172.16.0.1 through 172.16.255.254.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 addresses 172.16.6.0 through 172.16.6.255). You want all subnets at the university to be able to access this project subnet. The university's eight-bit 10.1.99 subnet 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? You could try the following three packet filtering rules. (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.)
| Rule | Source Address | Dest. Address | Action |
|---|---|---|---|
| A | 10.0.0.0/8 | 172.16.6.0/24 | Permit |
| B | 10.1.99.0/24 | 172.16.0.0/16 | Deny |
| C | Any | Any | Deny |
- Rule A permits the university to reach your project subnet.
- Rule B locks the hostile subnet at the university out of everything else on your network.
- Rule C disallows Internet access to your network.
8.8.5.1. If the rules are applied in the order ABC
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.| Packet |
Source Address |
Dest. Address |
Desired Action |
Actual Action (by Rule) |
|---|---|---|---|---|
| 1 | 10.1.99.1 | 172.16.1.1 | Deny | Deny (B) |
| 2 | 10.1.99.1 | 172.16.6.1 | Permit | Permit (A) |
| 3 | 10.1.1.1 | 172.16.6.1 | Permit | Permit (A) |
| 4 | 10.1.1.1 | 172.16.1.1 | Deny | Deny (C) |
| 5 | 192.168.3.4 | 172.16.1.1 | Deny | Deny (C) |
| 6 | 192.168.3.4 | 172.16.6.1 | Deny | Deny (C) |
- Packet 1 is from a machine at the university on the hostile subnet to a random machine on your network (not on the project subnet); you want it to be denied; it is, by rule B.
- Packet 2 is from a machine at the university on the hostile subnet to a machine on your project subnet; you want it to be permitted; it is, by rule A.
- Packet 3 is from a random machine at the university to a machine on your project subnet; you want it to be permitted; it is, by rule A.
- Packet 4 is from a random machine at the university to one of your nonproject machines; you want it to be denied; it is, by rule C.
- Packet 5 is from a random machine on the Internet to one of your nonproject machines; you want it to be denied; it is, by rule C.
- Packet 6 is from a random machine on the Internet to one of your project machines; you want it to be denied; it is, by rule C.
8.8.5.2. If the rules are applied in the order BAC
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.| Rule | Source Address | Dest. Address | Action |
|---|---|---|---|
| B | 10.1.99.0/24 | 172.16.0.0/16 | Deny |
| A | 10.0.0.0/8 | 172.16.6.0/24 | Permit |
| C | Any | Any | Deny |
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).
| Packet | Source Address | Dest. Address | Desired Action | Actual Action (by Rule) |
|---|---|---|---|---|
| 1 | 10.1.99.1 | 172.16.1.1 | Deny | Deny (B) |
| 2 | 10.1.99.1 | 172.16.6.1 | Permit | Deny (B) |
| 3 | 10.1.1.1 | 172.16.6.1 | Permit | Permit (A) |
| 4 | 10.1.1.1 | 172.16.1.1 | Deny | Deny (C) |
| 5 | 192.168.3.4 | 172.16.1.1 | Deny | Deny (C) |
| 6 | 192.168.3.4 | 172.16.6.1 | Deny | Deny (C) |
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.
8.8.5.3. Rule B is actually not necessary
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 following tables show what happens in either case.| Rule | Source Address | Dest. Address | Action |
|---|---|---|---|
| A | 10.0.0.0/8 | 172.16.6.0/24 | Permit |
| C | Any | Any | Deny |
| Packet | Source Address | Dest. Address | Desired Action | Actual Action (by Rule) |
|---|---|---|---|---|
| 1 | 10.1.99.1 | 172.16.1.1 | Deny | Deny (C) |
| 2 | 10.1.99.1 | 172.16.6.1 | Permit | Permit (A) |
| 3 | 10.1.1.1 | 172.16.6.1 | Permit | Permit (A) |
| 4 | 10.1.1.1 | 172.16.1.1 | Deny | Deny (C) |
| 5 | 192.168.3.4 | 172.16.1.1 | Deny | Deny (C) |
| 6 | 192.168.3.4 | 172.16.6.1 | Deny | Deny (C) |
8.8.5.4. Packet filtering rules are tricky
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 that 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. If a vendor will not or cannot tell you what order rules are applied in, do not buy that vendor's product.
8.8.6. It Should Apply Rules Separately to Incoming and Outgoing Packets, on a Per-Interface Basis
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:
- The system is always "outside" its own filters.
- Detecting forged packets is difficult or impossible.
Configuring such systems is extremely difficult if they have more than two interfaces.
Now consider the second problem. If a router can filter only 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 that claim to have internal source addresses), as is illustrated in Figure 8-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 impose the following policy:
- The two engineering networks can communicate with each other without restrictions.
- The two engineering networks and the Internet can communicate with each other with certain restrictions.
- The two engineering networks and the finance network can communicate with each other with certain restrictions -- restrictions that are different from those between the engineering nets and the Internet.
- The finance network cannot communicate with the Internet under any circumstances.
Figure 8-4. Packet filtering restrictions on different interfaces
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:
- Engineering Net A
- Internet filters, finance net filters, engineering net B filters
- Engineering Net B
- Internet filters, finance net filters, engineering net A filters
- Finance Net
- Internet filters, engineering net A filters, engineering net B filters
- Internet
- Engineering net A filters, engineering net B filters, finance net filters
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:
- All the filters related to the Internet (regardless of whether they apply to the engineering nets or the finance net) on the Internet interface
- All the filters related to the finance net (regardless of whether they apply to the engineering nets or the Internet) on the finance interface
- No filters at all on the engineering interfaces (thus allowing maximum performance for traffic between the engineering nets because it wouldn't pass through any filters)
What if the packet filtering system had both kinds of filters but didn't allow you to specify individual interfaces? This kind of system has all the problems of an outbound-only system (you have to merge all of the rules into a single set and incur packet filtering overhead even on unfiltered connections). In addition, it becomes very difficult to detect forged source addresses. Most such systems have special configurations to deal with forged source addresses, but these are less flexible than the controls you can get by directly specifying rules. In particular, they may protect you from external forgeries without detecting internal forgeries.
8.8.7. It Should Be Able to Log Accepted and Dropped Packets
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 specific information that is logged is also important and packet filtering routers have widely varying capabilities. You will want information about which rule and packet caused the log entry to be made. Ideally, you would like to know the definition of the rule, but a name or other constant identifier would be sufficient. A rule number which changes every time you edit the rule set is the least useful rule identifier, although it's better than no information at all.
You will also want information about the packet itself. At a minimum you will want to see source and destination IP addresses and protocol. For TCP and UDP packets you will want to see source and destination port numbers (and the flags for TCP packets). For ICMP you will want to see the type and code. Without this information it can be very difficult to debug rulesets or, when you are being attacked, trace or block packets from an unwanted source. In some situations, it is preferable to log the entire packet, instead of a summary.
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. Some packet filters also have various alerting capabilities (they can page an administrator or send email). These capabilities are useful but are less flexible than a generalized alerting system based on SNMP. If the packet filtering machine has a modem directly attached, and is capable of completing a page independently, paging capabilities provide a useful alerting mechanism of last resort, where the machine can call for help if it is unable to send any network traffic at all. Otherwise, paging on the packet filter is not of much interest; you would be better served by an alert sent to a general-purpose system.
8.8.8. It Should Have Good Testing and Validation Capabilities
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 come 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.
|  | |
| 8.7. Filtering by Service |  | 8.9. Packet Filtering Implementations for General-Purpose Computers |
