Olaf Kirch - Linux Network Administrator Guide, Second Edition

# iptables -N a-essent

# iptables -N a-noness

# iptables -A a-essent -j ACCEPT

# iptables -A a-noness -j ACCEPT

# iptables -A FORWARD -i ppp0 -m tcp -p tcp -sport ftp-data:ftp -j a-essent

# iptables -A FORWARD -i ppp0 -m tcp -p tcp -sport smtp -j a-essent

# iptables -A FORWARD -i ppp0 -m tcp -p tcp -sport www -j a-essent

# iptables -A FORWARD -j a-noness

This looks simple enough. Unfortunately, there is a small but unavoidable problem when trying to do accounting by service type. You will remember that we discussed the role the MTU plays in TCP/IP networking in an earlier chapter. The MTU defines the largest datagram that will be transmitted on a network device. When a datagram is received by a router that is larger than the MTU of the interface that needs to retransmit it, the router performs a trick called fragmentation . The router breaks the large datagram into small pieces no longer than the MTU of the interface and then transmits these pieces. The router builds new headers to put in front of each of these pieces, and these are what the remote machine uses to reconstruct the original data. Unfortunately, during the fragmentation process the port is lost for all but the first fragment. This means that the IP accounting can't properly count fragmented datagrams. It can reliably count only the first fragment, or unfragmented datagrams. There is a small trick permitted by ipfwadm that ensures that while we won't be able to know exactly what port the second and later fragments were from, we can still count them. An early version of Linux accounting software assigned the fragments a fake port number, 0xFFFF, that we could count. To ensure that we capture the second and later fragments, we could use a rule like:

# ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 0xFFFF

The IP chains implementation has a slightly more sophisticated solution, but the result is much the same. If using the ipchains command we'd instead use:

# ipchains -A forward -i ppp0 -p tcp -f

and with iptables we'd use:

# iptables -A FORWARD -i ppp0 -m tcp -p tcp -f

These won't tell us what the original port for this data was, but at least we are able to see how much of our data is fragments, and be able to account for the volume of traffic they consume.

In 2.2 kernels you can select a kernel compile-time option that negates this whole issue if your Linux machine is acting as the single access point for a network. If you enable the IP: always defragment option when you compile your kernel, all received datagrams will be reassembled by the Linux router before routing and retransmission. This operation is performed before the firewall and accounting software sees the datagram, and thus you will have no fragments to deal with. In 2.4 kernels you compile and load the netfilter forward-fragment module.

The ICMP protocol does not use service port numbers and is therefore a little bit more difficult to collect details on. ICMP uses a number of different types of datagrams. Many of these are harmless and normal, while others should only be seen under special circumstances. Sometimes people with too much time on their hands attempt to maliciously disrupt the network access of a user by generating large numbers of ICMP messages. This is commonly called ping flooding . While IP accounting cannot do anything to prevent this problem (IP firewalling can help, though!) we can at least put accounting rules in place that will show us if anybody has been trying.

ICMP doesn't use ports as TCP and UDP do. Instead ICMP has ICMP message types. We can build rules to account for each ICMP message type. To do this, we place the ICMP message and type number in place of the port field in the ipfwadm accounting commands. We listed the ICMP message types in "ICMP datagram types", so refer to it if you need to remember what they are.

An IP accounting rule to collect information about the volume of ping data that is being sent to you or that you are generating might look like:

# ipfwadm -A both -a -P icmp -S 0/0 8

# ipfwadm -A both -a -P icmp -S 0/0 0

# ipfwadm -A both -a -P icmp -S 0/0 0xff

or, with ipchains:

# ipchains -A forward -p icmp -s 0/0 8

# ipchains -A forward -p icmp -s 0/0 0

# ipchains -A forward -p icmp -s 0/0 -f

or, with iptables:

# iptables -A FORWARD -m icmp -p icmp -sports echo-request

# iptables -A FORWARD -m icmp -p icmp -sports echo-reply

# iptables -A FORWARD -m icmp -p icmp -f

The first rule collects information about the "ICMP Echo Request" datagrams (ping requests), and the second rule collects information about the "ICMP Echo Reply" datagrams (ping replies). The third rule collects information about ICMP datagram fragments. This is a trick similar to that described for fragmented TCP and UDP datagrams.

If you specify source and/or destination addresses in your rules, you can keep track of where the pings are coming from, such as whether they originate inside or outside your network. Once you've determined where the rogue datagrams are coming from, you can decide whether you want to put firewall rules in place to prevent them or take some other action, such as contacting the owner of the offending network to advise them of the problem, or perhaps even legal action if the problem is a malicious act.

Let's now imagine that we are interested in knowing how much of the traffic on our link is TCP, UDP, and ICMP. We would use rules like the following:

# ipfwadm -A both -a -W ppp0 -P tcp -D 0/0

# ipfwadm -A both -a -W ppp0 -P udp -D 0/0

# ipfwadm -A both -a -W ppp0 -P icmp -D 0/0

or:

# ipchains -A forward -i ppp0 -p tcp -d 0/0

# ipchains -A forward -i ppp0 -p udp -d 0/0

# ipchains -A forward -i ppp0 -p icmp -d 0/0

or:

# iptables -A FORWARD -i ppp0 -m tcp -p tcp

# iptables -A FORWARD -o ppp0 -m tcp -p tcp

# iptables -A FORWARD -i ppp0 -m udp -p udp

# iptables -A FORWARD -o ppp0 -m udp -p udp

# iptables -A FORWARD -i ppp0 -m icmp -p icmp

# iptables -A FORWARD -o ppp0 -m icmp -p icmp

With these rules in place, all of the traffic flowing across the ppp0 interface will be analyzed to determine whether it is TCP, UDP, or IMCP traffic, and the appropriate counters will be updated for each. The iptables example splits incoming flow from outgoing flow as its syntax demands it.

It is all very well to be collecting this information, but how do we actually get to see it? To view the collected accounting data and the configured accounting rules, we use our firewall configuration commands, asking them to list our rules. The packet and byte counters for each of our rules are listed in the output.