Arbitrary tweets made by TheGingerDog up to 21 January 2018
Arbitrary tweets made by TheGingerDog up to 24 July 2016
Fed up installing updates to WordPress sites? Stick this in a cron job somewhere, and cross your fingers (a little)…. Continue reading “Lazy wordpress updating using wp-cli.phar”
I came across the varnish throttle module the other day – which seems quite useful – and certainly gives better control over abusive requests than using fail2ban (in that, only specific URLs/request types can be targeted and blocked with the throttle module, while fail2ban tends to trigger the blocking of any traffic from a client which can be more painful).
Continue reading “varnish throttling”
WordPress seems to like hiding a load of ‘transient’ (cacheable) stuff in it’s wp_options table. Unfortunately for one site, it seems it didn’t bother to clean up the transient stuff, leaving behind about 750,000 records… which made a WP version upgrade painful, as MySQL locks the wp_option table which causes all other page loads to get stuck waiting (and the site to stop working).
Fix / hacky solution after the ‘more’…
Arbitrary tweets made by TheGingerDog up to 18 January 2015
Arbitrary tweets made by TheGingerDog up to 28 December 2014
While trying to block spam posts on a forum, I noticed this gem.
No doubt someone’s spam sending program has failed, just a little….
With the annoying brute force wordpress hack going round, one way to protect your site(s) would be to use fail2ban, with a configuration something like (which I’ve shamelessly lifted from http://blog.somsip.com/2011/12/protecting-apache-webservers-from-wordpress-admin-login-dictionary-attacks/ ).
The below seems to be working, and given it’s relative simplicity it’s obvious how you’d go about changing to protect other POST based scripts from brute force attacks.
As with all fail2ban rules, it’s not going to work if the attacker changes IP often (but from scanning the logs so far, it doesn’t seem to be the case that they are).
Obvious caveats :
- Users who can’t remember their password(s) will get blocked.
- It’s not going to protect you from a distributed attack (multiple IPs) very well
- You may want to perform other counter-measures (like putting Apache http authentication in for URLs matching /wp-login.php)
In /etc/fail2ban/jail.conf :
[apache-wp-login] enabled = true port = http,https filter = apache-wp-login logpath = /var/www/vhosts/*/statistics/logs/access_log maxretry = 5 findtime = 120
And In /etc/fail2ban/filter.d/apache-wp-login.conf :
[Definition] failregex = <HOST> - - .* "POST /wp-login.php HTTP/.*" 200 ignoreregex =
Where a “hacking” access.log entry looks a bit like :
220.127.116.11 - - [02/Feb/2014:12:50:01 +0000] "POST /wp-login.php HTTP/1.0" 200 4344 "-" "-"
See http://wordpress.org/support/topic/364929 and effectively the ‘patch’ on the Google Support forum thing which works fine (there are two bits of the plugin which need updating – whcih correlate to the two parts mentioned in the posting etc)
Bit annoyed that the fix is so easy – yet the plugin hasn’t been updated yet. Grr.