Bug 1850164 - default port in jail.conf is not compatible with firewalld-cmd syntax
Summary: default port in jail.conf is not compatible with firewalld-cmd syntax
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: fail2ban
Version: 39
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Shaw
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-23 15:53 UTC by Andy Wang
Modified: 2023-08-16 07:04 UTC (History)
11 users (show)

Fixed In Version: fail2ban-0.11.1-9.fc32 fail2ban-0.11.1-9.fc31 fail2ban-0.11.1-9.el8 fail2ban-1.0.2-1.fc36 fail2ban-1.0.2-1.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-12-27 00:42:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fail2ban fail2ban issues 2763 0 None closed nftables + multiport is broken 2020-08-22 02:42:34 UTC

Description Andy Wang 2020-06-23 15:53:54 UTC
Description of problem:
I tried to create a new jail without a `port` definition expecting it to work with similar to the ipset integration where the all of the ports were blocked

[sshd-repeat]
enabled = true
filter = sshd
maxretry = 25
findtime = 86400
bantime = 604800

This use to work fine but with the firewalld integration it fails with the following error:
2020-06-23 10:36:07,511 fail2ban.utils          [587974]: ERROR   7f70987efe00 -- exec: ports="0:65535"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='<banned ip>' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done
2020-06-23 10:36:07,511 fail2ban.utils          [587974]: ERROR   7f70987efe00 -- stderr: 'Error: INVALID_PORT: 0:65535'

This appears to be because the default port definition in jail.conf is 0:65535

I was able to workaround this by defining
port = 0-65535
but shouldn't the default value work properly with firewalld?

Comment 1 Richard Shaw 2020-06-24 11:46:55 UTC
I've been considering changing that, but then it breaks if someone changes back from nftables to iptables, but probably best to go ahead and do it.

Comment 2 Richard Shaw 2020-06-25 11:47:02 UTC
Upstream has committed an "on-the-fly" fix within the nftables configuration. Now I just need to figure out why one of the tests is failing.

Comment 3 Fedora Update System 2020-07-27 21:36:24 UTC
FEDORA-2020-68166b23ca has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-68166b23ca

Comment 4 Fedora Update System 2020-07-27 21:36:25 UTC
FEDORA-2020-3e043605f0 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3e043605f0

Comment 5 Fedora Update System 2020-07-28 01:45:45 UTC
FEDORA-EPEL-2020-3d92c1f42c has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3d92c1f42c

