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


Recommended Posts

2 hours ago, SNReloaded said:

Here's the docker run (it would have been faster to just say "edit the config & it'll give the run command")

SWAG:


root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='swag' --net='bridge' -e TZ="America/Chicago" -e HOST_OS="Unraid" -e 'EMAIL'='snreloaded@snreloaded.stream' -e 'URL'='snreloaded.stream' -e 'SUBDOMAINS'='home,' -e 'ONLY_SUBDOMAINS'='true' -e 'VALIDATION'='http' -e 'DNSPLUGIN'='' -e 'EXTRA_DOMAINS'='' -e 'STAGING'='false' -e 'DUCKDNSTOKEN'='' -e 'PROPAGATION'='' -e 'PUID'='99' -e 'PGID'='100' -p '1880:80/tcp' -p '18443:443/tcp' -v '/mnt/user/appdata/swag':'/config':'rw' --cap-add=NET_ADMIN 'linuxserver/swag'
1eb3775caaf9f7ab02460256f1579bb3ce6e34d1174f318cfcee9dd775e67091

 

Nextcloud:


root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='nextcloud' --net='bridge' -e TZ="America/Chicago" -e HOST_OS="Unraid" -e 'PUID'='99' -e 'PGID'='100' -p '444:443/tcp' -v '/mnt/user/nextcloud/':'/data':'rw' -v '/mnt/user/appdata/nextcloud':'/config':'rw' 'linuxserver/nextcloud'
22e325a33923bd38a0e9e96159c43bbb20351efa7bcd948abdc4337ccce2d5fa

 

For you, yes, but not for me. So you want me to use more of my time, so you can use less of yours, fixing your problem?

 

Change the port in the proxy conf to 443 and create a custom docker network and set both swag and nextcloud to use that one.

  • Like 1
Link to comment
31 minutes ago, saarg said:

Change the port in the proxy conf to 443 and create a custom docker network and set both swag and nextcloud to use that one.

I'm really trying here, & I've spent the last half hour trying to figure out how to create a custom docker network. I looked through the entirety of the docker faq, & it was not described there. I did set nextcloud's docker image to use 443, & I changed proxy-confs upstream to use 443. I set custom: br0 to use 192.168.1.199, & I tried to do that as well for SWAG, but then I got this docker run error

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='swag' --net='br0' --ip='192.168.1.199' -e TZ="America/Chicago" -e HOST_OS="Unraid" -e 'TCP_PORT_80'='1880' -e 'TCP_PORT_443'='443' -e 'EMAIL'='snreloaded@snreloaded.stream' -e 'URL'='snreloaded.stream' -e 'SUBDOMAINS'='home,' -e 'ONLY_SUBDOMAINS'='true' -e 'VALIDATION'='http' -e 'DNSPLUGIN'='' -e 'EXTRA_DOMAINS'='' -e 'STAGING'='false' -e 'DUCKDNSTOKEN'='' -e 'PROPAGATION'='' -e 'PUID'='99' -e 'PGID'='100' -v '/mnt/user/appdata/swag':'/config':'rw' --cap-add=NET_ADMIN 'linuxserver/swag'
4006ab65315419844b517497e8efa997b2e6ff31ded83a9197708da1d0afe837
/usr/bin/docker: Error response from daemon: Address already in use.

This makes sense that the IP is already in use, but I'm not understanding how to get both swag & nextcloud to use the docker network

Link to comment

Hi friends! Looking for advise/guidance.....I currently have swag working with unraid and several containers like Sonarr, Nextcloud etc.....I was wondering if I could use Swag to reverse proxy to other servers I have on my LAN (not on the unraid box). For example I have a synology NAS ruuning my cameras at 192.168.1.22. Is it possible to use Swag to reverse proxy to https://dscam.mydomain.com? I am thinking it would be but am unsure how to setup the .conf file. I am using the custom docker network that SI setup in his videos and it works great for reverse proxying to unraid containers just wasnt sure about LAN devices. 

 

A newb looking for advise with trying to make this work :)

TIA

 

 

