Sur cette page
À retenir
- Protéger le chemin avant l’hôteUn filtre local ne récupère pas les paquets déjà perdus sur un accès amont saturé.
- Attribuer chaque décisionDes filtres qui se recouvrent et des états indépendants peuvent produire des résultats contradictoires.
- Observer la repriseCompteurs, versions et procédure d’annulation testée doivent suivre le chemin du trafic.
Attribuer une responsabilité à chaque couche
Une chaîne de filtrage dédiée est une succession de décisions, pas une liste de produits installés. Commencez par la ressource protégée par chaque couche. La mitigation amont peut réduire le trafic avant la saturation de l’accès. Les vérifications locales précoces peuvent écarter des paquets inadaptés avant des traitements plus coûteux. Les contrôles avec état appliquent une politique de connexion, tandis que l’application vérifie identité, autorisations et comportement des requêtes.
Ces fonctions peuvent résider dans une plateforme ou plusieurs, mais leurs limites doivent rester compréhensibles. Ajouter un filtre sans définir son rôle complique la localisation des faux positifs. Si deux couches suivent les connexions, précisez comment chacune voit l’aller et le retour et ce qui se passe lorsqu’un paquet arrive sur un autre worker ou nœud.
| Couche | Rôle | Preuves à conserver |
|---|---|---|
| Chemin amont | Réduire le trafic avant un lien de livraison limité. | Décision amont, compteurs d’entrée et de livraison, état de diversion. |
| Traitement précoce des paquets | Rejeter un trafic indésirable précisément défini avec un travail borné. | Compteurs de règles, pertes des files de réception et version exacte des règles actives. |
| Politique de connexion | Appliquer les règles d’accès et de suivi d’état au trafic pris en charge. | Connexions réussies, échecs d’allocation et observations du chemin retour. |
| Application | Vérifier les utilisateurs et les requêtes applicatives. | Opérations réussies, types d’erreur, temps de réponse et charge des serveurs. |
Placer les contrôles précoces dans le chemin réellement utilisé
Un programme XDP peut s’exécuter tôt dans un chemin de réception pris en charge, mais son mode d’attachement compte. Vérifiez le pilote, le mode natif ou générique et le comportement de redirection ou de transfert sur l’interface réelle. L’acceptation d’un programme par le vérificateur eBPF ne prouve ni la pertinence de son classement ni la capacité de l’hôte à atteindre un débit en paquets.
Un chemin de transfert en espace utilisateur peut avoir un autre modèle de gestion des interfaces. Un logiciel utilisant DPDK ou un rattachement particulier de la carte réseau doit être qualifié avec le reste de la configuration ; ne supposez pas que toutes les fonctions du noyau restent sur le chemin. Consultez le déploiement documenté du produit avant de l’associer à un autre plan de données.
Commencez par peu de règles, compréhensibles. Limitez le périmètre au trafic que vous exploitez, identifiez les paquets légitimes ressemblant à chaque motif et gardez un moyen de désactiver le changement. Une correspondance sans état trop large ne distingue pas toutes les requêtes légitimes d’une attaque simplement parce qu’elle s’exécute tôt.
Dimensionner le traitement, pas seulement la carte réseau
Paquets par seconde, octets sur le fil, répartition des flux et création d’états influencent la charge. RSS répartit le trafic selon les champs et le hachage pris en charge par la carte ; il ne garantit pas une distribution égale pour chaque attaque. Une file surchargée peut perdre du trafic pendant que d’autres cœurs restent disponibles. Vérifiez la disposition réelle des files et interruptions, l’affectation des workers et la proximité NUMA des interfaces.
En livraison en ligne, le trafic traverse des ressources d’entrée et de sortie. Nombre de ports, sens et marge comptent donc autant que la capacité mesurée du filtre. Un deuxième serveur réservé au secours ne double pas automatiquement la capacité utile dans le scénario de panne exigé. Dimensionnez la configuration qui doit survivre, puis mesurez avec les règles pertinentes activées.
Rendre les contrôles avec état compatibles avec le routage
Suivi de connexions, SYN proxy et filtrage de protocole nécessitent la visibilité attendue par leur implémentation. Si le retour contourne l’équipement responsable de l’état, une connexion légitime peut sembler incomplète. Plusieurs chemins actifs peuvent exiger un hachage cohérent, une synchronisation des états ou une alternative sans état prise en charge. Deux sessions BGP ne fournissent pas automatiquement ces propriétés.
Encapsulation, ECMP, NAT ou répartition de charge peuvent également changer le nœud qui observe un flux. Documentez-le avant d’activer une nouvelle fonction avec état. Pour Defense Fabric, vérifiez les exigences de routage documentées du mode TCP choisi et qualifiez la redondance avec ce mode actif. N’en déduisez pas une prise en charge universelle du routage asymétrique avec état.
Laisser les décisions applicatives au bon composant
Un filtre réseau peut réduire les paquets indésirables et appliquer les vérifications de protocole prises en charge. Il ne devient pas un système d’autorisation applicative par sa seule position devant un serveur. Conservez contrôle des connexions utilisateur, budgets de requêtes, règles d’accès à l’origine et supervision applicative là où le contexte nécessaire est disponible.
Pour l’hébergement de jeux, distinguez le protocole effectivement pris en charge d’une simple autorisation UDP. Minecraft Java et FiveM n’ont pas les mêmes chemins de livraison ni les mêmes étapes de validation. Testez l’établissement des connexions et le comportement normal du jeu, pas seulement la réponse d’une adresse. N’activez pas un profil sans rapport parce que son nom ressemble au service.
Suivre la même période d’observation à travers les couches
Étiquetez chaque graphique avec le point de mesure, le sens, l’échantillonnage et la période. Trafic proposé en amont, estimations de flux échantillonnés, compteurs des cartes et requêtes applicatives ne sont pas les mêmes mesures. Une baisse à un niveau peut signifier filtrage réussi, perte antérieure, changement de route ou panne du collecteur. Croisez les preuves avant d’identifier la cause.
Consignez les versions de configuration actives et l’heure d’application des changements. Préférez des compteurs bornés à la journalisation de chaque paquet rejeté pendant une attaque. Si la télémétrie disparaît, distinguez absence d’observation et absence de trafic. Vérifiez séparément la reprise du collecteur et celle du transfert.
Qualifier les changements par étapes
Defense Fabric, Transit IP protégé et Flow Collector peuvent intervenir à différents endroits de cette architecture. Licence logicielle, transport et collecte de télémétrie nécessitent toujours des qualifications distinctes. Un test réussi sur un hôte constitue une preuve pour cet hôte et cette charge, pas une garantie publiée de capacité pour tous les clients.
Cartographier le chemin existant
Relevez interfaces, routage, responsables des règles et réussite applicative avant de modifier la chaîne.
Tester un contrôle à la fois
Utilisez un trafic représentatif dans un environnement isolé et autorisé ; vérifiez le comportement légitime autant que les rejets.
Tester la panne et l’annulation
Exercez la perte de nœud ou de chemin convenue et vérifiez le suivi d’état ainsi que le rétablissement.
Conserver une recette versionnée
Gardez ensemble logiciel, matériel, règles, observations et limites restant à vérifier.
Questions de déploiement
Peut-on ajouter XDP devant n’importe quelle application DPDK ?
Ne le supposez pas. Gestion des interfaces, mode du pilote et chemin de réception dépendent du déploiement. Vérifiez l’architecture prise en charge avant de combiner les plans de données.
Un deuxième filtre améliore-t-il toujours la protection ?
Non. Il doit avoir un rôle défini et un comportement de routage et d’état compatible. Sinon, il peut ajouter de la latence, des faux positifs ou de l’ambiguïté opérationnelle.
Qu’est-ce qui prouve que la chaîne est prête ?
Une recette reliant chemin réel, tests de service légitime, charge représentative isolée, comportement en panne et procédure d’annulation — pas seulement une vitesse de port.
