Argus 2.0 wishes

[Neil Long]

Either a filter file or perhaps have the clients use an ENV pointing
at a file for such options - the command lines can get awfully 
long otherwise.

I like the filter file option for argus itself - I can modify it and
see the effect the next time that cron scripts re-start it.

For argus wouldn't (or is) support for a -HUP signal (or USR1, etc)
to re-read the filter file be useful? 
There are often times when I would like the running process to 
temporarily ignore (or not) a host or port but at present I have to 
stop and start it.

On a busy network monitoring point I have been pondering on ways to 
reduce the cpu load - adding long or complex filter expressions
seems to have an impact on cpu utilisation. Has anyone tried using 
something along the lines of ipfilter to drop IPs or ports before they
get passed up the stack (or does the BPF filter defeat this line of
reasoning on Solaris?) on the Argus host? Otherwise I might try a simple bridge
firewall like Drawbridge to reduce the traffic. I can see there will be
trade-offs.

Neil



On Mar 16,  6:13am, Carter Bullard wrote:
> Subject: RE: Argus 2.0 wishes
> 
> Hey Russell,
>    For Argus clients, we already have a configuration
> file, of sorts, to support long filter defintions.
> Do we want to just extend that with additional
> configuration data?
> 
>    I really like the idea.  I'll try to come up with
> the set of data primitives that we can generate, and
> lets see what we have after that.  I'll try to have
> it by next week.
> 
> Carter
> 
> > -----Original Message-----
> > From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
> > Sent: Tuesday, March 14, 2000 6:49 PM
> > To: argus at lists.andrew.cmu.edu
> > Subject: Re: Argus 2.0 wishes
> > 
> > 
> > More wishes ;-)
> > 
> > I would like to see a argus confirguration file in which on 
> > can specify 
> > things like timestamp formats (I have patched ra to print dates in a 
> > non ambiguous format).  It would also be useful to allow one to set 
> > default flags for clients and even, possibly, default output (in a 
> > string like strftime). This would be really useful where one 
> > is feeding 
> > ra output to a perl script e.g. you specify just the data you 
> > want and 
> > have the fields separated by tabs -- "%T\t%F\t%P\t%S\%s\..."
> > 
> > %T -- timestamp 
> > %F -- flags
> > %P -- Protocol
> > %S -- source IP
> > %s -- source port
> > 
> > etc.
> > 
> > in perl:
> > 
> > while (<RA>) {
> >    my ($time, $f, $p, $src, $srcp ... ) = split("\t", $_);
> > 
> > }
> > 
> > At the moment I use unpack to split up the record but occasionally 
> > fields overflow and then unpack returns garbage for some 
> > fields. split 
> > should be faster than unpack too.
> > 
> > I'd be happy to contribute code to parse the config file -- I 
> > have done 
> > something similar for the netramet project.  (No it isn't in the 
> > current release).
> > 
> > Cheers, Russell.
> > 
> > 
> > 
> > 
> > 
> > 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Dr Neil J Long, Computing Services, University of Oxford
 13 Banbury Road, Oxford, OX2 6NN, UK Tel:+44 1865 273232 Fax:+44 1865 273275
 EMail:       Neil.Long at computing-services.oxford.ac.uk  
 PGP:    ID 0xE88EF71F    OxCERT: oxcert at ox.ac.uk PGP: ID 0x4B11561D