Description of problem: The default banaction set by fail2ban-firewalld in the jail.d/00-firewalld.conf file is firewallcmd-ipset. This will run 'firewall-cmd --direct' iptables-commands as the action, which will not have any effect since firewalld uses nftables as its default backend (on CentOS 8). Changing the default banaction to firewallcmd-rich-rules fixes this issue. Version-Release number of selected component (if applicable): fail2ban 0.10.5-2.el8 fail2ban-firewalld 0.10.5-2.el8 firewalld 0.7.0-5.el8 How reproducible: Installing the packages will produce this issue. Steps to Reproduce: 0. Use a system with firewalld using nftables as the backend 1. Install fail2ban with fail2ban-firewalld 2. Enable any jail (e.g. sshd) in fail2ban Actual results: IP adresses will not be banned by the firewall and can still connect to the system. Expected results: IP adresses will get banned via firewalld. Additional info: Tested on CentOS 8.1.1911
I noticed this on Fedora as well and wasn't particularly happy about the use of legacy iptables but wasn't sure what to change to. I'll take a look but from what you say it sounds like it would be best to change all the releases to this method (Fedora & EPEL).
Just verified it seems to work well. While I'm at it, is there any reason not to update the EPEL branches to the latest version?
At this point, probably not.
Performing builds now. As the config files are marked "noreplace" existing edited 00-firewalld.conf files will not be overwritten.
FEDORA-2020-30b046478a has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-30b046478a
FEDORA-EPEL-2020-f5c952ab51 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f5c952ab51
FEDORA-2020-caae9d7741 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-caae9d7741
FEDORA-2020-41b4fce889 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-41b4fce889
FEDORA-EPEL-2020-f5c952ab51 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f5c952ab51 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-30b046478a has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-30b046478a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-30b046478a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-caae9d7741 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-caae9d7741` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-caae9d7741 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-41b4fce889 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-41b4fce889` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-41b4fce889 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-30b046478a has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-caae9d7741 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
With recidive jail and bantime = -1 (for permanent) I get these errors: 2020-04-30 11:29:55,293 fail2ban.utils [937290]: ERROR 7f14bda4e690 -- exec: ports="0:65535"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='103.4.165.137' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done 2020-04-30 11:29:55,294 fail2ban.utils [937290]: ERROR 7f14bda4e690 -- stderr: 'Error: INVALID_PORT: 0:65535' 2020-04-30 11:29:55,294 fail2ban.utils [937290]: ERROR 7f14bda4e690 -- returned 102 2020-04-30 11:29:55,295 fail2ban.actions [937290]: ERROR Failed to execute ban jail 'recidive' action 'firewallcmd-rich-rules' info 'ActionInfo({'ip': '103.4.165.137', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x7f14bda5af80>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x7f14bda53680>})': Error banning 103.4.165.137 2020-04-30 11:29:55,295 fail2ban.actions [937290]: NOTICE [recidive] Restore Ban 103.79.141.109 2020-04-30 11:29:55,755 fail2ban.utils [937290]: ERROR 7f14bda4e690 -- exec: ports="0:65535"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='103.79.141.109' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done 2020-04-30 11:29:55,756 fail2ban.utils [937290]: ERROR 7f14bda4e690 -- stderr: 'Error: INVALID_PORT: 0:65535' 2020-04-30 11:29:55,757 fail2ban.utils [937290]: ERROR 7f14bda4e690 -- returned 102
Can we get this logged as a new bug? I hate that the changed caused a new problem but ipset wasn't working well at all. Are you using allports? (noticing the ports="0:65535") It doesn't look like the "$p" is being expanded.
(In reply to Richard Shaw from comment #16) > Can we get this logged as a new bug? I hate that the changed caused a new > problem but ipset wasn't working well at all. I can do that. There are several threads about this at Fail2ban's GitHub. > Are you using allports? (noticing the ports="0:65535") No I'm using banaction = firewallcmd-rich-rules in [DEFAULT] For pam-generic jail I do have: port = all
Ok, this may be simpler than I thought. It's choking on the 0:65535 but would accept 0-65535, so I just need to see how that's being generated.
in the main jail.conf (or setup a jail.local) change: # Ports to be banned # Usually should be overridden in a particular jail port = 0:65535 to # Ports to be banned # Usually should be overridden in a particular jail port = 0-65535
(In reply to Richard Shaw from comment #19) > in the main jail.conf (or setup a jail.local) change: > > # Ports to be banned > # Usually should be overridden in a particular jail > port = 0:65535 > > to > > # Ports to be banned > # Usually should be overridden in a particular jail > port = 0-65535 OK I have that for tbe pam-generic jail now and it works. However recidive jail is never triggered. I've tried various combinations of the below (# is a comment) and no bans [recidive] enabled = true filter = recidive action = %(action_mwl)s banaction = %(banaction_allports)s #action = iptables-allports[name=recidive] # sendmail-whois-lines[name=recidive, logpath=/var/log/fail2ban.log*] #bantime = 7776000 ; 3 months bantime = -1 ; permanent ban #action = %(banaction)s[name=%(__name__)s, bantime=0, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"] findtime = 86400 ; 1 day logpath = /var/log/fail2ban.log /var/log/fail2ban.log-*[!.gz] #action = firewallcmd-ipset[name=recidive] #banaction = firewallcmd-ipset[bantime=0] maxretry = 4 No errors from this either: fail2ban-client status recidive Status for the jail: recidive |- Filter | |- Currently failed: 0 | |- Total failed: 0 | `- Journal matches: _SYSTEMD_UNIT=fail2ban.service PRIORITY=5 `- Actions |- Currently banned: 0 |- Total banned: 0 `- Banned IP list:
FEDORA-2020-41b4fce889 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-f5c952ab51 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
I am still seeing the error even with the latest update fail2ban-server-0.11.1-6.fc32.noarch In particular, jail.conf still has port = 1:65535 I found that overriding this in a local sshd jail still produced these errors: 2020-05-31 22:46:36,481 fail2ban.utils [254236]: ERROR 7f45e6ad2cf0 -- exec: ports="1:65535"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='85.209.0.100' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done 2020-05-31 22:46:36,481 fail2ban.utils [254236]: ERROR 7f45e6ad2cf0 -- stderr: 'Error: INVALID_PORT: 1:65535' 2020-05-31 22:46:36,481 fail2ban.utils [254236]: ERROR 7f45e6ad2cf0 -- returned 102 2020-05-31 22:46:36,481 fail2ban.actions [254236]: ERROR Failed to execute ban jail 'sshd' action 'firewallcmd-rich-rules' info 'ActionInfo({'ip': '<remote ip>', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x7f45e623ee50>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x7f45e623f550>})': Error banning <remote ip> sshd.local: [sshd] enabled = true port = ssh action = firewallcmd-rich-rules logpath = %(sshd_log)s maxretry = 3 bantime = 86400 findtime = 86400 Also tried adding: [DEFAULT] port = 1-65535 to the top of sshd.local This had no apparent effect.
(In reply to Adam Huffman from comment #23) > I am still seeing the error even with the latest update > fail2ban-server-0.11.1-6.fc32.noarch > > In particular, jail.conf still has > > port = 1:65535 > > I found that overriding this in a local sshd jail still produced these > errors: > > 2020-05-31 22:46:36,481 fail2ban.utils [254236]: ERROR > 7f45e6ad2cf0 -- exec: ports="1:65535"; for p in $(echo $ports | tr ", " " > "); do firewall-cmd --add-rich-rule="rule family='ipv4' source > address='85.209.0.100' port port='$p' protocol='tcp' reject > type='icmp-port-unreachable'"; done > 2020-05-31 22:46:36,481 fail2ban.utils [254236]: ERROR > 7f45e6ad2cf0 -- stderr: 'Error: INVALID_PORT: 1:65535' > 2020-05-31 22:46:36,481 fail2ban.utils [254236]: ERROR > 7f45e6ad2cf0 -- returned 102 > 2020-05-31 22:46:36,481 fail2ban.actions [254236]: ERROR Failed to > execute ban jail 'sshd' action 'firewallcmd-rich-rules' info > 'ActionInfo({'ip': '<remote ip>', 'family': 'inet4', 'fid': <function > Actions.ActionInfo.<lambda> at 0x7f45e623ee50>, 'raw-ticket': <function > Actions.ActionInfo.<lambda> at 0x7f45e623f550>})': Error banning <remote ip> > > sshd.local: > > [sshd] > enabled = true > port = ssh > action = firewallcmd-rich-rules > logpath = %(sshd_log)s > maxretry = 3 > bantime = 86400 > findtime = 86400 > > Also tried adding: > > [DEFAULT] > port = 1-65535 > > to the top of sshd.local > > This had no apparent effect. Yep because action.d/firewallcmd-common.conf also has port = 1:65535. So either remove it from that file or override it in the respective service, so in your case in [sshd]. I don't get how this got bifurcated upstream. Why not be consistent with the port convention?
(In reply to RobbieTheK from comment #24) > I don't get how this got bifurcated upstream. Why not be consistent with the > port convention? Because it's not about fail2ban, but the backend. Iptables supports the ":" separator, but nftables (the default in f32), only supports "-". I need to patch the package but I only recently took over maintenance of fail2ban on Fedora.
Thought I should mention that I see these warnings: Jun 04 16:06:37 nuc.localdomain firewalld[85158]: WARNING: NOT_ENABLED: 'rule family="ipv4" source address="<remote IP>" port port="1-65535" protocol="tcp" reject type="icmp-port-unreachable"' not in 'FedoraServer'
Did you switch zones at some point? I know firewalld segregates a lot of stuff based on the zone it's in. I'm honestly not familiar enough with the interaction between firewalld zones and fail2ban to guess.
In case this is useful for others, adding a `--zone` statement to the banning action for firewallcmd solved this. There is a comment in the file including this suggestion.