Argus 2.0 wishes

[David Brumley]

I use argus for much of the same purposes as Russell.  Speed and
robustness are our main issues.

cheers,
david


On Tue, 7 Mar 2000, Russell Fulton wrote:

> 
> 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.
> 
> 

-- 
#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
David Brumley - Stanford Computer Security - dbrumley at Stanford.EDU
Phone: +1-650-723-2445    WWW: http://www.stanford.edu/~dbrumley
Fax:   +1-650-725-9121    PGP: finger dbrumley-pgp at sunset.Stanford.EDU
#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
c:\winnt> secure_nt.exe
  Securing NT.  Insert Linux boot disk to continue......
	    "I have opinions, my employer does not."