6.8.1 It Should Have Good Enough Packet Filtering Performance for Your Needs

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.

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

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

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.

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

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

	Direc-	Source	Dest.	Pro-	Source	Dest.
Rule	tion	Address	Address	tocol	Port	Port	Action
A	Out	Internal	Archie Server	UDP	>1023	1525	Permit
B	In	Archie Server	Internal	UDP	1525	>1023	Permit
C	Either	Any	Any	Any	Any	Any	Deny

• Rule A lets the clients talk to the Archie server.

• Rule B allows the Archie server to talk back to the clients.

• Rule C is the default rule that blocks everything else.

You can only do this if your filtering system allows you to filter based on source port.

6.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. 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 there are any quirks or bugs 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.

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).[6]

[6] 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 though 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 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.)

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

Now let's look at what happens in several different cases, depending on exactly how these rules are applied.

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

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:

• 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 6.9 illustrates this environment.

Figure 6.9: 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 A - Internet filters, finance filters, engineering B filters

• Engineering B - Internet filters, finance filters, engineering A filters

• Finance - Internet filters, engineering A filters, engineering B filters

• Internet - engineering A filters, engineering B filters, finance filters

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:

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

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

6.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 comes down to two related questions:

• Have you properly told the router to do what you want?

• Is the router doing what you've told it to?

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.