Micha
3bfecdd291
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>
95 lines
4.9 KiB
Markdown
95 lines
4.9 KiB
Markdown
# 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 |
|