|
Hello,
Many hits, but I think this is the relevant one:
http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1029.html
I remember that one, and the wrong documention in the kernel is still
not fixed :).
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.
Correct.
FYI: Certain _very_ expensive hardware load balancers do have enough RAM
and CPU power to keep a couple millions of packets in TCP/SYN state for
a defined amount of time. The pre-processing unit puts the packets into
different queues and decreases their lifetime expectancy according to
the difference of incoming SYN request and SYN/ACK reply from the
server. Every time interval the packets get re-prioritised to the end of
the queue until they are dropped (in case the SYN/ACK never came).
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.
Well, there's always QoS and iptables --limit as alternatives.
So, I guess I agree that you aren't stopping it, but if you reduce or
eliminate its effects, that is probably good enough.
Depending on your needs, yes.
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
:) Been there done that too, 6 years ago.
(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
At least the sales department was fit!
limitation was solved by front-ending them with proxy servers using SYN
cookies.
Nowadays hardware load balancers can handle most of the DoS pretty well
but this still doesn't make them any bit interesting to me.
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
|
