Re: help identifying packets from attack

[Matt Kettler <mkettler () evi-inc com>]

At very causal glance, I'd agree, it would appear to be a syn flood with 
spoofed source addresses. I suspect the sources as being spoofed due to the 
reserved 127/8 range being used as a source. Although it appears the 
attempt was to cause a synflood, it was also effective as a conventional 
flood of your link. (synfloods are not normally intended saturate your 
line, just tie up all the socket handles your server has).

When it really comes down to it, there is *no* defense against any kind of 
"my link is saturated" type attacks that you can do locally. Your upstream 
provider has to handle it, or you need to ride it out. Lets face it, if 
your link is saturated, your router can be the most efficient packet 
dropper on earth and it won't do you a damn bit of good. (as you already 
noticed)

Now a "normal" synflood doesn't have to be high bandwidth, but since your 
link is only 256k it was easily overwhelmed. Synfloods work even when you 
can't saturate the link of a target (ie: they have >45mbit/sec), but it is 
possible to defend against their effects on your servers locally ( you 
still can't defend against your link being saturated, should that happen). 
What you did would have worked, if your link didn't saturate.

A server has a finite amount of memory, and needs to use some memory to 
track the state of each of the connections it has to other machines. 
Generally TCP stacks have other limits on the total connections, but even 
if they could use all the ram in your system for connection tables, there's 
still an upper limit to the number of simultaneous connections. A synflood 
works by starting to initiate hundreds of thousands of connections, but not 
answering the response back, leaving the connections "half open" and it 
will take a while to time out in that state. In the meantime, nobody else 
can access that server, since all the socket handles on it are tied up. The 
attacker can keep the server unavailable indefinitely by continuing to send 
syn's.

Local defenses against synfloods include using tcp/ip stacks that implement 
syn-cookies on your servers, and old fashioned packet filtering with a 
router. AFAIK, most linux/*bsd systems can be configured to use 
syn-cookies, but you'll have to read up on that for your particular variant.


At 08:39 PM 9/1/2002 -0500, Ing. Daniel Manrique wrote:
> 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).



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users