Fail2ban plugin in OMV and Nignx Proxy Manager and vaultwarden docker containers

Quote from darkopi

Thank you.

This really works.

Before I tried fail2ban on Vaultwarden, I also tried fail2ban on Nignx Proxy Manager, but without success.

I can't say I fully understand how this works, and what I tried with fail2ban and Nignx Proxy Manager didn't work.

As far as I can see, the only difference is actually in /absolute/path/to/persistent/appdata/fail2ban/action.d/iptables-nft.local.

It's a custom action that's not in the basic fail2ban installation, and I guess this allows the whole thing to work as it should.

I wonder if I can apply this action to other docker containers as well?

Display More

I wrote that guide. It will apply to anything that nginxproxy manager logs as a failure to login, as it is the nginx proxy manager logs that it is watching. If failures exceed the thresholds set in the fail2ban configs it blocks the offending ip from accessing anything docker oriented, and since nginx proxy manager is the gateway to your services and is a docker container, the ip is blocked from nginx proxy manager. You can have it monitor other logs for specific containers if you like to have it only work on certain applications, but you would have to write a filter for those logs to parse the correct information and use an appropriate jail and action for each unique setup. The guide was intended as a "one size fits all" kind of configuration to allow people that want to use nginx proxy manager to add some additional security to the setup and mimic something close to what the swag reverse proxy container is doing.

I personally have 3 different filter/jail/action configuration running as I alluded to in the guide. One (the default in the guide) looks after short bans to hopefully make bots that are hammering on your system, stop because they fail to get a response, the next is a medium ban of 10 minutes using a higher fail count and timeframe that will hopefully look after manual attempts or bots that operate on a slower cycle, and the third is a long ban of 1 week that has an even higher failure count and timeframe to hopefully look after anything or anyone that starts hammering again after the short or medium bans.

Just remember that any additional configs or edits to the existing configs require a restart of the fail2ban container for them to become active.

As for email notifications, I didn't include those as it can become very annoying to get emails about bots getting banned on those short bans, but if you want to try to add notifications, there are guides to setting it up in the jail files, such as this one.

How to add email notifications to Fail2ban - technicalramblings.com

Quote

I wrote that guide

Hi!

Two questions.

Do I need to use:

networks:
 default:
  name: web
   driver: bridge

in the npm compose file for fail2ban to work?

In there is no /bin/check-health file in OMV7, why is it needed and how to add it if needed?

Thank you.

Quote from KOCTET

Hi!

Two questions.

Do I need to use:

Code

networks:
 default:
  name: web
   driver: bridge

in the npm compose file for fail2ban to work?

In there is no /bin/check-health file in OMV7, why is it needed and how to add it if needed?

Thank you.

Display More

The networks section creates a custom names docker network. It will work without it, but if there is no network defined, every compose file you deploy will create its own docker network, and while the dockers will still work they can not address each other by container name if you are trying to make several compose files act together to fill a single role. For example, if you had a database compose file and an application compose file that needed to talk to each other, without the network section defined in each one, they have to be linked by using an ip address, but if they have the same network defined they can communicate using the container names. This is just a feature of the way docker works. I custom define the network in all my docker container to keep the network list smaller and to allow for that container name linking.

As for the health check stuff, docker health checks can be configured to ensure a container is functioning correctly, such as can this specific container reach a certain address on the internet like a ping to a server. If the ping can’t happen, the container can be flagged as unhealthy so you can see it needs to be restarted or looked at. This can be useful if using a container like autoheal that checks for this flag and auto-restarts unhealthy containers.

I am not able to look up and post a specific example at the moment, but adding them is just another section in the compose file that tests for a specific criteria.

Quote from BernH

The networks section creates a custom names docker network. It will work without it, but if there is no network defined, every compose file you deploy will create its own docker network, and while the dockers will still work they can not address each other by container name if you are trying to make several compose files act together to fill a single role. For example, if you had a database compose file and an application compose file that needed to talk to each other, without the network section defined in each one, they have to be linked by using an ip address, but if they have the same network defined they can communicate using the container names. This is just a feature of the way docker works. I custom define the network in all my docker container to keep the network list smaller and to allow for that container name linking.

As for the health check stuff, docker health checks can be configured to ensure a container is functioning correctly, such as can this specific container reach a certain address on the internet like a ping to a server. If the ping can’t happen, the container can be flagged as unhealthy so you can see it needs to be restarted or looked at. This can be useful if using a container like autoheal that checks for this flag and auto-restarts unhealthy containers.

