Vendredi 21 octobre, la société DYN, basée aux États-Unis, a subi une attaque DDoS historique qui a ciblé ses serveurs DNS.
Plusieurs acteurs majeurs de l’Internet ont vu leurs services rendus inaccessibles pendant plusieurs heures.
Nous vous proposons de vous éclairer sur les modalités de l’attaque, sur ce qui l’a rendu possible et ce qui aurait permis de l’éviter, ou du moins de limiter les problèmes.
Les serveurs DNS
Commençons d’abord par vous expliquer ce qu’est un serveur DNS.
Le Domain Name System (DNS) a pour fonction de traduire un nom de domaine en une adresse IP.
Le rôle du serveur DNS est donc de trouver l’adresse IP associée au nom de domaine dont vous vous servez pour accéder à un site web (ou à tout autre service lié à un nom de domaine).
Par exemple :
www.icodia.com correspond à l’IP 46.31.192.17
L’IP étant l’adresse de la machine sur laquelle est hébergé le site. Cela permet d’atteindre un service web par son domaine (icodia.com), plutôt que par son adresse IP (46.31.192.17)
Schématiquement, le processus de résolution DNS fonctionne ainsi :
(cliquez sur l’image pour l’agrandir)
Attaques DDoS
L’attaque DDoS de vendredi a touché les serveurs DNS de la société DYN.
Une attaque par déni de service (DoS) consiste à envoyer un très grand nombre de requêtes à un serveur depuis une adresse IP.
Dans ce cas, la riposte est relativement simple puisqu’il « suffira » de bloquer l’adresse IP de la machine. Toutes les communications provenant de cette adresse seront alors empêchées.
Le cas de l’attaque par déni de service distribuée (DDOS) est beaucoup plus complexe puisqu’il n’y aura pas une mais plusieurs machines attaquantes avec autant d’adresses IP différentes.
C’est ce que l’on appelle un botnet, un réseau de machines zombies peu ou mal sécurisées, infectées au préalable pour qu’une machine maîtresse puisse en prendre le contrôle. Ces machines peuvent aussi bien être des ordinateurs que des objets connectés comme ça a été le cas vendredi.
Il est beaucoup plus difficile de contrer une attaque DDoS car elle provient de très nombreuses machines dont les adresses IP peuvent évoluer au cours de l’attaque en fonction de son degré de sophistication.
De plus, la technique même d’attaque des services DNS permet d’amplifier le niveau d’attaque et le nombre de paquets attaquants.
L’attaque de vendredi a utilisé différentes faiblesses du service DNS de DYN :
– Anycast
Anycast, l’une des technologie utilisée par DYN, permet, via des serveurs DNS dispersés un peu partout dans le monde, d’effectuer la résolution DNS sur la route la plus courte entre l’utilisateur et le serveur DNS.
Grâce à cette technique, chaque serveur DNS réplique ses informations aux autres, permettant à chaque serveur d’avoir les mêmes données de zone DNS, de cache, etc.
La limite provient de la combinaison de deux techniques :
– la pollution de cache (technique qui consiste à saturer le cache d’un serveur en requêtes non légitimes)
– le spoof d’IP (technique permettant de mentir sur l’adresse IP source)
Avec l’anycast, chaque serveur attaqué réplique son cache (pollué) aux autres, amplifiant ainsi énormément l’impact de l’attaque.
C’est un risque important, lorsqu’on estime que la technique de résolution DNS anycast va faire gagner quelques dizaines de millisecondes.
Optimiser le temps d’affichage d’un site Internet, ses serveurs, etc. est bien plus efficace.
De plus, l’anycast repose sur une synchronisation rapide des routages BGP (on route les mêmes adresses IP sur plusieurs routes BGP).
Mais en cas de DDoS important, un routeur BGP peut ne plus disposer de suffisamment de ressources pour dialoguer avec les autres routeurs.
– La résolution via le protocole UDP :
TCP/IP (le protocole utilisé pour échanger des données sur Internet) comporte beaucoup de couches différentes, et la norme la plus utilisée pour la résolution DNS est l’UDP.
Ce protocole permet d’effectuer des échanges rapides de petites données, idéal pour la résolution DNS.
Le principal problème du protocole UDP (en IPv4) est qu’il dispose de peu de sécurisation contre le spoofing.
Cela a permis un facteur d’amplification d’attaque important, permettant la pollution de cache, complexe à gérer en cas de DDoS.
Dans ce cas, une série de protocoles de sécurité auraient pu s’activer, afin de forcer la résolution DNS avec le protocole TCP.
Certes, cela prend quelques dizaines de millisecondes supplémentaires, mais cela permet de maintenir un service.
De plus, TCP permet d’activer une latence de réponse qui aurait posé problème aux robots attaquants.
– La gestion dynamique des TTL
Le TTL (« Time to Live ») est le temps pendant lequel le cache est conservé sur un serveur de cache : en cas d’attaque identifiée, il est primordial d’avoir un service qui permette, temporairement, d’augmenter le cache TTL des entrées des zones DNS.
On pourra alors bénéficier du cache des serveurs DNS des différents opérateurs d’Internet. Ainsi, la mise en cache limite le nombre de requêtes et permet d’accepter plus de connexions.
– Un service DNS classique avec Geoloc :
La norme Geoloc (RFC 1034 et 1035, qu’Icodia supporte) permet de résoudre des adresses IP en fonction de la position géographique : on donne une préférence à une adresse IP par rapport à une autre car son temps de réponse est plus faible (et généralement son positionnement géographique).
Par exemple, en utilisant un service DNS classique + un cache TTL correct, il est possible d’avoir une résolution de ns.icodia.com qui comporte une vingtaine d’adresse IP.
Chaque adresse IP correspond à un serveur DNS réparti sur le globe.
Lorsqu’un client situé aux USA se connecte, le serveur DNS ns.icodia.com lui fournit l’adresse IP ‘A’ du serveur le plus rapide (et souvent le plus proche). Il pourra ensuite se connecter sur l’adresse IP ‘A’ et faire la résolution DNS souhaitée.
Si un client situé en Europe se connecte sur la même adresse ns.icodia.com, l’analyse Geoloc lui donnera l’adresse IP ‘B’, qui sera plus proche, et il pourra également faire sa requête DNS.
On détermine alors que le serveur DNS racine, qui s’occupe de fournir les adresses IP ‘A’ ou ‘B’ doit disposer d’un temps de requête minimale afin d’accélérer la vitesse de résolution.
Pour conclure…
Finalement, l’attaque contre Dyn, ciblant indirectement les gros sites du marché US tels que Twitter, Netflix ou Paypal, a utilisé plusieurs failles, aussi bien techniques (gestion de l’attaque, attente d’une intervention humaine pour commencer la mitigation (atténuation des dommages)) que conceptuels (les serveurs DNS délégataires chez le même prestataire, sur la même technologie).
Le service étant revenu à la normale, il faut espérer qu’un certain nombre de mesures seront mises en place, notamment en proposant des optimisations applicatives qui permettront de limiter une prochaine vague d’attaque ; venant d’un spécialiste du marché, c’est le minimum qu’un client peut attendre.
On peut enfin s’interroger sur la pertinence de la technique de l’anycast, dont l’objectif est de faire gagner quelques millisecondes, quand un site parallèlement à cela prend plusieurs secondes pour afficher une page, une fois la résolution DNS effectuée…