Argus scripts and docs

[Russell Fulton]

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.