DDoS via un VPN : quelle adresse est réellement exposée ?
Un tunnel masque votre adresse source pour un service, mais pas votre lien montant, la sortie du VPN ou un port redirigé. Nommez la cible avant de planifier l’atténuation.
Commencez par la requête censée faire mal. Elle peut arriver sur votre lien domestique, sur la sortie du VPN ou sur une application publiée derrière le tunnel. Chaque destination a une limite de capacité différente et un propriétaire différent qui peut filtrer le trafic. Nommer la cible est la première étape utile, et un abonnement VPN ne répond qu’à une seule des trois.
Parcourez l’exposition avant l’attaque
Suivez une requête entrante depuis internet jusqu’à la ressource qu’elle doit épuiser. Si la destination est l’adresse de votre foyer, la limite est le lien d’accès et la périphérie du fournisseur. Si c’est la sortie du VPN, la limite appartient à l’opérateur du VPN. Si c’est un port redirigé, le traitement propre à l’application devient le goulot d’étranglement.
| Target | What saturates | Who can mitigate |
|---|---|---|
| Home connection address | The access link and provider edge | The access provider |
| VPN exit address | Provider capacity and filtering | The VPN operator |
| Published service | The application and its host | The service owner and hosting provider |
Les trois cibles peuvent être attaquées ensemble, mais elles sont atténuées à des endroits différents. Notez laquelle votre plan prétend protéger.
Votre propre lien montant conserve son adresse
Faire passer votre trafic sortant par un tunnel change ce que voient les services distants. Cela ne supprime pas l’adresse que détient votre lien d’accès et ne déplace pas la capacité de ce lien.
Le trafic dirigé vers le lien rivalise toujours avec les paquets du tunnel lui-même. Un pare-feu local peut abandonner des paquets après leur arrivée, mais le lien montant contraint les transporte déjà. Cette différence compte lorsque le lien est saturé, car un filtre ne peut pas rendre une capacité qu’il n’a jamais contrôlée. Contactez le fournisseur d’accès via sa procédure d’incident si les éléments pointent vers ce lien.
La sortie du VPN est désormais une dépendance partagée
Quiconque observe la sortie du VPN peut y envoyer du trafic indésirable à la place. Que le fournisseur l’absorbe dépend de la capacité réelle, de l’architecture et de tout service d’atténuation qu’il exploite, non du chiffrement du tunnel.
Une sortie partagée peut aussi subir un incident visant un autre client ou le réseau du fournisseur environnant. Les recommandations de la CISA sur le déni de service font observer que lorsqu’un fournisseur d’accès ou de cloud est attaqué, des réseaux que personne ne visait peuvent aussi tomber. Pour un serveur auto-hébergé, le fournisseur d’hébergement possède toujours la capacité montante qui arrive avant que votre invité voie un paquet. Le filtrage à l’intérieur de l’invité ne peut pas restaurer la bande passante déjà consommée.
Un port publié exige un plan de service
Un port redirigé expose délibérément une application, si bien que des requêtes d’apparence légitime atteignent son chemin de traitement, quelle que soit la manière dont l’admission est contrôlée au niveau du tunnel. L’admission au tunnel, le filtrage sur l’hôte et l’autorisation applicative couvrent des étapes différentes, et aucune ne garantit une protection contre l’épuisement des ressources.
Utilisez les limites prises en charge du service, la supervision et l’atténuation en amont, et nommez qui peut demander de l’aide pendant un incident. Un abonnement VPN grand public ne prouve pas que ces contrôles existent pour votre application.
Gardez le diagnostic proportionné. Les pages lentes et les connexions coupées viennent aussi de la maintenance, de la contention ou de pannes ordinaires ; conservez donc des horodatages et des observations bornées pour l’opérateur responsable. Ne validez jamais l’affirmation par un flood non autorisé, et utilisez plutôt un plan approuvé avec le propriétaire de l’infrastructure.