Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1823746
Summary: | fail2ban-firewalld default action uses unsupport direct rule, should use rich-rule | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Philip Fritzsche <fedora> |
Component: | fail2ban | Assignee: | Orion Poplawski <orion> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel8 | CC: | anon.amish, axel.thimm, bloch, hobbes1069, orion, rkudyba, vonsch |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | fail2ban-0.11.1-6.fc30 fail2ban-0.11.1-6.fc31 fail2ban-0.11.1-6.fc32 fail2ban-0.11.1-6.el8 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-04-30 02:51:10 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Philip Fritzsche
2020-04-14 11:52:09 UTC
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. |