Files

T

Micha 3bfecdd291 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 <noreply@anthropic.com>

2026-05-27 20:21:03 +02:00

4.9 KiB

Raw Blame History

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:

# 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:

FRITZ!Box-UI: in den Geraete-Details fuer PC-192-168-178-71 die aktuelle Selbstfreigabe-Liste pruefen und mit dem Operator besprechen.
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

4.9 KiB Raw Blame History