Olaf Kirch - Linux Network Administrator Guide, Second Edition

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.

Figure 9.4: A simple IP chain ruleset

Our input and tcpin chains are populated with our rules. Datagram processing always beings at one of the inbuilt chains. We'll see how our user-defined chain is called into play by following the processing path of different types of datagrams.

First, let's look at what happens when a UDP datagram for one of our hosts is received. Figure 9.5 illustrates the flow through the rules.

Figure 9.5: The sequence of rules tested for a received UDP datagram

The datagram is received by the input chain and falls through the first two rules because they match ICMP and TCP protocols, respectively. It matches the third rule in the input chain, but it doesn't specify a target, so its datagram and byte counters are updated, but no other action takes place. The datagram reaches the end of the input chain, meets with the default input chain policy, and is denied.

To see our user-defined chain in operation, let's now consider what happens when we receive a TCP datagram destined for the ssh port of one of our hosts. The sequence is shown in Figure 9.6.

Figure 9.6: The rules flow for a received TCP datagram for ssh

This time the second rule in the input chain does match and it specifies a target of tcpin, our user-defined chain. Specifying a user-defined chain as a target causes the datagram to be tested against the rules in that chain, so the next rule tested is the first rule in the tcpin chain. The first rule matches any datagram that has a source address outside our local network and specifies no target, so it too is an accounting rule and testing falls through to the next rule. The second rule in our tcpin chain does match and specifies a target of ACCEPT. We have arrived at target, so no further firewall processing occurs. The datagram is accepted.

Finally, let's look at what happens when we reach the end of a user-defined chain. To see this, we'll map the flow for a TCP datagram destined for a port other than than the two we are handling specifically, as shown in Figure 9.7.

Figure 9.7: The rules flow for a received TCP datagram for telnet

The user-defined chains do not have default policies. When all rules in a user-defined chain have been tested, and none have matched, the firewall code acts as though a RETURN rule were present, so if this isn't what you want, you should ensure you supply a rule at the end of the user-defined chain that takes whatever action you wish. In our example, our testing returns to the rule in the input ruleset immediately following the one that moved us to our user-defined chain. Eventually we reach the end of the input chain, which does have a default policy and our datagram is denied.

This example is very simple, but illustrates our point. A more practical use of IP chains would be much more complex. A slightly more sophisticated example is provided in the following list of commands:

#

# Set default forwarding policy to REJECT

ipchains -P forward REJECT

#

# create our user-defined chains

ipchains -N sshin

ipchains -N sshout

ipchains -N wwwin

ipchains -N wwwout

#

# Ensure we reject connections coming the wrong way

ipchains -A wwwin -p tcp -s 172.16.0.0/16 -y -j REJECT

ipchains -A wwwout -p tcp -d 172.16.0.0/16 -y -j REJECT

ipchains -A sshin -p tcp -s 172.16.0.0/16 -y -j REJECT

ipchains -A sshout -p tcp -d 172.16.0.0/16 -y -j REJECT

#

# Ensure that anything reaching the end of a user-defined chain is rejected.

ipchains -A sshin -j REJECT

ipchains -A sshout -j REJECT

ipchains -A wwwin -j REJECT

ipchains -A wwwout -j REJECT

#

# divert www and ssh services to the relevant user-defined chain

ipchains -A forward -p tcp -d 172.16.0.0/16 ssh -b -j sshin

ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 ssh -b -j sshout

ipchains -A forward -p tcp -d 172.16.0.0/16 www -b -j wwwin

ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 www -b -j wwwout

#

# Insert our rules to match hosts at position two in our user-defined chains.

ipchains -I wwwin 2 -d 172.16.1.2 -b -j ACCEPT

ipchains -I wwwout 2 -s 172.16.1.0/24 -b -j ACCEPT

ipchains -I sshin 2 -d 172.16.1.4 -b -j ACCEPT

ipchains -I sshout 2 -s 172.16.1.4 -b -j ACCEPT

ipchains -I sshout 2 -s 172.16.1.6 -b -j ACCEPT

#

In this example, we've used a selection of user-defined chains both to simplify management of our firewall configuration and improve the efficiency of our firewall as compared to a solution involving only the built-in chains.

Our example creates user-defined chains for each of the ssh and www services in each connection direction. The chain called wwwout is where we place rules for hosts that are allowed to make outgoing World Wide Web connections, and sshin is where we define rules for hosts to which we want to allow incoming ssh connections. We've assumed that we have a requirement to allow and deny individual hosts on our network the ability to make or receive ssh and www connections. The simplication occurs because the user-defined chains allow us to neatly group the rules for the host incoming and outgoing permissions rather than muddling them all together. The improvement in efficiency occurs because for any particular datagram, we have reduced the average number of tests required before a target is found. The efficiency gain increases as we add more hosts. If we hadn't used user-defined chains, we'd potentially have to search the whole list of rules to determine what action to take with each and every datagram received. Even if we assume that each of the rules in our list matches an equal proportion of the total number of datagrams processed, we'd still be searching half the list on average. User-defined chains allow us to avoid testing large numbers of rules if the datagram being tested doesn't match the simple rule in the built-in chain that jumps to them.