Argus scripts and docs

[Carter Bullard]

Hey guys,
   This discussion is great, sorry that I'm coming into
it at a late point.

   Your lone syn/ack flows are easily picked out of
argus records, because the state indicators are included
in each TCP flow record.  Unfortunately the current
argus specific compiler doesn't support picking tcp
flow records that have a single syn/ack packet as the
only packet in the flow, but this is easy to do.

Would you want to do this on a ra() command line, or
as a dedicated argus client that does this specific
filter?  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?

Carter

-----Original Message-----
From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
Sent: Thursday, February 11, 1999 3:44 PM
To: Joerg Bashir
Cc: argus at lists.andrew.cmu.edu
Subject: Re: Argus scripts and docs



On Wed, 10 Feb 1999 21:40:10 -0800 Joerg Bashir <jkb at healtheon.com> 
wrote:

 
> First off, are there more contributed scripts (clients) for data
> analysis, some kind of repository?

Only what comes with the argus distribution, so far as I am aware.

>  Secondly, is there more
> documentation available anywhere?  I'm very interested in answering some
> of the questions that are supposedly answerable, as mentioned in the
> readme.  I'll keep plugging away, no worries...

I am working on a generic scan detection tool based on the offlie 
processing of argus logs.  The aim is to detect 'scans' where the event 
rate is down about two or three events a day.  I have the detection and 
reporting stuff finished now and had it running for several months on 
our DMZ and, yes, it has detected activity that our other tools has 
missed without over burdening one with false hits.

Here is what it put in my mailbox this morning.  It shows a machine 
probing ftp control ports in one of our subnets --  hmmm funny how many 
of the machines we get probes from don't have PTR records for the 
addresses:

 [ xxx.yyy.168.239] -- hosts 39, times 8
	** 1999.02.11.19.00. **
		   130.216.5.151.21
	** 1999.02.11.18.00. **
		   130.216.5.138-142.21
		   130.216.5.144.21
	** 1999.02.11.17.00. **
		   130.216.5.131-136.21
	** 1999.02.11.16.00. **
		   130.216.5.123.21
		   130.216.5.129.21
	** 1999.02.11.15.00. **
		   130.216.5.113-114.21
		   130.216.5.117-119.21
		   130.216.5.121-122.21
	** 1999.02.11.14.00. **
		    130.216.5.77.21
		    130.216.5.79.21
		    130.216.5.89.21
		   130.216.5.105-106.21
	** 1999.02.11.13.00. **
		    130.216.5.29.21
		    130.216.5.51.21
		    130.216.5.59.21
		    130.216.5.61.21
		    130.216.5.67-69.21
		    130.216.5.73-74.21
	** 1999.02.11.12.00. **
		     130.216.5.3.21
		    130.216.5.11.21
		   130.216.5.254.21

I will now use ra to print all traffic for this address for yesterday 
and decide what should be done about it.

This tool is currently written in perl and maintians an external 
history file to remember past events between runs.  After a bit more 
tweaking I will be very happy to release it to the list.  Long term it 
would be possible and possibly desirable to rewrite the tool in C in 
the 'classic' style, all that would be necessary is a good hash table 
implementation and some trivial code to dump/restore it to/from disk.

What I need to do now is sharpen up my ra filters to catch more 
'suspicious events'.

Here is what I use now:

my $filter =  'not est and tcp and \(not \(port 80 or port 113 or port 
25\)\) and \(not src net 130.216\)';

Basically I am looking at tcp streams orginating from outside our net 
(130.216) that did not get established.  I had to exclude ports 80, 25 
and 113 because there is too much noise.

This is clearly inadequate for a real system and I would welcome 
suggestions.

As this stands it does not detect half open scans because the source 
address is always local so I need a way of detecting tcp streams that 
consist of a single syn/ack packet -- i am working on sumarized files.

Here is a more complete version:

 ( tcp and 'lone syn/ack' ) or 
 ( (not src net 130.216) and 
   not est and 
   ( (tcp and (not (port 80 or port 113 or port 25))) or
     (udp and (not (port.........)))
   )
 )

If somone can fill in the 'lone syn/ack'. 

I need to test (in C)  ! status & SAW_SYN && status & SAW_SYN_SENT but 
it isnt obvious how to do this in a tcpdump filter.

> 
> The output, while it seems very useful, appears to be a little confusing
> to me as well.  The (sd) I have assumed so far, stands for standard
> deviation? Is that correct.  Secondly, what "seconds" are those?
> milliseconds?  If so, then life is much better already...

Hmmm... not at all sure what you are asking here.  Which client output 
are you taking about?

Cheers, Russell.