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.
Now, I am going to start off my admitting I have never taken any classes on TCP/IP and only have a user's level of understanding. Now I can see an attack by making a web server dump its data too you so often that it cant keep up w/ everyone else as being effective if it doesnt have any sort of client balancing, or whatever. But I thought that DoS proper involved looking at the connection at a lower level, where you would fill the TCP handler's queue with requests that would never get past a certain point, so the server would have a ton of socket connections waiting to be completed, handshaked, whatever happens (So many in fact that it's queue was completely full and could not even open a socket connection to any more users to even give the "403" error message.) Thats why it was called "Denial of Service" because valid clients would not even get a SLOW response from the server, they would get nothing because their TCP/IP connections would never even be opened. Isnt that right?
Why stick up for big business?
Remember these rules are instantiated on a per-listener basis, so you have to have not only the same IP requesting the same page but the same client, since just about any current browser has a keep-alive. So if three people hit the server simultaneously, they would get 3 different listeners. The only way it'd deny them is if it hit the server one-after-the-other after each client disconnected and if it happened to hit the same child. This is extremely unlikely.
oh..and that would have to happen within 1 second's time. Apache's keep-alive defaults to 15 seconds, so unless each browser is requesting a "Connection: close" it's going to be impossible.
A while back I wrote an Apache module similar to this one (mod_antihak), but it protected against CodeRed bandwidth consumption. It also had a slightly more brutal method of blocking offenders: ipchains :) There's inherant problems with this though, the 403 would be the way I would go too if I did it all again.
how's this going to affect my porn wgets?
From the GNU Wget help page:
Thus, you can still wget as many images as you want. You'll just have to speciy the -w option and (so you don't waste any online time) possibly read Slashdot while the image download proceeds.
Will I retire or break 10K?
How about just something with a referer check? If the referer is the other guy's site, do a: window.open("www.somedirtypornsite.com", _top);
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
is blocking anyone who requests NIMDA/CodeRed related URLs.
I currently use a scheme where I created the appropriate directories on my web document tree
(/scripts for example)
and then set up 'deny to all' rules for them.
This way, the apache server doesn't even bother with a filesystem seek to tell that the file isn't there it just denies it.
Dropping packets would be even better.
In the free world the media isn't government run; the government is media run.
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..
Perhaps one of these is needed to ward off the ... effect? I suppose it would be damn easy to do; it just needs to be in the config by default.
"I think it would be a good idea" Gandhi, on Western Civilisation
How is this a troll? Clueless, maybe.
You wonder about moderation? You must be new here
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.
If you're looking for an easy way to automate blocking at the border router, take a look at:
http://www.ipblocker.orgWith a simple command line call to a Perl script you can have the ACL on a Cisco router updated to deny traffic from the offending user.