Fail2Ban problems with Debian Stretch

This week The Debian project released “Jessie” (Debian 8.0) as stable. I like to keep my servers a little more ahead of the curve than that, so I upgraded to the new testing branch “Stretch”.

While going through my logs from yesterday and this morning, log checker is awesome, I saw someone hitting my mail server. Normally you only get 1 chance to log in as a non-existent account before Fail2ban kicks in and adds the ip address to my Netfilter iptables jail. This address kept showing up, hour after hour in the logs, and multiple user names.

Looking, I found out that while running, it wasn’t catching all the rules for Fail2ban. I checked the configuration files, and things checked out OK. So I fell back on the old restart the service and see what errors pop.

So I go in to the jail.local file and find:

So there are 2 port statements. I commented out line 147.

Then when I tried to starting Fail2ban again, I got the following:

Googling the error got me no real good information. So lets go look at the logs. It had errors for ssh and for dovecot jails, and this nice little nuget:

Searching for loglevel in jail.local made a reference about checking .local

Going to fail2ban.conf said to go make changes in fail2ban.local. Reading fail2ban.local everything looks right:

But wait, that error log said it didn’t know what level 3 was…
back to fail2ban.conf to see if that Definition was different, and it was:

The fail2ban.conf and the fail2ban.local different and using different names to state the log level. I changed the setting in fail2ban.local. When I restarted after, everything worked.

I’m not sure if this is a bug in the Debian upgrade system or not. It didn’t ask me to maintain local copies. But looking at Jail.conf and Jail.local they don’t match either.

I looked some more at files on the one box. it had the old Fail2ban 0.6 jail.local, and the new 0.9 jail.conf. So I updated that, and things seem to be working.

2 thoughts on “Fail2Ban problems with Debian Stretch

  1. Bill Schultz

    I had this same problem on Centos. However, I discovered that yum had placed a modified configuration file into /etc/fail2ban named fail2ban.conf.rpmnew so I renamed fail2ban.conf to fail2ban.conf.rpmold and fail2ban.conf.rpmnew to fail2ban.conf and restarted fail2ban. There was apparently a design change in fail2ban but the update system won’t automatically replace or update your existing configuration file, so it leaves you this new skeleton configuration as an rpmnew file. You can diff to figure out what changed.

    Reply
  2. Guillaume

    thanks. I had the same issue and was able to fix it quickly with your explanation.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *