# ArchitekturDie Muster, die die Firewall am Laufen halten: HA, Zonen, transparente Sicherheit, SSL-Inspection. ## Übersicht ``` ┌──────────────────────────────┐ ISP A ──────────────┤ │ │ Sovereign Edge Firewall ├── Zone: Clients ISP B ──────────────┤ (active / passive Failover) │── Zone: VPN │ │── Zone: Anonymisierung │ • Stateful-Filter │── Zone: Privacy │ • NAT (pro Uplink) │── Zone: DMZ │ • Transparentes SSL-Offload │ │ • Failover-Monitor │ └──────────────────────────────┘ ``` Die Firewall sitzt am Netzrand mit zwei parallelen Internet-Uplinks. Intern präsentiert sie pro isolierte Zone eine logische Schnittstelle. ## Dual-Provider-Hochverfügbarkeit Zwei Uplinks (z. B. Glasfaser + LTE/5G oder zwei Carrier) werden parallel angebunden. Ein Failover-Monitor beobachtet Link-State, Gateway-Erreichbarkeit und Latenz und schaltet bei Ausfall die Default-Route binnen **unter fünf Sekunden** auf den zweiten Uplink. Kernpunkte: - **Symmetrisches Regelwerk.** Beide Uplinks teilen sich Filter-, NAT- und Scrub-Regeln. Kein „guter" und „schlechter" Pfad. - **Dynamisches NAT.** Source-NAT bezieht die Egress-IP dynamisch vom aktiven Interface — kein Hardcoding, keine Stale-Mappings beim Failover. - **Selektive Steuerung.** Bestimmte Verkehrsklassen können gezielt auf den zweiten Uplink gepinnt werden (z. B. ein Anonymisierungs- Proxy-Pfad oder Lastverteilung für download-lastige Dienste). - **Automatischer Failback.** Sobald der primäre Uplink wieder gesund ist, kehrt der Monitor die Default-Route automatisch zurück. - **Failover-Tests.** Eine definierte Drill-Routine (siehe [Betrieb](../operations/)) verifiziert quartalsweise, dass das Failover wirklich funktioniert — nicht nur in der Theorie. ## Zonen-Segmentierung Statt einer flachen „innen/außen"-Topologie operiert die Firewall auf einem mehrstufigen Zonen-Modell. Lateral-Bewegung zwischen Zonen ist per Default geblockt. | Zone | Zweck | Egress-Profil | |---|---|---| | Clients | Mitarbeiter-Workstations | Transparenter HTTP/HTTPS-Proxy mit Content-Inspection | | VPN | Remote-Access und Site-to-Site-Tunnel | Pro-Tunnel-Egress-Profil | | Anonymisierung | Sensible Workloads (Recherche, Whistleblower) | Sämtlicher Verkehr über Tor, inkl. DNS | | Privacy | Maximalschutz-Workloads | Anonymisierung + zusätzliche Schicht | | DMZ | Extern erreichbare Services | Gehärteter Reverse-Proxy vor den Services | Jede Zone hat ihre eigene: - **Filter-Regel-Logik** — was rein darf, was raus darf. - **NAT-Policy** — welche Egress-IP, welcher Uplink bevorzugt. - **Inspection-Schicht** — ob HTTPS aufgebrochen wird, was geloggt wird. - **Whitelist-/Blocklist-Tabellen** — gespeist aus den Daemon-Outputs (siehe [Abusive HTTP Watch](../../abusive-http-watch/) Doku). ## Transparente Sicherheits-Lagen Endgeräte in der Client-Zone bekommen die folgenden Schutzschichten ohne lokale Konfiguration: ### SSL-Offloading als Virenschutz Die operativ wertvollste Schicht. Die Begründung: - Über 90 % moderner Web-Bedrohungen — Malware-Downloads, Phishing-Payloads, Drive-by-Exploits — werden über TLS ausgeliefert. - Endgeräte-Virenschutz (Defender, Bitdefender, …) auf der Workstation sieht nur den verschlüsselten Stream. Er kann die infizierte Datei erst dann erkennen, **nachdem** das Gerät sie entpackt hat. - An diesem Punkt hat das Gerät die ersten Stufen der Payload bereits ausgeführt. Containment wird zu Incident-Response. Die Firewall terminiert TLS stattdessen am Gateway, übergibt den Klartext einer Antivirus-Engine und leitet erst dann den Inhalt ans Endgerät weiter. Das Endgerät sieht einen bereits gescannten Stream. Malware wird geblockt, **bevor sie das Endgerät erreicht**. Die CA für den Bump ist die [Sovereign Certificate Authority](../../sovereign-certificate-authority/) — Clients vertrauen den Gateway-Zertifikaten, weil das interne CA-Root per Standard-Konfigurationsmanagement installiert ist. ### Content-Filter Werbe-Netzwerke, Tracker-Domains und bekannte schädliche Hosts werden vor der Auslieferung herausgefiltert. Reduziert Seitenwicht, eliminiert eine Klasse von Supply-Chain-Angriffen (kompromittierte Werbe-Netzwerk-JavaScripts) und verbessert die Privatsphäre. ### Tor / Anonymisierungs-Gateway Die Anonymisierungszone hat **gar keinen direkten Internet-Egress**. Sämtlicher TCP-Verkehr wird transparent durch einen lokalen Tor-Daemon geroutet, inklusive DNS-Anfragen (über einen lokalen Resolver, der Tors DNS-Port nutzt). Endgeräte in dieser Zone brauchen keinen eigenen Tor-Client — das Netzwerk erzwingt das Routing. ### I2P / Privacy-Gateway Gleiche Idee wie die Tor-Zone, eine Schicht tiefer. Genutzt für Workloads, bei denen auch Tor-Exit-Node-Vertrauen ein Thema ist. ## Operative Defaults - **Default-Deny.** Jede Regel, die Verkehr erlaubt, ist explizit. Spoofing-Schutz, Reverse-Path-Validation und Anti-Scan-Heuristiken laufen per Default. - **Connection-State-Limits.** Hunderttausende parallele Sessions werden unterstützt; Per-Source-Caps verhindern eine State-Table-Erschöpfung. - **Verkehrs-Normalisierung.** TCP-Reassembly, MSS-Clamping und Fingerprinting-Schutz werden auf allen Egress-Pfaden angewandt — wichtig für Mobilfunk-Uplinks und VPN-Tunnel. - **Dual-Stack.** IPv4 und IPv6 sind First-Class, inklusive moderner ICMPv6-Mechanik (Router Advertisement, Neighbour Discovery). ## Wo der Daemon hineinpasst Der begleitende [Abusive HTTP Watch](../../abusive-http-watch/) Daemon schreibt eine Blocklist, die die Firewall per Tabellen-Reload-Cron konsumiert. Das fügt eine Verhaltens-basierte Block-Schicht oberhalb der statischen Regeln hinzu — IPs, die nachweislich Exploits suchen, werden am Edge gedroppt. ## Was das nicht ist - Keine Vendor-Box zum Kaufen. Das ist ein Liefermuster, kein Produkt-SKU. - Kein Anfänger-Projekt. Das verantwortungsvoll zu betreiben erfordert kompetente Operatoren (oder den [Betrieb](/de/services/support/)-Service, der sie stellt). - Keine „einmal einrichten und vergessen"-Lösung. Die Token-Sets, Blocklists und Zonen-Regeln brauchen Pflege — siehe [Betrieb](../operations/).