[Snort-users] help identifying packets from attack
mkettler at ...4108...
Mon Sep 2 11:08:06 EDT 2002
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
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
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:
>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).
More information about the Snort-users