Address workshop issues and expand challenge guidance

This commit is contained in:
hkoeck
2026-03-07 17:51:46 +01:00
parent 3047413a41
commit 314b63242f
12 changed files with 459 additions and 192 deletions
+127 -48
View File
@@ -1,32 +1,33 @@
# Workshop Challenges (Reverse Proxy + TLS Focus)
Diese Aufgaben sind auf **manuelle Proxy-Konfiguration** ausgelegt.
Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
Abgabe pro Aufgabe:
## Abgabe-Format pro Challenge
- kurzer Demo-Run (1-3 Minuten)
- Done-Check Command
- 2-3 Saetze: Was wurde geaendert und warum?
- 1-3 Minuten Demo
- Done-Check Command live ausfuehren
- 2-3 Saetze erklaeren: was geaendert, warum, welche Wirkung
## Arbeitsmodus
1. Datei anpassen (`proxy/nginx.conf`, `docker-compose.yml`).
1. Dateien anpassen (`proxy/nginx.conf`, `docker-compose.yml`).
2. Deployen mit `make redeploy` oder `make proxy-reload`.
3. Testen mit `curl`/`openssl`.
4. Wenn etwas kaputt ist: `./scripts/compose.sh logs reverse-proxy`.
3. Testen mit `curl` / `openssl` / Wireshark.
4. Bei Problemen: `./scripts/compose.sh logs reverse-proxy`.
---
## Easy
### 1) Routing verstehen
### 1) Routing verstehen (aktiv)
**Ziel**
- Reverse Proxy leitet Requests auf unterschiedliche Backends.
- Verstehen, wie Nginx Requests per Pfad an unterschiedliche Upstreams schickt.
**Muss**
- `service/a` und `service/b` aufrufen.
- Unterschiede in den Antworten erklaeren.
- 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.
**Done-Check**
```bash
@@ -37,32 +38,36 @@ curl http://localhost:8080/service/b
### 2) Drittes Backend manuell hinzufuegen
**Ziel**
- Proxy auf ein neues Backend erweitern.
- 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` anlegen.
- Upstream + Route `/service/c` konfigurieren.
- Service `backend-c` in Compose einbauen.
- Upstream + Route `/service/c` in Nginx anlegen.
- A/B muessen weiterhin funktionieren.
**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
### 3) Eigene Route mit Rewrite oder Alias-Route
**Ziel**
- URL-Struktur im Proxy gestalten.
- URL-Design vom Backend-Pfad entkoppeln.
**Datei**
- `proxy/nginx.conf`
**Muss**
- Route `/demo/a` soll intern auf Backend A zeigen.
- Implementierung ueber `rewrite` oder eigene `location`.
- Route `/demo/a` anbieten, die auf Backend A fuehrt.
- Entweder per rewrite oder per eigener proxy-Route loesen.
**Done-Check**
```bash
@@ -76,13 +81,13 @@ curl http://localhost:8080/demo/a
### 4) Security Headers setzen
**Ziel**
- Grundlegende Header-Haertung im Proxy.
- Browserseitige Basishaertung aktivieren.
**Datei**
- `proxy/nginx.conf`
**Muss**
- Setze mindestens:
- Mindestens setzen:
- `X-Content-Type-Options: nosniff`
- `X-Frame-Options: DENY`
- `Referrer-Policy: no-referrer`
@@ -95,31 +100,38 @@ curl -I http://localhost:8080/
### 5) Interne Route absichern
**Ziel**
- Route nur lokal erreichbar machen.
- Zugriff auf eine interne Route gezielt begrenzen.
**Datei**
- `proxy/nginx.conf`
**Muss**
- Neue Route `/internal/status` bauen.
- Route `/internal/status` bauen.
- Nur `127.0.0.1` erlauben, alle anderen verbieten.
**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**
- Proxy-Debugging ueber bessere Logs.
- Besser debuggen koennen.
**Datei**
- `proxy/nginx.conf`
**Muss**
- Eigenes `log_format` mit Upstream-Infos erstellen.
- Access Log auf dieses Format umstellen.
- Eigenes `log_format` mit Upstream-Infos anlegen.
- Access-Log auf das neue Format umstellen.
**Done-Check**
```bash
@@ -127,6 +139,65 @@ 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.
**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
```
### 6b) Header Stripping (Response)
**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.
**Done-Check**
```bash
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.
**Done-Check**
```bash
curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
./scripts/compose.sh logs reverse-proxy
```
---
## Hard (TLS)
@@ -134,16 +205,16 @@ curl http://localhost:8080/service/a
### 7) HTTPS von 0 mit Easy-RSA
**Ziel**
- Eigene CA + Server-Zertifikat fuer `localhost`.
- Eigene CA + Server-Zertifikat fuer `localhost` erstellen.
**Dateien**
- `docker-compose.yml`
- `proxy/nginx.conf`
**Muss**
- Cert fuer `localhost` erzeugen.
- Proxy auf `443` aktivieren (z. B. `8443:443`).
- Root-CA importieren.
- Zertifikat fuer `localhost` erstellen.
- Proxy auf `443` erweitern (z. B. `8443:443`).
- Root-CA importieren und ohne `-k` testen.
**Done-Check**
```bash
@@ -152,14 +223,18 @@ 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**
- Klarer Redirect-Flow.
- HTTP sauber auf HTTPS umlenken.
**Datei**
- `proxy/nginx.conf`
**Muss**
- HTTP Requests auf HTTPS umleiten.
- HTTP Requests auf HTTPS redirecten.
- `/healthz` darf optional auf HTTP bleiben.
**Done-Check**
@@ -167,20 +242,25 @@ curl https://localhost:8443/service/a
curl -I http://localhost:8080/service/a
```
### 9) TLS Haertung + Chain Check
### 9) TLS Haertung + Chain Check + HSTS
**Voraussetzung**
- Challenge 7 und 8 muessen abgeschlossen sein.
- Erweitere dieselbe `nginx.conf` weiter.
**Ziel**
- Bessere TLS-Defaults + saubere Validierung.
- TLS nicht nur aktivieren, sondern sauber haerten.
**Datei**
- `proxy/nginx.conf`
**Muss**
- TLS auf 1.2/1.3 beschraenken.
- HSTS aktivieren (`Strict-Transport-Security`).
- Zertifikatskette pruefen.
- HSTS setzen (`Strict-Transport-Security`).
- Zertifikatskette pruefen und kurz erklaeren.
Hinweis: Im HTTP-Basissetup ist HSTS absichtlich **noch nicht** aktiv. Das ist Teil der Aufgabe.
**Hinweis**
- Im HTTP-Basissetup ist HSTS absichtlich **noch nicht** aktiv. Das ist Teil der Aufgabe.
**Done-Check**
```bash
@@ -192,23 +272,22 @@ openssl s_client -connect localhost:8443 -servername localhost
## Bonus Expert
### 10) Wireshark: HTTP vs HTTPS
### 10) Wireshark: HTTP vs HTTPS sauber analysieren
**Ziel**
- Sichtbar machen, was verschluesselt ist und was nicht.
- Nachweisbar zeigen, was im Klartext sichtbar ist und was durch TLS geschuetzt wird.
**Muss**
- HTTP Traffic auf `8080` mitschneiden.
- HTTPS Traffic auf `8443` mitschneiden.
- TLS Handshake markieren (`ClientHello`, `ServerHello`, `Certificate`).
- Technisch erklaeren, warum HTTP lesbar ist und HTTPS nicht.
- HTTP auf `8080` mitschneiden.
- HTTPS auf `8443` mitschneiden.
- `ClientHello`, `ServerHello`, `Certificate` markieren.
- Technisch erklaeren, warum HTTP lesbar ist und HTTPS ohne Keys nicht.
**Vorgehen (empfohlen)**
1. Capture auf `lo` (oder passendes Interface) starten, Filter `tcp.port == 8080`.
2. `curl http://localhost:8080/service/a` senden und HTTP-Stream zeigen.
3. Capture auf `tcp.port == 8443` oder `tls` umstellen.
4. `curl https://localhost:8443/service/a` senden.
5. Handshake-Pakete markieren und kurz erklaeren.
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`.