detail vs 'summary' mode

[Carter Bullard]

Hey Russell,
I found the problem, and the fix is now in argus().  I've
also made some some very minor improvements to ra()
that will make the ICMP reporting a bit better.

There are two problems.

The detail records that report that they saw only
1 packet are in error.  ra() is to blame, but the logic
is in argus().  Fixed.

The other problem is that the UNK protocol packets from
and to the same hosts, may have been erroneously
aggregated into the ECO flow.  I'm only speculating here
but I removed a potential ICMP hashing problem, so that
may affect your situation.

I have made the changes to 1.8 code.  Would you like for
me to send you this pre-alpha stuff with the fixes?

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.