Web Hardening on brege.org

Updated Nginx configuration with Let's Encrypt headers

Mon, 03 Apr 2017 15:06:38 -0700

I’ve added a new security_headers.conf file in /etc/nginx/ to keep all the HTTPS headers in one place:

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;


    # intermediate configuration. tweak to your needs.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;


    # to score better grades on
    #  https://observatory.mozilla.org/analyze.html?host=brege.org

    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload";
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header Content-Security-Policy "default-src 'self';";
    add_header Referrer-Policy "no-referrer, strict-origin-when-cross-origin";

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

We include the headers we obtained in the last post in here as well. The main configuration file /etc/nginx/brege.org contains:

server {
    server_name *.brege.org;
    return http://brege.org/;
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name  brege.org;
    # enforce https
    return 301 https://$host$request_uri;

    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    } # managed by Certbot

}

server {
    listen 443 default ssl;
    listen [::]:443 default ssl;

    root /usr/share/nginx/brege.org;
    index index.html index.htm index.php;

    server_name brege.org;

    ssl_certificate /etc/letsencrypt/live/brege.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/brege.org/privkey.pem; # managed by Certbot

    include security_headers.conf;
    include letsencrypt.conf;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }

    location ~ ^/(?:feed|feeds|rss)  {
        return 301 /index.xml;
    }

}

Note that first server block does not work as expected. On a separate instance, I tested this and confirmed that http://abc.mysite.org does get redirected to https://mysite.org, but I think that since my site has been HSTS Preloaded, this doesn’t allow http://abc.brege.org to redirect to https://brege.org.

Getting an A+ on Mozilla's HTTP Observatory

Mon, 09 Jan 2017 18:29:50 -0500

After I learned about Mozilla’s tool to test how secure your site is, I ran it on my site https://observatory.mozilla.org/analyze.html?host=brege.org and received an “F”.

After some trial & error and searching around, I came up with the following to be placed in my Nginx server{...} block:

    add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload";
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header Content-Security-Policy "default-src 'self';";

Now I am receiving an “A+” from the observatory!

I also went to Google’s submission page to have your site put on the HSTS preloaded list, so that all users of Google Chrome access your site through HTTPS by default.

Automatic renewal of Let's Encrypt Certificates

Tue, 11 Oct 2016 00:15:22 +0000

Let’s Encrypt certificates need to be renewed every three months. The Arch Wiki has good documentation on automating the renewal process with systemd.

In /etc/systemd/system/certbot.service:

[Unit]
Description=Let's Encrypt renewal

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet --agree-tos

In /etc/systemd/system/certbot.timer:

[Unit]
Description=Daily renewal of Let's Encrypt's certificates

[Timer]
OnCalendar=daily
RandomizedDelaySec=1day
Persistent=true

[Install]
WantedBy=timers.target

Enable and start the timer:

sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer