Permanent ban (bantime=-1) causes failure when using firewalld

[Tedderouni]

Environment:

Fill out and check ([x]) the boxes which apply. If your Fail2Ban version is outdated,
and you can't verify that the issue persists in the recent release, better seek support
from the distribution you obtained Fail2Ban from

• Fail2Ban version (including any possible distribution suffixes):
• OS, including release name/version:
• Fail2Ban installed via OS/distribution mechanisms
• You have not applied any additional foreign patches to the codebase
• Some customizations were done to the configuration (provide details below is so)

The issue:

I've set up a vanilla install of CentOS 7.5 with firewalld and fail2ban. When I try to set bantime = -1, fail2ban fails without warning. I've tested this with the only other change to the default config being to enable the sshd jail. When I leave bantime at the default setting it works as expected.

Steps to reproduce

1. Install CentOS 7.5 minimal installation
2. sudo yum -y install epel-release
3. sudo yum -y install fail2ban-firewalld
4. Create /etc/fail2ban/jail.local with the following contents:

[sshd]
enabled = true
bantime = -1

5. sudo systemctl start fail2ban

Expected behavior

Fail2ban starts and creates the appropriate firewall rule for the sshd jail. The rule should look something like this:

# firewall-cmd --direct --get-all-rules
ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable

Also, an error message should be displayed from the startup script if the any errors occur while creating jails or in other steps.

Observed behavior

The startup command exits without displaying any error message, and the fail2ban service status also shows no error message.
The fail2ban process is running.
No firewall rule is created as shown by firewall-cmd --direct --get-all-rules.
Running systemctl status fail2ban looks as expected.
Running systemctl status firewalld -l shows the following error messages:

firewalld[703]: WARNING: '/usr/sbin/iptables-restore --wait=2 -n' failed: iptables-restore v1.4.21: Set fail2ban-sshd doesn't exist.

                Error occurred at line: 2
                Try 'iptables-restore -h' or 'iptables-restore --help' for more information.
firewalld[703]: ERROR: COMMAND_FAILED

The fail2ban log shows the messages shown below.

Any additional information

Running CentOS 7.5 (1804), with the following relevant package versions:
fail2ban-server-0.9.7-1.el7.noarch
fail2ban-firewalld-0.9.7-1.el7.noarch
ipset-6.29-1.el7.x86_64
firewalld-0.4.4.4-14.el7.noarch

Configuration, dump and another helpful excerpts

Any customizations done to /etc/fail2ban/ configuration

Only the following settings as mentioned above:

# cat jail.local
[sshd]
enabled = true
bantime = -1

Relevant parts of /var/log/fail2ban.log file:

2018-07-14 19:25:17,462 fail2ban.jail           [21346]: INFO    Jail 'sshd' started
2018-07-14 19:25:17,969 fail2ban.action         [21346]: ERROR   ipset create fail2ban-sshd hash:ip timeout -1
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable -- stdout: ''
2018-07-14 19:25:17,969 fail2ban.action         [21346]: ERROR   ipset create fail2ban-sshd hash:ip timeout -1
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable -- stderr: "ipset v6.29: Syntax error: '-1' is out of range 0-4294967\nError: COMMAND_FAILED\n"
2018-07-14 19:25:17,969 fail2ban.action         [21346]: ERROR   ipset create fail2ban-sshd hash:ip timeout -1
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable -- returned 13
2018-07-14 19:25:17,969 fail2ban.actions        [21346]: ERROR   Failed to start jail 'sshd' action 'firewallcmd-ipset': Error starting action

Relevant lines from monitored log files in question:

N/A

[sebres]

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"]

[alaahariri]

Hello,

I have exactly the same error for firewalld. However, I am not using permanent bantime. In the firewalld log file, the following error repeating everytimg:

 ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.4.21: Set fail2ban-ssh doesn't exist.

