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 - fail2ban-firewalld default action uses unsupport direct rule, should use rich-rule
Summary: fail2ban-firewalld default action uses unsupport direct rule, should use rich...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: fail2ban
Version: epel8
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-14 11:52 UTC by Philip Fritzsche
Modified: 2024-04-04 15:33 UTC (History)
7 users (show)

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:
Clone Of:
Environment:
Last Closed: 2020-04-30 02:51:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Philip Fritzsche 2020-04-14 11:52:09 UTC
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

Comment 1 Richard Shaw 2020-04-14 12:10:51 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).

Comment 2 Richard Shaw 2020-04-14 12:18:58 UTC
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?

Comment 3 Orion Poplawski 2020-04-15 21:55:25 UTC
At this point, probably not.

Comment 4 Richard Shaw 2020-04-16 12:27:45 UTC
Performing builds now. As the config files are marked "noreplace" existing edited 00-firewalld.conf files will not be overwritten.

Comment 5 Fedora Update System 2020-04-22 14:28:15 UTC
FEDORA-2020-30b046478a has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-30b046478a

Comment 6 Fedora Update System 2020-04-22 14:28:17 UTC
FEDORA-EPEL-2020-f5c952ab51 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f5c952ab51

Comment 7 Fedora Update System 2020-04-22 14:28:18 UTC
FEDORA-2020-caae9d7741 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-caae9d7741

Comment 8 Fedora Update System 2020-04-22 14:28:18 UTC
FEDORA-2020-41b4fce889 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-41b4fce889

Comment 9 Fedora Update System 2020-04-22 19:27:15 UTC
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.

Comment 10 Fedora Update System 2020-04-22 20:14:22 UTC
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.

Comment 11 Fedora Update System 2020-04-22 20:29:18 UTC
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.

Comment 12 Fedora Update System 2020-04-23 20:45:28 UTC
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.

Comment 13 Fedora Update System 2020-04-30 02:51:10 UTC
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.

Comment 14 Fedora Update System 2020-04-30 03:43:10 UTC
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.

Comment 15 RobbieTheK 2020-04-30 15:31:47 UTC
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

Comment 16 Richard Shaw 2020-04-30 15:50:25 UTC
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.

Comment 17 RobbieTheK 2020-04-30 15:58:38 UTC
(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

Comment 18 Richard Shaw 2020-04-30 16:03:59 UTC
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.

Comment 19 Richard Shaw 2020-04-30 16:15:28 UTC
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

Comment 20 RobbieTheK 2020-04-30 20:07:58 UTC
(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:

Comment 21 Fedora Update System 2020-05-01 04:05:30 UTC
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.

Comment 22 Fedora Update System 2020-05-07 00:40:57 UTC
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.

Comment 23 Adam Huffman 2020-05-31 21:51:40 UTC
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.

Comment 24 RobbieTheK 2020-06-01 00:13:10 UTC
(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?

Comment 25 Richard Shaw 2020-06-01 11:16:46 UTC
(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.

Comment 26 Adam Huffman 2020-06-04 15:22:56 UTC
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'

Comment 27 Richard Shaw 2020-06-05 13:24:02 UTC
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.

Comment 28 Adam Huffman 2024-04-04 15:33:40 UTC
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.


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