Praxis-Lab: Security-Header

In diesem Lab konfigurierst du einen nginx-Webserver in Kali Linux mit den wichtigsten Security-Headern, überprüfst das Ergebnis mit cURL und verstehst anhand bewusster Fehlkonfigurationen, was schief gehen kann.

Nach diesem Lab kannst du:

• Den Ausgangs-Header-Output eines unkonfigurierten nginx-Servers analysieren
• Die fünf wichtigsten Security-Header in nginx konfigurieren: HSTS, CSP, X-Frame-Options, X-Content-Type-Options und Referrer-Policy
• Die gesetzten Header mit cURL verifizieren
• Unsichere CSP-Konfigurationen (wie unsafe-inline) erkennen und erklären
• Erläutern, warum HSTS nur über HTTPS sinnvoll ist

Voraussetzungen

Wir halten es hier bewusst einfach: Du benötigst lediglich deine Kali-VM und Internet-Zugriff für die Installation der notwendigen Pakete aus den Online-Repositories.

Schritt 1: nginx installieren und starten

Installiere nginx auf deiner Kali-VM, falls noch nicht vorhanden:

sudo apt update && sudo apt install nginx -y

Starte den Webserver:

sudo systemctl start nginx

Prüfe, ob nginx läuft:

systemctl status nginx

Du solltest Active: active (running) sehen:

Prüfe mit dem Befehl sudo ss -tlpn, ob nginx aktuell an Port 80 gebunden ist:

Öffne im Browser http://localhost und die Standardseite erscheint:

Wird – wie oben in der Abbildung zu sehen – die Apache2-Startseite angezeigt, ist das kein Fehler. Apache2 und nginx nutzen oft dasselbe DocumentRoot-Verzeichnis.

Schritt 2: Ausgangszustand analysieren

Bevor du irgendetwas konfigurierst, schaust du dir die aktuellen HTTP-Header an. curl -I sendet eine HEAD-Anfrage und zeigt nur die Header, ohne den Body.

curl -I http://localhost

Nachfolgend die typische Ausgabe eines unkonfigurierten nginx:

Derzeit existiert hier kein einziger Security-Header. Im Server-Header steht hier nur nginx – das ist gut, aber oft wird die genaue nginx-Version (z.B. 1.26.3) genannt – ein unnötiges Geschenk für Angreifer, die nach versionsspezifischen Schwachstellen suchen. Auch das sollten wir nachfolgend betrachten.

Aufgabe: Bevor wir loslegen – weißt du noch, welche Security-Header hier überhaupt fehlen? Notiere alle, die dir einfallen und führe dir ins Gedächtnis, was sie bedeuten.

Schritt 3: Security-Header konfigurieren

Unter Debian-Derivaten hat nginx eine sehr ähnliche Dateistruktur für die Konfiguration wie der Apache2. Die Hauptkonfigurationsdatei liegt unter /etc/nginx/ und heißt – wie sollte es anders sein – nginx.conf. Für die Bearbeitung der Konfiguration einzelner Sites nutzen wir jedoch die Dateien unter /etc/nginx/sites-available. Öffne die Default-Site mit dem Editor nano:

sudo nano /etc/nginx/sites-available/default

Füge innerhalb des server {}-Blocks die nachfolgenden Zeilen ein.

# Version-Disclosure entfernen
server_tokens off;

# Verhindert, dass die Seite in einem iframe eingebettet wird (Clickjacking-Schutz)
add_header X-Frame-Options "SAMEORIGIN" always;

# Verhindert MIME-Type-Sniffing durch den Browser
add_header X-Content-Type-Options "nosniff" always;

# HSTS: Browser muss für 1 Jahr ausschließlich HTTPS verwenden
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Steuert, welche Ressourcen geladen werden dürfen
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; frame-ancestors 'none';" always;

# Referrer-Informationen auf den Ursprung beschränken
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Speichere die Datei mit Strg+S. Beene den Editor mit Strg+X.

⚠️ Stopp: Was die Header genau bewirken, haben wir in den vorigen Abschnitten bereits thematisiert. Nutze die Gelegenheit, noch einmal alle Header abzugleichen und zu verstehen, wofür sie stehen.

💡 Tipp: Falls du nginx.conf bearbeitest, füge sie in den http {}-Block ein – dann gelten sie für alle virtuellen Hosts.

Schritt 4: Konfiguration prüfen und nginx neu laden

Prüfe die Syntax, bevor du nginx neu lädst:

sudo nginx -t

Erwartete Ausgabe sieht folgendermaßen aus:

Sollten Fehler auftauchen, hast du dich vermutlich irgendwo verschrieben. Schau dir die Konfigurationsdatei dann noch einmal genau an und vergleiche sie mit den Parametern oben.

Lade nginx neu (ohne Downtime):

sudo systemctl reload nginx

Schritt 5: Header verifizieren

Prüfe nun die Header erneut:

curl -I http://localhost

Die nachfolgende Abbildung zeigt die erwartete Ausgabe:

Wie du siehst, sind jetzt alle Security-Header integriert, so dass der Browser genaue Anweisungen hat, wie er sich zu verhalten hat.