Edited by bclinton
Link to comment
57 minutes ago, bclinton said:

Hi friends! Looking for advise/guidance.....I currently have swag working with unraid and several containers like Sonarr, Nextcloud etc.....I was wondering if I could use Swag to reverse proxy to other servers I have on my LAN (not on the unraid box). For example I have a synology NAS ruuning my cameras at 192.168.1.22. Is it possible to use Swag to reverse proxy to https://dscam.mydomain.com? I am thinking it would be but am unsure how to setup the .conf file. I am using the custom docker network that SI setup in his videos and it works great for reverse proxying to unraid containers just wasnt sure about LAN devices. 

 

A newb looking for advise with trying to make this work :)

TIA

 

 

You just have to change the upstream_app variable from container name to the IP of the app you want to proxy.

Link to comment

I have created a fail2ban tutorial below to get you setup to 100% working order.

 

Tutorial:

fail2ban does start automatically with swag, but the client side doesnt, so for testing purposes, lets start it.  You need to goto swags console and type

fail2ban-client start

 

Next you need to edit your jail.local file to create a jail for a particular service.  In my example I will do Guacamole.  Enter the following text into jail.local file, located in your appdata/swag/fail2ban folder

 

[guacamole]
enabled  = true
filter   = guacamole_custom
port     = http,https
logpath  = /appdata/ApacheGuacamole/log/tomcat9/catalina.out 

 

Your logpath should be pointing to where your services log files are located.  It this particular case, I am pointing to /appdata/ApacheGuacamole/log/tomcat9/catalina.out because that is where the log files for Guacamole are kept on my server  (Dont forget to define your appdata path in the Swag Unraid Template)

 

Next you must create a filter file.  Goto the appdata/swag/fail2ban/filter.d folder and create a new file.  Now in this particular case, Guacamole already has a guacamole.conf, except It appears to be using formatting for an old version of guacamoles logs.  This can be a problem using the prebuilt .conf files because all these apps are constantly updating and the log files for these apps sometimes change locations or text formatting.  In this case, "nWARNING" is text that guacamole no longer uses when describing a failed login attempt in its logs.  To make matters worse, every time you restart your swag container, these .conf files will be overwritten, so you cant make any changes to them.  So to get around this, I'm going to create my own new .conf file. I'll call it guacamole_custom.conf.  You'll also notice that I have "filter   = guacamole_custom" in the jail.local file as shown above.  This is to make sure my jail is pointing to the correct filter.

Now inside the guacamole_custom.conf file, we need to define the regex that will match the log file.  This is basically reading the log files that guacamole produces, and matching the line for when a person enter incorrect credentials and then grabbing the ip.  For this part its best to get help by googleing around for a fail2ban regex for your service that youre trying to set this up for.  in Guacamoles case, as of Feburary 2021,  The below code is confirmed to be working:

 

[Definition]
failregex = Authentication attempt from <HOST> for user "[^"]*" failed\.$
  
ignoreregex = 
  
# "maxlines" is number of log lines to buffer for multi-line regex searches
maxlines = 2

datepattern = ^%%b %%d, %%ExY %%I:%%M:%%S %%p
              ^WARNING:()**
              {^LN-BEG}


 

To be honest, you might not even need most of that, just the failregex line is important.  Now when somebody makes a filed attempt to login, fail2ban will read guacamoles log file, and find the failed attempt.  I can test the filter to make sure it works by typing this command

 

fail2ban-regex /appdata/ApacheGuacamole/log/tomcat9/catalina.out /config/fail2ban/filter.d/guacamole_custom.conf

 

Doing this I get:

 

Running tests
=============

Use   failregex filter file : guacamole_custom, basedir: /config/fail2ban
Use         maxlines : 2
Use      datepattern : Default Detectors
Use         log file : /appdata/ApacheGuacamole/log/tomcat9/catalina.out
Use         encoding : UTF-8


Results
=======

