/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */ (Originally sent to the ipchains list, but it applies to ipfwadm/ip masq users as well. My apologies to all who subscribe to both lists.) Good day, Rajiv, On Wed, 3 Nov 1999, Rajiv Ghai wrote: (The concepts discussed below are equally valid for any packet filtering firewall, including ipfw, ipfwadm, ipchains, and netfilter/iptables on Linux, Cisco IOS access-lists, Border Manager, and any other packet filering firewall; only the syntax will differ). > As another one lurking around this list for a while I wonder if Rusty could > clear up one fundamental question I have and possibly many others too. > Does it matter in what order the ipchains rules are written ? Yes. > ie. ACCEPT Rule following a DENY rule is the same as a DENY Rule followed > by an ACCEPT Rule ?. Same with FORWARD, MASQ and REDIRECT ? For any packet arriving in the system, the input chain *1 is scanned from the top down until a matching accept, reject, deny, masq, or redirect rule is found. Picture a firewall with the following two rules: ipchains -A input -s 1.2.3.4/32 -j ACCEPT ipchains -A input -i eth0 -j ACCEPT Can these rules be swapped without changing the structure of the firewall? Yes, they can; for any given packet, it doesn't matter whether it matches the first or the second rule, it will still be accepted. How about these; can these be swapped? ipchains -A input -s 1.2.3.4/32 -j ACCEPT ipchains -A input -s 4.5.6.7/32 -j DENY Yes, they can, but for a different reason. Any given packet will have a source address of 1.2.3.4 (in which case it will be accepted whether that rule comes first or second), a source address of 4.5.6.7 (in which case it will be denied whether that rule comes first or second), or some other source address (in which case some other part of the firewall will handle it). One more important example: ipchains -A input -s 1.2.3.4/32 -j ACCEPT ipchains -A input -d 4.5.6.7/32 -j DENY These two _cannot_ be swapped without changing the structure of the firewall. A packet arrives on the system with a source address of 1.2.3.4 and a destination address of 4.5.6.7. If the rules are listed as above, it will be accepted because it's source address matches the first rule. If you swap the rules, that same packet will be denied because of its destination address. When you're looking at swapping rules, here's the summary (these are presented in the same order as the examples of them above): - If two rules have the same action, they can be swapped. - If two rules have different actions and no packets could be matched by both, they can be swapped. - If two rules have different actions and there are packets that could be matched by both, they cannot be swapped without changing the way the firewall acts. In particular, swapping those rules changes what the firewall will do to the packets that match both rules from the original action to the other action. One more subtle note about the term "action" as used in this context. For the purpose of this discussion, the following are all considered different actions: - accept the packet - deny the packet - reject the packet - accept it and log - deny it and log - reject it and log - masquerade it - masquerade it and log - redirect it to a local port - redirect it and log - accept it and copy to userspace (ipchains "-o") - deny it and copy to userspace - reject it and copy to userspace - accept it, log it, and copy to userspace - etc. In fact, the accept/reject/deny, -l (log) or not, -o (output to userspace) or not, -m (set mark value), and -t (set tos value) _all_ have to be identical for two rules to have the same "action" in the above discussion. On a more practical level, you'll have to decide whether it's safe to swap: ipchains -A input -s 1.2.3.4/32 -j ACCEPT -m 77 ipchains -A input -d 4.5.6.7/32 -j ACCEPT -m 89 You might decide that for your purposes, these two rules have the same action, or you might decide that the difference in mark value is enough to consider them different actions. I use the above concepts in building a firewall in Mason. Someone suggested that it might make sense to sort the firewall rules so the ones that match the most packets go at the top, and the ones that match the fewest packets go at the bottom. *2 Although it took a little work *3, it's not impossible to get the packet counts out of an "ipchains -L -n -x -v" listing and glue them back onto the rules in the firewall script. Unfortunately, I can't just sort this file numerically unless I can guarantee that either they all have exactly the same action (I know they may not) or can guarantee that absolutely no rules overlap in the packets they can match (also not true). The best I could do while staying confident that I wasn't risking making someone's firewall less secure was to break the firewall up into blocks of rules that all had the same target. Inside those blocks it's safe to sort numerically, then glue the sorted blocks back together. Mason could go further, trying to identify which rules could not possibly overlap, but that's really tough to do well. > If the order does matter than I would think that an ipchains -L command > would never give a true picture of what kind of firewall was in place. Right ? ipchains -L, like ipfwadm -l, lists the rules in a given chain in the order in which they're scanned by the kernel. The fact that the order makes a difference is exactly why ipfwadm allows you to insert a rule at the top of the firewall or append it to the bottom (ipchains extends this to allow you to insert a rule at any location in a chain). For more information on this, refer to the Mason-HOWTO which covers this topic and also covers the concept of handling a rule that's a subset of another rule. It can be read online at http://www.pobox.com/~wstearns/mason/ or in /usr/doc/mason if you install Mason on your system. See section 8.2, "Ordering Rules". Cheers, - Bill *1 The same holds true for packets going through the system that start at the top of the forwarding chain, and packets exiting the system that start at the top of the output chain. *2 One side of me agrees; putting the most commonly used rules at the top would seem to allow the kernel to match heavily used rules more quickly, sending them on their way more quickly. I suspect, however, that the code that matches packets is so fast to begin with that you would have to have thousands of rules before this technique provided _any_ measurable speedup. On the chance that it _might_ help, I included this sort ability. *3 Actually it was a real pain. *smile* --------------------------------------------------------------------------- Every program has at least one bug and can be shortened by at least one instruction--from which, by induction, it is evident that every program can be reduced to one instruction that does not work. (Courtesy of Weather-Man(a/k/a wormied dude, <[EMAIL PROTECTED]>) -------------------------------------------------------------------------- William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, named2hosts, and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns/ _______________________________________________ Masq maillist - [EMAIL PROTECTED] Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES UNSUBSCRIBING! or email to [EMAIL PROTECTED] PLEASE read the HOWTO and search the archives before posting. You can start your search at http://www.indyramp.com/masq/ Please keep general linux/unix/pc/internet questions off the list.
