Filtrage amontPublié le 23 mai 2026Temps de lecture : 13 min
Upstream filtering DDoS : filtrer l’attaque avant qu’elle ne sature votre infrastructure
Le filtrage DDoS upstream protège un service avant que l’attaque n’atteigne le port client, le firewall ou le serveur. Ce guide explique quand il sert vraiment, comment il diffère du blackhole et comment le combiner avec une relivraison de trafic propre.
Le premier goulot compte
Le meilleur filtre local ne sert à rien si le lien est saturé avant lui.
Filtrer ne veut pas dire blackholer
Un bon filtrage amont retire des patterns précis au lieu de couper tout le préfixe.
Le handoff reste essentiel
Après soulagement upstream, le trafic propre doit revenir de manière stable et observable.
Quand une attaque DDoS arrive jusqu’à votre port, il est souvent déjà trop tard. Un firewall local peut être excellent, un serveur peut avoir beaucoup de CPU, mais si le lien d’accès ou le port de transit est saturé, le trafic légitime ne passe plus. L’upstream filtering consiste à filtrer une partie de l’attaque chez le fournisseur en amont : transitaire, backbone, scrubbing edge ou opérateur de mitigation. L’objectif n’est pas de tout bloquer brutalement, mais de retirer assez de trafic parasite avant le goulot d’étranglement pour que la couche de filtrage fine puisse continuer à travailler.
Pourquoi choisir Peeryx
Pourquoi choisir Peeryx
Peeryx privilégie un design lisible : capacité amont, filtrage précis, handoff propre et support capable d’expliquer les décisions pendant l’incident.
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.
Chez Peeryx, l’approche consiste à considérer le filtrage amont comme une couche de soulagement, pas comme une solution unique. Le réseau doit d’abord absorber et réduire les floods volumétriques. Ensuite, la logique de mitigation plus précise traite les cas où le trafic légitime et l’attaque se ressemblent davantage.
Le BGP FlowSpec peut être utile pour retirer rapidement un pattern évident, par exemple une combinaison de protocole, ports source/destination, taille de paquet ou flags TCP. Mais il doit être court, ciblé et surveillé. Une règle large et permanente est presque toujours un mauvais signal opérationnel.
Le point clé reste la relivraison. Peeryx peut livrer le trafic propre par tunnel, cross-connect ou design BGP selon le niveau de contrôle du client. L’objectif est que le client comprenne le chemin : où l’attaque entre, où elle est réduite, où le trafic propre ressort et quelle partie de la logique reste sous son contrôle.
Pourquoi choisir Peeryx
Peeryx privilégie un design lisible : capacité amont, filtrage précis, handoff propre et support capable d’expliquer les décisions pendant l’incident.
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”.
1. Observer
Identifier volume, PPS, protocole, ports, chemin BGP et impact client.
2. Agir
Appliquer l’action minimale efficace : route, filtre, bascule ou handoff.
3. Retirer
Retirer ou resserrer les règles dès que la pression baisse pour éviter les effets persistants.
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
Le filtrage upstream remplace-t-il un anti-DDoS spécialisé ?
Non. Il soulage la saturation amont, mais la mitigation fine reste nécessaire pour préserver le trafic légitime, surtout sur les services gaming, UDP ou applicatifs.
BGP FlowSpec est-il dangereux ?
Il est dangereux s’il est trop large, permanent ou mal validé. Il est utile lorsqu’il est précis, temporaire et basé sur des caractéristiques réellement observées.
Pourquoi ne pas blackholer directement ?
Parce qu’un blackhole coupe le service. Il peut sauver le backbone, mais il ne protège pas la disponibilité du client.
Peut-on utiliser l’upstream filtering avec un tunnel GRE ?
Oui. Le filtrage amont peut réduire l’attaque avant relivraison du trafic propre par GRE, IPIP, VXLAN ou cross-connect.
Conclusion
L’upstream filtering DDoS est une brique essentielle quand la menace dépasse la capacité du port client ou du premier équipement local. Sa valeur n’est pas de bloquer le plus possible, mais de retirer assez de trafic parasite pour garder le service vivant et permettre une mitigation plus précise derrière.
La vraie qualité d’une architecture se voit dans la combinaison : seuils de déclenchement, règles ciblées, durée courte, visibilité, retour propre et capacité à expliquer ce qui est fait pendant l’attaque. C’est ce niveau d’exploitation qui transforme un simple filtrage amont en protection réellement vendable.
Ressources
Lectures liées
Pour approfondir le sujet, voici d’autres pages et articles utiles.
Peeryx peut analyser vos préfixes, vos upstreams, vos contraintes de latence et votre exposition DDoS afin de proposer un modèle de transit protégé ou de handoff propre adapté à votre vraie topologie.
