Best Practices When Using Docker & DDNS - from MariusHosting

[Gerard]

MariusHosting recently posted an article titled "Synology: Best Practices When Using Docker & DDNS." Most of the options proposed in this article are not on in my environment since they were never turned on by default.

Asking here to see who has all of, some of, or none of these options enabled? (Mainly the first 5, as 6 is case by case and 7 should be everyone).

1. HTTP2 enabled?
2. HTTP Compression enabled?
3. HSTS enabled?
4. Reuseport enabled?
5. Prevent Search Engines from Indexing your DDNS enabled?
6. (Access Control Profiles) Is more of a case by case use base, as opposed to the aforementioned across the board use case.
7. Synology Firewall - Everyone should have this on to some extent.

Article Source: MariusHosting - Synology: Best Practices When Using Docker & DDNS

 

[one-eyed-king]

Did you notice that except 3 and 6 everything else is not realy docker related. #3 and #6 could be considered associated with docker specific, if the reverse proxy is used as entrypoint to the container. But honestly the recommendations end in the reverse proxy and non of those things are realy docker related.

One would need to check the generaly nginx configuration to understand whether #1, #2, #4 and #5 even apply to reverse proxy rules.

Generaly, I find the title to be very missleading, as at most it's a general Synology reverse proxy configuration (if the points from above realy apply to it). This has nothing to do with docker at all.

 

[Gerard]

Correct It did appear this was more along the lines for reverse proxy rather than specifically docker. I do have #3 HSTS on for all the RP entries. I’ve never seen #5 happen as well (ddns is indexed by search engines). My current value there is ngix.

 

[one-eyed-king]

Honestly, I never bothered about #5, as non of my public reachabe services is without password protection, most of them even are protected by keycloak.

If I can find time the next days, I will check how the whole nginx.conf is merged to see whether #1, #2, #4 and #5 are actualy with broader scope and are even inherited by the RP-Rules.

I feel an important topic was missing: how to vertify the security ranking -> SSL Server Test (Powered by Qualys SSL Labs)

 

[Gerard]

I feel an important topic was missing: how to vertify the security ranking -> SSL Server Test (Powered by Qualys SSL Labs)

This is awesome. Will have check this out, it’s always good to check every once in a while to ensure there are no lapses in security.

 

[SynoMan]

Notice

Some posts in this thread have gone off topic and some forum rules have been violated. We deleted some posts and please, stick to the thread topic and respect forum rules.

Thank you.

 

[Gerard]

If I can find time the next days, I will check how the whole nginx.conf is merged to see whether #1, #2, #4 and #5 are actualy with broader scope and are even inherited by the RP-Rules.

Hi @one-eyed-king , i just wanted to follow up if and when you eventually can find the time regarding this. I’d be very interested in your findings since I use RP. Thanks again hope all is well

 

[one-eyed-king]

Thanks for the reminder. It might take some time, as I am on sick leave this week.

 

[Gerard]

Thanks for the reminder. It might take some time, as I am on sick leave this week.

No worries take your time. Im good with this technical stuff, but this is beyond my expertise. Much appreciated!

 

[one-eyed-king]

So here we go:

#2 (HTTP compression) is not applied for reverse proxy rules. Enabling the setting affects the dms https port (defaults to 5001) and the Website https port (defaults to 443). Regardless of the setting, it is always enabled for dsm http port (defaults to 5000) and website http (defaults to 80).

#1 (HTTP2) and #4 (Resuable port) the scope seems to be for the whole server, but as it declares both settings using the directive default_listen_option, I can't realy tell, as I didn't find this directive in the nginx documentation.

used in the http block (which is the most outer block, every other service is hooked in as server block):

default_listen_option tcp_reuseport ssl_http2;

Note: as a side affect of http2, it might happen that file upload dialogs will stop working for files largen than 8mb. Again a directive is used http2_max_client_body_buffer_size which can not be found in the nginx documentation.

#5 (Prevent indexing) the scope seems to be for the whole server, but as this is an undocumented nginx directive, I have no idea what it does and wether it actualy work.

They use this undocumented nginx directive in the main http block: server_tag "noindex";

Normaly this is done by this directive inside a location block:

    add_header X-Robots-Tag "noindex, nofollow" always;

Long story short: compression does not apply to to reverse proxy rules, the other settings may apply to everything the nginx serves, but it's impossible to tell because they use directive, which according the documentation, seem not to exist...

Now it#s time to spin up a demo container and use the browsers developer tools to check if the traffic shows signs of the additionaly expected headers. #1 and #5 should be easy to spot.
Nope, the browser's developer tools didn't help here for #1 or #4.

Update1:
#5 adds the header "Server" witht the value "noindex". I can not find any evidence it prevents indexer from crawling the page.

Update2:
#1 can be self tested using HTTP/2 Test - Verify HTTP/2 Support | KeyCDN Tools. As I am currently not running any internet exposed containers on the Syno, I leave this one for someone else to verify.

 

[Telos]

"Best Practices" ??? Based on remarks here... could this be a clickbait attempt?

... and there is this ... eight years ago

 

[Gerard]

@one-eyed-king Thank you again for running this thru its paces. So in your opinion one shouldn't have any concern that most of these options are at their default (I think) value of being off?

At the very least is Http/2 beneficial? I know you mentioned "not running any internet exposed containers" does this only apply to containers? I have a unifi & vaultwarden container which is accessible thru the internet. Additionally, I have some synology services that are internet facing such as dsm, photos, audio station, etc. Would it apply to this too or just containers?

 

[one-eyed-king]

Those options make sense (if they really apply), except #2 (compression) and #5 (no index) as they simply don't apply to reverse proxy rules. #1 (HTTP/2) and #3 (HSTS) indeed harden the security.

My remark regarding was not meant as "do not expose containers to the internet", I simply don't run any container exposed to the internet on the NAS. Of course, I have containers exposed to the internet, but they are running in a Swarm Cluster (I always postpone the migration to Kubernetes).

When it comes to accessing the DSM interface, I would strongly suggest to not expose it to the internet, but instead make it only accessible from local LAN or through a VPN connection.

I have no feelings about Photos and Audio Station as I don't use them - but I doubt they make any sense without being exposed to the internet I generally don't like the idea that a service running directly on the NAS is exposed to the internet.

Generally you should be fine with a hardened TLS setup, provided by the reverse proxy or the target application itself. Though, never, never ever expose services with just HTTP to the internet.

 

[Gerard]

Update2:
#1 can be self tested using HTTP/2 Test - Verify HTTP/2 Support | KeyCDN Tools. As I am currently not running any internet exposed containers on the Syno, I leave this one for someone else to verify.

I have HTTP/2 turned on, however the test site is saying HTTP/2 protocol is not supported and ALPN extension not supported. Is there something else that needs to be setup to take advantage of this?

 

[one-eyed-king]

I have no idea, as the nginx.conf uses directives that are undocumented (=high likely a custom implementation of Synology). I have no idea whether they work or not. I can only assume and hope they do I would have assumed that enabling the HTTP/2 checkbox should do the trick. Afaik, the only security aspect of HTTP/2 is that it enforces TLS, the main benefit is its efficiency.

Honestly, I would ditch the built-in reverse proxy and use the Nginx Proxy Manager instead to get full control. @Rusty made a nice blog post about it: NGINX proxy manager

Note: personally I use Traefik as reverse proxy on a 3 node cluster. It's more suited towards advanced users, as it provides no UI. I configure my proxy rules using only service labels on containers in my compose files.