Argus 2.0 wishes

[Russell Fulton]

On Mon, 6 Mar 2000 10:03:18 -0800 Carter Bullard 
<cbullard at nortelnetworks.com> wrote:

>    There aren't too many illegal TCP bit combinations,
> and this logic would be very useful, however, the Argus
> reporting strategy is to have a status bit to report
> each explicit condition.  Each detected combination would
> require a bit in a status field somewhere, and we don't
> really have any status bits to spare in the 1.x version
> of Argus.


I'm aware of that, but I have an eye to the future ;-)

> 
>    As a result, I am starting to think a lot about
> Argus 2.0, which will have a completely new Argus record
> format.  I am working on the basics right now.
> I would like to stay with fixed length records, and 128 - 192
> byte fixed length binary records are looking very attractive
> to me.  An alternative would be for Argus to output XML
> formated data, but I would rather have Argus put out binary,
> and have converters/translators that would generate XML
> as an example.

I agree with this.  We can write utilities to transcribe into transport 
formats if we need them.  The key advantage that Argus has is that it 
manages to pack a lot of information into a small record for archival 
purposes.

> 
>    I would love to hear what you guys would like to see
> in Argus 2.0.  My list is focused on performance metrics,
> but enhanced TCP state metrics are things that would be
> more than reasonable.  Any ideas????
> 

Hmmm.... Perhaps the best way of doing this is for some of us to 
describe how we use argus and what we see as its strenghts and 
weaknesses.

I use argus in (at least) 3 distinct ways:

1/ I have a perl script that reads data from an ra process which 
connects to argus server via a socket.  This provides near real time 
detection of network and host scans.

2/ I have a bunch of overnight jobs which do more detailed analysis of 
the days logs.  There is another scan detector which acts as a backup 
to 1 but also picks up very slow scans -- down to a packet or two a day.
I am currently running a filter that picks up Pretty Park traffic and I 
also log all non http traffic to our many web servers.

3/ Every now and again I end up trolling back through the logs for some 
special reason, eg. looking for the actual compromise when we find a 
cracked system etc.

So my focus is very much on detecting unwanted activity entering and 
leaving our network, either in (more or less) real time or well after 
the fact.

What I like about argus:
1/ Having the ability to process historical data, be it yesterday, last 
week or last month.  This is something you don't get with standard NIDS.
2/ being able to keep several months data on line on a fairly modest PC 
(OK we also have a fairly modest Internet feed (around 1Mbps) which 
helps.

Weakness:  From a NIDS point of view (which isn't what argus was 
designed as) not being able to get into the packet payload is a 
limitation.  What I really want is a cross between argus and snort.

Wish List:

1/ Better reporting of 'anomolous' tcp traffic.  One way of doing this 
would be to have a separate record class for things that are not part 
of a 'proper' tcp stream which used the status bits differently.

2/ a perl client ;-) I have wondered about building perl callouts for a 
client.  I have never done anything invovling C/Perl interface so I 
don't know how difficult or otherwise that would be and when it comes 
down to it starting up ra from within perl seems to work OK.

I have toyed with the idea of logging content from addresses that are 
scanning (to look for exploit attempts) but this is probably a waste of 
time since most scanning is automated and any exploit attempts are 
likely to come from somewhere else entirely.  To do this you need to be 
able to start your packet capture very quickly (I tried to fork tcpdump 
from my watcher script but it gets real messy trying to keep track of 
processes and kill them off at appropriate times).

I am happy to see argus stay a UNIX tool for the moment.

Cheers, Russell.