Strange behavior with fail2ban when permanently banning IPs

Question

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

Answer 1

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:

This is fixed in newer versions. For 0.9 you can simply overwrite bantime (timeout) parameter in action inside the jail (parameter timeout for ipset persistent rule is 0).

[sshd]
bantime = -1
action = %(banaction)s[name=%(__name__)s, bantime=0, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

Answer 2

ipset can only have a minimum timeout of 0 or a maximum timeout of 2147483 see http://ipset.netfilter.org/ipset.man.html

timeout All set types supports the optional timeout parameter when creating a set and adding entries. The value of the timeout parameter for the create command means the default timeout value (in seconds) for new entries. If a set is created with timeout support, then the same timeout option can be used to specify non-default timeout values when adding entries. Zero timeout value means the entry is added permanent to the set. The timeout value of already added elements can be changed by re-adding the element using the -exist option. The largest possible timeout value is 2147483 (in seconds).

the value that is used for the creation of the ipset's timeout is the conf value bantime. since you have a -1 in the bantime conf value, your system is having an error while creating the ipset for fail2ban's jails, since there is no ipset created because you are in essence having the system run something like this:

ipset create fail2ban-sshd hash:ip timeout -1

timeout value range that is acceptable is 0-2147483 seconds. afterwards without an ipset named fail2ban-sshd running something like:

firewall-cmd --direct --add-rule ipv4 filter INPUT_direct 0 -p tcp -m multiport --dports http,https -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable

or:

iptables -t filter -I INPUT_direct 1 -p tcp -m multiport --dports http,https -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable

would certainly fail as there is no ipset named fail2ban-sshd that has been created. you must change your -1 bantime to 0.