Optimiser Nginx

http {

   limit_req_zone $binary_remote_addr zone=login:10m rate=10r/s;

   server {

      limit_req zone=login burst=15;
   }
}

Ci dessus, la 1er directive indique la taille de 10Mo le cache nommé “login” dont celui-ci acceptera de traité 10 requêtes à la seconde. La seconde directive autorise le traitement d'un maximum 15 requêtes pour la zone “login” et en cas de dépassement, une erreur 503 sera déclaré.

source : http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

nano /etc/nginx/nginx.conf

On enlève le dièse devant ces commentaires :

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Le serveur indique aux navigateur que les prochaines requêtes devront être faites directement en HTTPS. Attention, une fois ce paramètre déclaré, il devra pour toujours être présent!

add_header Strict-Transport-Security "max-age=15552000; preload";

Le Online Certificate Status Protocol utile pour les sites en HTTPS, a pour objectif que le serveur indique aux navigateurs de vérifier si le certificat est toujours valide au près d'une autorité de certification. Cela impacte un peu les performances lors de la 1ère requête mais une fois la vérification faite, les prochaines seront plus rapide.

ssl_trusted_certificate  /etc/letsencrypt/live/domaine.com/chain.pem;
ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.0.1 80.67.169.12 valid=300s;
resolver_timeout 5s;

On pourra ensuite vérifier que ça fonctionne bien après une bonne demie-heure :

while true; do sleep 15 ; echo QUIT |openssl s_client -connect domaine.com:443 -tls1_2 -tlsextdebug -status | grep "OCSP Response Status: successful"; done

Permet d'améliorer la sécurité des sites web en permettant de détecter et mitiger certains types d'attaques, dont les Cross Site Scripting (XSS) et les injections de contenu

add_header Content-Security-Policy upgrade-insecure-requests;

Ainsi, on récupère uniquement les éléments d'une page accessible en HTTPS.

Permet d'éviter les attaques de type Man In The Middle. Ceci est fonctionnel avec Let's Encrypt. C'est une technologie très peu utilisé et utilisé uniquement par Firefox. Il sera voué à disparaître pour être remplacé par expect-ct.

Voici les Hash que nous avons besoin (il nous en faut deux au minimum). L'obtension de ces Hash doit correspondre avec les certificats que vous utilisez (ceux présent dans la chaine de certificats).

openssl rsa -in /etc/letsencrypt/live/domaine.com/chain.pem -outform der -pubout | openssl dgst -sha256 -binary| openssl enc -base64
curl https://letsencrypt.org/certs/lets-encrypt-x4-cross-signed.pem | openssl x509 -pubkey | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64
curl https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem | openssl x509 -pubkey | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64
curl https://letsencrypt.org/certs/isrgrootx1.pem | openssl x509 -pubkey | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

Un fois obtenu, on peut les rajouter dans le header suivant :

add_header Public-Key-Pins 'pin-sha256="Hash1"; pin-sha256="Hash2"; pin-sha256="Hash3"; pin-sha256="Hash4"; max-age=5184000;';

Ce Header sera valide durant 2 mois.

On peut vérifier que la configuration est correcte ici : https://report-uri.com/home/pkp_analyse

Ressource :

• https://lilleengen.io/blog/index.php/posts/activating-http-public-key-pinning-hpkp-on-lets-encrypt
• https://www.bjornjohansen.no/public-key-pinning
• https://scotthelme.co.uk/a-new-security-header-expect-ct/
• https://scotthelme.co.uk/the-death-knell-for-hpkp/