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


Recommended Posts

4 hours ago, Nem said:

 

@aptalca I'm pretty new to using VPNs so to clarify: (assuming I'm using a weak admin password for ovpnas) if someone brute forces my password and gets into the webgui theres a section where they can upload their own SSL certificate, but isn't that certificate only used for the web interface, not the actual VPN connection? How would my LAN be compromised in that case? Or do you mean they can now change my server config and redirect traffic?

 

I guess all of this can be prevented anyway with a strong password for the admin account...?

 

The webgui allows you to manage all the vpn users and their certs. Someone with access to the webgui can create a user for themselves and download its cert so they can connect to your vpn and bam they are in your network.

Link to comment

Hello! Im having some issues getting Let's Encrypt to work. I have set it all up and the container starts. But as soon im trying to access it, im getting the error: " This site cannot be accessed. ERR_CONNECTION_REFUSED." 

 

Tried opening these ports: 80,81,443,444 basically tried every port in the spectrum ;) Nothing working tho. When trying to setup 443 and 80 i cant acess lets encrypt, it goes directly to Tower. So read somewhere that i should try 81 and 444 but that dosent work either. Is it something im missing or doing wrong? Would love some help with this ( Bit of a noob still on unraid) :)

lets.PNG

Link to comment
59 minutes ago, Greygoose said:

Click show more settings on the docker page and there is a setting there that needs changing. Go back a few pages in this thread for more details.

 

Also make sure you have forwarded in your router 80 to 81 and 443 to 444.

 

Did check the other posts. But can't get it to work :S Did setup the ports and all, but still ERR_CONNECTION_REFUSED. Also tried restart the computer and cleaned browser history. 

 

 

asdasdsadasdasd.PNG

asdasdadasdsadsadasd.PNG

Link to comment

We have a new test version of the letsencrypt image with dns validation support. I tested it with cloudflare and it works well. I need volunteers to test it with other dns providers. If you are using the following dns providers and are willing to test, please pm me and I'll send instructions.

 

Cloudflare (already tested)

Cloudxns

Digitalocean

Dnsimple

Dnsmadeeasy

Google

Luadns

Nsone

rfc2136

Route53 (aws)

  • Like 2
Link to comment
On 1/13/2018 at 2:08 PM, aptalca said:

 

You do not need to make changes to your nginx site config and you do not need to enable listening on port 80. Validation is done through a separate web server temporarily put up during validation and is not affected by your nginx config. 

 

 

I've read a few dozen posts and, as quoted above, the holy post. Still, if it's me being thick, let me know.

My question: I could swear I did actually have to change my nginx site config and was getting errors until I enabled port 80 (which has been off for months). Also, there's a ton of posts about having WAN port 80 map to 81, which maps to 80 inside the container. Why would all that be needed, if validation doesn't get done through my server on port 80? I'm sure there's a answer and that it's 90% likely to be that I'm an idiot, 9% likely something has changed, and 1% (shock/horror) the "no nginx changes/ separate web server" is misleading, easily misunderstood, or even incorrect.

In any case, feel free to ignore me--I'm up and running with this awesome image. Thank you all for a great thing and all your support and information here.

Link to comment
On 12/6/2017 at 9:21 PM, GilbN said:

Hi would you mind posting exactly what you've added for qbit please as I can't get it to work.

 

Thanks

Link to comment
14 minutes ago, Sophware said:

 

I've read a few dozen posts and, as quoted above, the holy post. Still, if it's me being thick, let me know.

My question: I could swear I did actually have to change my nginx site config and was getting errors until I enabled port 80 (which has been off for months). Also, there's a ton of posts about having WAN port 80 map to 81, which maps to 80 inside the container. Why would all that be needed, if validation doesn't get done through my server on port 80? I'm sure there's a answer and that it's 90% likely to be that I'm an idiot, 9% likely something has changed, and 1% (shock/horror) the "no nginx changes/ separate web server" is misleading, easily misunderstood, or even incorrect.

