Sur cette page
À retenir
- Observer toute la chaîneRoutage, trafic reçu, compteurs des règles et résultats applicatifs doivent couvrir la même période.
- Confirmer l’effet du changementUne demande acceptée ou une règle annoncée ne suffit pas à prouver une modification du chemin de données.
- Préparer le retrait et l’activationUne protection temporaire demande un responsable, une condition de réévaluation et un retour contrôlé au fonctionnement normal.
1. Acheminer le trafic autorisé vers la protection
La première tâche consiste à faire traverser au trafic concerné l’infrastructure de protection prévue. Un déploiement routé peut utiliser des annonces de préfixes et des politiques convenues. Pour un service spécialisé, l’adresse publique peut déjà mener à une entrée protégée. Le mécanisme doit correspondre aux droits du client et du fournisseur.
Les modèles permanents et à la demande ont des transitions différentes. Pour une activation à la demande, identifiez le demandeur autorisé, les destinations éligibles, la confirmation du changement et le responsable du retrait. L’acceptation d’une requête API ne prouve pas que les routes sont choisies ou que le trafic atteint le filtrage.
Observez routage et trafic reçu pour les mêmes destinations et la même période. Vérifiez séparément le retour. Un tunnel transporte des paquets entre deux extrémités, mais ne démontre pas à lui seul que le trafic Internet souhaité a été acheminé vers lui.
2. Construire une observation du trafic étayée
Comparez volume, débit de paquets, protocoles, tailles et comportement des connexions lorsque le déploiement expose ces données. Conservez heure, sens, destination et frontière de mesure avec chaque chiffre. Un enregistrement de flux échantillonné et un compteur exhaustif ne constituent pas la même preuve.
Utilisez une référence de trafic normal adaptée. Un événement populaire, des tentatives répétées et une attaque peuvent tous augmenter l’activité : le dépassement d’un seuil demande du contexte. Identifiez le service touché et si l’échec concerne les sessions existantes, nouvelles ou certains réseaux clients.
La télémétrie décrit ce qu’un capteur voit. Une donnée absente ou retardée ne prouve pas l’absence de trafic. Notez les angles morts et ne considérez pas un capteur calme comme la preuve de la fin de l’incident.
3. Appliquer une politique dont le périmètre est vérifiable
Une décision de mitigation doit préciser cible, conditions de correspondance, action, responsable et condition de réévaluation. L’objectif est de réduire la charge nuisible tout en préservant les échanges légitimes requis. Davantage de paquets bloqués ne démontre pas, à lui seul, une meilleure politique.
La distribution dans le plan de contrôle et l’application effective sont des observations distinctes. BGP FlowSpec distribue des critères de trafic et des actions, mais la politique et l’implémentation du récepteur déterminent leur acceptation et application. Vérifiez la règle installée et ses compteurs plutôt que de supposer une application partout.
Apportez des changements proportionnés au problème et conservez un retour arrière autorisé. Un blocage large peut réduire la charge tout en supprimant un service légitime. Si le filtrage local atteint sa limite, coordonnez une réduction en amont selon le service convenu au lieu de supposer une capacité logicielle illimitée.
4. Livrer le trafic conservé par un chemin utilisable
Confirmez que le trafic sortant du filtrage atteint la destination par la livraison prévue. Vérifiez adressage, prochain saut, encapsulation et retour. Un compteur de transfert positif sur un équipement ne prouve pas qu’un échange applicatif a abouti à distance.
Validez le MTU requis sur chaque chemin principal et de reprise. Des échanges applicatifs plus grands peuvent révéler des problèmes invisibles aux petites sondes. TCP, UDP et les fonctions applicatives demandent des recettes adaptées ; régler la MSS TCP ne résout pas universellement tous les protocoles.
Si l’origine doit être accessible uniquement par une entrée protégée, contrôlez cette frontière d’accès lors de la livraison. Changer un nom public ne supprime pas les autres chemins vers une origine exposée. Coordonnez la vérification avec le responsable du réseau de destination.
5. Garder un relevé d’incident utile aux deux équipes
Comparez observations du fournisseur et symptômes clients sur une période commune. Notez destinations touchées, règles actives, changements de routage et dernier contrôle applicatif réussi. Séparez les observations des hypothèses pour que l’ingénieur suivant puisse reprendre le raisonnement.
Conservez un canal de communication convenu qui ne dépende pas entièrement du service dégradé. Précisez qui autorise les changements et qui vérifie l’application. L’état affiché par la supervision et l’engagement contractuel de réponse sont différents : utilisez les conditions réelles du support.
| Étape | Preuve de progression | Résultat insuffisant à lui seul |
|---|---|---|
| Acheminement | Routes attendues et trafic à l’entrée prévue | Demande d’activation acceptée |
| Classification | Compteurs et symptômes sur la même période | Une alarme de seuil isolée |
| Application des règles | Politique acceptée ou installée et compteurs d’effet pertinents | Règle annoncée par un contrôleur |
| Livraison | Échange applicatif par la livraison et le retour prévus | Tunnel ou BGP actif |
| Reprise | Contrôles applicatifs stables et règles temporaires revues | Graphique de trafic proche de la normale |
6. Retirer les mesures temporaires de façon contrôlée
Convenez d’une condition de réévaluation pour les changements temporaires de routage et de filtrage. Gardez la visibilité en rétablissant le chemin normal : cette transition peut révéler une autre panne ou le retour de l’attaque. Notez ce qui reste actif et pourquoi.
Vérifiez la reprise depuis des réseaux touchés représentatifs et depuis une référence fonctionnelle. Testez séparément nouvelles sessions et sessions existantes lorsque le service l’exige. Retirez les restrictions obsolètes par une séquence autorisée plutôt que d’effacer toutes les protections d’urgence à la fois.
Répéter le processus avant d’en dépendre
Un exercice de recette peut vérifier autorisations, contacts, observations de routage, transition contrôlée et échange applicatif normal. Il n’exige pas de produire du trafic d’attaque. Définissez périmètre, condition d’arrêt et responsable de reprise, en préservant les services étrangers à l’exercice.
Les benchmarks de capacité exigent un plan isolé distinct précisant matériel, logiciel, trafic et critères d’acceptation. Ne présentez pas une activation réussie comme un benchmark Gbit/s ou Mpps. Ne promettez pas non plus qu’une mesure sur un équipement couvre des dépendances amont ou de bascule non testées.
Questions sur la chaîne d’exploitation
Un tunnel actif signifie-t-il que la protection fonctionne de bout en bout ?
Non. Confirmez acheminement, règles pertinentes, livraison et échange applicatif réussi. Les états de tunnel et de BGP sont des observations utiles, de portée plus limitée.
Flow Collector filtre-t-il les paquets directement sur leur chemin ?
Non. Le périmètre publié de Peeryx Flow Collector couvre télémétrie, détection et déviation contrôlée pour des préfixes éligibles et autorisés. Le filtrage dans le chemin de données est un autre rôle.
Quand peut-on considérer le service rétabli ?
Lorsque les contrôles convenus réussissent, que les règles restantes sont comprises et que le chemin normal ou temporaire approuvé est stable. Un graphique de bande passante seul ne le démontre pas.
