Nginx quick reference(github.com)
github.com
Nginx quick reference
https://github.com/trimstray/nginx-quick-reference
21 comments
"and most of the hardening seems questionable at best." - Don't do this, please add rationale, not bullshit.
"Some of the headers that is suggested have some implications that aren't really explained at all. Like HSTS including sub-domains." - This repo also contain "Force all connections over TLS". However, I understand your attention.
"And you don't set the `default_server` as this document suggest. `default_server` is a parameter to the `listen`-directive. The only reason the docs might work is because the first server-block defined, when no-one is defined as `default_server`, becomes the default server." - You're right, your suggestion is very well (it's also from Nginx official handbook) and rationale, thanks for this! I receive this criticism, My mistake.
"Some of the headers that is suggested have some implications that aren't really explained at all. Like HSTS including sub-domains." - This repo also contain "Force all connections over TLS". However, I understand your attention.
"And you don't set the `default_server` as this document suggest. `default_server` is a parameter to the `listen`-directive. The only reason the docs might work is because the first server-block defined, when no-one is defined as `default_server`, becomes the default server." - You're right, your suggestion is very well (it's also from Nginx official handbook) and rationale, thanks for this! I receive this criticism, My mistake.
[deleted]
Don't casually enable HSTS with the following:
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains" always;
On a top domain site like https://example.com, if there are subdomain sites like http://golf.example.com which are not configured with TLS. The setting will be stored on the clients and they need to "forget" non-https sites after you have rolled back the misconfiguration. Of course you could go in the other direction and enable https for all subdomains. :)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains" always;
On a top domain site like https://example.com, if there are subdomain sites like http://golf.example.com which are not configured with TLS. The setting will be stored on the clients and they need to "forget" non-https sites after you have rolled back the misconfiguration. Of course you could go in the other direction and enable https for all subdomains. :)
"Disable compression (mitigation of CRIME attack)"
Is this really the best solution? This might get me an A+ at ssllabs but I also need an "A" from gtmetrics[1] and if I turn of gzip I will not get an A.
[1] https://gtmetrix.com/enable-gzip-compression.html
Is this really the best solution? This might get me an A+ at ssllabs but I also need an "A" from gtmetrics[1] and if I turn of gzip I will not get an A.
[1] https://gtmetrix.com/enable-gzip-compression.html
I was surprised to read that as well. I have gzip compression "turned on" in all of the nginx servers I administered. Didn't even know it could be an attack vector.
https://www.acunetix.com/vulnerabilities/web/crime-ssl-tls-a...
https://www.acunetix.com/vulnerabilities/web/crime-ssl-tls-a...
What's probably worth saying is that (at least for Apache), you can enable compression only for certain file types, such as static text files (HTML/CSS/JS) but not dynamic files (thinking of classical CGI scripting -- PHP/Python/Ruby). It should be possible to seperate this also for modern-world fcgi services.
How does HTTP2 and HTTP3 perform in this question? I always percieved deflate/gzip compression as something preferable. I never realized the CRIME attack before.
How does HTTP2 and HTTP3 perform in this question? I always percieved deflate/gzip compression as something preferable. I never realized the CRIME attack before.
My understanding is that the 'gzip' directive applies to HTTP compression, which is only performed on the body of the response (both in HTTP & HTTPS), and not SSL/TLS compression which compresses the headers and so is vulnerable to the CRIME attack.
SSL/TLS compression has been disabled in nginx since 1.3.2[1]
[1] http://mailman.nginx.org/pipermail/nginx-announce/2012/00008...
SSL/TLS compression has been disabled in nginx since 1.3.2[1]
[1] http://mailman.nginx.org/pipermail/nginx-announce/2012/00008...
For SSL Configuration there's always https://mozilla.github.io/server-side-tls/ssl-config-generat...
Off topic, it makes me wonder if a well designed IDE, a step by step wizard could save a lot of time from reading docs.
Web server Configuration should be simple if you already have the correct mindset. It's the nuances of each specific directive or variables that makes config hard. Try remember all those access_log formats. Ehh!
Web server Configuration should be simple if you already have the correct mindset. It's the nuances of each specific directive or variables that makes config hard. Try remember all those access_log formats. Ehh!
Like this? https://nginxconfig.io
+1, this is fantastic. Curious why the setting events { multi_accept on; } is flipped on from the default of off though. Is that a performance optimization?
Also, I added a PR to add thread_pool support (https://github.com/valentinxxx/nginxconfig.io/pull/66)
Also, I added a PR to add thread_pool support (https://github.com/valentinxxx/nginxconfig.io/pull/66)
Yes, exactly, but an IDE could cover more software like iptables, ffmpeg, ansible playbooks, etc.
Wow! That is awesome.
Thank you for this!
Not a Nginx administrator, but the general documentation flow is very much agreeable: actionable summary guideline, concise rationale, relevant example, external resource(s).
Awesome doc. Beware though lot of tradeoffs towards security in prejudice of performance and usability.
'quick reference'
1100 lines (707 sloc) 36.4 KB
1100 lines (707 sloc) 36.4 KB
For what it is, that's absolutely quick.
A printable lists of SSL ciphers... but why?? how could that be useful to anyone?!
And you don't set the `default_server` as this document suggest. `default_server` is a parameter to the `listen`-directive. The only reason the docs might work is because the first server-block defined, when no-one is defined as `default_server`, becomes the default server.
This will close the connection and log it internally, for any domain that isn't defined in Nginx.
Edit: Shout-out to #nginx on FreeNode, where you'll always find someone to point you i the right directing or help you out.