How to protect WordPress from DoS, DDoS and XMLRPC attacks

So, you are sysadmin of a Linux server that runs one or more WordPress sites. Everything “just works”… but now and again you notice a massive slowdown in site performance. You may even get an alert or three from your site monitoring system. Normally at anti-social times of the day 🙁

After looking into the Apache access logs for the WordPress site vhost you discover that large number of requests are seen from the same IP to a bunch of pages on your site.

Here are some examples from my own logs:
[malicious ip] - [02/Jul/2015:21:24:28 +0100] "GET /wp-login.php HTTP/1.1" 404 504 "-" "Mozilla/5.0 (Windows NT 6.1
; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/24.0.1309.0 Safari/537.17"
[malicious ip] - - [02/Jul/2015:21:24:28 +0100] "GET /administrator/ HTTP/1.1" 404 502 "-" "Mozilla/5.0 (Windows NT 6
.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/24.0.1309.0 Safari/537.17"
[malicious ip] - - [02/Jul/2015:21:24:31 +0100] "GET /admin.php HTTP/1.1" 404 500 "-" "Mozilla/5.0 (Windows NT 6.1; W
OW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/24.0.1309.0 Safari/537.17"
[malicious ip] - - [02/Jul/2015:21:25:14 +0100] "POST /blog/xmlrpc.php HTTP/1.0" 500 607 "-" "Mozilla/4.0 (compatible
: MSIE 7.0; Windows NT 6.0)"
[malicious ip] - - [02/Jul/2015:21:26:44 +0100] "POST /blog/xmlrpc.php HTTP/1.0" 500 607 "-" "Mozilla/4.0 (compatible
: MSIE 7.0; Windows NT 6.0)"
What you are seeing is malicious network traffic – designed to find vulnerabilities in your WordPress site software or to make it unavailable to genuine site visitors.
While you can keep your WordPress updated to help defend against these attacks (and indeed it’s as easy as clicking a button these days), this will not help keeping your site available.

Defending your WordPress site from a large quantity of malicious network requests cannot be done using just WordPress alone.
In this blog post, I’m going to share what I did to defend my own WordPess sites against such attacks.

I use Debian Linux but these instructions are also applicable to other distros with slight changes to package names, paths etc.

We’re going to install two packages:

• fail2ban – this will handle the network level blocking of malicious traffic by manipulating iptables
• mod_evasive – this is an Apache module that detects suspicious site activity, blacklists IPs to prevent access and logs those IPs

What we’re going to do is wire these two up to get “the best of both worlds“. In essence we’re going to detect malicious users, block them once they start misbehaving and ensure they never bother you again.

So lets start by installing both packages:
aptitude install fail2ban mod_evasive
fail2ban has a concept of “jails” – any malicious IPs detected by mod_evasive get “jailed”.

Lets create a couple of jails: one for the XMLRPC attacks and another for anything mod_evasive regards as suspicious:

In /etc/fail2ban/jail.conf

[apache-mod-evasive]
enabled = true
port = http,https
filter = apache-mod-evasive
logpath = /var/log/daemon.log
maxretry = 1
bantime = 3600
# keep the jail name short 29 chars or iptables will not be able to create the chain
[wp-xmlrpc]
enabled = true
port = http,https
filter = wp-xmlrpc
logpath = /var/log/apache2/mywordpress.com/access.log
maxretry = 1
bantime = 86400

Note the name limit for the jail!

Next we create filter files for both these jails so we can extract the malicious IPs (you can adapt these to other services and logfiles once you get the general idea)

/etc/fail2ban/filter.d/wp-xmlrpc.conf

# Fail2Ban configuration file
[Definition]
# Option: failregex
# Notes.: regex to match the Forbidden log entrys in apache error.log
# maybe (but not only) provided by mod_evasive
#
# Values: TEXT
#
#failregex = ^\^\*\]\s+\[error\]\s+\[client \] client denied by server configuration:\s
failregex = .*POST /blog/xmlrpc.php
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
…and in /etc/fail2ban/filter.d/apache-mod-evasive.conf

# Fail2Ban configuration file
[Definition]
# Option: failregex
# Notes.: regex to match the Forbidden log entrys in apache error.log
# maybe (but not only) provided by mod_evasive
#
# Values: TEXT
#
#failregex = ^\^\*\]\s+\[error\]\s+\[client \] client denied by server configuration:\s
failregex = mod_evasive\[\d+\]:\s+Blacklisting address :
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
For mod_evasive the config files vary depending on your Debian version…
Debian Wheezy: /etc/apache2/conf.d/mod-evasive
Debian Jessie: /etc/apache2/conf-available/mod-evasive.conf
# docs in /usr/share/doc/libapache2-mod-evasive/README.gz
DOSPageCount 10
DOSSiteCount 10
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 60
# this works but i dont really need to know all the time
#DOSEmailNotify root@localhost
# XXX make sure this dir exists beforehand!
DOSLogDir “/var/log/mod_evasive”
DOSWhitelist 127.0.0.1
# server external IP – just in case
DOSWhitelist [server external ip]

Please heed some of the comments above!

Note that the full docs for mod_evasive (and a config test program) can be found in /usr/share/doc/libapache2-mod-evasive/README.gz

You can add multiple DOSWhitelist lines – it would sensible to add the IP that you connect from the most – or add a “safe” unchanging once such as your employers IP.

I suggest playing about with the first bunch of settings (DOSPageCount, DOSSiteCount, DOSPageInterval, DOSSiteInterval) as you can easily get false-positives when trying this out – you could block legitimate traffic if you are not careful!

Ensure you restart the respective services once finished with configuration. Observe the log files to ensure operation is correct.
mod_evasive will log to /var/log/daemon.log like this:

Jul 2 11:19:44 defiant mod_evasive[8949]: Blacklisting address [blacklisted ip 1]: possible DoS attack.
Jul 2 11:26:24 defiant mod_evasive[9033]: Blacklisting address [blacklisted ip 2]: possible DoS attack.

fail2ban will log to /var/log/fail2ban.log like so

2015-07-08 18:44:06,516 fail2ban.actions: WARNING [wp-xmlrpc] Ban [malicious ip 1]
2015-07-08 18:44:06,536 fail2ban.actions: WARNING [wp-xmlrpc] Ban [malicious ip 2]

You can also examine the fail2ban jail like so:

# fail2ban-client status wp-xmlrpc
Status for the jail: wp-xmlrpc
|- filter
| |- File list: /var/log/apache2/mywordpress.com/access.log
| |- Currently failed: 0
| `- Total failed: 2
`- action
|- Currently banned: 2
| `- IP list: [malicious ip 1] [malicious ip 2]
`- Total banned: 2

You can also see the corresponding iptables chain:

# iptables --list --line-number
...
1 fail2ban-wp-xmlrpc tcp -- anywhere anywhere multiport dports http,https
...
Chain fail2ban-wp-xmlrpc (1 references)
num target prot opt source destination
1 DROP all -- [malicious ip 1] anywhere
2 DROP all -- [malicious ip 2] anywhere
3 RETURN all -- anywhere anywhere

And that should do it!
You may need to tweak the settings occaisonally. Just keep an eye on it. Log-in now and again for the next week or so after configuration and check these logs to see if things are running smoothly:

# multitail /var/log/apache2/mywordpress.com/access.log /var/log/fail2ban.log /var/log/daemon.log

If something does slip through the net you can manually ban/unban using something like:

# fail2ban-client set wp-xmlrpc banip [malicious ip]

Hope that helps! Let me know if it works/does not work by leaving a comment.