[Snort-users] re: help identifying packets from attack (ing. Daniel Manrique)

Charles Hanby fixer at ...6598...
Mon Sep 2 11:53:12 EDT 2002


Ow.  Not a fun Sunday. It appears ( to my mind, at least) that you've 
correctly identified what was happening as a SYN flood.  I'm basing 
this on the following (Note that I in no way way hold myself out to be 
an expert in sig analysis, so take this one for what its worth):

09/01-18:34:51.523402 0:10:7B:BA:AA:F0 -> 0:60:8:C2:31:A0 type:0x800 
len:0x3C
127.13.73.170:60921 -> x.x.x.x:41506 TCP TTL:235 TOS:0x0 ID:48936 
IpLen:20 DgmLen:40 DF
******S* Seq: 0x0  Ack: 0x37075D9A  Win: 0xB81A  TcpLen: 20

- The source IP address (127 octet, which is reserved for loopback, 
thus obviously forged)
- The fact that the desination ports "varied wildly" appears to be an 
attempt to overload the router rules (it harkens back to the CNN DoS 
attack in 1999 when the attacker flooded the router using ports 1-200 
as his attack ports of choice).
- And, of course, the SYN flag, is an obvious marker for a SYN flood.
- This all adds up to me to be a case of a SYN flood DoS attack using 
a spoofed source address.  By using the loopback as the source 
address, the victim computer will basically attempt to make all 
connections with itself...or at least that was the idea behind the 
attempt.

As for a solution, I'm not an expert on rulesets, so I'd suggest 
firing off a question to sigs forum and see if they have any 
suggestions.  If you want a really good book on the subject, I'd 
recommed Intrusion Signatures and Analysis, by Stephen Northcutt et 
al.  Happy Hunting.


Charles Hamby



Original Message Below


Hey!

What a great sunday it was, my network suffered a brutal attack that 
left 
us basically disconnected for the better part of 2 hours (well, 80% 
packet 
loss meant any attempts to contact the outside world were pretty 
futile).

the attack consisted of packets coming from a bunch of different IP
addresses, all targeted at the same IP address within my network (a
customer's server). Now, while the server itself managed to stay
responsive, the sheer amount of packets completely saturated our puny 
256k
internet link and had the router's CPU working at 50% capacity (normal
range is below 5%). The link's saturation continued even after I 
blocked
traffic to the affected host at our main router; obviously, since even 
though the router was denying packets, they still had to travel down 
the 
link to reach the router and be denied; and the router denied close to 
a 
million packets in the last 20 minutes of the attack.

Of course, during all this, before the router rules were in place, 
snort
found some strange packets (originating from loopback reserved 
addresses?)
and logged them. My IDS sits on the same LAN segment as the router's
ethernet interface and the victimized server's main ethernet interface.
They look like this (x.x.x.x stands for the targeted server's IP 
address,
everything else is unchanged):

09/01-18:34:51.447719 0:10:7B:BA:AA:F0 -> 0:60:8:C2:31:A0 type:0x800 
len:0x3C
127.56.80.150:6638 -> x.x.x.x:41260 TCP TTL:235 TOS:0x0 ID:48690 
IpLen:20 DgmLen:40 DF
******S* Seq: 0x0  Ack: 0x4D52D622  Win: 0x62  TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+

09/01-18:34:51.523402 0:10:7B:BA:AA:F0 -> 0:60:8:C2:31:A0 type:0x800 
len:0x3C
127.13.73.170:60921 -> x.x.x.x:41506 TCP TTL:235 TOS:0x0 ID:48936 
IpLen:20 DgmLen:40 DF
******S* Seq: 0x0  Ack: 0x37075D9A  Win: 0xB81A  TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+

They came from many many different addresses, and both origin and 
destination ports also varied wildly.

Apparently they have no payload, only control information, and I'm
guessing the ******S* thing means something about SYN, which makes me
initially think it was a syn flood attack. However, that's as far as my
analysis skills go, and they might even be wrong; and I'd really like 
to
know more about this, so that I can, hopefully, do something to prevent
it.

So, I'd appreciate help interpreting these packets, identifying what 
kind 
of attack they belong to, and finding more information on how to 
stop/prevent/detect the situation more accurately. Snort was helpful, 
however apparently it had no way of knowing the packets were some sort 
of 
attack; it only logged them because it thought loopback traffic looked 
suspicious.

Thanks in advance for any/all help!


- Roadmaster






More information about the Snort-users mailing list