Failregex: 27 total
|-  #) [# of hits] regular expression
|   1) [27] Authentication attempt from <HOST> for user "[^"]*" failed\.$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [468] {^LN-BEG}24hour:Minute:Second
|  [25] ^WARNING:()**
`-

Lines: 1455 lines, 0 ignored, 27 matched, 1428 missed
[processed in 0.09 sec]

Missed line(s): too many to print.  Use --print-all-missed to print all 1428 lines

 

You can see its working, because it found 27 matches currently in the log file.  So now restart Swag (Restarting fail2ban appears to fail, restart the entire swag docker).  After the swag container is restarted, start fail2ban again from the swag console with

fail2ban-client start


Now I can check my jail status with this command

fail2ban-client status guacamole

 

Status for the jail: guacamole
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /appdata/ApacheGuacamole/log/tomcat9/catalina.out
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

 

Now lets try logging in 5 times incorrectly and getting our IP banned.  Now I get this
 

Status for the jail: guacamole
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     5
|  `- File list:        /appdata/ApacheGuacamole/log/tomcat9/catalina.out
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   My_IP


EDIT: This should all be setup and working now.  You wont need to start the fail2ban-client everytime swag starts for it to work as it will run as a service. The hardest part of getting fail2ban working is the Regex for the particular app youre using.  Its not exactly easy to figure out the coding and often you will have to rely on somebody else to provide it.  Im still trying to hunt down regex for OMBI.

(Nginx proxy manager is a swag alternative which is GUI based and MUCH easier to setup and use than SWAG.  It does not include fail2ban however.  fail2ban also has a GUI for it called fail2web so perhaps one day that will be implemented and we can easily set rules for log matching rather than doing everything through command line and regex code).  If you need fail2ban today, struggle with it in SWAG.  If not, I recommend you just use Nginx proxy manager.  Its so easy you don't even need a guide to figure it out.  its also available for unraid!)

Edited by 007craft
Link to comment
8 hours ago, 007craft said:

I have created a fail2ban tutorial below to get you setup to 95% working order.  It derails at the end as I ran into a problem and cannot solve it.

 

Tutorial:

fail2ban does not start automatically with swag.  you need to goto console and type


fail2ban-client start

 

Next you need to edit your jail.local file to create a jail for a particular service.  In my example I will do Guacamole.  Enter the following text into jail.local file, located in your appdata/swag/fail2ban folder

 


[guacamole]
enabled  = true
filter   = guacamole_custom
port     = http,https
logpath  = /appdata/ApacheGuacamole/log/tomcat9/catalina.out 

 

Your logpath should be pointing to where your services log files are located.  It this particular case, I am pointing to /appdata/ApacheGuacamole/log/tomcat9/catalina.out because that is where the log files for Guacamole are kept on my server  (Dont forget to define your appdata path in the Swag Unraid Template)

 

Next you must create a filter file.  Goto the appdata/swag/fail2ban/filter.d folder and create a new file.  Now in this particular case, Guacamole already has a guacamole.conf, except It appears to be using formatting for an old version of guacamoles logs.  This can be a problem using the prebuilt .conf files because all these apps are constantly updating and the log files for these apps sometimes change locations or text formatting.  In this case, "nWARNING" is text that guacamole no longer uses when describing a failed login attempt in its logs.  To make matters worse, every time you restart your swag container, these .conf files will be overwritten, so you cant make any changes to them.  So to get around this, I'm going to create my own new .conf file. I'll call it guacamole_custom.conf.  You'll also notice that I have "filter   = guacamole_custom" in the jail.local file as shown above.  This is to make sure my jail is pointing to the correct filter.

Now inside the guacamole_custom.conf file, we need to define the regex that will match the log file.  This is basically reading the log files that guacamole produces, and matching the line for when a person enter incorrect credentials and then grabbing the ip.  For this part its best to get help by googleing around for a fail2ban regex for your service that youre trying to set this up for.  in Guacamoles case, as of Feburary 2021,  The below code is confirmed to be working:

 


[Definition]
failregex = Authentication attempt from <HOST> for user "[^"]*" failed\.$
  
ignoreregex = 
  
# "maxlines" is number of log lines to buffer for multi-line regex searches
maxlines = 2

