Why is my Apache web server crashing all of a sudden?
That can be a frustrating scenario especially if you’ve been making modifications to your configuration file or, for example, adding “plugins” to your WordPress environment. But what if you haven’t touched your set-up in weeks and now you’re faced with constant “Server Crashes” that inevitably keep your site offline. Much like a TV that doesn’t work, because it’s not plugged into the wall, so to is this problem, trouble-shoot the most obvious possibility first. You’re going to want to check for an unusual number of entries in your server log files, something like “POST /xmlrpc.php HTTP/1.0“, yup that’s it!
So why xmlrpc.php?
It’s a spec and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet.
It’s remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.
Compatible XML-RPC implementations that span all operating systems, programming languages, dynamic and static environments, open source and commercial, for Perl, Python, Java, Frontier, C/C++, Lisp, PHP, Microsoft .NET, Rebol, Real Basic, Tcl, Delphi, WebObjects and Zope, and more are coming all the time.
OK, you’ve identified the problem now what?
Using Apache we can manually block all XML-RPC traffic, and here’s how…
1 2 3 4 5 6
<VirtualHost> <files xmlrpc.php> order allow,deny deny from all </files> </VirtualHost>
If you don’t happen to have the luxury of running your own Apache web server you can always install the Jetpack by WordPress.com plugin to protect yourself from hackers. Hopefully your hosting provider has already configured their web server to mitigate such attacks.
Here are a couple of links related to this topic that I’m sure you’ll find interesting.
First discovered in 2009, the HTTP POST attack sends a complete, legitimate HTTP POST header, which includes a ‘Content-Length’ field to specify the size of the message body to follow. However, the attacker then proceeds to send the actual message body at an extremely slow rate (e.g. 1 byte/110 seconds). Due to the entire message being correct and complete, the target server will attempt to obey the ‘Content-Length’ field in the header, and wait for the entire body of the message to be transmitted, which can take a very long time. The attacker establishes hundreds or even thousands of such connections, until all resources for incoming connections on the server (the victim) are used up, hence making any further (including legitimate) connections impossible until all data has been sent. It is notable that unlike many other (D)DoS attacks, which try to subdue the server by overloading its’ network or CPU, a HTTP POST attack targets the logical resources of the victim, which means the victim would still have enough network bandwidth and processing power to operate. Further combined with the fact that Apache will, by default, accept requests up to 2GB in size, this attack can be particularly powerful. HTTP POST attacks are difficult to differentiate from legitimate connections, and are therefore able to bypass some protection systems. OWASP, an open source web application security project, has released a testing tool to test the security of servers against this type of attacks.
As an aside, one of my favourite DDoS (denial-of-service) attack prevention measures is mod_evasive2, an evasive maneuvers module for Apache that provides evasive action in the event of an HTTP DoS or DDoS attack or brute force attack.
Go ahead, make my day!