<chapter id="X-087-2-accounting"><title>IP Accounting</title>
<para>
<indexterm id="chac.tcp.ip.accounting" class="startofrange"><primary>TCP/IP (Transmission Control Protocol/Internet Protocol)</primary><secondary>accounting</secondary></indexterm>
In today&rsquo;s world of commercial Internet service, it is becoming 
increasingly important to know
how much data you are transmitting and receiving on your network connections.
If you are an Internet Service Provider and you charge your customers by
volume, this will be essential to your business. If you are a customer
of an Internet Service Provider that charges by data volume, you will
find it useful to collect your own data to ensure the accuracy of your
Internet charges.
</para>

<para>
There are other uses for network accounting that have nothing to do with
dollars and bills. If you manage a server that offers a number of different
types of network services, it might be useful to you to know exactly
how much data is being generated by each one. This sort of information
could assist you in making decisions, such as what hardware to buy or how
many servers to run.
</para>

<para>
The Linux kernel provides a facility that allows you to collect all sorts
of useful information about the network traffic it sees. This facility
is called <emphasis>IP accounting</emphasis>.
</para>

<sect1 id="X-087-2-accounting.kernel.config"><title>Configuring the Kernel <?lb>for IP Accounting</title>
<para>
<indexterm><primary>IP accounting</primary><secondary>kernel configuration</secondary></indexterm>
<INDEXTERM><PRIMARY>configuring</PRIMARY><SECONDARY>kernel</SECONDARY><TERTIARY SORTAS="IP accounting">for IP accounting</TERTIARY></INDEXTERM>
The Linux IP accounting feature is very closely related to the Linux
firewall software. The places you want to collect
accounting data are the same places that you would be interested in
performing firewall filtering: into and out of a network host, and in the
software that does the routing of datagrams. If you haven't read the section
on firewalls, now is probably a good time to do so, as we will be using some of
the concepts described in <xref linkend="X-087-2-firewall">.
</para>

<para>
<INDEXTERM><PRIMARY>2.0 kernels</PRIMARY><SECONDARY>IP accounting</SECONDARY></INDEXTERM>
<INDEXTERM><PRIMARY>2.2 kernels</PRIMARY><SECONDARY>IP accounting</SECONDARY></INDEXTERM>
To activate the Linux IP accounting feature, you should first see if your 
Linux kernel is configured for it. Check to see if the <filename>/proc/net/ip_acct</filename> file exists. If it does, your kernel already supports IP accounting. If it doesn't, you must build a new kernel, ensuring that you answer &ldquo;Y&rdquo; to the options in 2.0 and 2.2 series kernels:

<screen>
Networking options  --->
	[*] Network firewalls
	[*] TCP/IP networking
	 ...
	[*] IP: accounting
</screen>

<INDEXTERM><PRIMARY>2.4 kernels</PRIMARY><SECONDARY>IP accounting</SECONDARY></INDEXTERM>
or in 2.4 series kernels:

<screen>
Networking options  --->
    [*] Network packet filtering (replaces ipchains)
</screen>

</para>

</sect1>

<sect1 id="X-087-2-accounting.ipfwadm"><title>Configuring IP Accounting</title>
<para>
<INDEXTERM id="IPaccounting.config" class=startofrange><PRIMARY>IP accounting</PRIMARY><SECONDARY>configuring</SECONDARY></INDEXTERM>
<INDEXTERM id="config.IPaccounting" class=startofrange><PRIMARY>configuring</PRIMARY><SECONDARY>IP accounting</SECONDARY></INDEXTERM>
<INDEXTERM id="ipfwadm.config.IPaccount" class=startofrange><PRIMARY>ipfwadm command</PRIMARY><SECONDARY>configuring IP accounting</SECONDARY></INDEXTERM>
<INDEXTERM id="ipchains.config.IPaccount" class=startofrange><PRIMARY>ipchains command</PRIMARY><SECONDARY>configuring IP accounting</SECONDARY></INDEXTERM>
<INDEXTERM id="iptables.config.IPaccount" class=startofrange><PRIMARY>iptables command</PRIMARY><SECONDARY>configuring IP accounting</SECONDARY></INDEXTERM>
Because IP accounting is closely related to IP firewall, the same tool 
was designated to configure it, so <command>ipfwadm</command>,
<command>ipchains</command> or <command>iptables</command> are 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.
</para>

<para>
The general syntax for IP accounting with <command>ipfwadm</command> is:

<screen>
# <userinput>ipfwadm -A [<replaceable>direction</replaceable>] [<replaceable>command</replaceable>] [<replaceable>parameters</replaceable>]</userinput>
</screen>
</para>

<para>
The direction argument is new. This is simply coded as
<literal>in</literal>,
<literal>out</literal>, or
<literal>both</literal>.
These directions are from the perspective of the linux machine itself, so
<literal>in</literal> means data coming into the machine from a network 
connection and <literal>out</literal> means data that is being transmitted by 
this host on a network connection. The <literal>both</literal> direction is the 
sum of both the incoming and outgoing directions.
</para>

<para>
The general command syntax for <command>ipchains</command> 
and <command>iptables</command> is:

<screen>
# <userinput>ipchains -A <replaceable>chain</replaceable> <replaceable>rule-specification</replaceable></userinput>
# <userinput>iptables -A <replaceable>chain</replaceable> <replaceable>rule-specification</replaceable></userinput>
</screen></para>

<para>
The <command>ipchains</command> and <command>iptables</command>
commands allow you to specify direction in a manner more consistent
with the firewall rules.  IP Firewall Chains doesn't allow you to
configure a rule that aggregates both directions, but it does allow you
to configure rules in the <literal>forward</literal> chain that the
older implementation did not. We'll see the difference that makes in
some examples a little later.
</para>

<para>
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 <command>ipchains</command> and
<command>iptables</command>, all valid rules are accounting rules, and
any command that doesn't specify the <emphasis>-j</emphasis> option
performs accounting only.
</para>

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

<sect2 id="X-087-2-accounting.by.address"><title>Accounting by Address</title>
<para>
<indexterm><primary>IP accounting</primary><secondary SORTAS="address">by address</secondary></indexterm>
Let's work with an example to illustrate how we'd use IP accounting.
</para>

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

<para>
Let's also imagine that for billing purposes 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.
</para>

<para>
The following table shows the interface addresses we will use in our
example:
</para>

<para>
<informaltable>
<tgroup cols=3>
<thead>
<row>
	<entry>iface</entry>
	<entry>address</entry>
	<entry>netmask</entry>
</row>
</thead>
<tbody>
<row>
	<entry>eth0</entry>
	<entry>172.16.3.0</entry>
	<entry>255.255.255.0</entry>
</row>
<row>
	<entry>eth1</entry>
	<entry>172.16.4.0</entry>
	<entry>255.255.255.0</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>

<para>
To answer the question, &ldquo;How much data does each department
generate on the PPP link?&rdquo;, we could use a rule that looks like
this:

<screen>
# <userinput>ipfwadm -A both -a -W ppp0 -S 172.16.3.0/24 -b</userinput>
# <userinput>ipfwadm -A both -a -W ppp0 -S 172.16.4.0/24 -b</userinput>
</screen>

or:

<screen>
# <userinput>ipchains -A input -i ppp0 -d 172.16.3.0/24</userinput>
# <userinput>ipchains -A output -i ppp0 -s 172.16.3.0/24</userinput>
# <userinput>ipchains -A input -i ppp0 -d 172.16.4.0/24</userinput>
# <userinput>ipchains -A output -i ppp0 -s 172.16.4.0/24</userinput>
</screen>

and with <command>iptables</command>:

<screen>
# <userinput>iptables -A FORWARD -i ppp0 -d 172.16.3.0/24</userinput>
# <userinput>iptables -A FORWARD -o ppp0 -s 172.16.3.0/24</userinput>
# <userinput>iptables -A FORWARD -i ppp0 -d 172.16.4.0/24</userinput>
# <userinput>iptables -A FORWARD -o ppp0 -s 172.16.4.0/24</userinput>
</screen>

</para>

<para>
The first half of each of these set of rules say, &ldquo;Count all data
traveling in either direction across the interface named ppp0 with a source
or destination (remember the function of the <emphasis>-b</emphasis> flag in
<command>ipfwadm</command> and <command>iptables</command>) address of
<literal>172.16.3.0/24.</literal>&rdquo; The second half of each ruleset is
the same, but for the second Ethernet network at our site.
</para>

<para>
To answer the second question, &ldquo;How much data travels between the
two departments?&rdquo;, we need a rule that looks like this:

<screen>
# <userinput>ipfwadm -A both -a -S 172.16.3.0/24 -D 172.16.4.0/24 -b</userinput>
</screen>

or:

<screen>
# <userinput>ipchains -A forward -s 172.16.3.0/24 -d 172.16.4.0/24 -b</userinput>
</screen>

or:

<screen>
# <userinput>iptables -A FORWARD -s 172.16.3.0/24 -d 172.16.4.0/24</userinput>
# <userinput>iptables -A FORWARD -s 172.16.4.0/24 -d 172.16.3.0/24</userinput>
</screen>

These rules will count all datagrams with a source address belonging
to one of the department networks and a destination address belonging
to the other.
</para>

</sect2>

<sect2 id="X-087-2-accounting.by.service"><title>Accounting by Service Port</title>
<para>
<INDEXTERM id="IPaccounting.service.port" class=startofrange><PRIMARY>IP accounting</PRIMARY><SECONDARY SORTAS="service port">by service port</SECONDARY></INDEXTERM>
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 services are consuming.
</para>

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

<screen>
#!/bin/sh
# Collect FTP, smtp and www volume statistics for data carried on our
# PPP link using ipfwadm
#
ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data
ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 smtp
ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 www
</screen>

or:

<screen>
#!/bin/sh
# Collect ftp, smtp and www volume statistics for data carried on our
# PPP link using ipchains
#
ipchains -A input -i ppp0 -p tcp -s 0/0 ftp-data:ftp
ipchains -A output -i ppp0 -p tcp -d 0/0 ftp-data:ftp
ipchains -A input -i ppp0 -p tcp -s 0/0 smtp
ipchains -A output -i ppp0 -p tcp -d 0/0 smtp
ipchains -A input -i ppp0 -p tcp -s 0/0 www
ipchains -A output -i ppp0 -p tcp -d 0/0 www
</screen>

or:

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

<para>
There are a couple of interesting features to this
configuration. Firstly, 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
TCB-based, we've specified it as the protocol.  Secondly, we've
specified the two services <literal>ftp</literal> and
<literal>ftp-data</literal> in one command. <command>ipfwadm</command>
allows you to specify single ports, ranges of ports, or arbitrary lists
of ports. The <command>ipchains</command> command allows either single
ports or ranges of ports, which is what we've used here. The syntax
"<literal>ftp-data:ftp</literal>" means "ports ftp-data (20) through
ftp (21)," and is how we encode ranges of ports in both
<command>ipchains</command> and <command>iptables</command>. 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. Lastly, we've specified the
source address as &ldquo;<literal>0/0,</literal>&rdquo; which is
special notation that matches all addresses and is required by both
the <command>ipfwadm</command> and <command>ipchains</command>
commands in order to specify ports.
</para>

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

<screen>
# <userinput>ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data smtp www</userinput>
# <userinput>ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 1:19 22:24 26:79 81:32767</userinput>
</screen>
</para>

<para>
If you have already examined your <filename>/etc/services</filename> file, you
will see that the second rule covers all ports except (<literal>ftp</literal>, <literal>ftp-data</literal>, <literal>smtp</literal>,
and <literal>www</literal>).
</para>

<para>
How do we do this with the <command>ipchains</command> or
<command>iptables</command> commands, since they allow only one argument in
their port specification? We can exploit user-defined chains in accounting
just as easily as in firewall rules. Consider the following approach:
</para>

<para>
<screen>
# <userinput>ipchains -N a-essent</userinput>
# <userinput>ipchains -N a-noness</userinput>
# <userinput>ipchains -A a-essent -j ACCEPT</userinput>
# <userinput>ipchains -A a-noness -j ACCEPT</userinput>
# <userinput>ipchains -A forward -i ppp0 -p tcp -s 0/0 ftp-data:ftp -j a-essent</userinput>
# <userinput>ipchains -A forward -i ppp0 -p tcp -s 0/0 smtp -j a-essent</userinput>
# <userinput>ipchains -A forward -i ppp0 -p tcp -s 0/0 www -j a-essent</userinput>
# <userinput>ipchains -A forward -j a-noness</userinput>
</screen>

Here we create two user-defined chains, one called 
<literal>a-essent</literal>, where we capture accounting data for 
essential services and another called <literal>a-noness</literal>, 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 
<literal>a-essent</literal> chain, where we have just one rule that accepts 
all datagrams and counts them. The last rule in our forward chain is a rule 
that jumps to our <literal>a-noness</literal> chain, where again we have just 
one rule that accepts all datagrams and counts them. The rule that jumps to the
<literal>a-noness</literal> 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. Our <command>iptables</command> implementation of the same 
approach would look like:

