Argus-2.0 Clients

[Carter Bullard]

Hey Guys,
   I hope that there isn't any confusion about what
I'm doing and/or asking.  I think that we're well on
our way to coming up with a new Argus record that
is going to do a lot of good stuff.  I'm asking these
questions to make sure that we're not missing something
obvious before I begin the record format designs and
start coding Argus-2.0.

   So far we've got both new Argus data and management
records that are 3-4x previous Argus records.  The
management records have a new type, that will report
events that are associated with a give flow.  Among
those events are partial packet capture, and anomalous
protocol events, such as TCP state violations.  For
these in particular the entire TCP header, and some
of the user data will be in the event, so we should
be able to decode what is going on, if we have the
right type of clients.

   For the data records, we're going to extend the
flow model to include things like MPLS and
802.1P/Q type tags, and we're going to extend the
specific transport support to include RTP/RTCP and
IGMP traffic.  We're also going to put back the ARP
and the DHCP traffic auditing features, so you can
support things like arpwatch(), etc...

   I'm going to add traffic burst metrics, so that
we can better signature applications/services in
order to support what I'm calling covert channel
discovery, and we're going to add some amount of
user data into each record in order to support
covert channel, and application/service validation.

   So all of this sounds like a lot of work, but
much of this stuff will come quickly, once we get
the basic motives and needs down.

   I am interested in support some packet decode
capability in Argus, since we are going to put
some packet contents in Argus records.  But one of
the basic concepts of Argus is to try to minimize
packet decodes as a requirement.  I know that this
is a tough problem to solve, but I believe that it
is important with link speeds going up and up and
up.

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: Friday, July 21, 2000 11:13 PM
> To: Argus (E-mail)
> Subject: Re: RE: Argus-2.0 Clients
> 
> 
> 
> On Fri, 21 Jul 2000 13:20:50 -0700 (PDT) David Brumley 
> <dbrumley at rtfm.stanford.edu> wrote:
> 
> > > On Wed, 19 Jul 2000 08:24:07 -0400 Carter Bullard 
> <carter at qosient.com> 
> > > wrote:
> > > 
> > > > 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?
> > > 
> > > Firstly, I don't consider myself to be an expert in this area.  
> > > Basically all I have done is write some scripts that do 
> some fairly 
> > > obvious things.  I think David, Neil and Peter all know 
> more about the 
> > > the low level mechanics of what attackers are doing than 
> I do so I 
> > > would be very interested in their opinions of this matter.
> > > 
> > 
> > You give me too much credit :) Since the number of TCP/IP 
> combinations is
> > almost infinite, it's really hard to say what people are 
> going to do to
> > disguise traffic in the long run.  So, I think adding an 
> expression filter
> > where you can specify events (as in a chain of TCP/IP 
> packets) and an
> > action.
> 
> That's the conclusion I came to too. As I have said before, the best 
> way that argus can help with this problem is too report *all* packets 
> that don't fit into established tcp streams, cause illegal state 
> transitions or are illegal in some other way.
> 
> Another way of stating this is that it is easier to enumerate 
> the legal 
> states (be they flag combination or state transitions) than the 
> illegal. 
> 
> hmmmm... I guess what Carter is asking for is samples of illegal 
> traffic from know tools that should be flagged so he can build up a 
> test test that can be used for regression testing.  If that 
> is the case 
> then we need to keep it up to date as new tools and techniques emerge.
> 
> I have already volunteered to get some samples of nmap scans 
> and finger 
> printing.  Are there any other tools which we need samples from?
> 
> I seem to remember that the new argus record does have the ability to 
> save some packet data.  This would be very useful in regard to 
> anomolous traffic.  So when we get 'bad' packets then argus can 
> actually keep copies of the headers and possibly payload.
> 
> A while back I  commented that what I really wanted was a 
> cross between 
> argus and snort, this was one of the things I had in mind.
> 
> One other thing that I have wanted to do from time to time in my scan 
> detector (which listens on a socket to an argus server in 
> detail mode) 
> is to tell 'something' to start capturing a packets stream for me.  I 
> tried to do this by forking a process to run tcpdump but in 
> just about 
> every case by the time that tcpdump got started the traffic I was 
> interested in had ceased -- typically class C scans which last a few 
> seconds.
> 
> What would be neat would be a process that kept a few minutes 
> buffer of 
> network packets (like the modern portable CD players).  With current 
> memory prices this is now feasible (at least at the data rates that I 
> have to contend with). Then I could do retrospective packet dumps!
> 
> This is almost certainly outside the scope of the argus 
> project but if 
> anyone know of something that does I woud like to hear. 
> (something else 
> to play with in my copious spare time ;-)
> 
> Cheers, Russell.
> 
>