Argus: The Basics

When regular network IDS alerts aren't enough, and turning to full content data is not an option - the use of flow data can prove useful in tracking down the connections, bandwidth usage, and intents of particular hosts. Argus fits the bill as a lightweight, yet fully featured, bi-directional flow suite of tools.

Capturing data can be as simple as this:

argus -d -i eth0 -w logfile

Where -d starts argus as a daemon, -i specifies the network interface to capture on, and -w tells it where to write out its data to. Scripting the restart, naming of the output files, etc. allow for a more robust collecting scheme and more manageable file sizes.

Now let's say you want to look for a certain host communicating. You could do something as simple as this:

ra -r logfile -nn - host 10.10.5.4

This uses the argus client (ra), to read the logfile with -r. The -nn tells argus to not resolve IP addresses to hostnames, and to also not translate port numbers to service names - making the processing of the file that much faster. The pieces that follow the last (-), can be any BPF filter, with any number of combinations. The BPF used above, simply says, only include records that have IP address 10.10.5.4 as the source or destination. Various other ra* clients exist, for various different uses - as we will get into below.

Output from the above example could look like this:

01 Jun 07 14:01:22 q tcp 192.168.1.25 -> 10.10.5.4 7 1236 FIN
01 Jun 07 14:01:31 q udp 10.10.5.4 <-> 192.168.10.10 13 1411 CON

The ra client displays various useful information, such as a timestamp, protocol, source & destination ports and IPs, source and destination bytes transferred, and last known established state or pseudo-state.

Let's move on to a more complicated example, combining various argus clients to pull together some data that we may be interested in. Combining argus clients, to process the outputs of each sequentially allows much more powerful results.

Since argus takes a best guess as to an established flow or session, ragator, aggregates the various flows into what it thinks a "conversation" may contain - by combining flows it believes go together. Let's run it as so:

ragator -r logfile -nn -w tempgator - host 10.10.5.4

We read in our logfile with ragator, this time writing out our results to a new file called tempgator. Ragator aggregates the flows into "conversations" containing our host 10.10.5.4 in either the source or destination IP. This data could be useful to get a bigger picture, maybe seeing large transfers, etc. But let's now process this file through ramon to find our top pair of talkers with 10.10.5.4 being one on either side.

ramon -r tempgator -nn -w tempmon -M Matrix

In the above, ramon processes the ragator file, and finding the top pairs of talkers by bytes. Various other options can be passed to the -M option, such as finding only the top 10 talkers, etc. We will then process this resultant file through rasort to list our top talker pairs in a more orderly format.

rasort -r tempmon -nn -M saddr bytes

What we did here was tell rasort to list, in order, first by the source IP address, then by total bytes transferred the top talkers' conversations. Quickly identifying who were the largest bandwidth hoggers from our resultant argus capture file. Numerous sorting options are available to rasort via the -M option.

One other useful client to mention is racount. Racount will take a statistical snapshot of the file that you process to give you some higher level protocol breakdowns. As an example, run:

racount -ar logfile

This will give statistical counts of IP, TCP, UDP, etc. breakdowns of packets, bytes, etc. Useful for determining what the general makeup of this argus captured file is.

Argus includes many options, as this was only a small sampling of options available. Furthermore, v3.0 will introduce racluster which greatly simplifies the various steps needed to take to get data in the format that other argus clients act upon.