FWD: argus-clients informal survey

[Chris Newton]

Hi Carter, here are my coments.

  First, I think you are doing great work!

  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.

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

  d) allow for *at the argus* filtering.  IE: you connect a sensor to link.  
you then connect two remote clients to the argus server.  It would be nice if 
the clients could tell argus what their filters are... and, argus only 
delivers across the network, the flows that they asked for.  this way, a 
LARGE, powerful sensor handling a heavy link, could divide out the analysis of 
the flows to a number of boxes.

  e) allow for options to argus, to tell it what information to try to record.
 For instance, maybe you want info x, y, and z.  bit, not a, b and c.  To give 
argus the most breathing room on larger/abused (thts me :)) links, we could 
tell it up front what work it shouldnt even try to do.

Hmm, thats all for now... If I think of anything else ... :)

Chris


>===== Original Message From "Carter Bullard" <carter at qosient.com> =====
Gentle people,
   Just wanted to get some feedback on the
argus-clients package.  If you've had any chance
to look at it, could you send your first impression,
comments?  If its, "got no time" that's fine.  If its
"I can't understand what's going on because there
are no man pages", that's fine.  If its, "I wish
you would work on something else" then send that
ASAP.  Any comments would be well received.  I'm
trying to figure out where to apply limited
resources.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Chris Newton, Systems Analyst
Computing Services, University of New Brunswick
newton at unb.ca 506-447-3212(voice) 506-453-3590(fax)

"The best way to have a good idea is to have a lot of ideas."
Linus Pauling (1901 - 1994) US chemist

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Chris Newton, Systems Analyst
Computing Services, University of New Brunswick
newton at unb.ca 506-447-3212(voice) 506-453-3590(fax)

"The best way to have a good idea is to have a lot of ideas."
Linus Pauling (1901 - 1994) US chemist