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;

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

Diese Weiterleitung kann in NGINX sehr leicht erreicht werden. Es genügt folgenden Einzeiler in die Konfiguration aufzunehmen:

error_page 497 https://$host$request_uri;

Nun muss der Angreifer dem WordPress Blog einen Pingback von der Seite des Opfers vorgaukeln, das WordPress wird daraufhin den Pingback überprüfen und die Seite des Opfers aufrufen. Macht der Angreifer das mit zahlreichen WordPress Blogs gleichzeitig, kann die Traffic Flut die Seite des Opfers lahm legen.

Eine meiner Seiten wurde durch genau so einen Angriff bombardiert, es ist jedoch ziemlich leicht dagegen vorzugehen. Ich habe in meinem nginx **server block** einfach alle Aufrufe desen UserAgent „WordPress“ enthält geblockt:

# WordPress Pingback 
if ($http_user_agent ~* "WordPress") {
   return 403;
}

Danach nginx neustarten und das Snippet schützt euch davor dass der Angreifer eueren Server lahm legen kann. (Genauer gesagt kann nginx noch immer angegriffen werden, aber nginx blockt die Aufrufe nun sehr performant, anstatt die Aufrufe durchzulassen und an evtl. Gateways wie PHP oder nodejs weiter zu reichen).