Block only admin page with Fail2Ban

Using docker compose to startup vaultwarden and caddy, have set up Fail2Ban on the Ubuntu 20.04 host and jails are using

action = iptables-allports[name=vaultwarden, chain=FORWARD]

and

action = iptables-allports[name=vaultwarden-admin, chain=FORWARD]

properly with the jails set up for the webconfig and admin page as detailed in Fail2Ban Setup · dani-garcia/vaultwarden Wiki · GitHub

Currently we will also be using ignoreip = xx.xx.xx.xx/32 within the webconfig jail with ignore IP set to corp public IP as to prevent multiple separate users who possibly have failed logins from locking out everyone from Vaultwarden in our main office.

Currently we also have caddy as a reverse proxy to allow the admin page to only be accessible from within our corp network with:

@insecureadmin {
not remote_ip xx.xx.xx.xx/32
path /admin*
}
redir @insecureadmin /

I wonder if there is a way possibly to set Fail2Ban to ban by the destination path to caddy with URI and ban access only to that directory, as this would allow for banning from our Corp IP in the case a malicious actor or curious user were to stumble upon this, but not ban the full web vault to the server.

We are currently looking into the ability to increment failures and bans with fail2ban and provide email alerts for the admin page jail for logging and notifications.
Much thanks for any input here

Fail2ban works via iptables which is a TCP layer 3 firewall. It only knows IP’s or MAC’s that’s it. It doesn’t know if it is http, ftp, dns etc … so via fail2ban this is not going to work, it blocks the source or it doesn’t.

You probably want s WAF kinda function. Not sure if caddy had that. But i think that is what you are looking for.

1 Like

(please note that I absolutely do not want to be confrontational in that post - after re-reading myself I fear that the tone may seem as such. It really is not - but not being a native speaker of English I sometimes struggle to get the right words and what coms out may not be ideal)

What is the true reason for using fail2ban?

  • making sure that one intruder will not bruteforce your admin interface? → use a long password
  • avoiding the crack of users passwords? → the attempt will not come from a single IP, it will be ran though a botnet
  • avoiding a DoS? Yes, that could be a relevant use, but when have you seen a DoS from a single IP?
  • avoiding a DDoS? it won’t work

I dislike software such as fail2ban because it does not bring any real protection, but complexifies the setup and brings a single point of failure for very limited advantages.

Absolutely no problem at all, we each have our own opinions and methods of security.
For us it is mostly about avoiding “script kiddies” and bots that scour the internet and open ports for vulnerabilities.

One key example is at our Corp location we get multiple IPS notifications occasionally about a known vulnerability on an open port we have regarding remote code execution attempts on a DD-WRT router firmware found here CVE - CVE-2009-2765 (mitre.org)
We don’t have a DD-WRT router anywhere, but these types of attacks still happen most likely due to automated scripts that run looking for exploits.

Caddy (reserve proxy) is set to currently only respond to strict SNI and so a bad actor would need to run any attack on the URI and not just the IP address from an automated scan as is common. Though a simple Shodan search will give you that bitwarden.. - Shodan Search

So Fail2Ban provides just another layer of security in my mind, such that if an attacker has the URI of your Vaultwarden instance, and is running automated scripts this will help to prevent this. The configuration is not too complex to get the simple jails set up, and currently looking to get jail set to allow for admin page to email notifications to us as this should not typically be access by users, only IT and should not fail multiple times with admin token as this will be stored securly and should not have multiple failed login attempts. An email notification would be cause for investigation and alerts us to the possibility something may be awry, it may be nothing but in my opinion it is better to be safe than sorry.

I believe Bitwarden itself is fairly secure, and by extension Vaultwarden as well, the extra layer of protection however helps to make it an easier sell to our administration. Currently I am working just on configuration, testing, and documentation in my homelab prior to making my presentation and so just looking at the different options for set up and to fine tune to our needs.

Thanks for this info, that makes sense that Fail2Ban works via iptables. I am fairly new with Linux administration in general but am familiar with iptables. I believe this will suffice for our needs currently as it stands.
May look into options for a WAF either with Caddy if it has the capabilities, some say it does but possibly not to the extent we would need for granular filtering, or simply another reverse proxy solution or otherwise.

Really appreciate the response and help, it at least gives me a start of where to begin looking for now and determine the best course of actions for us.
Thanks!

It is nice to see that people care about security :slight_smile:

Script kiddies will use an exploit (usually an old one) so you would need to feed to fail2ban the pattern you would see in the logs. But then you are effectively recreating a WAF on top of fail2ban.

Yes, but the scans will come from various IPs. Effective bots will spread the probing across the IPs they control to evade systems such as fail2ban (and generally, throttling)

If the attack is against caddy then SNI does not matter. If it is against the application then fail2ban does not matter because it will be a single exploit.

Now - fail2ban will not hurt - I am vary of solutions that have a low impact on security but carry a risk of false positive, or open yet another attack vector.

I expose my VaultWarden instance and in order to secure the data within:

  • I update my containers as soon as there is a new version of caddy or vaultwarden. Even if this breaks something (I prefer security to availability)
  • I do not expose the admin endpoint (even if it has a long token, it is a risk that can be avoided)
  • I require MFA for the users, this way attempts to crack their master password will fail