detail vs 'summary' mode

[Carter Bullard]

Hey Russell,
   OK, so I'm a little unconscience this morning.
I was wrong about how argus handles ICMP packets
differently between detail and summary.  I was 
confusing the -C flag which is detail for ICMP,
and the -d flag, which is detail for the argus()
flow model.  My mistake.

   The real truth is that when you use the -d flag,
you get a report when argus encounters the very first
ICMP packet in a flow, rather than waiting to report
the existence of the ICMP flow until the IP timer
for the flow has expired.

   Now ra() treats the first report differently than
all the other reports that are seen on a persistent
flow, and so I still think that ra() is the primary
culprit.

Still hope this is helping, and still would like to
see the argus() output.

Carter



-----Original Message-----
From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
Sent: Monday, April 26, 1999 12:17 AM
To: argus at lists.andrew.cmu.edu
Subject: detail vs 'summary' mode


HI,
	This message is both a bug report and an invitation to comment
on some strange traffic...

I run two argus servers on our DMZ, one in detail (argus -d 60 -i eth0
-w current) mode and one in summary mode (argus -i eth0 -w current).
Both on i-386 linux boxes.

I have noticed some differences in the output of the two systems.  For
example we recently received an appearent DOS attack involving large
amounts of garbage icmp packets targeted at one of our systems.  The
packets had random source addresses.

I used ra to extract all traffic for the target machine ccu1 (130.216.3.1)
on both systems running argus:  I'll call them detail and summary.

Having done this I use grep to extract data for particular source addresses:

[argus at k-meter argus]$ grep 203.55.99.235 ccu1.detail.24th 
Sat 04/24 18:36:07     icmp     130.216.3.1       <-    203.55.99.235       0      1                          ECR
Sat 04/24 18:36:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK
Sat 04/24 18:37:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK
Sat 04/24 18:38:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK
Sat 04/24 18:39:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK
Sat 04/24 18:40:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK
Sat 04/24 18:41:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK
Sat 04/24 18:42:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK
Sat 04/24 18:43:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK
Sat 04/24 18:44:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK
Sat 04/24 18:45:07     icmp   203.55.99.235        ->     130.216.3.1       1      0                          UNK

[argus at ruru argus]$ grep 203.55.99.235 ccu1.ordinary.24th 
Sat 24/04 18:36:07     icmp     130.216.3.1        ->   203.55.99.235       334    0                          ECR
Sat 24/04 18:42:08     icmp     130.216.3.1        ->   203.55.99.235       137    0                          ECR

As the above greps show the two systems tell very different stories.
I am inclinded to believe the detail file (our inbound traffic shows a
huge peak at this time -- that's what lead me to examine the logs in
the first place). i.e. that the packets are coming in with forged
source addresses.  There are 10 packets from each address I have
looked at, Always starting with an ECR (type 0) but some have things
other than UNK on the other 9.  Looks like there is always a type 0
then 9 packets with random type field.

The summary file suggest that the ECR packets are far more numerous
and out going!

A quick squint at the ra source shows:

         case ICMP_ECHOREPLY:
            rev = 1;
            break;

and this combined with the code in the server that collapes the ICMP
traffic stream seems to result in erroneous reporting. (Or maybe the
garbage in the packet somehow affected argus).

Anyone seen this sort of attack before?  This is (at least) the second
time this particular machine has been targeted.  Last time was just
over a week ago -- also in the weekend.

Cheers, Russell.