Error occurred at line: 2
Try `iptables-restore -h' or 'iptables-restore --help' for more information.

I have exactly the same configuration of the original post. In fail2ban log file, there is no any error. The problem is only with firewalld.

Can you please help me on how to fix this?

[sebres]

I have exactly the same error for firewalld.

Nope, the issue describes supplying of wrong timeout parameter (of persistent jails) caused error Syntax error: '-1' is out of range, your error seems to be Set fail2ban-ssh doesn't exist.
But if you nevertheless mean, you seems to have "exactly the same error" (and fail2ban v.0.9.x), I described above how to fix it... Simply set bantime=0 as a parameter of action (not jail), or even set it as default in your jail.local:

[DEFAULT]
action_ = %(banaction)s[name=%(__name__)s, bantime="0", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

In newer versions of fail2ban it should be already fixed.

If it is not the same, then something seems to delete your chain or a set fail2ban-ssh by running fail2ban.
E. g. that may be missing dependencies (so for example firewall reloaded without fail2ban), or some service which reset rules created by fail2ban.
In this case the only "repair" possibility I see at the moment - to restart fail2ban.
And try to find and fix the service which causes that to avoid it in the future.

---

Note to me: still one reason to fulfill #980.

[alaahariri]

Dear Sergey,

But if you nevertheless mean, you seems to have "exactly the same error" (and fail2ban v.0.9.x), I described above how to fix it... Simply set bantime=0 as a parameter of action (not jail), or even set it as default in your jail.local

Yes, I meant I am getting exactly the same error message. I have fail2ban version 0.9.7-1.e17 However, I already followed your fix above with no luck. My server is Centos 7. Please see the output of the below commands:

# systemctl status fail2ban

● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; vendor preset: disabled)
   Active: active (running) since Sat 2019-07-20 13:38:08 +03; 22min ago
     Docs: man:fail2ban(1)
  Process: 2727 ExecStop=/usr/bin/fail2ban-client stop (code=exited, status=0/SUCCESS)
  Process: 2768 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=0/SUCCESS)
 Main PID: 2771 (fail2ban-server)
   CGroup: /system.slice/fail2ban.service
           └─2771 /usr/bin/python2 -s /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b

Jul 20 13:38:07  systemd[1]: Stopped Fail2Ban Service.
Jul 20 13:38:07  systemd[1]: Starting Fail2Ban Service...
Jul 20 13:38:08  fail2ban-client[2768]: 2019-07-20 13:38:08,011 fail2ban.server         [2769]: INFO    Starting Fail2ban v0.9.7
Jul 20 13:38:08  fail2ban-client[2768]: 2019-07-20 13:38:08,012 fail2ban.server         [2769]: INFO    Starting in daemon mode
Jul 20 13:38:08  systemd[1]: Started Fail2Ban Service.

# firewall-cmd --direct --get-all-rules

ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable ipv4 filter INPUT 0 -p tcp -m multiport --dports 0:65535 -m set --match-set fail2ban-ssh src -j REJECT --reject-with icmp-port-unreachable

# systemctl status firewalld

● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-07-20 15:50:32 +03; 1h 16min ago
     Docs: man:firewalld(1)
 Main PID: 643 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─643 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Jul 20 15:50:30  systemd[1]: Starting firewalld - dynamic firewall daemon...
Jul 20 15:50:32  systemd[1]: Started firewalld - dynamic firewall daemon.
Jul 20 15:50:34  firewalld[643]: ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.4.21: Set fail2ban-ssh doesn't exist.

                                                Error occurred at line: 2
                                                Try `iptables-restore -h' or 'iptables-restore --help' for more information.