Comment 6 Fedora Update System 2020-07-28 15:20:24 UTC
FEDORA-2020-68166b23ca 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-68166b23ca`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-68166b23ca

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Fedora Update System 2020-07-28 15:36:24 UTC
FEDORA-EPEL-2020-3d92c1f42c 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-3d92c1f42c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2020-07-28 16:07:14 UTC
FEDORA-2020-3e043605f0 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-3e043605f0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3e043605f0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2020-08-05 01:20:29 UTC
FEDORA-2020-68166b23ca has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Fedora Update System 2020-08-05 02:16:19 UTC
FEDORA-2020-3e043605f0 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 11 Fedora Update System 2020-08-12 01:48:13 UTC
FEDORA-EPEL-2020-3d92c1f42c has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 12 Chris Adams 2020-08-22 02:44:15 UTC
This also appears to be a problem with fail2ban-0.11.1-9.el7.2 on CentOS+EPEL 7 with firewalld+iptables... I get "ERROR: INVALID_PORT: 0:65535" in the default config with fail2ban-{server,systemd,firewalld}.

Comment 13 mx 2022-10-17 01:57:08 UTC
it appear again after recent update of fail2ban-1.0.1-1.el9, in EPEL9

Err in log file /var/log/fail2ban.log:
2022-10-14 15:00:35,948 fail2ban.actions        [634349]: NOTICE  [recidive] Restore Ban *.*.*.*
2022-10-14 15:00:36,142 fail2ban.utils          [634349]: ERROR   7fbce155e7a0 -- exec: ports="0:65535"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="rule family='ipv4' source address='*.*.*.*' port port='$p' protocol='tcp' reject type='icmp-port-unreachable'"; done
2022-10-14 15:00:36,142 fail2ban.utils          [634349]: ERROR   7fbce155e7a0 -- stderr: 'Error: INVALID_PORT: 0:65535'
2022-10-14 15:00:36,142 fail2ban.utils          [634349]: ERROR   7fbce155e7a0 -- returned 102

Comment 14 Richard Shaw 2022-10-17 12:15:16 UTC
Upstream reverted the "fix" because lots of people still use iptables and not nftables. The quick fix would probably be to override in a jail.local "ports=0-65535" or change jail.conf. I need to think about how to fix this in the packaging. While the default is nftables on all current releases of Fedora (and EPEL I think) I don't want to prevent someone from using iptables if they want to.

Comment 15 Chris Adams 2022-10-17 14:13:07 UTC
(In reply to Richard Shaw from comment #14)
> While the default is nftables on all current releases of
> Fedora (and EPEL I think)

Just to note (in case it affects how this gets addressed): EPEL 7 uses iptables, EPEL 8 and 9 use nftables.

Comment 16 Richard Shaw 2022-10-17 14:31:12 UTC
Yeah, I was noodling on how to deal with that since it doesn't support "Recommends:" 

I may just have to force the iptables sub-package on it since they're unlikely to switch to nftables. 

%if 0%{?RHEL} < 8
Requires: fail2ban-iptables
%else
Recommends: fail2ban-nftables
%endif

Does EL 8 support recommends?

Comment 17 Sjoerd Mullender 2022-10-21 12:23:57 UTC
The easiest fix is to change
tr ", " " "
to
tr ":, " "- "

What this does is translate the colon in the port range to a minus and the comma separator into a space.
The original only did the latter.

Comment 18 Richard Shaw 2022-10-21 22:22:01 UTC
(In reply to Sjoerd Mullender from comment #17)
> The easiest fix is to change
> tr ", " " "
> to
> tr ":, " "- "
> 
> What this does is translate the colon in the port range to a minus and the
> comma separator into a space.
> The original only did the latter.

I may need a little more context as to what you're referring to. I don't use tr in the spec file anywhere. Is it somewhere in fail2bans build system?

Comment 19 Sjoerd Mullender 2022-10-22 08:42:12 UTC
The original bug report and comment 13 both show the tr command in question.
In Fedora 36 I see it in the file /etc/fail2ban/action.d/firewallcmd-rich-rules.conf.

Comment 20 Frank Crawford 2022-11-21 01:54:03 UTC
I've just been looking at this as well, and I agree that the fix that's recommended upstream is to add "ports=0-65535" in the [DEFAULT] block, but rather than putting in jail.local, why not have it added into jail.d/00-firewalld.conf for appropriate releases, i.e. all current Fedora and whatever EPEL uses nftables?

Just BTW, the incorrect port definition error only comes from the use of the default value, I'm pretty sure in all other case of multiple ports, it does not give a range, but only individual ports separated by commas.

Comment 21 Chen Chen 2022-12-17 05:49:34 UTC
Looks like the upstream is already applied a patch on 1.0.2. Maybe a simple version bump will help?

https://github.com/fail2ban/fail2ban/commit/a038fd5dfe8cb0714472833604735b83462a217d

Comment 22 Fedora Update System 2022-12-18 12:42:47 UTC
FEDORA-2022-bf03238d02 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-bf03238d02

Comment 23 Fedora Update System 2022-12-18 12:42:49 UTC
FEDORA-2022-2551057544 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-2551057544

Comment 24 Chen Chen 2022-12-18 12:52:08 UTC
Sorry for the last comment. It was incorrect.
That commit was reverted (https://github.com/fail2ban/fail2ban/commit/4b54a07d71a6ce1c85a3eae92bace6c0dadcdcfb) because firewalld use different syntax depending on iptables/nftables backend.

Comment 25 Fedora Update System 2022-12-19 02:15:50 UTC
FEDORA-2022-bf03238d02 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-bf03238d02`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-bf03238d02

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 26 Fedora Update System 2022-12-19 02:24:44 UTC
FEDORA-2022-2551057544 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-2551057544`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2551057544

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 27 Fedora Update System 2022-12-27 00:42:18 UTC
FEDORA-2022-2551057544 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 28 Fedora Update System 2022-12-27 01:12:20 UTC
FEDORA-2022-bf03238d02 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 29 Peter Beurle 2023-07-30 06:45:26 UTC
(In reply to Sjoerd Mullender from comment #17)
> The easiest fix is to change
> tr ", " " "
> to
> tr ":, " "- "
> 
> What this does is translate the colon in the port range to a minus and the
> comma separator into a space.
> The original only did the latter.

A few weeks ago I did a fresh install of F37 and this is what got me going. I understand from various posts, depending on how the net filter is implemented will change the outcome. If installed from default it should work, so this is how it should ship? It is potentially a security issue as you could be under the misunderstanding that fail2ban is working when its not...

Comment 30 Richard Shaw 2023-07-30 11:54:39 UTC
Currently there's a bigger problem that I can't build fail2ban in rawhide but the python module asynchat was removed from Python 3.12 and it needs to be ported to asyncio.

Comment 31 Richard Shaw 2023-07-30 12:04:46 UTC
(In reply to Sjoerd Mullender from comment #17)
> The easiest fix is to change
> tr ", " " "
> to
> tr ":, " "- "
> 
> What this does is translate the colon in the port range to a minus and the
> comma separator into a space.
> The original only did the latter.

Took me a minute to find it, but I assume I need to change both instances here:

config/action.d/firewallcmd-rich-rules.conf:actionban = ports="<port>"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --add-rich-rule="%(fwcmd_rich_rule)s"; done
config/action.d/firewallcmd-rich-rules.conf:actionunban = ports="<port>"; for p in $(echo $ports | tr ", " " "); do firewall-cmd --remove-rich-rule="%(fwcmd_rich_rule)s"; done

Comment 32 Richard Shaw 2023-07-30 22:23:06 UTC
I can now get fail2ban to build at least for f38 and lower.

Here's some scratch builds for testing:
F38:
https://koji.fedoraproject.org/koji/taskinfo?taskID=104156139

F37:
https://koji.fedoraproject.org/koji/taskinfo?taskID=104156086

Comment 33 Fedora Release Engineering 2023-08-16 07:04:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.


Note You need to log in before you can comment on or make changes to this bug.