Securing SWAG

Securing-SWAG.md

Moved to https://virtualize.link/secure/

• fail2ban section - i think this needs much more expansion; we need to discuss HOW that filter came to be, how do we test the filter, etc. this is usually something like taking the log with failed attempts, created a regex to parse it, and then using fail2ban-regex to test. From a user perspective, this is a blackmagic filter and they won't know how to expand this.

• for exposing the log into swag, there are some concerns with using the file directly as opposed to a log directory; bitwarden is a good example as you can specify a log folder and then map that folder.

• hsts section - this is missing some steps which is why we normally don't suggest hsts. 1) it makes tshooting difficult and 2) enabling that line isn't the only step, you also need to preload your hsts (note: https://hstspreload.org/) I think we should also mention that this makes support rather difficult and should only be used with a stable environment and working setup.

• internal applications, this setup will lead to cert errors, it would be much better to explain split dns and simply use the same domain inside as outside in this setup which will ensure the certs are trusted.

formerly known as letsencrypt

Should probably say

formerly known as linuxserver/letsencrypt

note from ixnyne: you do NOT have to preload for HSTS to work, however it's a good idea. without preload a visitor won't know prior to visiting your server that HSTS is enabled (and what the expiration is). preload would allow certain browsers (chrome/chromium based/firefox/safari) to know before even making a request to your server that hsts is enabled, and therefore never allow the possibility of an http request. users can enable HSTS by uncommenting the line in swag config and not do anything else. if they want preload they have to go to https://hstspreload.org/ and add their domain to the site.

why is HSTS not enabled by default in swag? because once it's on you can't turn it off. you have to let it expire. it's our recommendation that you first get swag running with a working cert and verify you are able to visit your site via https. once you are confident that you would not have a reason to use http and that you have a working setup then you can enable HSTS and optionally add yourself to the preload list.

iXNyNe: also i agree on the split dns topic. there's a lot of ways to do this, but if you own an actual domain and want to have a few things accessible via that domain locally but not publicly you can accomplish that. one common way is to point that domain (or a subdomain) to an ip like 0.0.0.0 with your registrar, and use dns validation to obtain a cert, and setup your LAN DNS to point that domain to your SWAG host.
iXNyNe: ex: local.linuxserver.io with an A record to 0.0.0.0 or 127.0.0.1 at the registrar and then local DNS to point it to 192.168.1.5 or whatever
iXNyNe: technically you can make the A record point to 192.168.1.5 and it'll work without any local DNS effort

I have done the following changes:

• Rewrote the Internal Applications section according to the discord discussion
• Expanded the Fail2Ban section according to driz's notes
• Expanded the HSTS section according to iXNyNe's notes
• Reordered the sections
• Changed letsencrypt to linuxserver/letsencrypt

then create a file called nextcloud.conf under fail2ban/filter.d:

User made fail2ban filters/actions should use .local instead of .conf
Something something fail2ban might overwrite them on an update ect.

Also. Great job!

Thanks!
More changes:

• Changed conf to local based on gilbN's comment
• Changed internal applications and phrasing based on driz's comments on discord
• Changed formatting and phrasing

You said "uncomment" the X-Robots-Tag, but it's not there or not there anymore.
Do the LinuxServer guys removed it?
I know I can just add it but I still want to know if there's a reason that they may have removed it.
Thanks for this guide, very much appreciated!

You said "uncomment" the X-Robots-Tag, but it's not there or not there anymore.
Do the LinuxServer guys removed it?
I know I can just add it but I still want to know if there's a reason that they may have removed it.
Thanks for this guide, very much appreciated!

I actually don't think it was ever in the config (it's not in the repo history). You can simply add it to the ssl.conf file though.

You said "uncomment" the X-Robots-Tag, but it's not there or not there anymore.
Do the LinuxServer guys removed it?
I know I can just add it but I still want to know if there's a reason that they may have removed it.
Thanks for this guide, very much appreciated!

I guess it was removed, or it was never there! :)
Though you can still find it in the Readme if you search "X-Robots-Tag".

If I use: curl -I https://example.com

It displays all my header info.
I am new to this, but is there any way to hide/reduce that info?

@GilbN fail2ban is now included with SWAG. Here are their default filters.

Do you have any generic suggestions for NGINX publicly hosted sites for the nginx-deny.conf filter?

Thanks for this great gist @quietsy. I see you also used cloudflare for dns. I'm trying to use swag + cloudflare but with cloudflare's proxy on; actually what I want is to hide my server's IP. Is there any possiblity to do this? I have swag setup with cloudflare, but If I ping my dockers' url I get my server IP :/; want to have this hidden by cloudflare

just turn cf proxy on; you may need our cloudflare-real-ip swag mod, but generally it just works. If you need support from us though, turn it off before asking. We dont support it being on (though it works fine)

@drizuid thanks for the guide. I turned it on, but it doesn't hide my server's IP. I ping my docker image's domain and I get my server's IP.

UPDATE:
I tested your mod. But didn't understand what it does, precisely (for my case).

I think i'm getting close to some clues. Found this on cloudflare's website:

Yes. Cloudflare supports the wildcard '*' record for DNS management in all customer plans.
Free, Pro, and Business plans
Non-enterprise customers can create but not proxy wildcard records.

I had used wildcard CNAME record. that's why my subdomain was getting exposed.

Now, idealistically I want something to overcome this issue, cause I have more than handful of sudbomains, but otherwise it's still possible to hide my server's IP by adding A records in CF manually.

That was a good read, @quietsy. I'm using lscr.io/linuxserver/swag and I want to do geo blocking, but there is no geoip2.conf and no mention of it in nginx.conf? Should I look for another image?

Hey @agingorange , please use the updated guide at https://virtualize.link/secure/

@quietsy Fantastic. Thanks much!