Bevor ihr diese Zeilen in eueren server Teil euerer nginx Konfiguration ergänzt, stellt sicher bereits ein SSL Zertifikat zu haben und den Pfad dorthin anzupassen. Darüber hinaus solltet ihr auch einen Diffie-Hellmann Key erzeugen und den Pfad dorthin ebenfalls anzupassen.

Einen Diffie-Hellmann Key wird mit folgendem Befehl erzeugt (kann sehr lange dauern):
> cd /etc/ssl/private

> openssl dhparam -out dhparams.pem 2048

> chmod 600 dhparams.pem

Habt ihr nun ein SSL Zertifikat und einen eigene DH Key, so stellt nochmals sicher die Pfade in folgendem Snippet anzupassen – dann könnt ihr es in euerer nginx Server Directive einsetzen:

listen 443 ssl http2;
ssl    on;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
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:!CAMELLIA:!DES:!MD5:!PSK:!RC4';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate    /etc/letsencrypt/live/hilfreiche-server.tips/fullchain.pem;
ssl_certificate_key    /etc/letsencrypt/live/hilfreiche-server.tips/privkey.pem;

Das ganze ist eigentlich recht einfach. Wir benötigen den Quellcode unserer gerade installierten nginx Version, sowie den Quellcode des gewünschten Moduls. Dann bauen wir beides zusammen, nehmen aber nur das erstelle Modul und binden es in die vorhandene nginx Installation ein. Wie so immer müssen wir jedoch auf das ein oder andere Detail achten.

Wir brauchen den Quellcode der nginx Version die wir bereits installiert haben. Diese bekomen wir mit folgendem Befehl:

nginx -v

Das Ergbnis sieht so aus:

Jetzt wissen wir also dass wir aktuell Version 1.15.8 installiert haben und können uns davon den Quellcode herunterladen:

wget http://nginx.org/download/nginx-1.15.8.tar.gz 
tar -xzvf nginx-1.15.8.tar.gz

Nun benötigen wir den Quellcode des gewünschten Moduls. Als Beispiel nehme ich hier das NAXSI Modul:

git clone https://github.com/nbs-system/naxsi.git

Jetzt wechseln wir in den nginx Ordner

cd nginx-1.15.8

Bevor wir nun aber nginx und das Modul bauen können, benötigen wir noch die Build Flags des bereits installierten nginx, sonst bekommen wir später folgende Meldung:

dynamic module is not binary compatible with nginx

Um die Flags festzustellen nutzen wir den Befehl

nginx -V

Was uns die gesuchten Flags anzeigt

Der nun zu verwendente Buildbefehl sieht so aus und muss durch die gerade festgestellten Flags erweitert werden:

./configure --with-compat --add-dynamic-module=../naxsi/naxsi_src

Was dann bei mir so aussieht:

./configure --with-compat --add-dynamic-module=../naxsi/naxsi_src  

--prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.15.8/debian/debuild-base/nginx-1.15.8=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'

Nachdem der Befehl erfolgreich abgeschlossen wurde, erstellen wir noch die Module mit

make modules

Nun ist das Modul bereit zu Verwendung. Dazu kopieren wir es in den nginx modules Ordner

cp objs/ngx_http_naxsi_module.so /etc/nginx/modules

Und aktivieren es in der nginx.conf

load_module modules/ngx_http_naxsi_module.so;

Das war es auch schon. Nginx abschließend neustarten und das Modul wird geladen.

Google sind jedoch auch niedrige Ladezeiten wichtig, leider ist es jedoch so das eine HTTPS Verbindung per se mehr Rechenleistung benötigt um die Verbindung zum Browser zu verschlüsseln. Besonders aufgefallen ist mir der langsame SSL Handshake. Also der Abschnitt des Verbindungsaufbaus in dem sich Server und Browser auf eine Technologie einigen. Das lag an den zahlreichen unterstützen SSL Algorithmen. Manchmal ist halt doch weniger mehr.

Daher bietet mein nginx Webserver nun nur noch die SSL Algorithmen an die von Cloudflare empfohlen werden und somit konnte ich auch die Ladezeiten wieder verbessern:

ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers                 EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers   on;

• Der „X-XSS-Protection“-HTTP-Header ist nicht so konfiguriert, dass er „1; mode=block“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
• Der „X-Content-Type-Options“-HTTP-Header ist nicht so konfiguriert, dass er „nosniff“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
• Der „X-Robots-Tag“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
• Der „X-Frame-Options“-HTTP-Header ist nicht so konfiguriert, dass er „SAMEORIGIN“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
• Der „X-Download-Options“-HTTP-Header ist nicht so konfiguriert, dass er „noopen“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
• Der „X-Permitted-Cross-Domain-Policies“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.

Beheben lässt sich das sehr leicht. Verwendet man nginx muss man lediglich in die nginx v-host Konfiguration ein paar Zeilen ergänzen. Die Datei findet man im Normalfall unter /etc/nginx/sites-enabled/default

Hinzugefügt werden muss innerhalb des Serverblocks folgendes

add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options "noopen";
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy no-referrer;

Abschließend den Server neustarten

/etc/init.d/nginx restart