Part II: Building Firewalls
Chapter 7. Firewall Design
8.8 Choosing a Packet Filtering Router
8.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. (One innovative vendor even touts this as a user interface benefit, because you no longer have to worry about what order to specify the rules in!) 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 any quirks or bugs are 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).18
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 addresses 172.16.6.0 through 172.16.6.255). You want all subnets at the university to be able to access this project subnet. The university's eight-bit 10.1.99 subnet 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? You could try the following three packet filtering rules. (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 Source Address Dest. Address Action
A 10.0.0.0/8 172.16.6.0/24 Permit
B 10.1.99.0/24 172.16.0.0/16 Deny
C Any Any Deny
•
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.
8.8.5.1 If the rules are applied in the order ABC
If the rules are applied in the order ABC - the same order specified by the user - the following table shows what happens with a variety of sample packets.
Packet Source Address Dest. Address Desired Action Actual Action (by Rule)
1 10.1.99.1 172.16.1.1 Deny Deny (B)
2 10.1.99.1 172.16.6.1 Permit Permit (A)
3 10.1.1.1 172.16.6.1 Permit Permit (A)
4 10.1.1.1 172.16.1.1 Deny Deny (C)
5 192.168.3.4 172.16.1.1 Deny Deny (C)
6 192.168.3.4 172.16.6.1 Deny Deny (C)
•
Packet 1 is from a machine at the university on the hostile subnet to a random machine on your network (not on the project subnet); you want it to be denied; it is, by rule B.•
Packet 2 is from a machine at the university on the hostile subnet to a machine on your project subnet; you want it to be permitted; it is, by rule A.•
Packet 3 is from a random machine at the university to a machine on your project subnet; you want it to be permitted; it is, by rule A.•
Packet 4 is from a random machine at the university to one of your nonproject machines; you want it to be denied; it is, by rule C.•
Packet 5 is from a random machine on the Internet to one of your nonproject machines; you want it to be denied; it is, by rule C.•
Packet 6 is from a random machine on the Internet to one of your project machines; you want it to be denied; it is, by rule C.8.8.5.2 If the rules are applied in the order BAC
What would happen if the router reordered the rules by the number of significant bits in the source address, so that more specific rules are applied first? In other words, rules applying to more specific IP source addresses (i.e., rules that apply to a smaller range of source addresses) would be applied before rules applying to less specific IP source addresses. In this case, the rules would be applied in the order BAC.
Rule Source Address Dest. Address Action
B 10.1.99.0/24 172.16.0.0/16 Deny
A 10.0.0.0/8 172.16.6.0/24 Permit
C Any Any Deny
Here are the same six sample packets, with the new outcomes if the rules are applied in the order BAC; in bold face, we show how the actions differ from the previous case (in which rules are applied in the order specified by the user).
Packet Source Address Dest. Address Desired Action Actual Action (by Rule)
1 10.1.99.1 172.16.1.1 Deny Deny (B)
2 10.1.99.1 172.16.6.1 Permit Deny (B)
3 10.1.1.1 172.16.6.1 Permit Permit (A)
4 10.1.1.1 172.16.1.1 Deny Deny (C)
5 192.168.3.4 172.16.1.1 Deny Deny (C)
6 192.168.3.4 172.16.6.1 Deny Deny (C)
If the rules are applied in the order BAC, then packet 2, which should be permitted, is improperly denied by rule B. Now, denying something that should be permitted is safer than permitting something that should be denied, but it would be better if the filtering system simply did what you wanted it to do.
You can construct a similar example for systems that reorder rules based on the number of significant bits in the destination address, which is the most popular other reordering criteria.
8.8.5.3 Rule B is actually not necessary
If you consider this example carefully, you can see that the discussion about the hostile subnet, which is the reason for rule B, is redundant and isn't necessary to achieve the desired results. Rule B is intended to limit the hostile subnet to accessing only your project subnet. Rule A, however, already restricts the entire university - including the hostile subnet - to accessing only your project subnet. If you omit rule B, then the rules will be applied in order AC regardless of whether or not the system reorders based on the number of significant bits in the IP source address. The following tables show what happens in either case.
Rule Source Address Dest. Address Action
A 10.0.0.0/8 172.16.6.0/24 Permit
C Any Any Deny
Packet Source Address Dest. Address Desired Action Actual Action (by Rule)
1 10.1.99.1 172.16.1.1 Deny Deny (C)
2 10.1.99.1 172.16.6.1 Permit Permit (A)
3 10.1.1.1 172.16.6.1 Permit Permit (A)
4 10.1.1.1 172.16.1.1 Deny Deny (C)
5 192.168.3.4 172.16.1.1 Deny Deny (C)
8.8.5.4 Packet filtering rules are tricky
The point here is that getting filtering rules right is tricky. In this example, we are considering a relatively simple situation, and we've still managed to come up with a rule set that had a subtle error in it. Real-life rule sets are significantly more complex than these, and often include tens or hundreds of rules. Considering the implications and interactions of all those rules is nearly impossible, unless they are simply applied in the order specified. So- called "help" from a router, in the form of reordering rule sets, can easily turn an over-specified but working rule set into a nonworking rule set. You should make sure that the packet filtering router you select doesn't reorder rule sets.
It's OK if the router does optimization, as long as the optimization doesn't change the effect of the rules. Pay close attention to what kind of optimizations your packet filtering implementation tries to do. If a vendor will not or cannot tell you what order rules are applied in, do not buy that vendor's product.