Categories
debian linux tech

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.

Categories
tech

Be Broadband Firmware upgrade for users with a static IP and non-default config

This weekend I attempted the Be Broadband mandatory router firmware upgrade which appears to be linked to Be’s sale to Sky 🙁

I thought I’d relate my experience of that here so that folks have “all the information in one place”. The process was pretty much smooth but those of us geeky enough to have a static IP, custom DHCP range, port-forwards and other config changes might (will?) run into minor niggles.
First thing to note is that Be Broadband have actually organized things nicely and you should have an email or two with your static IP, links to firmware and an installation guide. However read on to see my approach…

Now I love bullet points and my process with be in that format with a few asides here and there.
Here we go:

  • Essentially I followed this:

https://www.bethere.co.uk/web/beportal/single-static-update-instructions#q2
And that boiled down to:

  • boot into Debian Linux laptop and attach wired connection to router
  • backup user config to file (important! needed for diff later)
  • download new firmware

It was at this point that I realized that the firmware upgrade required running an .exe on Windows. I somehow expected to be able to upload the firmware to the router via the web GUI 🙁 So…

  • download flasher from this guide:

http://beusergroup.co.uk/technotes/index.php/Modem_Firmware
It’s written for Windows BUT there is actually upgrade instructions on how you can use Linux instead:
http://beusergroup.co.uk/technotes/index.php/Modem_Firmware#Linux_and_other_Unixes
Be warned that it involves setting up local TFTP and BootP servers. I’m secure enough in my geekyness to have done that (I have done so in the past to setup Cisco VOIP phones) but in the real-world of lack-of-time and family commitments I just dual-booted into Windows (also my notes for all this were synced in Dropbox – nice).

  • boot into Windows

Ensure flasher and firmware is downloaded (again!)
Now just in case, have both these open in browser tabs (and/or save web page locally) in case of net outage:
https://www.bethere.co.uk/web/beportal/techguides_installing_bebox_firmware
http://beusergroup.co.uk/technotes/index.php/Modem_Firmware
Note the “bethere” link above has some nice friendly screenshots.

  • extract flasher software
  • ensure thompson router connected via wired NOT wireless
  • extract bin file from firmware archive

Note that the flasher software will look in “TGUPGv7201/Builds” by default but you can point it to where ever you downloaded it to.

  • proceed with flash

screenshots from that process:
Thomson Home Install Wizard_2013-03-02_13-05-58
Thomson Home Install Wizard_2013-03-02_13-06-23
After flash router will be on http://192.168.1.254 and the user/pass will be “Administrator/<router serial>”
In my case some of the config could not be restored for some reason…
(eg. it worked but gave a non-fatal error about not being able to restore some of the config.)
Thomson Home Install Wizard_2013-03-02_13-10-36
Note that I didn’t have to provide the new static IP anywhere, the router assumed it after the upgrade and the ATM connection completed.
I now had a situation with working internet but the router was running with default settings. The router may need a reboot just to make sure everything is OK (I didn’t need to but did it as a basic check).

  • diff the configs and reconfigure router

Now this was the time consuming part and I had forgotten at how “rudimentary” the GUI is compared to something like SmoothWall Express or pfSense.
Anyway, I wanted to reconfigure the router as I has diverged from the default in a few ways.
My approach to this was to download the new config and rename it, examine the diffs:

$ diff -u <original config>.ini <new config>.ini

There’s quite a few changes in the new config, looks like they have simplified some settings and are using aliases for services and such.

From memory this was the stuff I re-configured:

– turn off UPNP
– add debian uk ntp pool
– wi-fi setup: restore ssid, g-only, reset wi-fi passphrase (but best to disable wi-fi here, reenable later in last step)
– change LAN IP and DHCP pool
(do this by `Home Network > Interfaces > LocalNetwork > Configure`)
– set <my personal DHCP range>.1 as LAN interface IP
– (At this point I turned off wi-fi as family was complaining about internet going up/down!)
– set laptop wired nic as <DHCP address>.100 manually
– The default DHCP 1.0/24 range still in dhcp pool, reboot router to ensure no devices have a 0.1/24 dhcp range address
– when router back, you will be able to delete the 0.1/24 pool (named “LAN_private”)

create new firewall ruleset based on “standard” ruleset.

– add port forward(s) from outside

This is best done by first setting a name to the server via the “home network”
do this via `Home > Toolbox > Game & Application Sharing`
click `Create a new game or application` and add application `ssh-custom` or whatever.
then go to `Home > Toolbox > Game & Application Sharing` and assign to server name.

  • change external DNS provider as static IP has changed
  • change any intrusion prevention rules and whitelists given new static IP
  • Now turn on all your computers so they get new DHCP addresses.

I was using some static internal addresses as I run a local DNS server but this time I set detected devices to use DHCP and always use the same IP based on Mac address.
I also set device type eg. desktop, laptop, phone…
Shame no “server” icon 🙂

  • save router config now and keep somewhere safe

All Done! (I hope)
Now there has been some discussion on Google+ among my peers on what the sale to Sky will mean for Be and it’s pretty damn good standard of service. Some folks are thinking of jumping to the more geeky (but costly) ISP such as Zen or Andrews & Arnold and some have said that Sky is “not that bad actually”.
We’ll be watching…