datepattern = ^%%b %%d, %%ExY %%I:%%M:%%S %%p
              ^WARNING:()**
              {^LN-BEG}


 

To be honest, you might not even need most of that, just the failregex line is important.  Now when somebody makes a filed attempt to login, fail2ban will read guacamoles log file, and find the failed attempt.  I can test the filter to make sure it works by typing this command

 


fail2ban-regex /appdata/ApacheGuacamole/log/tomcat9/catalina.out /config/fail2ban/filter.d/guacamole_custom.conf

 

Doing this I get:

 


Running tests
=============

Use   failregex filter file : guacamole_custom, basedir: /config/fail2ban
Use         maxlines : 2
Use      datepattern : Default Detectors
Use         log file : /appdata/ApacheGuacamole/log/tomcat9/catalina.out
Use         encoding : UTF-8


Results
=======

Failregex: 27 total
|-  #) [# of hits] regular expression
|   1) [27] Authentication attempt from <HOST> for user "[^"]*" failed\.$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [468] {^LN-BEG}24hour:Minute:Second
|  [25] ^WARNING:()**
`-

Lines: 1455 lines, 0 ignored, 27 matched, 1428 missed
[processed in 0.09 sec]

Missed line(s): too many to print.  Use --print-all-missed to print all 1428 lines

 

You can see its working, because it found 27 matches currently in the log file.  So now restart Swag (Restarting fail2ban appears to fail, restart the entire swag docker).  After the swag container is restarted, start fail2ban again from the swag console with


fail2ban-client start


Now I can check my jail status with this command


fail2ban-client status guacamole

 


Status for the jail: guacamole
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /appdata/ApacheGuacamole/log/tomcat9/catalina.out
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

 

Now lets try logging in 5 times incorrectly and getting our IP banned.  Now I get this
 


Status for the jail: guacamole
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     5
|  `- File list:        /appdata/ApacheGuacamole/log/tomcat9/catalina.out
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   My_IP


However I am afraid this is where this tutorial ends because at this point even tho the IP is banned, it will still have access to try logging in.  The reason for this is because the fail2ban ACTION (as defined in the iptables-allports.conf) does not appear to be configured correctly to work within docker.  Currently the IP is indeed added to the iptables within the swag container.  You can see this by typing in the swag console:
 


 iptables -L

 

And this is the code returned


Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
f2b-guacamole  tcp  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain f2b-guacamole (1 references)
target     prot opt source               destination         
REJECT     all  --  My_IP               anywhere             reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere   


I believe the problem is that Unraid doesnt see that f2b-guacamole chain.  As typing "iptables -L" into the UNRAID console shows no such connection as seen below.

 


Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
LIBVIRT_INP  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
LIBVIRT_FWX  all  --  anywhere             anywhere            
LIBVIRT_FWI  all  --  anywhere             anywhere            
LIBVIRT_FWO  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
LIBVIRT_OUT  all  --  anywhere             anywhere   

 

Perhaps the Devs for this container can chime in here (or even update the container) to include the correct actions we need to pass the banned IP?

Fail2ban starts when the container starts. It's started in /etc/services.d/fail2ban/run

Link to comment
9 hours ago, saarg said:

Fail2ban starts when the container starts. It's started in /etc/services.d/fail2ban/run

I guess it looks like the service is running in the background, but the client side doesnt start automatically

ezgif-2-c08663d26874.gif

 

Edited by 007craft
Link to comment

Most of my subdomains are setup and working with swag.  But how do I setup the main domain?  In the unraid template I set "only subdomains" to false and this seems to ahve worked because going to www.mydomain.com gives me an ssl cert, but right into this screen

image.png.1ecf34f5f97d78ec732b965efc54f0df.png
 

I assume I need to edit the file "default" in  the site-confs folder but I tried that, replacing this text

location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_pass 192.168.1.102:8096;
		fastcgi_index index.php;
		include /etc/nginx/fastcgi_params;
	}


With this which is used in my subdomain file (which works):

