Skip to content

Instantly share code, notes, and snippets.

@DeadAlready
Created March 28, 2016 06:43
Show Gist options
  • Save DeadAlready/78f5a790812f8d0ec7ab to your computer and use it in GitHub Desktop.
Save DeadAlready/78f5a790812f8d0ec7ab to your computer and use it in GitHub Desktop.
Nginx secure configuration
# Remove server identifiers to help against enumeration
server_tokens off;
# Add some protection headers for ClickJacking
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
# Redirect to https
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
# Redirect to https and remove www
server {
listen 80;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
server {
# Listen for HTTPS connections using http2;
listen 443 ssl http2;
server_name example.com;
# Define where to find the certificates
# These will be under the letsencrypt folder
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Cache SSL handshakes
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 5m;
# Use our new Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_prefer_server_ciphers on;
# disable SSLv3(enabled by default since nginx 0.8.19) since it's less secure then TLS http://en.wikipedia.org/wiki/Secure_Sockets_Layer#SSL_3.0
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ciphers chosen for forward secrecy and compatibility
# http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
# Define our root folder
root /var/appdata/fooapp/;
# Use gzip to save on bandwith
gzip on;
gzip_comp_level 7;
gzip_types text/plain text/css text/javascript application/javascript;
gzip_proxied any;
# Tell the browser to force HTTPS
add_header Strict-Transport-Security "max-age=31536000;";
# Optimise internal TCP connections
tcp_nopush on;
tcp_nodelay on;
# Add static file serving from /var/appdata/fooapp/public folder
location /public {
sendfile on;
include /etc/nginx/mime.types;
charset utf-8;
expires 30d;
}
# Proxy all other requests to our Node.js application
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://0.0.0.0:2765;
proxy_redirect off;
}
}
@uahengojr
Copy link

I have a question regarding how you've set up the redirects to https:

#Redirect to https
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

#Redirect to https and remove www
server {
    listen 80;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

The same outcome be achieved by the following, right?

server{
     listen 80;
     server_name  example.com www.example.com;
     return 301 https://$host$request_uri;
}`

I get that one is much more cleaner/transparent, and probably more maintainable, however I'd just like to clarify whether there is a distinction as pertaining to security. Thanks in advance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment