Challenges - Reverse Proxy & TLS

Muss: zuerst in proxy/nginx.conf nachsehen, dann testen.

Warum wichtig: Routing ist die Grundfunktion jedes Reverse Proxys - ohne sauberes Matching ist alles andere instabil.

• Welche location matched /service/a?
• Welcher upstream wird verwendet?

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

Muss: Compose-Service + Upstream + Route /service/c.

Zusatz: backends/c/index.html ist vorhanden und darf angepasst werden.

Warum wichtig: Neue Services kommen laufend dazu; Erweiterungen ohne Seiteneffekte sind Praxisalltag.

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

Muss: Alias-Route bauen, die auf Backend A fuehrt.

Warum wichtig: Der Proxy entkoppelt externe Pfade von internen Backend-Implementierungen.

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

Setze mindestens nosniff, DENY, strict-origin-when-cross-origin, Permissions-Policy, COOP, CORP.

Optional: CSP fuer statische Seiten.

Warum wichtig: Diese Header reduzieren konkrete Browser-Angriffsvektoren und gehoeren zur Security-Baseline.

curl -I http://localhost:8080/

Muss: /internal/status nur fuer 127.0.0.1.

Wichtig: Host-Request zeigt typischerweise 403 (Docker-Netzwerk).

Warum wichtig: Nicht jeder Endpoint darf oeffentlich erreichbar sein; Netzsegmentierung beginnt oft am Proxy.

curl -i http://localhost:8080/internal/status
./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status"

Eigenes log_format mit Upstream-Infos einbauen.

Warum wichtig: Ohne brauchbare Logs dauert Fehleranalyse deutlich laenger und Incident-Response wird unzuverlaessig.

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

Zweite Instanz von Backend A (backend-a2) einbauen und Round-Robin zeigen.

Warum wichtig: Lastverteilung ist Kernnutzen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.

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

Mindestens einen Backend-Response-Header per proxy_hide_header ausblenden.

Abgrenzung zu #4: #4 setzt Schutz-Header, #6b entfernt unnoetige Header aus Upstream-Responses.

Warum wichtig: Weniger preisgegebene Metadaten erschweren Fingerprinting und zielgerichtete Angriffe.

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

Mit proxy/nginx.broken.conf arbeiten, Fehler finden und reparieren.

Warum wichtig: In der Praxis geht es oft um Diagnose unter Zeitdruck, nicht nur um Greenfield-Konfiguration.

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

Zertifikat fuer localhost, Port 8443:443, Root-CA importiert.

Warum wichtig: TLS-Grundaufbau ist Voraussetzung fuer vertrauliche und manipulationssichere Kommunikation.

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

Voraussetzung: Challenge 7 abgeschlossen. Bestehende Config weiterverwenden.

Warum wichtig: Redirect verhindert unabsichtliche Klartext-Nutzung und erzwingt den sicheren Transport.

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

Voraussetzung: Challenge 7 und 8 abgeschlossen. Gleiche Config weiter erweitern.

Warum wichtig: Erst Haertung + HSTS reduzieren Downgrade-Risiken und sorgen fuer dauerhaft sichere Clients.

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

Warum wichtig: Sichtbarkeit auf Paketebene macht den Sicherheitsgewinn von TLS fuer alle nachvollziehbar.

1. HTTP auf 8080 mitschneiden und Klartext zeigen.
2. HTTPS auf 8443 mitschneiden.
3. ClientHello, ServerHello, Certificate markieren.
4. 3-5 Bulletpoints: was ist sichtbar, was ist geschuetzt?

Optional: TLS Decrypt mit SSLKEYLOGFILE.

Abgabe: mind. 3 Screenshots + technische Interpretation.