Lorsque l'ADC et le pare-feu sont gérés séparément, la chaîne de sécurité se brise.
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.
Notre approche
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.
Gestion du pare-feu par namespace
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.
Pipeline test → apply
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.
Ensembles de règles IPv4 et IPv6 parallèles
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.
Règles de pare-feu automatiques depuis les objets ADC
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é.
Capacités
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, le CGNAT déterministe et l'isolation des namespaces.
Isolation de pare-feu par namespace
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.
CGNAT déterministe — traçabilité de l'abonné sans journal de sessions
Chaque abonné reçoit un bloc fixe et pré-calculé de ports publics : identifier un abonné à partir d'une adresse et d'un port publics relève de l'arithmétique, pas d'une requête en base. La journalisation par session qu'impose sinon la RFC 6888, et qui domine d'ordinaire le coût d'un déploiement CGNAT, disparaît, la traçabilité légale restant intacte. Les ALG FTP, TFTP, SIP, PPTP et H.323 sont inclus. Le filtrage indépendant du point d'extrémité et le hairpinning sortent du périmètre de cette version.
Gestion séparée IPv4 et IPv6
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.
NAT double pile, NAT66 compris — une règle, deux familles d'adresses
Le même moteur de règles produit les jeux IPv4 et IPv6 à partir d'une seule politique : SNAT statique, DNAT et traduction un-à-un se comportent à l'identique sur un réseau IPv6. La traduction entre préfixes IPv6 — NAT66 — en fait partie, et nous le disons clairement car on la suppose généralement absente. Il n'existe pas de chemin de configuration IPv6 distinct, ni de règle qui ne s'applique discrètement qu'à une seule famille : c'est ce qui empêche une migration IPv6 de devenir un second pare-feu à moitié oublié.
Définition de règles par interface
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.
Règles allow, deny, forward et not-forward
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.
Prise en charge DNAT et SNAT
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.
Correspondance GeoIP et par pays
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.
Correspondance CIDR, MAC et négation
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.
Correspondance multi-ports et plage de ports
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.
20+ directives de protection DDoS
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.
Tables de quarantaine
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.
Prise en charge des connection marks pour la persistance L4
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.
Règles ADC/GTM/NAT automatiques
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.
Isolation des règles défaillantes
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.
Prise en charge des logs et de l'audit
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é.
Protection automatique pour les interfaces de gestion et de synchronisation de cluster
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.
Profondeur opérationnelle
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.
Chemin de configuration et séparation des ensembles de règles
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.
Timeout de synchronisation et application sécurisée
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.
Synchronisation parallèle des namespaces
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.
Types de règles automatiques
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.
Connection tracking
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.
Hashlimit et connlimit
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.
ICMP et découverte de voisins IPv6
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é.
Ensemble de règles final après récupération d'erreur
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.
Quand l'utiliser
Réduction des tentatives SSH brute-force sur l'interface de gestion
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.
Politique d'accès par pays
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é.
Séparation DNAT multi-tenant
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.
Mitigation DDoS intégrée
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é.
Transit contrôlé entre segments via la chaîne FORWARD
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.
Publication DNAT inline
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.
Questions fréquentes
Quelle est la différence entre un pare-feu par namespace et un pare-feu global ?
Si une règle défaillante est écrite, l'ensemble du pare-feu est-il affecté ?
Les règles IPv6 sont-elles gérées séparément des règles IPv4 ?
Un appareil séparé est-il requis pour la protection DDoS ?
Les règles de pare-feu peuvent-elles être générées automatiquement depuis les objets ADC ?
Comment fonctionne la correspondance GeoIP et affecte-t-elle les performances ?
Gérez la sécurité réseau depuis la même console que votre ADC
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.