Are we all in risk?? Apache DoS global attack

Portal Home > Knowledgebase > Articles Database > Are we all in risk?? Apache DoS global attack

Posted by pedrojose, 06-19-2009, 11:23 PM
Hello all, I have just saw on leaseweb noc site that there has been a public release of a Apache DoS tool and all All versions of Apache are vulnerable. So can anyone confirm this and give some possible solution or advices? url: http://noc.leaseweb.com/status.php?i=353 --------------------------------------------------------------- Dear customer, There has been a public release of a Apache DoS tool. You can read about it on the following URL's http://isc.sans.org/diary.html?storyid=6601 http://ha.ckers.org/slowloris/ All versions of Apache are vulnerable. There are a couple of solutions, one of them is limitipconn http://dominia.org/djao/limitipconn2.html However we have found it does not work as it should on all distributions. We have put together a quick shell script that should give you protection in case your server is being attacked. It currently is a crude version, if you see it does not work on your server please contact our support and we will try and get it working for you. If you suspect your server is being attacked you can download the following to your linux webserver. This script does not work on BSD or windows. http://www.leaseweb.com/antiloris.sh Place the file in some directory and make it executable. # wget -O /usr/local/sbin/antiloris.sh http://www.leaseweb.com/antiloris.sh # chmod 755 /usr/local/sbin/antiloris.sh # echo "* * * * * /usr/local/sbin/antiloris.sh" >> /etc/crontab Then edit the file. In the beginning of the file there are a couple of variables: LIMIT=50 EMAILADDRESS=your-email@example.com SENDEMAIL=1 RESTARTAPACHE=1 LIMIT is used for the amount of sessions the attacker has to open before his IP address will be blocked. EMAILADDRESS is the email address you want to receive email alerts on SENDMAIL can be 1 or 0. Set to 0 to no longer receive email. RESTARTAPACHE This variable can restart apache after the IP address has been blocked. Some customers may not want to restart their apache after eac attack, but wait for regular apache time-outs. ---------------------------------------------------------------
Posted by UNIXy, 06-19-2009, 11:39 PM
Yes, the attack vector is real. Last edited by UNIXy; 06-19-2009 at 11:43 PM.
Posted by Steven, 06-20-2009, 01:19 AM
this really is nothing special. Ive seen this kind of attack for months.
Posted by mgphoto, 06-20-2009, 08:25 AM
http://ha.ckers.org/slowloris/
Posted by pedrojose, 06-20-2009, 09:09 AM
any solution or advices regarding how to do to keep our serve rsafe? patch/udates/etc...
Posted by 040Hosting, 06-20-2009, 09:41 AM
What is special about it is that anyone with a bit of knowledge can do this, which makes it special in its own kind of way.
Posted by alanzkorner, 06-20-2009, 11:07 AM
Whatever i was bit careful with the servers today.. Though i did not find any Ddos activity on any of them.. Alan
Posted by fog, 06-20-2009, 11:51 AM
I haven't had the time to test either of these, but I'm curious if anyone has, or if anyone has any thoughts: - I'm not an iptables whiz, but it looks like it's possible to limit the number of concurrent connections from a given IP. Wouldn't an iptables rule that dropped anything beyond 16 concurrent connections from a given IP keep this from having much effect without adversely impacting legitimate visitors? (Obviously, this is not helpful if the attack is originating from many computers simultaneously.) - squid is explicitly mentioned as vulnerable, and varnish seems to use the same model (threads, turning away after you hit max_threads), but haproxy does not appear to spawn threads like crazy and it references HTTP connection buffering like FreeBSD's accf_http does. I wonder if haproxy in front of Apache will limit the impact this can have, too? Not sure I'm going to get a chance to test either of these theories today; does anyone else have thoughts on whether these strategies would work or not?
Posted by jeev, 06-20-2009, 11:54 AM
kldload accf_data kldload accf_http apachectl restart that seems to fix it on my freebsd servers but maybe there is more to it. i've tested with and without and this prevents the connections
Posted by fwaggle, 06-20-2009, 10:39 PM
jeev: httpready is actually mentioned in the page about it, it deflects the default attacks but the attacking tool can be reconfigured to use the POST method which negates httpready.
Posted by jeev, 06-20-2009, 10:40 PM
yea, i wouldn't doubt it. i said i'm sure there is more to it.. at least this keeps some people away for a while
Posted by plumsauce, 06-20-2009, 11:21 PM
1 for IIS, any version
Posted by hostpc.com, 06-20-2009, 11:32 PM
http://www.theregister.co.uk/2009/06...ache_dos_flaw/
Posted by hostpc.com, 06-20-2009, 11:33 PM
Well, I guess Linux IS gaining market share, attacks aren't designed toward MS for a change /me ducks
Posted by jon-f, 06-21-2009, 12:17 AM
OMG, this is defintely nothing new. Apache has ALWAYS been vulnerable to simple connection flooding dos, they have never acknowledged it nor anyone treat it as an exploit. I always thought it was because it sure doesnt take much to knock one offline, even single ips can do it in some cases. Sure you can harden it with protections and firewalls but the exploit is still there and you will have a slowdown in the event of attack. Reasons I say its an exploit and always been: 1- takes very little connection flooding to do it 2 - no resource exhaustion, simply stops responding on the port. 3 - look at these latest devlopments But I disagree with the recent posts because I have seen visual basic made programs that do the same exact thing dating back to 2004 and earlier.
Posted by net, 06-21-2009, 12:34 AM
We tested it already and CSF will block this kind of attack. This is not new.
Posted by speckl, 06-21-2009, 12:36 AM
Yawn... Nothing new here. I get attacks all the time that are taken care of in a matter of seconds.
Posted by cywkevin, 06-21-2009, 02:15 AM
I'm more curious that the last update to http was back in 2008.
Posted by Nonya, 06-21-2009, 02:44 AM
which is exactly why we just went with CSF on all three dedis we have and are trying to use it on one VPS. Is there a newbie tutorial on configuring it, especially the portflooding feature? What other features either in iptables or CSF (or lfd, for that matter) can we maximize to protect our server and its contents? Thanks. Anya
Posted by AquariusStorage, 06-21-2009, 02:55 AM
CSF out of box owns this attack as long as its only coming from a single machine All you will need to do is enable it and make sure all modules are enabled.
Posted by fog, 06-21-2009, 11:42 AM
I toyed around with using SlowLoris to "attack" an in-house test server. It's surprisingly easy. I ran the Perl script and any attempts to load pages on the test server just timed out. Stopping the Perl script immediately brought everything back to normal. Out-of-the-box Apache is super-vulnerable, though. And I don't buy that load-balancers necessarily buy you anything. Many just round-robin TCP connections, and will merrily pass on the attack. Perhaps if one had persistent sessions it would limit the attack to one box. What does work well is haproxy. I changed Apache to listen on localhost:8080 only, and set up a pretty basic haproxy configuration to listen on *:80 with localhost:8080 as the only backend. Problem solved -- haproxy buffers the connections like BSD's accf_http does. I could see thousands of requests to haproxy with "Error" status, and a handful (me in a web browser testing) of successful ones. Load on the box was extremely minimal during the whole thing, haproxy or not. I'm curious what CSF does to protect against this. Is it just limiting the sudden flood of connections from one IP? I was unable to get iptables on CentOS 5.3 to work with connlimit due to what's apparently a long-standing bug.
Posted by Steven, 06-21-2009, 03:00 PM
Ha... CSF blocking the attack. it blocks the perl script version buttt You can easily attack apache in a manner that it takes it down within seconds with a simple flooder that was made in php. CSF won't have time to block it. Depending on the way the 'attack' is done, csf will provide you no protection. Last edited by Steven; 06-21-2009 at 03:03 PM.
Posted by Voltar, 06-21-2009, 09:50 PM
CSF's port flood protection will mitigate the attacks. I just posted the following over at cPanel's forums, did a little testing and research on both Linux and FreeBSD cPanel boxes. Last edited by Voltar; 06-21-2009 at 09:54 PM.
Posted by LoganNZ, 06-21-2009, 10:27 PM
Ive been monitoring this for some time now, its not a major vulnerability. Its an attack of which can be blocked/deferred.
Posted by jon-f, 06-22-2009, 12:29 AM
This portflood feature guys has max 100 entries. SO it will only work if you are getting a very small botnet attack under 100 ips. A single machine using this will be no problem to block but if you are using apache you could have it tweaked to the max and everything else, csf and all. If there is significant amount of ips hitting it it will go down. By all means though do what you can on the server level but if you start getting larger scale attacks you will have to get protection upstream from your network in addition to your server level protection in order to fight these attacks.
Posted by tathompson, 06-22-2009, 12:46 AM
The Internet Storm Center over at SANS has a great short article on the mitigation of the attack here: http://isc.sans.org/diary.html?storyid=6613 If you guys don't already, I highly recommend following their blog on a daily basis. They have done some very good analysis on this and other types of attacks that are *typically* overblown (Conflicker April 1 for instance). Really, it just depends on how you look at this one. Flooding is nothing new, but it could cause a lot of problems now that a tool is known to a broader community. Any idiot could cause a ton of problems, which is the main concern with this one. Serious attackers are going to use a real attack (something that would do damage) that would require a more sophisticated approach to the attack. This is dangerous because anyone could make it happen with zero knowledge of the server's setup.
Posted by rcbandit, 06-22-2009, 12:55 AM
What software for firewall big web hosting companies use to protect their clients? Could you tell me some of the best and efficient firewalls?
Posted by plumsauce, 06-22-2009, 04:01 AM
If you *must* stay on *nix, nginx is noted by the author as being not affected. Another option is IIS on Microsoft Windows Server, versions 5+, which the author also notes is not affected. The reason is that they both use event driven thread pools for i/o. In certain, IIS has always used IOCP's. Finally, the sans.org handler's diary suggests that the timeout directive is the best option thusfar. Then it goes on to say: Mitigating the published .pl script would not be a long term win if it depends on the signature. The *real* blackhats won't be long in designing signature evasion. Perhaps the only reason they haven't used this attack vector recently is that like all things, the new guys forgot history. Now, they have been reminded. It might also be that they have quietly used it as evidenced by postings on WHT about mysterious intermittent site failures without evidence of significant load. BTW, a possible enhancement to the published attack would be to decide on the cookie header as the interesting header. Use an 8K cookie, then feed it to the server at 10 bytes every 5 seconds. Do the same with the url itself. A 1K url would not be unreasonable with the fetish for long seo'd urls. Rinse and repeat. Hopefully, people who have quietly stuck with IIS despite being tarred and feathered in forums can now look forward to a few less barbs. Last edited by plumsauce; 06-22-2009 at 04:11 AM.
Posted by Baris, 06-22-2009, 10:22 AM
Once the kiddies find out about this, the fun will start
Posted by Johnny Cache, 06-22-2009, 03:55 PM
Just feel like throwing this out here for opinions. One of my cPanel boxes got a taste of this on Saturday. All of my http pids suddendly showed 9% - 14% %mem in top. Assuming I could have been vulnerable, I tried making a couple of adjustments in the Options Directive of my QA httpd.conf. Of course, this is going to depend on the admin vs. what his/her clients need. - Disabled IncludesNOEXEC - Disabled ExecCGI - Disabled MultiViews from mod_negotiation All of my httpd pids are back to 1.0 and 1.3. I'm only throwing it out there because it worked for me and the 40something domains on this specific machine all appear to function just as before the symptoms, of course, it depends too on your own clienteles' requirements. I've not had a single flood since I made this change.
Posted by Brook, 06-23-2009, 05:08 PM
I have high loads on my server at the mo, but when I restart apache they drop! Could we be a victim of one of these attacks? The other thing I have noticed is that one of my sites is getting more 'guests' than normal, over 200, when it usually only gets about 10 (it's a fairly new site). Which is why I think we're getting attacked. The IPs range from brazil to argentina, to USA, to poland - quite varied. We have CSF installed as well as a ddos script. But they don't seem to be helping. The server tech says we need to add more memory (currently on 2GB) but I'm suspicious of all these new 'guests' on that one site, esp as none of them seem to be signing up and quite a few of them getting error messages (for trying to reply to a thread when not logged in). Any ideas?
Posted by jeev, 06-23-2009, 05:13 PM
count how many connections from each ip ? i dont see the point of someone ddosing when it's easily capable enough coming from one server, i dont know.
Posted by 040Hosting, 06-23-2009, 05:15 PM
So the memory eh ? could you be so kind to show your TOP output (till the line where it says SWAP used), wondering what it says there. Did you check for any IP's which have an unusual lot of connections in use ? i.e. with something quick and dirty like:
Posted by hostpc.com, 06-23-2009, 05:44 PM
Are there any outdated, potentially compromised scripts on the server? For instance, Drupal, phpBB, Wordpress, Joomla etc? 2gb of memory should hold you through several hundred connections on a well maintained optimized machine.
Posted by bostjan, 06-23-2009, 08:35 PM
Set apache config directives Timeout 10 KeepAliveTimeout 2 and you should be on the safe side. b.
Posted by plumsauce, 06-23-2009, 11:08 PM
Not according to to tests run by sans.org: They concluded even 5 seconds was insufficiently short, and here you recommend 10 seconds as if it were a complete cure.
Posted by petteyg359, 06-23-2009, 11:37 PM
Excessive connections make excessive load. This is not news...
Posted by mwatkins, 06-24-2009, 12:23 AM
Unless you are using lighttpd or another one of http servers also not affected. With slowloris creating as many connections as RAM on one server would allow, the target - lighttpd on another server will merrily chug away still pumping out many thousands of requests per second as if nothing was happening. We front end many applications with lighttpd; this is one of the benefits we get from that.
Posted by Domenico, 06-24-2009, 10:14 AM
Here is another solution against slowloris: http://bit.ly/17yAvQ
Posted by bloodyman, 06-24-2009, 12:22 PM
Is this a solution for Apache 1.x ? Has anyone tested it with Apache 1.x?
Posted by DamianMyerscough, 06-24-2009, 01:39 PM
Hello, I have been looking at the Slowloris script and I think there is a possible solution by using iptables. The hit counter cannot go above 20 otherwise the attacker will be successful. The only problem that I see with the above iptables solution is that, if more than 20 users from the same IP address attempt to connect to the web server at once the IP address will be blocked.
Posted by mwatkins, 06-24-2009, 02:33 PM
Damian - one page reload on WHT pulls in more than 20 src elements - mostly images.
Posted by bloodyman, 06-24-2009, 04:17 PM
It would be good to have something like mod_antiloris for Apache 1.x ...