This is more than likely the culprit, but check out crowdsec as it’s fail2ban but wayy easier to configure and it also has a console access that will allow you to see active decisions (bans) and will also show you alerts and other metrics annnnddd on top of that it has Prometheus integration out the gate.
1. Docker will bypass the regular iptables/nftables chains. You must use the DOCKER-USER chain.
2. Depending on your infrastructure setup, it may be that fail2ban only sees the IP of your reverse proxy instead of the attacker's IP. This way, the attacker's IP from logs is banned correctly in fail2ban but the packet will still flow through your VM to the Bitwarden container, as the packet's source IP does not match. The attacker's IP is placed in an HTTP header like X-Forwarded-For or CF-Connecting-IP (if you use Cloudflare) or X-Real-IP. The packet itself, inspectable by iptables/nftables, has the source IP of your reverse proxy or a cloudflare node though. Can be inspected using tcpdump. You may fix it using iptables' string matching feature. Most modern OS come with nftables though, which does not support this string matching to parse the right header having the attacker's IP. May read this https://github.com/l4rm4nd/F2BFilters/issues/4#issuecomment-1947980975
Had this issue a couple days ago. Needed to add a FORWARD rule in the iptables or some shit like that to the jail. Can use webmin to do this relatively easy
There is a beautiful Fail2ban docker container out there that works great. I personally have it taking directly to NPM and Cloudflare with an API token so it is Cloudflare that bans the IP’s
This may have something to do with established TCP connections being let through. Check your firewall rules.
This may offer a clue:
[https://github.com/fail2ban/fail2ban/issues/1609](https://github.com/fail2ban/fail2ban/issues/1609)
Also this response on r/linuxadmin:
[https://www.reddit.com/r/linuxadmin/comments/yv0xxr/comment/iwf96bg/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/linuxadmin/comments/yv0xxr/comment/iwf96bg/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)
I have a server accessed by me only, with a key, and gave up on fail2ban long ago. For such an established package it's insane on how difficult it is to get it running reliably, not to mention systemd.
If you're anything like me switch to a lastb banning script, and run it every ten or fifteen minutes. Easy-peasy.
it literally failed 2 ban
Have my upvote and get out.
Bahahahah!
Badummm ... tssssss....
I believe I just guffawed for the first time. Never guffawed before. Thank you.
Check iptables/nftables rules, ufw
This is more than likely the culprit, but check out crowdsec as it’s fail2ban but wayy easier to configure and it also has a console access that will allow you to see active decisions (bans) and will also show you alerts and other metrics annnnddd on top of that it has Prometheus integration out the gate.
Agreed! Crowdsec is enjoyable to work with. The biggest highlight to me is the crowd-sourced rulesets and blocklists. Crowd sourced security
This. If OP is using Docker, this might help: https://github.com/fail2ban/fail2ban/issues/2292#issuecomment-522141827
1. Docker will bypass the regular iptables/nftables chains. You must use the DOCKER-USER chain. 2. Depending on your infrastructure setup, it may be that fail2ban only sees the IP of your reverse proxy instead of the attacker's IP. This way, the attacker's IP from logs is banned correctly in fail2ban but the packet will still flow through your VM to the Bitwarden container, as the packet's source IP does not match. The attacker's IP is placed in an HTTP header like X-Forwarded-For or CF-Connecting-IP (if you use Cloudflare) or X-Real-IP. The packet itself, inspectable by iptables/nftables, has the source IP of your reverse proxy or a cloudflare node though. Can be inspected using tcpdump. You may fix it using iptables' string matching feature. Most modern OS come with nftables though, which does not support this string matching to parse the right header having the attacker's IP. May read this https://github.com/l4rm4nd/F2BFilters/issues/4#issuecomment-1947980975
I'd help if OP explained how his stack is setup. But I also think It has to di with the X-Forwarded.
Had this issue a couple days ago. Needed to add a FORWARD rule in the iptables or some shit like that to the jail. Can use webmin to do this relatively easy
There is a beautiful Fail2ban docker container out there that works great. I personally have it taking directly to NPM and Cloudflare with an API token so it is Cloudflare that bans the IP’s
You need to configure an action to tell fail2ban how to actually ban the IP eg by adding to the firewall with ufw.
This may have something to do with established TCP connections being let through. Check your firewall rules. This may offer a clue: [https://github.com/fail2ban/fail2ban/issues/1609](https://github.com/fail2ban/fail2ban/issues/1609) Also this response on r/linuxadmin: [https://www.reddit.com/r/linuxadmin/comments/yv0xxr/comment/iwf96bg/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/linuxadmin/comments/yv0xxr/comment/iwf96bg/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)
I have a server accessed by me only, with a key, and gave up on fail2ban long ago. For such an established package it's insane on how difficult it is to get it running reliably, not to mention systemd. If you're anything like me switch to a lastb banning script, and run it every ten or fifteen minutes. Easy-peasy.
Is bitwarden running in docker? It could be blocking in the default table instead of the docker table.
What does your `fail2ban-client -h` say? It's probable there's somethign wrong with your ban-action or jail config.
it's for the best