I would think that you would wish to serve that requests? Getting another server (even if temporary, for instance Amazon EC2) might be a better idea than turning down legitimate visitors. IMHO, of course.
Willy: thanks for the explanation on tactics below! Ever thought of writing a book on the subject? I don't mean haproxy configuration but its possible deployments, common setups,... Anze On Tuesday 16 March 2010, Mikołaj Radzewicz wrote: > Hmm, it is little not what I thought... We have DDoS due to our links > are put on high load site. I wanted to check referrers dynamical and > then block them (with the highest rate). > Maybe is it possible to limit the session based on host? > > On Tue, Mar 16, 2010 at 6:08 AM, Willy Tarreau <[email protected]> wrote: > > Hi, > > > > On Mon, Mar 15, 2010 at 07:54:19PM +0100, Miko?aj Radzewicz wrote: > >> Dear Sir, > >> I have been using haproxy for a couple of weeks in some basic > >> configuration. Since 2 weeks we have been suffering from some DoS > >> attacks to our web servers which made them causes 500 due to extreamly > >> high number of connections. All of them are caused through the > >> referers - links(urls) to our web servers are put on very load pages > >> causing run out of pool of connection on our web servers. Is it some > >> way to protect our infrastructur using haproxy? Are you planning to > >> add sth like that in the future? > > > > The first thing you must do is to set a "maxconn" value on each "server" > > line in haproxy's config to limit the number of concurrent connections > > per server to a level the server can sustain. This will ensure that your > > servers are not saturated anymore. The second thing is to correctly > > configure your various timeouts so that you don't needlessly keep a > > lot of connections on haproxy or your servers when you suppose that > > the client might already have gone. For instance, a client will not > > wait more than 30-40 seconds for something that does not seem to come, > > so let's have your server timeout and queue timeout at these levels. > > You must also set "option abortonclose" so that each connection aborted > > while the request is still in the queue will not be sent to a server. > > > > Then if you know what to identify in the requests, you can eliminate > > them or "tarpit" them, which consists in keeping the connection open > > for some predefined time to slow down the attacker. But since what you > > describe looks more like normal browsers, maybe a drop will be enough. > > If you can identify a set of referrers, you can block on that. You can > > even redirect the request to the site holding the referrer. Probably > > that they'll check their page and fix it quickly after detecting the > > higher load ! For instance : > > > > acl from_site1 hdr_beg(referer) http://site1.dom/ > > redirect location http://site1.dom/ if from_site1 > > ... > > > > Regards, > > Willy >
