An nginx configuration for security(tautt.com)
tautt.com
An nginx configuration for security
http://tautt.com/best-nginx-configuration-for-security/
12 comments
They actually package both 1.4.x and 1.5.x:
http://nginx.org/en/linux_packages.html#stable
http://nginx.org/en/linux_packages.html#mainline
http://nginx.org/en/linux_packages.html#stable
http://nginx.org/en/linux_packages.html#mainline
Thanks for this. Does "mainline" mean "unstable/development"? I briefly looked around on nginx.org but couldn't find a description of the difference.
I agree that having a PPA isn't the best thing in the world, but this one is very stable(I'm using it for quite some time). Anyway, I will update the post to use the official repo, since it's really a better option. Thanks :)
Problem solved! I've updated the post to use the official repository(I've updated my step-by-step) :)
Thanks for the contribution
Thanks for the contribution
A couple points:
* !RC4 - RC4 is in doubt[1]. The only reason to keep it around was to mitigate the BEAST attack, which is now mitigated[2] client side, so RC4 should be dropped.
* gzip off; - Explicitly disable gzip compression to avoid BREACH[3]
* Ensure TLS deflate is off to mitigate CRIME[4] (this is the default in most, but not all combinations of nginx/OpenSSL).
* openssl ciphers -v is great for testing what ciphers match your settings.
* Comment your nginx config! You will not remember all of this when you next look at it (or someone else does). And some of it will certainly be outdated. Security is not a static game.
[1] http://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_b... [2] https://community.qualys.com/blogs/securitylabs/2013/09/10/i... [3] http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29 [4] http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29
* !RC4 - RC4 is in doubt[1]. The only reason to keep it around was to mitigate the BEAST attack, which is now mitigated[2] client side, so RC4 should be dropped.
* gzip off; - Explicitly disable gzip compression to avoid BREACH[3]
* Ensure TLS deflate is off to mitigate CRIME[4] (this is the default in most, but not all combinations of nginx/OpenSSL).
* openssl ciphers -v is great for testing what ciphers match your settings.
* Comment your nginx config! You will not remember all of this when you next look at it (or someone else does). And some of it will certainly be outdated. Security is not a static game.
[1] http://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_b... [2] https://community.qualys.com/blogs/securitylabs/2013/09/10/i... [3] http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29 [4] http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29
> * gzip off; - Explicitly disable gzip compression to avoid BREACH[3]
You don't have to disable gzip entirely. Just on any URLs where an attacker could influence the contents of the response. If you serve all your static assets out of their own location block, feel free to enable gzip there.
You don't have to disable gzip entirely. Just on any URLs where an attacker could influence the contents of the response. If you serve all your static assets out of their own location block, feel free to enable gzip there.
I followed your advice and added comments to almost all my configurations. I will add some test tools to allow easier test of the configurations, but I think it's a lot better now.
Besides that, I assume people will use nginx 1.3.7 or newer, so a few defaults are assumed as well.
Besides that, I assume people will use nginx 1.3.7 or newer, so a few defaults are assumed as well.
[deleted]
I guess it is a slow news day but there are better guides out there.
If you are using centos or any redhat related product you will have to build your own openssl to get 1.0.1 with perfect-forward-secrecy (the IUS repository does NOT include EC ciphers either). RedHat decided EC ciphers have patents that are valid (they are not).
The example configuration is missing ocsp stapling.
Their configuration is also including the root certificate in the download for every connection which is unnecessary.
Using RC4 over AES for beast mitigation is no longer considered optimal, if anything RC4 is not 100% trustworthy anymore. Lean on elliptic-curve ciphers with AES over RC4 for modern browsers. As a bonus you get CPU acceleration for AES on most servers and many newer home computers.
If you are using centos or any redhat related product you will have to build your own openssl to get 1.0.1 with perfect-forward-secrecy (the IUS repository does NOT include EC ciphers either). RedHat decided EC ciphers have patents that are valid (they are not).
The example configuration is missing ocsp stapling.
Their configuration is also including the root certificate in the download for every connection which is unnecessary.
Using RC4 over AES for beast mitigation is no longer considered optimal, if anything RC4 is not 100% trustworthy anymore. Lean on elliptic-curve ciphers with AES over RC4 for modern browsers. As a bonus you get CPU acceleration for AES on most servers and many newer home computers.
Thanks for the heads up ck2. I've updated the config to add ocsp stapling. The certificate really has a extra(unnecessary) root certificate, I will solve this later today.
The RC4 part is based on this article https://community.qualys.com/blogs/securitylabs/2013/08/05/c.... But I will do some more research and update the post.
The RC4 part is based on this article https://community.qualys.com/blogs/securitylabs/2013/08/05/c.... But I will do some more research and update the post.
Ivan has already adjusted his views on RC4 as you can read here:
https://community.qualys.com/blogs/securitylabs/2013/09/17/u...
And the qualys SSL analyzer no longer penalizes for not mitigating Beast, they just warn about it in orange but there is no longer a penalty as of a couple weeks ago.
https://community.qualys.com/blogs/securitylabs/2013/09/17/u...
And the qualys SSL analyzer no longer penalizes for not mitigating Beast, they just warn about it in orange but there is no longer a penalty as of a couple weeks ago.
Thanks again ck2. I will read it today and update the post to mitigate BEAST as well. Better then that, do you have a better setup for chipers?
The best thing I did with ciphers is stop just using everyone's "magic list" without understanding what they are and what they mean.
To start understanding the magic list of ciphers, enter the list into openssl like this and watch what it produces:
take away some of the adds/exclusions in the list and watch what they add/remove. Plug in other people's lists and see what they do.
Then learn what ECDHE vs DHE means (and why DHE is slower)
Then learn about RSA vs DSA keys, EC ciphers etc.
Then play around with this tool that shows you what ciphers different browser support (try it with IE8 vs Firefox vs Chrome, etc) https://cc.dcsec.uni-hannover.de/
Then read about AES hardware acceleration in openssl on most modern processors (not all but many). http://zombe.es/post/4078724716/openssl-cipher-selection
and eventually, a few days later, you'll start to understand what is best :-)
It is always much more than a few lines in a configuration file if you really want to understand.
To start understanding the magic list of ciphers, enter the list into openssl like this and watch what it produces:
openssl ciphers -V 'RC4'
openssl ciphers -V 'EECDH+aRSA+RC4 EECDH EDH+aRSA !aNULL !eNULL !LOW' take away some of the adds/exclusions in the list and watch what they add/remove. Plug in other people's lists and see what they do.
Then learn what ECDHE vs DHE means (and why DHE is slower)
Then learn about RSA vs DSA keys, EC ciphers etc.
Then play around with this tool that shows you what ciphers different browser support (try it with IE8 vs Firefox vs Chrome, etc) https://cc.dcsec.uni-hannover.de/
Then read about AES hardware acceleration in openssl on most modern processors (not all but many). http://zombe.es/post/4078724716/openssl-cipher-selection
and eventually, a few days later, you'll start to understand what is best :-)
It is always much more than a few lines in a configuration file if you really want to understand.
Why can't get the 'best config for security' be default out of the box on nginx and apache httpd? That's the only way we're actually going to have a secure web, ain't it?
There's been a lot of recent flux in what the consensus on "best config for security" even is in the past six months. We went through a phase where RC4 was the recommended cipher, now we're mostly coming around to it being a bad idea, for instance, and that's still a thing in progress rather than totally done.
Seems like someone should invent a way to easily get automatic updates to your ssl config in apache and/or nginx.
I know I'm not the only one with half a dozen, a dozen, or dozens of web servers I am responsible for -- who realistically isn't going to keep track of what the current consensus is and go updating the ssl configuration even every six months.
I know I'm not the only one with half a dozen, a dozen, or dozens of web servers I am responsible for -- who realistically isn't going to keep track of what the current consensus is and go updating the ssl configuration even every six months.
That would be Puppet, Chef, etc.
The following two headers are also useful:
The second prevents browsers from including this site in an iframe or frame, which helps prevent clickjacking attacks. If your site depends on those you can also set the option to SAMEORIGIN.
https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Option... https://developer.mozilla.org/en-US/docs/Security/HTTP_Stric... https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
add_header Strict-Transport-Security max-age=31536000;
add_header X-Frame-Options DENY;
The second prevents browsers from including this site in an iframe or frame, which helps prevent clickjacking attacks. If your site depends on those you can also set the option to SAMEORIGIN.
https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Option... https://developer.mozilla.org/en-US/docs/Security/HTTP_Stric... https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
I hope this isn't too off topic, but this has to e the very worst mobile theme I've seen for a site. Everything is blurry! And I can't zoom in, and there are weird overlays hanging around. I wish people would stop putting in effort to make their site harder to read. I couldn't even get through the first paragraph, because I kept on reaching for my glasses on the nightstand, when they are already on my face.
It is fairly straightforward to compile nginx against the latest ssl tarball, rather than the extreme option of distro upgrade (which as pointed out is no good for Centos / RHEL) for the cipher support.
Actually this is speaking to two different issues.
Nginx is indeed one of the easiest programs to compile, very light and fast to build.
Building the newest openssl from scratch for centos into an rpm is quite a workout. I had to read two guides and still had to play with it a bit to get everything just right. Oh and pro-tip from a big "duh" moment - don't try to remove old openssl on a SSH connection. It doesn't just run from memory, when it goes away, so does your connection to the server.
Nginx is indeed one of the easiest programs to compile, very light and fast to build.
Building the newest openssl from scratch for centos into an rpm is quite a workout. I had to read two guides and still had to play with it a bit to get everything just right. Oh and pro-tip from a big "duh" moment - don't try to remove old openssl on a SSH connection. It doesn't just run from memory, when it goes away, so does your connection to the server.
I really wish there was an openssl cookbook that upgraded openssl to 1.0.1 on centos. Seems like something someone can automate.
Link should be named "A Good Starting Config for Learning nginx Security"
If you don't know what each line of a config that is being spoon-fed to you off of some website is doing, you're doing it wrong. Research everything!
If you don't know what each line of a config that is being spoon-fed to you off of some website is doing, you're doing it wrong. Research everything!
I agree partially. To improve that, I will add comments in each line to explain why I'm doing that.
i believe "ssl on" is redundant. "listen 443 ssl" already does this.
You're right, thanks :)
http://wiki.nginx.org/HttpSslModule#ssl Note that since nginx version 0.7.14, the standard way to enable SSL is through the listen directive
http://wiki.nginx.org/HttpSslModule#ssl Note that since nginx version 0.7.14, the standard way to enable SSL is through the listen directive
> Internal Server Error
There is a good amount of irony here. The most secure system is a system that you can't access at all.
There is a good amount of irony here. The most secure system is a system that you can't access at all.
Anyway, the server that has that config isn't my blog, it's forgott.com :)
WP Super Cache for the rescue. Things running smoothly-ish right now :)
Just unplug the server.
Seriously though, any "best for security" article should be taken with a huge grain of salt as security isn't something static that's the same everywhere.
Seriously though, any "best for security" article should be taken with a huge grain of salt as security isn't something static that's the same everywhere.
I don't think this is a good idea. It's a bit unclear on their wiki[1] but they have an official repository maintained by nginx.org
(substitute your Ubuntu version for lucid, obviously)
and separately the PPA you're using but "this PPA is maintained by volunteers and is not distributed by nginx.org." How committed are those volunteers? Do you want to find out on your server?
The official repository carries nginx 1.4.2 (I use it with raring) which works with at least TLS 1.1 (that's what Chrome tells me about the connection).
EDIT: Qualsys gives my setup an A, with a pat on the back for supporting forward secrecy and a warning that I'm vulnerable to the BEAST attack. Apparently, I also support TLS 1.2, what do you know.
[1] http://wiki.nginx.org/Install#Official_Debian.2FUbuntu_packa...