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


Recommended Posts

I seem to need some help setting up basic authentication. I've created a proxy configuration that works perfectly without authentication, added the user and password to /config/nginx/.htpasswd using the htpasswd command (which I've verified to work using the -v option) and now I only get 403/Forbidden when accessing the proxied page despite entering the correct username/password.

 

I haven't found anything useful in the logs, so I'd be very interested to hear from the experts where to start looking.

 

EDIT:
I have now set up another application which is simpler in the proxy configuration, authentication seems to work fine there. So I suspect it's something I had to do in my original proxy configuration that breaks authentication somehow.

 

Here is my proxy configuration:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name tvh.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    location / {
        # enable the next two lines for http auth
        auth_basic "Restricted";
        auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /login;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_tvheadend 192.168.1.81;
        proxy_pass http://$upstream_tvheadend:9981;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

The error looks like this:

82.102.24.174 - - [01/Nov/2019:05:26:21 +0100] "GET / HTTP/2.0" 401 179 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
82.102.24.174 - test [01/Nov/2019:05:26:25 +0100] "GET / HTTP/2.0" 302 173 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
82.102.24.174 - test [01/Nov/2019:05:26:26 +0100] "GET /extjs.html HTTP/2.0" 403 129 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
82.102.24.174 - test [01/Nov/2019:05:26:26 +0100] "GET /favicon.ico HTTP/2.0" 403 129 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"

To me this looks like a 401, which gets me redirected somewhere, only to end up at a 403 error it can't seem to get out of.

 

Any ideas?

Edited by drdebian
more info
Link to comment

I used the guide here to update my Nextcloud Docker: PSA: Nextcloud & CVE-2019-11043. Since then I am getting onyl an A security grade and some warnings:

Der „X-Content-Type-Options“-HTTP-Header ist nicht so konfiguriert, dass er „nosniff“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
Der „X-Robots-Tag“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
Der „X-Download-Options“-HTTP-Header ist nicht so konfiguriert, dass er „noopen“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
Der „X-Permitted-Cross-Domain-Policies“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.

Der "Referrer-Policy" HTTP-Header ist nicht gesetzt auf "no-referrer", "no-referrer-when-downgrade", "strict-origin", "strict-origin-when-cross-origin" oder "same-origin". Dadurch können Verweis-Informationen preisgegeben werden. Siehe die W3C-Empfehlung

Seems that the "default" file for Nextcloud is ok as no one in the Nextcloud forum identified any issues with my file

@saarg gave me the advise to check here if the "default" file of the Letsencrypt container could generate these warnings.

All three "default" files are attached below.

Thanks a lot for your help.

 

Edited by EdgarWallace
Link to comment
3 minutes ago, EdgarWallace said:

I used the guide here to update my Nextcloud Docker: PSA: Nextcloud & CVE-2019-11043. Since then I am getting onyl an A security grade and some warnings:


Der „X-Content-Type-Options“-HTTP-Header ist nicht so konfiguriert, dass er „nosniff“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
Der „X-Robots-Tag“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
Der „X-Download-Options“-HTTP-Header ist nicht so konfiguriert, dass er „noopen“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
Der „X-Permitted-Cross-Domain-Policies“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.

Der "Referrer-Policy" HTTP-Header ist nicht gesetzt auf "no-referrer", "no-referrer-when-downgrade", "strict-origin", "strict-origin-when-cross-origin" oder "same-origin". Dadurch können Verweis-Informationen preisgegeben werden. Siehe die W3C-Empfehlung

Seems that the "default" file for Nextcloud is ok as no one was able to identify any issues, so @saarg it might be a good idea to asked, if the "default" file for the Letsencrypt container could generate these warnings.

All three "default" files are attached below.

default.original is the file that I was using initially and that caused no warnings

default.regenerated is the file that was generated after having done the updates mentioned above

default.letsencrypt is selfexplanatory......

Thanks a lot for your help.

default.letsencrypt 1.81 kB · 0 downloads default.original 2.2 kB · 0 downloads default.regenerated 5.87 kB · 0 downloads

You have to post the warnings in English if you want any help resolving them. Isn't nextcloud suggesting fixes for it?

 

As for the default file, I don't have any warnings, except for strict transport security (HSTS) which I'm not enabling as it activates for the whole domain and can cause some issues.

  • Like 1
Link to comment

Anyone know if the nginx portion within the letsencrypt image includes the cache capability?  I added the below (+ server bloc)

 

When I add this: proxy_cache_path /config/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10G inactive=60m use_temp_path=off

I get this: nginx: [emerg] invalid parameter "include" in /config/nginx/nginx.conf:77(edited)

Line 77 is actually this line: include /etc/nginx/conf.d/*.conf;

Edited by Marshalleq
Link to comment
35 minutes ago, Marshalleq said:

Anyone know if the nginx portion within the letsencrypt image includes the cache capability?  I added the below (+ server bloc)

 

When I add this: proxy_cache_path /config/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10G inactive=60m use_temp_path=off

I get this: nginx: [emerg] invalid parameter "include" in /config/nginx/nginx.conf:77(edited)

Line 77 is actually this line: include /etc/nginx/conf.d/*.conf;

Sounds like you made an error when you edited.

I'm not familiar with nginx, so what it is I can't say.

Probably best to post the config so others might be able to point out the error.

Link to comment

I‘ve been experiencing an odd issue recently: For some reason, I cannot access the sites behind the reverse proxy when I‘m in the same network as my server. When connecting from outside my network (i.e. tethering), I can access Nextcloud, which is one of the programs sitting behind the reverse proxy, just fine.

 

I think that the error occurred after summertime was over. Not sure though, but I‘m assuming it was around that time.

 

I‘d appreciate any hints.

 

 

Link to comment
I‘ve been experiencing an odd issue recently: For some reason, I cannot access the sites behind the reverse proxy when I‘m in the same network as my server. When connecting from outside my network (i.e. tethering), I can access Nextcloud, which is one of the programs sitting behind the reverse proxy, just fine.
 
I think that the error occurred after summertime was over. Not sure though, but I‘m assuming it was around that time.
 
I‘d appreciate any hints.
 
 
This is normally due to nat reflection.

You could split DNS and point the local DNS to your local Host IP

Sent from my Pixel 4 XL using Tapatalk

Link to comment
5 minutes ago, Orejo said:

I‘ve been experiencing an odd issue recently: For some reason, I cannot access the sites behind the reverse proxy when I‘m in the same network as my server. When connecting from outside my network (i.e. tethering), I can access Nextcloud, which is one of the programs sitting behind the reverse proxy, just fine.

 

I think that the error occurred after summertime was over. Not sure though, but I‘m assuming it was around that time.

 

I‘d appreciate any hints.

 

 

This is controlled by your router. loopback, nat hairpinning, are some terms to google along with your router.

Link to comment

I am in the process of setting up Collabora according to SpaceinvaderOne's tutorial. I've added the relevant cname, added the Collabora app in Nextcloud, installed the Collabora docker container, and set up the LetsEncrypt proxy .conf file. When I restart the LE docker container, I get the following repeating error:

Quote

nginx: [emerg] "resolver" directive is duplicate in /config/nginx/proxy-confs/collabora.subdomain.conf:11

I'm not sure where the duplication is occurring (I mean, I realize it is pointing to line 11 in the code included below).

 

But, the only change I made to the .conf file from the sample included in the LE container was changing the subdomain name from 'collabora.*' to 'office.*'

 

Any thoughts?

 

Thanks

 

For reference, I've included the contents of my collabora.subdomain.conf file below:

# make sure that your dns has a cname set for collabora and that your collabora container is named collabora

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name office.*;

    include /config/nginx/ssl.conf;

    resolver 127.0.0.11 valid=30s;
    set $upstream_collabora collabora;

    # static files
    location ^~ /loleaflet {
        proxy_pass https://$upstream_collabora:9980;
        proxy_set_header Host $http_host;
    }

    # WOPI discovery URL
    location ^~ /hosting/discovery {
        proxy_pass https://$upstream_collabora:9980;
        proxy_set_header Host $http_host;
    }

    # Capabilities
    location ^~ /hosting/capabilities {
        proxy_pass https://$upstream_collabora:9980;
        proxy_set_header Host $http_host;
    }

    # main websocket
    location ~ ^/lool/(.*)/ws$ {
        proxy_pass https://$upstream_collabora:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $http_host;
        proxy_read_timeout 36000s;
    }

    # download, presentation and image upload
    location ~ ^/lool {
        proxy_pass https://$upstream_collabora:9980;
        proxy_set_header Host $http_host;
    }

    # Admin Console websocket
    location ^~ /lool/adminws {
        proxy_pass https://$upstream_collabora:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $http_host;
        proxy_read_timeout 36000s;
    }
}

 

Link to comment
2 hours ago, H2O_King89 said:

The request message was malformed :: Error creating new order :: Domain name "unraid.domain.com" is redundant with a wildcard domain in the same request. Remove one or the other from the certificate request.

 

You have your domain set up using wildcard and are trying to add a subdomain in the extra domain field?

Edited by saarg
Link to comment
11 hours ago, EdgarWallace said:

Thanks @saarg

Modifying default under /mnt/user/system/docker/appdata/letsencrypt/nginx/site-confs is having an effect:


The "Strict-Transport-Security" HTTP header is not set to at least "15552000" seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips ↗.

However I guess you are correct that the issues are generated by Nextcloud (this time in English):


    The "X-Content-Type-Options" HTTP header is not set to "nosniff". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
    The "X-Robots-Tag" HTTP header is not set to "none". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
    The "X-Frame-Options" HTTP header is not set to "SAMEORIGIN". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
    The "X-Download-Options" HTTP header is not set to "noopen". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
    The "X-Permitted-Cross-Domain-Policies" HTTP header is not set to "none". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
    The "Strict-Transport-Security" HTTP header is not set to at least "15552000" seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips ↗.

    The "Referrer-Policy" HTTP header is not set to "no-referrer", "no-referrer-when-downgrade", "strict-origin", "strict-origin-when-cross-origin" or "same-origin". This can leak referer information. See the W3C Recommendation ↗.

Strange enough, that my default is an exact copy of the Nginx configuration manual from Nextcloud.....that was the reason that I was asked to raise the question here.

 

The default file I'm talking about is the one in the nextcloud container. Not letsencrypts default file.

I don't know if we have the same config as in the nextcloud manual,  but you can delete it and our version will be restored when you restart the container.

The same goes for the default file of letsencrypt. At the top you will have a version number of the file and you can compare it with the default file in the github repo to see if you have the latest version. If you haven't made any edits to that file, you can safely delete it and the latest will be restored (if your container is up to date).

 

Are you using our reverse proxy config for nextcloud or did you make it/copy it from the web?

Link to comment
4 hours ago, H2O_King89 said:

Yes because unraid doesn't work well with wildcard cert.

I cat the certs and key to be able to use my certs for the unraid gui

Sent from my Pixel 4 XL using Tapatalk
 

You can't use a subdomain of the main domain in the extra domain. That is why you get that error.

  • Like 1
Link to comment

Good morning/afternoon.  

 

I am a bit out of my element with the reverse proxy stuff and custom conf files and need some help.

 

I am trying to run the CSMM-7DTD server manager (docker by ich77) via reverse proxy and https.  It works portionately via http, but uses steam to login to the software itself and that's where I get hung up.  I click my steam login and because its https it craps out.  I am unsure if this is supposed to be handled by the .conf file or elsewhere.  Anything to point me in the proper direction would be appreciated.  What I do have for a conf file comes from the creator of CSMM.  I am using DuckDNS docker and links, as well as a CNAME from my website. Thanks in advance for any and all help.  

 

server {

  server_name csmm.example.com;
  index index.html;

        location / {
            proxy_pass http://localhost:1337;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_cache_bypass $http_upgrade;
            proxy_read_timeout 300;
            proxy_connect_timeout 300;
        }

  listen 80;
}

 

Link to comment
Hello, I've got letsencrypt working, my domain links to the unraid server dashboard. I don't understand how i can now setup a sub domain for my ombi app. I want to use this subdomain to give to my friends so they can request movies using ombi. Please help me out with this ?
Don't point this to your unraid gui!

Sent from my Pixel 4 XL using Tapatalk

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.