Still problems with ra -A (and tcp smurf logs)

[Carter Bullard]

Hey Russell,
  Yes I have fixed this in the mythical "F" release,
which I hope to have out tomorrow.  Sorry for the delay!!!!

What is the "_" notation at the of your records?
Am I doing that or are you ;o)

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Russell Fulton
Sent: Monday, December 04, 2000 7:47 PM
To: argus at lists.andrew.cmu.edu
Subject: Still problems with ra -A (and tcp smurf logs)


I am still getting the occasional screwy count with -A.  In this case
everything was fine except for the 255.255.255.255 records.


bash-2.04$ bin/ra -Zb -ncr data/2000.12.04/argus-2000.12.04.21.00.gz - host
216.93.65.65 | grep 255.255
04 Dec 00 20:55:49.851285   tcp 255.255.255.255.80     o>
216.93.65.65.38971 192      0         12288        0           RA_
04 Dec 00 20:55:48.705615   tcp 255.255.255.255.80     o>
216.93.65.65.46588 246      0         15744        0           RA_
04 Dec 00 20:55:47.292610   tcp 255.255.255.255.80     o>
216.93.65.65.46587 764      0         48896        0           RA_
04 Dec 00 20:55:48.511802   tcp 255.255.255.255.80     o>
216.93.65.65.38970 768      0         49152        0           RA_
bash-2.04$ bin/ra -AZb -ncr data/2000.12.04/argus-2000.12.04.21.00.gz - host
216.93.65.65 | grep 255.255
04 Dec 00 20:55:49.851285   tcp 255.255.255.255.80     o>
216.93.65.65.38971 192      0         0            -162525840  RA_
04 Dec 00 20:55:48.705615   tcp 255.255.255.255.80     o>
216.93.65.65.46588 246      0         0            -324525512  RA_
04 Dec 00 20:55:47.292610   tcp 255.255.255.255.80     o>
216.93.65.65.46587 764      0         0            -1983371664 RA_
04 Dec 00 20:55:48.511802   tcp 255.255.255.255.80     o>
216.93.65.65.38970 768      0         0            1492133488  RA_


In case any of you are wondering what provoked this weird traffic, it
resulted from a tcp scan (ACK to port 80) directed against
130.216.*.255.  Some sort of tcp smurf?

Here is a sample of the triggering traffic:

04 Dec 00 20:56:01.574232   tcp    216.93.65.65.38971  o>
130.216.202.255.80    1        0         64           0           A_
04 Dec 00 20:56:01.577682   tcp    216.93.65.65.38971  o>
130.216.203.255.80    1        0         64           0           A_
04 Dec 00 20:56:01.578219   tcp    216.93.65.65.38971  o>
130.216.204.255.80    1        0         64           0           A_
04 Dec 00 20:56:01.579589   tcp    216.93.65.65.38971  o>
130.216.205.255.80    1        0         64           0           A_
04 Dec 00 20:56:01.581133   tcp    216.93.65.65.38971  o>
130.216.206.255.80    1        0         64           0           A_
04 Dec 00 20:56:01.583455   tcp    216.93.65.65.38971  o>
130.216.235.255.80    1        0         64           0           A_

I'm picking that 216.93.65.65 is the victim not the perpetrator.
Looks like its time to block *.255 for tcp (I thought we alread did but
obviously not :( ) as well as udp and icmp.

Anyone know why responding packets have source of all 1s?
A few machines did respond with their own source addresses.

Cheers, Russell.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20001205/47ad527b/attachment.html>