# BetriebDie Firewall in Produktion betreiben: Failover-Drills, Log-Review, Grenz-Tests, Pflege.

## Quartals-Failover-Drill

Der ganze Punkt eines Dual-Provider-HA-Setups ist, dass das
Failover funktioniert, **wenn der primäre Uplink echt ausfällt**.
Der einzige Weg, sich darauf zu verlassen, ist es absichtlich zu
testen.

Empfohlene Kadenz: **vierteljährlich**, in einem ruhigen
Verkehrsfenster, mit dem Operator an der Konsole.

Ablauf:

1. Drill auf dem Team-Kanal ankündigen — das Failover soll
   unsichtbar sein, aber falls etwas schiefläuft, will man es
   sofort wissen.
2. Primären Uplink auf Interface-Ebene deaktivieren (nicht am
   Provider-Modem — das simuliert den falschen Fehlerfall).
3. Innerhalb von fünf Sekunden sollte der Failover-Monitor die
   Default-Route auf den zweiten Uplink umschalten.
4. Externe Erreichbarkeit verifizieren: ein Request aus einer Zone
   sollte weiterhin auflösen, abrufen und zurückkehren.
5. Primären Uplink wieder aktivieren.
6. Der Monitor sollte die Default-Route innerhalb seines
   konfigurierten Intervalls zurück auf den primären stellen.
7. Drill in einem Logbuch festhalten: Datum, Time-to-detect,
   Time-to-recover, irgendwas Ungewöhnliches.

Wenn das Failover länger braucht als erwartet, sind das Check-
Intervall oder die Schwellwerte des Monitors zu tunen. Wenn das
Failover gar nicht stattfindet, ist die Monitor-Konfiguration
kaputt — beheben, bevor du nach Hause gehst. Ein nicht-
funktionierender Failover-Monitor ist schlimmer als gar kein
Monitor; er gibt dem Operator falsche Sicherheit.

## Log-Review

Drei Log-Streams sind wichtig:

- **Firewall-Events.** Drop-Entscheidungen, Tabellen-Erweiterungen,
  NAT-State. Laut bei Recon-Scans, leise unter normaler Last.
- **SSL-Offloading-Events.** Termination-Fehler, Zertifikats-
  Validierungs-Fehlschläge, Scanner-Verdikte. Spikes bedeuten, dass
  sich etwas geändert hat — eine Zert-Rotation upstream, ein neuer
  Client, der dem internen CA-Root nicht vertraut, oder ein
  Malware-Pattern, das einer früheren Filterstufe entglitten ist.
- **Failover-Monitor-Events.** Link-Übergänge. Sollte die meisten
  Wochen leer sein. Häufige Übergänge deuten auf einen flackernden
  Uplink hin — Thema beim Carrier aufmachen.

Empfohlene Operator-Routine: wöchentlich fünfzehn Minuten durch
diese drei Streams scrollen. Ungewöhnliches markieren, Tickets
fürs nächste Quartals-Review anlegen.

## Zonen-Grenzen-Verifikation

Die Zonen sind im Regelwerk definiert. Das Regelwerk kann falsch
sein. Der einzige Weg festzustellen welches stimmt, ist Testen.

Empfohlene Kadenz: **halbjährlich**, oder nach jeder signifikanten
Regelwerks-Änderung.

Für jedes Zonen-Paar (Clients ↔ DMZ, Clients ↔ VPN,
Anonymisierung ↔ alles andere, etc.):

1. Von einem Host in Zone A einen Service in Zone B zu erreichen
   versuchen, der nicht erreichbar sein soll.
2. Bestätigen, dass die Verbindung scheitert — TCP-RST,
   ICMP-Unreachable oder Timeout, je nach Regeltyp.
3. Ergebnis im selben Logbuch festhalten.

Wenn ein erwartet-geblockter Pfad erreichbar ist, ist das ein
Regel-Bug. Noch am selben Tag fixen.

## Blocklist-Pflege

Die Blocklist-Tabellen wachsen mit der Zeit. Zwei häufige
Fehlerbilder:

- **Veraltete Einträge.** Eine IP, die vor sechs Monaten
  abusive war, ist heute ein DSL-Anschluss mit neuem Eigentümer.
  Periodisches Rotieren der Blocklist-Datei (siehe
  [Abusive-HTTP-Watch-Konfiguration](../../abusive-http-watch/configuration/)-Doku)
  begrenzt das.
- **Whitelist-Drift.** Office- und VPN-IP-Bereiche ändern sich
  über die Zeit. Veraltete Whitelist-Einträge verursachen keine
  unmittelbaren Incidents, reduzieren aber den Wert der Whitelist
  als Steuerungsinstrument. Whitelist-Datei vierteljährlich
  reviewen.

## Zertifikats-Rotation

Die TLS-Terminations-Schicht nutzt Zertifikate der
[Sovereign Certificate Authority](../../sovereign-certificate-authority/).
Rotation erfolgt automatisch via ACME, aber:

- **Rotation bestätigen** mindestens monatlich — `openssl s_client`
  gegen das Gateway, prüfen, dass das `notAfter` des Zertifikats
  in der Zukunft liegt, prüfen, dass die Chain immer noch gegen
  den internen Root validiert.
- **Client-Vertrauen testen** nach jeder CA-seitigen Änderung —
  einen repräsentativen Client je Zone wählen, einen HTTPS-Service
  innerhalb des Netzes aufrufen, prüfen, dass keine Zertifikats-
  Warnung erscheint.

Fehlerbild: eine Rotation läuft CA-seitig durch, aber die Firewall
übernimmt das neue Zertifikat nicht (Configuration-Reload fehlt,
Datei-Permissions falsch). Das alte Zert ist noch eine Weile
gültig — der Bug bleibt verdeckt. Die monatliche Verifikation
fängt das ab.

## Routine-Pflege

- **OS-Patches.** Sicherheitsrelevante Patches innerhalb des vom
  Hersteller empfohlenen Fensters einspielen. Rebooten — die
  Firewall ist keine Cattle-Style-Appliance, aber Uptime jenseits
  von neun Monaten lädt zu Problemen ein.
- **Dependency-Review.** Die Tor-, I2P-, Squid- und Privoxy-
  Daemons haben jeweils eigene Patch-Zyklen. Upstream-Releases
  tracken.
- **Kapazitäts-Check.** State-Table-Füllung, CPU im Peak,
  Speicher-Headroom. Die Firewall sollte komfortabel unter der
  halben Kapazität laufen. Wenn nicht, nächste Hardware-Erneuerung
  planen.

## Wenn etwas kaputt geht

Die operative Gewohnheit mit dem höchsten Wert: **aufschreiben,
was passiert ist**.

Eine kurze Notiz pro Incident — wann, was du gesehen hast, was du
geändert hast, was funktioniert hat, was nicht — macht aus einem
Vorfall einen dauerhaften Lerngewinn. Beim nächsten Auftreten
desselben Musters löst es entweder dieselbe Person oder ihr
Nachfolger in Minuten statt Stunden.

Wenn ein Incident die Expertise oder Zeit deines Teams übersteigt,
ist [Betrieb](/de/services/support/) der Eskalationspfad.