detail vs 'summary' mode

[Carter Bullard]

Hey Russell,
   Oh yeah, I forgot to mention that I think in your attack
someone is trying to tickle a kernel bug where they are
sending invalid ICMP packets at the kernel (ICMP type value
greater than 18).  We can tell which types are being used
from the detail argus() output.  We may be able to do it even
in the summary, but I'll need to see the actual argus records.

Hope all is well,

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.