Betrieb

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-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. 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 der Eskalationspfad.