Since I migrated my blog to the new service provider I ran into a few problems.
WordPress.com Stats Plugin
First of all I was unable to post from Live Writer because of an error I kept on getting. The error looked like an error with something that had to do with XML-RPC support. Which –ofcourse- I had enabled.
Finally I found a forumpost on the WordPress Support Forum where someone advised to disable all plugins to see if the problem disappeared, and it did.
After a bit of testing I found out that the “WordPress.com Stats” plugin caused this plugin and after reading the release-notes of this plugin carefully I noticed that the plugin was tested up to WordPress version 2.8 and not to 2.8.2.
After the problem above was fixed I noticed another problem. After posting from Live Writer now went error-free it seemed that HTML-tags in the posts I posted became somewhat incomplete cause the < and > characters were stripped from the HTML-code. Which resulted in incomplete or distorted messages, since it also happend when you edited messages in Live Writer.
The problem –after a bit of research- appeared to caused by the combination of PHP 5.2.8 and LibXML 2.7.2. I found a post on the WordPress Support forum where a link was mentioned to the libXML2 Fix Plugin and from that page there was a reference to the WordPress Trac (bugtracker database) where the problem was described that I was experiencing.
After installing the libXML2 Fix Plugin on my blog all of the problem disappared and everything worked fine again!
Categories: Blog Apache, Blog, bug, bugs, metaweblog.newpost, php, plug-in, plugin, rpc, statistics, stats, wordpress, xml, xml-rpc
This “vulnerability” is somewhat unavoidable. The thing is that this tool keeps on opening simple HTTP connections which is –even if the webserver limits the maximum number of connections- really unstoppable. As the quote from the Slowloris website explains pretty clearly too.
Also, the DoS tool (perl script) is freely downloadable.
Slowloris holds connections open by sending partial HTTP requests. It continues to send subsequent headers at regular intervals to keep the sockets from closing. In this way webservers can be quickly tied up. In particular, servers that have threading will tend to be vulnerable, by virtue of the fact that they attempt to limit the amount of threading they’ll allow. Slowloris must wait for all the sockets to become available before it’s successful at consuming them, so if it’s a high traffic website, it may take a while for the site to free up it’s sockets. So while you may be unable to see the website from your vantage point, others may still be able to see it until all sockets are freed by them and consumed by Slowloris. This is because other users of the system must finish their requests before the sockets become available for Slowloris to consume. If others re-initiate their connections in that brief time-period they’ll still be able to see the site. So it’s a bit of a race condition, but one that Slowloris will eventually always win – and sooner than later.
I’m not sure if there’s anything you can do to prevent an attack caused by this tool and I don’t think there is a solution to protect yourself from such.
As you might understand I advise you not to use this tool on public websites or such but only for educational purposes to see if you can find a way to protect yourself from it.
Also the attacks you do with this tool can be traced back to you cause the HTTP connections you create by using the tool will always be initiated from your own source IP address.