Conventions for Packet Filtering Rules (Building Internet Firewalls, 2nd Edition)

8.5. Conventions for Packet Filtering Rules

The rest of this chapter and the chapters in Part III, "Internet Services" show the kinds of rules you can specify for your packet filtering router in order to control what packets can and cannot flow to and from your network. There are a few things you need to know about these rules.

To avoid confusion, the example rules are specified with abstract descriptions, rather than with real addresses, as much as possible. Instead of using real source and destination addresses (e.g., 172.16.51.50), we use "internal" or "external" to identify which networks we're talking about. Actual packet filtering systems usually require you to specify address ranges explicitly; the syntax varies from router to router.

In all of our packet filtering examples, the assumption is that, for each packet, the router goes through the rules in order until it finds one that matches, and then it takes the action specified by that rule. We assume an implicit default "deny" if no rules apply, although it's a good idea to specify an explicit default (and we generally do).

The syntax used in our filtering examples specifies the number of bits significant for comparison to other addresses after a slash character (/ ). Thus, 10.0.0.0/8 matches any address that starts with 10; it's equivalent to 10.0.0.0 with a Unix netmask of 255.0.0.0, or 10.0.0.0 with a Cisco wildcard mask of 0.255.255.255, or (if it is a filename) 10.*.*.*. Please note that it is also equivalent to 10.255.255.255/8 or 10.1.27.32/8. The last three octets are simply ignored. Although the examples in this book systematically use "0" for ignored numbers or omit them entirely, that will not be true of all configurations you see in real life, and this is a common source of errors.

Although we try to be as specific as possible in these examples, it's impossible to tell you precisely what you have to specify for your particular packet filtering product. The exact mechanism for specifying packet filtering rules varies widely from product to product. Some products allow you to specify a single set of rules that are applied to all packets routed by the system. Others allow you to specify rules for particular interfaces. Still others allow you to specify sets of rules and then apply sets by name to particular interfaces (so that you might define one set of rules that is shared by a number of different interfaces, for example, and put the rules that are unique to a given interface into a different set).

Here's a simple example to illustrate the differences. We chose these systems because they represent somewhat different ways of specifying filters, not because of any particular preference for them; in general, other systems are similar to these.

Let's say that you want to allow all IP traffic between a trusted external host (host 172.16.51.50) and hosts on your internal network (Class C net 192.168.10.0). In our examples, we would show this case as follows.

Rule

Direction

Source Address

Dest. Address

ACK Set

Action

Inbound

Trusted external host

Internal

Any

Permit

Outbound

Internal

Trusted external host

Any

Permit

Either

Any

Deny

On a Cisco router, you specify rules as sets, and apply the relevant sets to the right direction on the right interface. If your external interface is named "serial1", your rules would look like this:

access-list 101 permit ip 172.16.51.50 0.0.0.0 192.168.10.0 0.0.0.255 
access-list 101 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 
interface serial 1 
access-group 101 in 
 
access-list 102 permit ip 192.168.10.0 0.0.0.255 172.16.51.50 0.0.0.0 
access-list 102 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 
interface serial 1 
access-group 102 out

The Linux ipchains rules (assuming that eth0 is the internal interface and eth1 is the external interface) would look like this:

ipchains -P input DENY
ipchains -P output DENY
ipchains -P forward DENY
ipchains -A input -i eth0 -s 192.168.10.0/24 -d 172.16.51.50 -j ACCEPT
ipchains -A input -i eth1 -s 172.16.51.50 -d 192.168.10.0/24 -j ACCEPT
ipchains -A input -l -j DENY
ipchains -A output -i eth1 -s 192.168.10.0/24 -d 172.16.51.50 -j ACCEPT
ipchains -A output -i eth0 -s 172.16.51.50 -d 192.168.10.0/24 -j ACCEPT
ipchains -A output -l -j DENY
ipchains -A forward -b -s 172.16.51.50 -d 192.168.10.0/24 -j ACCEPT
ipchains -A forward -l -j DENY

The rules for ipfilter, which would be placed in ipf 's configuration file (assuming that le0 is the internal interface and le1 is the external interface) look like this:

pass in quick on le0 from 192.168.10.0/24 to 172.16.51.50
pass in quick on le1 from 172.16.51.50 to 192.168.10.0/24
pass out quick on le1 from 192.168.10.0/24 to 172.16.51.50
pass out quick on le0 from 172.16.51.50 to 192.168.10.0/24
block in all
block out all

Using Windows NT's Routing and Remote Access Service filtering, you would add two rules:

Source address 192.168.10.0 and mask 255.255.255.0, destination address 172.16.51.50 and mask 255.255.255.255, protocol any
Source address 172.16.51.50 and mask 255.255.255.255, destination address 192.168.10.0 and mask 255.255.255.0, protocol any

and then select "Drop all except listed below".

For detailed information on the syntax of a particular package or product, consult the documentation for that package or product. Once you understand the syntax for the particular system you are using, you shouldn't have too much difficulty translating from our tables to that system's syntax.

TIP: Watch out for implicit defaults. Different filtering systems have different default actions they take if a packet doesn't match any of the filtering rules specified. Some systems deny all such packets. Other systems make the default the opposite of the last rule; that is, if the last rule was a "permit", the system default is to "deny", and if the last rule was a "deny", the default is to "permit". In any case, it's a good idea to put an explicit default rule at the end of your list of packet filtering rules, so you don't have to worry about (or even remember) which implicit default your system is going to use.