<screen>
# <userinput>iptables -N a-essent</userinput>
# <userinput>iptables -N a-noness</userinput>
# <userinput>iptables -A a-essent -j ACCEPT</userinput>
# <userinput>iptables -A a-noness -j ACCEPT</userinput>
# <userinput>iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport ftp-data:ftp -j a-essent</userinput>
# <userinput>iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport smtp -j a-essent</userinput>
# <userinput>iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport www -j a-essent</userinput>
# <userinput>iptables -A FORWARD -j a-noness</userinput>
</screen>
</para>

<para>
<INDEXTERM><PRIMARY>datagrams</PRIMARY><SECONDARY>fragmentation of</SECONDARY></INDEXTERM>
<INDEXTERM><PRIMARY>fragmentation, datagram</PRIMARY></INDEXTERM>
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 <emphasis>fragmentation</emphasis>. 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 <command>ipfwadm</command> 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:

<screen>
# <userinput>ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 0xFFFF</userinput>
</screen>
</para>

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

<screen>
# <userinput>ipchains -A forward -i ppp0 -p tcp -f</userinput>
</screen>

and with <command>iptables</command> we'd use:

<screen>
# <userinput>iptables -A FORWARD -i ppp0 -m tcp -p tcp -f</userinput>
</screen>
</para>

<para>
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.
</para>

<para>
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 <option>IP:
always defragment</option> 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 <emphasis>netfilter</emphasis>
<filename>forward-fragment</filename> module.
</para>
<INDEXTERM startref="IPaccounting.service.port" class=endofrange>
</sect2>

<sect2 id="X-087-2-accounting.of.ICMP"><title>Accounting of ICMP Datagrams</title>
<para>
<indexterm><primary>IP accounting</primary><secondary SORTAS="ICMP datagrams">of ICMP datagrams</secondary></indexterm>
<INDEXTERM><PRIMARY>ICMP (Internet Control Message Protocol)</PRIMARY><SECONDARY>datagram accounting</SECONDARY></INDEXTERM>
<INDEXTERM><PRIMARY>ping flooding</PRIMARY></INDEXTERM>
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 <emphasis>ping flooding</emphasis>. 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.
</para>

<para>
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
<command>ipfwadm</command> accounting commands. We listed the ICMP message
types in <xref linkend="X-087-2-firewall.ipfwadm.icmp-types">,&rdquo; so refer to it
if you need to remember what they are.
</para>

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

<screen>
# <userinput>ipfwadm -A both -a -P icmp -S 0/0 8</userinput>
# <userinput>ipfwadm -A both -a -P icmp -S 0/0 0</userinput>
# <userinput>ipfwadm -A both -a -P icmp -S 0/0 0xff</userinput>
</screen>

or, with <command>ipchains</command>:

<screen>
# <userinput>ipchains -A forward -p icmp -s 0/0 8</userinput>
# <userinput>ipchains -A forward -p icmp -s 0/0 0</userinput>
# <userinput>ipchains -A forward -p icmp -s 0/0 -f</userinput>
</screen>

or, with <command>iptables</command>:

<screen>
# <userinput>iptables -A FORWARD -m icmp -p icmp --sports echo-request</userinput>
# <userinput>iptables -A FORWARD -m icmp -p icmp --sports echo-reply</userinput>
# <userinput>iptables -A FORWARD -m icmp -p icmp -f</userinput>
</screen>

The first rule collects information about the
&ldquo;ICMP Echo Request&rdquo; datagrams (ping requests), and the
second rule collects information about the &ldquo;ICMP Echo Reply&rdquo;
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.
</para>

<para>
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.
</para>

</sect2>

<sect2 id="X-087-2-accounting.by.protocol"><title>Accounting by Protocol</title>
<para>
<indexterm><primary>IP accounting</primary><secondary SORTAS="protocol">by protocol</secondary>
</indexterm>
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:

<screen>
# <userinput>ipfwadm -A both -a -W ppp0 -P tcp -D 0/0</userinput>
# <userinput>ipfwadm -A both -a -W ppp0 -P udp -D 0/0</userinput>
# <userinput>ipfwadm -A both -a -W ppp0 -P icmp -D 0/0</userinput>
</screen>

or:

<screen>
# <userinput>ipchains -A forward -i ppp0 -p tcp -d 0/0</userinput>
# <userinput>ipchains -A forward -i ppp0 -p udp -d 0/0</userinput>
# <userinput>ipchains -A forward -i ppp0 -p icmp -d 0/0</userinput>
</screen>

or:

