htl-reverse-proxy-tls-lab/challenges/README.md

# 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**
```bash
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**
```bash
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**
```bash
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**
```bash
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**
```bash
# 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**
```bash
curl http://localhost:8080/service/a
./scripts/compose.sh logs reverse-proxy
```

### 7) 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)**
```bash
for i in $(seq 1 8); do
  curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
done
```

### 8) 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 8 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
```

### 9) 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.

**Erwartete Fehlerarten (Beispiel aus `nginx.broken.conf`)**
- Upstream-Name passt nicht zum referenzierten Namen in `proxy_pass`.
- Falscher Upstream-Port (`8080` statt `80`).
- Fehlender Trailing Slash in `proxy_pass` bei Prefix-Location.

**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
curl http://localhost:8080/service/b
./scripts/compose.sh logs reverse-proxy
```

---

## Hard (TLS)

### 10) 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**
```bash
curl https://localhost:8443/service/a
```

### 11) HTTP -> HTTPS Redirect

**Voraussetzung**
- Challenge 10 muss abgeschlossen sein.
- Nutze deine bestehende `nginx.conf` aus Challenge 10 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**
```bash
curl -I http://localhost:8080/service/a
```

### 12) TLS Haertung + Chain Check + HSTS

**Voraussetzung**
- Challenge 10 und 11 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**
```bash
curl -I https://localhost:8443/service/a
openssl s_client -connect localhost:8443 -servername localhost
```

---

## Bonus Expert

### 13) 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`