Argus 2.0 wishes

[Russell Fulton]

On Mon, 6 Mar 2000 17:14:17 -0800 (PST) Peter Van Epp <vanepp at sfu.ca> 
wrote:
> 
> > 
> > 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.
> > 
> 
> 	I'm torn on this one :-)

Me too ;-)

[ snip ]

You did a good job of describing the functionality that I want!

> 
> > 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 tend to think ra is the appropriate answer here. Most of what I find
> perl useful for in argus is summarizing and keeping state across time (such
> as finding scans fast or slow) and/or sorting or summarizing by address and or 
> content with associative arrays and that isn't particularly time sensitive. 
> Thus the additional step of processing through ra doesn't seem a problem to me
> against the additional work of maintaining a perl interface to argus, but I 
> may well be wrong or not thinking far enough ahead.

Yes, and if you have a really time critical application then you can 
protype it in perl fairly quickly and then write a 'proper' C client 
for it.

> 
> > 
> > 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.
> 
> 	Or as a network tool that runs on a stripped down box that really isn't
> Unix anymore (since Argus is really mostly a state machine that understands
> the network).

Hmmmm... we still maintain a DOS version of NeTraMet, it's got all the 
packet capture code...  Also there is Trinux ( http://www.trinux.org/ )
which would be a lot more straight forward.

> 
> 	And finally one wish list item of my own (to do with network 
> performance): I'd like to see argus at least count non IP packets on the 
> network interface with a view to providing an indication of how busy the 
> network is over a time interval i.e. since it is seeing all packets on the 
> network, at least we hope it is, count them and calculate how busy the network
> has been over some possibly programable interval. I'd have to admit that it
> may be a better bet to leave this to NetRaMet as the tool designed for the 
> job, but argus has the information (and already keeps track of who is running
> at least for IP).

I use NeTraMet for this ;-)  I run both argus and Netramet servers on 
the same Linux box but with your datarates you may want two boxes.

BTW Netramet will now collect frequency distributions for things like 
bit rates etc.  I can post some of my plots if anyone is interested.

Russell.