nginx-proxy-manager
nginx-proxy-manager copied to clipboard
NginxProxyManager
[Request] Add Fail2Ban
Please consider fail2ban https://www.fail2ban.org/wiki/index.php/Main_Page
and a 2 step verification method https://www.authelia.com/ https://github.com/clems4ever/authelia
BTW your software is being a total sucess here https://forums.unraid.net/topic/76460-support-djoss-nginx-proxy-manager/
I agree on the fail2ban, I can see 2fa being good if it is going to be externally available. Big thing if you implement f2b, make sure it will pay attention to the forwarded-for IP. That way you don't end up blocking cloudflare.
I switched away from that docker container actually simply because it wasn't up-to-date enough for me. I needed the latest features such as the ability to forward HTTPS enabled sites.
@lordraiden Thanks for the heads up, makes sense why so many issues being logged in the last 2 weeks! F2B is definitely a good improvement to be considered.
@vrelk Upstream SSL hosts support is done, in the next version I'll release today. Is that the only thing you needed that the docker version couldn't do?
@jc21 I guess I should have specified that I was referring to the docker container linked in the first post (unRAID). It is a few months out of date. My switch was from the jlesage fork to yours.
Would be great to have fail2ban built in like the linuxserver/letsencrypt Docker container!
Would also love to see fail2ban, or in the meantime, if anyone has been able to get it working manually and can share their setup/script
Is there a (manual) way to use Nginx-proxy-manager reverse proxies in combination with Authelia 2FA? I love the proxy manager's interface and ease of use, and would like to use it together with a authentication service.
+1 for both fail2ban and 2fa support. I would rank fail2ban as a primary concern and 2fa as a nice to have. With both of those features added i think this solution would be ready for smb production environments.
Some update on fail2ban, since I don't see this happening anytime soon, I created a fail2ban filter myself. Create a file called "nginx-docker" in /etc/fail2ban/filder.d with the following contents
[INCLUDES]
[Definition]
failregex = ^<HOST>.+" (4\d\d|3\d\d) (\d\d\d|\d) .+$
^.+ 4\d\d \d\d\d - .+ \[Client <HOST>\] \[Length .+\] ".+" .+$
This will jail all requests that return a 4xx/3xx code on the main ip or a 400 on the specified hosts in the docker (no 300 here because of redirects used to force HTTPS)
enable the jail in the jail.local file:
[nginx-docker]
enabled = true
logpath = <docker-config-location>/nginx-proxy-manager/data/logs/default_host.log
<docker-config-location>/nginx-proxy-manager/data/logs/proxy_host-*.log
maxretry = 3
bantime = 360
findtime = 60
The only issue is that docker sort of bypasses all iptables entries, fail2ban makes the entry but those are ignored by docker, resulting in having the correct rule in iptables or ufw, but not actually blocking the IP. Maybe someone in here has a solution for this.
wessel145 - I have played with the same problem ( docker ip block ) few days :) finally I have working solution;
- in /etc/docker/daemon.json - you need to add option "iptables": true
- you need to be sure docker create chain in iptables DOCKER-USER
- for fail2ban ( docker port ) use SINGLE PORT ONLY - custom action.d/customaction.conf
--ctorigdstport !!! mine looks like this and it works
customaction.conf
[INCLUDES]
before = iptables-common.conf
[Definition]
actionstart =
-N f2b- -A f2b- -j -I DOCKER-USER -p -m conntrack --ctorigdstport --ctdir ORIGINAL -j f2b-
actionstop =
- in your jail add action
[nginx-docker]
enabled = true
logpath =
/nginx-proxy-manager/data/logs/default_host.log /nginx-proxy-manager/data/logs/proxy_host-*.log
banaction = customaction
maxretry = 3 bantime = 360 findtime = 60
NOTE: for docker to ban port need to use single port and option iptables -m conntrack --ctorigdstport
my personal opinion nginx-proxy-manager should be ONLY nginx-proxy-manager ; as with docker concept fail2ban and etc, etc, you can have as separate containers; better to have one good nginx-proxy-manager without mixing; jc21/nginx-proxy-manager made nice job. ! thanks
@dariusateik i do not agree on that since the letsencrypt docker container also comes with fail2ban, 'all reverse proxy traffic' will go through this container and is therefore a good place to handle fail2ban.
@dariusateik the other side of docker containers is to make deployment easy. Currently fail2ban doesn't play so well sitting in the host OS and working with a container. Setting up fail2ban is also a bit more advanced then firing up the nginx-proxy-manager container and using a UI to easily configure subdomains. Having f2b inside the npm container and pre-configured, similiar to the linuxio container, gives end users without experience in building jails and filters an extra layer of security. And those of us with that experience can easily tweak f2b to our liking. If you are using volumes and backing them up nightly you can easily move your npm container or rebuild it if necessary. I want to try out this container in a production environment but am hesitant to do so without f2b baked in. In production I need to have security, back ups, and disaster recovery.
@dariusateik the other side of docker containers is to make deployment easy. Currently fail2ban doesn't play so well sitting in the host OS and working with a container. Setting up fail2ban is also a bit more advanced then firing up the nginx-proxy-manager container and using a UI to easily configure subdomains. Having f2b inside the npm container and pre-configured, similiar to the linuxio container, gives end users without experience in building jails and filters an extra layer of security. And those of us with that experience can easily tweak f2b to our liking. If you are using volumes and backing them up nightly you can easily move your npm container or rebuild it if necessary. I want to try out this container in a production environment but am hesitant to do so without f2b baked in. In production I need to have security, back ups, and disaster recovery.
it is always - we could find many "yes" and many "no" ; there is no one answer... If npm will have it - why not; but i am using crazymax/fail2ban for this; more complexing docker, more possible mistakes; configs, etc; how will be or f2b integrated - should decide jc21
Personally I don't understand the fascination with f2b. There's talk about security, but I've worked for multi million dollar companies with massive amounts of sensitive customer data, used by government agencies and never once have we been hacked or had any suspicious attempts to gain access.
And we have never used f2b.
On one hand, this project's goals was for the average joe to be able to easily use HTTPS for their incoming websites; not become a network security specialist. I understand that there are malicious people out there and there are users who want to protect themselves, but is f2b the only way for them to do this?
On the other hand, f2b is easy to add to the docker container. It's the configuration of it that would be hard for the average joe. Anyone who wants f2b can take my docker image and build a new one with f2b installed.
Super secret stuff: I'm not working on v2 anymore, and instead slowly working on v3. I'll be considering all feature requests for this next version.
100 % agree - > ... On the other hand, f2b is easy to add to the docker container
hopping in to say that a 2fa solution (such the the one authelia brings) would be an amazing addition.
Authelia itself doesnt require a LDAP server or its own mysql database, it can use built in single file equivalents just fine for small personal installations
To y'all looking to use fail2ban with your nginx-proxy-manager in docker here's a tip:
In your jail.local file under where the section (jail) for nginx-http-auth is you need to add this line so when something is banned it routes through iptables correctly with docker:
chain = DOCKER-USER
