HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Argus
Go to: HSC Trainings
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Argus  

by Yann Berthier (19/02/2002)




	--[ A R G U S ]--

Argus (Audit Record Generation and Utilisation System) is a tool to do IP
networks auditing.


Argus has two main modes of operation:

o offline reading of a tcpdump network capture, to spot 'illegitimate' flows.

o deployment of Argus sensors with real-time capture of the network traffic, to
do analysis of the generated network records.

Information gathered by Argus on the network is synthesized by flows, and will
serve several purposes: 

o to highlight and diagnose network problems, eg performance ones.
o to pinpoint security problems, and, to some extent, to enhance the security
process in your networks - we will focus on this application of Argus.


	--[ Installing Argus ]--

Argus can be downloaded here: http://qosient.com/argus/

Installation process is usual, and should not be a problem:
./configure && make && sudo make install

But as one say, your mileage may vary.


	--[ An overview of Argus ]--

Argus is made of several programs, controlled via configuration files or
command-line options.

o argus reads network data, from a tcpdump / snoop capture file or directly
from the network, and writes its output in argus format, either on the network
and / or in a file. Up to 5 different outputs can be specified for each
instance of argus running.

o ra* programs take argus data as input (from the network or from a file) and
generate ASCII records. ra* programs can work on Cisco Netflow data too. 

Bpf like¹ filters can be specified for each Argus program.

¹ while the syntax originates from the bpf(4) one, expressions specific to
argus are available to apply filters on argus generated network records.


argus
-----

Main options of argus:

-d: daemonize 
-r <file>: reads a tcpdump / snoop trace 
-i <interface>: specifies the network interface Argus will listen on
-w <file>: writes the output in a file 
-P <port>: binds to the TCP port <port> for remote ra* clients.

When the -P flag is used, Argus supports TCP-Wrappers for access control, and
SASL for authentication - SASL support must be activated at compile time
though.


ra*
---

Main options:

-r: reads a file in the argus(8) format 
-S <server>: specifies a remote argus server to collect data
-P: specifies the port of the remote server 
-F <file>: uses the configuration file <file> 
-a: displays per protocol stats at the end of the output
-c: displays the number of packets and the number of bytes of network records
-g: displays the duration of a flow
-n: disables DNS resolution
-p <number>: sets the time precision displayed
-m: displays link-level (MAC) addresses 
-w <file>: writes the output in a file, default being the standard output

Another helpful option is the -t flag, to specify a time range. The main
problem on a network being the users :-/ it can be handy to focus on flows when
there is supposedly no user activity, to be able to pinpoint more easily
suspicious flows.

Examples:

-t 02/12 to display only flows of the 12th of february 
-t 14 for flows between 2pm and 3pm each day
-t 02/07.18 - 02/08.08 for flows between 6pm the 02/07 to 8am the 02/08 


Main ra* programs
-----------------

ra: takes argus data as input, and produces an ASCII output.

ragator: aggregates flows coming from an argus source. The aggregate method of
network records can be controlled in a flowfile(5) configuration file,
specified with the -f <flowfile> option. 

The default behavior of ragator is to aggregate network flows by the {(saddr,
sport), (daddr,dport)} four-tupple, but one can for instance aggregates all
$HTTP flows going to the $PROXY_DMZ. An example of flowfile can be found in the
support/Config/ directory in the Argus source hierarchy.

rasort: sorts argus network records. Several sort fields can be specified.

raxml: produces an xml output from an Argus input.


A command-line example to read data from the network and to display recorded
flows on the standard output:

# argus -i ep0 -w - | ra -n -g -c -L 0 - 'ip and src net 192.70.106.0/24'

The -L 0 option, documented only in the support/Config/rarc example file,
displays column headers.


	--[ Argus network records (flows) ]--

One of the main strengths of Argus to spot illegitimate network traffic is its
support of flows.

Regarding ICMP, any icmp traffic between the source address and the destination
address with matching icmp type for the request and the reply is considered as
a flow, eg:

    Start_Time      Duration Type     SrcAddr    Sport  Dir       DstAddr  port  SrcPkt   Dstpkt    Response Information    State
14 Feb 02 13:33:39        0  icmp   192.168.3.75       <->     192.168.3.33       1        1         98           98          ECO

here, one (SrcPkt column) icmp echo request datagram flew from 192.168.3.75 to
192.168.3.33 which replied with an echo reply datagram, as shown by the 'Dir'
and 'DstPkt' column.

For UDP, is considered as a flow packets matching the four-tupple
{(saddr,sport), (daddr,dport)}. The state of the 'connection' is taken in
account as well:

INT to indicate the first datagram of a UDP flow from the source to the
destination.

ACC to indicate the destination replied:

14 Feb 02 13:44:32        0   udp   192.168.3.75.1493  <->     192.168.2.99.53    1        1         66           121         ACC

This Argus record shows a DNS query from 192.168.3.75 to 192.168.2.99, and the
server reply (of 121 bytes).

CON: a UDP transaction is pending between the source and the destination. Here
is an example of an NTP synchronisation: 

14 Feb 02 13:50:46        0   udp   192.168.3.75.123   <->     192.168.3.33.123   4        4         360          360         CON


For TCP, the same tupple is, of course, taken into account, and the TCP flags
are considered as well:

REQ indicates a connection request (SYN bit set from the source to the
destination).
EST: the TCP session is established.
CLO: the TCP session ended normally, with the 2 way FIN exchange between source
and destination.

I'm sure that those of you who already had to try to determine whether a
compromission occured on a network among one weekend of tcpdump traces see all
the benefits of Argus !


	--[ Argus use ]--

Argus can be of invaluable help to leverage the security on a network.

To synthesize flows on a network, to be able to characterize a network and
distinguish normal flows from suspicious ones, hence to be able to partition
the network (yes this is an important use of Argus, and yes we see actually
many flat networks, and more admins without an ounce of knowledge about what's
going on on their networks, and which flows are required and which ones can be
filtered)

To easily spot illegitimate flows and / or filtering rules not properly
enforcing the security policy: 

o traffic during illegitimate hours, for example irc flows to the Internet, or
numerous DNS requests coming from a single workstation during the night.

o traffic to / from sensible hosts / networks.

o flows with puzzling characteristics, eg icmp network records with huge
payloads .

All those patterns, easily catched by digging into Argus records can be
evidences of a compromised host.

Slow scan can be detected too, especially using ragator:

./ragator -n -G -c -L 0 -R -r /data/trace3.arg

(the -G option is used to display the start _and_ end time of a flow)

13 Feb 02 20:01:41  14 Feb 02 09:27:27  icmp      192.168.0.11        ->     172.16.3.33   	85 	0         5610         0           ECO

Here, 85 icmp datagrams (echo request) were sent by the source from 8h01pm the
02/13 to 9h27 the 02/14. No reply appears in the flow, the datagrams have been
discarded somewhere in the path.


13 Feb 02 18:47:47  14 Feb 02 09:22:57  icmp      192.168.22.68       <->     172.16.3.25       352      352       34496        34496       ECO

A contrario, this network record show 352 echo requests which all elicited echo
replies from the destination.

At it appeared by looking at the originating IP, the first flow was generated
indeed by a well known association dealing with Internet data analysis and is
not a scan per se - well, not an evil one :)


Several perl scripts are available in the contrib/ directory of the Argus
sources to help detect scans.

Other scripts have been written around Argus, for example to detect crc32
compensation attacks against ssh.


	--[ Which stands for conclusion ]--


When we are called after an incident, one of the first things we usually ask
our customer is to put sniffers on the network to have data to work on when we
begin the analysis. Of course Argus is very helpful when it come to find
evidences in the network records gathered.

Unfortunately, it's often already too late - what we need to determine what
happened is traces from the very beginning of the incident. Argus sensors
deployed on several locations on the network would be a big win in such a case:

The point is that in real life things are not always simple like a rooted
Linux box with a nice rootkit. 

Generally, when we are called after a problem on a server, we're asked to
determine the origin of a problem:

o external intrusion
o internal malevolence
o human error

Having network records is generally vital in such situations, to have proof of
what happened and assess the different assumptions.


Argus is by no means intended as a replacement for a sniffer like tcpdump, or
for a NIDS such as Snort. Actually, it's a very complementary approach to
'classical' NIDS sensors to do attack detection:

o Argus doesn't rely on signatures.
o Argus helps to spot things which are difficult to track at an NIDS level:
slow scans and covert channels for instance. 
o Traffic recorded by the Argus sensor(s) is invaluable to do network forensics
after an incident, and to understand the cause of the incident. 

Argus sensors are already deployed to do attack detection / network forensics
on big networks with big pipes.

It's now up to you to give it a try on your networks !

$Id: argus_en.tip,v 1.3 2002/03/08 11:04:50 berthier Exp $



Last modified on 12 November 2003 at 13:55:00 CET - webmaster@hsc.fr
Information on this server - © 1989-2013 Hervé Schauer Consultants