Argus-2.0 Clients

[Carter Bullard]

Hey Russell,
   Thanks for the reply!!  Do you think that Argus
has all the information you need, or have you run into
situations where you really needed something more?

   I know that you focus on security quite a bit
and Argus has a number of security features that are
underused, because again, we haven't supplied clients
to "show off" the feature.  One in particular is
TCP takeover detection and/or spoofing.  Argus already
provides base sequence numbers in each TCP connection
attempt, when it runs in detail mode.  We did this,
because TCP base sequence number prediction is a
serious problem, and a machines susceptibility to this
type of attack is easily detected by a simple scan
of these records.  I'm moving the data into non-detail
TCP Argus records so that we can do this type of scan
routinely.  The client that will do the scan will be
in Argus-2.0.

   Another example where we can improve Argus's strength
in security would be in the area of TCP flow control
activity reporting.  TCP flow control can be used to
mount very subtitle, and very effective DOS attacks. This
I believe will emerge in the next year or two.  But,
again, we don't have any clients that really emphasize
Argus's ability to report TCP flow control activity.
So I'd propose a client in Argus-2.0 that could analyze
for anomalous TCP flow control behavior.

   These are just a few examples of what can be improved
in the area of security.  Does anyone see anything
that we could add in the area of security?


Carter  

-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Russell Fulton
Sent: Tuesday, July 18, 2000 6:12 PM
To: Argus (E-mail)
Subject: Re: Argus-2.0 Clients



On Tue, 18 Jul 2000 08:16:27 -0400 Carter Bullard <carter at qosient.com> 
wrote:

> Gentle People,
>    Its now time to discuss the supported clients that we
> want to provide in Argus-2.0.  The current list of clients
> is not "well thought out" in that we have a collection of
> examples, rather than a concise set of tools that really
> solve problems.  It has been this way a little on purpose,
> as Argus has always been a proof of concept project, rather
> than a solutions style project.  By enumerating the "wish
> list" of clients, I believe we can finish the basic 
> design of the Argus-2.0 server.
> 

Most of the things I do with argus are somewhat esoteric and the 
subject of ongoing developement or, in some cases, one off jobs.  I 
find perl the best language for this and thus my interest is mainly in 
how can I extract data from argus logs quickly (both in terms of cpu 
and human efficiency).  With argus 1.x I open a pipe to ra in my perl 
scripts and this works reasonably well.  So far the only thing I have 
needed that is not available from the default ra displays is access to 
*all* the state info for tcp session.  To get this I ended up patching 
ra :-(

I hate having local patches because of the support problem and it means 
that anyone who uses my scripts also need my patches. (Hi Neil :)  This 
is the main reason I have not submitted my scan detection script to the 
contrib collection (the other reason is that it could do with some more 
tidying up ;) .

So what I want is a client that will allow me to get access to *all* 
the data in the argus records without incurring the difficulties of 
parsing output from fullra.  I guess this is what I was really getting 
at with my proposal for formatting strings for ra output.  I need a 
general tool for efficently extracting and formatting arbitary 
combinations of data from argus records.

The alternative would be to have an api for perl but a generalised 
access tool is necessary because someone else will want to process 
records in Visual Basic ;-)

The other client that I use on a regular basis is raconnections to help 
reduce size of files for archive purposes.

Cheers, Russell.