Argus 2.0 features

[Carter Bullard]

Hey Russell,
   This can be done.  Argus is already doing this to some
extent, since it has to account for the TCP state machine
when it gets these anomalous packets.  The question is,
"what do you want Argus to do?".  There are several options.

 1. We could have a bit indicator that reports that the anomaly
    existed during this reporting interval.  Probably interesting
    but probably not what you want.

 2. We could generate an independent Argus record for the
    anomaly, say as a management record.  This will do what you
    want, but generate potential problems, as it offers an
    attacker the opportunity to overwhelm the Argus system
    with unlimited anomalous packet reports.

 3. Come up with an anomalous packet flow abstraction, that
    allows us to track the anomaly packet as a separate flow
    allowing us to control how often we report on the event.

None of these are probably exactly what is needed.  What kind
of crazy packets do we expect to see?

Carter



-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Russell Fulton
Sent: Tuesday, July 04, 2000 11:20 PM
To: argus at lists.andrew.cmu.edu
Subject: Argus 2.0 features


Hi All,
	My main interest in argus is two fold, firstly as a tool for 
detecting threatening or anomolous traffic and secondly as an audit 
tool for forensic investigations.

The current version of argus is an very good for that latter purpose 
but has significant weaknesses in the former role.  In particular it 
does not do a very good job of logging single packets that do not 
conform to the normal tcp state transitions.  Carter has done a great 
deal over the last couple of years to improve argus in this respect 
(Thanks!) but he has now run up against the storage limitations of the 
current audit record.

So what I would like to initiate here is a discussion amongst those of 
us involved in Misuse detection (for want of a better term).

The question is what new features do we want from Argus?

Here one idea of the top of my head:

1/ the ability to log tcp packets that are anomalous, e.g.
   packets with illegal combinations of flags.
2/ the logging of more complete information for such packets (perhaps 
   the best way to do this would be to have a new record class for such 
   packets.
3/ When such packets are detected the should be written out immediately.

There are some cases where it is not straight forward to decide if a 
packet is anomolous or not e.g.  a packet with ACK of FIN set where 
there is no established tcp stream.   It may be a tcp-ping or FIN scan 
or they might just be packets of a tcp stream that got delayed and the 
stream has timed out.  I think that I would like such packets flagged 
in some way to aid easy extraction by ra and friends. 

What do others think?

On the subject of language support, (dam, I seem to have lost Carters 
original post on the subject).  Nearly all my access to argus records is
via perl scripts which run ra with various filters.  This works fine 
most of the time but there are ocasions when I would have liked to have 
a lower level access to the argus files from within perl (or more 
sophisticated filtering) from ra.  It would seem that the biggest cpu 
overhead in ra is formatting the record for output, in a few cases I 
have had to use ra to extract large numbers of (or all) records and this
is relatively slow.  This is particularly so if you are doing 
statistical investigations. 

Lastly an aside -- I am about to buy a new machine which will be used 
to store and analyse argus records.  Anybody have any experience on 
what factors limit the performance of ra and friends running on disk 
based logs?  Oh, BTW money, is tight ;-)

I thought of a fast and wide scsi disk and 128MB memory 500Mhz 
processor.  Not taking the standard IDE disks increases the price 
considerably does anyone have a feeling for what difference this will 
make to performance?  

It will run either Linux or FreeBSD, again any opinions?

Is there anyway I can trade memory for disk reading performance on 
these OSes.

Cheers and thanks,

Russell.