Argus scripts and docs

[Carter Bullard]

Hey James,
If the 'est' keyword was working, you would do:

   ra -ncr filename reset and not est

In the new scheme you could do:

   ra -ncr filename syn and reset and not (synack or data)

Both of these schemes would select:

SYN  ->>
RST <->

This is my notation for multiple SYN's from the source
and a single RST from either the source or destination.

So, here you would get matches when the source resets the
TCP establishment, which is very common, especially
with HTTP traffic (someone hit STOP on their browser).

In order to pick up only your scenario, you will want
to see only SYN and RESET flags set in the status 
field, and check the src and dst count fields to see
that you have traffic in both directions, preferrably
with only one packet from the destination.

Hope this helps,

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: James Dryfoos [mailto:dryfoos at ll.mit.edu]
> Sent: Tuesday, February 16, 1999 9:02 AM
> To: Carter Bullard
> Subject: RE: RE: Argus scripts and docs
> 
> 
> On Tue, 16 Feb 1999, Carter Bullard wrote:
> 
> > 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
> 
> Great. Would that allow me to filter on a
> 
> SYN ->
> RST <-
> 
> pair? Kind of a "not est"?
> 
>   -- Jim
> 
> > 
> > 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.
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> 
> ==============================================================
> ============
>      James Dryfoos (JD243)              | mailto:dryfoos at ll.mit.edu
>      M.I.T. Lincoln Laboratory          |
>      Computer & Telecommunications      |
>      244 Wood Street, MailStop: B-120   | (781) 981-2008 - office
>      Lexington, MA 02420-9108, Earth    | (781) 981-0782 - fax
> ==============================================================
> ============
>