Dans les architectures classiques, l'ADC vit sur un appareil, le pare-feu sur un autre, et les règles de routage et NAT existent dans encore une autre couche opérationnelle. Cette séparation semble ordonnée au premier abord, mais en production chaque changement devient un problème de coordination. Un nouveau vService est ouvert et la règle de pare-feu est oubliée. Un DNAT change et la route n'est pas mise à jour. Un segment backend change et la règle FORWARD reste obsolète.
Dans les environnements multi-namespace ou multi-tenant, le problème s'aggrave. Lorsque chaque tenant a son propre espace IP, ses propres interfaces et ses propres règles NAT, une seule table de pare-feu globale n'est pas suffisante. Le même CIDR peut être utilisé dans différents namespaces ; dans ce cas, le pare-feu doit également être séparé par namespace.
Utiliser un appareil pare-feu séparé n'est pas seulement un fardeau de gestion supplémentaire — l'audit et le basculement se fragmentent également. Un opérateur ne peut pas répondre « qui a ouvert ce trafic ? », « quelle règle automatique vient de quel vService ? » ou « dans quel namespace ce DNAT est-il actif ? » depuis un seul panneau. Lors d'un incident, les logs ADC, les logs pare-feu et l'état du routage doivent être inspectés séparément.
La sécurité de l'application des règles est un autre problème. Dans les ensembles de règles de pare-feu traditionnels, une seule ligne défaillante peut faire échouer l'ensemble de l'opération de chargement. En production, la conséquence est sévère : les règles correctes ne sont également pas appliquées, le trafic est interrompu ou la politique de sécurité tombe en veille.
TR7 ADC traite le pare-feu comme une partie naturelle de l'ADC : ensembles de règles par namespace, contrôle par interface, règles ADC/GTM/NAT automatiques, directives DDoS, un pipeline test-apply et isolation des règles défaillantes sont combinés dans un seul modèle de gestion.
L'approche pare-feu de TR7 n'est pas un appareil de sécurité séparé boulonné dessus — c'est une couche de contrôle L3/L4 intégrée dans le modèle de trafic, de routage et de namespace de l'ADC.
Chaque namespace dispose de son propre gestionnaire de pare-feu. Une règle à l'intérieur d'un namespace ne touche pas le trafic d'un autre namespace. Ce modèle fournit une isolation sécurisée dans les scénarios multi-tenant, CIDR chevauchant et table de routage séparée.
Le nouveau contenu du pare-feu est d'abord testé puis appliqué. Si une ligne échoue, l'ensemble de règles entier n'est pas annulé — la ligne défaillante est automatiquement désactivée et les règles saines sont réessayées. Cela empêche une seule erreur de faire tomber l'ensemble de règles entier lors d'un changement en production.
Les règles IPv4 et IPv6 sont gérées dans des fichiers séparés, avec une validation séparée, en parallèle. Une défaillance dans une famille IP n'affecte pas l'autre. Sur les services dual-stack, la politique de sécurité est appliquée de manière cohérente pour les deux familles.
Lorsqu'un pool ADC, un NAT L4, un DNAT inline, une redirection DNS GTM, un accès de gestion ou un marqueur backend est configuré, les règles de pare-feu peuvent être générées automatiquement. Les opérateurs ouvrant un vService n'ont pas besoin de se souvenir séparément du côté sécurité.
Le Pare-feu Intégré combine le contrôle L3/L4 classique avec la génération de règles automatique native à l'ADC, la mitigation DDoS, la quarantaine et l'isolation des namespaces.
Chaque namespace fonctionne avec un ensemble de règles de pare-feu indépendant. Un DNAT défini dans le namespace du Tenant A n'affecte pas le même bloc CIDR dans le Tenant B. Cette structure fournit la séparation de sécurité fondamentale pour les scénarios multi-tenant et d'espace IP chevauchant.
Les règles IPv4 et IPv6 sont produites et appliquées comme des ensembles de règles séparés. Dans les services dual-stack, le côté IPv6 n'est pas oublié plus tard ; les contrôles allow, deny, forward, NAT et rate-limit peuvent être écrits pour les deux familles IP.
Les règles peuvent être définies non seulement au niveau du namespace mais aussi au niveau de l'interface. Différentes politiques peuvent être appliquées à l'interface de gestion, l'interface de synchronisation, l'interface tenant ou l'interface de service. Ce modèle contrôle le trafic selon le point d'entrée/sortie réel.
Les opérations de pare-feu principales sont gérées dans un modèle unique. Autoriser, bloquer, permettre le passage en transit ou exclure un trafic spécifique du transit peuvent tous être définis dans les chaînes INPUT et FORWARD.
Le DNAT peut être appliqué pour rediriger le trafic entrant vers une IP de destination différente ; le SNAT change l'IP source du trafic sortant. La publication inline, la redirection de service L4 et les scénarios multi-segments backend sont gérés avec ces règles.
La correspondance IP source peut être effectuée sur des ensembles de pays. Il est possible d'ajouter certains pays à la liste blanche, de bloquer des pays spécifiques ou de supprimer rapidement des régions à haut risque lors d'une attaque. L'opération basée sur des ensembles préserve les performances à grande échelle.
La logique IP/CIDR, adresse MAC et « exclure » est prise en charge. Par exemple, un sous-réseau entier peut être bloqué tandis que des IPs spécifiques sont exemptées. Cette structure est utilisée pour les listes blanches opérationnelles et les règles de réponse aux incidents temporaires.
Plusieurs ports ou plages de ports peuvent être définis dans une seule règle. Des politiques d'accès larges ou étroites peuvent être écrites pour les ports DNS, RADIUS, SIP, API et de gestion.
La suppression de paquets invalides, la limite de nouvelles connexions TCP, la limite totale de connexions, la limite de flood UDP, la limite de flood DNS/NTP, la limite de reset TCP, la suppression de fragments, le MSS suspect, la détection d'attaque LAND et le blocage des UDP à octets zéro peuvent tous être activés sous une seule politique.
Les sources qui dépassent un seuil sont ajoutées à des ensembles de quarantaine temporaires. Lorsque la période de quarantaine expire, l'entrée est automatiquement supprimée. Les ensembles de liste blanche peuvent être exclus des règles de quarantaine afin que les sources de confiance ne soient jamais accidentellement affectées.
Les connection marks et les recent lists peuvent être utilisés pour lier le trafic client spécifique au même backend dans les services L4. C'est important pour la continuité de session dans les scénarios UDP ou plage de ports.
Des types de règles automatiques sont pris en charge pour autoriser un port de service lorsqu'un pool est ouvert, générer L4 SNAT/DNAT, créer une règle DNAT inline, rediriger l'accès DNS GTM ou ajouter une règle de refus local.
Lorsqu'une ligne échoue lors de l'application de l'ensemble de règles, elle est détectée, commentée et les règles restantes sont réessayées. Une seule règle défaillante ne peut pas arrêter l'ensemble de la synchronisation du pare-feu.
Les règles peuvent être configurées pour produire des entrées de log. Les comportements de suppression, allow, DNAT ou quarantaine peuvent être inclus dans la chaîne d'audit. Après un incident, quelle règle a affecté quel trafic peut être retracé.
Le trafic de gestion et de synchronisation de cluster est géré spécialement par le système. Les interfaces critiques sont protégées avec un comportement allow automatique pour éviter la perte accidentelle d'accès opérationnel.
La couche de pare-feu intégré n'est pas seulement un écran de rédaction de règles — elle fonctionne ensemble avec les tests, la synchronisation, l'isolation des erreurs, la génération automatique de règles et la gestion du cycle de vie des namespaces.
Le contenu du pare-feu IPv4 et IPv6 pour chaque namespace est stocké dans des fichiers de configuration séparés. La dernière configuration combinée est également conservée, rendant le suivi des changements et le débogage simples.
La synchronisation du pare-feu opère dans des limites de timeout définies. Le processus atteint d'abord un état prêt ; puis les étapes de test et d'application sont exécutées. Une opération longue ou bloquée est délimitée par le système.
Lorsque de nombreux namespaces sont présents, la synchronisation du pare-feu s'exécute par lots en parallèle. Cela rend opérationnellement gérable le fait que chaque namespace ait son propre ensemble de règles dans les environnements multi-tenant.
Des types de règles automatiques tels que 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 et be-mark peuvent être générés depuis les objets ADC.
Les flux de retour pour le trafic RELATED et ESTABLISHED sont reconnus automatiquement. Cela réduit la nécessité d'écrire des règles manuelles séparées pour chaque paquet de retour dans les services avec état.
Les limites de taux par source et les limites de connexion sont prises en charge. Les connexions excessives, les paquets reset, les paquets ICMP, les floods UDP DNS/NTP ou les tentatives de nouvelles connexions TCP depuis la même IP peuvent tous être délimités.
Bloquer ICMP entièrement peut altérer les fonctions réseau principales telles que IPv6 et Path MTU Discovery. TR7 gère les politiques ICMP avec granularité ; les messages de découverte et de contrôle nécessaires peuvent être gérés en toute sécurité.
Après que les règles défaillantes sont commentées, l'ensemble de règles final est réécrit sur le disque. Les opérateurs peuvent voir quelle ligne a été désactivée et la corriger. Le système produit un résultat visible et actionnable plutôt qu'un échec silencieux.
Les connexions SSH vers l'interface de gestion sont délimitées avec une limite par source. Si la même IP dépasse le seuil défini, elle est temporairement mise en quarantaine. La surface brute-force est réduite tandis que l'accès de gestion reste ouvert.
Seul le trafic des pays sélectionnés est autorisé ; tous les autres sont supprimés. Cela fournit un contrôle rapide pour la conformité et la réduction des risques par pays dans les systèmes financiers, du secteur public ou de santé.
Tandis que le DNAT 1.2.3.4 → 10.0.0.5 est appliqué dans le namespace du Tenant A, le Tenant B peut utiliser le même CIDR interne avec une règle différente. L'isolation des namespaces garantit que les politiques NAT des deux tenants ne sont pas en conflit.
Les comportements de flood UDP à octets zéro, de flood DNS/NTP, de TCP anormal, de fragment et de flood de connexions sont mitigés avec les mécanismes hashlimit, connlimit et quarantaine. La protection L3/L4 de base est appliquée sans appareil de scrubbing séparé.
Lorsque du trafic de transit est nécessaire entre deux segments backend, un passage contrôlé est établi avec des règles FORWARD. Quelle source peut atteindre quelle destination sur quel port est défini précisément.
Une IP backend est publiée via TR7 et le trafic entrant est délivré au backend concerné via DNAT inline. La couche de sécurité et de routage TR7 est insérée sans changer le plan IP de l'application ou du backend.
Isolation des namespaces, directives DDoS, DNAT/SNAT et génération automatique de règles — parcourons ensemble une configuration en direct dans votre propre environnement.