An nginx configuration for security

<p><pre><code> &gt; add-apt-repository ppa:nginx&#x2F;stable </code></pre> I don&#x27;t think this is a good idea. It&#x27;s a bit unclear on their wiki[1] but they have an official repository maintained by nginx.org<p><pre><code> deb http:&#x2F;&#x2F;nginx.org&#x2F;packages&#x2F;ubuntu&#x2F; lucid nginx deb-src http:&#x2F;&#x2F;nginx.org&#x2F;packages&#x2F;ubuntu&#x2F; lucid nginx </code></pre> (substitute your Ubuntu version for lucid, obviously)<p><i>and separately</i> the PPA you&#x27;re using but &quot;this PPA is maintained by volunteers and is not distributed by nginx.org.&quot; How committed are those volunteers? Do you want to find out on your server?<p>The official repository carries nginx 1.4.2 (I use it with raring) which works with at least TLS 1.1 (that&#x27;s what Chrome tells me about the connection).<p>EDIT: Qualsys gives my setup an A, with a pat on the back for supporting forward secrecy and a warning that I&#x27;m vulnerable to the BEAST attack. Apparently, I also support TLS 1.2, what do you know.<p>[1] <a href="http://wiki.nginx.org/Install#Official_Debian.2FUbuntu_packages" rel="nofollow">http:&#x2F;&#x2F;wiki.nginx.org&#x2F;Install#Official_Debian.2FUbuntu_packa...</a>

A couple points:<p>* !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.<p>* gzip off; - Explicitly disable gzip compression to avoid BREACH[3]<p>* Ensure TLS deflate is off to mitigate CRIME[4] (this is the default in most, but not all combinations of nginx&#x2F;OpenSSL).<p>* openssl ciphers -v is great for testing what ciphers match your settings.<p>* 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.<p>[1] <a href="http://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullrun_analysis/" rel="nofollow">http:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2013&#x2F;09&#x2F;06&#x2F;nsa_cryptobreaking_b...</a> [2] <a href="https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat" rel="nofollow">https:&#x2F;&#x2F;community.qualys.com&#x2F;blogs&#x2F;securitylabs&#x2F;2013&#x2F;09&#x2F;10&#x2F;i...</a> [3] <a href="http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;BREACH_%28security_exploit%29</a> [4] <a href="http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;CRIME_%28security_exploit%29</a>

I guess it is a slow news day but there are better guides out there.<p>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).<p>The example configuration is missing ocsp stapling.<p>Their configuration is also including the root certificate in the download for every connection which is unnecessary.<p>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.

Why can&#x27;t get the &#x27;best config for security&#x27; be default out of the box on nginx and apache httpd? That&#x27;s the only way we&#x27;re actually going to have a secure web, ain&#x27;t it?

The following two headers are also useful:<p><pre><code> add_header Strict-Transport-Security max-age=31536000; add_header X-Frame-Options DENY; </code></pre> The first one tells browsers it should never try to visit the http version of this site, even if the user clicks on a http link the browser will visit the https version. This helps prevent ssl stripping attacks.<p>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.<p><a href="https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;HTTP&#x2F;X-Frame-Option...</a> <a href="https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Security&#x2F;HTTP_Stric...</a> <a href="https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;SSL_stripping#SSL_stripping</a>

I hope this isn&#x27;t too off topic, but this has to e the very worst mobile theme I&#x27;ve seen for a site. Everything is blurry! And I can&#x27;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&#x27;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 &#x2F; RHEL) for the cipher support.

This might be a good place to ask; is there a good way to get fail2ban and nginx to work nicely together? I keep getting shitbirds pecking away at &#x2F;wpadmin on my website.

Link should be named &quot;A Good Starting Config for Learning nginx Security&quot;<p>If you don&#x27;t know what each line of a config that is being spoon-fed to you off of some website is doing, you&#x27;re doing it wrong. Research everything!

i believe &quot;ssl on&quot; is redundant. &quot;listen 443 ssl&quot; already does this.

&gt; Internal Server Error<p>There is a good amount of irony here. The most secure system is a system that you can&#x27;t access at all.

Just unplug the server.<p>Seriously though, any &quot;best for security&quot; article should be taken with a huge grain of salt as security isn&#x27;t something static that&#x27;s the same everywhere.