location / {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app jellyfin;
        set $upstream_port 8096;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_set_header Range $http_range;
        proxy_set_header If-Range $http_if_range;
    }

    location ~ (/jellyfin)?/socket {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app jellyfin;
        set $upstream_port 8096;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

 

but it doesnt work.  The setup video only mentions setting up the reverse proxy for sub domains, not the main domain.
 

Link to comment
18 hours ago, 007craft said:

I guess it looks like the service is running in the background, but the client side doesnt start automatically

ezgif-2-c08663d26874.gif

 

Never used it, so can't really help with it. Did you modify any config files related to fail2ban that might interfere with it?

Link to comment

Hey community,

i add in nextcloud config.php trusted domains -> mywebsite.de

 

in the pictures you see my swag default config with the error of letsencrypt.

i don't understand why the port doesn't work.

 

(the blanc one is my website)

what do i wrong ? i just wanna use swag (not reverse proxy)

 

nxc: 192.168.1.2:9443

swag: 192.168.1.2:4443 ( is closed )

 

Solution: check my domain that he knows my ip

 

site-confs.default.png

port.png

Edited by srepper
Link to comment
On 1/17/2021 at 3:12 PM, _rogue said:

So I have been banging my head off the wall trying to figure this out. I have searched this thread and google as much as I can. I think I might just not have the right search terms to get the info I need. (or something is not working right)

 

I am trying to get nginx to pass the real client IP to the backend. I cannot figure for the life of me why it does not work. My proxy.conf is set to default right now but I have tried every combination of settings I can think of. It appears that I am passing a list of IPs to the backend that includes both the reverse proxy and the client IPs but apps are only reading the reverse proxy IP. I need to get it to pass just the client IP. How do I do this?

 

Was this ever resolved?  I am having the same issue and the same bad luck with google.  The only thing I am trying to proxy right now is self-hosted Bitwarden container.  Then only conf I changed was the Bitwarden proxy one to rename it to bitwardenrs.  I followed Spaceinvaders videos for the most part and am using a user defined bridge network.  Everything works as far as clients accessing Bitwarden through the domain.   But all access through nginx gets reported as coming from my Unraid server's IP address and everything in the Bitwarden log is either from the Unraid server's IP address or the address of the Swag docker.  Is this just how it works inside docker? I was previously using nginx directly (not in a container) on an Arch vm and always got the real internet ip addresses in the logs.  But I was really hoping to ditch that vm and go with an all container solution.

 

I'm not sure what other information to provide.  Any help would be greatly appreciated?

Link to comment
18 hours ago, brentdog said:

Was this ever resolved?  I am having the same issue and the same bad luck with google.  The only thing I am trying to proxy right now is self-hosted Bitwarden container.  Then only conf I changed was the Bitwarden proxy one to rename it to bitwardenrs.  I followed Spaceinvaders videos for the most part and am using a user defined bridge network.  Everything works as far as clients accessing Bitwarden through the domain.   But all access through nginx gets reported as coming from my Unraid server's IP address and everything in the Bitwarden log is either from the Unraid server's IP address or the address of the Swag docker.  Is this just how it works inside docker? I was previously using nginx directly (not in a container) on an Arch vm and always got the real internet ip addresses in the logs.  But I was really hoping to ditch that vm and go with an all container solution.

 

I'm not sure what other information to provide.  Any help would be greatly appreciated?

 

So I gave up trying to figure it out. What I think is happening is the applications we are proxying are showing the client IP they "discovered" rather than the one they are told about. You cannot change the actual source IP because the app has to respond to the proxy at the proxies IP. Make sense?

Basically the backend apps are not following the expression "Do as I say, not as I do" when it comes to logging. Pfsense shows both the proxy IP and client IP, Librespeed shows just the client IP and Tautuli shows just the proxy IP. Issue is not with SWAG but with the backend app.

Link to comment
On 2/22/2021 at 1:58 AM, 007craft said:

I have created a fail2ban tutorial below to get you setup to 95% working order.  It derails at the end as I ran into a problem and cannot solve it.

 

Tutorial:

fail2ban does not start automatically with swag.  you need to goto console and type


fail2ban-client start

 

Next you need to edit your jail.local file to create a jail for a particular service.  In my example I will do Guacamole.  Enter the following text into jail.local file, located in your appdata/swag/fail2ban folder

 


[guacamole]
enabled  = true
filter   = guacamole_custom
port     = http,https
logpath  = /appdata/ApacheGuacamole/log/tomcat9/catalina.out 

 

Your logpath should be pointing to where your services log files are located.  It this particular case, I am pointing to /appdata/ApacheGuacamole/log/tomcat9/catalina.out because that is where the log files for Guacamole are kept on my server  (Dont forget to define your appdata path in the Swag Unraid Template)

 

Next you must create a filter file.  Goto the appdata/swag/fail2ban/filter.d folder and create a new file.  Now in this particular case, Guacamole already has a guacamole.conf, except It appears to be using formatting for an old version of guacamoles logs.  This can be a problem using the prebuilt .conf files because all these apps are constantly updating and the log files for these apps sometimes change locations or text formatting.  In this case, "nWARNING" is text that guacamole no longer uses when describing a failed login attempt in its logs.  To make matters worse, every time you restart your swag container, these .conf files will be overwritten, so you cant make any changes to them.  So to get around this, I'm going to create my own new .conf file. I'll call it guacamole_custom.conf.  You'll also notice that I have "filter   = guacamole_custom" in the jail.local file as shown above.  This is to make sure my jail is pointing to the correct filter.

Now inside the guacamole_custom.conf file, we need to define the regex that will match the log file.  This is basically reading the log files that guacamole produces, and matching the line for when a person enter incorrect credentials and then grabbing the ip.  For this part its best to get help by googleing around for a fail2ban regex for your service that youre trying to set this up for.  in Guacamoles case, as of Feburary 2021,  The below code is confirmed to be working:

 


[Definition]
failregex = Authentication attempt from <HOST> for user "[^"]*" failed\.$
  
