Fail2ban with firewalld fails to ban established traffic

[ghost]

Hello,

Environment:

• Fail2Ban version (including any possible distribution suffixes): 0.9.5-3.fc24
• OS, including release name/version: Fedora 24
• Fail2Ban installed via OS/distribution mechanisms
• You have not applied any additional foreign patches to the codebase
• Some customizations were done to the configuration (provide details below is so)
  Activated nginx-http-auth plugin with default config.

The issue:

I have installed firewalld 0.4.4.1 on Fedora 24 with Fail2ban 0.9.5.
I have enabled jail nginx-http-auth, and firewallcmd-ipset as default ban action.
IPs are correctly added to the ipset but it does not ban established connections.

Looking at iptables the issue is quiet obvious:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 133K  178M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
  295 17700 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
 6180  961K INPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 6180  961K INPUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  512  102K INPUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited
............... other chains .....
Chain INPUT_direct (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22 match-set fail2ban-sshd src reject-with icmp-port-unreachable
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443 match-set fail2ban-nginx-http-auth src reject-with icmp-port-unreachable

The ban rule is inserted within the INPUT_direct chain after the accept target for all established traffic.

The expected behaviour is to ban established connection by default and leave the user the option to not ban established connections if he/she does not want to.

What default ban action would you recommend to mitigate this bug until the issue is fixed with firewalld ?

Thank you very much in advance for your help here,
Cheers.

[sebres]

There's possible (I suspect), that there is something wrong with your basic firewalld (resp. iptables) configuration? I can be wrong, but...
I mean, that our firewall-cmd actions never manipulate the sequence of targets.
I don't know why the INPUT target was located after ACCEPT target. Could it be an initial state of your firewalld configuration? I mean, without fail2ban started...

BTW. Just to reference with #1474.

[ghost]

Thank you very much for your comment.
My firewalld configuration is stock Fedora 24 configuration without particular configuration from me except opening of some services.
I started this thread following the discussion in #732.
I do not know what to think: either firewalld should open the door for adding rules before accepting established traffic and fail2ban should make use of it, either fail2ban should insert the ban rule at top of the INPUT chain.
What do you think ?

[sebres]

@fail2ban/maintainers any idea?

[yarikoptic]

FWIW As a workaround I guess you could just use iptables action for now (instead of kosher firewalld ) which should insert it first in the input chain.

[ghost]

Thank you @yarikoptic. Indeed falling back to iptables-ipset-proto6 default banaction does the job perfectly. I need to dig further the consequences of having firewalld and fail2ban administrating iptables at the same time. I believe that as long as firewalld rules are not modified (which is the case on a regular server) then it should not overlap or erase fail2ban rules. This needs to be further investigated though.

[quux]

I see the same behaviour on our Centos 7 boxen. Kickstarted, some services activated and fail2ban deployed via Ansible:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
f2b-recidive  tcp  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
INPUT_direct  all  --  0.0.0.0/0            0.0.0.0/0
INPUT_ZONES_SOURCE  all  --  0.0.0.0/0            0.0.0.0/0
INPUT_ZONES  all  --  0.0.0.0/0            0.0.0.0/0
DROP       all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain INPUT_direct (1 references)
target     prot opt source               destination
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22 match-set fail2ban-sshd src reject-with icmp-port-unreachable
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 0:65535 match-set fail2ban-seafile src reject-with icmp-port-unreachable

EDIT: an Ansible script was setting the "firewalld-ipset" banaction. Disregard my comment.

[marcosfrm]

Here is the problem:

firewalld/firewalld#44

[sebres]

Thus closed as 3rd party issue.
PR's to fix or workaround such behavior of firewalld are welcome...

[AndyLeeRobinson]

I dealt with this problem years ago, and thought you may find this useful.
Install conntrack-tools
Issue this command after banning the ip address:
conntrack -D -s ipaddr
The ip will be 'deestablished' and subsequent attempts will be blocked.

Additionally, this script can be used to terminate both sides of the conversation if spawned in the background at ban time:
/usr/local/bin/tcpcut

#!/bin/bash
#
# tcpcut v1.0 - Andy Lee Robinson Jan 2012
# Cut tcp connection on next packet
#
# Inserts rules at beginning on INPUT and OUTPUT chains for 20 seconds, then removes them.
# Usage: tcpcut 12.34.56.78 &
# The address can then be banned from reestablishing a connection.
iface=eth0;
ip=$1;
delay=20;
action="REJECT --reject-with tcp-reset"

# create temporary rule to break existing tcp connection (insert at beginning in reverse order)
/sbin/iptables -w -I INPUT  -i $iface -m tcp -p tcp -s $ip -j $action;

# prevent forwarding
/sbin/iptables -w -t nat -I PREROUTING  -i $iface -s $ip -j RETURN;

# tell local service that connection is closed
/sbin/iptables -w -I OUTPUT -o $iface -m tcp -p tcp -d $ip -j $action > /dev/null 2>&1;
sleep 1
/usr/sbin/conntrack -D -s $ip > /dev/null 2>&1

# delete rules after delay seconds
sleep $delay;
/sbin/iptables -w -D OUTPUT -o $iface -m tcp -p tcp -d $ip -j $action > /dev/null 2>&1;
/sbin/iptables -w -t nat -D PREROUTING  -i $iface -s $ip -j RETURN > /dev/null 2>&1;
/sbin/iptables -w -D INPUT  -i $iface -m tcp -p tcp -s $ip -j $action > /dev/null 2>&1;

[cepheid666]

@AndyLeeRobinson Thanks so much for this tcpcut script. However, it doesn't seem to be actually cutting the connection for me. I'm on CentOS 7... I can see that the iptables commands are getting run, with the IP being properly inserted and deleted... but conntrack doesn't seem to actually be disconnecting the ip, as I can see the sendmail and fail2ban entries continuing to come in even while tcpcut is running.

How can I debug this and find out why it's not working? Can I provide you with log entries, and if so, what?

This script is definitely required because spammers listed in a DNSBL or trying to brute-force SMTP AUTH can be rejected dozens or hundreds of times without the connection being severed, so even though fail2ban is trying to ban them, it's not helping... so I'm trying to find how to properly sever the connection. Your script seems like the solution but I'm having trouble making it work.

Thanks!

[cepheid666]

Just for reference: I experience the same issue as in this thread, but I use the fail2ban iptables rules, not firewalld. That is, existing connections (most particularly for sendmail, using iptables-multiport) will get banned but not dropped. I attempted to use @AndyLeeRobinson's "tcpcut" script but it doesn't seem to have any effect.

This is particularly seen when a spammer connects from an IP that is in a DNSBL and tries to issue many (dozens) of RCPT commands... each RCPT command issues a rejection from sendmail (since the IP is on a blocklist), and sendmail-reject will ban the IP after 3 attempts, but will not disconnect the IP... so it keeps trying and f2b keeps issuing "already banned" warnings. Thus, a method of cutting the connection outside of sendmail is needed. (Sendmail is behaving "appropriately" in this case, it's not a bug in sendmail.)

[sebres]

Just for reference: I experience the same issue as in this thread, but I use the fail2ban iptables rules, not firewalld.

Then you have not exactly the same issue. Either you have some net-filter problems (e. g. delaying or ignoring reject connections or something similar) or your iptables rules contain some allowing rules (white-listing for established connections) before INPUT chain or before rules of fail2ban there.
Neither one nor other is an issue of fail2ban (or even sendmail) but either it is your (or CentOS) mistaken configuration.