<screen>
# <userinput>iptables -A FORWARD -i ppp0 -m tcp -p tcp</userinput>
# <userinput>iptables -A FORWARD -o ppp0 -m tcp -p tcp</userinput>
# <userinput>iptables -A FORWARD -i ppp0 -m udp -p udp</userinput>
# <userinput>iptables -A FORWARD -o ppp0 -m udp -p udp</userinput>
# <userinput>iptables -A FORWARD -i ppp0 -m icmp -p icmp</userinput>
# <userinput>iptables -A FORWARD -o ppp0 -m icmp -p icmp</userinput>
</screen>

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

</sect2>

<INDEXTERM startref="IPaccounting.config" class=endofrange>
<INDEXTERM startref="config.IPaccounting" class=endofrange>
</sect1>

<sect1 id="X-087-2-accounting.viewing.results"><title>Using IP Accounting Results</title>
<para>
<INDEXTERM id="IPaccounting.results" class=startofrange><PRIMARY>IP accounting</PRIMARY><SECONDARY>using results of</SECONDARY></INDEXTERM>
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.
</para>

<para>
The <command>ipfwadm</command>, <command>ipchains</command>, and
<command>iptables</command> commands differ in how accounting data is handled,
so we will treat them independently.
</para>

<sect2><title>Listing Accounting Data with ipfwadm</title>
<para>
<INDEXTERM><PRIMARY>ipfwadm command</PRIMARY><SECONDARY>listing accounting data with</SECONDARY></INDEXTERM>
The most basic means of listing our accounting data with the
<command>ipfwadm</command> command is to use it like this:

<screen>
# <userinput>ipfwadm -A -l</userinput>
IP accounting rules
 pkts bytes dir prot source               destination          ports
 9833 2345K i/o all  172.16.3.0/24      anywhere             n/a
56527   33M i/o all  172.16.4.0/24      anywhere             n/a
</screen>
</para>

<para>
This will tell us the number of packets sent in each direction. If we use 
the extended output format with the <option>-e</option> option (not shown here because the 
output is too wide for the page), we are also supplied the options and
applicable interface names. Most of the fields in the output will be 
self-explanatory, but the following may not:
</para>


<variablelist>
<varlistentry><term>dir</term>
<listitem><para>
The direction in which the rule applies. Expected values here are
<literal>in</literal>, <literal>out</literal>,
or <literal>i/o</literal>, meaning both ways.
</para></listitem>
</varlistentry>
<varlistentry><term>prot</term>
<listitem><para>
The protocols to which the rule applies.
</para></listitem>
</varlistentry>
<varlistentry><term>opt</term>
<listitem><para>
A coded form of the options we use when invoking
<command>ipfwadm</command>. 
</para></listitem>
</varlistentry>
<varlistentry><term>ifname</term>
<listitem><para>
The name of the interface to which the rule applies.
</para></listitem>
</varlistentry>
<varlistentry><term>ifaddress</term>
<listitem><para>
The address of the interface to which the rule applies.
</para></listitem>
</varlistentry>
</variablelist>

<para>
By default, <command>ipfwadm</command> displays the packet and byte
counts in a shortened form, rounded to the nearest thousand (K) or million
(M). We can ask it to display the collected data in exact units by using the
expanded option as follows:

<screen width=105>
# <userinput>ipfwadm -A -l -e -x</userinput>
</screen>
</para>

</sect2>

<sect2><title>Listing Accounting Data with ipchains</title>
<para>
<INDEXTERM><PRIMARY>ipchains command</PRIMARY><SECONDARY>listing accounting data with</SECONDARY></INDEXTERM>
The <command>ipchains</command> command will not display our accounting data
(packet and byte counters) unless we supply it the <literal>-v</literal>
argument. The simplest means of listing our accounting data with the
<command>ipchains</command> is to use it like this:

<screen width=130>
# <userinput>ipchains -L -v</userinput>
</screen>
</para>

<para>
Again, just as with <command>ipfwadm</command>, we can display the packet and
byte counters in units by using the expanded output mode. The
<command>ipchains</command> uses the <literal>-x</literal> argument for this:

<screen width=134>
# <userinput>ipchains -L -v -x</userinput>
</screen>
</para>

</sect2>

<sect2><title>Listing Accounting Data with iptables</title>
<para>
<INDEXTERM><PRIMARY>iptables command</PRIMARY><SECONDARY>listing accounting data with</SECONDARY></INDEXTERM>
The <command>iptables</command> command behaves very similarly to the
<command>ipchains</command> command. Again, we must use the <literal>-v</literal>
when listing tour rules to see the accounting counters. To list our accounting
data, we would use:
</para>

