fail2ban / fail2ban

Daemon to ban hosts that cause multiple authentication errors
http://www.fail2ban.org
Other
12.18k stars 1.26k forks source link

please add counter to nftables block rule, so you can easily see if it works #2767

Open hanscees opened 4 years ago

hanscees commented 4 years ago

Hi, I am using fail2ban in a docker container as described here: https://github.com/crazy-max/docker-fail2ban/issues/29

My linux host system is debian: 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux

fail2ban inside the container is / # fail2ban-client --version Fail2Ban v0.11.1

The issue:

Its not so much an issue but a feature request. Troubleshooting if the fail2ban block in nftables works was very cumbersome.

To be able to see if any traffic at all passed the nftables rules I had to add some lines with a counter and while doing that was wondering why the fail2ban default rule doesnt add a counter. Adding a counter in nftables doesnt add much cpu or memory and it helps you out a great deal while having a look if the rules catch any traffic.

If you do nft list ruleset it fills in the numbers nicely.

Steps to reproduce

In my setup the action is a banaction = nftables[type=multiport]

The nftables input is

[Init]
table = f2b-table-docker
chain_hook = forward

The resulting nftables look like this:

nft list table inet f2b-table-docker -a

table inet f2b-table-docker { # handle 21
    set addr-set-nginx403 { # handle 2
        type ipv4_addr
        elements = { 129.211.22.74, 213.41.135.119 }
    }

    chain f2b-chain { # handle 1
        type filter hook forward priority -1; policy accept;
        ip saddr @addr-set-nginx403 ip protocol tcp counter packets 0 bytes 0 tcp dport { http, https } drop # handle 9
        tcp dport { http, https } ip saddr @addr-set-nginx403 reject # handle 6
        tcp dport ssh counter packets 0 bytes 0 # handle 7
        tcp dport { http, https } counter packets 1 bytes 52 # handle 11
    }
}

Notice however that I have manually added handle 9 (and also handle 7 and 11) Handle 6 is what fail2ban produces by default (as far as I know)

Desired/requested behavior

a nftables reject/block line with a counter ip saddr @addr-set-nginx403 ip protocol tcp counter packets 0 bytes 0 tcp dport { http, https } drop # handle 9

Observed behavior

a block line without counter tcp dport { http, https } ip saddr @addr-set-nginx403 reject # handle 6

Any additional information

added the nftables line with

nft insert rule inet f2b-table-docker f2b-chain position 6 ip saddr @addr-set-nginx403 ip protocol tcp counter tcp dport { http, https } drop

all config can be found here: https://github.com/crazy-max/docker-fail2ban/issues/29

sebres commented 4 years ago

Could you not use some parameter applied in the rule creation to insert counter option? For instance blocktype?

[jail]
# newest version:
banaction = nftables[type=multiport, blocktype="counter drop"]
# version before #2254:
banaction = nftables-multiport[blocktype="counter drop"]

Also note that position of counter in the rule sequence matters - your example (counter before ports) is not equivalent to the rule above (counter before verdict statement like drop). The rule of nftables is evaluated from the left to the right, so in your case any kind of packet via tcp from banned IPs will update the counters, not only http/https packets. I don't think it would be proper.

Adding a counter in nftables doesnt add much cpu or memory

Well perhaps it doesn't, but it depends either. Although it would indeed not reserve much memory and the increment of counter is probably atomic, but it can affect search of matching rule or the counter (e. g. lock on execution/lookup may be a bit longer, what is undesirable, especially under race conditions on some huge traffic).