Jul 20 15:50:34  firewalld[643]: ERROR: COMMAND_FAILED: Direct: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.4.21: Set fail2ban-ssh doesn't exist.

                                                Error occurred at line: 2
                                                Try `iptables-restore -h' or 'iptables-restore --help' for more information.

I reinstalled fail2ban and firwalld with no luck. The content of jail.local is as follows:

[DEFAULT]
ignoreip = 127.0.0.0/8
bantime  = 86400
findtime = 86400
maxretry = 5

# Override /etc/fail2ban/jail.d/00-firewalld.conf:
banaction = firewallcmd-ipset

[sshd]
enabled = true

[ssh]
enabled  = true
filter   = sshd
action   = %(action_)s
logpath  = /var/log/secure
maxretry = 5

So what is going wrong? Am I missing anything? I am a developer who knows few about servers.

Thank you!

[sebres]

Hmm...

Our action firewallcmd-ipset does not create permanent rules.
I don't know firewalld innards (not use it and therefore not so familiar), but it seems to use iptables-restore, even to restore permanent rules.
The error you see (Set fail2ban-ssh doesn't exist.), if you're starting firewalld, looks like some persistent rule, which it tries to restore.

The only one explanation I see at the moment: For some reasons something (or possibly you at some day) have obtained fail2ban chain as some permanent rule in firewalld, but because in chain related ipset is not yet created to start time point, it fails obviously.

Either you need to delete (manually) this rule (and possibly some others) in firewalld. Or you should create ipset's before firewalld going started (some service and add dependency in firewalld.service).
But normally you should not use fail2ban chains in your own firewalld rules (or other services).

If I were you, I'd stop fail2ban and delete all remaining rules with name matching fail2ban-* manually, something like:

firewall-cmd --permanent --direct --remove-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports ssh -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable 
firewall-cmd --permanent --direct --remove-rule ipv4 filter INPUT 0 -p tcp -m multiport --dports 0:65535 -m set --match-set fail2ban-ssh src -j REJECT --reject-with icmp-port-unreachable

[alaahariri]

Your solution worked like a charm. Thanks a million. I have been struggling with it especially that Google has no results related to the same error message except this page.

I want to note that while manually deleting the 2 rules, I got the following warning for one of them only.

Warning: NOT_ENABLED: rule '['-p', 'tcp', '-m', 'multiport', '--dports', 'ssh', '-m', 'set', '--m atch-set', 'fail2ban-sshd', 'src', '-j', 'REJECT', '--reject-with', 'icmp-port-unreachable']' is not in 'ipv4:filter:INPUT'

So having no warning for the other rule would confirm your explanation:

The only one explanation I see at the moment: For some reasons something (or possibly you at some day) have obtained fail2ban chain as some permanent rule in firewalld, but because in chain related ipset is not yet created to start time point, it fails obviously.

I have no error messages and clean log files now.

Have a wonderful life.

[raviktiwari007]

Hi @sebres picking from the subject line, I am facing issues with Permanent ban (bantime=-1)

I am using Virtualmin which has Fail2Ban v0.10.2

In order to configure permanent ban, in jail.local, I set the "bantime = -1"

But now logwatch has started throwing error:
7f0fc88522c0 -- stderr: "ipset v6.34: Syntax error: '-1' is out of range 0-4294967": 3 Time(s)

So I have 3 questions:

1.> I have now changed it to: "bantime = 4294967" but this is not a permanent block - so what else I can do?

2.> Where does all the blocked IP Address get stored (just in case I want to see all the banned ip in one place). Will it be in "hosts.deny"?

3.> What happens when I have thousands and millions of ip address in my blocked list? I mean the file size will increase, the initial scan will get longer, so will it slow down the system? So does that mean we should refresh the "blocked list" periodically?

Many Thanks,
Rav

[sebres]

1. It is fixed in newest version
2. where the IPs are stored in net-filter is the matter of action used for that, ipset stores it in ipset hash tables (memory); in fail2ban they are stored internally in memory and sqlite database
3. this is the main reason why I say everywhere "don't use persistent banning". There are many better alternatives for instance version 0.11 has an incremental banning:

# incremental ban-time:
bantime.increment = true
# max ban-time 7 week:
bantime.maxtime = 7w

[raviktiwari007]

Thanks @sebres

1.> What is the latest version? Is it ready and available or about to be released? Is there a simple command to upgrade it without loosing previous settings and configurations?

2.> Does that mean all jails should have same action (as far as storing IP is concerned or else every jail will be stroring IP address at different locations)? Should I look for action.d and then respective jail.conf

3.>Thanks for this. Can I jsut go ahead and use the command that you suggested. Rememeber, I am still on "Fail2Ban v0.10.2". Will it still work?