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.
|
1 2 3 |
root@village:/etc/fail2ban# service fail2ban restart Restarting authentication failure monitor: fail2banERROR Failed during configuration: While reading from '/etc/fail2ban/jail.local' [line 147]: option 'port' in section 'pam-generic' already exists failed! |
So I go in to the jail.local file and find:
|
1 2 3 4 5 6 7 8 9 |
141 enabled = false 142 # pam-generic filter can be customized to monitor specific subset of 'tty's 143 filter = pam-generic 144 # port actually must be irrelevant but lets leave it all for some possible uses 145 port = all 146 banaction = iptables-allports 147 port = anyport 148 logpath = /var/log/auth.log 149 maxretry = 6 |
So there are 2 port statements. I commented out line 147.
Then when I tried to starting Fail2ban again, I got the following:
|
1 2 |
root@village:/etc/fail2ban# service fail2ban start Starting authentication failure monitor: fail2banERROR NOK: ('Invalid log level',) |
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:
|
1 |
2015-04-29 xx:xx:xx,753 fail2ban.transmitter [10631]: WARNING Command ['set', 'loglevel', '3'] has failed. Received ValueError('Invalid log level',) |
Searching for loglevel in jail.local made a reference about checking .local
|
1 |
# Make sure that your loglevel specified in fail2ban.conf/.local |
Going to fail2ban.conf said to go make changes in fail2ban.local. Reading fail2ban.local everything looks right:
|
1 2 3 4 5 6 7 8 9 10 11 |
[Definition] # Option: loglevel # Notes.: Set the log level output. # 1 = ERROR # 2 = WARN # 3 = INFO # 4 = DEBUG # Values: [ NUM ] Default: 1 # loglevel = 3 |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[Definition] # Option: loglevel # Notes.: Set the log level output. # CRITICAL # ERROR # WARNING # NOTICE # INFO # DEBUG # Values: [ LEVEL ] Default: ERROR # loglevel = INFO |
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.
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.
thanks. I had the same issue and was able to fix it quickly with your explanation.