Proper jail action for npm behind docker

[maxdd]

Hello,
i'm trying to understand what is the proper config to be used to jail an IP from NPM or vaultwarden logs.
I've tried the following

[DEFAULT]
...
chain = DOCKER-USER
action = nftables[type=allports]
...

but although i get the Ban IP text, this is not applied.
I had to search on some forums and found the following

[DEFAULT]
...
chain = INPUT
action = iptables-nft[type=allports, chain=DOCKER-USER]
...

## Version 2022/08/06iptables-nft
# Fail2Ban configuration file
#
# Authors: Sergey G. Brester (sebres), Cyril Jaquier, Daniel Black, 
#          Yaroslav O. Halchenko, Alexander Koeppe et al.
#

[Definition]

# Option:  type
# Notes.:  type of the action.
# Values:  [ oneport | multiport | allports ]  Default: oneport
#
type = oneport

# Option:  actionflush
# Notes.:  command executed once to flush IPS, by shutdown (resp. by stop of the jail or this action)
# Values:  CMD
#
actionflush = <iptables-nft> -F f2b-<name>

# Option:  actionstart
# Notes.:  command executed on demand at the first ban (or at the start of Fail2Ban if actionstart_on_demand is set to false).
# Values:  CMD
#
actionstart = { <iptables-nft> -C f2b-<name> -j <returntype> >/dev/null 2>&1; } || { <iptables-nft> -N f2b-<name> || true; <iptables-nft> -A f2b-<name> -j <returntype>; }
              <_ipt_add_rules>

# Option:  actionstop
# Notes.:  command executed at the stop of jail (or at the end of Fail2Ban)
# Values:  CMD
#
actionstop = <_ipt_del_rules>
             <actionflush>
             <iptables-nft> -X f2b-<name>

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = <_ipt_check_rules>

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = <iptables-nft> -I f2b-<name> 1 -s <ip> -j <blocktype>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionunban = <iptables-nft> -D f2b-<name> -s <ip> -j <blocktype>

# Option:  pre-rule
# Notes.:  prefix parameter(s) inserted to the begin of rule. No default (empty)
#
pre-rule =

rule-jump = -j <_ipt_rule_target>

# Several capabilities used internaly:

_ipt_for_proto-iter = for proto in $(echo '<protocol>' | sed 's/,/ /g'); do
_ipt_for_proto-done = done

_ipt_add_rules = <_ipt_for_proto-iter>
              { %(_ipt_check_rule)s >/dev/null 2>&1; } || { <iptables-nft> -I <chain> %(_ipt_chain_rule)s; }
              <_ipt_for_proto-done>

_ipt_del_rules = <_ipt_for_proto-iter>
              <iptables-nft> -D <chain> %(_ipt_chain_rule)s
              <_ipt_for_proto-done>

_ipt_check_rules = <_ipt_for_proto-iter>
              %(_ipt_check_rule)s
              <_ipt_for_proto-done>

_ipt_chain_rule = <pre-rule><ipt_<type>/_chain_rule>
_ipt_check_rule = <iptables-nft> -C <chain> %(_ipt_chain_rule)s
_ipt_rule_target = f2b-<name>

[ipt_oneport]

_chain_rule = -p $proto --dport <port> <rule-jump>

[ipt_multiport]

_chain_rule = -p $proto -m multiport --dports <port> <rule-jump>

[ipt_allports]

_chain_rule = -p $proto <rule-jump>


[Init]

# Option:  chain
# Notes    specifies the iptables chain to which the Fail2Ban rules should be
#          added
# Values:  STRING  Default: INPUT
chain = INPUT

# Default name of the chain
#
name = default

# Option:  port
# Notes.:  specifies port to monitor
# Values:  [ NUM | STRING ]  Default:
#
port = ssh

# Option:  protocol
# Notes.:  internally used by config reader for interpolations.
# Values:  [ tcp | udp | icmp | all ] Default: tcp
#
protocol = tcp

