Snort mailing list archives
Re: help identifying packets from attack
From: Matt Kettler <mkettler () evi-inc com>
Date: Mon, 02 Sep 2002 14:06:30 -0400
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
Current thread:
- help identifying packets from attack Ing. Daniel Manrique (Sep 01)
- Re: help identifying packets from attack Matt Kettler (Sep 02)