|
Hi Joe,
Joseph Mack wrote:
Here's a posting in ./ to an article about DoS attacks on hash functions.
http://slashdot.org/article.pl?sid=03/05/31/2157254&mode=thread&tid=126&tid=172
Old news ;). Check out the following thread (actually they discuss two things):
http://marc.theaimsgroup.com/?l=linux-net&m=105325042601829&w=2
is LVS susceptible to this sort of attack on the connection hash table?
Yes, under the constraints of the attacks realm, meaning that almost every
deficiency showing up in the vanilla kernel is highly likely to hit a kernel
patched with LVS too. In this case it's the input routing cache.
I would imagine that the client only has a small number of variables (the
port they are sending from?), the others being fixed (CIP, VIP:port).
and probably can't mount much of an attack even if they can choose the
ports at the clients end.
Ohh, now I understand! Interesting qustion, indeed. I would need to go back and
check with the code (could be another week or so) unless someone beats me to it.
Theoretically we're susceptible to this sort of attack, yes. Check out the
devastating effects on running Julian's testlvs with certain parameters.
However, I think you need to fill up the LVS connection bucket a lot to have a
remarkable DoS on table lookups. Wensong, Julian and me once tested a couple
case scenarios but actually never measured the performance impact on the linked
list chain length.
You can still enable tcp defence strategies of LVS though :).
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
