Apache Security Hole - Protecting your WebServer From DoS.

[Dyndrilliac]

Apache Security DoS Hole Explanation, By MooReR Software

[size=18]Introduction[/size]

If you are experiencing threats to knock out your web servers, which run Apache as the server, are most likely to be hit with the program that I originally wrote, and exploit I discovered.  I'm sure that many others have found this exploit, as no one truly is the only discoverer of an exploit.  Some just do not open up the facts to other people.  I have keep this a secret for quite some time, as many others would.  That is why you never find programs like this to do such powerful things.  The people on yahoo who say they made it, are full of it.  I know of one person who made it, which released the source and now everyone's saying they made it.  These idiots on yahoo say "Well, it connects and disconnects a bunch and causes a page fault in apache", which was what some idiot said who claims he made it -- To bad you're completely wrong, read and learns something.

Recently, many people have been remaking my original version of the Apache DoS.  It was not intended to be released to as many people who have to this day.  I sent it to only a couple people, in which I thought I could trust.  Of course, they sent it out to others, which in the end was distributed beyond belief.  Now that others have been remaking the program, they will be released it to all of their friends, and the chain will continue to be extended.  I really noticed the problem when someone (I will not mention his name) started threatening for a certain host for money, if they did not pay up, he attacked the servers.  You know what happens when you start doing that?  The issues start to get more serious, people start getting in trouble, and companies start to keep a stronger eye on the servers.  You will get caught and once you do, who are you going to blame? Can't blame me, I did not do it, you will have to blame yourself.

[size=18]The Problem with Apache[/size]

Though Apache is said to be the best around.  It seems to have a hard time with DoS attacks of all sorts. You can set up Apache to detect the incoming attacks by logging SYN requests, not just your average HTTP requests, but actually preventing them through Apache is useless.  There are  no modules inside of Apache (that I know of) that will allow anyone who has established more then one connection to be automatically banned or disconnected.  With that being said, the space for a DoS is very wide.

You can simply max out the connections allowed by Apache.  Once you have maxed out these connections, the server will be rendered useless, generating an error such as (taken directly from a default installation of Apache 2.0 for Win32) :

[Fri Apr 09 19:59:06 2004] [error] [client 192.168.0.100] client sent HTTP/1.1 request without hostname: /
[Fri Apr 09 19:59:14 2004] [warn] Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

If you were to check your access logs, you would see one attempt from the 192.168.0.100 is get / http/1.1" 400 312.  This is suspicious activity, definitely not from a web browser.  A web browser would send something like "GET / HTTP/1.1" 200 1672.  As you can see the responses are not only different (400 312) but the request GET is not capitalized.  I know this may not be a lot to work from, but this is a way to suspect suspicious activity against your web server, such as someone just telneting to it and manually sending the commands, up to a DoS.

The logs may vary.  It depends on how you have Apache setup.  But, this is the default for Apache 2.0 for Win32.

[size=18]Solutions[/size]

Now that you have a general idea of what is happening, you probably would like to know "How the hell do I stop this?".  Well, there are many solutions for the problem.  Though, not many of them will do everything for you, as you would probably want.  It will still take some monitoring, which all sys admins should take the time to do.  No one just puts a server up, lets it sit there and do its thing with out being monitored.

1.  You may setup the Apache logs to pick up SYN connections (Help Documents).  Do this!  It will show each attempted connection, which will obviously show you an attack of any type through  DoS.

2. Use a basic Intrusion Detection System (IDS) like Snort.  Set it up correctly and you can monitor everything coming in and out of your servers.  Its a lot more advanced then simple SYN logs.  You can setup various rules to detect all sorts of possible attacks.  This is the best IDS known.

3. You may even use a netstat type of program, which will show you your current connection activity.  It will show the attackers IP address just flying across the netstat logs.  This is obviously an attempt to DoS attack either your web server, or your machine in general.  Simply block that IP address, even its IP range to stop further attacks.

4. Setup a firewall.  Whether its an Linux hardware firewall (Tutorial by Optikwon), generic software firewall for windows like Sygate or Kerio, IPTables is all you need for Linux/Unix, if setup correctly, or even a router.  Just get something that will block attacks like we have discussed.

5. Now, if you are not wanting to do either of the above and want Apache to detect the attacks, and automatically block the IP, check out DosEvasive.  This add-on for Apache 1.3 and 2.0 which will create types of protection against users connecting more then 50 times, and even different kinds of brute force attacks! I have not personally tested it, but it looks very promising.

6. If none of these solutions work for you, then wait for the latest version of Apache to be released.  They are aware of this vulnerability and it will be patched with the next release of Apache.

That concludes the article on Apache DoS.  Hopefully now people can protect themselves more, rather then being wide open to attacks.  For a killer combination, use all of these methods together and you should be pretty safe.  Keep in mind, that no one is safe from a DDoS, which can render anything useless with enough random attacks.