Sur cette page
À retenir
- Tracer les deux sens du traficL’arrivée du trafic, sa livraison après filtrage et le retour applicatif peuvent avoir des contraintes différentes.
- Distinguer observation et filtrageUn collecteur de flux mesure le trafic ; un autre composant doit appliquer les décisions aux paquets.
- Prévoir maintenance et défaillancesUn second nœud n’est utile que si le routage, la capacité et les procédures permettent réellement le secours prévu.
Partir du chemin réellement emprunté
Une architecture DDoS utile commence par les destinations protégées, leurs chemins amont et la première ressource susceptible de saturer. Tracez le chemin entrant normal, celui utilisé pendant la mitigation et le retour. Indiquez chaque liaison limitée et qui est autorisé à annoncer, détourner ou retirer chaque préfixe.
Le schéma doit expliquer le trajet d’une requête légitime jusqu’à la réponse applicative. S’arrêter à un nuage de scrubbing masque le lien récepteur, le tunnel, le pare-feu et le serveur qui doivent encore traiter le trafic résiduel.
Distinguer quatre responsabilités
Ces fonctions peuvent partager un produit, mais demandent chacune une validation. Voir une route dans BGP ne démontre pas à lui seul que le filtre applique la règle voulue. Recevoir de la télémétrie de flux ne place pas le collecteur dans le chemin des paquets.
| Fonction | Résultat ou action | Preuve de validation |
|---|---|---|
| Observer et détecter | Échantillons, compteurs, alertes ou incident potentiel. | Point d’observation, échantillonnage, délai et comportement en cas de données manquantes connus. |
| Décider et orienter | Modification autorisée d’une route ou d’une politique. | Périmètre, validation, convergence et procédure de retrait. |
| Inspecter et filtrer | Transfert, rejet ou limitation de paquets prise en charge. | Politique installée, compteurs de décision et réussite du service légitime. |
| Livrer et servir | Le trafic filtré atteint l’application et les réponses reviennent. | Capacité, MTU, routage, latence et contrôles applicatifs. |
Choisir l’emplacement selon la limite réelle
La mitigation amont est pertinente lorsque le trafic proposé peut saturer l’accès client. Le filtrage local convient à un opérateur disposant de suffisamment de capacité entrante et souhaitant contrôler les décisions sur ses équipements. Une architecture hybride peut associer les deux, mais ajoute des interactions de politiques et de pannes dont quelqu’un doit être responsable.
Un proxy applicatif peut convenir à un protocole et à un mode de livraison pris en charge. Il n’est pas interchangeable avec la protection d’un préfixe routé quelconque. Un contrôle HTTP ne couvre pas non plus tous les services UDP ou TCP. Listez les applications et familles d’adresses au lieu de considérer « Layer 7 » comme une capacité universelle.
Le permanent et l’à-la-demande ne se testent pas pareil
Dans une architecture permanente, le trafic normal emprunte continuellement le chemin protégé. Validez sa latence quotidienne, le routage retour, la maintenance et sa capacité. À la demande, mesurez aussi les délais de détection, de décision et de changement de route ; la transition peut affecter les sessions même si le chemin final fonctionne.
Prévoyez une hystérésis et une procédure de retour explicite pour éviter les activations et retraits répétés autour d’un seuil. Les données absentes ou périmées nécessitent une réponse définie. L’opérateur doit savoir si la route reste en place, est retirée ou demande une intervention ; tous les contrôleurs ne se comportent pas de la même façon.
Peeryx Flow Collector observe hors du chemin des paquets et coordonne la dérivation ; il ne filtre pas en ligne. Sa dérivation automatique concerne des préfixes IPv4 /24 autorisés. L’éligibilité, les permissions de routage et le service protégé doivent être vérifiés séparément ; cela n’implique pas une dérivation IPv6 automatique.
Exemple : réduction en amont et règles locales
Supposons un opérateur recevant le trafic sur un lien de 10 Gbit/s, avec des applications derrière un pare-feu local. Si le trafic entrant dépasse ce lien, ajouter un filtre plus puissant derrière ne déplace pas le point de perte. Un chemin protégé en amont peut traiter cette contrainte, tandis que la couche locale conserve la politique d’accès applicative.
Pour une livraison GRE, documentez le chemin externe, la MTU interne effective et les routes de retour. Testez des transferts assez grands pour révéler les problèmes de MTU ; un petit ping ne suffit pas. Les contrôles avec état peuvent exiger que les deux sens traversent un chemin compatible avec cet état. C’est un exemple de conception, pas une promesse de dérivation sans interruption.
Rendre la recette vérifiable
Prouver l’autorisation et la connectivité
Confirmez la propriété des préfixes ou l’autorisation, les annonces acceptées, les prochains sauts et chaque famille d’adresses requise. Vérifiez les chemins normal et protégé depuis des points indépendants.
Qualifier la capacité en cas de panne
Mesurez le mélange de trafic avec les fonctions prévues. Tenez compte d’une répartition inégale, des liens récepteurs et de la perte du nœud ou de l’uplink que l’architecture doit tolérer.
Tester l’application
Testez les sessions nouvelles et établies, les protocoles concernés, les transferts sensibles à la MTU et le retour. Observez les réussites légitimes avec les compteurs de mitigation.
Répéter le rétablissement
En environnement isolé ou pendant une maintenance convenue, testez la panne de processus, de lien ou de nœud prévue. Notez la convergence, l’impact sur les sessions, le retour arrière et l’accès d’administration.
L’étiquette « backup » n’est pas un résultat de bascule
- Deux tunnels sur le même routeur physique ne protègent pas d’une panne de ce routeur.
- Une session BGP de secours établie ne prouve pas que des routes utilisables et le bon transfert seront sélectionnés à la disparition du principal.
- Un bypass peut maintenir la connectivité en contournant le filtre ; vérifiez l’état de protection obtenu.
- Deux liens de même débit ne garantissent ni une répartition égale ni le double de capacité pour un flux unique.
- Une bascule fonctionnant pour des paquets sans état peut interrompre des sessions dépendant d’un état partagé.
Conserver un dossier d’exploitation court
Le dossier de livraison doit contenir la topologie, le périmètre protégé, les hypothèses de capacité, les résultats de recette, les responsables des alertes et le retour arrière. Séparez le comportement prévu des résultats observés. Refaites les tests concernés après une modification de routage, de logiciel ou de chemin physique.
Questions et réponses
Un collecteur filtre-t-il le trafic qu’il affiche ?
Pas nécessairement. La télémétrie peut être exportée vers un observateur hors du chemin de transfert. Identifiez le composant distinct qui inspecte ou rejette réellement les paquets.
Un second tunnel garantit-il la redondance des routeurs ?
Non. Vérifiez les équipements physiques, les chemins sous-jacents, les routes sélectionnées et le scénario de panne testé. Deux tunnels peuvent partager le même point de défaillance.
Un ping réussi valide-t-il toute l’architecture ?
Non. Il ne confirme qu’un test de connectivité limité. Validez les tailles de paquets utiles, les applications, la charge, les retours et la procédure de panne prévue.
