|
Dear Dave,
> >> 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.
My objective was to protect Nimda hits in the cache servers (Transparent Proxy)
mainly. I enabled syncookies in the directors as well as in the 3 proxies,
simulated nimda from one W2K+IIS Pentium 4 PC, but found no positive effect at
all.
I believe that it can be filtered out in a very easy way, I am working on it
and will post in this mailing list after successfully done.
Faruk
----------------------------------------------------------
This mail sent through AIT WebMail : http://www.ait.ac.th/
|
