detail vs 'summary' mode

[Carter Bullard]

Hey Russell,
   I would agree with you that I think that the
detail is more believable that the summary ICMP
records, but my question is, "is the problem in
argus() or in ra()?".

   The difference between detail and summary
modes of operation, with regard to ICMP, are that
in detail mode, each ICMP packet generates an
argus() record.  In summary mode, argus() processes
ICMP packets using the same connection oriented model
that it uses for all IP traffic.  So, ...., summary
mode for ICMP is much more complicated, and both
argus() and ra() are involved in the complicatedness.

There are two types of ICMP flows, informational and error.
Pings fall into the informational family, which all have a
request/response protocol structure.  The types of ICMP
packets that are informational are echo (ping), timestamp,
address mask and information.  For each of these types of
ICMP packets there are response packets.

In argus(), requests and responses are hashed together so
that we can report on the IP/ICMP informational flow.  So
we end up playing some games in trying to understand who is
the source and who is the destination.  Argus() doesn't
really care, ra() cares quite a bit, as its trying to do a
consistent thing with its output.

I suspect that the logic for doing all the field overloading
that we do in order to handle the flow model for ICMP ping
flows has a little bug in it.  But, like I said, who has the
bug.  My guess is that ra() is having the most problems, but
thats just my guess.

Russell, could you send me an argus() output file that has
the ICMP reports that are funky?  I'll take a look at them.

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.