Packet Filtering Tips and Tricks

Packet filtering systems are complicated, and administering them has some subtlety. Here are some ways to deal with them more effectively and make them more secure.

Edit Your Filtering Rules Offline

The filter-editing tools on most systems are usually pretty minimal. Also, it's not always clear how new rules will interact with existing rule sets. In particular, it's often difficult to delete rules, or to add new rules in the middle of an existing rule set.

You might find it more convenient to keep your filters in a text file on one of your Unix or PC systems, so that you can edit them there with the tools you're familiar with, and then load the file on the filtering system as if it contained commands you were typing at the console. Different systems support various ways of doing this. For example, on Cisco products, you can use TFTP to obtain command files from a server. (Be careful of where you enable a TFTP server, though. See the discussion of TFTP in "File Transfer, File Sharing, and Printing", and think about using something like TCP Wrapper to control what hosts can activate that TFTP server.)

An added advantage of keeping the filters elsewhere as a file is that you can keep comments in the file (stripping them out of the copy sent to the router, if necessary). Most filtering systems discard any comments in the commands they're given; if you later go look at the active filters on the system, you'll find that the comments aren't retained.

Reload Rule Sets from Scratch Each Time

The first thing the file should do is clear all the old rules, so that each time you load the file you're rebuilding the rule set from scratch; that way, you don't have to worry about how the new rules will interact with the old. Next, specify the rules you want to establish, followed by whatever commands are necessary to apply those rules to the appropriate interfaces.

When you clear the old filtering rules, many filtering systems will default to allowing all packets through. If you have any problems loading the new filtering rules, your filtering system could be allowing everything through while you sort out the problems with the new rules. Therefore, it's a good idea to temporarily disable or shut down the external interface while you update filtering rules, then re-enable it when you're done updating the rules. Make sure that you aren't connecting to the filtering system and doing the update through the external interface, or you'll cut yourself off in mid-session when you shut down the external interface.

Replace Packet Filters Atomically

Sometimes you want to update filtering rules without temporarily shutting off all access (as was discussed previously). This is possible, as long as: If your system meets both of these conditions, you can update rules with the following system:
  1. Load the new rules with an unused identifier.
  2. Assign the new rules to the interface.
  3. Verify that the new rules are in place and working correctly.
  4. Delete the old rules.
  5. In order to keep your configuration consistent, load the new rules again with the original identifier and assign them to the interface again. (This doesn't change the rule set, but it returns you to your normal identifier.)
  6. Update any offline copies of the configuration with the new rules.
It is possible to automate and script this process if copious and very pessimistic error checking is performed.

Always Use IP Addresses, Never Hostnames

Always specify hosts and networks in filtering rules by IP address, never by hostname or by network name (if your filtering product even supports that). If you specify filtering rules by hostname, your filtering could be subverted if someone accidentally or intentionally corrupts the name-to-address translation (e.g., by feeding false data to your DNS server).

Password Protect Your Packet Filters

Packet filtering systems have to be configured, and many provide ways to do this interactively over the network, perhaps using Telnet or SNMP. If the packet filtering system is based upon a general-purpose computer, then you should take the same remote access precautions as you would when configuring a bastion host. For specialized packet filtering systems, you should take very similar precautions. In particular, if the system stores a master password, even if it is hashed, in a configuration file and attackers can obtain that information, they can use password-cracking tools to guess or break the password. Some packet filtering systems have different password modes; be sure to consult vendor documentation and use a mode that cannot be trivially broken.

If Possible, Use Named Access Lists

Some packet filtering systems allow names to be assigned to sets of rules. In addition, these names may get included in log messages. Using meaningful names can be very useful for both debugging and parsing error log files.