Qu'est-ce qu'une attaque DDoS par inondation UDP ?

Qu'est-ce qu'une attaque DDoS par inondation UDP ?

Une inondation UDP est une attaque DDoS volumétrique qui envoie un nombre énorme de paquets UDP (User Datagram Protocol) vers une cible, souvent sur de nombreux ports différents, jusqu'à épuiser sa bande passante, son pare-feu ou son processeur, de sorte que le trafic légitime ne passe plus. UDP n'a pas d'établissement de connexion : l'émetteur peut falsifier son adresse et la cible ne distingue pas le vrai du faux. Cette entrée explique le mécanisme et les défenses. Ce n'est pas un guide pour lancer une attaque : attaquer des systèmes qui ne vous appartiennent pas est illégal.

Pourquoi UDP est facile à détourner

UDP est défini dans la RFC 768 comme un protocole de datagrammes dont la livraison et la protection contre les doublons ne sont pas garanties. Il n'y a pas d'établissement de connexion et le port source est même facultatif. Rien dans le protocole ne vérifie que l'adresse IP source appartient à l'émetteur : un paquet à l'adresse falsifiée est accepté comme n'importe quel autre.

Comment fonctionne une inondation UDP

• Inondation directe. De nombreuses machines, généralement un botnet, envoient des paquets UDP vers des ports aléatoires de la cible. Pour chaque paquet, l'hôte cherche une application à l'écoute sur ce port. S'il n'y en a pas, il peut répondre par un message ICMP « destination inaccessible » (port inaccessible, défini dans la RFC 792), ce qui ajoute de la charge sortante à l'inondation entrante.
• Réflexion et amplification. L'attaquant envoie de petites requêtes à des serveurs UDP publics en usurpant l'adresse de la victime comme source. Les serveurs envoient leurs réponses, plus volumineuses, à la victime. L'alerte archivée de la CISA sur l'amplification UDP (TA14-017A) indique des facteurs d'amplification comme 28 à 54 pour DNS, 556,9 pour NTP et 358,8 pour CharGEN, et jusqu'à 51 000 pour Memcached.
• Sources usurpées. L'adresse source étant falsifiée, bloquer des adresses IP aide rarement et l'origine réelle est difficile à retrouver.

Les attaques par réflexion ont leurs propres entrées : amplification DNS et DDoS Memcached.

Exemple

Un studio de jeux fait tourner un serveur sur un port UDP. Le trafic atteint plusieurs fois la capacité de sa liaison internet, presque uniquement de petits paquets UDP venant d'adresses dispersées. La liaison est saturée avant qu'un paquet n'atteigne le pare-feu, donc les règles du serveur n'y changent rien. Le studio a besoin que son hébergeur filtre en amont.

Comment se défendre contre une inondation UDP

• L'absorber en amont. Une inondation qui remplit votre liaison ne se règle pas sur votre propre serveur. Utilisez un service de protection DDoS ou un hébergeur qui épure le trafic avant qu'il ne vous atteigne. La CISA cite aussi le blackholing déclenché à distance via BGP, coordonné avec les fournisseurs en amont.
• Fermer ce que vous n'utilisez pas. Bloquez les ports UDP dont aucun service n'a besoin et n'exposez que ce que vous exploitez. L'inspection UDP avec suivi d'état aide en périphérie.
• Ne pas devenir un amplificateur. Désactivez les services UDP inutiles, appliquez une limitation du débit des réponses sur DNS et les autres services UDP, et ne laissez jamais de résolveurs ouverts ou de Memcached accessibles depuis internet.
• Stopper l'usurpation à la source. Les opérateurs réseau devraient appliquer le filtrage en entrée décrit dans le BCP 38 (RFC 2827), qui rejette les paquets dont l'adresse source n'appartient pas au réseau d'où ils viennent.
• Surveiller le trafic. Déclenchez des alertes sur les hausses brutales du volume UDP, les réponses anormalement grosses vers une seule adresse et les anomalies de taille de paquets dans les données de flux.

Le cadre général est dans comment arrêter les attaques DDoS. Une inondation UDP est l'équivalent au niveau réseau d'une inondation HTTP, qui vise l'application web.

Erreurs fréquentes

• Compter sur le pare-feu du serveur face à une inondation qui sature la liaison avant que le pare-feu ne voie quoi que ce soit.
• Exploiter des services UDP publics comme DNS ou NTP avec la configuration par défaut et participer ainsi à l'attaque d'un autre.
• Ne pas avoir de contact ni de plan avec l'hébergeur avant que l'attaque ne commence.

La place de LoadFocus

LoadFocus ne simule pas d'attaques, y compris les inondations UDP. Ses tests de charge envoient des requêtes HTTP et HTTPS depuis 25 régions cloud, et une attaque UDP volumétrique doit être absorbée en amont par votre hébergeur ou votre fournisseur de protection DDoS. Un test de charge montre en revanche comment votre application web se comporte quand le trafic légitime augmente, pour connaître votre capacité réelle et votre marge. Voir test de charge et test de stress et les tests de pic pour le planifier. Ne testez que des systèmes qui vous appartiennent ou pour lesquels vous avez une autorisation écrite, et vérifiez d'abord la politique de test de votre hébergeur.

Questions fréquentes

Qu'est-ce qu'une inondation UDP en termes simples ?

C'est une attaque qui envoie un très grand nombre de paquets UDP vers une cible pour que sa liaison réseau, son pare-feu ou son serveur manquent de capacité et que les utilisateurs légitimes ne puissent plus se connecter.

Pourquoi peut-on falsifier l'adresse source en UDP ?

UDP n'établit pas de connexion et ne vérifie pas qui a envoyé un paquet : un paquet à l'adresse source falsifiée est donc accepté. C'est pourquoi les attaques par réflexion fonctionnent et pourquoi le filtrage en entrée (BCP 38) compte.

Un pare-feu peut-il arrêter une inondation UDP ?

Seulement en partie. Un pare-feu peut rejeter le trafic UDP vers des ports inutilisés, mais une inondation capable de remplir votre liaison internet doit être filtrée en amont par votre hébergeur ou un service de protection DDoS.

LoadFocus simule-t-il des inondations UDP ?

Non. Les tests de charge LoadFocus envoient des requêtes HTTP et HTTPS pour mesurer les performances de votre application sous charge légitime. Il ne fait pas de simulation d'attaque.