|
Roberto Nibali wrote:
Hi,
My conception is, human usually do not eshtablish SYN connection as
more as Nimda or other worms, if I can determine a threshold of
simultenious SYN connection that nimda usually creates, probably I
will be able to drop packets from specific source IP which meet the
threshold. There is chance of false positive - I agree.
Another risk is if the attackers are forging their source IP
addresses. I don't think your threshhold approach would work in this
case.
Have you heard of SYNCookies? http://cr.yp.to/syncookies.html
I think that should stop any SYN flood type of Denial of Service
attack, and also should allow all legitimate traffic to get through.
Search google using my name and syncookies for more information on why
syn cookies have no measurable impact on reducing real DoS.
Many hits, but I think this is the relevant one:
http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1029.html
And I think the relevant snippet is:
--- snip ----
> I don't think these statements are entirely true. While it is true that
> you can't use things like window scaling or SACK - syncookies 100%
> successfully stop syn flood attacks.
Someone needs to adjust the text then.
> The attack is that if you fill the syn backlog queue with bogus requests
> then legitimate clients can no longer connect. The syn flood attack
> isn't "your legitimate connections wont be able to use window scaling".
I completely agree with this definition of SYN flooding and then I will
also say that you can 'stop' SYN flooding, well, at least you give
legitimate clients a real chance to still successfully connect to your
service, while it is under a SYN flood. I think we agree now. It should
only be remarked that the line is still flooded, thus the wording "100
stop SYN flood" is simply inappropriate in my eyes. It's all a matter of
definition.
Regards,
Roberto Nibali, ratz
--- snip ---
My points were these:
1) Trying to find out who is sending too many SYNs will be very tough (I
think that was the idea in the first paragraph of this email). On the
one hand, you have mega-proxies, which might be sending more SYNs than
other legitimate source IPs. On the other hand, a SYN flood attacker
might just forge the source IPs, so finding the 'bad source' won't work.
2) You aren't really stopping the attack, you are limiting the resource
draining effects of it so that your server can still respond to
legitimate requests. I assume that for the attacker it is much less
gratifying to see the site has slowed down instead of stopped responding
altogether. In that regard, I find SYN cookies the only way to go.
So, I guess I agree that you aren't stopping it, but if you reduce or
eliminate its effects, that is probably good enough.
BTW, this is one of the reasons I subscribed to this list: I got tired
of special h/w vendors telling me how 'fast' their box is, only to find
that it could be rendered useless by a simple attack. One vendor said
(when their firewall was rebooting every few minutes during a SYN flood
attack) that they technically were functioning as designed, since they
were protecting my real servers from these bad packets! Their
limitation was solved by front-ending them with proxy servers using SYN
cookies.
Thanks,
dj
|