<screen width=88>
# <userinput>iptables -L -v</userinput>
</screen>

<para>
Just as for the <command>ipchains</command> command, you can use the 
<literal>-x</literal> argument to show the output in expanded
format with unit figures.
</para>

</sect2>
<INDEXTERM startref="IPaccounting.results" class=endofrange>
</sect1>

<sect1 id="X-087-2-accounting.zeroing.counter"><title>Resetting the Counters</title>
<para>
<indexterm><primary>IP accounting</primary><secondary>resetting the counters</secondary></indexterm>
The IP accounting counters will overflow if you leave them long enough.
If they overflow, you will have difficulty determining the
value they actually represent. To avoid this problem, you should read
the accounting data periodically, record it, and then reset the counters
back to zero to begin collecting accounting information for the next
accounting interval.
</para>

<para>
The <command>ipfwadm</command> and <command>ipchains</command> commands provide
you with a means of doing this quite simply:

<screen>
# <userinput>ipfwadm -A -z</userinput>
</screen>

or:

<screen>
# <userinput>ipchains -Z</userinput>
</screen>

or:

<screen>
# <userinput>iptables -Z</userinput>
</screen>

You can even combine the list and zeroing actions together to ensure that
no accounting data is lost in between:

<screen>
# <userinput>ipfwadm -A -l -z</userinput>
</screen>

or:

<screen>
# <userinput>ipchains -L -Z</userinput>
</screen>

or:

<screen>
# <userinput>iptables -L -Z -v</userinput>
</screen>

These commands will first list the accounting data and then immediately
zero the counters and begin counting again. If you are interested in
collecting and using this information regularly, you would probably want to
put this command into a script that recorded the output and stored it
somewhere, and execute the script periodically using the
<command>cron</command> command.
</para>

</sect1>

<sect1 id="X-087-2-accounting.flushing.rules"><title>Flushing the Ruleset</title>
<para>
<indexterm><primary>IP accounting</primary><secondary>flushing the rules</secondary></indexterm>
One last command that might be useful allows you to flush all the IP
accounting rules you have configured. This is most useful when you want to
radically alter your ruleset without rebooting the machine.
</para>

<para>
The <literal>-f</literal> argument in combination with the
<command>ipfwadm</command> command will flush all of the rules of the type
you specify. <command>ipchains</command> supports the <literal>-F</literal>
argument, which does the same:

<screen>
# <userinput>ipfwadm -A -f</userinput>
</screen>

or:

<screen>
# <userinput>ipchains -F</userinput>
</screen>

or:

<screen>
# <userinput>iptables -F</userinput>
</screen>

This flushes all of your configured IP accounting rules, removing them all
and saving you having to remove each of them individually. Note that flushing
the rules with <command>ipchains</command> does not cause any user-defined
chains to be removed, only the rules within them.
</para>

<INDEXTERM startref="ipfwadm.config.IPaccount" class=endofrange>
<INDEXTERM startref="ipchains.config.IPaccount" class=endofrange>
<INDEXTERM startref="iptables.config.IPaccount" class=endofrange>
</sect1>

<sect1 id="X-087-2-accounting.passive.collection"><title>Passive Collection of Accounting Data</title>
<para>
<indexterm><primary>IP accounting</primary><secondary>passive collection</secondary></indexterm>
One last trick you might like to consider: if your Linux machine is
connected to an Ethernet, you can apply accounting rules to all of the data
from the segment, not only that which it is transmitted by or destined for it.
Your machine will passively listen to all of the data on the segment and
count it.
</para>

<para>
You should first turn IP forwarding off on your Linux machine so
that it doesn't try to route the datagrams it
receives.<footnote id="X-087-2-FNAC01">
<para>
This isn't a good thing to do if your Linux machine serves as a router. If
you disable IP forwarding, it will cease to route! Do this only on a
machine with a single physical network interface.
</para>
</footnote>
In the 2.0.36 and 2.2 kernels, this is a matter of:

<screen>
# <userinput>echo 0 &gt;/proc/sys/net/ipv4/ip_forward</userinput>
</screen>
</para>

<para>
<INDEXTERM><PRIMARY>ifconfig command</PRIMARY></INDEXTERM>
You should then enable promiscuous mode on your Ethernet interface using the
<command>ifconfig</command> command. Now you can establish accounting
rules that allow you to collect information about the datagrams flowing
across your Ethernet without involving your Linux in the route at all.
</para>

</sect1>

<indexterm class="endofrange" startref="chac.tcp.ip.accounting">
</chapter>
