Argus scripts and docs

[Russell Fulton]

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.