Arbitrary tweets made by TheGingerDog (i.e. David Goodwin) up to 29 August 2013
Continue reading “Automated twitter compilation up to 29 August 2013”
Linux, PHP, geeky stuff … boring man.
Arbitrary tweets made by TheGingerDog (i.e. David Goodwin) up to 29 August 2013
Continue reading “Automated twitter compilation up to 29 August 2013”
Arbitrary tweets made by TheGingerDog (i.e. David Goodwin) up to July 5th 2013
Continue reading “Automated twitter compilation up to July 5th 2013”
And a new theme. Perhaps one day I’ll fix my twitter sync script.
In the mean time, there’s a bit on Solr on Pale Purple’s blog. along with SpamDyke to stop Qmail being overrun by spam.
Arbitrary tweets made by TheGingerDog (i.e. David Goodwin) up to 01 August 2013
Continue reading “Automated twitter compilation up to 01 August 2013”
Deletion is easiest if you know the rule number. Rather than counting down, it’s easiest to use –
iptables -nL –line-numbers
Which may show something like :
Vagrant commands :
Obviously requires you have a reasonably good ‘Vagrantfile’ to start with…..
Arbitrary tweets made by TheGingerDog (i.e. David Goodwin) up to 01 July 2013
Continue reading “Automated twitter compilation up to 01 July 2013”
Another month passes, and another arbitrary tweets post … by TheGingerDog up to 01 June 2013
Continue reading “Automated twitter compilation up to 01 June 2013”
Arbitrary tweets made by TheGingerDog (i.e. David Goodwin) up to 01 May 2013
Continue reading “Automated twitter compilation up to 01 May 2013”
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 :
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 :
107.21.107.144 - - [02/Feb/2014:12:50:01 +0000] "POST /wp-login.php HTTP/1.0" 200 4344 "-" "-"