FWD: argus-clients informal survey

[Peter Van Epp]

> 
> Hi Carter, here are my coments.
> 
>   First, I think you are doing great work!
> 

	I'll second that one and agree with most of the rest of Chris's 
statements below. I'm in the "currently too swamped to do much" catagory
I have compiled the new code (although not the newest one yet) but thats 
about it so far (and probably for the next while). I'll try to get to compiling
the latest code on Solaris FreeBSD OpenBSD and NetBSD.


>   Second:  I was quite happy to see the ratop addition, but I believe, with 
> that, you have provided quite an array of methods for retrieving information 
> from the argus log files.  With a well defined interface to the argus 
> structures, possibly a perl module, and 1 client that could print out anything 
> in the log file, I'd say that is very complete.  It gives everyone the tools 
> they need to do what ever analysis they need/want to do.
> 
>   I know your interest is in security, and others in performance of the 
> monitoring capability.  Having said that, _my_ vote (which is obviously 
> strongly affected by my needs/interests) would be in seeing more information 
> added to argus that it can track, and scaling changes to move argus up so that 
> it is the hardware limits we run into, not software.
> 
>   Here are some ideas along those lines, off the top of my head:
> 
> 
>   a) the 'step down' ideas we all talked about a couple months back, where 
> when argus is seeing a DoS attack (or something), it starts 'doing less'.  Ie: 
> says, forget the interpacket jitter information, forget the super accurate 
> duration information...lets just get this stuff accounted for.
> 

	Agree completely. I suspect this is going to get more important on 
faster links.

>   b) when a DDoS type attack is seen, understand it, and not try to generate a 
> flow record for each remote IP seen, when attacking a certain host on a 
> network... tell argus to generate an aggregated record *at the argus*.
> 
>   c) when a standard DoS attack is seen, which you can know by the unique 
> signature (flags/status) and sheer number of packets, do aggregation at the 
> argus... dont tryand generate a flow (and, all the flow info that goes along 
> with it).

	Nice idea, if it can be done but I expect the required state to 
slow things down a lot. I expect the capture engine is going to need to 
just capture and do minimul processing and be prepared to pass off to possibly
multiple back ends with more horsepower/time (because of limited focus) than
the main sensor. The main sensor wants to be able to keep up at wire speed
and intellegently (without being overloadable which is the exciting part :-))
distribute flows amoung backend processing engines.


Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada