Guide de déploiement Defense Fabric

Le rôle du logiciel

Defense Fabric exécute la détection, le filtrage des paquets et la gestion des politiques sur vos serveurs. La capacité locale dépend de ces machines et de leurs liaisons. Le logiciel ne fournit pas la capacité amont du transit IP protégé Peeryx.

Flow Collector est un outil gratuit distinct, consacré à l’observation et à la diversion. Il ne remplace pas le moteur de filtrage Defense Fabric. Le transit Peeryx est le service réseau livré séparément qui permet de filtrer le trafic en amont.

Serveur et système d’exploitation

L’installateur actuel cible Debian 12 et le module de filtrage distribué est destiné à x86-64. TPM 2.0 est requis pour la licence liée à la machine. L’installateur fixe VPP et ses modules à la version 25.10-release ; ne substituez pas une autre ABI VPP lors d’une mise à jour du système.

• Prévoyez un accès d’administration indépendant, un DNS fonctionnel, une horloge correcte et un accès HTTPS sortant pour l’inscription, les contrôles de licence et les mises à jour signées.
• Vérifiez ensemble le processeur, les canaux mémoire peuplés, le placement NUMA, la largeur PCIe, la référence exacte de la carte réseau, son firmware, son pilote et les optiques. Le nom d’une famille ConnectX ne suffit pas à valider la compatibilité.
• Séparez l’administration des interfaces de trafic. Réservez les ressources CPU, mémoire et stockage nécessaires au moteur, à la collecte de flux et à la conservation des éléments d’analyse.

Dimensionnement et mesures de performance

Utilisez les Gbit/s et les Mpps conjointement. À 100 Gbit/s, des trames Ethernet de 64 octets représentent environ 148,81 Mpps en comptant le préambule et l’intervalle entre trames. Il s’agit d’un calcul de débit de ligne, pas d’un résultat de filtrage. Deux ports ne garantissent pas le double de capacité de bout en bout.

Les configurations matérielles publiées sont des candidates à qualifier. Aucun rapport de performance reproductible n’est publié pour ces configurations. Testez la machine exacte avec les règles prévues, différentes tailles de paquets, du trafic légitime simultané et la mitigation active. Mesurez les pertes, la latence et la reprise, en plus du débit.

Licences, ports et serveurs

La licence de base comprend un port 10G. Les ports achetés forment un ensemble partagé entre les serveurs gérés par la licence ; installer un second serveur ne les duplique pas. Allouez à chaque serveur le nombre et la vitesse de ports nécessaires avant l’exploitation payante. La limite de gestion est de 128 serveurs par licence.

L’essai de 14 jours ne fixe pas de quota logiciel sur le nombre de ports ou leur vitesse déclarée. Il ne supprime ni les limites physiques, ni la qualification matérielle, ni les conditions d’activation réseau. Ajouter un serveur ne relance pas l’essai.

La validité de la licence, l’identité du serveur et la disponibilité du routage sont des contrôles distincts. Après l’essai, le paiement et des droits valides sont nécessaires à la poursuite de l’exploitation sous licence. L’espace client affiche l’expiration et l’état du renouvellement applicables.

Installation et inscription du serveur

Commencez sur la page Defense Fabric de votre compte client. Créez ou sélectionnez la souscription, ajoutez le serveur et générez son jeton d’inscription à usage unique et durée limitée. Suivez les instructions associées à ce serveur ; conservez son identité et son jeton de façon privée.

L’installateur vérifie Debian 12, la disponibilité du TPM et la version VPP requise. Un moteur réseau tiers déjà actif exige une migration : préparez une maintenance au lieu d’installer par-dessus. La vérification des versions signées et l’inscription réussie ne prouvent pas que le trafic client est protégé.

• Notez la version installée et vérifiez le résultat de l’installation.
• Contrôlez séparément la connexion au panel, le moteur de filtrage, les ports alloués et les compteurs d’interfaces.
• Conservez l’observation tant que les chemins d’acheminement et de retour n’ont pas été testés.

Interfaces et retour du trafic propre

Identifiez l’entrée recevant le trafic à filtrer et l’interface logique distincte qui renvoie le trafic propre. Confirmez les VLAN, adresses, passerelles, MTU et accessibilité des prochains sauts sur le routeur et le serveur. Ne confondez pas les compteurs d’administration Linux avec ceux des ports de filtrage.

Vérifiez que le trafic détourné ne peut pas revenir en boucle sur l’entrée sale. Les adresses de contrôle et des passerelles propres doivent rester hors des plages de destination protégées. Mesurez le trafic client réel dans les deux sens avant de déclarer le chemin validé.

Inline, diversion BGP ou hybride

Inline : le trafic traverse en permanence le chemin de filtrage local. Validez le comportement en cas de panne du serveur, d’une interface ou de l’alimentation ; l’installation du logiciel ne crée pas de bypass physique.

Diversion BGP : le routeur dirige les destinations attaquées sélectionnées vers le prochain saut de filtrage. Définissez les filtres d’import/export et les communautés, puis vérifiez les annonces, l’installation dans la FIB, le retour propre et le retrait. Les délais d’export et la convergence influencent le temps de réaction.

Hybride : associez le filtrage local au transit protégé Peeryx pour intervenir en amont. Le service de transit exige son activation, des préfixes autorisés et un chemin de livraison testé. L’achat d’une licence ne modifie pas, à lui seul, votre routage amont.

BGP, FlowSpec et RTBH

Renseignez le router ID, les adresses locale et distante, les ASN, un prochain saut de filtrage joignable et la communauté de diversion convenue. Le contrôle de routage du panel autorise les sessions et annonces gérées par l’agent ; enregistrer un brouillon ne confirme pas l’installation de la route attendue sur le routeur.

FlowSpec exporte des règles amont ciblées uniquement lorsqu’il est activé, que la simulation est désactivée et que la famille BGP correspondante est établie. Commencez en simulation, inspectez les règles générées et vérifiez les capacités du routeur. Le panel limite à 50 le nombre de règles simultanées.

RTBH est un dernier recours qui supprime tout le trafic destiné à la cible, y compris le trafic légitime. Traitez séparément son seuil, son délai de persistance et sa durée avant retrait, puis testez la reprise.

sFlow, NetFlow et IPFIX

Activez la collecte sur une adresse joignable par vos exportateurs autorisés, de préférence via un réseau privé ou un VPN. Le port récepteur par défaut est UDP 6343 ; faites correspondre le port configuré des deux côtés et restreignez les sources autorisées. N’exposez pas un collecteur sans restriction sur Internet.

Vérifiez l’échantillonnage et les délais d’export avant de choisir les seuils de détection. sFlow fournit son propre taux ; le multiplicateur configuré sert à NetFlow/IPFIX lorsque l’exportateur ne le fournit pas. La fenêtre de collecte se règle de 5 à 60 secondes.

Comparez les débits estimés aux compteurs d’interfaces et vérifiez leur fraîcheur. L’absence d’exports ne prouve pas que le trafic ou l’attaque s’est arrêté. Les captures et les estimations de flux décrivent des observations différentes.

Préfixes, seuils et retour à la normale

Les politiques protègent des blocs IPv4 /24 enregistrés et des exceptions /32 appartenant à ces blocs. Analysez le trafic normal avant d’appliquer un profil. Dans cette version, les seuils de détection par protocole et destination sont exprimés en PPS ; les réglages en Gbit/s de FlowSpec et RTBH correspondent à leurs décisions de capacité distinctes.

Le mode Monitor observe sans diversion d’attaque. Automatic détourne le trafic pendant les attaques détectées. Permanent maintient le chemin de filtrage validé. Réglez le seuil de sortie sous le seuil d’entrée et utilisez une durée de maintien pour limiter les changements répétés de routes.

Un profil charge des seuils par protocole. Il ne constitue pas une liste d’applications autorisées, et un profil plus strict n’est pas automatiquement adapté à un réseau plus chargé.

Règles adaptatives et protection TCP/UDP

La détection adaptative peut évaluer les signatures en observation ou appliquer les règles générées en mode actif. Examinez la signature enregistrée et son effet sur le trafic légitime avant de l’exclure ou de changer de moteur d’exécution. Le moteur disponible doit correspondre à la version installée et au matériel qualifié.

SYN proxy valide l’établissement des connexions et exige un chemin symétrique testé. SYN challenge correspond au cas asymétrique pris en charge. Ces réglages ne sont pas interchangeables : le panel empêche les combinaisons incompatibles. La validation spécifique SYNACK exige également le chemin symétrique documenté.

Les quotas par source limitent les paquets UDP ou le total SYN/SYNACK par IP source sur les préfixes qui les activent. Des utilisateurs derrière NAT, VPN ou proxy peuvent partager une même IP ; prenez en compte leur trafic normal cumulé pour définir le quota.

Exceptions et pare-feu après filtrage

Utilisez les exceptions /32 pour les hôtes particuliers d’un /24 enregistré. Gardez-les précises et documentées. Une règle accept s’applique à l’étape de pare-feu après filtrage ; elle n’annule pas les rejets précédents et ne garantit pas le contournement des autres protections.

Le panel accepte jusqu’à 20 priorités ordonnées de pare-feu par préfixe. Vérifiez le protocole, la plage source, les ports de destination et les unités de débit avant application. Les sélecteurs de ports TCP/UDP n’ont pas de sens pour tous les protocoles IP.

Panel, rapports et accès API

Lisez séparément la connexion au panel, l’état du moteur, les sessions BGP et la disponibilité de la protection. Un agent connecté ou un processus démarré ne constitue pas un test d’acheminement réussi. Les statistiques récentes sont échantillonnées ; une mesure périmée doit être examinée plutôt que traitée comme un trafic nul.

L’historique des attaques, les règles de mitigation enregistrées et les exports PCAP, ZIP ou PDF disponibles aident à expliquer un incident. La rétention et l’échantillonnage limitent les reconstitutions ; un export n’est pas nécessairement une capture complète de l’attaque.

Consultez la référence OpenAPI publique pour les opérations et droits disponibles. Les opérations exigent une authentification : limitez les jetons au compte et aux permissions nécessaires. Les écritures de politique utilisent une révision et renvoient un état en attente d’application ; vérifiez l’état du serveur avant de considérer le changement appliqué. N’automatisez pas les composants internes du panel.

Plusieurs serveurs et ECMP

Une licence partagée et un second serveur ne créent pas automatiquement une réplication d’état ou de la haute disponibilité. Définissez la détection de panne, la préférence des routes, leur retrait et la reprise pour l’architecture complète, puis testez chaque panne séparément.

Le second lien pris en charge utilise un iBGP directement connecté avec le même ASN et des VLAN sales/propres séparés. Il exige Fabric 2.8.0 ou plus récent. Chaque session annonce son prochain saut local. ECMP répartit les flux ; un même flux peut rester sur un seul lien.

SYN proxy et SYNACK challenge ne sont pas qualifiés pour ce mode à deux chemins. Deux liens 100G ne garantissent pas 200 Gbit/s de filtrage.

Mises à jour et restauration de configuration

Utilisez le mécanisme de mise à jour signé proposé dans le panel. Planifiez une maintenance : la mise à jour peut redémarrer le moteur de filtrage. Confirmez la version attendue et conservez un accès indépendant avant de commencer.

Le programme vérifie la version, conserve la configuration et prépare les fichiers de reprise. Si l’installation échoue, examinez les diagnostics et l’état restauré ; un retour à la version précédente ne prouve pas, à lui seul, la reprise de tous les chemins réseau.

Avant de modifier les politiques, conservez la configuration concernée et comparez les changements proposés. Gardez sauvegardes et identifiants privés. Validez la politique restaurée avec le logiciel en cours d’exécution avant d’y renvoyer du trafic détourné.

Recette avant mise en production

Définissez le test de recette et les conditions de retour arrière avant de détourner des services actifs. Utilisez du trafic que vous êtes autorisé à générer et une destination de test maîtrisée.

• Référence : comparez trafic normal, compteurs, pertes et accessibilité applicative avec la protection inactive puis active.
• Détection : testez un événement limité et vérifiez qu’il affecte uniquement la destination, la règle et la route prévues.
• Reprise : arrêtez l’événement, attendez la durée de maintien et confirmez le retrait des règles et le retour de l’acheminement.
• Panne : testez séparément la perte d’export, du BGP et du serveur de filtrage. Confirmez le chemin observé et le comportement ouvert ou fermé de l’architecture.
• Conservez la version, le serveur, la carte réseau, les tailles de paquets, le nombre de règles, l’échantillonnage, la durée du test, les pertes et la latence. Gardez la preuve du fonctionnement et du retour arrière.

Diagnostiquer la couche en défaut

Sans contact avec le panel : vérifiez l’administration, le DNS, l’horloge, l’accès HTTPS, l’identité et la licence. Ne modifiez pas le BGP de production pour simplement rétablir l’administration.

Moteur démarré mais absence de trafic protégé : contrôlez interfaces de filtrage, VLAN, prochains sauts et compteurs RX/TX réels. Vérifiez la FIB du routeur et le retour propre indépendamment de l’état de la session BGP.

Mitigation inattendue : comparez le débit normal mesuré, l’échantillonnage, le profil choisi et la règle enregistrée. Ajustez un brouillon, examinez le changement et appliquez-le volontairement. Collectez les diagnostics avant de redémarrer des processus ou de retirer des routes.

Limites connues

Ce guide décrit la version Debian 12/x86-64 distribuée et le parcours de protection IPv4. Il ne certifie pas les autres systèmes, toutes les cartes réseau, une équivalence des politiques IPv6, une bascule sans perte ou un résultat donné en Mpps.

Le filtrage local ne récupère pas une bande passante déjà saturée en amont. Le transit Peeryx permet, séparément, de déplacer le filtrage en amont ; Flow Collector peut accompagner une architecture à la demande validée distinctement.

Les protections SYN, ECMP et le routage automatique ont chacun des conditions de compatibilité. Une combinaison non testée relève de la qualification, pas d’un service déjà actif.