BLOG

Donner un sens aux attaques DDoS du dernier mois

Miniature F5
F5
Publié le 27 octobre 2016

Dans cet article, nous examinerons brièvement l’impact des attaques DDoS sans précédent de septembre et octobre 2016 et fournirons des conseils à ceux qui souhaitent améliorer leur résilience.

Célébrons l’arrivée de l’Internet des Objets ! Nous savons qu'il est enfin là car il a été utilisé comme arme informatique à trois reprises à partir de septembre. Tout a commencé avec une attaque massive contre le journaliste blogueur Brian Krebs, dont le site Web krebsonsecurity.com était hébergé et protégé par le CDN Akamai. L'attaque a été suffisamment grave pour affecter les autres clients d'Akamai, qui ont donc abandonné leur défense bénévole du blogueur.

Les chercheurs de l’industrie (y compris ceux de F5) ont été alertés de l’existence d’un nouveau botnet composé de DVR, de caméras vidéo et d’autres « objets ». Mais les DVR et les caméras vidéo sont importants car ils ont à la fois une capacité CPU élevée (qui peut donc héberger des logiciels malveillants sophistiqués) et des liaisons montantes à large bande passante (à partir desquelles ils lancent des attaques jusqu'à 100 Mbs chacune). Le trafic d’attaque total dirigé contre Krebs était de 620 Gb/s, ce qui représentait à l’époque la plus grande attaque DDoS au monde.

La deuxième attaque a mis hors service OVH, le plus grand hébergeur français (numéro trois mondial, si l'on en croit la littérature) pendant une bonne partie de la journée. De nombreux rapports médiatiques ont estimé que l'attaque d'OVH avait une taille presque deux fois supérieure à celle de Krebs ; un térabit par seconde.

La troisième et probablement la plus grave attaque a été perpétrée contre Dyn, la société de services DNS. Dyn est le fournisseur DNS de nombreux sites Web de premier plan, notamment Twitter, Spotify et GitHub (où, ironiquement, le code du botnet IoT a été publié).

Alors, qui l'a fait ?

Par une étrange coïncidence, Bruce Schneier, une sommité du secteur, avait fait le tour des interviews le mois précédent, mettant en garde contre des attaques DDoS massives à venir au niveau des États-nations. Ses informations privilégiées provenaient de sources industrielles anonymes qui repéraient des attaques DDoS d’étalonnage contre l’infrastructure principale d’Internet.

Mais il s’avère que ces attaques de sondage n’étaient peut-être qu’une simple coïncidence. Schneier lui-même a admis sur son blog qu'il ne pensait pas que l'attaque de Dyn était un acte étranger à un État-nation. Mais peut-être que cet État-nation se contente d’observer et d’attendre.

La clé de l’attribution dans les affaires Krebs, OVH et Dyn pourrait probablement venir de Brian Krebs lui-même .

« L’attaque contre DYN survient quelques heures seulement après que Doug Madory, chercheur chez DYN, a présenté une conférence sur les attaques DDoS à Dallas, au Texas, lors d’une réunion du North American Network Operators Group (NANOG). … l’ attaque DDoS record de 620 Gbps contre KrebsOnSecurity.com survient quelques heures seulement après la publication de l’article sur lequel Madory et moi avons collaboré. »

Il est très probable que l’adversaire soit un individu (ou un petit groupe) ayant un programme contre Brian Krebs ou Doug Madory, ou les deux.

Nous pouvons tous comprendre que des millions d’utilisateurs seraient touchés par une cyberguerre à grande échelle entre la Chine et les États-Unis. Mais si cela s’avère être un agenda personnel d’un seul individu contre un autre individu ? C’est encore plus effrayant qu’une attaque d’un État-nation. Quel type d’Internet avons-nous construit lorsqu’une seule personne en veut à une autre personne et peut interrompre des services essentiels pour des millions de personnes ?

Comment en sommes-nous arrivés là ?

F5 surveille la chasse aux appareils Internet des objets (IoT) depuis plus d’un an maintenant. Notre premier rapport sur ce problème a été publié en juillet 2016 et a montré une augmentation de 140 % des analyses de force brute Telnet et SSH d'une année sur l'autre. Telnet et SSH sont des ports d'administration à distance largement utilisés, et ils sont souvent laissés sans le savoir exposés à Internet avec le nom d'utilisateur et les mots de passe par défaut du fournisseur (ou faciles à deviner).

Les attaques DDoS sans précédent contre Krebs, OVH et Dyn en octobre 2016 ont utilisé exactement cette technique (recherche de ports Telnet et de mots de passe par défaut des fournisseurs sur les appareils IoT) pour créer un botnet aux capacités uniques.

Tout le monde est à nouveau une cible. Les éleveurs de robots n’ont pas peur de retourner leur cyberarme contre certains des plus grands fournisseurs du monde, des cibles que l’on croyait auparavant intouchables.

Même si ces attaques semblent avoir eu lieu du jour au lendemain, en réalité, le bot herder recherche, trouve et compromet lentement les appareils IoT vulnérables depuis au moins un an.

Plongée en profondeur dans ce que nous savons

Nous avons en fait une assez bonne idée des capacités du botnet IoT, Mirai. Les chercheurs de F5 ont rédigé une analyse technique du bot Mirai peu de temps après que son auteur ait publié le code source sur hackforums.net.

La puissance de feu collective est probablement d’un ordre de grandeur supérieur à celle des botnets précédents ; elle atteint plusieurs térabits par seconde.

Le botnet IoT inclut (mais sans s'y limiter) les techniques DDoS avancées suivantes. La section d’orientation prescriptive ci-dessous fournira des recommandations sur la manière d’atténuer ces risques, lorsque cela est possible.

Les inondations HTTP GET résistent à la redirection

Les inondations HTTP GET étaient déjà pernicieuses. Pendant des années, les attaquants ont pu désactiver des sites Web en envoyant un flot de requêtes HTTP pour des objets volumineux ou des requêtes de base de données lentes. En règle générale, ces requêtes transitent directement par un pare-feu standard, car elles ressemblent à des requêtes HTTP normales pour la plupart des appareils dotés d'un traitement matériel des paquets. Le code d'attaque Mirai va encore plus loin en identifiant les empreintes digitales des épurateurs DDoS basés sur le cloud, puis en contournant les redirections 302 que les épurateurs renvoient. Les redirections étaient autrefois un bon moyen de contrecarrer les robots simples, mais celle-ci n'est pas simple .

La torture de l'eau DNS

Le bot Mirai inclut une attaque de « torture par l’eau » contre un fournisseur DNS cible. Cette technique est différente de l' attaque d’amplification DNS classique car elle nécessite l'envoi de beaucoup moins de requêtes par le bot, permettant au serveur DNS récursif du FAI d'effectuer l'attaque sur le serveur DNS faisant autorité cible. Dans cette attaque, le bot envoie une requête DNS bien formée contenant le nom de domaine cible à résoudre, tout en ajoutant un préfixe généré aléatoirement au nom. L'attaque devient efficace lorsque le serveur DNS cible est surchargé et ne répond plus. Les serveurs DNS du FAI retransmettent ensuite automatiquement la requête pour essayer un autre serveur DNS faisant autorité de l’organisation cible, attaquant ainsi ces serveurs au nom du bot.

Dyn a confirmé dans son article de blog, Dyn Analysis Summary of Friday, October 21 attack , que la torture de l'eau a effectivement été utilisée contre eux.

« Par exemple, l’impact de l’attaque a généré une tempête d’activités de nouvelle tentative légitimes alors que les serveurs récursifs tentaient d’actualiser leurs caches, créant un volume de trafic 10 à 20 fois supérieur à la normale sur un grand nombre d’adresses IP. Lorsque la congestion du trafic DNS se produit, les nouvelles tentatives légitimes peuvent contribuer davantage au volume du trafic.

Il semble que les attaques malveillantes proviennent d'au moins un botnet, la tempête de tentatives fournissant un faux indicateur d'un ensemble de points de terminaison bien plus grand que ce que nous connaissons actuellement. Nous travaillons encore à l'analyse des données, mais l'estimation au moment de la rédaction de ce rapport s'élève à 100 000 points de terminaison malveillants. »

Le chercheur de F5, Liron Segal, avait détaillé les mécanismes de l'attaque Water Torture du robot dans son article publié quelques semaines plus tôt : Mirai, le robot qui a vaincu Krebs.

Mise à jour des attaques de couche 4

Selon le créateur du bot, l’attaque dite « TCP STOMP » est une variante du simple flood ACK destiné à contourner les dispositifs d’atténuation. En analysant la mise en œuvre réelle de cette attaque, il semble que le bot ouvre une connexion TCP complète et continue ensuite à inonder de paquets ACK qui ont des numéros de séquence légitimes afin de maintenir la connexion en vie.

Compte tenu de notre compréhension des vecteurs de menace individuels avec le nouveau bot IoT, nous pouvons fournir quelques conseils pour l’atténuation de ces vecteurs de menace individuels.

Soyons clairs avant de commencer les conseils. Les attaques Krebs, OVH et Dyn sont dans une classe à part. De toute évidence, les techniques existantes d’atténuation des attaques DDoS n’ont pas facilement permis de neutraliser les attaquants, d’où les pannes et la couverture médiatique à la une. Toutefois, dans de nombreux cas, les mesures d’atténuation ont fini par porter leurs fruits. Une architecture appropriée, comme l’utilisation d’Anycast et de centres de données dispersés, a également aidé. Il convient de noter que la côte ouest et les régions occidentales des États-Unis n’ont pas été touchées par l’attaque de Dyn.

Orientation prescriptive

Nos conseils viennent de nos propres clients. F5 fournit des applications aux plus grandes marques mondiales depuis vingt ans, et nombre de ces clients sont quotidiennement attaqués par DDoS. Nos clients les plus expérimentés divisent leurs défenses en trois ou quatre zones :

  • Nettoyage des nuages
  • Défense du réseau
  • Défense de la application
  • DNS, le cas échéant

Une architecture anti-DDoS ultra-résistante ressemble donc à ceci :

Il s’agit de l’architecture de référence de protection DDoS, largement utilisée par les clients F5 depuis des années. L' architecture de référence complète et les pratiques recommandées sont disponibles sur F5.com. Toutefois, pour une consommation plus rapide, les conseils relatifs à ces attaques sont détaillés ci-dessous.

Défense volumétrique

L'hébergeur français OVH a été touché par une attaque volumétrique de 990Gbs. Il a été rapporté que l'attaque Dyn a culminé à 1,2 térabits. Les attaques de cette ampleur ne peuvent généralement être atténuées que par des nettoyeurs de cloud spécialisés dans la défense à grande échelle. Les nettoyeurs de cloud, y compris la protection DDoS Silverline de F5, interceptent le trafic d'attaque, le nettoient et envoient uniquement le bon trafic à la cible via des tunnels préétablis.

Conseils: Les organisations doivent s’assurer qu’elles ont conclu des accords avec un ou plusieurs nettoyeurs de cloud avant d’être attaquées. La configuration des tunnels préétablis n’est pas une opération facile à réaliser au milieu d’une attaque volumétrique. Contrat avec une défense DDoS de nettoyage du cloud dans le cadre de votre stratégie DDoS.

Conseils: La diffusion des attaques peut être votre amie pour les attaques volumétriques. N'oubliez pas que le DNS peut également être votre ami ; diffusez vos centres de données mondiaux pour le contenu répliqué afin de diffuser les attaques DDoS lorsqu'elles se produisent. Chaque centre de données participant à Anycast peut aider à diviser l'attaque.

Documents pertinents :

Défense du réseau

Le bot Mirai inclut plusieurs attaques de couche 4 dans son arsenal : les inondations SYN standard, les inondations TCP et les inondations UDP. Ces anciens vecteurs de menace doivent être atténués soit au niveau d’un épurateur de cloud, soit, s’ils sont suffisamment petits, au niveau de la couche de défense du réseau dans le centre de données. Le niveau de défense du réseau est construit autour du pare-feu réseau. Il est conçu pour atténuer les attaques informatiques telles que les inondations SYN et les inondations de fragmentation ICMP. Ce niveau atténue également les attaques volumétriques jusqu’à la congestion du point d’entrée (généralement 80 à 90 pour cent de la taille nominale du tuyau).

Conseils: De nombreux pare-feu ne résistent pas aux attaques DDoS, à moins d’être correctement configurés. Vérifiez les paramètres auprès du fournisseur de votre pare-feu réseau. Certains clients placeront des dispositifs anti-DDoS devant leurs pare-feu pour repousser les attaques de couche 4.

Conseils: Le module pare-feu F5 (BIG-IP Advanced Firewall Manager (AFM)) a été conçu spécifiquement pour repousser les attaques de couche 4. Certains architectes utilisent BIG-IP AFM uniquement dans ce cas, soit devant, soit en remplacement des pare-feu réseau conventionnels. Les appareils matériels avec AFM utilisent des matrices de portes programmables sur le terrain pour repousser plus de 30 types de flux de paquets et décharger le travail du processeur.

Documents pertinents :

Défense de la demande

Le bot Mirai peut générer des floods HTTP GET impressionnants et gérer les directs. Étant donné que les inondations GET ressemblent à un trafic normal pour les périphériques de défense du réseau, elles doivent être traitées au niveau de l' application . Les attaques GET Flood sont de loin le type d'attaque de couche application le plus courant observé par F5, et il existe de nombreuses façons de les atténuer, en fonction du portefeuille de produits utilisé par un client.

Conseils: Pour les robots capables de gérer des redirections simples, F5 recommande soit de limiter les connexions en fonction de leur métrique de requêtes par seconde, soit d'utiliser ce qu'on appelle un « mur de connexion ». Un mur de connexion nécessite qu'une connexion soit authentifiée auprès de l' application avant de pouvoir consommer des ressources non mises en cache ou dynamiques telles que des requêtes de base de données.

Documents pertinents :

Défense DNS

Il y a deux problèmes DNS qui méritent d'être évoqués en ce qui concerne l'attaque Dyn. La première chose à faire, et la plus simple, est de savoir quoi faire si votre fournisseur DNS est mis hors ligne par l’un des nouveaux types d’attaques. Dyn était le fournisseur de services de noms pour Twitter, GitHub et Spotify. Ainsi, lorsque Dyn a été bloqué, les utilisateurs finaux n'ont pas pu trouver d'adresses IP pour ces services.

Conseils: Intégrez la résilience à votre plan DNS qui inclut, sans s'y limiter, plusieurs fournisseurs DNS pour fournir des adresses à vos applications critiques. De cette façon, si l’un des fournisseurs succombe temporairement à une attaque, l’autre fournisseur peut servir vos adresses. Cela peut ralentir vos utilisateurs finaux de quelques millisecondes, mais vos applications et services seront toujours disponibles.

La deuxième question est de savoir quoi faire si votre propre serveur DNS est attaqué. DNS est le service le plus ciblé, suivi de HTTP. Lorsque le DNS est perturbé, tous les services externes du centre de données (et pas seulement une seule application) sont affectés. Ce point unique de défaillance totale, ainsi que l’infrastructure DNS souvent sous-approvisionnée, font du DNS une cible tentante pour les attaquants.

N’oubliez pas que même si votre propre serveur n’est pas attaqué, une panne en aval de vous pourrait amener un autre ensemble de serveurs DNS à inonder vos serveurs DNS de requêtes alors qu’ils tentent de remplir leurs propres caches. Dyn a signalé 10 à 20 fois plus de requêtes normales lorsque cela s'est produit avec eux, et cela provenait de serveurs DNS légitimes essayant de faire face à la situation.

Conseils: Un pourcentage important de services DNS sont sous-provisionnés au point qu'ils sont incapables de résister même aux attaques DDoS de petite à moyenne taille. Les caches DNS sont devenus populaires car ils peuvent améliorer les performances perçues d'un service DNS et offrir une certaine résilience contre les attaques de requêtes DNS standard. Les attaquants sont passés à ce que l’on appelle les attaques « no such domain » (ou NXDOMAIN), qui épuisent rapidement les avantages en termes de performances fournis par le cache.

Pour les clients F5, F5 recommande d'utiliser les services DNS avec le module proxy DNS appelé F5 DNS Express™. DNS Express agit comme un résolveur absolu devant les serveurs DNS existants. Il charge les informations de zone à partir des serveurs et résout chaque demande ou renvoie NXDOMAIN. Il ne s’agit pas d’un cache et il ne peut pas être vidé via les requêtes NXDOMAIN.

Conseils: N'oubliez pas que le DNS peut être votre ami lors d'une attaque DDoS ; diffusez vos centres de données mondiaux pour le contenu répliqué afin de diffuser les attaques DDoS lorsqu'elles se produisent.

Conseils: Considérez le placement des services DNS. Souvent, le service DNS existe sous la forme de son propre ensemble de périphériques, en dehors du premier périmètre de sécurité. Cela est fait pour garder le DNS indépendant des applications qu’il sert.

Certaines grandes entreprises disposant de plusieurs centres de données fournissent un DNS en dehors du périmètre de sécurité principal à l'aide d'une combinaison de BIG-IP DNS avec DNS Express et du module de pare-feu BIG-IP AFM. Le principal avantage de cette approche est que les services DNS restent disponibles même si le niveau de défense du réseau est hors ligne en raison d’une attaque DDoS.

Documents pertinents :

Conclusion

Les attaques Krebs, OVH et Dyn marquent une nouvelle phase dans les DDoS. Dans le même temps, ils marquent l’avènement de l’Internet des objets.

Comme vous pouvez le constater, F5 possède une grande expérience dans la recherche, la lutte et la rédaction d’articles sur les attaques DDoS et nous souhaitons travailler avec nos clients pour maintenir la disponibilité de leurs applications . Cela nécessitera une vigilance de la part de tous, du F5 aux partenaires en passant par les clients.

Si vous êtes client, ou même si vous ne l'êtes pas, et que vous êtes victime d'une attaque, n'oubliez pas que la protection DDoS F5 Silverline est à portée de téléphone : 866-329-4253.

Quant à la menace IoT, les blackhats partagent entre eux tout le temps (ils ont partagé Mirai après avoir attaqué Krebs et OVH, et il a été utilisé dans l'attaque Dyn). Nous, la communauté InfoSec, devons nous inspirer de leur approche et nous unir pour résoudre ce problème mondial de l’IoT. Nous n’avons pas d’autre choix que de le faire. Il est dans la nature humaine de comprendre les problèmes, de les résoudre et donc d’évoluer.

Il y aura sans aucun doute des ratés au cours des prochaines années, à mesure que les attaques augmenteront en taille, que les services de nettoyage augmenteront en bande passante pour prendre en charge ces attaques de grande envergure et que les fabricants d’appareils IoT trouveront comment gérer les insécurités de leurs appareils. Les organisations et les consommateurs doivent s’habituer à cette menace en constante évolution, comme à tous les autres problèmes majeurs avant celui-ci.