Red Hat Bugzilla – Bug 979622
[RFE] fail2ban should use firewall-cmd instead of iptables
Last modified: 2014-09-22 20:05:15 EDT
Created attachment 766740 [details]
Description of problem:
fail2ban has only actions (in actions.d) for iptables, not for firewall-cmd.
But when running firewalld, using iptables rules makes problems because the rules added to netfilter are sometimes in a wrong order. firewalld does not care about other netfilter rules.
I provide a new action file that is a copy of iptables-new.conf but uses firewall-cmd instead of iptables.
I attatch the action file which can be installed in (for example)
It contains some comments that describes what I have done.
These comments may be removed when the file is included in the fail2ban package or the upstream repository.
There is an important note:
fail2ban is not allowed by SELinux to use "firewall-cmd".
There are new SELinux rules neccessary to allow this.
I will create a new bug report for SELinux for this problem and place a notice here later.
Version-Release number of selected component (if applicable):
See bug #979624 for SELinux module policy file.
Created attachment 768553 [details]
I found a typo error in the action file (a paranthesis was to much).
Created attachment 791126 [details]
firewalld-0.3.4-1.fc19 requires some changes:
- "--remove-rule" requires the use of a priority number.
- "--get-rules" returns a priority number now, so no change in the for loop is required.
selinux-policy-targeted-3.12.1-73.fc19 contains all neccessary selinux rules required for using firewall-cmd in fail2ban, so no additional rules are required.
Can you file a bug/PR upstream? https://github.com/fail2ban/fail2ban/
That would be the best place to get this integrated.
Unless I hear otherwise from Edgar Hoch in the next week, I'm going to attempt to bridge the two communities by opening an issue at https://github.com/fail2ban/fail2ban/issues .
I searched through the Issues and https://github.com/fail2ban/fail2ban/blob/master/ChangeLog and found no evidence that this issue has been raised or addressed already. I'm a user that would really like a "supported" fail2ban install for Fedora 19 that I wouldn't have to babysit every time there's a new version. While I don't have the time or patience to do what Edgar did (namely figure out fail2ban and firewall-cmd well enough to create a new config file), I do think I can attempt the person to person parts of getting this file added to Fail2Ban so it can simply flow downstream into Fedora's packaging system.
It would be nice if this was upstream but I don't see it as being a blocker for fixing in fedora. This is just a configuration file change not a software change.
There probably also needs to be a change to the .service file to make fail2ban dependent/wait for on firewalld.
The upstream is in progress - see https://github.com/fail2ban/fail2ban/issues/395 and https://github.com/fail2ban/fail2ban/pull/396 . They may be waiting to see if https://fedorahosted.org/firewalld/ticket/10 gets any traction, and if it doesn't they'll just handle it using the current (ugly) approach.
A question that came into my mind several times for fail2ban: Why not using ipsets (http://ipset.netfilter.org/)?
This way only one rule in the firewall would be needed and the set could be used in more ways then. A simple log and DROP/REJECT combination would also be possible with this.
fail2ban only needs to take care of the set and one rule in the firewall then. The set could be easily created, updated, cleared. The use of the set in the firewall is much better for the throughput also.
Thomas - probably an excellent question, but one that should be put to upstream directly. Would you please file an issue at https://github.com/fail2ban/fail2ban/issues ? Thanks.
The odds of firewalld fixing https://fedorahosted.org/firewalld/ticket/10 for FC19/20 is slim to none.
Can we please get this fixed in fedora now for the current version of fail2ban especially as the fix is accepted upstream with only tweaks based on the firewalld issue?
Fail2ban master was just updated - see https://github.com/fail2ban/fail2ban/issues/395 and https://github.com/fail2ban/fail2ban/pull/396. Based on looking at historical release patterns, it looks like Fail2ban releases roughly every 6 months (except for chemspills), and so 0.8.11 is probably due for release in the next month or two. Once that releases and gets packaged for Fedora, that should close this ticket.
Fail2ban done a prerelease including an action for firewalld https://github.com/fail2ban/fail2ban/releases/tag/0.8.11.pre1
The fix for firewalld ticket 10 is here https://github.com/fail2ban/fail2ban/pull/412 however it required an as yet unreleased version of firewalld. I'll merge it after a release exists unless you can think of a better way to do it.
Thomas, yes, ipsets are pretty cool and there's actions for them https://github.com/fail2ban/fail2ban/tree/master/config/action.d. They should be easy enough to backport to older fail2ban version as it doesn't depend on code changes.
your friendly fail2ban upstream dev
> The odds of firewalld fixing https://fedorahosted.org/firewalld/ticket/10 for FC19/20 is slim to none.
Looks hopeful here:
As such I'll be requiring 0.3.8 in fail2ban-0.8.11 (release in next few days)
Is good. Will that be able to go into f19 or only 20+?
> Is good. Will that be able to go into f19 or only 20+?
Will be up to the Fedora maintainer. No reason why https://github.com/fail2ban/fail2ban/blob/master/config/action.d/firewall-cmd-direct-new.conf couldn't be backported to f19 (no code changes required) but its not my call.
So firewall-cmd-direct-new.conf is now distributed in 0.8.11.1.fc19 from updates testing, however, it is not enabled in jail.conf, nor is an alternate jail.conf distributed.
Any chance of getting this in?
To try it out, first I copied firewall-cmd-direct-new.conf to firewall-cmd.conf as fail2ban warns that its name is too long. Then in jail.conf I added:
enabled = true
filter = sshd
action = firewall-cmd[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=root, firstname.lastname@example.org, sendername="Fail2Ban"]
logpath = /var/log/secure
maxretry = 5
Nov 27 17:09:10 domex fail2ban.actions: WARNING [ssh-firewall-cmd] Ban XXX.YYY.ZZZ.193
Nov 27 17:09:10 domex fail2ban.actions.action: ERROR firewall-cmd --direct --get-chains ipv4 filter | grep -q 'fail2ban-SSH[ \t]' returned 100
Nov 27 17:09:10 domex fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment
Nov 27 17:09:12 domex fail2ban.actions.action: ERROR firewall-cmd --direct --get-chains ipv4 filter | grep -q 'fail2ban-SSH[ \t]' returned 100
Nov 27 17:09:12 domex fail2ban.actions.action: CRITICAL Unable to restore environment
To fix this, I had to editthe actioncheck line in firewall-cmd.conf to check for the case where fail2ban-SSH is the only chain defined:
actioncheck = firewall-cmd --direct --get-chains ipv4 filter | grep -q 'fail2ban-<name>$\|fail2ban-<name>[[space]]'
Thanks Joel for reporting this in both places: https://github.com/fail2ban/fail2ban/pull/396#issuecomment-29433845
I will take care about this bug.
(In reply to Joel from comment #19)
> To fix this, I had to editthe actioncheck line in firewall-cmd.conf to check
> for the case where fail2ban-SSH is the only chain defined:
> actioncheck = firewall-cmd --direct --get-chains ipv4 filter | grep -q
Maybe it's personal opinion but `grep -Eq 'fail2ban-SSH$|fail2ban-SSH '` looks more readable for me and should work same way as your proposal so I will use it.
(In reply to Adam Tkac from comment #22)
> (In reply to Joel from comment #19)
> > To fix this, I had to editthe actioncheck line in firewall-cmd.conf to check
> > for the case where fail2ban-SSH is the only chain defined:
> > actioncheck = firewall-cmd --direct --get-chains ipv4 filter | grep -q
> > 'fail2ban-<name>$\|fail2ban-<name>[[space]]'
> Maybe it's personal opinion but `grep -Eq 'fail2ban-SSH$|fail2ban-SSH '`
> looks more readable for me and should work same way as your proposal so I
> will use it.
Should be `grep -Eq 'fail2ban-<name>$|fail2ban-<name> '`, of course...
Thanks Adam. Will we have new rpms in the system soon?
What do you think of Daniel's suggestion to remove the actioncheck completely? (At the fail2ban gitpull 396 linked above.
Will the action.d file be renamed to something shorter? Also can we change the default entry in jail.conf to use the firewalld script or at least get a disabled entry into the jail.conf (like I have above)?
I'm renaming it upstream : https://github.com/fail2ban/fail2ban/pull/463/files
also too long was:
(In reply to Joel from comment #24)
> Thanks Adam. Will we have new rpms in the system soon?
> What do you think of Daniel's suggestion to remove the actioncheck
> completely? (At the fail2ban gitpull 396 linked above.
I don't know fail2ban internals well so I'm afraid I'm not the right person who can decide if actioncheck should be dropped. This decision must be made in upstream and then it can be pulled into Fedora.
> Will the action.d file be renamed to something shorter? Also can we change
> the default entry in jail.conf to use the firewalld script or at least get a
> disabled entry into the jail.conf (like I have above)?
This should be also done in upstream. Since upstream developers still don't push any change to firewall-cmd-direct-new, I propose to leave it as is until upstream push rename commit to the main fail2ban repo. I tested customized jail.conf with firewall-cmd-direct-new action (action = firewall-cmd-direct-new[name=SSH, port=ssh, protocol=tcp]) and everything worked fine so you can use it as well.
fail2ban-0.8.11-1.el6 has been submitted as an update for Fedora EPEL 6.
fail2ban-0.8.11-2.fc19 has been submitted as an update for Fedora 19.
fail2ban-0.8.11-2.fc18 has been submitted as an update for Fedora 18.
I finally did the merge of https://github.com/fail2ban/fail2ban/pull/463 ( rename firewall-cmd-direct-new to firewall-cmd-new ) in upstream.
>> What do you think of Daniel's suggestion to remove the actioncheck
>> completely? (At the fail2ban gitpull 396 linked above.
> I don't know fail2ban internals
actioncheck is a command executed before each ban to check if the environment is stable. If it fails it executes a actionstop and actionstart and before doing the ban. Both a grep change and a removal will both correct the usability of firewall-cmd-new.
I'll see what I can do to prod the other developers towards a consensus here and let you know.
Thanks for packaging up the modifications Adam.
What exactly is the "-new" supposed to transmit here? There never was an old firewall-cmd implementation. The fact that the action.d script was copied from something else with "-new" in the name isn't a good reason. At most that would documented in the internal comments to the action.d script.
Since firewalld is default on fedora, fail2ban should default to having firewalld support enabled (in jail.conf) on fedora (at least from fc20 onwards).
> What exactly is the "-new" supposed to transmit here?
Is was consistent with the other stateful firewall rules that have --state NEW in them.
As a meaningful name it does have some serious issues.
I can look was should be done for 0.9 and getting that version out in a meaningful timeframe for fc20. 0.9 also has a easy mechanism for setting a default action on all jails which it sounds like you want to use.
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing fail2ban-0.8.11-2.el6'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Thomas - firewallcmd / ipsets as requested : https://github.com/fail2ban/fail2ban/pull/490
fail2ban-0.8.11-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
fail2ban-0.8.11-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
fail2ban-0.8.11-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
FYI, Looks like fail2ban-0.9-0.3.git1f1a561.fc20.noarch regresses this fix.
C.f. bug #1046816