LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: anti-DOS techniques?

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: anti-DOS techniques?
From: Roberto Nibali <ratz@xxxxxxxxxxxx>
Date: Mon, 01 Dec 2003 22:46:33 +0100
Hi,

We're using the RedHat AS 2.1 version of LVS.  I'm not sure exactly what
the differences are, but Red Hat didn't have any answers for what we'd
like to do.

We can try ...

I know that iptables can block connections if they exceed a specified
number of connections per second (from anywhere).

Which is a very bad practice approach to handle such problems.

The question is, is
anybody doing this on a per-client basis, so that if any particular IP is
sending us more than a specified number of connections per second, they
get blocked but all other clients can keep going?

You have no information if the IP which is making those request attempts at a high rate is malicious or friendly. If it's malicious (IP spoofing) you probably block an existing friendly IP.

We occasionally (several times per week) experience what can only be
described as a traffic storm, or DOS attack.  LVS handles it just fine,
but the web-servers get loaded up really bad, and pretty soon our site is
all but un-usable.

Could you describe your overloaded system with some metrics or could you determine the upper connection threshold where your RS are still working fine?

Also looking for tools we could use to analyze this
(we use Webalizer for our web-logs-- but it can't tell us who's talking to
us in any given time-frame...)

You could dump the LVS masquerading table from time to time and grep for connection templates.

Thanks in advance for any words of wisdom...  :-)

I'll try, although my words are never of any deeper wisdom ;).

I see 4 approaches (in no particular order) to this problem:

A. LVS tcp defense mechanism, best described in [1].
B. L7 load balancer which inspects HTTP content, best described in [2]
   or in the package Readme.
C. Use of the per RS threshold limitation patch I wrote [3].
D. Use the feedbackd [4] architecture to signal the director of network
   anomalies based on certain metrics gained on the RSs.

[1] http://www.linux-vs.org/docs/defense.html
[2] http://www.linux-vs.org/software/ktcpvs/ktcpvs.html
[3] http://marc.theaimsgroup.com/?l=linux-virtual-server&m=105914647925320&w=2
[4] http://www.redfishsoftware.com.au/projects/feedbackd/

When I get more time I can list the advantages and disadvantages to all those approaches. I reckon you've got some material to read through and maybe meanwhile someone beats me to it ;).

Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

<Prev in Thread] Current Thread [Next in Thread>