Incapsula, provider of security and performance for our clients’ WordPress sites, this week reported a Distributed Denial Of Service (DDOS) attack using thousands of WordPress sites against a target.
The attack does not compromise the many WordPress sites involved, it only uses them to make connections to the target site with the goal of overloading it with “Pingbacks”.
How Did The Attack Work?
The attack involves making thousands of WordPress sites think that they have been linked to by the target site. The default behaviour of WordPress when receiving notification of a link is to connect to that site to verify that the link exists – a so called “PingBack”.
All this works well when the links are real. However, when the link does not exist then the instigator can orchestrate thousands or potentially millions of WordPress to pingback the target site. If these happen simultaneously then this can overload the chosen target site and the server may crash.
How Should You Combat This WordPress Vulnerability?
Here are 5 possible responses to the issue depending on your social responsibility and general level of paranoia when it comes to security.
Level 1 – Frankly Scarlett . . .
Do nothing to tighten your security. And don’t give a damn about it.
My site can afford the odd pingback to an exploitative corporate, run by executives with multi-million dollar bonuses paid into the Cayman Islands that had it coming anyway. If their site is down because my one connection was the straw that broke the camel’s back then good on that straw!
Level 2 – It Wasn’t Me
Do nothing to tighten your security. And Be Defensive About It.
Deny responsibility. In order to take a site down it takes thousands or even millions of connections.
Blame the hacker, blame WordPress, don’t blame me.
Level 3 – Take Action After The Event
Do nothing to tighten your security right now as that might be a waste of effort. But if you later detect your site has been used in a DDoS attack then you could take some action and block the IP address that originated the attack.
Don’t spend time solving problems you don’t have
You can block the IP address in your site’s firewall, either by asking your host to do it or doing it yourself if you have a VPS or dedicated server, or do it in the .htaccess. Even simpler is that if like me you have a Whooshed site then you can use the Blocked IPs page on the WordFence plugin to block that IP address manually.
Level 4 – Disable Pingbacks And Trackbacks
Block the exploitation with minimum impact to your own site.
95% of pingbacks and trackbacks are SPAM in any case so why not just disable them? In WordPress Settings | Discussion clear the checkbox Allow link notifications from other blogs (pingbacks and trackbacks) .
Say goodbye to pingbacks and trackbacks. Who needs them anyway.
With this setting disabled, your site cannot be used as described above to attack other sites. Also you have the added benefit of not having to not waste time marking external pingbacks as spam or deleting self-pingbacks generated by your own posts.
This is my preferred approach.
Level 5 – Disable XMLRPC
Block the exploitation by deleting xmlrpc.php to disable all remote functions.
This approach is recommended by Gur Shatz, the Incapsula CEO who identified the problem. However, I think it is an excessive response if you need to use XMLRPC on your own site for features such as remote posting. Why disable useful functionality on the off-chance that you are one of several thousand that contributed to an attack?
In any case if you do want to disable XMLRPC then there are better ways to achieve than by deleting the file as it will be replaced next time you upgrade. A better approach is to use the Disable RPC plugin.
