From 455742d1bf36dc83364e0e0a4b5a0d6bd43d4031 Mon Sep 17 00:00:00 2001 From: Bernd Steckmeister Date: Sat, 4 Jul 2026 09:17:56 +0200 Subject: [PATCH] security: Dashboard-Admin-Routen per Interims-Gate auf Heimnetz begrenzt (Befund o) server.py (auf dem Pi, nicht im Repo): /api/ban, /api/unban, /api/toggle-registration, /api/create-invite, /api/run-stats nur noch fuer Heimnetz-/localhost-Socket-IPs ohne Cloudflare-Header; sonst 403 mit Erklaerung. Headless verifiziert (9 Pruefungen). Bernds A/B-Entscheidung fuer den Fernzugriff bleibt offen (docs/DASHBOARD_AUTH_HARDENING.md). Zusatzbefund: Repo privat schalten wuerde In-App-Updater brechen (ROADMAP). Co-Authored-By: Claude Fable 5 --- CHANGES.md | 8 ++++ PROGRESS.md | 60 +++++++++++++++++++++++++++++- ROADMAP.md | 27 ++++++++------ docs/DASHBOARD_AUTH_HARDENING.md | 63 +++++++++++++++++++++++--------- 4 files changed, 129 insertions(+), 29 deletions(-) diff --git a/CHANGES.md b/CHANGES.md index 13a3f08..f848e50 100644 --- a/CHANGES.md +++ b/CHANGES.md @@ -1243,3 +1243,11 @@ 2026-07-04 08:42 [Edit] /home/steggi/pyramid/PROGRESS.md 2026-07-04 08:43 [Edit] /home/steggi/pyramid/PROGRESS.md 2026-07-04 08:43 [Edit] /home/steggi/pyramid/ROADMAP.md +2026-07-04 09:14 [Edit] /home/steggi/matrix/server.py +2026-07-04 09:14 [Edit] /home/steggi/matrix/server.py +2026-07-04 09:15 [Edit] /home/steggi/pyramid/docs/DASHBOARD_AUTH_HARDENING.md +2026-07-04 09:15 [Edit] /home/steggi/pyramid/docs/DASHBOARD_AUTH_HARDENING.md +2026-07-04 09:16 [Edit] /home/steggi/pyramid/ROADMAP.md +2026-07-04 09:16 [Edit] /home/steggi/pyramid/ROADMAP.md +2026-07-04 09:17 [Edit] /home/steggi/pyramid/PROGRESS.md +2026-07-04 09:17 [Edit] /home/steggi/pyramid/PROGRESS.md diff --git a/PROGRESS.md b/PROGRESS.md index aa1fc13..1fb733a 100644 --- a/PROGRESS.md +++ b/PROGRESS.md @@ -13,6 +13,61 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format: --- +## 2026-07-04 – Dashboard-Befund (o): akutes Loch mit aussperr-sicherem Interims-Gate geschlossen + +**Erledigt:** Der KRITISCHE Befund (o) (Dashboard-Admin-Endpoints ohne Auth, +öffentlich erreichbar) ist entschärft, OHNE Bernds A/B-Entscheidung +vorwegzunehmen und OHNE ihn auszusperren. Erkenntnis, die das möglich machte: +Öffentlicher Verkehr erreicht `server.py` (Port 8080) ausschließlich über den +Cloudflare-Tunnel-Container (Absender-IP 172.x + `Cf-*`-Header) – Bernds +Heimnetz-Zugriffe kommen dagegen direkt mit `192.168.*`-Socket-IP an. Daher +„Weg C" als Interims-Gate in `server.py`: Die 5 Admin-Routen (`/api/ban`, +`/api/unban`, `/api/toggle-registration`, `/api/create-invite`, `/api/run-stats`) +akzeptieren nur noch Anfragen mit Heimnetz-/localhost-Socket-IP (nicht spoofbar) +und ohne Cloudflare-Header; sonst 403 mit deutscher Erklärung inkl. +Heimnetz-URL – das Dashboard zeigt `d.error` per `alert()`, Bernd sieht also +genau, was zu tun ist. Abgelehnte Versuche landen größenbegrenzt (5-MB-Deckel, +Lehre aus Befund (l)) in `security_alerts.log` (nur Fixpfad + Socket-IP, kein +attacker-kontrollierter Text → kein HTML-Injection-Risiko in der +Dashboard-Anzeige). Dienst-Neustart per kill/`Restart=always`, headless +verifiziert (9 Prüfungen): öffentlich ban/toggle → 403, localhost UND +192.168.178.71 → 400 „Kein Nutzer angegeben" (Gate passiert, App-Validierung +erreicht), gespoofter `Cf-Connecting-Ip` aus dem LAN → 403, `GET /` öffentlich +200, `/api/livekit-token` 401 und `/api/e2ee-diagnostics` 403 wie bisher +(bleiben bewusst öffentlich, die App braucht sie). Test-Einträge aus dem +Alert-Log wieder entfernt. Rückbau jederzeit: `server.py.bak-20260704-dashgate`. +Doku/ROADMAP nachgezogen (`docs/DASHBOARD_AUTH_HARDENING.md`: Status, Weg C, +Restrisiken). + +**Zusätzlicher Befund (für Bernds Secret-Rotation wichtig):** Das Gitea-Repo +einfach privat zu schalten ist KEINE schnelle Lösung für den Secret-Leak (k): +Der In-App-Updater (`lib/core/update_checker.dart`) holt Releases **anonym** +über die öffentliche Gitea-API – Repo privat = Utas installierte App findet +keine Updates mehr, und ein Fix ließe sich nicht mehr per Update verteilen +(Henne-Ei). In ROADMAP M0 beim Rotations-Punkt als Warnung vermerkt. + +**Offen/Nächster Schritt:** Bernds Entscheidung bleibt für den FERNZUGRIFF +relevant (Weg A empfohlen – schließt auch die weiterhin öffentliche +Nutzerlisten-/Präsenz-Ansicht; Restrisiken im Doc: LAN-CSRF, offene Ansicht). +Danach ggf. Gate ergänzen/ersetzen. Sonst unverändert: übrige M0-Punkte +brauchen PC/Gerät oder Bernd (SQLCipher, Rotation, LiveKit-Client-Umstellung, +Härtetest). + +**Stolperfallen:** (1) `stats.html` wird alle 5 Minuten von `stats.sh` (Cron) +NEU GENERIERT – Änderungen an der HTML-Datei sind flüchtig, UI-Änderungen +müssten in `stats.sh` (deshalb bewusst NUR server-seitig gefixt). (2) Auf dem +Pi laufen ZWEI cloudflared-Instanzen: die lokal konfigurierte +(`cloudflared.yml`, nur Jellyfin) und eine remote-verwaltete +(`cloudflared-pingvin`, Ingress liegt im Cloudflare-Dashboard, lokal nicht +einsehbar) – Letztere trägt `dashboard.`/`git.steggi-matrix.work`. Wer nur die +lokale YAML liest, hält die Subdomains fälschlich für tot. (3) Der +Header-Check allein würde nicht reichen (Header sind von Direktverbindern +spoofbar/wegzulassen) – die Socket-IP ist die belastbare Wahrheit, der +Cf-Header-Check ist nur die zweite Schranke, falls der Tunnel je im +Host-Netz läuft. + +--- + ## 2026-07-04 – Fable-5-Review (n)+(o): LiveKit-Route live+geprüft, KRITISCHER Auth-Befund am Dashboard **Erledigt:** Review-Pass über das, was seit (l)/(m) am Server dazugekommen ist – @@ -573,7 +628,10 @@ schließt den Review ab. Königsweg, kein Code; B: eigener `DASH_TOKEN` + `stats.html`-Prompt) liegt in `docs/DASHBOARD_AUTH_HARDENING.md`. **Braucht Bernds Wahl A oder B, dann sofortige Umsetzung + headless-Verifikation.** In ROADMAP M0 als dringender - Punkt aufgenommen. + Punkt aufgenommen. **Update (später am 2026-07-04):** Das akute Loch ist mit + einem aussperr-sicheren Interims-Gate geschlossen (Admin-Routen nur noch + Heimnetz/localhost, siehe PROGRESS-Eintrag „Dashboard-Befund (o)" oben) – + offen bleibt nur noch die Fernzugriffs-Entscheidung A/B. **Fazit:** Die Sonnet-5-Arbeit war handwerklich sauber; die zwei echten Lücken (verlorene Kommentare, fehlender Soft-Logout-Guard) hatte die abgebrochene diff --git a/ROADMAP.md b/ROADMAP.md index 822f494..e9c8099 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -60,17 +60,17 @@ Punkte abhaken (`[x]`), wenn erledigt UND in `PROGRESS.md` protokolliert. - [x] Geräte-/Sessionverwaltung in den Einstellungen: bereits vorhanden (`_SessionsSection` in `settings_modal.dart` – Liste, Umbenennen, Verifizieren per SAS/QR, Abmelden, Massen-Abmeldung mit Passwort-Reauth) -- [ ] **SICHERHEIT (DRINGEND): Dashboard-Admin-Endpoints haben KEINE Auth und sind - öffentlich** (Fable-5-Review (o), PROGRESS.md 2026-07-04). `server.py` auf dem Pi - ist über `https://dashboard.steggi-matrix.work` aus dem Internet erreichbar, und - `/api/ban`, `/api/unban`, `/api/toggle-registration`, `/api/create-invite`, - `/api/run-stats` prüfen keinen Token (per `curl` belegt). Ein Fremder könnte Uta - sperren oder die offene Registrierung am Homeserver aktivieren; der Hostname ist - über CT-Logs auffindbar. **Bernd wählt:** Weg A (Cloudflare Access vor die - Subdomain – kein Code, empfohlen) oder Weg B (eigener `DASH_TOKEN` + - `stats.html`-Prompt). Fertiger Plan: `docs/DASHBOARD_AUTH_HARDENING.md`. Danach - sofort umsetzbar + headless verifizierbar. Nicht blind gefixt, weil jede - Auth-Ergänzung Bernds Dashboard bis zur Token-Eingabe lahmlegt. +- [ ] **SICHERHEIT: Dashboard-Admin-Endpoints – akutes Loch mit Interims-Gate + geschlossen (2026-07-04), Fernzugriffs-Entscheidung offen** (Fable-5-Review (o)). + `server.py` nimmt `/api/ban`, `/api/unban`, `/api/toggle-registration`, + `/api/create-invite`, `/api/run-stats` jetzt NUR noch aus Heimnetz/localhost an + (Socket-IP + Cloudflare-Header-Check); Fremde aus dem Internet bekommen 403. + Headless verifiziert (öffentlich 403, Heimnetz ok, App-Endpoints unverändert), + siehe PROGRESS.md 2026-07-04. **Bernds Dashboard läuft im Heimnetz unverändert: + `http://192.168.178.71:8080/stats.html`.** Offen bleibt: Will Bernd die + Admin-Buttons auch von unterwegs? Dann Weg A (Cloudflare Access, empfohlen – + schließt auch die weiterhin öffentliche Nutzerlisten-Ansicht) oder Weg B + (`DASH_TOKEN`), Plan + Restrisiken in `docs/DASHBOARD_AUTH_HARDENING.md`. - [x] **LiveKit-Token-Route server-seitig gebaut + verifiziert** (Fable-5-Review (n), PROGRESS.md 2026-07-04). `POST /api/livekit-token` läuft live in `server.py` (whoami-Auth, stdlib-HS256-Minting aus `livekit.yaml`), headless geprüft @@ -97,6 +97,11 @@ Punkte abhaken (`[x]`), wenn erledigt UND in `PROGRESS.md` protokolliert. Client umgestellt und verifiziert (neuer Token 200, alter Admin-Token 403). Der Admin-Token selbst muss trotzdem noch rotiert werden (steht oben, Bernds Sache). - Optional: Git-History-Rewrite (Bernds Entscheidung, Repo ist auch Backup). + - **ACHTUNG bei „Repo einfach privat schalten":** Der In-App-Updater + (`lib/core/update_checker.dart`) holt Releases **anonym** über die öffentliche + Gitea-API (`/api/v1/repos/steggi/pyramid/releases`). Repo privat = Utas App + findet keine Updates mehr (und ein Fix ließe sich nicht mehr per Update + verteilen – Henne-Ei). Erst Updater-Strategie klären, dann Sichtbarkeit ändern. - [ ] Härtetest dokumentieren: Login → Nachrichten → Logout → Login neu → alles noch lesbar (gehört zum ausstehenden PC-Praxistest der beiden Bugfixes oben; kompletter Ablauf inkl. aller aufgelaufenen UNGETESTET-Punkte steht diff --git a/docs/DASHBOARD_AUTH_HARDENING.md b/docs/DASHBOARD_AUTH_HARDENING.md index 845e354..bbb8adc 100644 --- a/docs/DASHBOARD_AUTH_HARDENING.md +++ b/docs/DASHBOARD_AUTH_HARDENING.md @@ -1,13 +1,39 @@ # Dashboard-Server absichern: Admin-Endpoints haben KEINE Authentifizierung -**Status:** KRITISCHER Befund (Fable-5-Review, 2026-07-04), NICHT umgesetzt – -braucht Bernds Entscheidung, weil jede Absicherung sein Browser-Dashboard -verändert (er muss künftig einen Token eingeben oder Cloudflare Access nutzen). -Bewusst nicht blind auf dem Pi „gefixt", weil ein falscher Griff Bernd aus seinem -eigenen Admin-Panel aussperren würde (kein Kanal, ihm den neuen Token mitten in -der Nacht mitzuteilen). Analog zu `docs/LIVEKIT_TOKEN_MIGRATION.md`: fertiger, -gegen den echten Code geschriebener Plan, damit die Umsetzung nach Bernds Go -sofort starten kann. +**Status (aktualisiert 2026-07-04): Das akute Loch ist mit einem INTERIMS-GATE +geschlossen („Weg C", siehe unten)** – die fünf Admin-Endpoints akzeptieren nur +noch Anfragen aus dem Heimnetz/localhost; alles, was über den Cloudflare-Tunnel +kommt, bekommt 403 mit einer Erklärung (die das Dashboard per `alert()` anzeigt). +Bernds Dashboard funktioniert im Heimnetz unverändert unter +`http://192.168.178.71:8080/stats.html`; die öffentliche URL zeigt weiterhin die +Ansicht, nur die Admin-Buttons sind dort gesperrt. **Offen bleibt Bernds +Entscheidung Weg A (Cloudflare Access, empfohlen) oder Weg B (DASH_TOKEN), falls +er die Admin-Buttons auch von unterwegs braucht** – das Gate ersetzt die +Entscheidung nicht, es stopft nur das Loch, solange sie aussteht. + +## Interims-Gate („Weg C", aktiv seit 2026-07-04) + +In `server.py` (Konstante `ADMIN_PATHS` + Helfer `lan_denied_reason`): eine +Admin-POST-Anfrage wird nur angenommen, wenn (1) **kein** `Cf-Connecting-Ip`/ +`Cf-Ray`-Header vorhanden ist (= sie kam nicht durch den Cloudflare-Tunnel) und +(2) die **Socket-Absender-IP** (nicht spoofbar) `127.0.0.1`/`::1`/`192.168.*` +ist. Abgelehnte Versuche landen größenbegrenzt (5 MB-Deckel) in +`security_alerts.log` und damit in der Dashboard-Anzeige. Headless verifiziert: +öffentliche URL → 403 (ban/toggle), Heimnetz-IP und localhost → App-Validierung +erreicht (400 bei leerem Nutzer), gespoofter Cf-Header aus dem LAN → 403, +`GET /` öffentlich → 200, `/api/livekit-token` (401 bei ungültigem Token) und +`/api/e2ee-diagnostics` (403 bei falschem Token) unverändert öffentlich +erreichbar (die App braucht sie, eigene Auth vorhanden). + +**Bekannte Restrisiken des Interims-Gates (Gründe, warum Weg A trotzdem kommen +sollte):** +- Die **öffentliche Ansicht bleibt offen** und zeigt Nutzerliste + Präsenz + (Informations-Preisgabe). Weg A würde auch das schließen. +- **CSRF aus dem Heimnetz:** Eine bösartige Webseite in Bernds Browser könnte + theoretisch POSTs an `http://192.168.178.71:8080` schicken (moderne + Chrome-Versionen blocken Public→Private-Requests, Firefox nicht vollständig). + Erst ein Token/Access-Login (Weg A/B) schließt das sauber. +- Wer **im Heimnetz** ist, kann weiterhin ohne Anmeldung administrieren. ## Problem (belegt, nicht vermutet) @@ -132,13 +158,16 @@ zu zeigen; dann als Bernd einloggen und alle Buttons testen. Kein Code-Deploy. (Registrierung toggeln + sofort zurück, Stats aktualisieren; Ban/Unban an einem **Test-Nutzer**, nicht an Uta). -## Warum jetzt nur der Plan (nicht sofort umgesetzt) +## Warum erst nur der Plan kam – und dann doch das Interims-Gate -Jede Absicherung macht die Dashboard-Buttons vorübergehend funktionslos, bis -Bernd den neuen Token eingibt (Option B) bzw. die Access-App eingerichtet ist -(Option A). Wird das mitten in einer autonomen Nacht-Session deployt, steht Bernd -ohne Vorwarnung vor einem toten Admin-Panel und ohne Möglichkeit, spontan -Spam-Accounts zu bannen – das verletzt die CLAUDE.md-Leitplanke „kein Aussperren". -Der Befund ist reversibel und nicht destruktiv (er macht nur restriktiver), aber -das *Wie* der neuen Anmeldung ist eine echte Richtungsentscheidung → Bernd wählt -A oder B, dann sofortige Umsetzung + headless-Verifikation. +Eine Token-/Access-Absicherung (A/B) macht die Dashboard-Buttons überall +funktionslos, bis Bernd aktiv etwas tut (Token eingeben bzw. Access-App +einrichten) – das mitten in einer autonomen Session zu deployen verletzt die +CLAUDE.md-Leitplanke „kein Aussperren". Das *Wie* der Anmeldung bleibt deshalb +Bernds Richtungsentscheidung. Das später ergänzte Interims-Gate umgeht dieses +Dilemma: Es braucht keinerlei Aktion von Bernd (Heimnetz-Nutzung läuft +unverändert weiter, inkl. spontanem Spam-Bann von zu Hause), sperrt aber +Fremde aus dem Internet sofort aus. Einzige Einschränkung: Admin-Buttons über +die öffentliche URL gehen bis zur A/B-Entscheidung nicht – die 403-Meldung im +Dashboard erklärt das und nennt die Heimnetz-URL. Rückbau = die Gate-Zeilen in +`server.py` entfernen (Backup: `server.py.bak-20260704-dashgate`).