In any case, feel free to ignore me--I'm up and running with this awesome image. Thank you all for a great thing and all your support and information here.

 

Let me clarify, you do not need to enable listening on port 80 in the "nginx site config", because letsencrypt validation does not use the nginx webserver. During validation, it first stops nginx, and then puts up its own webserver (bootstrap based) that is listening on port 80. After validation, nginx is started back up.

 

So you do need port 80 forwarding on the router to the container and the container needs the mapping for port 80, but nginx does not need to listen on 80 through its site config.

 

In the past, validation was being done through port 443, so you didn't even need to forward port 80 on the router. But since letsencrypt disabled that, validation has to be done through 80.

Link to comment
15 minutes ago, aptalca said:

 

Let me clarify, you do not need to enable listening on port 80 in the "nginx site config", because letsencrypt validation does not use the nginx webserver. During validation, it first stops nginx, and then puts up its own webserver (bootstrap based) that is listening on port 80. After validation, nginx is started back up.

 

So you do need port 80 forwarding on the router to the container and the container needs the mapping for port 80, but nginx does not need to listen on 80 through its site config.

 

In the past, validation was being done through port 443, so you didn't even need to forward port 80 on the router. But since letsencrypt disabled that, validation has to be done through 80.

 

Sure enough. Everything is exactly as your post states. Clever and idiot proof (with only me, the over-thinker, as an exception).

 

Server ready.

 

Thank you.

Link to comment
3 hours ago, GilbN said:

wow that site's a potential treasure trove - thanks!

 

I've got QB working - thanks.  For bonus marks, I tried to copy your unifi implemention but I'm getting security errors when i go to unifi.domain.com - do I need to do more than amend your https://github.com/gilbN/Nostromo/blob/master/Server/nginx/site-confs/unifi file?

Link to comment
4 minutes ago, phildep8 said:

Is there any plan to upgrade to the latest Certbot version?

I keep getting this message and can't access anything since it will not start properly.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

 

Issue is opened here: https://community.letsencrypt.org/t/solution-client-with-the-currently-selected-authenticator-does-not-support-any-combination-of-challenges-that-will-satisfy-the-ca/49983 

 

Has nothing to do with the certbot version. Read the last few pages here, and the docker info

Link to comment
8 hours ago, DZMM said:

wow that site's a potential treasure trove - thanks!

 

I've got QB working - thanks.  For bonus marks, I tried to copy your unifi implemention but I'm getting security errors when i go to unifi.domain.com - do I need to do more than amend your https://github.com/gilbN/Nostromo/blob/master/Server/nginx/site-confs/unifi file?

 

Did you add your sub domain in all the places in the /location block? And remove the include line if you don't use organizr.

Link to comment
12 hours ago, aptalca said:

We have a new test version of the letsencrypt image with dns validation support. I tested it with cloudflare and it works well. I need volunteers to test it with other dns providers. If you are using the following dns providers and are willing to test, please pm me and I'll send instructions.

 

Cloudflare (already tested)

Cloudxns

Digitalocean

Dnsimple

Dnsmadeeasy

Google

Luadns

Nsone

rfc2136

Route53 (aws)

@aptalca You rock!  you made my decision an easy one...I'm changing from NO-IP to Cloudflare.  I've been thinking about doing it anyways because Cloudflare's free service it better than NO-IP's paid service.  Done a lot of research so I wouldn't have to bother you but I though that reading the inclusion of DNS-01 verification warranted a big thank you. 

Link to comment
2 hours ago, Rudder2 said:

@aptalca You rock!  you made my decision an easy one...I'm changing from NO-IP to Cloudflare.  I've been thinking about doing it anyways because Cloudflare's free service it better than NO-IP's paid service.  Done a lot of research so I wouldn't have to bother you but I though that reading the inclusion of DNS-01 verification warranted a big thank you. 

 

Glad to hear it ;-)

Link to comment
On 24/01/2018 at 9:55 AM, Nem said:

