Comment protéger une infrastructure multi-site contre les attaques DDoS

Définition du problème

Une infrastructure multi-site regroupe plusieurs emplacements qui participent réellement au service : datacenters distincts, points de présence, environnements cloud, réseaux de reprise, ou combinaison de plusieurs modèles. Dans ce type d’architecture, une attaque DDoS ne touche pas seulement une IP : elle peut déséquilibrer le routage, saturer un lien partagé, déplacer un problème vers un autre site ou perturber la relivraison du trafic légitime.

Le cœur du problème n’est donc pas seulement le volume brut en Gbps. Il faut aussi regarder la pression en PPS, les asymétries de routage, la cohérence BGP, la logique de handoff du trafic propre et la capacité des équipes à comprendre rapidement ce qui se passe. Une protection DDoS pour plusieurs sites doit être conçue comme un système de circulation du trafic, pas uniquement comme une boîte qui bloque des paquets.

Les variantes naturelles liées à cette intention sont nombreuses : protection DDoS multi-site, anti DDoS multi datacenter, transit IP protégé multi-site, clean traffic handoff multi-site, ou encore architecture de mitigation DDoS pour plusieurs sites. Toutes ramènent à la même réalité : garder des chemins propres, prévisibles et exploitables même sous pression.

Pourquoi c’est important

Le multi-site donne souvent une impression de résilience automatique. Pourtant, si les rôles des sites sont flous ou si les retours de trafic propre sont improvisés, une architecture distribuée devient plus fragile qu’un schéma simple. Une attaque visant un seul service peut alors impacter plusieurs sites, plusieurs équipes ou plusieurs couches réseau en même temps.

C’est aussi un sujet commercial. Quand une entreprise affiche plusieurs sites ou plusieurs POPs, les clients attendent une continuité réelle. Ils veulent savoir si vous pouvez absorber une attaque sans couper l’accès, sans envoyer tout le trafic sur un site inadéquat et sans provoquer une hausse inutile de latence. Une stratégie cohérente renforce à la fois la disponibilité, l’exploitation et la crédibilité B2B.

Les solutions possibles

Il existe trois grands modèles de protection DDoS multi-site. Le premier consiste à mutualiser la mitigation sur une couche de transit IP protégé puis à relivrer le trafic propre vers les différents sites. Le deuxième consiste à protéger chaque site localement avec sa propre logique de mitigation. Le troisième, souvent le plus crédible, est un modèle hybride dans lequel certaines fonctions sont mutualisées et d’autres restent proches de la production.

Le bon choix dépend du type de services exposés, des contraintes de latence, de la présence ou non de BGP, du mode de livraison attendu et du niveau d’autonomie souhaité site par site. Dans beaucoup de cas, il vaut mieux mutualiser l’absorption et garder une relivraison flexible plutôt que de disperser des capacités incomplètes partout.

Notre méthode / approche

Chez Peeryx, l’approche la plus saine consiste à partir du chemin du trafic avant de parler du moteur de filtrage. On cartographie d’abord les préfixes, les sites exposés, les points d’entrée, les services réellement critiques et les chemins de retour disponibles. Ensuite seulement, on choisit le bon modèle de protection et de relivraison.

Dans une architecture multi-site, la bonne question n’est pas seulement ‘où filtre-t-on ?’, mais aussi ‘où rend-on le trafic propre ?’, ‘quelle destination est prioritaire ?’, ‘que se passe-t-il si un lien tombe ?’, et ‘qu’est-ce qui doit rester simple pour les équipes d’exploitation ?’. Cette logique permet d’éviter les schémas théoriquement élégants mais impraticables en production.

Quand cette solution est pertinente / quand elle ne l’est pas

Une architecture de protection DDoS multi-site est particulièrement pertinente quand vous exploitez plusieurs datacenters, plusieurs zones techniques ou plusieurs régions qui doivent rester joignables selon des contraintes différentes. Elle devient aussi très utile quand vous voulez mutualiser une capacité Anti-DDoS importante sans reconstruire chaque site comme un scrubbing center autonome.

En revanche, si toute la production dépend réellement d’un seul site, si vous n’avez aucun contrôle de routage, ou si l’exploitation réseau est encore très immature, il est souvent préférable de commencer par un design plus simple. Le multi-site n’a de valeur que s’il reste compréhensible et testable.

• Pertinent si vous avez plusieurs datacenters, plusieurs POPs ou plusieurs régions cloud exposées.
• Pertinent si vous devez rendre du trafic propre vers des destinations différentes selon le service.
• Pertinent si vous voulez mutualiser la mitigation tout en gardant des chemins de retour crédibles.
• Moins pertinent si toute votre production tient réellement sur un seul site.
• Moins pertinent si vous n’avez ni visibilité réseau, ni BGP, ni capacité à tester les scénarios de reprise.

Cas concret ou exemple d’usage

Imaginons une infrastructure répartie entre Marseille, Paris et une région cloud européenne. Les services publics sont annoncés via une couche de transit IP protégé. Lors d’une attaque, le trafic brut est absorbé et filtré en amont. Ensuite, le trafic propre est relivré vers Marseille pour les services principaux, vers Paris pour les services d’administration séparés, et vers le cloud pour certains composants applicatifs spécifiques.

Dans ce scénario, l’intérêt du multi-site n’est pas simplement d’avoir ‘plusieurs endroits’. L’intérêt est de pouvoir orienter le trafic propre vers la bonne destination selon la fonction du service, sans forcer toute l’infrastructure à passer par un seul site de sortie. Cela limite les détours, réduit les dépendances inutiles et maintient un comportement plus prévisible pendant l’attaque.

Erreurs fréquentes

Les erreurs les plus courantes viennent rarement du filtre lui-même. Elles viennent d’une architecture mal cadrée : rôles flous entre sites, préfixes annoncés sans logique de retour, tunnels improvisés, absence de plan de secours, ou choix d’un design trop complexe pour l’équipe qui doit l’exploiter tous les jours.

• Confondre multi-site et résilience automatique.
• Annoncer plusieurs chemins sans définir précisément quel site doit recevoir quel trafic propre.
• Oublier de prévoir un secours pour le tunnel, le port ou la livraison locale.
• Dupliquer des moyens partout au lieu de mutualiser ce qui peut l’être proprement.
• Sous-estimer l’observabilité et le temps de diagnostic.
• Concevoir la mitigation sans penser à l’exploitation réelle pendant un incident.
• Ignorer la latence et les effets d’un routage asymétrique mal maîtrisé.
• Créer une architecture trop belle sur le papier mais trop lourde à maintenir.

Mini tableau comparatif

Le tableau ci-dessous résume les grands compromis entre les principaux modèles de protection DDoS multi-site. Il ne remplace pas une étude de topologie, mais il aide à cadrer rapidement la logique la plus adaptée.

Pourquoi choisir Peeryx

Peeryx ne se limite pas à bloquer des paquets. L’objectif est de construire une protection réellement exploitable : transit IP protégé, options de handoff, relivraison du trafic propre, logique adaptée aux sites exposés et capacité à garder une architecture compréhensible même lorsque plusieurs environnements doivent cohabiter.

Pour une infrastructure multi-site, cette approche évite les promesses trop vagues. On construit un schéma cohérent entre mitigation, routage, latence et exploitation quotidienne, afin que la disponibilité reste crédible même dans des scénarios plus complexes que le simple ‘un service, une IP, un tunnel’.

FAQ

Ressources utiles

Pour approfondir le sujet, vous pouvez consulter les ressources ci-dessous. Elles complètent bien une réflexion sur l’architecture, le routage et les bonnes pratiques de défense réseau.