Filtrage DDoS en amont : protéger le lien d’accès

Définition du problème

Le problème central est simple : beaucoup d’architectures placent le vrai filtrage trop bas dans le chemin. Le trafic arrive d’abord sur un port opérateur, traverse éventuellement un routeur, puis touche un firewall, un load balancer ou un serveur. Une attaque de réflexion UDP, un flood TCP à haute PPS ou un mélange de petits paquets peut saturer le premier lien bien avant que votre logique locale ne voie assez d’échantillons pour réagir correctement.

L’upstream filtering déplace une partie de la décision plus haut. Le fournisseur amont peut appliquer des règles volumétriques, des ACL, du BGP FlowSpec, du rate-limit ciblé ou une redirection vers un scrubbing center. Cette couche ne remplace pas la mitigation fine, car elle voit souvent moins de contexte applicatif. Elle sert plutôt à dé-grossir l’attaque pour éviter la panne par saturation physique ou commerciale.

Il faut aussi distinguer trois choses : blackholer un préfixe, filtrer un pattern d’attaque et relivrer un trafic propre. Le blackhole protège le réseau du fournisseur mais coupe le service. Le filtrage amont intelligent tente de réduire l’attaque sans sacrifier les utilisateurs légitimes. La relivraison propre permet ensuite de garder le service joignable.

Pourquoi c’est important

Ce sujet est critique pour les hébergeurs, opérateurs, serveurs de jeux et plateformes exposées parce que le coût d’une erreur se voit immédiatement : pertes de joueurs, tickets clients, ports saturés, trafic facturé au 95e percentile ou annonce blackhole déclenchée trop vite. Une attaque de 40 Gbps contre une infrastructure connectée en 10 Gbps n’est pas un problème de firewall ; c’est d’abord un problème de capacité d’entrée.

Le filtrage amont est aussi important pour éviter les faux positifs massifs. Si la seule réponse disponible est “blackhole du /32” ou “blocage UDP complet”, le service reste indisponible même si l’attaque est techniquement absorbée. Une bonne stratégie upstream doit viser le minimum d’action efficace : protocole, ports, longueurs de paquet, flags ou sources évidentes, avec durée courte et rollback clair.

Enfin, le filtrage amont influence la perception commerciale. Un client B2B ne veut pas entendre uniquement “nous avons beaucoup de Tbps”. Il veut savoir où l’attaque est arrêtée, combien de temps la règle reste active, comment le trafic légitime est préservé et comment le support peut expliquer ce qui a été fait pendant l’incident.

Les solutions possibles

La première solution est le blackhole BGP, utile en dernier recours lorsque l’objectif prioritaire est de sauver le reste du réseau. C’est simple, rapide et supporté par de nombreux transitaires, mais destructif pour le service visé. Il ne doit pas être présenté comme une vraie protection de disponibilité.

La deuxième solution est le filtrage statique chez l’opérateur : ACL ou profils anti-amplification classiques sur DNS, NTP, SSDP, memcached et autres vecteurs. C’est efficace contre des attaques évidentes, mais insuffisant contre des attaques qui imitent partiellement le trafic normal ou qui changent rapidement de forme.

La troisième solution est l’usage contrôlé de BGP FlowSpec. FlowSpec permet de propager des règles portant sur plusieurs champs de trafic, pas seulement une destination. Bien utilisé, il soulage le port sans bloquer tout le préfixe. Mal utilisé, il peut casser le légitime aussi vite qu’il arrête l’attaque.

La quatrième solution est le scrubbing upstream avec retour de trafic propre par GRE, IPIP, VXLAN, cross-connect ou VM routeur. C’est souvent le modèle le plus propre lorsque le client veut rester en ligne pendant l’attaque et garder une logique de filtrage plus fine derrière.

• Blackhole ou FlowSpec : deux réponses différentes au DDoS ↗

  Comparer blackhole et règles FlowSpec ciblées.

Cas concret ou exemple d’usage

Prenons un hébergeur qui expose plusieurs serveurs de jeux derrière un port 10G. Un flood UDP de réflexion arrive à 70 Gbps avec des paquets très reconnaissables. Si tout arrive jusqu’au port client, le service disparaît. Le bon réflexe n’est pas de bloquer tout UDP, car les jeux en ont besoin.

Une stratégie plus propre consiste à appliquer en amont une règle courte sur les caractéristiques de l’attaque, par exemple certains ports source de réflexion, une plage de longueurs et une destination précise. Le volume tombe sous la capacité disponible. Ensuite, la mitigation spécialisée continue de distinguer les flux légitimes des flux suspects.

Le client voit encore son service fonctionner, même si l’attaque continue. Le support peut expliquer la règle appliquée, sa durée, son impact attendu et le plan de retrait. C’est exactement la différence entre “nous avons absorbé” et “nous avons protégé sans couper inutilement”.

Erreurs fréquentes

• Confondre upstream filtering et blackhole total du service.
• Appliquer une règle trop large sur UDP ou TCP sans comprendre le trafic légitime.
• Laisser une règle FlowSpec active après la fin de l’attaque.
• Ne pas mesurer le 95e percentile et les seuils de saturation réels.
• Ne pas prévoir de chemin de retour propre avant l’incident.
• Acheter une protection uniquement sur la capacité annoncée sans demander la logique de filtrage.

FAQ