@Ding Dong Del Ive finally managed to get ovpn-as webgui running through a reverse proxy by just using a subdomain and another server block in the config. But Im also intrigued by your use of the same port for both https and vpn traffic. I'm wondering why you chose to use hostnames/streams/subdomains to redirect traffic instead of using the port share feature of ovpn?

@Nem

 

it was probably equal parts ignorance, and equal parts stubbornness :)

I was playing with / had set up my reverse proxy virtual directories first, before deciding to set up a vpn.

 

Even though if I used a vpn to connect home, I didn't really need anything exposed, I was pretty pleased with myself having set up the virtual dirs, so didn't want to take them down.....

Silly I know....

 

Same thing, I don't use the webgui of ovpn - I always use a vpn client. By the time I realised I could use the port share feature of ovpn I was too lazy to undo my work (even though it probably ended up being more work setting up the stream approach).

 

so I set them both up to be available on 443 because I didn't want to open too many ports on my fw, and because I wanted to be able to get to either from behind e.g. a corporate firewall which I am sure will have outbound 443 open (but probably couldn't rely on much else being open)

Link to comment
7 hours ago, GilbN said:

 

Did you add your sub domain in all the places in the /location block? And remove the include line if you don't use organizr.

I think I did it all right (but obviously not!):

 

#UNIFI CONTROLLER

server {
        listen 80;
        server_name unifi.MY-DOMAIN.com;
        return 301 https://unifi.MY-DOMAIN.com;
	}
		
