security – Wise Geek

I’m here today to relate a story about my friend who had his bike stolen last September from Gunwharf Quays. It was in broad daylight in a busy area with lots of shoppers and people walking close by.

This photo was taken by me when we discovered the missing bike. It should have been there next to the red foldable one. — This photo was taken mere minutes after we discovered the bike had been stolen. It should have been there next to the red foldable one.

How did this happen? The answer is simple – the lock my friend had used was little more than a piece of a wire. Quickly and stealthily cut with a pair of pliers.

Here is a similar cable (lock with glove for scale) - this is only good for securing your helmet. — Here is the kind of cable lock I mean (with glove for scale) – this is only good for securing your helmet.

Do not make the same mistake my friends, get a decent U-lock or D-Lock such as this. This lock conforms to the Sold Secure “Silver” certification standard – which is an independent lock testing standard. You want to aim for “Silver” or above when it comes to choosing a lock for your bike. Another good lock is this one from Kryptonite.

May 2019 Update: this is the lock that WG has been using for the last year – tough and compact and Sold Secure Gold rated:

If I’m cycling somewhere like the New Forest where I’m not sure that cycle lock hoops are available then I will take a thick cable lock like this one below so it’s easier to attach to posts and fences etc:

At the very least when locking your bike you MUST put the lock through the rear wheel, large triangle of the frame and loop it around a fixed bike post.
So, what to do if your bike is actually stolen? Sadly not that much. You can report it to the Police and if they recover it they might contact you. Some Police forces have a Twitter account where they publicize recovered bikes (like this one).
In my friends case above I actually located the bike on Gumtree a few days after it had been stolen. What I did was to set-up a search alert using the keywords and location of the theft (in this case “mountain bike” and “within 5 miles of Southsea, Hampshire”). Normally the thief will live locally (these unfortunate people normally sell them on to fund a drug habit or other addiction).

After I set-up a daily search alert on Gumtree I made sure to check the alerts every day for a week… Sure enough a few days later his bike appeared! It was being sold by a guy in Southsea – within about a mile of Gunwharf Quays. The seller’s name was “Jordan” and I contacted the guy feigning interest.
I sent my friend the link and he reported it to the Police. Sadly the Police probably would not be able to recover it and are generally have other more important crimes to deal with :/
That was no comfort to my friend but he is of a chilled, live-and-let-live disposition so it was cool with him.
He did relate one tale of someone finding their stolen bike on Gumtree, arranging to take a test ride of it.. and then cycling off into the distance, re-united with their bike once more. I can’t ever condone that though since it might incur a violent encounter with the original theif.
Stealing your own bike back though? I’ve love to see a video of such an incident – complete with a Go-Pro rear-facing camera capturing the look on the face of the original miscreant 😉
Further reading: How Not to Get Your Bike Stolen

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.