6.9 Where to Do Packet Filtering

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

Many 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 ). 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 screend , ipfilterd , or TCP Wrapper. This is highly advisable for 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 .

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. We discuss above 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 LAN s 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 either going to 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 often reach a point of diminishing returns fairly quickly when you try to apply filtering widely within a LAN , rather than just at its perimeter.

You may still have internal packet filtering routers at boundaries within the LAN (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.