Iptables – How To Block Established Connections With Fail2ban?

Home » CentOS » Iptables – How To Block Established Connections With Fail2ban?
CentOS 4 Comments

I am working to a CentOS 6 server with nonstandard iptables system without rule for ACCEPT ESTABLISHED connections. All tables and chains empty (flush by legacy custom script) so only filter/INPUT chain has rules (also fail2ban chain):

Chain INPUT (policy ACCEPT)
target prot opt source destination f2b-postfix tcp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 192.168.0.0/16 0.0.0.0/0
ACCEPT all -- 127.0.0.0/8 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:995
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02

Chain f2b-postfix (1 references)
target prot opt source destination 
REJECT all -- 200.23.235.30 0.0.0.0/0 reject-with icmp-port-unreachable 
REJECT all -- 177.11.167.57 0.0.0.0/0 reject-with icmp-port-unreachable 
RETURN all -- 0.0.0.0/0 0.0.0.0/0

When fail2ban block a IP address, established connections are allowed to continue, but with no rule to accept established connections how is that possible? Why doesn’t f2b first rule block established connections?

4 thoughts on - Iptables – How To Block Established Connections With Fail2ban?

  • The short answer is that the firewall rules REJECT…Fail2Ban only tells the firewall what to reject, at the point of entry.

    Think of it this way:

    Fail2Ban is the manager of a popular dance club. He determines the list of who may or may not be admitted to the club.

    The firewall is the guy at the door of a popular club. He’s doing his job, checking IDs, checking against the list of allowed or rejected guests and acting accordingly.

    If the manager updates the list, it’s not the door guy’s job to go back through the club to find anyone who may have been admitted prior to the list having been updated. That’s the job of a bouncer.

    If you want the door guy to also be a bouncer, you’ll need to configure your Fail2Ban actions to add iptables rules which invoke DROP instead of REJECT.

  • […]
    […]

    The first rule should indeed block traffic for the established connections too. It matches tcp only, are your connections really on tcp (and ipv4)?

    Try adding the “-v” option to iptables so you can see the packet counters. Do some experiments and check if the counters grow or not when you expect packets to be dropped.

    Regards.


    Roberto Ragusa mail at robertoragusa.it

  • It doesn’t look like it would be.

    1: Open a connection that will demonstrate the problem later.
    2: Trigger a block from an address that you control.
    3: Check the output of “iptables -L -v” to demonstrate that the address is blocked.
    4: Use “tcpdump -nn -i any host

    ” to watch traffic from that address.
    5: Send a command over the connection from step 1.  tcpdump should show packets in both directions, and your session should be usable, according to the problem you described.
    6: Check the output of “iptables -L -v” again and look at the counters on each rule to see which rule is being matched.
  • The way I solved this problem was using conntrack.  I added entries to the fail2ban action to delete connections where the source or destination matched the IP I was trying to block.  This results in all communications from that IP being dropped immediately.  I used a .local file to redefine the actionban.  It looks like this:

    $ cat firewallcmd-allports.local
    [Definition]
    actionban = firewall-cmd –direct –add-rule ipv4 filter f2b- 0 -s -j

                (conntrack -D -s ; exit 0)
                (conntrack -D -d
    ; exit 0)

    You have to install the conntrack-tools package to use the conntrack command, but I
    don’t remember having to do anything else to make it work.


    Bowie