AlexBa16/htl-reverse-proxy-tls-lab
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Verbessere Challenge-Angaben, TLS-Fixes und Windows-Tauglichkeit

Browse Source 
Fachliche Fixes:
- Easy-RSA: explizites --subject-alt-name (SAN) ergaenzt, sonst
  scheitert curl trotz CA-Import
- HSTS: max-age auf 3600 reduziert, includeSubDomains erklaert,
  Warnung zur host-weiten Browser-Falle + Reset-Weg
- Challenge 9: Backup-/Restore-Schritte fuer nginx.conf
- Compose-Portwechsel: redeploy statt proxy-reload klargestellt
- log_format-Platzierung (http-Block) dokumentiert
- add_header-Vererbungsfalle erklaert (Ch. 4 + Abgrenzung Ch. 8)

Angabe-Struktur (alle 13 Challenges):
- Einheitliches Schema: Ausgangszustand, Schritte (Muss),
  Zielzustand/Akzeptanz, erwartete Done-Check-Ausgaben
- Arbeitsweise global geklaert (additiv, Ausnahme Ch. 9, Reset)

Robustheit/Kosmetik:
- Load-Balancing: eindeutiger INSTANCE-Marker statt fragilem grep
- Challenge-3-Titel auf "Alias-Route" korrigiert
- HTTPS_PORT in .env.example parametrisiert
- Umlaut-Konsistenz (ASCII)

Windows-Tauglichkeit:
- Klargestellt: Test-Kommandos laufen in WSL bash, nicht PowerShell
  (curl-Alias-Falle), Stack-Steuerung per Wrapper oder WSL
