- t andmask xormask
Enables you to manipulate the "type of service" bits in the IP header of any datagram that matches this rule. The type of service bits are used by intelligent routers to prioritize datagrams before forwarding them. The Linux routing software is capable of this sort prioritization. The andmask and xormask represent bit masks that will be logically ANDed and ORed with the type of service bits of the datagram respectively. This is an advanced feature that is discussed in more detail in the IPCHAINS-HOWTO.
- x
Causes any numbers in the ipchains output to be expanded to their exact values with no rounding.
- y
Causes the rule to match any TCP datagram with the SYN bit set and the ACK and FIN bits clear. This is used to filter TCP connection requests.
Our Naïve Example Revisited
Let's again suppose that we have a network in our organization and that we are using a Linux-based firewall machine to allow our users access to WWW servers on the Internet, but to allow no other traffic to be passed.
If our network has a 24-bit network mask (class C) and has an address of 172.16.1.0, we'd use the following ipchains rules:
# ipchains -F forward
# ipchains -P forward DENY
# ipchains -A forward -s 0/0 80 -d 172.16.1.0/24 -p tcp -y -j DENY
# ipchains -A forward -s 172.16.1.0/24 -d 0/0 80 -p tcp -b -j ACCEPT
The first of the commands flushes all of the rules from the forward rulesets and the second set of commands sets the default policy of the forward ruleset to DENY. Finally, the third and fourth commands do the specific filtering we want. The fourth command allows datagrams to and from web servers on the outside of our network to pass, and the third prevents incoming TCP connections with a source port of 80.
If we now wanted to add rules that allowed passive mode only access to FTP servers in the outside network, we'd add these rules:
# ipchains -A forward -s 0/0 20 -d 172.16.1.0/24 -p tcp -y -j DENY
# ipchains -A forward -s 172.16.1.0/24 -d 0/0 20 -p tcp -b -j ACCEPT
# ipchains -A forward -s 0/0 21 -d 172.16.1.0/24 -p tcp -y -j DENY
# ipchains -A forward -s 172.16.1.0/24 -d 0/0 21 -p tcp -b -j ACCEPT
Listing Our Rules with ipchains
To list our rules with ipchains, we use its -L argument. Just as with ipfwadm, there are arguments that control the amount of detail in the output. In its simplest form, ipchains produces output that looks like:
# ipchains -L -n
Chain input (policy ACCEPT):
Chain forward (policy DENY):
target prot opt source destination ports
DENY tcp -y---- 0.0.0.0/0 172.16.1.0/24 80 -> *
ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 * -> 80
ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 80 -> *
ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 * -> 20
ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 20 -> *
ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 * -> 21
ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 21 -> *
Chain output (policy ACCEPT):
If you don't supply the name of a chain to list, ipchains will list all rules in all chains. The -n argument in our example tells ipchains not to attempt to convert any address or ports into names. The information presented should be self-explanatory.
A verbose form, invoked by the -u option, provides much more detail. Its output adds fields for the datagram and byte counters, Type of Service AND and XOR flags, the interface name, the mark, and the outsize.
All rules created with ipchains have datagram and byte counters associated with them. This is how IP Accounting is implemented and will be discussed in detail in Chapter 10. By default these counters are presented in a rounded form using the suffixes K and M to represent units of one thousand and one million, respectively. If the -x argument is supplied, the counters are expanded to their full unrounded form.
Making Good Use of Chains
You now know that the ipchains command is a replacement for the ipfwadm with a simpler command-line syntax and some interesting enhancements, but you're no doubt wanting to know where you'd use the user-defined chains and why. You'll also probably want to know how to use the support scripts that accompany the ipchains command in its software package. We'll now explore these subjects and address the questions.
User-defined chains
The three rulesets of the traditional IP firewall code provided a mechanism for building firewall configurations that were fairly simple to understand and manage for small networks with simple firewalling requirements. When the configuration requirements are not simple, a number of problems become apparent. Firstly, large networks often require much more than the small number of firewalling rules we've seen so far; inevitably needs arise that require firewalling rules added to cover special case scenarios. As the number of rules grows, the performance of the firewall deterioriates as more and more tests are conducted on each datagram and managability becomes an issue. Secondly, it is not possible to enable and disable sets of rules atomically; instead, you are forced to expose yourself to attack while you are in the middle of rebuilding your ruleset.
The design of IP Firewall Chains helps to alleviate these problems by allowing the network administrator to create arbitrary sets of firwewall rules that we can link to the three inbuilt rulesets. We can use the -N option of ipchains to create a new chain with any name we please of eight characters or less. (Restricting the name to lowercase letters only is probably a good idea.) The -j option configures the action to take when a datagram matches the rule specification. The -j option specifies that if a datagram matches a rule, further testing should be performed against a user-defined chain. We'll illustrate this with a diagram.
Consider the following ipchains commands:
ipchains -P input DENY ipchains -N tcpin
ipchains -A tcpin -s! 172.16.0.0/16
ipchains -A tcpin -p tcp -d 172.16.0.0/16 ssh -j ACCEPT
ipchains -A tcpin -p tcp -d 172.16.0.0/16 www -j ACCEPT
ipchains -A input -p tcp -j tcpin ipchains -A input -p all
We set the default input chain policy to deny. The second command creates a user-defined chain called "tcpin." The third command adds a rule to the tcpin chain that matches any datagram that was sourced from outside our local network; the rule takes no action. This rule is an accounting rule and will be discussed in more detail in Chapter 10. The next two rules match any datagram that is destined for our local network and either of the ssh or www ports; datagrams matching these rules are accepted. The next rule is when the real ipchains magic begins. It causes the firewall software to check any datagram of protocol TCP against the tcpin user-defined chain. Lastly, we add a rule to our input chain that matches any datagram; this is another accounting rule. They will produce the following Firewall Chains shown in Figure 9-4.