Posts

Posted on

vagrant commands for the lazy and forgetful

Vagrant commands :

  • vagrant up  – aka “clocking on at work, time to boot up the VM”
  • vagrant status – aka “did I leave that VM running last night?”
  • vagrant halt – aka “time to go home or change project”
  • vagrant destroy – aka “VM is broken; kill it with fire and deploy a virgin VM to start again”
  • vagrant package default –output /path/to/output/file.box – aka “I like this VM, I think I’ll keep a copy around somewhere for future purposes”
  • vagrant init – aka “Get this project started …”

 

Obviously requires you have a reasonably good ‘Vagrantfile’ to start with…..

Posted on

Fail2ban filter for WordPress

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 :

  1. Users who can’t remember their password(s) will get blocked.
  2. It’s not going to protect you from a distributed attack (multiple IPs) very well
  3. 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 :

107.21.107.144 - - [02/Feb/2014:12:50:01 +0000] "POST /wp-login.php HTTP/1.0" 200 4344 "-" "-"
Posted on

Script to fix NFS (Debian Squeeze + Backports bits)

I have a NFS server running Debian Squeeze. Additionally it’s using the 3.2.x kernel from backports, and the nfs-kernel-server from backports too.

Sometimes NFS breaks, and gives helpful messages like :

mount.nfs: connection timed out

or just:

Stale NFS handle on clients.

 

While I’m confident that my /etc/exports and other configuration files are correct, it still insists on misbehaving.

Below is a random shell script I seem to have created to fix the NFS server –

#!/bin/bash
set -e
/etc/init.d/nfs-kernel-server stop
/etc/init.d/nfs-common stop
/etc/init.d/rpcbind stop

rm -Rf /var/lib/nfs
mkdir /var/lib/nfs
mkdir /var/lib/nfs/v4recovery /var/lib/nfs/rpc_pipefs

for f in /var/lib/nfs/etab \
/var/lib/nfs/rmtab \
/var/lib/nfs/xtab; do
[ -e $f ] || touch $f
done

/etc/init.d/rpcbind start
sleep 2
/etc/init.d/nfs-common start
sleep 2
/etc/init.d/nfs-kernel-server start

echo "NFS may now work"

exportfs -f

Yes… “NFS may now work” … that sums it up about right.