My Techie-Thoughts

Your intentions are good, rotating your fail2ban log file. You are rotating your fail2ban log file, right? I mean, it’s not done by default for some weird reason so I’d forgive you if you aren’t. They get big and they should be trimmed and archived. If you’re already rotating your fail2ban log file or you’ve tried doing it in the past, did you ever notice that fail2ban stops using those rotated files? How rude! Let’s fix that.

The problem

Although log file rotation is a best-practice and something that too many admins overlook which leads to bloated giant log files and tons of wasted space, it seems that fail2ban doesn’t play nice with this idea. The issue is that the hash- value of the new log file created by logrotate does not match the one created by fail2ban itself. As a result, f2b throws a fit and refuses to use the log file. Even worse, this happens silently! Maybe a reason why your bans have stopped taking effect? Thankfully, it’s a pretty easy fix that we can implement via logrotate itself.

The fix

Fail2ban does not create a logrotate configuration by default, so if you don’t already have one, then you can just create the following file. If you already have a logrotate configuration file, then you can edit it as necessary to add this fix. I’m going to assume you’re starting from scratch so we need to create the file:

cd /etc/logrotate.d
touch fail2ban

Open this new file in your editor of choice and type the following, changing settings as appropriate for your environment or just using my suggestions for now if you’re new to all this (you do NOT have to include my comments!):

/var/log/fail2ban.log {
	# it's ok if the file doesn't already exist
	missingok
	# rotate once per week
	weekly
	# maintain 4 weeks of archived log files before deleting the oldest
	rotate 4
	# compress archived log files
	compress
	# create a new log file
	create 0600 root root
	# perform the following actions after rotating
	postrotate
		systemctl restart fail2ban.service 1>/dev/null
	endscript	
}

Fail2ban documentation suggests using fail2ban-client restart whenever the daemon should be restarted. However, this leaves the service active but exited. That’s really not helpful and why I use systemctl restart instead.

Testing

It’s always a good idea to test stuff before you count on it working in production. We’ll test things out in two steps.

1. Debug mode

Debug mode only simulates rotation, nothing will actually happen to your log files. This is a quick and safe way to make sure we don’t have any syntax errors or invalid parameters in our logrotate configuration for fail2ban.

cd /etc/logrotate.d
logrotate -df fail2ban

If everything is good, you won’t receive any errors. If that’s not the case, read the generated errors and double-check your configuration. Re-run this debug test until your configuration gets a clean bill of health and then let’s move on.

2. Forced rotation

To actually make sure fail2ban is restarted properly and uses the new log file, we need to rotate the log file for real. No simulation can substitute for real-life.

One caveat you should be aware of: This forced rotation will only run options in our fail2ban configuration file. It will ignore your default configuration options. In a real automated (normal) rotation, your default settings would be processed in addition to our fail2ban configuration. It shouldn’t make a difference for our testing, but you should be aware of this limitation.

Force the log file rotation:

logrotate --force fail2ban

Verify that fail2ban was actually restarted:

systemctl status fail2ban.service
fail2ban-client status

You should see that fail2ban was restarted a few seconds ago and the client should report all your jails running normally. Now, let’s see if the new log file is being used:

ls -lA /var/log/fail2*
tail /var/log/fail2ban.log

You should see your fail2ban.log file along with at least one archived backup file. The ‘tail’ of your fail2ban.log should show that it is actually being used since you will see some f2b status messages. If this isn’t the case, then re-check your logrotate configuration file for fail2ban and re-run these tests.

Final thoughts

This is a pretty annoying issue and one that I haven’t seen really talked about anywhere. So, hopefully this was helpful and fixes what I think is a pretty often overlooked issue. If nothing else, hopefully it encouraged you to start rotating your fail2ban log files!