8.10. Where to Do Packet Filtering

If you look at the various firewall architectures outlined in Chapter 6, "Firewall Architectures", you see that you might perform packet filtering in a variety of places. Where should you do it? The answer is simple: anywhere you can.

any of the architectures (e.g., the screened host architecture or the single-router screened subnet architecture) involve only one router. In those cases, that one router is the only place where you could do packet filtering, so there's not much of a decision to be made.

However, other architectures, such as the two-router screened subnet architecture, and some of the architectural variations, involve multiple routers. You might do packet filtering on any or all of these routers.

Our recommendation is to do whatever packet filtering you can wherever you can. This is an application of the principle of least privilege (described in Chapter 3, "Security Strategies"). For each router that is part of your firewall, figure out what types of packets should legitimately be flowing through it, and set up filters to allow only those packets and no more. You may also want to put packet filters on destination hosts, using a host-based packet filtering system like the ones discussed previously, or using special-purpose software designed for filtering on destination hosts.This is highly advisable for bastion hosts, and destination host filtering packages are discussed further in the chapters about bastion hosts (Chapter 10, "Bastion Hosts", Chapter 11, "Unix and Linux Bastion Hosts", Chapter 12, "Windows NT and Windows 2000 Bastion Hosts ").

This may lead to duplication of some filters on multiple routers; in other words, you may filter out the same thing in more than one place. That's good; it's redundancy, and it may save you some day if you ever have a problem with one of your routers -- for example, if something was supposed to be done but wasn't (because of improper configuration, bugs, enemy action, or whatever). It provides defense in depth and gives you the opportunity to fail safely -- other strategies we outlined in Chapter 3, "Security Strategies".

If filtering is such a good idea, why not filter on all routers, not just those that are part of the firewall? Basically, because of performance and maintenance issues. Earlier in this chapter, we discussed what "fast enough" means for a packet filtering system on the perimeter of your network. However, what's fast enough at the edge of your network (where the real bottleneck is probably the speed of the line connecting you to the Internet) is probably not fast enough within your network (where you've probably got many busy local area networks of Ethernet, FDDI, or perhaps something even faster). Further, if you put filters on all your routers, you're going to have to maintain all those filter lists. Maintaining filter lists is a manageable problem if you're talking about one or a handful of routers that are part of a firewall, but it gets out of hand in a hurry as the number of routers increases. This problem is worsened if some of the routers are purely internal. Why? Because you probably want to allow more services within your network than you allow between your network and the Internet. This is going to either make your filter sets longer (and thus harder to maintain), or make you switch from a "default deny" stance to a "default permit" stance on those internal filters (which is going to seriously undermine the security they provide anyway). You reach a point of diminishing returns fairly quickly when you try to apply filtering widely within a local area network, rather than just at its perimeter.

You may still have internal packet filtering routers at boundaries within the local area network (between networks with different security policies, or networks that belong to different organizations). As long as they're at clearly defined boundaries, and they're up to the performance requirements, that's not a problem. Whether or not you duplicate the external rules on these internal packet filters is going to depend on how much you trust the external packet filters, and how much complexity and overhead the external rules are going to add.

In some cases, you may also be able to run packet filtering packages on bastion hosts. If this is not a performance problem, it can provide additional security in the event that a packet filtering router is compromised or misconfigured.

Some people argue against putting packet filters on routers when you also have a firewall inside the router, on the grounds that allowing packets to reach the firewall system gives you a single logging point, making it easier to detect attacks. If an attack involves some packets that are filtered out at the router, and others that are rejected at an internal firewall, the internal firewall may not be successful at detecting the attack. This is not a convincing argument; the internal firewall will still be successful at detecting any attack that has any chance of succeeding against it, and any reasonable logging configuration will let you correlate the logs from the packet filters with the logs from the internal firewall and do intrusion detection on the union of them in any case. The increased detection benefit from allowing the packets is more than outweighed by the decrease in security.[21]

[21]We have also heard the argument that "the firewall is more secure than the packet filter, so you should use it instead." This is relevant only if you can't use both at the same time. Clearly, the firewall is not more secure than the combination of the firewall and the packet filter!

---