# Option:  blocktype
# Note:    This is what the action does with rules. This can be any jump target
#          as per the iptables man page (section 8). Common values are DROP
#          REJECT, REJECT --reject-with icmp-port-unreachable
# Values:  STRING
blocktype = DROP

# Option:  returntype
# Note:    This is the default rule on "actionstart". This should be RETURN
#          in all (blocking) actions, except REJECT in allowing actions.
# Values:  STRING
returntype = RETURN

# Option:  lockingopt
# Notes.:  Option was introduced to iptables to prevent multiple instances from
#          running concurrently and causing irratic behavior.  -w was introduced
#          in iptables 1.4.20, so might be absent on older systems
#          See https://github.com/fail2ban/fail2ban/issues/1122
# Values:  STRING
lockingopt = -w

# Option:  iptables
# Notes.:  Actual command to be executed, including common to all calls options
# Values:  STRING
iptables-nft = iptables-nft <lockingopt>


[Init?family=inet6]

# Option:  blocktype (ipv6)
# Note:    This is what the action does with rules. This can be any jump target
#          as per the iptables man page (section 8). Common values are DROP
#          REJECT, REJECT --reject-with icmp6-port-unreachable
# Values:  STRING
blocktype = DROP

# Option:  iptables (ipv6)
# Notes.:  Actual command to be executed, including common to all calls options
# Values:  STRING
iptables-nft = ip6tables-nft <lockingopt>

which is working but i would like to keep the changes as small and as compatible as possible.
I'm currently on debian 12

[sebres]

action = nftables[type=allports]

With that setting you'll overwrite default action definition

fail2ban/config/jail.conf

Line 212 in ecb9771

