Sur cette page
À retenir
- Localiser la ressource épuiséeUn lien saturé, une table de connexions pleine et une application lente demandent des preuves et des réponses différentes.
- Conserver les règles utilesLa protection DDoS complète le contrôle d’accès ; désactiver le pare-feu n’est pas une stratégie de gestion d’incident.
- Mesurer la configuration réelleUn débit annoncé ne décrit pas tous les mélanges de paquets, fonctions d’inspection ou rythmes de création de connexions.
Un pare-feu a un emplacement et une capacité limités
Un pare-feu applique une politique d’accès, rejette du trafic indésirable et peut, selon le produit et sa configuration, proposer des fonctions DDoS dédiées ou une accélération matérielle. Affirmer que tous les pare-feu échouent face à toutes les attaques DDoS est inexact. Il faut identifier la ressource épuisée et vérifier si l’équipement peut agir avant sa saturation.
Un filtre placé derrière un accès saturé ne récupère pas les paquets légitimes perdus en amont. À l’inverse, un lien disposant encore de bande passante peut transmettre plus de paquets ou de nouveaux états qu’un système donné ne peut en traiter. Ces situations se ressemblent côté utilisateur, mais appellent des solutions différentes.
Distinguer quatre limites avant de modifier les règles
Recueillez ces mesures sur la même période et précisez leur point d’observation. L’entrée du pare-feu, sa sortie et un échantillon de flux en amont ne sont pas des vues interchangeables. Comparez une période saine à l’incident avant de faire d’un seul graphique votre diagnostic.
| Ressource | Mesures à recueillir | Ce qu’elles ne prouvent pas |
|---|---|---|
| Capacité de l’accès | Débits proposés et reçus, pertes en amont et erreurs d’interface. | Un faible débit reçu n’exclut pas des pertes avant le pare-feu. |
| Traitement des paquets | Paquets par seconde, pertes dans les files de réception et charge par cœur. | Une faible moyenne CPU n’exclut pas la saturation d’une file ou d’un worker. |
| États de connexion | Nouvelles connexions, entrées allouées, limites et échecs d’allocation. | Le nombre d’entrées seul n’identifie pas les sessions malveillantes. |
| Travail applicatif | Requêtes réussies, latence, échecs de connexion et charge des serveurs. | Une erreur HTTP seule ne démontre pas une attaque DDoS réseau. |
Placer chaque contrôle avant la ressource à protéger
Si l’accès est le facteur limitant, étudiez un filtrage en amont ou un chemin de livraison protégé. Si l’équipement lui-même sature, une règle sans état bien ciblée, un filtrage précoce pris en charge ou une mitigation spécialisée peuvent réduire le travail avant les traitements coûteux. Les abus applicatifs peuvent aussi nécessiter une authentification, des contrôles de requêtes ou un proxy compatible.
Préservez les règles d’accès nécessaires, l’administration et le trafic de contrôle. Les pare-feu diffèrent dans leur gestion des états, leurs accélérations et leurs fonctions DDoS : examinez la configuration réelle et les mesures correspondant aux fonctions activées. Les mots « matériel » ou « logiciel » ne suffisent pas à qualifier une charge.
Lire les compteurs d’état avant de choisir une correction
Sous Linux, nf_conntrack_count indique les entrées de flux allouées et nf_conntrack_max la limite configurée. Examinez-les avec les échecs d’allocation et le comportement du trafic. Une hausse peut correspondre à une activité légitime ; un faible nombre ne prouve pas que le reste de la pile réseau fonctionne correctement.
N’augmentez pas aveuglément les limites de connexion et ne réduisez pas tous les délais d’expiration. La mémoire consommée, les sessions établies et le comportement des protocoles comptent aussi. Journaliser chaque paquet pendant une attaque peut ajouter du travail et noyer les événements utiles. Préférez des compteurs bornés et les fonctions de journalisation adaptées à votre implémentation.
Exemple : 12 Mpps ne saturent pas forcément un lien de 10 Gbit/s
Considérons un flux hypothétique de 12 millions de trames Ethernet minimales par seconde. Avec 64 octets par trame, FCS compris, et 20 octets pour le préambule et le temps intertrame, l’occupation nominale du lien dans un sens est de 8,064 Gbit/s. Cela ne remplit pas à lui seul un lien de 10 Gbit/s. Des trames plus grandes, d’autres flux et la méthode de comptage peuvent modifier le résultat.
Ce calcul ne dit pas non plus si un pare-feu donné peut inspecter le flux. Il faut mesurer son chemin de traitement configuré et sa charge de suivi d’états. C’est un exemple de dimensionnement, pas un incident client ni un benchmark produit. Un pare-feu annoncé à 40 Gbit/s ne peut être déclaré adapté ou saturé sur cette seule valeur.
Définir la réussite au-delà du compteur de rejets
Établir une référence
Relevez les pics légitimes, tailles de paquets, nouvelles connexions et transactions applicatives réussies. Incluez la supervision et l’accès d’administration.
Reproduire la limite dans un cadre maîtrisé
Utilisez un chemin de test isolé et autorisé avec les règles prévues. Mesurez la charge proposée, le trafic légitime livré, les pertes et la latence ; ne surchargez pas un lien de production partagé pour en découvrir la limite.
Vérifier la livraison après filtrage
Confirmez que le trafic résiduel tient dans le lien récepteur et dans les capacités du pare-feu et de l’application. Observez les nouvelles connexions comme les sessions existantes.
Tester le retour arrière
Identifiez le responsable, le périmètre et la procédure de retrait. Vérifiez que retirer une règle rétablit la politique attendue sans exposer d’autres services.
Éviter les changements qui masquent la panne
- Un grand nombre de rejets ne signifie pas que le service est rétabli : vérifiez les actions réussies des clients.
- Ne désactivez pas tout le pare-feu pour contourner un problème de performances inexpliqué.
- Ne comparez pas un benchmark de transfert de grandes trames à une inspection avec état de petits paquets.
- Ne supposez pas que le filtrage amont élimine toutes les requêtes applicatives indésirables.
- Ne prenez pas la moyenne d’un incident court pour son pic de paquets ou de connexions.
Documenter le rôle de chaque couche de protection
Précisez quel composant gère les accès, réduit les paquets, modifie les routes et contrôle l’application. Conservez ses mesures de capacité et sa procédure de rétablissement. L’exploitation dispose ainsi d’un chemin d’escalade utile lorsque le prochain incident touche une autre ressource.
Questions et réponses
Un pare-feu peut-il arrêter certaines attaques DDoS ?
Oui, si son emplacement, ses ressources disponibles et ses fonctions conviennent à l’attaque. Un équipement local ne peut pas récupérer le trafic déjà perdu sur un chemin amont saturé.
Faut-il toujours augmenter la table de connexions ?
Non. Confirmez la pression sur les allocations, le coût mémoire et les besoins des sessions légitimes avant de changer les limites. Une table plus grande ne résout pas tous les problèmes de traitement ou d’application.
Le transit protégé remplace-t-il les règles du pare-feu ?
Non. La réduction du trafic en amont et le contrôle d’accès local ont des responsabilités différentes. Conservez et validez la politique nécessaire au service.