- Wireshark: empfohlener Capture-Weg in WSL (tshark), npcap-Hinweis
- CA-Import: Linux-Trust-Store (WSL) vs Windows-Browser (certutil)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
hkoeck
2026-05-31 22:08:41 +02:00
parent 1739810044
commit 79a13f0919
12 changed files with 294 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.env.example
+7
View File
@@ -1 +1,8 @@
# Host-Port fuer HTTP (Reverse Proxy -> Container Port 80)
HTTP_PORT=8080
# Host-Port fuer HTTPS, wird erst ab Challenge 10 genutzt (-> Container Port 443).
# Hinweis: Nginx liest in der statischen Config keine Env-Variablen. Wenn du diesen
# Wert aenderst, musst du den Redirect-Zielport in proxy/nginx.conf
# (z. B. "return 301 https://$host:8443$request_uri;") manuell angleichen.
HTTPS_PORT=8443
README.md
+2
View File
@@ -122,6 +122,8 @@ curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
```
> **Windows:** Diese und alle weiteren Test-Kommandos (`curl`, `openssl`, `grep`, Schleifen) im **WSL-Terminal (bash)** ausfuehren, nicht in PowerShell. In PowerShell ist `curl` ein Alias fuer `Invoke-WebRequest` und versteht die genutzten Flags (`-I`, `-k`, `--cacert`) nicht. PowerShell nur fuer den Stack-Wrapper `scripts/workshop.ps1`.
## Fokus im Workshop
Die Basis ist bewusst nur HTTP. HTTPS ist Teil der Aufgaben:
backends/a/index.html
+1
View File
@@ -64,6 +64,7 @@
</style>
</head>
<body>
<!-- INSTANCE=A -->
<main>
<span class="tag">Backend A</span>
<h1>Reverse Proxy Target A</h1>
backends/a2/index.html
+1
View File
@@ -39,6 +39,7 @@
</style>
</head>
<body>
<!-- INSTANCE=A2 -->
<main>
<h1>Reverse Proxy Target A2</h1>
<p>Use this page to validate load balancing between backend-a and backend-a2.</p>
challenges/README.md
+186 -61
View File
@@ -8,13 +8,29 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
- Done-Check Command live ausfuehren
- 2-3 Saetze erklaeren: was geaendert, warum, welche Wirkung
## Wo laufen die Kommandos? (besonders Windows)
Die meisten Teilnehmer arbeiten unter **Windows mit Docker Desktop + WSL**. Wichtig:
- **Stack steuern** (`make ...` oder der PowerShell-Wrapper `scripts/workshop.ps1`): geht aus PowerShell **oder** aus dem WSL-Terminal.
- **Alle Challenge-Kommandos** (`curl`, `openssl`, `grep`, `wget`, `for`-Schleifen, `./scripts/compose.sh ...`): laufen im **WSL-Terminal (bash)**, nicht in PowerShell.
- **Warnung:** In PowerShell ist `curl` ein Alias fuer `Invoke-WebRequest` und versteht die hier genutzten Flags (`-I`, `-k`, `--cacert`) **nicht**. Immer im WSL-Terminal testen.
- Das Repo liegt im WSL-Dateisystem oder unter `/mnt/c/...`; arbeite am besten aus dem WSL-Terminal im Projektordner.
## Arbeitsmodus
1. Dateien anpassen (`proxy/nginx.conf`, `docker-compose.yml`).
2. Deployen mit `make redeploy` oder `make proxy-reload`.
2. Deployen: nach reinen `nginx.conf`-Aenderungen reicht `make proxy-reload`; nach Aenderungen an `docker-compose.yml` (z. B. neue Ports oder Services) immer `make redeploy`, da der Container neu erstellt werden muss.
3. Testen mit `curl` / `openssl` / Wireshark.
4. Bei Problemen: `./scripts/compose.sh logs reverse-proxy`.
## Arbeitsweise (wichtig)
- Es wird **additiv in einer einzigen `proxy/nginx.conf`** gearbeitet: jede Challenge erweitert den Stand der vorherigen. Loesungen nicht wieder loeschen - die TLS-Challenges (10-12) bauen direkt aufeinander auf.
- **Ausnahme Challenge 9** (Debugging): Diese ueberschreibt die `nginx.conf` bewusst. Vorher sichern (`cp proxy/nginx.conf proxy/nginx.conf.bak`), danach wiederherstellen.
- Jede Angabe nennt einen **Ausgangszustand** (worauf baue ich auf) und einen **Zielzustand / Akzeptanz** (woran erkenne ich "fertig"). Der Done-Check ist die pruefbare Form des Zielzustands.
- Komplett zuruecksetzen geht jederzeit mit `make reset` (Container/Volumes) bzw. `make reset-hard` (zusaetzlich lokale Datei-Aenderungen verwerfen).
---
## Easy
@@ -24,45 +40,59 @@ Diese Aufgaben sind bewusst auf **manuelle Proxy-Konfiguration** ausgelegt.
**Ziel**
- Verstehen, wie Nginx Requests per Pfad an unterschiedliche Upstreams schickt.
**Muss**
**Datei**
- `proxy/nginx.conf` (nur lesen)
**Schritte (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.
**Zielzustand / Akzeptanz**
- Du kannst fuer `/service/a` und `/service/b` jeweils Location -> Upstream -> Backend benennen und begruenden, warum die Antworten unterschiedlich sind.
**Done-Check**
```bash
curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
curl http://localhost:8080/service/a # -> "Reverse Proxy Target A"
curl http://localhost:8080/service/b # -> "Reverse Proxy Target B"
```
**Warum wichtig**
- Das ist die Kernkompetenz bei Reverse Proxys: Request-Fluss lesen und korrekt begruenden.
### 2) Drittes Backend manuell hinzufuegen
**Ziel**
- Setup sicher erweitern, ohne bestehende Routen kaputt zu machen.
**Ausgangszustand**
- Stack laeuft, `/service/a` und `/service/b` antworten.
- `backends/c/index.html` liegt bereits im Repo (Starterseite).
**Dateien**
- `docker-compose.yml`
- `proxy/nginx.conf`
- `backends/c/index.html` (vorhanden, darf angepasst werden)
**Muss**
**Schritte (Muss)**
- Service `backend-c` in Compose einbauen.
- Upstream + Route `/service/c` in Nginx anlegen.
- A/B muessen weiterhin funktionieren.
- Deployen mit `make redeploy` (Compose-Aenderung -> Container-Neustart noetig).
**Warum wichtig**
- In realen Umgebungen kommen neue Services laufend dazu. Saubere Erweiterung ohne Regression ist entscheidend.
**Zielzustand / Akzeptanz**
- `/service/c` liefert Backend C.
- `/service/a` und `/service/b` funktionieren unveraendert weiter (keine Regression).
**Done-Check**
```bash
curl http://localhost:8080/service/c
curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
curl http://localhost:8080/service/c # -> enthaelt "Reverse Proxy Target C"
curl http://localhost:8080/service/a # -> weiterhin "Reverse Proxy Target A"
curl http://localhost:8080/service/b # -> weiterhin "Reverse Proxy Target B"
```
**Warum wichtig**
- In realen Umgebungen kommen neue Services laufend dazu. Saubere Erweiterung ohne Regression ist entscheidend.
### 3) Eigene Route mit Rewrite oder Alias-Route
**Ziel**
@@ -71,18 +101,22 @@ curl http://localhost:8080/service/b
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (Muss)**
- Route `/demo/a` anbieten, die auf Backend A fuehrt.
- Entweder per rewrite oder per eigener proxy-Route loesen.
- Deployen mit `make proxy-reload`.
**Warum wichtig**
- Der Proxy entkoppelt externe API-Pfade von internen Service-Pfaden und ermoeglicht saubere Migrationen.
**Zielzustand / Akzeptanz**
- `/demo/a` liefert dieselbe Antwort wie `/service/a` (Backend A), obwohl der externe Pfad ein anderer ist.
**Done-Check**
```bash
curl http://localhost:8080/demo/a
curl http://localhost:8080/demo/a # -> "Reverse Proxy Target A"
```
**Warum wichtig**
- Der Proxy entkoppelt externe API-Pfade von internen Service-Pfaden und ermoeglicht saubere Migrationen.
---
## Medium
@@ -95,7 +129,7 @@ curl http://localhost:8080/demo/a
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (Muss)**
- Mindestens setzen:
- `X-Content-Type-Options: nosniff`
- `X-Frame-Options: DENY`
@@ -104,15 +138,24 @@ curl http://localhost:8080/demo/a
- `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)
- Deployen mit `make proxy-reload`.
**Warum wichtig**
- Diese Header reduzieren typische Browser-Angriffsvektoren und gehoeren zu Security-Baselines.
**Fallstrick (`add_header`-Vererbung)**
- Header am besten **einmal im `server {}`-Block** setzen, dann gelten sie fuer alle Locations.
- Achtung: Sobald in einem `location {}`-Block **ein** `add_header` steht, verwirft Nginx in dieser Location **alle** `add_header` aus dem `server`-Block. Dann muessen sie dort wiederholt werden. Pruefen mit `curl -I` direkt auf der jeweiligen Route.
**Zielzustand / Akzeptanz**
- `curl -I http://localhost:8080/` zeigt alle geforderten Security-Header in der Antwort.
**Done-Check**
```bash
curl -I http://localhost:8080/
# -> zeigt X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP, CORP
```
**Warum wichtig**
- Diese Header reduzieren typische Browser-Angriffsvektoren und gehoeren zu Security-Baselines.
### 5) Interne Route absichern
**Ziel**
@@ -121,25 +164,29 @@ curl -I http://localhost:8080/
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (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.
- Deployen mit `make proxy-reload`.
**Wichtiger Hinweis**
- Host-Request ueber `localhost:8080` kommt aus Docker-Sicht oft **nicht** von `127.0.0.1`.
**Zielzustand / Akzeptanz**
- Aufruf vom Host liefert `403`; Aufruf von innerhalb des Proxy-Containers (`127.0.0.1`) liefert die Antwort.
**Done-Check**
```bash
# Erwartet typischerweise 403 vom Host (by design)
curl -i http://localhost:8080/internal/status
# -> Erwartet typischerweise 403 vom Host (by design)
# Muss innerhalb des Proxy-Containers funktionieren
./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status"
# -> "internal ok" (funktioniert nur container-intern)
```
**Warum wichtig**
- Nicht jeder Endpoint soll oeffentlich sein; Zugriffskontrolle direkt am Proxy ist oft die erste Schutzschicht.
### 6) Logging verbessern
**Ziel**
@@ -148,19 +195,27 @@ curl -i http://localhost:8080/internal/status
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (Muss)**
- Eigenes `log_format` mit Upstream-Infos anlegen.
- Access-Log auf das neue Format umstellen.
- Deployen mit `make proxy-reload`.
**Warum wichtig**
- Gute Logs verkuerzen Incident- und Debug-Zeit drastisch und sind zentral fuer Betrieb/Security.
**Hinweis**
- `log_format` gehoert in den `http {}`-Block (nicht in `server {}` oder `location {}`), sonst startet Nginx mit `"log_format" directive is not allowed here` nicht. `access_log` darf in `http`, `server` oder `location` stehen.
**Zielzustand / Akzeptanz**
- Nach einem Request erscheint im Log eine Zeile im neuen Format inklusive Upstream-Infos (`upstream=...`, `urt=...`).
**Done-Check**
```bash
curl http://localhost:8080/service/a
./scripts/compose.sh logs reverse-proxy
# -> neue Log-Zeile mit upstream=... und urt=...
```
**Warum wichtig**
- Gute Logs verkuerzen Incident- und Debug-Zeit drastisch und sind zentral fuer Betrieb/Security.
### 7) Load Balancing konfigurieren
**Ziel**
@@ -170,20 +225,29 @@ curl http://localhost:8080/service/a
- `docker-compose.yml`
- `proxy/nginx.conf`
**Muss**
**Ausgangszustand**
- `/service/a` zeigt aktuell nur eine Instanz (Backend A). `backends/a2/index.html` liegt bereits im Repo.
**Schritte (Muss)**
- Zweite Instanz von Backend A (`backend-a2`) anlegen.
- `upstream backend_a` auf beide Instanzen erweitern.
- Mehrfach-Requests zeigen, dass beide Instanzen antworten.
- Deployen mit `make redeploy` (Compose-Aenderung).
**Warum wichtig**
- Lastverteilung ist eine der wichtigsten Funktionen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.
**Zielzustand / Akzeptanz**
- Bei mehreren Aufrufen von `/service/a` antworten **beide** Instanzen (Round-Robin), also sowohl `Target A` als auch `Target A2`.
**Done-Check (Beispiel)**
```bash
for i in $(seq 1 8); do
curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
done
# -> Mischung aus "INSTANCE=A" und "INSTANCE=A2" ueber die 8 Requests
```
- Der unsichtbare Marker `<!-- INSTANCE=A -->` bzw. `INSTANCE=A2` steckt im HTML der Backends. `[A-Za-z0-9]*` matched das ganze Token eindeutig (kein Prefix-Problem wie bei `A` vs. `A2`).
**Warum wichtig**
- Lastverteilung ist eine der wichtigsten Funktionen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.
### 8) Response Header Minimization
@@ -193,51 +257,64 @@ done
**Datei**
- `proxy/nginx.conf`
**Muss**
**Schritte (Muss)**
- Mit `proxy_hide_header` mindestens einen durchgereichten Backend-Header ausblenden
(z. B. `ETag`, `Last-Modified`).
- Kurz erklaeren, warum weniger Fingerprinting-Infos hilfreich sind.
- Deployen mit `make proxy-reload`.
**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.
**Zielzustand / Akzeptanz**
- Der gewaehlte Header (z. B. `ETag`) taucht in `curl -I http://localhost:8080/service/a` **nicht mehr** auf, vorher war er sichtbar.
**Done-Check**
```bash
curl -I http://localhost:8080/service/a
# -> der ausgeblendete Header (z. B. ETag) fehlt jetzt in der Antwort
```
**Warum wichtig**
- Weniger Response-Metadaten bedeuten weniger Angriffsoberflaeche fuer Fingerprinting und Reconnaissance.
### 9) Debugging Challenge (kaputte Config reparieren)
**Ziel**
- Fehlerdiagnose in Nginx ueben.
**Ausgangszustand**
- Eigene `proxy/nginx.conf` ist in Betrieb. `proxy/nginx.broken.conf` enthaelt absichtlich mehrere Fehler.
**Datei**
- `proxy/nginx.broken.conf`
**Muss**
**Schritte (Muss)**
- Zuerst die eigene `proxy/nginx.conf` sichern (z. B. `cp proxy/nginx.conf proxy/nginx.conf.bak`) - diese Challenge ueberschreibt sie.
- Defekte Config testweise als aktive Config verwenden.
- Mindestens 2-3 Fehler finden und fixen.
- Symptome und Diagnoseweg erklaeren.
- Am Ende die eigene Config wiederherstellen (`cp proxy/nginx.conf.bak proxy/nginx.conf`).
**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.
**Zielzustand / Akzeptanz**
- Nach den Fixes liefern `/service/a` und `/service/b` wieder ihre Backends; Nginx startet ohne Config-Fehler.
**Done-Check**
```bash
curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
curl http://localhost:8080/service/a # -> "Reverse Proxy Target A"
curl http://localhost:8080/service/b # -> "Reverse Proxy Target B"
./scripts/compose.sh logs reverse-proxy
```
**Warum wichtig**
- Debugging unter Druck ist Praxisalltag; diese Aufgabe trainiert systematisches Vorgehen mit Logs und Config-Tests.
---
## Hard (TLS)
@@ -247,23 +324,40 @@ curl http://localhost:8080/service/b
**Ziel**
- Eigene CA + Server-Zertifikat fuer `localhost` erstellen.
**Ausgangszustand**
- Stack laeuft auf HTTP (`8080`). Noch kein TLS, kein Port `8443`.
- `easy-rsa` und `openssl` sind installiert (siehe `challenges/easyrsa-hints.md`).
**Dateien**
- `docker-compose.yml`
- `proxy/nginx.conf`
- `docker-compose.yml` (Port `8443:443` + Cert-Volume)
- `proxy/nginx.conf` (TLS-Serverblock)
- `certs/easyrsa/*` (PKI), `certs/live/*` (Runtime-Cert + Key)
**Muss**
- Zertifikat fuer `localhost` erstellen.
- Proxy auf `443` erweitern (z. B. `8443:443`).
- Root-CA importieren und ohne `-k` testen.
**Schritte (Muss)**
- CA + Server-Zertifikat fuer `localhost` mit SAN erstellen (`--subject-alt-name="DNS:localhost,IP:127.0.0.1"`).
- Nur Runtime-Cert + Key bereitstellen (nicht die ganze PKI mounten).
- Proxy auf `443` erweitern (Mapping `8443:443`) und TLS in Nginx aktivieren.
- Mit `make redeploy` deployen (Compose-Aenderung -> Container-Neustart noetig).
- Root-CA in den System-Trust-Store importieren.
**Warum wichtig**
- TLS korrekt einzurichten ist Basis fuer Vertraulichkeit, Integritaet und Vertrauensaufbau im Netzwerk.
**Zielzustand / Akzeptanz**
- `curl https://localhost:8443/service/a` liefert Backend A **ohne** `-k` (CA wird vertraut).
- Kein SAN-/Hostname-Fehler.
**Done-Check**
```bash
curl https://localhost:8443/service/a
# Erwartet: HTML von Backend A, KEIN "SSL certificate problem"
# Falls CA noch nicht global importiert:
curl --cacert certs/easyrsa/pki/ca.crt https://localhost:8443/service/a
```
**Warum wichtig**
- TLS korrekt einzurichten ist Basis fuer Vertraulichkeit, Integritaet und Vertrauensaufbau im Netzwerk.
**Haeufigster Blocker**
- Ohne SAN scheitert curl mit `no alternative certificate subject name matches target host name` -> beim Signieren `--subject-alt-name` setzen (Details in `challenges/easyrsa-hints.md`).
### 11) HTTP -> HTTPS Redirect
**Voraussetzung**
@@ -273,21 +367,29 @@ curl https://localhost:8443/service/a
**Ziel**
- HTTP sauber auf HTTPS umlenken.
**Ausgangszustand**
- Aus Challenge 10: HTTPS laeuft auf `8443`, HTTP auf `8080` liefert noch direkt Inhalte.
**Datei**
- `proxy/nginx.conf`
**Muss**
- HTTP Requests auf HTTPS redirecten.
**Schritte (Muss)**
- HTTP Requests auf HTTPS redirecten (`return 301 https://$host:8443$request_uri;`).
- `/healthz` darf optional auf HTTP bleiben.
- Deployen mit `make proxy-reload` (reine `nginx.conf`-Aenderung).
**Warum wichtig**
- Redirect erzwingt verschluesselten Zugriff und verhindert versehentliche Nutzung unsicherer HTTP-Endpunkte.
**Zielzustand / Akzeptanz**
- HTTP-Aufrufe auf `8080` antworten mit `301` und `Location: https://localhost:8443/...`.
**Done-Check**
```bash
curl -I http://localhost:8080/service/a
# Erwartet: HTTP/1.1 301 ... und Location: https://localhost:8443/service/a
```
**Warum wichtig**
- Redirect erzwingt verschluesselten Zugriff und verhindert versehentliche Nutzung unsicherer HTTP-Endpunkte.
### 12) TLS Haertung + Chain Check + HSTS
**Voraussetzung**
@@ -300,23 +402,39 @@ curl -I http://localhost:8080/service/a
**Datei**
- `proxy/nginx.conf`
**Muss**
- TLS auf 1.2/1.3 beschraenken.
**Ausgangszustand**
- Aus Challenge 10+11: HTTPS auf `8443` laeuft, HTTP wird umgeleitet. TLS ist aber noch ungehaertet (keine Protokoll-Beschraenkung, kein HSTS).
**Schritte (Muss)**
- TLS auf 1.2/1.3 beschraenken (`ssl_protocols TLSv1.2 TLSv1.3;`).
- HSTS setzen (`Strict-Transport-Security`).
- Zertifikatskette pruefen und kurz erklaeren.
**Warum wichtig**
- Reines "HTTPS an" reicht nicht: erst Haertung + HSTS reduzieren Downgrade- und Fehlkonfigurationsrisiken.
- Deployen mit `make proxy-reload`.
**Hinweis**
- Im HTTP-Basissetup ist HSTS absichtlich **noch nicht** aktiv. Das ist Teil der Aufgabe.
**Warnung (HSTS-Falle im Browser)**
- HSTS merkt sich der Browser **host-weit** (`localhost`), nicht pro Port. Nach einem Besuch von `https://localhost:8443` erzwingt der Browser `https` auch fuer `http://localhost:8080` -> das HTTP-Lab scheint dann "kaputt".
- Zum Pruefen daher `curl` nutzen (curl speichert HSTS nicht).
- Falls der Browser haengt: HSTS fuer `localhost` zuruecksetzen (Chrome: `chrome://net-internals/#hsts` -> "Delete domain security policies" -> `localhost`).
- `max-age` ist im Lab bewusst kurz (1h), damit der Effekt von selbst verfaellt.
**Zielzustand / Akzeptanz**
- `curl -I` zeigt den `Strict-Transport-Security`-Header.
- `openssl s_client` verhandelt TLSv1.2 oder TLSv1.3 und endet mit `Verify return code: 0 (ok)`.
**Done-Check**
```bash
curl -I https://localhost:8443/service/a
# -> enthaelt: Strict-Transport-Security: max-age=3600; includeSubDomains
openssl s_client -connect localhost:8443 -servername localhost
# -> Protocol: TLSv1.3 (oder 1.2), Verify return code: 0 (ok)
```
**Warum wichtig**
- Reines "HTTPS an" reicht nicht: erst Haertung + HSTS reduzieren Downgrade- und Fehlkonfigurationsrisiken.
---
## Bonus Expert
@@ -326,14 +444,18 @@ openssl s_client -connect localhost:8443 -servername localhost
**Ziel**
- Nachweisbar zeigen, was im Klartext sichtbar ist und was durch TLS geschuetzt wird.
**Muss**
**Ausgangszustand**
- HTTPS laeuft (Challenge 10), `8080` und `8443` sind erreichbar. Wireshark/tshark ist installiert (siehe `challenges/wireshark-hints.md`).
**Schritte (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.
**Zielzustand / Akzeptanz**
- HTTP-Mitschnitt: Pfad und Header sind im Klartext lesbar (Follow Stream).
- HTTPS-Mitschnitt: nur der TLS-Handshake ist sichtbar, die Nutzdaten sind ohne Key nicht lesbar.
**Vorgehen (empfohlen)**
1. Capture auf passendem Interface starten (lokal meist `lo`).
@@ -347,6 +469,9 @@ openssl s_client -connect localhost:8443 -servername localhost
**Done-Check**
- 3-4 Screenshots + 3-5 Bulletpoints Auswertung.
**Warum wichtig**
- Wer den Unterschied auf Paketebene gesehen hat, versteht TLS nicht nur theoretisch, sondern praktisch.
**Typische Fehler**
- falsches Interface gewaehlt
- HTTPS noch nicht korrekt aktiv
challenges/easyrsa-hints.md
+10 -4
View File
@@ -36,9 +36,11 @@ cd certs/easyrsa
```bash
./easyrsa gen-req localhost nopass
./easyrsa sign-req server localhost
./easyrsa --subject-alt-name="DNS:localhost,IP:127.0.0.1" sign-req server localhost
```
Wichtig: Das `--subject-alt-name` ist nicht optional. Moderne Clients (curl, Browser) ignorieren den CN und pruefen ausschliesslich den SAN. Ohne SAN scheitert `curl https://localhost:8443` trotz korrekt importierter CA mit `no alternative certificate subject name matches target host name`.
## 5) Nur Runtime-Zertifikate bereitstellen (nicht komplette PKI mounten)
Nutze fuer den Container nur die benoetigten Laufzeitdateien:
@@ -69,8 +71,8 @@ Danach in `proxy/nginx.conf` TLS aktivieren und in `docker-compose.yml` Port `44
services:
reverse-proxy:
ports:
- "8080:80"
- "8443:443"
- "${HTTP_PORT:-8080}:80"
- "${HTTPS_PORT:-8443}:443"
volumes:
- ./proxy/nginx.conf:/etc/nginx/nginx.conf:ro,z
- ./proxy/html:/usr/share/nginx/html:ro,z
@@ -101,7 +103,7 @@ server {
ssl_certificate /etc/nginx/certs/localhost.crt;
ssl_certificate_key /etc/nginx/certs/localhost.key;
ssl_protocols TLSv1.2 TLSv1.3;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
@@ -122,6 +124,10 @@ server {
## 6) Root-CA importieren (Trust Store)
Wichtig: In den Trust-Store **der Umgebung importieren, in der du testest**.
- Test mit `curl` aus **WSL** (der Standardweg im Workshop): in den **Linux**-Trust-Store importieren -> Ubuntu/Debian-Befehle unten.
- Test im **Windows-Browser**: zusaetzlich der Windows-Import (`certutil`).
Fedora:
```bash
challenges/wireshark-hints.md
+17 -1
View File
@@ -22,6 +22,20 @@ sudo apt install -y wireshark tshark
- Linux lokal: meist `lo` (Loopback) fuer `localhost`
- Docker-Welt: ggf. `docker0` bzw. Bridge-Interface
**Windows (Docker Desktop + WSL) - empfohlener Weg:**
- Capture **innerhalb WSL** machen, dort verhaelt sich `lo` wie unter Linux. Sowohl der `curl`-Request als auch der Mitschnitt laufen im WSL-Terminal:
```bash
# Terminal 1 (WSL): Mitschnitt starten
sudo tshark -i lo -f "tcp port 8080"
# Terminal 2 (WSL): Request senden
curl http://localhost:8080/service/a
```
- Natives Windows-Wireshark kann `localhost` nur ueber den npcap-Adapter "Adapter for loopback traffic capture" mitschneiden, und Docker-Desktop-Portforwarding macht das unzuverlaessig. Fuer den Workshop daher in WSL bleiben.
- Wireshark-GUI unter WSL braucht WSLg (Windows 11) oder ein X-Server; einfacher ist `tshark` (CLI) plus spaeter `.pcap` in der Wireshark-GUI oeffnen (`tshark -w mitschnitt.pcap ...`).
## 3) HTTP zuerst (Klartext)
1. Mitschnitt starten
@@ -85,12 +99,14 @@ tls.handshake.type == 11
## 6) Optional: TLS in Wireshark entschluesseln
1. Vor Browser-Start setzen:
1. Vor Browser-Start setzen (WSL/bash):
```bash
export SSLKEYLOGFILE="$HOME/sslkeys.log"
```
In PowerShell waere es stattdessen `$env:SSLKEYLOGFILE = "$HOME\sslkeys.log"` - der einfachste Weg ist aber, alles in WSL zu machen.
2. Browser aus derselben Shell starten und HTTPS-Request erzeugen.
3. In Wireshark unter TLS-Preferences `sslkeys.log` als Key Log File setzen.
4. Mitschnitt erneut laden.
proxy/html/challenges.html
+42 -18
View File
@@ -176,6 +176,12 @@
</div>
</section>
<section class="panel">
<h2>Wo laufen die Kommandos? (Windows)</h2>
<p>Stack steuern geht aus PowerShell (<code>scripts/workshop.ps1</code>) <b>oder</b> WSL. Aber <b>alle</b> Test-Kommandos (<code>curl</code>, <code>openssl</code>, <code>grep</code>, <code>for</code>-Schleifen, <code>./scripts/compose.sh</code>) laufen im <b>WSL-Terminal (bash)</b>.</p>
<p><span class="kw">Warnung:</span> In PowerShell ist <code>curl</code> ein Alias fuer <code>Invoke-WebRequest</code> und versteht <code>-I</code>/<code>-k</code>/<code>--cacert</code> nicht. Immer im WSL-Terminal testen.</p>
</section>
<section class="panel">
<h2>Abgabe-Format</h2>
<ul>
@@ -196,8 +202,9 @@
<li>Welche <code>location</code> matched <code>/service/a</code>?</li>
<li>Welcher <code>upstream</code> wird verwendet?</li>
</ul>
<pre><code>curl http://localhost:8080/service/a
curl http://localhost:8080/service/b</code></pre>
<p><span class="kw">Zielzustand:</span> Du kannst Location &rarr; Upstream &rarr; Backend benennen und begruenden, warum A und B unterschiedlich antworten.</p>
<pre><code>curl http://localhost:8080/service/a # -&gt; "Target A"
curl http://localhost:8080/service/b # -&gt; "Target B"</code></pre>
</details>
<details id="challenge-2-backend-c">
@@ -205,16 +212,18 @@ curl http://localhost:8080/service/b</code></pre>
<p><span class="kw">Muss:</span> Compose-Service + Upstream + Route <code>/service/c</code>.</p>
<p><span class="kw">Zusatz:</span> <code>backends/c/index.html</code> ist vorhanden und darf angepasst werden.</p>
<p><span class="kw">Warum wichtig:</span> Neue Services kommen laufend dazu; Erweiterungen ohne Seiteneffekte sind Praxisalltag.</p>
<pre><code>curl http://localhost:8080/service/c
curl http://localhost:8080/service/a
curl http://localhost:8080/service/b</code></pre>
<p><span class="kw">Zielzustand:</span> <code>/service/c</code> liefert Backend C; A und B laufen unveraendert weiter.</p>
<pre><code>curl http://localhost:8080/service/c # -&gt; "Reverse Proxy Target C"
curl http://localhost:8080/service/a # -&gt; weiterhin "Target A"
curl http://localhost:8080/service/b # -&gt; weiterhin "Target B"</code></pre>
</details>
<details>
<summary><span class="badge easy">Easy</span> 3) Eigene Route /demo/a</summary>
<p><span class="kw">Muss:</span> Alias-Route bauen, die auf Backend A fuehrt.</p>
<p><span class="kw">Warum wichtig:</span> Der Proxy entkoppelt externe Pfade von internen Backend-Implementierungen.</p>
<pre><code>curl http://localhost:8080/demo/a</code></pre>
<p><span class="kw">Zielzustand:</span> <code>/demo/a</code> liefert dieselbe Antwort wie <code>/service/a</code>.</p>
<pre><code>curl http://localhost:8080/demo/a # -&gt; "Target A"</code></pre>
</details>
</section>
@@ -226,7 +235,9 @@ curl http://localhost:8080/service/b</code></pre>
<p>Setze mindestens <code>nosniff</code>, <code>DENY</code>, <code>strict-origin-when-cross-origin</code>, <code>Permissions-Policy</code>, <code>COOP</code>, <code>CORP</code>.</p>
<p><span class="kw">Optional:</span> CSP fuer statische Seiten.</p>
<p><span class="kw">Warum wichtig:</span> Diese Header reduzieren konkrete Browser-Angriffsvektoren und gehoeren zur Security-Baseline.</p>
<pre><code>curl -I http://localhost:8080/</code></pre>
<p><span class="kw">Fallstrick:</span> Header im <code>server {}</code>-Block setzen. Sobald in einem <code>location {}</code> ein <code>add_header</code> steht, verwirft Nginx dort <b>alle</b> Server-Header &rarr; dann erneut setzen.</p>
<p><span class="kw">Zielzustand:</span> <code>curl -I /</code> zeigt alle geforderten Security-Header.</p>
<pre><code>curl -I http://localhost:8080/ # -&gt; nosniff, DENY, Referrer-Policy, Permissions-Policy, COOP, CORP</code></pre>
</details>
<details>
@@ -234,25 +245,29 @@ curl http://localhost:8080/service/b</code></pre>
<p><span class="kw">Muss:</span> <code>/internal/status</code> nur fuer <code>127.0.0.1</code>.</p>
<p><span class="kw">Wichtig:</span> Host-Request zeigt typischerweise 403 (Docker-Netzwerk).</p>
<p><span class="kw">Warum wichtig:</span> Nicht jeder Endpoint darf oeffentlich erreichbar sein; Netzsegmentierung beginnt oft am Proxy.</p>
<pre><code>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"</code></pre>
<p><span class="kw">Zielzustand:</span> Host &rarr; 403; container-intern (127.0.0.1) &rarr; Antwort.</p>
<pre><code>curl -i http://localhost:8080/internal/status # -&gt; 403 (vom Host)
./scripts/compose.sh exec -T reverse-proxy sh -lc "wget -qO- http://127.0.0.1/internal/status" # -&gt; "internal ok"</code></pre>
</details>
<details>
<summary><span class="badge medium">Medium</span> 6) Logging verbessern</summary>
<p>Eigenes <code>log_format</code> mit Upstream-Infos einbauen.</p>
<p><span class="kw">Hinweis:</span> <code>log_format</code> gehoert in den <code>http {}</code>-Block, sonst startet Nginx nicht.</p>
<p><span class="kw">Warum wichtig:</span> Ohne brauchbare Logs dauert Fehleranalyse deutlich laenger und Incident-Response wird unzuverlaessig.</p>
<p><span class="kw">Zielzustand:</span> Log-Zeile im neuen Format mit Upstream-Infos (<code>upstream=...</code>, <code>urt=...</code>).</p>
<pre><code>curl http://localhost:8080/service/a
./scripts/compose.sh logs reverse-proxy</code></pre>
./scripts/compose.sh logs reverse-proxy # -&gt; neue Zeile mit upstream=... urt=...</code></pre>
</details>
<details>
<summary><span class="badge medium">Medium</span> 7) Load Balancing</summary>
<p>Zweite Instanz von Backend A (<code>backend-a2</code>) einbauen und Round-Robin zeigen.</p>
<p><span class="kw">Warum wichtig:</span> Lastverteilung ist Kernnutzen eines Reverse Proxys fuer Skalierung und Verfuegbarkeit.</p>
<p><span class="kw">Zielzustand:</span> Ueber mehrere Requests antworten <b>beide</b> Instanzen (Mischung aus A und A2).</p>
<pre><code>for i in $(seq 1 8); do
curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
done</code></pre>
curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
done # -&gt; Mischung aus "INSTANCE=A" und "INSTANCE=A2"</code></pre>
</details>
<details>
@@ -260,16 +275,19 @@ done</code></pre>
<p>Mindestens einen Backend-Response-Header per <code>proxy_hide_header</code> ausblenden.</p>
<p><span class="kw">Abgrenzung zu #4:</span> #4 setzt Schutz-Header, #8 entfernt unnoetige Header aus Upstream-Responses.</p>
<p><span class="kw">Warum wichtig:</span> Weniger preisgegebene Metadaten erschweren Fingerprinting und zielgerichtete Angriffe.</p>
<pre><code>curl -I http://localhost:8080/service/a</code></pre>
<p><span class="kw">Zielzustand:</span> Der ausgeblendete Header (z. B. <code>ETag</code>) fehlt jetzt in der Antwort.</p>
<pre><code>curl -I http://localhost:8080/service/a # -&gt; ETag/Last-Modified nicht mehr vorhanden</code></pre>
</details>
<details>
<summary><span class="badge medium">Medium</span> 9) Debugging Challenge</summary>
<p>Mit <code>proxy/nginx.broken.conf</code> arbeiten, Fehler finden und reparieren.</p>
<p><span class="kw">Zuerst sichern:</span> diese Challenge ueberschreibt deine <code>nginx.conf</code> &rarr; vorher <code>cp proxy/nginx.conf proxy/nginx.conf.bak</code>, am Ende zurueckkopieren.</p>
<p><span class="kw">Warum wichtig:</span> In der Praxis geht es oft um Diagnose unter Zeitdruck, nicht nur um Greenfield-Konfiguration.</p>
<p><span class="kw">Typische Fehler in der kaputten Datei:</span> Upstream-Name-Mismatch, falscher Port, fehlender Trailing Slash in <code>proxy_pass</code>.</p>
<pre><code>curl http://localhost:8080/service/a
curl http://localhost:8080/service/b
<p><span class="kw">Zielzustand:</span> Nach den Fixes liefern A und B wieder ihre Backends; Nginx startet fehlerfrei.</p>
<pre><code>curl http://localhost:8080/service/a # -&gt; "Target A"
curl http://localhost:8080/service/b # -&gt; "Target B"
./scripts/compose.sh logs reverse-proxy</code></pre>
</details>
</section>
@@ -280,22 +298,27 @@ curl http://localhost:8080/service/b
<details>
<summary><span class="badge hard">Hard</span> 10) HTTPS von 0 (Easy-RSA)</summary>
<p>Zertifikat fuer <code>localhost</code>, Port <code>8443:443</code>, Root-CA importiert.</p>
<p><span class="kw">Wichtig:</span> Der neue Port ist eine Compose-Aenderung &rarr; mit <code>make redeploy</code> deployen, nicht nur <code>make proxy-reload</code>.</p>
<p><span class="kw">Warum wichtig:</span> TLS-Grundaufbau ist Voraussetzung fuer vertrauliche und manipulationssichere Kommunikation.</p>
<pre><code>curl https://localhost:8443/service/a</code></pre>
<p><span class="kw">Zielzustand:</span> Aufruf liefert Backend A <b>ohne</b> <code>-k</code> (kein SAN-/Zertifikatsfehler). Zertifikat mit SAN signieren!</p>
<pre><code>curl https://localhost:8443/service/a # -&gt; Backend A, KEIN "SSL certificate problem"</code></pre>
</details>
<details>
<summary><span class="badge hard">Hard</span> 11) HTTP -&gt; HTTPS Redirect</summary>
<p><span class="kw">Voraussetzung:</span> Challenge 10 abgeschlossen. Bestehende Config weiterverwenden.</p>
<p><span class="kw">Warum wichtig:</span> Redirect verhindert unabsichtliche Klartext-Nutzung und erzwingt den sicheren Transport.</p>
<pre><code>curl -I http://localhost:8080/service/a</code></pre>
<p><span class="kw">Zielzustand:</span> HTTP auf <code>8080</code> antwortet mit <code>301</code> und <code>Location: https://localhost:8443/...</code>.</p>
<pre><code>curl -I http://localhost:8080/service/a # -&gt; 301, Location: https://localhost:8443/service/a</code></pre>
</details>
<details>
<summary><span class="badge hard">Hard</span> 12) TLS Haertung + Chain + HSTS</summary>
<p><span class="kw">Voraussetzung:</span> Challenge 10 und 11 abgeschlossen. Gleiche Config weiter erweitern.</p>
<p><span class="kw">Warum wichtig:</span> Erst Haertung + HSTS reduzieren Downgrade-Risiken und sorgen fuer dauerhaft sichere Clients.</p>
<pre><code>curl -I https://localhost:8443/service/a
<p><span class="kw">Warnung (HSTS-Falle):</span> Der Browser merkt sich HSTS host-weit fuer <code>localhost</code> (nicht pro Port). Nach <code>https://localhost:8443</code> wird auch <code>http://localhost:8080</code> auf https erzwungen. Zum Testen <code>curl</code> nutzen; Browser-HSTS ggf. unter <code>chrome://net-internals/#hsts</code> fuer <code>localhost</code> loeschen. <code>max-age</code> ist im Lab bewusst kurz (1h).</p>
<p><span class="kw">Zielzustand:</span> <code>curl -I</code> zeigt <code>Strict-Transport-Security</code>; <code>s_client</code> verhandelt TLSv1.2/1.3 mit <code>Verify return code: 0 (ok)</code>.</p>
<pre><code>curl -I https://localhost:8443/service/a # -&gt; enthaelt Strict-Transport-Security
openssl s_client -connect localhost:8443 -servername localhost</code></pre>
</details>
</section>
@@ -313,6 +336,7 @@ openssl s_client -connect localhost:8443 -servername localhost</code></pre>
<li>3-5 Bulletpoints: was ist sichtbar, was ist geschuetzt?</li>
</ol>
<p><span class="kw">Optional:</span> TLS Decrypt mit <code>SSLKEYLOGFILE</code>.</p>
<p><span class="kw">Zielzustand:</span> HTTP-Mitschnitt zeigt Pfad/Header im Klartext; HTTPS zeigt nur den Handshake, Nutzdaten ohne Key nicht lesbar.</p>
<p><span class="kw">Abgabe:</span> mind. 3 Screenshots + technische Interpretation.</p>
</details>
</section>
proxy/html/hints.html
+1 -1
View File
@@ -173,7 +173,7 @@ cd certs/easyrsa
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa gen-req localhost nopass
./easyrsa sign-req server localhost</code></pre>
./easyrsa --subject-alt-name="DNS:localhost,IP:127.0.0.1" sign-req server localhost</code></pre>
<p>Nur Runtime-Certs mounten (z. B. <code>certs/live</code>), nicht die komplette PKI.</p>
</article>
<article class="card">
proxy/html/index.html
+5 -1
View File
@@ -104,7 +104,7 @@
<section class="panel">
<h1>HTL Reverse Proxy & TLS Lab</h1>
<p>
Basis läuft mit HTTP. Ziel im Workshop: Reverse Proxy verstehen und HTTPS/TLS manuell
Basis laeuft mit HTTP. Ziel im Workshop: Reverse Proxy verstehen und HTTPS/TLS manuell
aufbauen.
</p>
<div class="top-links">
@@ -125,6 +125,10 @@
<li><code>curl http://localhost:8080/service/b</code></li>
<li><code>./scripts/compose.sh ps</code></li>
</ul>
<p>
<b>Windows:</b> Diese Kommandos im <b>WSL-Terminal (bash)</b> ausfuehren, nicht in PowerShell
(dort ist <code>curl</code> ein Alias fuer <code>Invoke-WebRequest</code>).
</p>
</section>
<section class="panel">
proxy/html/solutions.html
+18 -9
View File
@@ -215,7 +215,7 @@ location /service/c {
</details>
<details>
<summary><span class="badge easy">Easy</span> 3) Rewrite Route</summary>
<summary><span class="badge easy">Easy</span> 3) Alias-Route /demo/a</summary>
<p><span class="kw">Dateien:</span> <code>proxy/nginx.conf</code></p>
<p><span class="kw">Commands noetig:</span> ja</p>
<pre><code>location = /demo/a {
@@ -238,6 +238,7 @@ add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Resource-Policy "same-origin" always;</code></pre>
<p><span class="kw">Platzierung:</span> in den <code>server {}</code>-Block, damit alle Locations sie erben. Sobald eine Location ein eigenes <code>add_header</code> hat, verwirft Nginx dort die Server-Header und sie muessen wiederholt werden.</p>
<p><span class="kw">Optional CSP (statisch, inline styles erlaubt):</span></p>
<pre><code>add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'none'; frame-ancestors 'none'" always;</code></pre>
<p><span class="kw">Check:</span> <code>curl -I http://localhost:8080/</code></p>
@@ -262,6 +263,7 @@ add_header Cross-Origin-Resource-Policy "same-origin" always;</code></pre>
<summary><span class="badge medium">Medium</span> 6) Logging verbessern</summary>
<p><span class="kw">Dateien:</span> <code>proxy/nginx.conf</code></p>
<p><span class="kw">Commands noetig:</span> ja</p>
<p><span class="kw">Platzierung:</span> <code>log_format</code> muss in den <code>http {}</code>-Block (sonst startet Nginx nicht). <code>access_log</code> darf in <code>http</code>, <code>server</code> oder <code>location</code>.</p>
<pre><code>log_format workshop '$remote_addr - $request '
'status=$status upstream=$upstream_addr '
'rt=$request_time urt=$upstream_response_time';
@@ -289,8 +291,9 @@ access_log /var/log/nginx/access.log workshop;</code></pre>
}</code></pre>
<p><span class="kw">Check:</span></p>
<pre><code>for i in $(seq 1 8); do
curl -s http://localhost:8080/service/a | grep -o "Target A2\|Target A"
curl -s http://localhost:8080/service/a | grep -o "INSTANCE=[A-Za-z0-9]*"
done</code></pre>
<p><span class="kw">Marker:</span> Backend A/A2 enthalten unsichtbar <code>&lt;!-- INSTANCE=A --&gt;</code> bzw. <code>INSTANCE=A2</code>. <code>[A-Za-z0-9]*</code> matched das ganze Token (kein Prefix-Problem A vs. A2).</p>
</details>
<details>
@@ -298,6 +301,7 @@ done</code></pre>
<p><span class="kw">Dateien:</span> <code>proxy/nginx.conf</code></p>
<p><span class="kw">Commands noetig:</span> ja</p>
<p><span class="kw">Abgrenzung zu #4:</span> #4 fuegt Schutz-Header hinzu, #8 entfernt unnoetige Upstream-Metadaten.</p>
<p><span class="kw">Gut zu wissen:</span> <code>proxy_hide_header</code> ist kein <code>add_header</code> &rarr; es loest die Vererbungsfalle aus #4 nicht aus. Die Server-Header bleiben in dieser Location erhalten.</p>
<pre><code>location /service/a {
proxy_pass http://backend_a/;
proxy_hide_header ETag;
@@ -310,10 +314,14 @@ done</code></pre>
<summary><span class="badge medium">Medium</span> 9) Debugging Challenge</summary>
<p><span class="kw">Dateien:</span> <code>proxy/nginx.broken.conf</code>, <code>proxy/nginx.conf</code></p>
<p><span class="kw">Commands noetig:</span> ja</p>
<p><span class="kw">Ablauf:</span> Kopiere testweise <code>proxy/nginx.broken.conf</code> auf <code>proxy/nginx.conf</code>, behebe die Fehler und stelle danach die funktionierende Konfiguration wieder her.</p>
<pre><code>cp proxy/nginx.broken.conf proxy/nginx.conf
<p><span class="kw">Ablauf:</span> Zuerst die eigene Config sichern (diese Challenge ueberschreibt sie!), dann die kaputte aktivieren, Fehler beheben und am Ende die eigene Config wiederherstellen.</p>
<pre><code>cp proxy/nginx.conf proxy/nginx.conf.bak # 1. eigene Config sichern
cp proxy/nginx.broken.conf proxy/nginx.conf # 2. kaputte aktivieren
make proxy-reload
./scripts/compose.sh logs reverse-proxy</code></pre>
./scripts/compose.sh logs reverse-proxy # 3. Fehler finden + fixen</code></pre>
<p><span class="kw">Am Ende eigene Config zurueck:</span></p>
<pre><code>cp proxy/nginx.conf.bak proxy/nginx.conf
make proxy-reload</code></pre>
<p><span class="kw">Konkrete Fehler und Fixes:</span></p>
<ol>
<li><span class="kw">Upstream-Mismatch:</span> <code>backend_a_typo</code> ist definiert, aber <code>backend_a</code> wird referenziert -> Namen angleichen.</li>
@@ -340,15 +348,16 @@ cd certs/easyrsa
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa gen-req localhost nopass
./easyrsa sign-req server localhost</code></pre>
./easyrsa --subject-alt-name="DNS:localhost,IP:127.0.0.1" sign-req server localhost</code></pre>
<p><span class="kw">Compose:</span></p>
<pre><code>reverse-proxy:
ports:
- "8080:80"
- "8443:443"
- "${HTTP_PORT:-8080}:80"
- "${HTTPS_PORT:-8443}:443"
volumes:
- ./certs/live:/etc/nginx/certs:ro,z</code></pre>
<p><span class="kw">Wichtig:</span> Nicht die komplette PKI in den Container mounten. Nur Runtime-Zertifikat + Key bereitstellen.</p>
<p><span class="kw">Deploy:</span> Port- und Volume-Aenderungen sind Compose-Aenderungen &rarr; <code>make redeploy</code> (nicht <code>make proxy-reload</code>), sonst greift der neue Port nicht.</p>
<p><span class="kw">Nginx TLS-Pfade:</span> <code>ssl_certificate /etc/nginx/certs/localhost.crt;</code> und <code>ssl_certificate_key /etc/nginx/certs/localhost.key;</code></p>
<p><span class="kw">Check:</span> <code>curl https://localhost:8443/service/a</code> (ohne <code>-k</code> nach CA-Import)</p>
</details>
@@ -381,7 +390,7 @@ cd certs/easyrsa
<p><span class="kw">Commands noetig:</span> ja</p>
<pre><code>ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;</code></pre>
add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;</code></pre>
<p><span class="kw">Check:</span></p>
<pre><code>curl -I https://localhost:8443/service/a
openssl s_client -connect localhost:8443 -servername localhost</code></pre>
proxy/nginx.tls.example.conf
+4 -1
View File
@@ -39,7 +39,10 @@ http {
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# max-age im Lab bewusst kurz (1h). In Produktion eher 1 Jahr (31536000).
# includeSubDomains weitet HSTS auf alle Subdomains aus (Produktions-Best-Practice).
# Achtung: HSTS bleibt im Browser host-weit haengen -> siehe Warnhinweis in Challenge 12.
add_header Strict-Transport-Security "max-age=3600; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;