1

I'm facing a confusing issue with Fail2Ban.

I run an older version which, upon restart of the Fail2Ban Daemon unbans all IP addresses.

I now have Fail2Ban version 0.9.3 installed on Centos 7. When I restart Fail2Ban, it re-bans the previously banned IP addresses. I do not want this to happen, and instead want all bans cleared on restart, which is the way it used to work.

I've set dbfile = None to prevent persistent banning and also set dbpurgeage = 0 just to be safe.

But on restart any banned IP's get banned again.

Here's an excerpt from /var/log/fail2ban.log when a user gets banned via vsftpd:

2016-09-19 20:45:58,671 fail2ban.filter         [23752]: INFO    [vsftpd] Found xx.xx.xx.xx
2016-09-19 21:01:55,665 fail2ban.filter         [23752]: INFO    [vsftpd] Found xx.xx.xx.xx
2016-09-19 21:02:06,679 fail2ban.filter         [23752]: INFO    [vsftpd] Found xx.xx.xx.xx
2016-09-19 21:02:06,936 fail2ban.actions        [23752]: NOTICE  [vsftpd] Ban xx.xx.xx.xx

Then upon restarting Fail2Ban here's the last few lines of the log file:

2016-09-19 21:02:42,719 fail2ban.jail           [24213]: INFO    Jail 'vsftpd' started
2016-09-19 21:02:42,761 fail2ban.filter         [24213]: INFO    [vsftpd] Found xx.xx.xx.xx
2016-09-19 21:02:42,761 fail2ban.filter         [24213]: INFO    [vsftpd] Found xx.xx.xx.xx
2016-09-19 21:02:42,921 fail2ban.actions        [24213]: NOTICE  [vsftpd] Ban xx.xx.xx.xx

It seems to be re-scanning the log files and re-banning a previously banned user.

As I mention, this is not how it used to work in older versions of Fail2Ban - how can I revert to the previous functionality?

Improve this question
3
  • Hmm. I'm not sure. Most people hated that it wasn't persistent, and want the current behavior. Why are you trying to do this?
    – Michael Hampton
    Sep 19, 2016 at 21:12
  • Occasionally a legitimate user will get banned - rather than try and figure out and confirm what their IP address is, it was easier just to restart fail2ban - that's the main reason really
    – MrCarrot
    Sep 19, 2016 at 21:21
  • 2
    So instead of unbanning the hapless user, you want to unban everything, including the bad actors?
    – Michael Hampton
    Sep 19, 2016 at 21:23

1 Answer 1

Reset to default
2

Disabling the use of dbfile means that fail2ban loses track of its read position in each file on restart and so reads the whole file leading to the behaviour you've observed.

Adding tail after the filenames in the logpath statements will tell fail2ban to start reading from end of file rather than starting at beginning. That should (I think) give the behaviour you want (or near enough). See docs for more detail. Relevant section is ...

Optional space separated option 'tail' can be added to the end of the path to cause the log file to be read from the end, else default 'head' option reads file from the beginning

However, I'd agree with the implication of Michael Hampton's comment - the right way to deal with this is to reinstate the use of dbfile and use the unban functionality.

Improve this answer
1
  • OK point taken. We've been doing it this way for years so now it feels like a chore attempting to find out the user's IP address, attempting to find out if they're banned, and then unbanning them. Previously we'd just re-load Fail2Ban and see if the user was able to get access again. Quick and dirty I admit, but I guess we'll have to get used to unbanning them manually in the future.
    – MrCarrot
    Sep 20, 2016 at 8:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .