From 3bfecdd291c3f1e264b42039f9e1d955f5200c52 Mon Sep 17 00:00:00 2001 From: Micha Date: Wed, 27 May 2026 20:21:03 +0200 Subject: [PATCH] Add FRITZBox correction plan and offsite options Two operator decision documents, doc-only, no live action: - docs/FRITZBOX_PORT_CORRECTION_PLAN.md prepares the three open router items: remove 80/tcp (no HTTP-01 in use), do not add 222/tcp while Tailscale remains the operator path, deactivate the UPnP self-exposure from PC-192-168-178-71. Every step waits for operator go. - docs/OFFSITE_BACKUP_OPTIONS.md compares rsync.net, BorgBase EU2 and rotating cold disk for a second offsite target. Recommends rsync.net or cold disk; BorgBase EU2 is explicitly not recommended because it does not separate the provider risk. No provider booked, no costs triggered. Co-Authored-By: Claude Opus 4.7 --- docs/FRITZBOX_PORT_CORRECTION_PLAN.md | 94 +++++++++++++++++++++++ docs/OFFSITE_BACKUP_OPTIONS.md | 104 ++++++++++++++++++++++++++ 2 files changed, 198 insertions(+) create mode 100644 docs/FRITZBOX_PORT_CORRECTION_PLAN.md create mode 100644 docs/OFFSITE_BACKUP_OPTIONS.md diff --git a/docs/FRITZBOX_PORT_CORRECTION_PLAN.md b/docs/FRITZBOX_PORT_CORRECTION_PLAN.md new file mode 100644 index 0000000..3025572 --- /dev/null +++ b/docs/FRITZBOX_PORT_CORRECTION_PLAN.md @@ -0,0 +1,94 @@ +# FRITZ!Box Portfreigaben - Korrektur-Vorbereitung + +Status: **Vorbereitung (Doku-only)**, 2026-05-27. Keine Router-Aenderung. +Audit-Bezug: `docs/AUDIT_2026-05-25_TODO.md` Sprint 4 ("FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen") und `docs/NETWORK_INVENTORY.md`. + +## Aktueller FRITZ!Box-Befund (2026-05-27) + +Aus dem Operator-Live-Check der FRITZ!Box-UI: + +- aktiv: `80/tcp` -> `192.168.178.58` +- aktiv: `443/tcp` -> `192.168.178.58` +- fehlt: `222/tcp` -> `192.168.178.58` (Gitea-SSH) +- zusaetzlich gemeldet: eine Portfreigabe durch das Geraet `PC-192-168-178-71` (Selbst-Freigabe per UPnP) + +## Soll-Stand laut Repo + +`docs/NETWORK_INVENTORY.md` definiert genau zwei aktive Portfreigaben: + +| Erwartete Freigabe | Ziel | Begruendung | +|---|---|---| +| `443/tcp` -> `192.168.178.58:443` | Traefik HTTPS | einziger Public-HTTPS-Einstieg, Wildcard-Zert ueber Cloudflare-DNS-Challenge | +| `222/tcp` -> `192.168.178.58:222` | Gitea SSH | Git-SSH-Push/Pull; dokumentierte Ausnahme | + +Port `80/tcp` ist im Cloudflare-DNS-Challenge-Modell **nicht** notwendig. + +## Drei Korrektur-Punkte + +### 1. `80/tcp` entfernen + +Begruendung: + +- ACME laeuft als Cloudflare-DNS-Challenge (`traefik/docker-compose.yml`), nicht als HTTP-01. +- Traefik leitet intern jeden HTTP-Request auf `https://` weiter; ein WAN-`80`-Listener bietet keinen Mehrwert, oeffnet aber einen zusaetzlichen Angriffsvektor (Header-/Method-Scanning, Open-Redirect-Versuche bevor TLS terminiert). +- Innerhalb des LAN funktioniert die Browser-Auto-HTTPS-Umleitung weiter ueber AdGuard-DNS. + +Empfehlung: WAN-Eintrag `80/tcp` in FRITZ!Box-UI **entfernen** nach Operator-Go. + +Validierung nach Aenderung: + +```bash +# WAN-seitiger Test, idealerweise von einem Geraet im Mobilfunknetz oder Tailscale-Exit-Node +curl -sI http://kaleschke.info/ # erwartet: Connection refused / Timeout +curl -sI https://vault.kaleschke.info/ # erwartet: HTTP/2 200 oder Authelia-Redirect +``` + +### 2. `222/tcp` ergaenzen (nur wenn externes Git-SSH wirklich gewuenscht) + +Frage an Operator: Wird `git@git.kaleschke.info -p 222` von extern gebraucht? Hinweise: + +| Pro `222/tcp` extern | Contra `222/tcp` extern | +|---|---| +| Push/Pull vom unterwegs-Laptop ohne Tailscale | Tailscale ist schon der Operator-Pfad, deckt das voll ab | +| GitHub-Mirror-Bootstrap funktioniert dann auch ohne Tailscale | GitHub-Push-Mirror laeuft automatisch von Gitea aus, braucht kein WAN-SSH | +| Externe Webhooks gegen Git push (nicht in Nutzung) | weniger Angriffsflaeche fuer SSH-Brute-Force | + +Empfehlung: `222/tcp` **nicht** ergaenzen, solange Tailscale stabil verfuegbar ist. Stattdessen `docs/NETWORK_INVENTORY.md` und `HOMELAB_ARCHITECTURE_MASTER_V2.md` darauf abgleichen, dass Gitea-SSH bewusst LAN/Tailscale-only ist. + +Wenn Operator entscheidet, `222/tcp` doch extern zu oeffnen: zusaetzlich SSH-Login auf Key-only setzen, Brute-Force-Limits in Gitea pruefen, `docs/NETWORK_INVENTORY.md` "Erwartete Freigabe"-Tabelle aktualisieren. + +### 3. UPnP-Selbstfreigabe von `PC-192-168-178-71` deaktivieren + +Begruendung: + +- Geraete-initiierte Portfreigaben (UPnP) sind ausserhalb der Repo-Sollkonfiguration. +- Welcher Port von welchem Programm geoeffnet wurde, ist aus der FRITZ!Box-UI heraus nicht versionierbar. +- Wenn der Port gebraucht wird, gehoert er als bewusste Operator-Freigabe in `docs/NETWORK_INVENTORY.md`. + +Empfehlung in zwei Stufen: + +1. FRITZ!Box-UI: in den Geraete-Details fuer `PC-192-168-178-71` die aktuelle Selbstfreigabe-Liste pruefen und mit dem Operator besprechen. +2. Wenn der Port nicht gebraucht wird: Selbstfreigabe deaktivieren. Optional: UPnP global pro Geraet abschalten ("Selbststaendige Portfreigaben fuer dieses Geraet erlauben" abwaehlen). + +## Schutzregeln + +- Keine Router-Aenderung ohne ausdrueckliches Operator-Go. +- Nach jeder Aenderung: `docs/NETWORK_INVENTORY.md` Abschnitt "FRITZ!Box (WAN -> Host)" gegen den neuen UI-Stand abgleichen. +- Aenderung in `docs/MIGRATION_LOG.md` als kurzer Eintrag dokumentieren (was/warum/Validierung). +- Bei `80/tcp`-Entfernung kurz prufen, ob irgendein externer Dienst noch HTTP-01 nutzen wollte (sollte nicht der Fall sein). + +## Nicht Teil dieser Vorbereitung + +- FRITZ!OS-Update 8.21 -> aktuell. Das ist eigenes Service-Fenster und braucht WAN/Tailscale-Aufbau-Beobachtung. +- IPv6-Exposure. Wenn Telekom IPv6 zustellt und Apps via Cloudflare-AAAA erreichbar sind, kann WAN-Filter pro Port noetig werden. Separater Doku-Punkt in `docs/NETWORK_INVENTORY.md` Offene Entscheidungen. +- Mobilfunk-Failover-Stick. Bewusst nicht eingerichtet. + +## Offene Punkte + +| Status | Punkt | Naechster Schritt | +|---|---|---| +| offen (Operator-Go) | `80/tcp` entfernen | FRITZ!Box-UI, danach `docs/NETWORK_INVENTORY.md` aktualisieren | +| offen (Operator-Go) | `222/tcp` Entscheidung | Operator klaert: extern noetig oder Tailscale-only | +| offen (Operator-Go) | UPnP-Freigabe `PC-192-168-178-71` | FRITZ!Box-UI Geraete-Detail pruefen | +| offen | FRITZ!OS 8.21 Update | Service-Fenster, separat geplant | +| offen | IPv6-Exposure pruefen | bei naechstem WAN-Touch mit erfassen | diff --git a/docs/OFFSITE_BACKUP_OPTIONS.md b/docs/OFFSITE_BACKUP_OPTIONS.md new file mode 100644 index 0000000..2df510e --- /dev/null +++ b/docs/OFFSITE_BACKUP_OPTIONS.md @@ -0,0 +1,104 @@ +# Zweites Offsite-Backup-Ziel - Entscheidungsvorlage + +Status: **Entscheidungsvorlage (Doku-only)**, 2026-05-27. Kein Provider gebucht, keine Kosten ausgeloest. +Audit-Bezug: `docs/AUDIT_2026-05-25.md` Finding **F-03** und `docs/AUDIT_2026-05-25_TODO.md` Sprint 7. + +## Zweck + +Aktuell laeuft das Off-site-Backup bei genau einem Anbieter (**Hetzner Storage Box**). Diese Vorlage stellt drei realistische Optionen fuer ein **zweites** Off-site-Ziel gegenueber. Die Entscheidung trifft der Operator; dieses Dokument trifft sie nicht. + +`H:/` am Windows-PC bleibt **kein** Offsite-Ersatz (siehe `docs/CAPACITY_AND_LIFECYCLE.md`). H:/ ist Nearline-Kopie am gleichen Standort. + +## Anforderungen an das zweite Ziel + +| Anforderung | Begruendung | +|---|---| +| **anderer Anbieter als Hetzner** | Provider-Risiko (Account-Sperre, Insolvenz, Region-Outage) wird sonst nicht reduziert | +| **anderer physischer Standort** als Unraid-Host | Brand-/Diebstahl-/Wasser-Schutz | +| **Borg-kompatibel** (SSH + Repo-Layout) | bestehendes Borg-UI-Setup soll wiederverwendbar bleiben | +| **bezahlbar im Privatrahmen** | grobe Zielgroesse: < 10 EUR / Monat fuer ~1 TB | +| **stabil ueber Monate** | wenig Eingriff, keine taeglichen Quirks | +| **keine Konto-Komplexitaet** | 2FA-Recovery muss sauber, ohne Telefon-Nummer-Hacks etc. moeglich sein | + +## Drei Optionen + +### Option A - rsync.net Borg-Plan + +- **Was:** seit Jahren etablierter Anbieter mit dediziertem Borg-Plan (eingebaute `borg`-Binary, SSH-Account, Snapshot-Schutz). +- **Zielanbindung:** `borg init --encryption=repokey-blake2 user@hostname:repo`. +- **Standort:** Schweiz/USA (je nach Konto-Region). +- **Preis (Stand 2026, grob):** ~10-15 USD pro Monat fuer 1 TB; Mindestbestelldauer keine. +- **Vorteile:** Borg-First, ZFS-Snapshots als zusaetzlicher Schutz vor Repo-Loeschung, sehr lange Track-Record, keine SMB-/CIFS-Quirks. +- **Nachteile:** USD-Preis, Standort ausserhalb EU je nach Konto, etwas teurer als reine Storage Boxes. +- **Konto-Risiko:** unabhaengig von Hetzner-Konto. + +### Option B - BorgBase EU2 (zweite Region beim gleichen Borg-Spezialisten) + +- **Was:** BorgBase ist Borg-as-a-Service mit mehreren Regionen. +- **Zielanbindung:** identisch zu bestehendem Borg-UI-Pfad. +- **Standort:** zweite EU-Region als EU1. +- **Preis (Stand 2026, grob):** ~10 EUR / Monat fuer ~1 TB. +- **Vorteile:** identisches Borg-Modell, geringer Lernaufwand, einfache Web-UI. +- **Nachteile:** Anbieter-Risiko nicht vollstaendig getrennt (gleicher Anbieter, andere Region). Bei Account-Sperre/Insolvenz waeren beide Ziele gleichzeitig betroffen. +- **Konto-Risiko:** **gleicher** Anbieter, **anderes** Geo-Risiko. + +### Option C - Rotierende Cold-Wechselplatte ausser Haus + +- **Was:** zweite externe HDD (z. B. 2x WD Elements 4 TB), die im monatlichen Wechsel zwischen Heim-LAN und vertrauter dritter Person (Familie, Schliessfach, Buero) rotiert. +- **Zielanbindung:** Borg-Repo lokal auf der eingesteckten Platte; Backup-Lauf nur wenn die Platte gerade vor Ort ist. +- **Standort:** echtes Ausserhaus, dazwischen offline (Air-Gap). +- **Preis (einmalig):** zwei Platten ~250 EUR, keine laufenden Kosten. +- **Vorteile:** echtes Air-Gap, keine Provider-Abhaengigkeit, keine Bandbreitenfrage, keine Konto-Risiken. +- **Nachteile:** manuelle Disziplin noetig, Recovery-Zeit haengt davon ab, dass die Platte gerade erreichbar ist. Nicht so taggenau wie Cloud-Borg. +- **Konto-Risiko:** keines (keine Provider-Bindung). + +## Bewertung gegen die Anforderungen + +| Anforderung | Hetzner (Ist) | Option A rsync.net | Option B BorgBase EU2 | Option C Cold-Platte | +|---|---|---|---|---| +| Anderer Anbieter | - | ja | nein (gleicher) | ja (keiner) | +| Anderer Standort | - | ja | ja | ja | +| Borg-kompatibel | ja | ja | ja | ja | +| Preis < 10 EUR/Monat | ja | grenzwertig | ja | einmalig ~250 EUR | +| Stabilitaet | hoch | hoch | hoch | Operator-Disziplin abhaengig | +| 2FA/Konto-Recovery | OK | OK | OK | n/a | + +## Empfehlung (nicht Entscheidung) + +Wenn der Operator die geringste Bedienung bei maximalem Provider-getrennten Schutz will: **Option A rsync.net**. Echte Anbieter-Trennung gegenueber Hetzner, Borg-First-Anbieter, ZFS-Snapshot-Schutz, keine zusaetzliche Hardware noetig. + +Wenn Air-Gap und Null-Provider-Abhaengigkeit am wichtigsten sind und der Operator die monatliche Rotation tatsaechlich diszipliniert macht: **Option C Cold-Platte**. + +**Option B (BorgBase EU2) wird nicht empfohlen** als zweites Ziel, weil das das Provider-Risiko nicht reduziert. + +## Was vor einer Buchung zu tun ist + +1. Operator-Entscheidung Option A vs. C dokumentieren (kein Provider-Kontakt vor Entscheidung). +2. Falls Option A: + - Konto bei rsync.net anlegen, Borg-Plan waehlen. + - SSH-Key vom Borg-UI-Container exportieren bzw. dediziertes Key-Pair erzeugen. + - `borg init` gegen das neue Repo durchfuehren (separate Passphrase oder gleiche - bewusst entscheiden). + - Borg-UI um zweites Repository erweitern (separater Eintrag, kein Replace). + - Schedule pruefen: erstes Vollbackup als One-Shot, danach inkrementell. + - `docs/SECRETS_MAP.md` und `docs/EXTERNAL_DEPENDENCIES.md` um neuen Provider ergaenzen. + - `docs/RESTORE_MATRIX.md` und `docs/STORAGE_LAYOUT.md` Backup-Ziel-Liste aktualisieren. +3. Falls Option C: + - zwei Platten beschaffen, Filesystem XFS oder ext4 (kein NTFS). + - Rotations-Plan in `docs/STORAGE_LAYOUT.md` ยง8.1 ergaenzen. + - Borg-Repo-Init pro Platte; Borg-UI um lokales Repo erweitern (nur aktiv wenn Platte eingesteckt). + - Operator-Disziplin: monatliche Rotation als Kalender-Reminder. + +## Was bewusst NICHT in dieser Vorlage steht + +- Konkrete Hetzner-Konto-Daten, rsync.net-Accountnamen, IBANs, Telefonnummern. Diese Daten gehoeren nirgendwo in dieses Repo. +- Borg-Passphrasen. Bleiben ausserhalb des Repos. +- "Migrieren weg von Hetzner" als Option. Hetzner bleibt; das zweite Ziel ist Ergaenzung, nicht Ablosung. + +## Offene Punkte + +| Status | Punkt | Naechster Schritt | +|---|---|---| +| offen | Entscheidung Option A vs. C | Operator | +| offen | Budget-Freigabe | Operator | +| offen | Provider-/Hardware-Beschaffung | nach Entscheidung | +| offen | Schedule-Anpassung in `ops/borg-ui` | nach Provider-Bereitstellung |