action_ = %(banaction)s[port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

fail2ban/config/jail.conf

Line 263 in ecb9771

action = %(action_)s

thus the chain parameter specified in jail will be not supplied to action anymore.

Basically it would be enough to set banaction instead:

  chain = DOCKER-USER
- action = nftables[type=allports]
+ banaction = nftables[type=allports]

[maxdd]

I see i'll give it a try, what if i have a script to receive notification on telegram?
Can i do

[DEFAULT]
...
chain = DOCKER-USER
action = %(action_)s
         telegram
banaction = nftables[type=allports]
...

Also is nftables suggested as ban action? is the default banaction different?
If the "telegram action" reacts on both action and banaction shall i append it below banaction as well?

...
banaction = nftables[type=allports]
            telegram
...

[sebres]

Can i do ...

Yes you can.

Also is nftables suggested as ban action? is the default banaction different?

It depends on your distro, availability of net-filters etc.

However if you want use it, I'd suggest something like that (so single or multiple port banning jails remaining multi-port):

banaction = nftables[type=multiport]
banaction_allports = nftables[type=allports]

If the "telegram action" reacts on both action and banaction shall i append it below banaction as well?

No. This would cause wrong syntax after substitution of action_.

[maxdd]

It depends on your distro, availability of net-filters etc.

I'm on debian 12

However if you want use it, I'd suggest something like that (so single or multiple port banning jails remaining multi-port):

banaction = nftables[type=multiport]
banaction_allports = nftables[type=allports]

I'm not following, probably due to the lack of knowledge on fail2ban.
I thought that

banaction = nftables[type=allports]

was supposed to ban the IP on all the ports.
What is the added benefit of going for your suggestion?

No. This would cause wrong syntax after substitution of action_.

will i still be able to get telegram notification on actionstart/actionstop/actionban/actionunban?

[maxdd]

I went with the simple version first and for nginx proxy manager logs

[DEFAULT]
ignoreip = 127.0.0.1/8 192.168.1.0/24 #Set ignored ranges
maxretry = 3
bantime  = 600
bantime.increment = true
bantime.rndtime = 2048
bantime.multipliers = 1 5 30 60 300 720 1440 2880
findtime = 300

chain = DOCKER-USER
action = %(action_)s
         telegram
banaction = nftables[type=allports]

#chain = INPUT
#action = iptables-nft[type=allports, chain=DOCKER-USER]
#         telegram

[npm-docker]
enabled = true
logpath = /npm/default-host_*.log
          /npm/proxy-host-*.log

but the result is

2024-05-10 14:21:31,852 fail2ban.filter         [1]: INFO    [npm-docker] Found 78.211.4.25 - 2024-05-10 14:21:31
2024-05-10 14:21:32,188 fail2ban.actions        [1]: NOTICE  [npm-docker] Ban 78.211.4.25
2024-05-10 14:21:37,761 fail2ban.filter         [1]: INFO    [npm-docker] Found 78.211.4.25 - 2024-05-10 14:21:37
2024-05-10 14:21:37,763 fail2ban.observer       [1]: INFO    [npm-docker] Found 78.211.4.25, bad - 2024-05-10 14:21:37, 2 # -> 3.0, Ban
2024-05-10 14:21:38,416 fail2ban.actions        [1]: NOTICE  [npm-docker] 78.211.4.25 already banned
2024-05-10 14:21:40,468 fail2ban.filter         [1]: INFO    [npm-docker] Found 78.211.4.25 - 2024-05-10 14:21:40
2024-05-10 14:21:40,470 fail2ban.observer       [1]: INFO    [npm-docker] Found 78.211.4.25, bad - 2024-05-10 14:21:40, 2 # -> 3.0, Ban
2024-05-10 14:21:40,624 fail2ban.actions        [1]: NOTICE  [npm-docker] 78.211.4.25 already banned

and i can still navigate.
If i use iptables-nft it works as intended instead.
Is there for me to check the entries of the ban from my host to see if they are there?

[maxdd]

I guess the fact that with sudo su i cannot issue nftables means that i still have legacy iptables then?

[sebres]

If i use iptables-nft it works as intended instead.

iptables-nft says nothing to me (we don't have such action in stock fail2ban).

Is there for me to check the entries of the ban from my host to see if they are there?

nft list could do the job

I guess the fact that with sudo su i cannot issue nftables means that i still have legacy iptables then?

I don't think so (iptables-nft implies it somehow)... The command is calling nft and not nftables...

Since it is docker and not the input chain, you have to check what exactly docker configured on your side.

[maxdd]

I'm not following you, iptables-nft custom action is pasted above and as i said i dont want to use it exactly because it is not stock
The command in iptables-nft is calling "iptables-nft" and not nft or ntftables (as you mentioned)

the DOCKER-USER chain property is used when using iptables-nft or iptables (stock) and properly working
So if it is chan related than this command

chain = DOCKER-USER
action = %(action_)s
         telegram
banaction = nftables[type=allports]

is not the proper syntax, would this work?

nftables[type=allports, chain=DOCKER-USER]

[sebres]

The command in iptables-nft is calling "iptables-nft" and not nft or ntftables (as you mentioned)

Yes, but iptables-nft command simply provides a bridge to the nftables kernel API. (See https://developers.redhat.com/blog/2020/08/18/iptables-the-two-variants-and-their-relationship-with-nftables#the_kernel_api)
So basically it simply emulates nft with iptables command syntax.

is not the proper syntax

No... normally it is correct syntax (as already said).
However I don't know how docker (or whatever) organizes it with native nftables (not the bridge) in your case.
You have to check nft list (e. g. nft list chains or nft list tables) to see what exactly docker configures there and determine the chain (or possibly the hook or table) where you have to "inject" fail2ban chains to protect docker container.
Also some rules can simply avoid the packet reaches chain DOCKER-USER (and so bypass f2b rules)...
It is impossible from here to see what happens with net-filter (or docker or its container) on your side.

You can also inspect nft listings using the bridge iptables-nft in fail2ban (to see what is different or why it doesn't work for you with nftables action).

Also note the fork of @crazy-max - docker-fail2ban - maybe you'd get there more info.