Bug 979622 - [RFE] fail2ban should use firewall-cmd instead of iptables
Summary: [RFE] fail2ban should use firewall-cmd instead of iptables
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fail2ban
Version: 19
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-28 22:06 UTC by Edgar Hoch
Modified: 2014-09-23 00:05 UTC (History)
10 users (show)

Fixed In Version: fail2ban-0.8.11-2.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-15 03:35:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
/etc/fail2ban/action.d/firewall-cmd-direct-new.conf (4.08 KB, text/plain)
2013-06-28 22:06 UTC, Edgar Hoch
no flags Details
/etc/fail2ban/action.d/firewall-cmd-direct-new.conf (4.08 KB, text/plain)
2013-07-04 01:45 UTC, Edgar Hoch
no flags Details
/etc/fail2ban/action.d/firewall-cmd-direct-new.conf (3.96 KB, text/plain)
2013-08-27 17:37 UTC, Edgar Hoch
no flags Details

Description Edgar Hoch 2013-06-28 22:06:52 UTC
Created attachment 766740 [details]
/etc/fail2ban/action.d/firewall-cmd-direct-new.conf

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)
  /etc/fail2ban/action.d/firewall-cmd-direct-new.conf

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):
fail2ban-0.8.8-4.fc19.noarch

Comment 1 Edgar Hoch 2013-06-28 22:17:14 UTC
See bug #979624 for SELinux module policy file.

Comment 2 Edgar Hoch 2013-07-04 01:45:56 UTC
Created attachment 768553 [details]
/etc/fail2ban/action.d/firewall-cmd-direct-new.conf

I found a typo error in the action file (a paranthesis was to much).

Comment 3 Edgar Hoch 2013-08-27 17:37:59 UTC
Created attachment 791126 [details]
/etc/fail2ban/action.d/firewall-cmd-direct-new.conf

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.

Comment 4 Orion Poplawski 2013-08-28 15:48:04 UTC
Can you file a bug/PR upstream?  https://github.com/fail2ban/fail2ban/

That would be the best place to get this integrated.

Comment 5 Toby Ovod-Everett 2013-10-06 13:26:24 UTC
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.

Thanks!

Comment 6 Joel 2013-10-16 23:24:19 UTC
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.

Comment 7 Toby Ovod-Everett 2013-10-16 23:35:30 UTC
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.

Comment 8 Thomas Woerner 2013-10-21 09:17:02 UTC
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.

Comment 9 Orion Poplawski 2013-10-21 13:23:24 UTC
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.

Comment 10 Joel 2013-10-21 16:53:14 UTC
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?

Comment 11 Toby Ovod-Everett 2013-10-22 19:59:00 UTC
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.

Comment 12 Daniel Black 2013-10-31 01:07:23 UTC
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.

Daniel
your friendly fail2ban upstream dev

Comment 13 Daniel Black 2013-11-06 00:35:51 UTC
> The odds of firewalld fixing https://fedorahosted.org/firewalld/ticket/10 for FC19/20 is slim to none.

Looks hopeful here:

http://pkgs.fedoraproject.org/cgit/firewalld.git/

As such I'll be requiring 0.3.8 in fail2ban-0.8.11 (release in next few days)

Comment 14 Joel 2013-11-06 02:33:17 UTC
Is good.  Will that be able to go into f19 or only 20+?

Comment 15 Daniel Black 2013-11-06 03:11:47 UTC
> 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.

Comment 16 Daniel Black 2013-11-26 22:12:39 UTC
see #1034355

Comment 17 Joel 2013-11-28 00:35:35 UTC
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?

Comment 18 Joel 2013-11-28 01:03:26 UTC
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:


[ssh-firewall-cmd]

enabled  = true
filter   = sshd
action   = firewall-cmd[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=root, sender=fail2ban.edu, sendername="Fail2Ban"]
logpath  = /var/log/secure
maxretry = 5

However

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

Comment 19 Joel 2013-11-28 01:32:55 UTC
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]]'

Comment 20 Daniel Black 2013-11-28 01:56:26 UTC
Thanks Joel for reporting this in both places: https://github.com/fail2ban/fail2ban/pull/396#issuecomment-29433845

Comment 21 Adam Tkac 2013-12-03 14:10:48 UTC
I will take care about this bug.

Comment 22 Adam Tkac 2013-12-03 15:13:36 UTC
(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.

Comment 23 Adam Tkac 2013-12-03 15:14:52 UTC
(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...

Comment 24 Joel 2013-12-04 21:49:12 UTC
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)?

Comment 26 Adam Tkac 2013-12-05 12:38:30 UTC
(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.

Comment 27 Fedora Update System 2013-12-05 12:41:19 UTC
fail2ban-0.8.11-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12189/fail2ban-0.8.11-1.el6

Comment 28 Fedora Update System 2013-12-05 12:44:55 UTC
fail2ban-0.8.11-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/FEDORA-2013-22223/fail2ban-0.8.11-2.fc19

Comment 29 Fedora Update System 2013-12-05 12:48:11 UTC
fail2ban-0.8.11-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-22238/fail2ban-0.8.11-2.fc18

Comment 30 Daniel Black 2013-12-05 22:11:58 UTC
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.

Comment 31 Joel 2013-12-05 22:31:59 UTC
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).

Comment 32 Daniel Black 2013-12-06 00:25:18 UTC
> 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.

Comment 33 Fedora Update System 2013-12-06 00:32:37 UTC
Package fail2ban-0.8.11-2.el6:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12189/fail2ban-0.8.11-2.el6
then log in and leave karma (feedback).

Comment 34 Daniel Black 2013-12-14 09:09:50 UTC
Thomas - firewallcmd / ipsets as requested : https://github.com/fail2ban/fail2ban/pull/490

Comment 35 Fedora Update System 2013-12-15 03:35:51 UTC
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.

Comment 36 Fedora Update System 2013-12-15 03:37:25 UTC
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.

Comment 37 Fedora Update System 2013-12-20 16:54:56 UTC
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.

Comment 38 Derek Atkins 2014-01-02 21:21:49 UTC
FYI, Looks like fail2ban-0.9-0.3.git1f1a561.fc20.noarch regresses this fix.
C.f. bug #1046816


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