Slashdot Mirror
New Apache Module For Fending Off DoS Attacks
Network Dweebs Corporation writes "A new Apache DoS mod, called mod_dosevasive (short for dos evasive maneuvers) is now available for Apache 1.3. This new module gives Apache the ability to deny (403) web page retrieval from clients requesting more than one or two pages per second, and helps protect bandwidth and system resources in the event of a single-system or distributed request-based DoS attack. This freely distributable, open-source mod can be found at http://www.networkdweebs.com/stuff/security.html"
Handling all of those requests still takes processing time and bandwidth. What is needed is some type of hardware "filter" out front that can recognize a DoS attack and throw packets away.
"Send an Instant Karma to me" - Yes
Does anyone know how clever it is? There are several things that I suppose
you could do to make sure that this doesn't get in the way of normal browsing, but still catches DOS attacks. What sort of things does this module include to work intelligently? How tunable is it?
One thing that jumps to mind is that you could have some kind of ratio between images and html which has to be adhered to for any x second period. This would hopefully mean that going to webpages with lots of images (which are all requested really quickly) wouldn't cause any problems. Also, more than one request can be made in a single http session (I think - I don't really know anything about this) so I guess you could make use of that to assess whether the traffic fitted the normal profile of a websurfer for that particular site.
Also, is there anything you can do to ensure that several people behind a NATing firewall all surfing to the same site don't trip the anti-DOS features?
Just thinking while I type really...
On the securityfocus incidents list, there was a guy that ran a little web site that was being DoSed by a competitor in a strange way. The much higher traffic competitor had a bunch of 1 pixel by 1 pixel frames and each one loaded a copy of the little guy's site. The effect was he was using his own users to DoS his competition.
People suggessted a javascript popup telling them the truth about what was going on, or an HTTP redirect to a very large file on the big guy's site, but Jonathan A. Zdziarski at the site linked above decided to write this patch as an ad-hoc solution.
I'd be very careful with this patch in production, as it is ad-hoc and not tested very much at all.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
"This new module gives Apache the ability to deny (403) web page retrieval from clients requesting more than one or two pages per second."
I can easily request a couple of pages a second, if i'm spawning off links to read in the background. On the other hand wouldnt an automated attack be requesting much faster than 2 per second?
no sig.
I'm sure they've thought of this, but will this affect frame pages where the browser requests multiple pages at the same time? How about scripting and stylesheet includes which are made as seperate requests, usually right on the heels of the original page? I hope they've handled this. It seems like the number should be set higher. Maybe 10 requests a second is a better point. That's probably adjustable though. I suppose I should RTFM.
THIS SPACE FOR RENT
Hi there,
Just wanted to clear up a bit of misunderstanding about this module. First off, please forgive me for screwing up the story submission. What it *should* have said was "...This new module gives Apache the ability to deny (403) web page retrieval from clients requesting THE SAME FILES more than once or twice per second...". That's the way this tool works; if you request the same file more than once or twice per second, it adds you to a blacklist which prevents you from getting any web pages for 10 seconds; if you try and request more pages, it adds to that 10 seconds.
Second, I'd like to address the idea that we designed this as the "ultimate solution to DoSes". This tool should help in the event of your average DoS attack, however to be successful in heavy distributed attacks, you'll need to have an infrastructure capable of handling such an attack. A web server can only handle so many 403's before it'll stop servicing valid requests (but the # of 403's it can handle as opposed to web page or script retrievals is greater). It's our hope that anyone serious enough about circumventing a DoS attack will also have a distributed model and decentralized content, along with a network built for resisting DoS attacks.
This tool is not only useful for providing some initial frontline defense, but can (should) also be adapted to talk directly to a company's border routers or firewalls so that the blacklisted IPs can be handled before any more requests get to the server; e.g. it's a great detection tool for web-based DoS attacks.
Anyhow, please enjoy the tool, and I'd be very interested in hearing what kind of private adaptations people have made to it to talk to other requipment on the network.
There are many different types of DoS attacks, and the kind you're describing have other methods of circumvention. The type of DoS this module was designed to fight/detect was a request-based attack where a website was flooded with requests to increase bandwidth and system load.
This was exactly what I was thinking. How is this going to affect w3mir, WebWhacker (on Windows and Mac), or WebDevil (on Mac)?
I'm not sure how this is any different than the feature of mod_bandwidth that limits the number of requests per user per second. I'm definately going to test it out it's unclear how this is any different, except that it doesn't have all the other overhead functionality of mod_bandwidth.
--CTH
--Got Lists? | Top 95 Star Wars Line
Run a wget -r type of attack (only dump the resulting files into /dev/null). This module would seem to have no effect.
my old sig used to be funny, but then slashcode ate it and now it's not funny anymore
To stop a non-bandwidth bogus-request attack, you just turn on syncookies and that's that. This module is designed to stop a different kind of attack, wherein the clients are completing entire transactions too many times and thus consuming your bandwidth. There are other types of DOS attacks too -- reflection attacks (where you get a ton of ACK packets from all over the internet, using up all your bandwidth), for example, have to be stopped at the router level upstream, which prevents the server from completing any transactions as a client (over the internet; it can still get through over the LAN, of course).
Cut that out, or I will ship you to Norilsk in a box.
I work as tech support for a webhosting company. I see things like this all the time. People tend to think its impossible to block because its not from any one specific ip address, but the requests are coming from all over. People need to learn the awesome power of mod_rewrite.
/* - [F]
RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http://(.+\.)*bigguysite.com/ [NC]
RewriteRule
I've also seen people who had bad domain names pointed at their ips, where you can check the HTTP_HOST. I've seen recursive download programs totally crush webservers, mod_rewrite can check the HTTP_USER_AGENT for that. Of course, download programs could always change the specified user agent, which is I guess where this apache module could come in handy. Good idea..
If you design web sites pay attention.
So many designers that I ran into in my travels, still don't understand, that when you put Flash animations (Which I can't stand 99% of the time), large png files, or complex front pages, especially public pages, you increase you bandwidth costs.
Seems very simple to most. I am still surprised how many companies redesign sites, with gaudy graphics all over the place, and then find ALL OF A SUDDEN after deployment thier website goes down.
I can remember many customers I use to deal with, that had fixed contracts for hosting, yet they maintained thier own content, calling up and claiming our server was slow, and or down/experiencing technical difficulties.
I would usually say: "OH REALLY, I don't see any problems with the server per se. Did you happen to modify anything lately on the site?"
"Yes" they would reply: "We just put a flash movie movie on the front page..."
Immediately I knew what the problem is, they blew thier bandwidth budget. At times I would see companies quadruple the size of thier front pages, which reduces by about a quarter the number of users they can support at quality page download times. Especially if they are close to thier bandwidth limit as IS without the new pages.
The bigger the pages, the better the DOS or the easier the DOS is too perform.
In my design philosophy for my companies site, you can't get access to big pages without signing in first. If you sign in a zillion times at one or more pages, obviously that isn't normal behavior, and the software on my site is intelligent enough to figure that pout and disables the login, which then points you to a 2K Error page.
In any case, if you are trying to protect your website and you don't want to resort to highly technical and esoteric methods, to minimize DOS attacks. You might want to start with the design of the website content.
The lighter the weight of the pages, the harder it is for an individual to amass enough machines to prevent legitimate users from using your site.
IMHO, Flash plugins, and applets and other such features should be available only to registered users, and logins strictly controlled.
Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.