Linux Network Administratoramp;#039;s Guide (3rd Edition) [Electronic resources] نسخه متنی

8.2. Configuring IP Accounting

Because IP accounting is closely
related to IP firewall, the same tool was designated to configure it,
so the iptables command is used to
configure IP accounting. The command syntax is very similar to that
of the firewall rules, so we won't focus on it, but
we will discuss what you can discover about the nature of your
network traffic using this feature.

The general command syntax is:

# iptables -A  chain rule-specification 

The iptables command allows you to
specify direction in a manner consistent with the firewall rules.

The commands are much the same as firewall
rules, except that the policy rules do not apply here. We can add,
insert, delete, and list accounting rules. In the case of
ipchains and iptables, all valid rules are accounting
rules, and any command that doesn't specify the
-j option performs accounting only.

The rule specification parameters for IP
accounting are the same as those used for IP firewalls. These are
what we use to define precisely what network traffic we wish to count
and total.

8.2.1. Accounting by Address

Let's work with an example
to illustrate how we'd use IP accounting.

Imagine we have a Linux-based router that serves two departments at
the Virtual Brewery. The router has two Ethernet devices,
eth0 and etH1, each of which
services a department; and a PPP device, ppp0,
that connects us via a high-speed serial link to the main campus of
the Groucho Marx University.

Let's also imagine that for billing purposes that we
want to know the total traffic generated by each of the departments
across the serial link, and for management purposes we want to know
the total traffic generated between the two departments.

Table 8-1 shows the interface addresses we will
use in our example:

To answer the question, "How much data does each
department generate on the PPP link?", we could use
a rule that looks like this:

# iptables -A FORWARD -i ppp0 -d 172.16.3.0/24
# iptables -A FORWARD -o ppp0 -s 172.16.3.0/24
# iptables -A FORWARD -i ppp0 -d 172.16.4.0/24
# iptables -A FORWARD -o ppp0 -s 172.16.4.0/24

The first two rules say, "Count all data traveling
in either direction across the interface named
ppp0 with a source or destination address of
172.16.3.0/24."
The second set of two rules do the same thing, but for the second
Ethernet network at our site.

To answer the second question, "How much data
travels between the two departments?", we need a
rule that looks like this:

# iptables -A FORWARD -s 172.16.3.0/24 -d 172.16.4.0/24
# iptables -A FORWARD -s 172.16.4.0/24 -d 172.16.3.0/24

These rules will count all packets with a
source address belonging to one of the department networks and a
destination address belonging to the other.

8.2.2. Accounting by Service Port

Okay,
let's suppose we also want a better idea of exactly
what sort of traffic is being carried across our PPP link. We might,
for example, want to know how much of the link the FTP, SMTP, and
World Wide Web (HTTP) services are consuming.

A script of rules to enable us to collect this information might look
like this:

#!/bin/sh
# Collect ftp, smtp and www volume statistics for data carried on our
# PPP link using iptables.
#
iptables -A FORWARD -i ppp0 -p tcp --sport 20:21
iptables -A FORWARD -o ppp0 -p tcp --dport 20:21
iptables -A FORWARD -i ppp0 -p tcp --sport smtp
iptables -A FORWARD -o ppp0 -p tcp --dport smtp
iptables -A FORWARD -i ppp0 -p tcp --sport www
iptables -A FORWARD -o ppp0 -p tcp --dport www

There are a couple of interesting
features to this configuration. First, we've
specified the protocol. When we specify ports in our rules, we must
also specify a protocol because TCP and UDP provide separate sets of
ports. Since all of these services are TCP based,
we've specified it as the protocol. Second,
we've specified the two services
ftp and ftp-data in one
command. The iptables command allows
either single ports or ranges of ports, which is what
we've used here. The syntax
"20:21" means
"ports 20 (ftp-data) through 21
(ftp)," and is how we encode
ranges of ports in iptables (the
tcp match extension allow you to use port names in
range specifications, but the multiport match
extension does notand you are better off using numbers for
ranges anyway so you don't accidentally include more
ports than you intend). When you have a list of ports in an
accounting rule, it means that any data received for any of the ports
in the list will cause the data to be added to that
entry's totals. Remembering that the FTP service
uses two ports, the command port and the data transfer port;
we've added them together to total the FTP traffic.

We can expand on the second point a little to give us a different
view of the data on our link. Let's now imagine that
we class FTP, SMTP, and World Wide Web (HTTP) traffic as essential
traffic, and all other traffic as nonessential. If we were interested
in seeing the ratio of essential traffic to nonessential traffic, we
could do something like this:

# iptables -A FORWARD -i ppp0 -p tcp -m multiport \
    --sports ftp-data,ftp,smtp,www -j ACCEPT
# iptables -A FORWARD -j ACCEPT

The first rule would count our essential traffic while the second one
would count everything else.

Alternatively, we can use user-defined chains (this would be useful
if the rules for determining essential traffic were more complex):

# 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 -p tcp -m multiport \
    --sports ftp-data,ftp,smtp,www -j a-essent
# iptables -A FORWARD -j a-noness

Here we create two user-defined
chainsone called a-essent, where we capture
accounting data for essential services, and another called
a-noness, where we capture accounting data for
nonessential services. We then add rules to our forward chain that
match our essential services and jump to the
a-essent chain, where we have just one rule that
accepts all packets and counts them. The last rule in our forward
chain is a rule that jumps to our a-noness chain,
where again we have just one rule that accepts all packets and counts
them. The rule that jumps to the a-noness chain
will not be reached by any of our essential services, as they will
have been accepted in their own chain. Our tallies for essential and
nonessential services will therefore be available in the rules within
those chains. This is just one approach you could take; there are
others.

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 packet
that will be transmitted on a network device. When a packet 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
packet 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 host
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 packets. It can reliably count only the
first fragment or unfragmented packets. To ensure that we capture the
second and later fragments, we could use a rule like this:

# 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 account for the volume of traffic they
consume.

Connection tracking does automatic defragmenting, so this technique won't often be useful. But if you aren't doing connection tracking, you can use it.

8.2.3. Accounting of ICMP Packets

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 packets. 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 (the generic
term for this type of denial of service attack is packet
flooding, but ping flooding is a common one). 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. We place the ICMP
message and type number in place of the port field in the accounting
commands.

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 this:

# 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" packets (ping requests), and the second
rule collects information about the "ICMP Echo
Reply" packets (ping replies). The third rule
collects information about ICMP packet fragments. This is a trick
similar to that described for fragmented TCP and UDP packets.

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 packets 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 taking legal action if the problem is a malicious act.

8.2.4. Accounting by Protocol

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:

# 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 ICMP traffic, and
the appropriate counters will be updated for each.