[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)


Recommended Posts

I got a question regarding fail2ban and my docker containers running behind nginx.
Am I right that I'm not able to setup any custom fail2ban filters here as my letsencrypt-nginx container obviously can't see any logfiles from other containers such as Emby or Nextcloud!?
As I understand the use of fail2ban here is that it's restricted to basic_auth only when used with Docker.
Is this correct or is there a way to get this working together with Emby for example?


you can mount the locations of the log files in the letsencrypt container
Link to comment
10 minutes ago, aptalca said:

 

 


you can mount the locations of the log files in the letsencrypt container

 

 

Oh wow didn't know this is possible and unfortunately I have no idea how the container path would look like :P

Or do I just need a host path here (e.g. /mnt/user/appdata/emby/logs) and leave the container path empty?

Edited by Marv
Link to comment
6 minutes ago, Marv said:

 

Oh wow didn't know this is possible and unfortunately I have no idea how the container path would look like :P

Or do I just need a host path here (e.g. /mnt/user/appdata/emby/logs) and leave the container path empty?

 

 /emby-logs would be my suggestion then when you're editing the fail2ban config specify /emby-logs or whatever....

Link to comment
19 hours ago, CHBMB said:

 

 /emby-logs would be my suggestion then when you're editing the fail2ban config specify /emby-logs or whatever....

 

Thanks! Got it working for Emby. :)

Unfortunately my Nextcloud container does not see the real remote IP from a user when logging in but always the Docker network IP 172.17.0.1.

This way whenever a user gets a ban all other users get a ban aswell.

I already specified my problem a few weeks ago in the Nextcloud thread.

I guess this has something to do with Nextcloud running in bridge mode maybe!?

Does anyone gets the real remote IP reported in the Nextcloud logs or is there some setting for Nginx that would be the solution?

 

I think it's really strange that Nginx passes the remote IP through Emby but regarding Nextcloud it's not working.

I really want to setup fail2ban for Nextcloud aswell. 

Edited by Marv
Link to comment
On 3/14/2017 at 2:45 AM, Marv said:

I think it's really strange that Nginx passes the remote IP through Emby but regarding Nextcloud it's not working.

I really want to setup fail2ban for Nextcloud aswell. 

This works for me. Add the real ip lines to the nginx default site-confs for the nextcloud docker. Then restart the nextcloud docker.

server {
  listen 443 ssl;
  server_name _;

  real_ip_header X-Forwarded-For;
  set_real_ip_from 172.17.0.0/16;
  real_ip_recursive on;

 

Link to comment

I'm struggling getting emby to work properly. I can access the server no problem externally but only film playback seems to work, music and TV both fail and it seems to be because it's then trying to access the necessary pages via the default port of 8096.

 

I added this to my config:

 

location ^~ /emby {
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.7.11:8096;
    }

 

Although that allows me to access remotely and log in and play a film, it fails to play music with things like this in the emby log:

 

HTTP Response 404 to x.x.x.x. Time: 0ms. http://myserver.com:8096/embywebsocket?deviceId=77d035c190408a514627dd623c86d962941ac660

(i've replaced IP with x.x.x.x. and changed my domain to myserver.com incase anyone points that out.

 

Can anyone shed some light on what I might need to do to make this work? I guess part of the issue is that with emby there is no way to change the base path of the server.

Link to comment
2 hours ago, dmacias said:

This works for me. Add the real ip lines to the nginx default site-confs for the nextcloud docker. Then restart the nextcloud docker.


server {
  listen 443 ssl;
  server_name _;

  real_ip_header X-Forwarded-For;
  set_real_ip_from 172.17.0.0/16;
  real_ip_recursive on;

 

 

OMG thank you its working finally.

I already found this solution before but placed the lines in my default config file of the Letsencrypt container and not inside the one from Nextcloud.

Thanks for your post :)

 

 

2 hours ago, allanp81 said:

I'm struggling getting emby to work properly. I can access the server no problem externally but only film playback seems to work, music and TV both fail and it seems to be because it's then trying to access the necessary pages via the default port of 8096.

 

I added this to my config:

 

location ^~ /emby {
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.7.11:8096;
    }

 

Although that allows me to access remotely and log in and play a film, it fails to play music with things like this in the emby log:

 


HTTP Response 404 to x.x.x.x. Time: 0ms. http://myserver.com:8096/embywebsocket?deviceId=77d035c190408a514627dd623c86d962941ac660

(i've replaced IP with x.x.x.x. and changed my domain to myserver.com incase anyone points that out.

 

Can anyone shed some light on what I might need to do to make this work? I guess part of the issue is that with emby there is no way to change the base path of the server.

 

This is how my emby locaton looks like. Only difference is the '/emby' after the port.

Strange that movie playback works for you though.

 

    location /emby {
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.121.10:8096/emby;
    }

Link to comment
10 minutes ago, Marv said:

 

OMG thank you its working finally.

I already found this solution before but placed the lines in my default config file of the Letsencrypt container and not inside the one from Nextcloud.

Thanks for your post :)

 

 

 

This is how my emby locaton looks like. Only difference is the '/emby' after the port.

Strange that movie playback works for you though.

 

    location /emby {
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.121.10:8096/emby;
    }

How are you configuring emby to be on http://192.168.121.10:8096/emby? I can't see any settings under emby itself to set the base path like you can in others things such as sickbeard/couch potato etc.

Link to comment
4 hours ago, dmacias said:

This works for me. Add the real ip lines to the nginx default site-confs for the nextcloud docker. Then restart the nextcloud docker.


server {
  listen 443 ssl;
  server_name _;

  real_ip_header X-Forwarded-For;
  set_real_ip_from 172.17.0.0/16;
  real_ip_recursive on;

 

 

Thanks for this, although I'd understood letsencrypt fail2ban would stop all abusive IP's at source itself without then having to forward them to the server beyond the proxy?

 

Does forwarding the real IP mean that the letsencrypt fail2ban could not do its work and that would then be left to the destination server to block?

 

 

Link to comment
5 hours ago, dmacias said:

This works for me. Add the real ip lines to the nginx default site-confs for the nextcloud docker. Then restart the nextcloud docker.


server {
  listen 443 ssl;
  server_name _;

  real_ip_header X-Forwarded-For;
  set_real_ip_from 172.17.0.0/16;
  real_ip_recursive on;

 

What IP should the "set_real_ip_from" point to? The IP of my unRAID, or what?

Link to comment
What IP should the "set_real_ip_from" point to? The IP of my unRAID, or what?

You shouldn't change it. The 172.17.0.0/16 covers the docker0 bridge interface. That is the ip range that a nginx docker sees behind a nginx reverse proxy docker. Maybe this should be part of the nextcloud nginx default site. If you include the /config/nginx/proxy.conf in your location block in letsencrypt it forwards the headers. 

 

 

 

 

 

 

 

 

Link to comment
 

Thanks for this, although I'd understood letsencrypt fail2ban would stop all abusive IP's at source itself without then having to forward them to the server beyond the proxy?

 

Does forwarding the real IP mean that the letsencrypt fail2ban could not do its work and that would then be left to the destination server to block?

 

 

/config/nginx/proxy.conf in letsencrypt already passes the ip of the remote address.

proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

In order to get fail2ban to work with anything other than local auth_basic access, you have to add the path of the logs to the letsencrypt container like Marv did for Emby.  (Container path: /emby_logs  Host path: /mnt/user/appdata/emby/logs) The problem with nextcloud was that all it sees is the ip of the unRAID docker0 bridge interface. So if there was malicious usage everyone would be banned. So adding this to Nextcloud nginx gets the forwarded ip from the headers instead of the docker0 ip.

  real_ip_header X-Forwarded-For; set_real_ip_from 172.17.0.0/16; real_ip_recursive on;

So now you have the real ip in your nextcloud and nextcloud nginx logs and fail2ban can use that.

 

 

  • Upvote 1
Link to comment
5 hours ago, allanp81 said:

How are you configuring emby to be on http://192.168.121.10:8096/emby? I can't see any settings under emby itself to set the base path like you can in others things such as sickbeard/couch potato etc.

 

You don't have to change anything in the Emby settings to get it working like this.

Link to comment

@dmacias Thanks for the explanation.

 

I was at a more principle level in that I'd understood, the letsencrypt docker was looking at its nginx access logs in order to ban attempts to access any and all of the servers that it was proxying.

 

I presume you are additionally setting up fail2ban on the nextcloud docker too, in order to detect nextcloud specific access attempts and the need to get the real IP of the remote user, rather than the IP address of the LE proxy.

 

I've got these setup and working nicely, but am not sure fail2ban on he LE docker is doing what I think it is, hence my continued clarification.

 

Apologies for being a bit slow :)

 

Edit: Ok, reading 2nd para again, it seems you are sharing the nextcloud specific logs via mount points to the LE container, so that the LE container can be setup specifically to monitor and ban nextcloud specific attempts, which makes sense. If those logs only contained the IP's of the proxy then the remote client would never be banned.

 

Is giving the NC logs better than the LE container blocking the IP anyway? as wouldn;t the same IP be in the generic nginx logs as well? Guess that is what I am missing. 

Edited by local.bin
Link to comment
2 minutes ago, local.bin said:

@dmacias Thanks for the explanation.

 

I was at a more principle level in that I'd understood, the letsencrypt docker was looking at its nginx access logs in order to ban attempts to access any and all of the servers that it was proxying.

 

I presume you are additionally setting up fail2ban on the nextcloud docker too, in order to detect nextcloud specific access attempts and the need to get the real IP of the remote user, rather than the IP address of the LE proxy.

 

I've got these setup and working nicely, but am not sure fail2ban on he LE docker is doing what I think it is, hence my continued clarification.

 

Apologies for being a bit slow :)

 

You don't have to setup fail2ban on the Nextcloud Docker. You need to map the location of the Nextcloud log file in the Letsencrypt container and then you are able to setup individual filters and add them to your jail.local file inside the Letsencrypt container itself.

Link to comment
6 minutes ago, Marv said:

 

You don't have to setup fail2ban on the Nextcloud Docker. You need to map the location of the Nextcloud log file in the Letsencrypt container and then you are able to setup individual filters and add them to your jail.local file inside the Letsencrypt container itself.

Thanks for that, I'd twigged when I reread the second para of dmacias

 

As I edited, apart from nextcloud individual filters, wouldn't the same IP still get banned in the setup now, but just wouldn't be listed in a specific nextcloud filter?

Link to comment
2 hours ago, local.bin said:
Whats the benefit of adding the specific nextcloud filter when the original setup would do the same.


The original setup for letsencrypt/fail2ban only monitors the access.log and error.log of the front end nginx of the LE docker. Unless you have something like this in your nextcloud location block which would require users to login first before actually getting to the nextcloud login.

auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;


If not then all nextcloud traffic is proxypass to backend nginx of nextcloud docker. Any failed logins are only seen in nextcloud and nextcloud nginx access/error logs. Fail2ban never sees this unless you add the location of the NC logs to the LE docker and setup a fail2ban filter to monitor those logs.

Here's my setup. So for the LE docker I added
Container Path: /logs/emby with Host Path: /mnt/user/appdata/emby/logs/
and
Container Path: /logs/nc_nginx with Host Path: /mnt/user/appdata/nextcloud/log/nginx/

Container Path: /logs/nextcloud with Host Path: /mnt/user/nextcloud/

My ../appdata/letsencrypt/fail2ban/jail.local looks like this.

# This is the custom version of the jail.conf for fail2ban
# Feel free to modify this and add additional filters
# Then you can drop the new filter conf files into the fail2ban-filters
# folder and restart the container

[DEFAULT]

# "bantime" is the number of seconds that a host is banned.
bantime  = 600

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = 600

# "maxretry" is the number of failures before a host get banned.
maxretry = 5


[ssh]

enabled = false

[nginx-http-auth]

enabled  = true
filter   = nginx-http-auth
port     = http,https
logpath  = /config/log/nginx/error.log


[nginx-badbots]

enabled  = true
port     = http,https
filter   = nginx-badbots
logpath  = /config/log/nginx/access.log
maxretry = 2


[nginx-botsearch]

enabled  = true
port     = http,https
filter   = nginx-botsearch
logpath  = /config/log/nginx/access.log


[emby]

enabled  = true
port     = http,https
filter   = emby
logpath  = /logs/emby/server-*.txt


[nc-nginx-http-auth]

enabled  = true
filter   = nginx-http-auth
port     = http,https
logpath  = /logs/nc_nginx/error.log


[nc-nginx-badbots]

enabled  = true
port     = http,https
filter   = nginx-badbots
logpath  = /logs/nc_nginx/access.log
maxretry = 2


[nc-nginx-botsearch]

enabled  = true
port     = http,https
filter   = nginx-botsearch
logpath  = /logs/nc_nginx/access.log


[nextcloud]

enabled  = true
port     = http,https
filter   = nextcloud
logpath = /logs/nextcloud/nextcloud.log

 

I added ../fail2ban/filter.d/emby.conf

# Fail2Ban filter for emby
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf


[Definition]

_daemon = emby-server

failregex = Info HttpServer: HTTP Response 401 to <HOST>.*authenticatebyname
            Info HttpServer: HTTP Response 500 to <HOST>.*mediabrowser/Users/None

ignoreregex =

# DEV Notes:
#
#       Matching on http 401 with a trailing url including 'authenticatebyname' to catch incorrect passwords
#       Matching on http 500 with a trailing url including 'mediabrowser/Users/None' to catch incorrect usernames
#
# Author: [email protected]
I also added ../fail2ban/filter.d/nextcloud from here https://github.com/hailthemelody/nextcloud-fail2ban
# Fail2Ban filter for Nextcloud

[INCLUDES]
before = common.conf

[Definition]
failregex = Login failed.*Remote IP.*'<HOST>'
ignoreregex =

 

Edited by dmacias
Link to comment

Thanks for the comprehensive writeup, very helpful thanks.

 

I had understood, obviously wrongly that fail2ban would still block attempts at the proxy first, but after testing this I do get the correct IP address to ban.

 

If I have understood correctly, the base setup for the letsencrypt docker will only log and block .htaccess failures via nginx, but as I don't use that for nextcloud and piwik, neither would be protected by fail2ban.  

 

I moved the nextcloud.log to my nextcloud data directly, rather than mounting my data directly from letsencypt and note that the config.php edits are also needed to get nextcloud to output the log to the appropriate place :)

 

Works nicely, thanks.

 

Now to see if I can do the same with Piwik and get them both logged by netdata :)

Edited by local.bin
Link to comment
Great container, replaces a VM I had running that had the same functions, but took a lot more resources.
 
In the VM I had running, I used sSMTP to send fail2ban emails.  Would it be possible to add this in a future release?  Or is there already a way of sending email in the container?


The container has sendmail you can use
Link to comment

Let me apologize in advance for the moronic questions, but I'm an absolute beginner when it comes to linux/dockers/etc ....

 

I telnet into unRAID, and use 'docker exec -it letsencrypt /bin/bash' to get to the command line.  When I try testing by 'sendmail [email protected] < /tmp/testmail.txt' I get the response 'can't connect to remote host (127.0.0.1): Connection refused' which I am guessing means that sendmail isn't configured.  I look in /etc and I can't find anything - no mail or sendmail folder, no sendmail.conf, nothing at all.  Using find to search the entire image, I still don't see anything.

 

I'm completely lost, what am I doing wrong?  Appreciative of any advice you could give.

Link to comment
3 hours ago, dukiethecorgi said:

Let me apologize in advance for the moronic questions, but I'm an absolute beginner when it comes to linux/dockers/etc ....

 

I telnet into unRAID, and use 'docker exec -it letsencrypt /bin/bash' to get to the command line.  When I try testing by 'sendmail [email protected] < /tmp/testmail.txt' I get the response 'can't connect to remote host (127.0.0.1): Connection refused' which I am guessing means that sendmail isn't configured.  I look in /etc and I can't find anything - no mail or sendmail folder, no sendmail.conf, nothing at all.  Using find to search the entire image, I still don't see anything.

 

I'm completely lost, what am I doing wrong?  Appreciative of any advice you could give.

 

I have gone through exactly the same process today and as you found no config files to setup proxying to gmail to be able to send emails out.

 

I had to park it for now, but we must be missing something simple, as installing sendmail should have created the config files somewhere. At least thats my thought process :)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.