server {
        listen 443 ssl;
        server_name unifi.MY-DOMAIN.com;
		
# SSL settings
	ssl_certificate /config/etc/letsencrypt/live/MY-DOMAIN.duckdns.org/fullchain.pem;
	ssl_certificate_key /config/etc/letsencrypt/live/MY-DOMAIN.duckdns.org/privkey.pem;
	ssl_session_cache   shared:SSL:10m;
	ssl_session_timeout 10m;
        keepalive_timeout   300;
	ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
	ssl_prefer_server_ciphers on;
		
	proxy_cache off;
        proxy_store off;
		
#	Organizr auth
#	include /config/nginx/serverauth.conf;
		
       location / {
		auth_request /auth-admin;
                proxy_cookie_domain unifi.MY-DOMAIN.com $host;
                sub_filter unifi.MY-DOMAIN.com $host;
                proxy_cookie_domain $server_name $host;
                sub_filter unifi.MY-DOMAIN>COM $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header HOST $http_host;
                proxy_pass https://192.168.50.97:8443;
                proxy_hide_header X-Frame-Options;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
        location /ws/ {
		auth_request /auth-admin;
                proxy_pass http://192.168.50.97:8443/ws/;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
}

I get a privacy error on my LAN, and nothing off LAN.

 

For qbittorrent, it loads...but, I can't use the menus e.g right-clicking to stop seeding etc.  Is there a change I'm supposed to make in QBT, or should your config work ok? 

 

# QBITTORRENT CONTAINER

location /qbt {
        return 301 /qbt/;
    }	
	
location ~ /qbt/(?<url>.*) {
    proxy_pass  http://192.168.20.73:8080/$url;
    proxy_set_header   X-Forwarded-Host  $host:$server_port;
    proxy_hide_header  Referer;
    proxy_hide_header  Origin;
    proxy_set_header   Referer           '';
    proxy_set_header   Origin            '';
	add_header X-Frame-Options "SAMEORIGIN";
	}

 

PS I have my qbut config in default and unifi in site-confs/unifi which is a bit different to you - don't know if this matters

 

 

 

 

Link to comment
2 hours ago, DZMM said:

I think I did it all right (but obviously not!):

 


#UNIFI CONTROLLER

server {
        listen 80;
        server_name unifi.MY-DOMAIN.com;
        return 301 https://unifi.MY-DOMAIN.com;
	}
		
server {
        listen 443 ssl;
        server_name unifi.MY-DOMAIN.com;
		
# SSL settings
	ssl_certificate /config/etc/letsencrypt/live/MY-DOMAIN.duckdns.org/fullchain.pem;
	ssl_certificate_key /config/etc/letsencrypt/live/MY-DOMAIN.duckdns.org/privkey.pem;
	ssl_session_cache   shared:SSL:10m;
	ssl_session_timeout 10m;
        keepalive_timeout   300;
	ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
	ssl_prefer_server_ciphers on;
		
	proxy_cache off;
        proxy_store off;
		
#	Organizr auth
#	include /config/nginx/serverauth.conf;
		
       location / {
		auth_request /auth-admin;
                proxy_cookie_domain unifi.MY-DOMAIN.com $host;
                sub_filter unifi.MY-DOMAIN.com $host;
                proxy_cookie_domain $server_name $host;
                sub_filter unifi.MY-DOMAIN>COM $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header HOST $http_host;
                proxy_pass https://192.168.50.97:8443;
                proxy_hide_header X-Frame-Options;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
        location /ws/ {
		auth_request /auth-admin;
                proxy_pass http://192.168.50.97:8443/ws/;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
}

I get a privacy error on my LAN, and nothing off LAN.

 

For qbittorrent, it loads...but, I can't use the menus e.g right-clicking to stop seeding etc.  Is there a change I'm supposed to make in QBT, or should your config work ok? 

 


# QBITTORRENT CONTAINER

location /qbt {
        return 301 /qbt/;
    }	
	
location ~ /qbt/(?<url>.*) {
    proxy_pass  http://192.168.20.73:8080/$url;
    proxy_set_header   X-Forwarded-Host  $host:$server_port;
    proxy_hide_header  Referer;
    proxy_hide_header  Origin;
    proxy_set_header   Referer           '';
    proxy_set_header   Origin            '';
	add_header X-Frame-Options "SAMEORIGIN";
	}

 

PS I have my qbut config in default and unifi in site-confs/unifi which is a bit different to you - don't know if this matters

 

 

 

 

 

you have 

auth_request /auth-admin;

in the location blocks. Remove those.  That is for server auth using Organizr.

 

And I dont use qbittorrent. So I didnt really test it. If you dont figure it out you could try sub domain. 

 

This worked better. 

 

server {
		listen 80;	
		listen 443 ssl http2;
		server_name qbit.domain.com;
			

location / {
    proxy_pass  http://192.168.1.34:8080;
    proxy_set_header   X-Forwarded-Host  $host:$server_port;
    proxy_hide_header  Referer;
    proxy_hide_header  Origin;
    proxy_set_header   Referer           '';
    proxy_set_header   Origin            '';
	add_header X-Frame-Options "SAMEORIGIN";			
    }
}

 

Link to comment
31 minutes ago, kreene1987 said:

I've thrown a recommendation in the upgrade notes that people change their ports away from 443 and 80 due to the conflict with the new Unraid SSL cert system.

 

Perhaps that will alleviate a lot of the common issues seen above.

 

Ut was already in the updates note ;-)

Link to comment
On 1/14/2018 at 4:59 PM, Living Legend said:

Same issues as the rest.  I've read the 100+ responses on how to fix.  I went to go edit the HTTPVAL option.  Can't find it.  I have advanced settings selected, and I've also clicked on "show more settings" and it's not there.  


I removed the docker and image and nothing different.

 

 

yeah I'm out of it today.

 

Sorry.

Link to comment
1 hour ago, phildep8 said:

 

Thanks, manually doing it with TXT record works fine. 

 

 

Right, so the method above worked as a workaround. I was asking more as a permanent solution.

 

Docker info contains a very simple permanent solution (unless your ISP blocks port 80, which you did not state whether it is the case or not)

Link to comment
8 hours ago, GilbN said:

 

you have 


auth_request /auth-admin;

in the location blocks. Remove those.  That is for server auth using Organizr.

 

And I dont use qbittorrent. So I didnt really test it. If you dont figure it out you could try sub domain. 

 

This worked better. 

 


server {
		listen 80;	
		listen 443 ssl http2;
		server_name qbit.domain.com;
			

location / {
    proxy_pass  http://192.168.1.34:8080;
    proxy_set_header   X-Forwarded-Host  $host:$server_port;
    proxy_hide_header  Referer;
    proxy_hide_header  Origin;
    proxy_set_header   Referer           '';
    proxy_set_header   Origin            '';
	add_header X-Frame-Options "SAMEORIGIN";			
    }
}

 

Thanks - sorted unifi.  Very happy as I can't use the unfi cloud access due to my firewall.

Link to comment

Just thought i would add in some more info, in case others have a case like mine

 

I initially said my hosting / domain provider didnt have an API for DNS. That is because i didnt understand what cloudfare was. 

 

So, for anyone who isnt aware, you can signup for a free cloudfare account, change your nameservers to point to cloudfares, and then use the cloudfare API to auto generate certs with the dns challenge. 

 

This is what i have setup at the moment, and hope to do in the future once/if the docker is updated to use the dns api scripts. 

 

 

Link to comment
On 22/01/2018 at 11:59 PM, aptalca said:

 

Check if there's anything listening on the host

 

So I’ve tried any number of things and am clearly missing something.

 

Details of latest specific attempt below at the bottom of my post, would appreciate any insight.

 

I’ve tried any number of combinations of things:

  • I have confirmed that port 80 is not blocked by temporarily forwarding external port 80 in my router to my Krusader container and have been able access successfully it via my dynamic domain name.
  • I have tried combinations of IPV4, and IPV6, host networking, bridge networking, I am currently using eth0 networking so that my LE container has a dedicated IPV4 address on my local 192.168.1.0/24 network.
  • In bridged mode, I confirmed there were no port conflicts by using 88, and 440 (respectively). I also used 80, and 443 on the host, after having moved the unraid UI to 81, and 444 respectively - a config I’ve used successfully on other hosts.
  • I’ve added —cap-add=NET_ADMIN as per the linxserver page for the LE container

 

HOST netstat output

root@cerberus:~# netstat -tulpn | grep -i listen

80,443 in this instance are the unraid UI’s - don’t think this is relevant given that the container has it’s own dedicated local ip (192.168.1.1 vs. 192.1.68.1.10 for the host - cerberus)



tcp        0      0 0.0.0.0:37              0.0.0.0:*               LISTEN      1597/inetd          

tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1643/smbd           

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1583/rpcbind        

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      8610/nginx: master  

tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      1597/inetd          

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1605/sshd           

tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      1597/inetd          

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      8610/nginx: master  

tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      1643/smbd           

tcp        0      0 0.0.0.0:59331           0.0.0.0:*               LISTEN      1587/rpc.statd      

tcp6       0      0 :::58185                :::*                    LISTEN      1587/rpc.statd      

tcp6       0      0 :::139                  :::*                    LISTEN      1643/smbd           

tcp6       0      0 :::111                  :::*                    LISTEN      1583/rpcbind        

tcp6       0      0 :::8080                 :::*                    LISTEN      29105/docker-proxy  

tcp6       0      0 :::80                   :::*                    LISTEN      8610/nginx: master  

tcp6       0      0 :::22                   :::*                    LISTEN      1605/sshd           

tcp6       0      0 :::443                  :::*                    LISTEN      8610/nginx: master  

tcp6       0      0 :::445                  :::*                    LISTEN      1643/smbd   

 

 I've also attached my letsencrypt log file from the LE container - note it still talks about the bind to :80 using IPV4 failing.

 

5a6aba0b821f0_ScreenShot2018-01-26at14_39_53.thumb.png.650173f61463bea63f932255449744be.png

 

Screen Shot 2018-01-26 at 14.40.51.png

Screen Shot 2018-01-26 at 14.34.21.png

Screen Shot 2018-01-26 at 14.34.37.png

Screen Shot 2018-01-26 at 14.34.10.png

Screen Shot 2018-01-26 at 14.33.37.png

letsencrypt.log

Edited by Ding Dong Del
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.