As per documentation, setting jail bantime to a negative value should result in a permanent ban. However once that is done, the following behavior changes, compared to when setting bantime to a positive integer:
1) ipset list
doesn't show fail2ban-sshd hash table
2) firewall-cmd --direct --get-all-rules
is empty
3) /var/log/fail2ban.log
becomes a single line. interesting entry
sshd[25772]: Invalid user ubuntu from 93.174.89.88 port 37477', 'ip':
'93.174.89.88', 'ipmatches': at 0x7f4588f9dc08>,
'ipfailures': at 0x7f4588f9daa0>, 'time':
1536301842.088076, 'failures': 1443, 'ipjailfailures': at 0x7f4588f9dd70>})': Error banning 93.174.89.88
4) /var/log/messages
has the following
firewalld[916]: WARNING: '/usr/sbin/iptables-restore –wait=2 -n'
failed: iptables-restore v1.4.21: Set fail2ban-sshd doesn't
exist.#012#012Error occurred at line: 2#012Try 'iptables-restore -h'
or 'iptables-restore –help' for more information. firewalld[916]:
ERROR: COMMAND_FAILED
The only command working as expected is fail2ban-client status sshd
, however the IPs that are shown to be banned still try to connect. I think the root of all problems is that ipset isn't created for whatever reason once the integer is negative.
Any ideas? Also, does the command fail2ban-client reload
has the same affect as systemctl restart fail2ban.service
when applying new configuration?
In my case, /etc/fail2ban/jail.d/local.conf
[sshd]
enabled = true
bantime = -1
findtime = 3600
maxretry = 5
action = %(action_)s
Best Answer
This was a bug in older versions of fail2ban. It has since been fixed, but if your Linux distribution still ships that older version, you may also need a workaround.
The GitHub issue which explains the problem and fix also includes a workaround: