I have recently moved this, and a bunch of other sites I host, over to new infrastructure.

Unfortunately, for reasons I won’t bore you with (mainly because I’ve not yet figured them out), the standard ip-tables ban action in fail2ban has stopped working. However, since I am already behind a firewall, all I really need is to block the script kiddie attacks for the various website logins.

I already have some filters for this, so I wrote some quick actions to add these IP addresses to ban lists that can be used by Apache.

I have two flavours, one for apache 2 and another for apache2.4.

Usage

Copy the appropriate action config into your /etc/fail2ban/action.d directory, and enable the action in the usual way.

Then, to actually use the block list, you’re going to need to include it into your vhost config by referencing it in your <directory> block, e.g.:

<RequireAll>
    Require all granted
    Include /var/run/fail2ban/fail2ban.apache24
</RequireAll>

Link to fail2ban.apache for the apache 2 version.

Hope this is useful to folks!

» Visit the project on Github...

I have previously written about using Git to add revision history to existing rsync backups. Having performed a number of configuration changes and system upgrades recently, I have found another use of Git which has proven invaluable.

It’s a fairly obvious hack, but it turns out that turning selected configuration directories (for example /etc/apache2/ and /etc/exim4/) into in situ Git repositories is a very handy thing to do.

The revision log you get in a Git repo gives you a very handy place to note down the reasons behind a certain configuration change. This provides a very handy historical context for a change, meaning you’re less likely to remove something odd that turns out later on to have been important.

Having configuration under version control also means that even if you do accidentally remove or change something that later causes problems you can easily roll them back.

Another handy feature is the ability to easily branch, so you can very quickly experiment with some wild configuration settings and very quickly revert them to the original working configuration should they turn out to be problematic or if you run out of time to complete them.

So, give it a try!