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.
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.
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.
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.
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.
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.
Die Integrierte Firewall kombiniert klassische L3/L4-Kontrolle mit ADC-nativer automatischer Regelgenerierung, DDoS-Mitigation, Quarantäne und Namespace-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.
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.
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.
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 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.
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.
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.
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.
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.
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-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 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.
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.
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.
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.
Die integrierte Firewall-Schicht ist nicht nur ein Regelschreibbildschirm — sie arbeitet zusammen mit Testing, Synchronisation, Fehler-Isolation, automatischer Regelgenerierung und Namespace-Lebenszyklusmanagement.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Namespace-Isolation, DDoS-Direktiven, DNAT/SNAT und automatische Regelgenerierung — lassen Sie uns ein Live-Setup in Ihrer eigenen Umgebung durchgehen.