AlexBa16/htl-reverse-proxy-tls-lab
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
92a833ec50a68931dc494b02c46b266e3bac7a48
htl-reverse-proxy-tls-lab/challenges/README.md
T

8.6 KiB
Raw Blame History

Workshop Challenges (Reverse Proxy + TLS Focus)

Diese Aufgaben sind bewusst auf manuelle Proxy-Konfiguration ausgelegt.

Abgabe-Format pro Challenge

  • 1-3 Minuten Demo
  • Done-Check Command live ausfuehren
  • 2-3 Saetze erklaeren: was geaendert, warum, welche Wirkung

Arbeitsmodus

  1. Dateien anpassen (proxy/nginx.conf, docker-compose.yml).
  2. Deployen mit make redeploy oder make proxy-reload.
  3. Testen mit curl / openssl / Wireshark.
  4. Bei Problemen: ./scripts/compose.sh logs reverse-proxy.

Easy

1) Routing verstehen (aktiv)

Ziel

  • Verstehen, wie Nginx Requests per Pfad an unterschiedliche Upstreams schickt.

Muss

  • Vor dem Test in proxy/nginx.conf nachsehen, welche location auf welchen upstream zeigt.
  • Dann erst Requests ausfuehren.
  • In eigenen Worten erklaeren, warum die Antworten unterschiedlich sind.

Warum wichtig

  • Das ist die Kernkompetenz bei Reverse Proxys: Request-Fluss lesen und korrekt begruenden.

Done-Check

curl http://localhost:8080/service/a
curl http://localhost:8080/service/b

2) Drittes Backend manuell hinzufuegen

Ziel

  • Setup sicher erweitern, ohne bestehende Routen kaputt zu machen.

Dateien

  • docker-compose.yml
  • proxy/nginx.conf
  • backends/c/index.html (vorhanden, darf angepasst werden)

Muss

  • Service backend-c in Compose einbauen.
  • Upstream + Route /service/c in Nginx anlegen.
  • A/B muessen weiterhin funktionieren.

Warum wichtig

  • In realen Umgebungen kommen neue Services laufend dazu. Saubere Erweiterung ohne Regression ist entscheidend.

Done-Check

curl http://localhost:8080/service/c
curl http://localhost:8080/service/a
curl http://localhost:8080/service/b

3) Eigene Route mit Rewrite oder Alias-Route

Ziel

  • URL-Design vom Backend-Pfad entkoppeln.

Datei

  • proxy/nginx.conf

Muss

  • Route /demo/a anbieten, die auf Backend A fuehrt.
  • Entweder per rewrite oder per eigener proxy-Route loesen.

Warum wichtig

  • Der Proxy entkoppelt externe API-Pfade von internen Service-Pfaden und ermoeglicht saubere Migrationen.

Done-Check

curl http://localhost:8080/demo/a

Medium

4) Security Headers setzen

Ziel

  • Browserseitige Basishaertung aktivieren.

Datei

  • proxy/nginx.conf

Muss

  • Mindestens setzen:
    • X-Content-Type-Options: nosniff
    • X-Frame-Options: DENY
    • Referrer-Policy: strict-origin-when-cross-origin
    • Permissions-Policy: camera=(), microphone=(), geolocation=()
    • Cross-Origin-Opener-Policy: same-origin
    • Cross-Origin-Resource-Policy: same-origin
  • Optional (Bonus): Content-Security-Policy fuer statische Seiten (mit Inline-Styles bewusst beruecksichtigen)

Warum wichtig

  • Diese Header reduzieren typische Browser-Angriffsvektoren und gehoeren zu Security-Baselines.

Done-Check

curl -I http://localhost:8080/

5) Interne Route absichern

Ziel

  • Zugriff auf eine interne Route gezielt begrenzen.

Datei

  • proxy/nginx.conf

Muss

  • Route /internal/status bauen.
  • Nur 127.0.0.1 erlauben, alle anderen verbieten.

Warum wichtig

  • Nicht jeder Endpoint soll oeffentlich sein; Zugriffskontrolle direkt am Proxy ist oft die erste Schutzschicht.

Wichtiger Hinweis

  • Host-Request ueber localhost:8080 kommt aus Docker-Sicht oft nicht von 127.0.0.1.

Done-Check

# Erwartet typischerweise 403 vom Host (by design)
curl -i http://localhost:8080/internal/status

# Muss innerhalb des Proxy-Containers funktionieren
./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status"

6) Logging verbessern

Ziel

  • Besser debuggen koennen.

Datei

  • proxy/nginx.conf

Muss

  • Eigenes log_format mit Upstream-Infos anlegen.
  • Access-Log auf das neue Format umstellen.

Warum wichtig

  • Gute Logs verkuerzen Incident- und Debug-Zeit drastisch und sind zentral fuer Betrieb/Security.

Done-Check

curl http://localhost:8080/service/a
./scripts/compose.sh logs reverse-proxy

6a) Load Balancing konfigurieren

Ziel

  • Kernfunktion eines Reverse Proxys praktisch zeigen.

Dateien

  • docker-compose.yml
  • proxy/nginx.conf

Muss

  • Zweite Instanz von Backend A (backend-a2) anlegen.
  • upstream backend_a auf beide Instanzen erweitern.
  • Mehrfach-Requests zeigen, dass beide Instanzen antworten.