ignoreregex = 
  
# "maxlines" is number of log lines to buffer for multi-line regex searches
maxlines = 2

datepattern = ^%%b %%d, %%ExY %%I:%%M:%%S %%p
              ^WARNING:()**
              {^LN-BEG}


 

To be honest, you might not even need most of that, just the failregex line is important.  Now when somebody makes a filed attempt to login, fail2ban will read guacamoles log file, and find the failed attempt.  I can test the filter to make sure it works by typing this command

 


fail2ban-regex /appdata/ApacheGuacamole/log/tomcat9/catalina.out /config/fail2ban/filter.d/guacamole_custom.conf

 

Doing this I get:

 


Running tests
=============

Use   failregex filter file : guacamole_custom, basedir: /config/fail2ban
Use         maxlines : 2
Use      datepattern : Default Detectors
Use         log file : /appdata/ApacheGuacamole/log/tomcat9/catalina.out
Use         encoding : UTF-8


Results
=======

Failregex: 27 total
|-  #) [# of hits] regular expression
|   1) [27] Authentication attempt from <HOST> for user "[^"]*" failed\.$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [468] {^LN-BEG}24hour:Minute:Second
|  [25] ^WARNING:()**
`-

Lines: 1455 lines, 0 ignored, 27 matched, 1428 missed
[processed in 0.09 sec]

Missed line(s): too many to print.  Use --print-all-missed to print all 1428 lines

 

You can see its working, because it found 27 matches currently in the log file.  So now restart Swag (Restarting fail2ban appears to fail, restart the entire swag docker).  After the swag container is restarted, start fail2ban again from the swag console with


fail2ban-client start


Now I can check my jail status with this command


fail2ban-client status guacamole

 


Status for the jail: guacamole
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /appdata/ApacheGuacamole/log/tomcat9/catalina.out
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

 

Now lets try logging in 5 times incorrectly and getting our IP banned.  Now I get this
 


Status for the jail: guacamole
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     5
|  `- File list:        /appdata/ApacheGuacamole/log/tomcat9/catalina.out
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   My_IP


This should be setup now. however I am afraid this is where this tutorial ends because at this point even tho the IP is banned, it will still have access if its using anything outside the swag container.  The reason for this is because the fail2ban ACTION (as defined in the iptables-allports.conf) does not appear to be configured correctly to work within docker.  Currently the IP is indeed added to the iptables within the swag container.  You can see this by typing in the swag console:
 


 iptables -L

 

And this is the code returned


Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
f2b-guacamole  tcp  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain f2b-guacamole (1 references)
target     prot opt source               destination         
REJECT     all  --  My_IP               anywhere             reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere   


I believe the problem is that Unraid doesnt see that f2b-guacamole chain.  As typing "iptables -L" into the UNRAID console shows no such connection as seen below.

 


Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
LIBVIRT_INP  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
LIBVIRT_FWX  all  --  anywhere             anywhere            
LIBVIRT_FWI  all  --  anywhere             anywhere            
LIBVIRT_FWO  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
LIBVIRT_OUT  all  --  anywhere             anywhere   

 

I guess not a big deal if you want fail2ban working on any of the forwards you setup within swag, but wont help for any containers setup and routed to outside of swag.

Perhaps the Devs for this container can chime in here (or even update the container) to include the correct actions we need to pass the banned IP to root and out of the container?

 

I got the exact same results with my swag setup, fail2ban works and can log ips and add them in the iptables for the container, but are still not blocking the traffic for whatever reason, even if it is fully contained within swag.  Example, I have a bitwarden filter, am able to see my IP logged into the jail, but can still access even though it is in the f2b-bitwarden iptable entry as DENY.  It must have to do with what you said, dev input would be beneficial on this

Link to comment
4 hours ago, _rogue said:

 

So I gave up trying to figure it out. What I think is happening is the applications we are proxying are showing the client IP they "discovered" rather than the one they are told about. You cannot change the actual source IP because the app has to respond to the proxy at the proxies IP. Make sense?

Basically the backend apps are not following the expression "Do as I say, not as I do" when it comes to logging. Pfsense shows both the proxy IP and client IP, Librespeed shows just the client IP and Tautuli shows just the proxy IP. Issue is not with SWAG but with the backend app.

OK I feel stupid.  I had an OpenVPN server in front of nginx using the port-share option (probably should have mentioned that).  I have had this setup for years when nginx was on an Arch vm and always got the real ip in the nginx logs.  I switched back to my Arch vm just for grins and it was only seeing the Unraid server IP in the logs as well.  So something changed, I have no idea what.  I moved OpenVPN back to its standard port and have my router forwarding straight into swag and I now see the real client ip addresses in the access log.  I even see the real ip addresses in the Bitwarden log now to boot.

Link to comment

I have everything up and running. However if i wanted to redirect the root domain to overseerr not a subdomain how do i do that? Currently overseerr.domain.com works. I want just domain.com to goto the overseerr container.

Link to comment

Anyway I can use this without a subdomain or dns? I would like to generated certs for my local 10.10.60.100 for my local bitwarden docker. I followed invaders video replacing the duckdns.com portion to 10.10.60.100 with no luck

Link to comment

Had bare binhex-nginx installed and it worked fine. Got to the index.html without issues.

 

Wanted to use let's encrypt and it appears the swag was "the way" forward.

Can not get a validation for duckdns.org.

 

always fail at:

http-01 challenge for ???.duckdns.org
Waiting for verification...
Challenge failed for domain ???.duckdns.org

 

No logs are saved in var/log/**

nslookup for duckdns.org resolves to my public exposed ip address.

Any directions?

Link to comment
7 hours ago, -jim said:

Had bare binhex-nginx installed and it worked fine. Got to the index.html without issues.

 

Wanted to use let's encrypt and it appears the swag was "the way" forward.

Can not get a validation for duckdns.org.

 

always fail at:


http-01 challenge for ???.duckdns.org
Waiting for verification...
Challenge failed for domain ???.duckdns.org

 

No logs are saved in var/log/**

nslookup for duckdns.org resolves to my public exposed ip address.

Any directions?

Go West?

We are not mind readers, just so you know.

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.