Argus scripts and docs

[Carter Bullard]

Hey Russell,
   The 'est' bug I'll get to this week and we'll
have it in 1.8 which is just now coming together.
I'll also put in the key words for picking out
TCP state.

Carter

Carter Bullard
Principal Consultant
Nortel Networks
320 Park Avenue  16th Floor
New York, New York 10022
Email  cbullard at nortelnetworks.com
Phone +1 212 317 4230
Fax   +1 212 317 4324 

> -----Original Message-----
> From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
> Sent: Sunday, February 14, 1999 4:12 PM
> To: Carter Bullard
> Cc: argus at lists.andrew.cmu.edu
> Subject: Re: RE: Argus scripts and docs
> 
> 
> 
> On Fri, 12 Feb 1999 19:02:53 -0500 Carter Bullard 
> <cbullard at nortelnetworks.com> wrote:
> 
> > Would you want to do this on a ra() command line, or
> > as a dedicated argus client that does this specific
> > filter? 
> 
> In the long term probably both ;-)  See below.
> 
> > If you want to do it on the command line, then
> > I can describe the mods needed for the scanner.l and grammar.y
> > files to give us a command line tag that will pick these
> > specific records for you.
> > 
> >    It maybe that we might want to expose all the
> > TCP states on the command line so that you can pick
> > the ones of interest.  If we did expose all the
> > state, we could have a syn, synack, data, fin, finack,
> > like set of tags that you can use to chose your flows
> > of interest.
> > 
> >    I believe that your lone synack would break down
> > to be in this scenario:
> > 
> >     (synack and not (syn or data or fin or finack or reset))
> > 
> > that may be the most general purpose way of approaching
> > your need.  
> > 
> >    Your call as to how you want it implemented.  What do you
> > think?
> > 
> 
> I think that exposing all the tcp states on the ra command line is a 
> good way to do it. This allows easy prototyping of tools 
> which can then 
> be recoded as separate C clients if there are performance issuses.  
> 
> I have been corresponding with someone who is interested in my scan 
> detector but they have 1GB of logs a day and I'm fairly sure my perl 
> progam which reads output from ra won't hack it.  So, once I have it 
> all sussed, I will recode the whole thing as a C client which should 
> speed it up a lot. In the mean time it has been great using 
> perl and ra 
> to construct the prototype.  I find it a much faster way to work.
> 
> i.e. I think just about everything should be accessable from 
> ra. ra is 
> like the raw sql interface to a Database -- very powerful for one off 
> jobs or prototyping but not something you tell the secretary about.
> 
> I have been assuming that 'not est' will report all tcp sessions that 
> did not have a completed the initial handshake (including any 
> isolated 
> single packets like fins or fin+acks).   Syn+acks are problematic 
> because ra (quite logically) swapps the source and 
> destination so they 
> get lost if you are filtering on source or destination networks.
> 
> BTW what is the status of the 'est' filter element in 1.7?  I had 
> failed to get it to work and have a patched ra that ignores all 
> established tcp sessions.  I know this has come up before but I am 
> confused as to what the final answer was.
> 
> Cheers, Russell.
> 
> 
> 
> 
>