Architektur

Ü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) 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.

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 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 — 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 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-Service, der sie stellt).
• Keine „einmal einrichten und vergessen"-Lösung. Die Token-Sets, Blocklists und Zonen-Regeln brauchen Pflege — siehe Betrieb.