Warum wichtig

  • Lastverteilung ist eine der wichtigsten Funktionen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.

Done-Check (Beispiel)

for i in $(seq 1 8); do
  curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
done

6b) Response Header Minimization

Ziel

  • Unnoetige Header aus Upstream-Responses entfernen.

Datei

  • proxy/nginx.conf

Muss

  • Mit proxy_hide_header mindestens einen durchgereichten Backend-Header ausblenden (z. B. ETag, Last-Modified).
  • Kurz erklaeren, warum weniger Fingerprinting-Infos hilfreich sind.

Abgrenzung zu Challenge 4

  • Challenge 4 setzt aktive Schutz-Header.
  • Challenge 6b entfernt unnoetige Header aus Upstream-Responses.

Warum wichtig

  • Weniger Response-Metadaten bedeuten weniger Angriffsoberflaeche fuer Fingerprinting und Reconnaissance.

Done-Check

curl -I http://localhost:8080/service/a

6c) Debugging Challenge (kaputte Config reparieren)

Ziel

  • Fehlerdiagnose in Nginx ueben.

Datei

  • proxy/nginx.broken.conf

Muss

  • Defekte Config testweise als aktive Config verwenden.
  • Mindestens 2-3 Fehler finden und fixen.
  • Symptome und Diagnoseweg erklaeren.

Warum wichtig

  • Debugging unter Druck ist Praxisalltag; diese Aufgabe trainiert systematisches Vorgehen mit Logs und Config-Tests.

Done-Check

curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
./scripts/compose.sh logs reverse-proxy

Hard (TLS)

7) HTTPS von 0 mit Easy-RSA

Ziel

  • Eigene CA + Server-Zertifikat fuer localhost erstellen.

Dateien

  • docker-compose.yml
  • proxy/nginx.conf

Muss

  • Zertifikat fuer localhost erstellen.
  • Proxy auf 443 erweitern (z. B. 8443:443).
  • Root-CA importieren und ohne -k testen.

Warum wichtig

  • TLS korrekt einzurichten ist Basis fuer Vertraulichkeit, Integritaet und Vertrauensaufbau im Netzwerk.

Done-Check

curl https://localhost:8443/service/a

8) HTTP -> HTTPS Redirect

Voraussetzung

  • Challenge 7 muss abgeschlossen sein.
  • Nutze deine bestehende nginx.conf aus Challenge 7 als Basis.

Ziel

  • HTTP sauber auf HTTPS umlenken.

Datei

  • proxy/nginx.conf

Muss

  • HTTP Requests auf HTTPS redirecten.
  • /healthz darf optional auf HTTP bleiben.

Warum wichtig

  • Redirect erzwingt verschluesselten Zugriff und verhindert versehentliche Nutzung unsicherer HTTP-Endpunkte.

Done-Check

curl -I http://localhost:8080/service/a

9) TLS Haertung + Chain Check + HSTS

Voraussetzung

  • Challenge 7 und 8 muessen abgeschlossen sein.
  • Erweitere dieselbe nginx.conf weiter.

Ziel

  • TLS nicht nur aktivieren, sondern sauber haerten.

Datei

  • proxy/nginx.conf

Muss

  • TLS auf 1.2/1.3 beschraenken.
  • HSTS setzen (Strict-Transport-Security).
  • Zertifikatskette pruefen und kurz erklaeren.

Warum wichtig

  • Reines "HTTPS an" reicht nicht: erst Haertung + HSTS reduzieren Downgrade- und Fehlkonfigurationsrisiken.

Hinweis

  • Im HTTP-Basissetup ist HSTS absichtlich noch nicht aktiv. Das ist Teil der Aufgabe.

Done-Check

curl -I https://localhost:8443/service/a
openssl s_client -connect localhost:8443 -servername localhost

Bonus Expert

10) Wireshark: HTTP vs HTTPS sauber analysieren

Ziel

  • Nachweisbar zeigen, was im Klartext sichtbar ist und was durch TLS geschuetzt wird.

Muss

  • HTTP auf 8080 mitschneiden.
  • HTTPS auf 8443 mitschneiden.
  • ClientHello, ServerHello, Certificate markieren.
  • Technisch erklaeren, warum HTTP lesbar ist und HTTPS ohne Keys nicht.

Warum wichtig

  • Wer den Unterschied auf Paketebene gesehen hat, versteht TLS nicht nur theoretisch, sondern praktisch.

Vorgehen (empfohlen)

  1. Capture auf passendem Interface starten (lokal meist lo).
  2. HTTP Request senden und lesbaren Stream zeigen.
  3. HTTPS Request senden und TLS Handshake analysieren.
  4. Ergebnisse in 3-5 Bulletpoints zusammenfassen.

Optional

  • TLS Decrypt mit SSLKEYLOGFILE.

Done-Check

  • 3-4 Screenshots + 3-5 Bulletpoints Auswertung.

Typische Fehler

  • falsches Interface gewaehlt
  • HTTPS noch nicht korrekt aktiv
  • Keylog gesetzt, aber Browser nicht aus derselben Shell gestartet

Zusatz-Hints

  • challenges/easyrsa-hints.md
  • challenges/wireshark-hints.md
Reference in New Issue View Git Blame Copy Permalink