1

I'm new to nftables and I haven't used fail2ban before so its possible I'm wrong, but I think I may have discovered a bug in fail2ban.

I had constructed a set of firewall rules using nftables which looked something like this

table ip filter {
    chain input {
        type filter hook input priority filter; policy drop;
        .
        my rules including a rule to allow access to port 22
        .
     }
}

However, when I installed fail2ban and used the client to ban a specific IP as a test of the setup using this command

fail2ban-client set sshd banip 1.2.3.4

the fail2ban server added these 2 base chains to my "filter" table

  chain f2b-sshd {
        ip saddr 1.2.3.4 counter reject 
        counter return
  }

  chain INPUT {
        type filter hook input priority filter; policy accept;
        meta l4proto tcp tcp dport 22 counter jump f2b-sshd
  }

which would appear to be problematic in that my "input" chain and the "INPUT" chain created by fail2ban both have the same hook priority and according to the nftables documentation the order in which they will be applied will be unpredictable.

OTOH the documentation also suggests that even if my "input" chain had a lower priority causing it to be evaluated first and the verdict was to accept the connection the fail2ban "INPUT" chain would subsequently be applied so maybe it doesn't matter that the priorities are the same.

Can anyone tell me whether or not the fact that the "INPUT" chain created by fail2ban has the same priority as my "input" chain could result in the ban being ignored?

rick mallett
  • 11
  • 2
  • INPUT is probably handled by `iptables-nft`. So fail2ban uses iptables. For priority, this won't matter (and it's to be considered undefined). the packet can be dropped before or after, it stays dropped: https://unix.stackexchange.com/questions/607358/packet-processing-order-in-nftables/607391#607391 – A.B May 01 '23 at 22:15

0 Answers0