Refine workshop UI navigation and hardening guidance

challenges/README.md

@@ -29,6 +29,9 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
 - 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**
 ```bash
 curl http://localhost:8080/service/a
@@ -50,6 +53,9 @@ curl http://localhost:8080/service/b
 - 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**
 ```bash
 curl http://localhost:8080/service/c
@@ -69,6 +75,9 @@ curl http://localhost:8080/service/b
 - 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**
 ```bash
 curl http://localhost:8080/demo/a
@@ -90,7 +99,14 @@ curl http://localhost:8080/demo/a
 - Mindestens setzen:
   - `X-Content-Type-Options: nosniff`
   - `X-Frame-Options: DENY`
-  - `Referrer-Policy: no-referrer`
+  - `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**
 ```bash
@@ -109,6 +125,9 @@ curl -I http://localhost:8080/
 - 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`.
 
@@ -133,6 +152,9 @@ curl -i http://localhost:8080/internal/status
 - 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**
 ```bash
 curl http://localhost:8080/service/a
@@ -153,6 +175,9 @@ curl http://localhost:8080/service/a
 - `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)**
 ```bash
 for i in $(seq 1 8); do
@@ -160,7 +185,7 @@ for i in $(seq 1 8); do
 done
 ```
 
-### 6b) Header Stripping (Response)
+### 6b) Response Header Minimization
 
 **Ziel**
 - Unnoetige Header aus Upstream-Responses entfernen.
@@ -173,6 +198,13 @@ done
   (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**
 ```bash
 curl -I http://localhost:8080/service/a
@@ -191,6 +223,9 @@ curl -I http://localhost:8080/service/a
 - 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**
 ```bash
 curl http://localhost:8080/service/a
@@ -216,6 +251,9 @@ curl http://localhost:8080/service/b
 - 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**
 ```bash
 curl https://localhost:8443/service/a
@@ -237,6 +275,9 @@ curl https://localhost:8443/service/a
 - 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**
 ```bash
 curl -I http://localhost:8080/service/a
@@ -259,6 +300,9 @@ curl -I http://localhost:8080/service/a
 - 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.
 
@@ -283,6 +327,9 @@ openssl s_client -connect localhost:8443 -servername localhost
 - `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.