Wenn ADC und Firewall separat verwaltet werden, bricht die Sicherheitskette.
In klassischen Architekturen befindet sich der ADC auf einem Gerät, die Firewall auf einem anderen und Routing- und NAT-Regeln in einer weiteren Betriebsschicht. Diese Trennung sieht anfangs ordentlich aus, aber in der Produktion wird jede Änderung zu einem Koordinationsproblem. Ein neuer vService wird geöffnet und die Firewall-Regel wird vergessen. Ein DNAT ändert sich und die Route wird nicht aktualisiert. Ein Backend-Segment verschiebt sich und die FORWARD-Regel bleibt veraltet.
In Multi-Namespace- oder Multi-Tenant-Umgebungen wächst das Problem. Wenn jeder Tenant seinen eigenen IP-Raum, seine eigenen Interfaces und seine eigenen NAT-Regeln hat, ist eine einzige globale Firewall-Tabelle nicht ausreichend. Derselbe CIDR kann in verschiedenen Namespaces verwendet werden; in diesem Fall muss auch die Firewall nach Namespace getrennt sein.
Ein separates Firewall-Gerät zu verwenden ist nicht nur eine zusätzliche Management-Last — Audit und Failover fragmentieren ebenfalls. Ein Operator kann "Wer hat diesen Traffic geöffnet?", "Welche automatische Regel kam von welchem vService?" oder "In welchem Namespace ist dieses DNAT aktiv?" nicht von einem einzigen Panel aus beantworten. Bei einem Vorfall müssen ADC-Protokolle, Firewall-Protokolle und Routing-Zustand separat inspiziert werden.
Regel-Anwendungssicherheit ist ein weiteres Problem. In traditionellen Firewall-Regelwerken kann eine einzige fehlerhafte Zeile dazu führen, dass der gesamte Ladevorgang fehlschlägt. In der Produktion ist die Konsequenz schwerwiegend: Korrekte Regeln werden auch nicht angewendet, Traffic wird unterbrochen oder die Sicherheitsrichtlinie fällt ins Leere.
TR7 ADC behandelt die Firewall als natürlichen Teil des ADC: Pro-Namespace-Regelwerke, Pro-Interface-Kontrolle, automatische ADC/GTM/NAT-Regeln, DDoS-Direktiven, eine Test-Apply-Pipeline und Fehleregel-Isolation sind in einem einzigen Managementmodell kombiniert.
Unser Ansatz
TR7s Firewall-Ansatz ist nicht ein separates Sicherheitsgerät, das angehängt wird — es ist eine L3/L4-Kontrollschicht, die in das Traffic-, Routing- und Namespace-Modell des ADC eingebettet ist.
Pro-Namespace-Firewall-Management
Jeder Namespace hat seinen eigenen Firewall-Manager. Eine Regel innerhalb eines Namespaces berührt nicht den Traffic in einem anderen Namespace. Dieses Modell bietet sichere Isolation in Multi-Tenant-, Überlappungs-CIDR- und Separate-Route-Table-Szenarien.
Test → Apply-Pipeline
Neuer Firewall-Inhalt wird zuerst getestet und dann angewendet. Wenn eine Zeile fehlschlägt, wird das gesamte Regelwerk nicht abgebrochen — die fehlerhafte Zeile wird automatisch deaktiviert und die gesunden Regeln werden erneut versucht. Dies verhindert, dass ein einzelner Fehler das gesamte Regelwerk bei einer Produktionsänderung abbricht.
Parallele IPv4- und IPv6-Regelwerke
IPv4- und IPv6-Regeln werden in separaten Dateien mit separater Validierung parallel verwaltet. Ein Fehler in einer IP-Familie beeinflusst nicht die andere. Bei Dual-Stack-Diensten wird die Sicherheitsrichtlinie konsistent für beide Familien angewendet.
Automatische Firewall-Regeln aus ADC-Objekten
Wenn ein ADC-Pool, L4-NAT, Inline-DNAT, GTM-DNS-Umleitung, Management-Zugriff oder Backend-Marker konfiguriert wird, können Firewall-Regeln automatisch generiert werden. Operatoren, die einen vService öffnen, müssen nicht separat an die Sicherheitsseite denken.
Fähigkeiten
Die Integrierte Firewall kombiniert klassische L3/L4-Kontrolle mit ADC-nativer automatischer Regelgenerierung, DDoS-Mitigation, Quarantäne, deterministischem CGNAT und Namespace-Isolation.
Pro-Namespace-Firewall-Isolation
Jeder Namespace betreibt ein unabhängiges Firewall-Regelwerk. Ein in Tenant A's Namespace definiertes DNAT beeinflusst nicht denselben CIDR-Block in Tenant B. Diese Struktur bietet die grundlegende Sicherheitstrennung für Multi-Tenant- und Überlappungs-IP-Raum-Szenarien.
Deterministisches CGNAT — Teilnehmer-Nachverfolgbarkeit ohne Session-Log
Jeder Teilnehmer erhält einen festen, vorberechneten Block öffentlicher Ports: Die Zuordnung aus öffentlicher Adresse und Port ist Arithmetik statt Datenbankabfrage. Das sonst von RFC 6888 erzwungene Logging jeder Session, das die Kosten einer CGNAT-Einführung meist dominiert, entfällt — die rechtliche Nachverfolgbarkeit bleibt. ALGs für FTP, TFTP, SIP, PPTP und H.323 sind enthalten. Endpoint-Independent Filtering und Hairpinning liegen außerhalb des Umfangs dieser Version.
Separates IPv4- und IPv6-Management
IPv4- und IPv6-Regeln werden als separate Regelwerke produziert und angewendet. Bei Dual-Stack-Diensten wird die IPv6-Seite nicht später vergessen; Allow-, Deny-, Forward-, NAT- und Rate-Limit-Kontrollen können für beide IP-Familien geschrieben werden.
Dual-Stack-NAT inklusive NAT66 — eine Regel, beide Adressfamilien
Dieselbe Regel-Engine erzeugt aus einer Policy IPv4- und IPv6-Regelsätze, sodass statisches SNAT, DNAT und 1:1-Übersetzung im IPv6-Netz identisch arbeiten. Die Übersetzung zwischen IPv6-Präfixen — NAT66 — gehört dazu und wird ausdrücklich genannt, weil man sie üblicherweise für fehlend hält. Es gibt keinen separaten IPv6-Konfigurationspfad und keine Regel, die stillschweigend nur für eine Familie gilt — genau das verhindert, dass eine IPv6-Einführung zur zweiten, halb erinnerten Firewall wird.
Pro-Interface-Regeldefinition
Regeln können nicht nur auf Namespace-Ebene, sondern auch auf Interface-Ebene definiert werden. Verschiedene Richtlinien können auf das Management-Interface, Sync-Interface, Tenant-Interface oder Service-Interface angewendet werden. Dieses Modell kontrolliert Traffic gemäß dem tatsächlichen Ingress/Egress-Punkt.
Allow-, Deny-, Forward- und Not-Forward-Regeln
Kern-Firewall-Operationen werden in einem einzigen Modell verwaltet. Erlauben, Blockieren, Transit-Passage zulassen oder spezifischen Traffic von Transit ausschließen können alle in den INPUT- und FORWARD-Ketten definiert werden.
DNAT- und SNAT-Unterstützung
DNAT kann angewendet werden, um eingehenden Traffic zu einer anderen Ziel-IP umzuleiten; SNAT ändert die Quell-IP des ausgehenden Traffics. Inline-Publishing, L4-Service-Umleitung und Multi-Backend-Segment-Szenarien werden mit diesen Regeln verwaltet.
GeoIP- und länderbasiertes Matching
Quell-IP-Matching kann gegen Ländersets durchgeführt werden. Es ist möglich, bestimmte Länder auf die Allowlist zu setzen, spezifische Länder zu blockieren oder bei einem Angriff schnell Hochrisiko-Regionen zu verwerfen. Set-basierter Betrieb bewahrt die Performance bei großer Skalierung.
CIDR-, MAC- und Negations-Matching
IP/CIDR, MAC-Adresse und "Ausschluss"-Logik werden unterstützt. Zum Beispiel kann ein gesamtes Subnetz blockiert werden, während spezifische IPs ausgenommen sind. Diese Struktur wird sowohl für betriebliche Allowlists als auch für temporäre Incident-Response-Regeln verwendet.
Multi-Port- und Port-Range-Matching
Mehrere Ports oder Port-Bereiche können in einer einzigen Regel definiert werden. Breite oder enge Zugriffsrichtlinien können für DNS, RADIUS, SIP, API und Management-Ports geschrieben werden.
20+ DDoS-Schutz-Direktiven
Ungültiger Paket-Drop, neues TCP-Verbindungslimit, Gesamtverbindungslimit, UDP-Flood-Limit, DNS/NTP-Flood-Limit, TCP-Reset-Limit, Fragment-Drop, verdächtiger MSS, LAND-Angriffserkennung und Zero-Byte-UDP-Blockierung können alle unter einer einzigen Richtlinie aktiviert werden.
Quarantänetabellen
Quellen, die einen Schwellenwert überschreiten, werden zu temporären Quarantänesets hinzugefügt. Wenn die Quarantänezeit abläuft, wird der Eintrag automatisch entfernt. Whitelist-Sets können von Quarantäneregeln ausgenommen werden, sodass vertrauenswürdige Quellen nie versehentlich betroffen sind.
Connection-Mark-Unterstützung für L4-Persistenz
Connection-Marks und Recent-Lists können verwendet werden, um spezifischen Client-Traffic an dasselbe Backend in L4-Diensten zu binden. Dies ist für Sitzungskontinuität in UDP- oder Port-Range-Szenarien wichtig.
Automatische ADC/GTM/NAT-Regeln
Automatische Regeltypen werden für das Erlauben eines Service-Ports beim Öffnen eines Pools, das Generieren von L4-SNAT/DNAT, das Erstellen einer Inline-DNAT-Regel, das Umleiten des GTM-DNS-Zugriffs oder das Hinzufügen einer Local-Deny-Regel unterstützt.
Fehleregel-Isolation
Wenn eine Zeile während der Regelwerk-Anwendung fehlschlägt, wird sie erkannt, auskommentiert und die verbleibenden Regeln werden erneut versucht. Eine einzige fehlerhafte Regel kann die gesamte Firewall-Synchronisation nicht stoppen.
Log- und Audit-Unterstützung
Regeln können so konfiguriert werden, dass sie Log-Einträge erzeugen. Drop-, Allow-, DNAT- oder Quarantäneverhalten können in die Audit-Kette einbezogen werden. Nach einem Vorfall kann nachverfolgt werden, welche Regel welchen Traffic beeinflusst hat.
Automatischer Schutz für Management- und Cluster-Sync-Interfaces
Management- und Cluster-Sync-Traffic wird speziell vom System behandelt. Kritische Interfaces werden mit automatischem Allow-Verhalten geschützt, um versehentlichen Verlust des betrieblichen Zugriffs zu verhindern.
Operative Tiefe
Die integrierte Firewall-Schicht ist nicht nur ein Regelschreibbildschirm — sie arbeitet zusammen mit Testing, Synchronisation, Fehler-Isolation, automatischer Regelgenerierung und Namespace-Lebenszyklusmanagement.
Config-Pfad und Regelwerk-Trennung
IPv4- und IPv6-Firewall-Inhalt für jeden Namespace wird in separaten Konfigurationsdateien gespeichert. Die letzte kombinierte Konfiguration wird ebenfalls aufbewahrt, was Change-Tracking und Debugging unkompliziert macht.
Synchronisations-Timeout und sicheres Apply
Firewall-Synchronisation arbeitet innerhalb definierter Timeout-Grenzen. Der Prozess erreicht zuerst einen Bereit-Zustand; dann werden die Test- und Apply-Schritte ausgeführt. Ein lang laufender oder hängengebliebener Vorgang wird vom System begrenzt.
Parallele Namespace-Sync
Wenn viele Namespaces vorhanden sind, wird die Firewall-Synchronisation in Batches parallel ausgeführt. Dies macht es operativ handhabbar, dass jeder Namespace sein eigenes Regelwerk in Multi-Tenant-Umgebungen hat.
Automatische Regeltypen
Automatische Regeltypen wie pool-tcp-udp, ftp-allow, l4-snat, l4-any-dnat, l4-any-snat, inline-dnat, fw-access-allow, fw-access-dnat, gtm-dns-dnat, gtm-access-dnat, local-deny und be-mark können aus ADC-Objekten generiert werden.
Connection-Tracking
Rückflüsse für RELATED- und ESTABLISHED-Traffic werden automatisch erkannt. Dies reduziert den Bedarf, für jeden Rückgabe-Paket in stateful Services separate manuelle Regeln zu schreiben.
Hashlimit und connlimit
Pro-Source-Rate-Limits und Verbindungslimits werden unterstützt. Übermäßige Verbindungen, Reset-Pakete, ICMP-Pakete, DNS/NTP-UDP-Floods oder neue TCP-Verbindungsversuche von derselben IP können alle begrenzt werden.
ICMP und IPv6-Neighbor-Discovery
Das vollständige Blockieren von ICMP kann grundlegende Netzwerkfunktionen wie IPv6 und Path MTU Discovery beeinträchtigen. TR7 behandelt ICMP-Richtlinien granular; die notwendigen Discovery- und Control-Nachrichten können sicher verwaltet werden.
Finales Regelwerk nach Fehler-Recovery
Nachdem fehlerhafte Regeln auskommentiert wurden, wird das finale Regelwerk zurück auf die Festplatte geschrieben. Operatoren können sehen, welche Zeile deaktiviert wurde und können sie korrigieren. Das System produziert ein sichtbares, umsetzbares Ergebnis anstelle eines stillen Fehlers.
Wann einsetzen
SSH-Brute-Force-Reduktion am Management-Interface
SSH-Verbindungen zum Management-Interface werden mit einem Pro-Source-Limit begrenzt. Wenn dieselbe IP den definierten Schwellenwert überschreitet, wird sie temporär in die Quarantäne gestellt. Die Brute-Force-Angriffsfläche wird reduziert, während der Management-Zugriff offen bleibt.
Länderbasierte Zugriffsrichtlinie
Nur Traffic aus ausgewählten Ländern wird erlaubt; alle anderen werden verworfen. Dies bietet eine schnelle Kontrolle für länderbasierte Compliance und Risikoreduktion in Finanz-, Behörden- oder Gesundheitssystemen.
Multi-Tenant-DNAT-Trennung
Während 1.2.3.4 → 10.0.0.5 DNAT in Tenant A's Namespace angewendet wird, kann Tenant B denselben internen CIDR mit einer anderen Regel verwenden. Namespace-Isolation stellt sicher, dass die NAT-Richtlinien der beiden Tenants nicht konfligieren.
Integrierte DDoS-Mitigation
UDP-Zero-Byte-Flood, DNS/NTP-Flood, abnormales TCP, Fragment- und Connection-Flood-Verhalten werden mit Hashlimit-, connlimit- und Quarantänemechanismen gemindert. Grundlegender L3/L4-Schutz wird ohne ein separates Scrubbing-Gerät angewendet.
Kontrollierter Transit zwischen Segmenten via FORWARD-Kette
Wenn Transit-Traffic zwischen zwei Backend-Segmenten benötigt wird, wird kontrollierter Durchgang mit FORWARD-Regeln etabliert. Welche Quelle welches Ziel über welchen Port erreichen kann, wird präzise definiert.
Inline-DNAT-Publishing
Eine Backend-IP wird durch TR7 veröffentlicht und eingehender Traffic wird via Inline-DNAT zum relevanten Backend geliefert. Die TR7-Sicherheits- und Routing-Schicht wird eingesetzt, ohne den Anwendungs- oder Backend-IP-Plan zu ändern.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Pro-Namespace-Firewall und einer globalen Firewall?
Wenn eine fehlerhafte Regel geschrieben wird, bricht die gesamte Firewall zusammen?
Werden IPv6-Regeln separat von IPv4-Regeln verwaltet?
Ist ein separates Gerät für den DDoS-Schutz erforderlich?
Können Firewall-Regeln automatisch aus ADC-Objekten generiert werden?
Wie funktioniert GeoIP-Matching und beeinflusst es die Performance?
Netzwerksicherheit von derselben Konsole wie Ihren ADC verwalten
Namespace-Isolation, DDoS-Direktiven, DNAT/SNAT und automatische Regelgenerierung — lassen Sie uns ein Live-Setup in Ihrer eigenen Umgebung durchgehen.