homelab-infra/docs/FRITZBOX_PORT_CORRECTION_PLAN.md

FRITZ!Box Portfreigaben - Korrektur-Vorbereitung

Status: umgesetzt 2026-05-28, Doku bleibt als Historie und Begruendungs-Anker. Audit-Bezug: docs/AUDIT_2026-05-25_TODO.md Sprint 4 ("FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen") und docs/NETWORK_INVENTORY.md.

Umsetzungs-Befund 2026-05-28

Punkt	Entscheidung	Validierung
1. 80/tcp entfernen	umgesetzt	Mobilfunk-Test: http://vault.kaleschke.info Timeout, https://... weiter erreichbar. Lokal via LAN: HTTP->HTTPS-Redirect funktioniert weiter durch Traefik.
2. 222/tcp ergaenzen	bewusst NICHT umgesetzt	Tailscale bleibt Operator-Pfad; GitHub-Mirror deckt DR-Bootstrap ab; SSH-Brute-Force-Vektor vermieden. Repo-Soll in NETWORK_INVENTORY.md und MASTER_V2.md Sektion 10 entsprechend angepasst.
3. UPnP-Selbstfreigabe PC-192-168-178-71	umgesetzt	"Selbstständige Portfreigaben fuer dieses Geraet erlauben" deaktiviert. Identifiziert als VONETS-WiFi-Bridge (Hostname VONETS.COM, MAC 00:17:13:2F:61:96) — vermutlich Bridge zum SolarEdge-Wechselrichter. SolarEdge-Cloud-Sync ist outbound und benoetigt keine UPnP.

Aktiver Endstand: ausschliesslich 443/tcp -> 192.168.178.58:443 (Traefik HTTPS) ist von WAN aus erreichbar.

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:

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
erledigt 2026-05-28	80/tcp entfernen	umgesetzt, Mobilfunk-validiert
erledigt 2026-05-28 (bewusst nicht)	222/tcp Entscheidung	bleibt Tailscale-only; Repo-Soll entsprechend angepasst
erledigt 2026-05-28	UPnP-Freigabe PC-192-168-178-71	UPnP-Selbstfreigabe-Recht fuer VONETS-Bridge deaktiviert
offen	FRITZ!OS 8.21 Update	Service-Fenster, separat geplant
offen	IPv6-Exposure pruefen	bei naechstem WAN-Touch mit erfassen