I am not able to look up and post a specific example at the moment, but adding them is just another section in the compose file that tests for a specific criteria.

I got it, thanks!

It seemed to me that NextCloud AIO doesn't work very well if you turn on this network, that's why I asked, I'll try without it.

The second question is also clear, thanks!

I don’t use Nextcloud aio, so I can’t comment on its behavior other than to say it is a unique beast with its own way of doing things. I can tell you that the NPM/fail2ban config I posted will cause problems with Nextcloud because the NPM log for Nextcloud have a bunch of errors in it that fail2ban will act on.

There was another post on the forums where someone ran into this issue and figures out a tweak to the fail2ban config that let Nextcloud work. What I posted was more of a generic setup that should work fine for most applications. Jellyfin is another application that can throw fail2ban into a blocking loop.

I have Nextcloud manually deployed in an lxc with its own fail2ban instance so it behaves like a completely independent computer. I did this because I prefer to have full control over all aspects of it and have been using it in this manual deployment configuration since its start and before there was a docker for it (even earlier really as I used to run owncloud before nextcloud form off of it) when set like this, I have simply excluded the nextcloud proxy host from the fail2ban config by implicitly specifying the logs I want it to watch. I have also excluded my Jellyfin and enabled it own internal brute force blocking, as that is all fail2ban is really protecting you against.

Quote from BernH

Display Spoiler

I don’t use Nextcloud aio, so I can’t comment on its behavior other than to say it is a unique beast with its own way of doing things. I can tell you that the NPM/fail2ban config I posted will cause problems with Nextcloud because the NPM log for Nextcloud have a bunch of errors in it that fail2ban will act on.

There was another post on the forums where someone ran into this issue and figures out a tweak to the fail2ban config that let Nextcloud work. What I posted was more of a generic setup that should work fine for most applications. Jellyfin is another application that can throw fail2ban into a blocking loop.

I have Nextcloud manually deployed in an lxc with its own fail2ban instance so it behaves like a completely independent computer. I did this because I prefer to have full control over all aspects of it and have been using it in this manual deployment configuration since its start and before there was a docker for it (even earlier really as I used to run owncloud before nextcloud form off of it) when set like this, I have simply excluded the nextcloud proxy host from the fail2ban config by implicitly specifying the logs I want it to watch. I have also excluded my Jellyfin and enabled it own internal brute force blocking, as that is all fail2ban is really protecting you against.

Now I installed Nextcloud AiO again, without including it in the npm network, it works well, fail2ban works as configured in npm-docker.local, it blocks access after 3 unsuccessful attempts.

First, the built-in NC protection works, after several attempts it blocks access, and then errors appear in npm and after 3 works fail2ban

Thanks for your help. Sorry for my english.

Just to elaborate on this topic: it is possible to run the Fail2ban plugin monitoring logs from a docker service. For instance with Nginx Proxy Manager (NPM) what I did:

1. In the docker compose file of NPM just mount a volume containing log files, for instance:

    volumes:
      - ${CONFIG}/nginxpm/data:/data

2. Then on the OMV GUI, under Services -> Fail2Ban -> Jails add one with the following:

1. name: npm_docker
2. port: http, https
3. filter: nginx-404 (all the available filters can be found under /etc/fail2ban/filter.d/)
4. logpath: ${CONFIG}/nginxpm/data/logs/*access*.log

3. On the OMV command line side:

# grep npm_docker /etc/fail2ban/jail.d/*
/etc/fail2ban/jail.d/openmediavault-xxxx.conf:[npm_docker]
# vi /etc/fail2ban/jail.d/openmediavault-xxxx.conf # and add at the end:
...
chain = FORWARD

Thus iptables rules generated by fail2ban will be added to the FORWARD chain, where docker do all its stuff.

Unfortunately this last line will be removed at any fail2ban modification through the interface.

Thus a question: will it be possible to add a textarea in the fail2ban plugin GUI for adding custom informations to jails ?

I answer to myself: fail2ban let the possibility to add .local files in /etc/fail2ban/jail.d folder that are loaded after the .conf files and can change or add settings. For instance it is easy to add:

# vi /etc/fail2ban/jail.d/custom.local
[npm_docker]
chain = FORWARD

Now the addition will survive openmediavault generation of config files. I just need to keep the name npm_docker in Jails panels of the OMV GUI. I think it could still be better to integrate custom options in the OMV GUI as it will be easier to backup.