Cookies nécessaires
Conditions de déploiement
Protection DDoS pour FAI et opérateurs réseau
Protéger un réseau d’accès consiste à préserver les chemins partagés par de nombreux abonnés tout en gardant la maîtrise des routes et du comportement des connexions. Commencez par les préfixes exploités et la ressource qui cède en premier.
Trois limites comptent dans un réseau d’accès
- Liens partagés et cibles réparties
- Une attaque répartie sur plusieurs adresses d’abonnés peut charger un lien commun sans qu’une destination domine le graphique. Observez le trafic par préfixe et par amont, en plus des adresses individuelles ; un point d’accès calme ne prouve pas que le chemin agrégé dispose de marge.
- État des connexions et adresses sources partagées
- Le CGNAT et les équipements de bordure à état peuvent subir une pression sur les connexions indépendamment du débit. De nombreux utilisateurs légitimes peuvent aussi partager une IP publique source. Une limite par source doit donc être étudiée selon les usages, plutôt que fixée très bas pour tous les abonnés.
- Plusieurs responsables du routage
- Vos préfixes, les annonces de clients et les adresses fournies par un opérateur peuvent relever de règles d’autorisation et d’export différentes. Définissez le périmètre protégé, les annonces acceptées et les attentes concernant la route par défaut avant d’ajouter un chemin de protection.
Associer livraison amont et contrôles sous votre responsabilité
Le Transit IP protégé peut fournir la couche réseau ; un filtrage local compatible peut remplir un autre rôle derrière celle-ci. Une architecture hybride exige toujours des responsables identifiés pour la déviation, le filtrage et la restauration.
Observer les chemins exposés
Collectez la télémétrie des routeurs et les compteurs d’interfaces pertinents, avec un intervalle et un sens de mesure connus.
Livrer le trafic protégé
Validez le tunnel ou la remise physique convenus, la sélection des routes, le MTU et la capacité de livraison restante.
Préserver le service des abonnés
Vérifiez le retour et les usages normaux avec les modes TCP et les fonctions à état retenus localement.
Exemple de cheminement. Le devis et le procès-verbal de recette définissent le service livré.
Décisions à prendre avant la commande
- Qui peut annoncer les préfixes protégés ?
- Documentez l’ASN, les autorisations, les filtres de routes et la propagation permise. L’état d’une session BGP ne prouve pas que les routes prévues sont acceptées.
- Le retour peut-il contourner le filtre local ?
- Cela dépend du mode de protection choisi. Validez ses exigences de routage avant d’activer les fonctions à état ; plusieurs voisins BGP ne démontrent pas une prise en charge de l’asymétrie.
- Qu’est-ce qui peut déclencher une déviation ?
- Distinguez observation, autorisation et application de la décision. Peeryx Flow Collector fonctionne hors du chemin des paquets, dans le périmètre publié de déviation IPv4 /24 autorisée ; il ne fournit ni capacité réseau ni filtrage en ligne.
Vérifier que le service d’accès résiste au changement convenu
- Relevez trafic normal en heure chargée, connexions réussies et compteurs d’état avant l’activation de la protection.
- Contrôlez routes acceptées, deux sens de trafic et transferts petits et grands sur chaque chemin livré.
- Coordonnez le test de panne de chemin ou d’équipement, relevez le rétablissement utile et désignez un responsable du retour arrière.
Questions sur ce déploiement
La capacité partagée du réseau réserve-t-elle ce débit à mon FAI ?
Non. Commit, port livré, capacité amont partagée et capacité locale de filtrage mesurée sont des grandeurs distinctes. La proposition applicable définit le service qui vous est livré.
Un filtre local remplace-t-il une protection amont sur un accès saturé ?
Il ne peut pas récupérer les paquets perdus avant de l’atteindre. La protection destinée à soulager le point de saturation doit agir en amont de celui-ci.
Référence technique : RFC 7454 : exploitation et sécurité BGP