Comprendre le dernier mois d’attaques DDoS

F5

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

Célébrons l’avènement de l’Internet des objets ! Nous savons qu’il est enfin là, car il a été utilisé comme cyberarme à trois reprises depuis septembre. Tout a commencé par une attaque massive contre le journaliste et blogueur Brian Krebs, dont le site web krebsonsecurity.com était hébergé et protégé par le CDN d’Akamai. L’attaque était suffisamment grave pour affecter les autres clients d’Akamai, qui a donc cessé d’assurer gratuitement la protection du blogueur.

Les chercheurs du secteur (notamment ceux de F5) ont été alertés de l’existence d’un nouveau botnet composé d’enregistreurs vidéo numériques, de caméras vidéo et d’autres « objets ». Mais les enregistreurs et les caméras vidéo sont particulièrement importants, car ils disposent à la fois d’une grande puissance de calcul (leur permettant ainsi d’héberger des logiciels malveillants sophistiqués) et de liaisons montantes à haut débit (depuis lesquelles ils ont lancé des attaques atteignant chacune 100 Mbit/s). Le trafic total de l’attaque visant Krebs s’est élevé à 620 Gbit/s, ce qui en faisait à l’époque la plus importante attaque DDoS au monde.

La deuxième attaque a mis hors service OVH, le plus grand hébergeur français (le troisième au monde, si l’on en croit les publications), pendant une grande partie de la journée. De nombreux médias ont indiqué que l’attaque contre OVH avait atteint près du double de l’attaque contre Krebs, soit un térabit par seconde.

La troisième attaque, et peut-être la pire, a visé 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 avait été publié).

Alors, qui est derrière tout ça ?

Par une étrange coïncidence, Bruce Schneier, figure éminente du secteur, avait multiplié les interviews le mois précédent pour mettre en garde contre l’imminence d’attaques DDoS massives menées par des États-nations. Ses informations privilégiées provenaient de sources anonymes du secteur qui avaient repéré des attaques DDoS de calibrage visant l’infrastructure centrale d’Internet.

Mais il s’avère que ces attaques exploratoires n’étaient peut-être qu’une coïncidence. Schneier lui-même a reconnu sur son blog qu’il ne pensait pas que l’attaque contre Dyn était le fait d’un État. Mais peut-être que cet État se contente d’observer et d’attendre.

La clé permettant d’identifier les responsables dans les affaires Krebs, OVH et Dyn pourrait bien venir de Brian Krebs lui-même.

« L’attaque contre DYN survient quelques heures seulement après que le chercheur de DYN Doug Madory 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 Gbit/s contre KrebsOnSecurity.com s’est produite quelques heures seulement après la publication de l’article auquel Madory et moi avions collaboré. »

Il est très probable que l’adversaire soit un individu (ou un petit groupe) qui en veut à Brian Krebs, à Doug Madory, ou aux deux.

Nous pourrions tous comprendre que des millions d’utilisateurs soient touchés par une cyberguerre totale entre la Chine et les États-Unis. Mais s’il s’avérait qu’il s’agit d’une vendetta personnelle menée par un individu contre un autre ? Ce serait encore plus effrayant qu’une attaque menée par un État. Quel genre d’Internet avons-nous construit pour qu’une seule personne, animée par une rancune envers une autre, puisse perturber des services essentiels pour des millions de personnes ?

Comment en sommes-nous arrivés là ?

F5 surveille la recherche d’appareils de l’Internet des objets (IoT) depuis maintenant plus d’un an. Notre premier rapport sur ce sujet a été publié en juillet 2016 et faisait état d’une augmentation de 140 % sur un an des analyses par force brute visant Telnet et SSH. Telnet et SSH sont des ports d’administration à distance largement utilisés, qui sont souvent laissés exposés à Internet par inadvertance avec les identifiants et mots de passe par défaut du fournisseur (ou faciles à deviner).

Les attaques DDoS sans précédent qui ont visé Krebs, OVH et Dyn en octobre 2016 ont précisément utilisé 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 opérateurs de botnets n’hésitent pas à retourner leur cyberarme contre certains des plus grands fournisseurs au monde — des cibles que l’on pensait auparavant intouchables.

Même si ces attaques peuvent donner l’impression d’être survenues du jour au lendemain, en réalité, le responsable du botnet recherche, repère et compromet progressivement des appareils IoT vulnérables depuis au moins un an.

Analyse approfondie de ce que nous savons

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

La puissance de frappe cumulée est probablement dix fois supérieure à celle des précédents botnets, dépassant plusieurs térabits par seconde.

Le botnet IoT utilise notamment les techniques DDoS avancées suivantes. La section ci-dessous consacrée aux recommandations fournira des conseils sur les mesures permettant d’en atténuer les effets, lorsque cela est possible.

Inondations de requêtes HTTP GET résistantes à la redirection

Les attaques par déluge de requêtes HTTP GET étaient déjà redoutables. Depuis des années, les attaquants peuvent mettre des sites web hors service en envoyant un déluge de requêtes HTTP portant sur des objets volumineux ou des requêtes de base de données lentes. En général, ces requêtes traversent sans encombre un pare-feu standard, car la plupart des appareils dotés d’un traitement matériel des paquets les considèrent comme des requêtes HTTP normales. Le code d’attaque de Mirai va encore plus loin : il identifie les services cloud de neutralisation des attaques DDoS, puis contourne les redirections 302 qu’ils lui renvoient. Les redirections constituaient autrefois un bon moyen de déjouer les bots rudimentaires, mais celui-ci n’a rien de rudimentaire.

Torture par saturation DNS

Le bot Mirai intègre une attaque par « torture par l’eau » visant un fournisseur DNS. Cette technique diffère des attaques classiques par réflexion et amplification DNS, car le bot doit envoyer beaucoup moins de requêtes : il laisse le serveur DNS récursif du FAI mener l’attaque contre le serveur DNS faisant autorité ciblé. Lors de cette attaque, le bot envoie une requête DNS correctement formée contenant le nom de domaine cible à résoudre, auquel il ajoute un préfixe généré aléatoirement. L’attaque devient efficace lorsque le serveur DNS cible est surchargé et ne répond plus. Les serveurs DNS du FAI retransmettent alors automatiquement la requête afin d’essayer un autre serveur DNS faisant autorité de l’organisation ciblée, attaquant ainsi ces serveurs pour le compte du bot.

Dyn a confirmé dans son article de blog, Dyn Analysis Summary of Friday, October 21 attack, que la technique de la « torture par l’eau » avait bien été utilisée contre l’entreprise.

« Par exemple, l’impact de l’attaque a provoqué une avalanche de nouvelles tentatives légitimes, les serveurs récursifs essayant d’actualiser leur cache, générant ainsi un volume de trafic 10 à 20 fois supérieur à la normale sur un grand nombre d’adresses IP. Lorsque le trafic DNS est saturé, les nouvelles tentatives légitimes peuvent accroître davantage encore le volume de trafic.

Il semble que les attaques malveillantes provenaient d’au moins un botnet, la tempête de nouvelles tentatives ayant donné l’impression erronée que le nombre de terminaux était nettement supérieur à ce que nous savons aujourd’hui. Nous poursuivons l’analyse des données, mais au moment de la rédaction de ce rapport, leur nombre est estimé à 100 000 terminaux malveillants. »

Quelques semaines auparavant, Liron Segal, chercheur chez F5, avait détaillé le fonctionnement de l’attaque « Water Torture » du bot dans son article « Mirai, le bot qui a mis Krebs hors ligne ».

Attaques de couche 4 mises à jour

Selon le créateur du bot, l’attaque dite « TCP STOMP » est une variante du simple flood ACK visant à contourner les dispositifs d’atténuation. L’analyse de la mise en œuvre réelle de cette attaque semble indiquer que le bot établit une connexion TCP complète, puis continue à envoyer massivement des paquets ACK dotés de numéros de séquence légitimes afin de maintenir la connexion active.

Compte tenu de notre compréhension des différents vecteurs de menace associés au nouveau bot IoT, nous pouvons fournir quelques recommandations pour atténuer chacun d’entre eux.

Soyons clairs avant de commencer à formuler nos recommandations. Les attaques contre Krebs, OVH et Dyn sont sans commune mesure. De toute évidence, les techniques existantes d’atténuation des attaques DDoS n’ont pas permis de repousser facilement les assaillants, d’où les interruptions de service et leur forte médiatisation. Toutefois, dans de nombreux cas, les mesures d’atténuation ont bel et bien fini par porter leurs fruits. Une architecture adaptée, reposant notamment sur l’utilisation d’Anycast et de centres de données géographiquement dispersés, a également été utile. Il convient de noter que la côte Ouest et les régions occidentales des États-Unis ont été largement épargnées par l’attaque contre Dyn.

Recommandations prescriptives

Nos recommandations s’appuient sur l’expérience de nos propres clients. Depuis vingt ans, F5 assure la mise à disposition des applications des plus grandes marques mondiales, et nombre de ces clients subissent quotidiennement des attaques DDoS. Nos clients les plus expérimentés répartissent leurs défenses en trois ou quatre zones :

• Nettoyage du trafic dans le cloud
• Défense du réseau
• Défense des applications
• DNS, le cas échéant

Une architecture offrant une résistance optimale aux attaques DDoS se présente donc comme suit :

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

Défense contre les attaques volumétriques

L’hébergeur français OVH a été la cible d’une attaque volumétrique de 990 Gbit/s. Selon certaines informations, l’attaque contre Dyn aurait atteint un pic de 1,2 Tbit/s. Les attaques de cette ampleur ne peuvent généralement être atténuées que par des services de nettoyage du trafic dans le cloud, spécialisés dans la protection à grande échelle. Ces services, notamment Silverline DDoS Protection de F5, interceptent le trafic malveillant, le filtrent et n’acheminent vers la cible que le trafic légitime, via des tunnels préconfigurés.

Recommandation : Les organisations doivent veiller à conclure des accords avec un ou plusieurs services de nettoyage du trafic dans le cloud avant de subir une attaque. Il est difficile de configurer les tunnels préétablis en pleine attaque volumétrique. Intégrez à votre stratégie de protection contre les attaques DDoS un contrat avec un service de défense DDoS reposant sur le nettoyage du trafic dans le cloud.

Recommandation : La répartition des attaques peut être une alliée face aux attaques volumétriques. N’oubliez pas que le DNS peut également vous être utile : utilisez Anycast dans vos centres de données répartis dans le monde entier pour le contenu répliqué, afin de répartir les attaques DDoS lorsqu’elles surviennent. Chaque centre de données utilisant Anycast peut contribuer à diviser l’attaque.

Ressources pertinentes :

• F5 Silverline DDoS – Méthodes de déploiement
• Le guide F5 sur les attaques DDoS : dix étapes pour lutter contre les attaques DDoS en temps réel
• Bonnes pratiques recommandées par F5 pour la protection contre les attaques DDoS
• Architecture de référence F5 pour la protection contre les attaques DDoS

Défense du réseau

Le bot Mirai dispose dans son arsenal de plusieurs attaques de couche 4 : inondations SYN standard, inondations TCP et inondations UDP. Ces vecteurs de menace anciens doivent être neutralisés soit par un service de nettoyage du trafic dans le cloud, soit, s’ils sont suffisamment limités, au niveau de la couche de défense réseau du centre de données. Cette couche s’articule autour du pare-feu réseau. Elle est conçue pour contrer les attaques visant les ressources de calcul, telles que les inondations SYN et les attaques par fragmentation ICMP. Elle permet également d’atténuer les attaques volumétriques jusqu’à saturation du point d’entrée (généralement entre 80 et 90 % de la capacité nominale de la liaison).

Recommandation : De nombreux pare-feu ne résistent pas aux attaques DDoS s’ils ne sont pas correctement configurés. Consultez le fournisseur de votre pare-feu réseau pour connaître les paramètres appropriés. Certains clients placent des dispositifs anti-DDoS devant leurs pare-feu afin de repousser les attaques de couche 4.

Recommandation : Le module de pare-feu F5 (BIG-IP Advanced Firewall Manager (AFM)) a été spécialement conçu pour contrer les attaques de couche 4. Certains architectes utilisent BIG-IP AFM précisément à cette fin, soit en amont des pare-feu réseau classiques, soit pour les remplacer. Les appliances matérielles équipées d’AFM utilisent des réseaux de portes programmables pour contrer plus de 30 types d’inondations de paquets et décharger le processeur de ce travail.

Ressources pertinentes :

• Atténuation des attaques DDoS avec BIG-IP AFM
• Fiche technique de F5 BIG-IP Advanced Firewall Manager
• Les dix fonctionnalités de sécurité F5 les plus avancées de BIG-IP 12.1
• Bonnes pratiques recommandées pour la protection contre les attaques DDoS de F5

Défense des applications

Le bot Mirai peut générer d’impressionnantes inondations de requêtes HTTP GET et gérer les redirections. Comme ces inondations ressemblent à du trafic normal pour les dispositifs de défense du réseau, elles doivent être traitées au niveau applicatif. Les inondations de requêtes GET sont de loin le type d’attaque de la couche applicative le plus fréquemment observé par F5, et il existe de nombreuses façons de les atténuer, selon la gamme de produits dont dispose le client.

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

Ressources pertinentes :

• Pratiques recommandées pour la protection contre les attaques DDoS avec F5
• Protection de la page de connexion avec ASM
• DevCentral : mur de connexion simple avec iRule

Protection DNS

Deux problématiques liées au DNS méritent d’être abordées concernant l’attaque contre Dyn. La première, et la plus évidente, est de savoir quoi faire si votre fournisseur DNS est mis hors ligne par l’un de ces nouveaux types d’attaques. Dyn fournissait les services de noms de domaine à Twitter, GitHub et Spotify. Ainsi, lorsque Dyn a été bloqué, les utilisateurs finaux n’ont plus pu trouver les adresses IP de ces services.

Recommandation : renforcez la résilience de votre stratégie DNS, notamment en faisant appel à plusieurs fournisseurs DNS pour fournir les adresses de vos applications critiques. Ainsi, si l’un des fournisseurs est temporairement mis hors service par une attaque, l’autre pourra continuer à fournir vos adresses. Cela pourra ralentir vos utilisateurs finaux de quelques millisecondes, mais vos applications et services resteront disponibles.

Le deuxième problème consiste à déterminer la marche à suivre si votre propre serveur DNS fait l’objet d’une attaque. Le DNS est le service le plus ciblé, suivi du HTTP. Lorsque le DNS est perturbé, tous les services externes du centre de données sont affectés, et pas seulement une application. Ce point unique de défaillance totale, associé à une infrastructure DNS souvent sous-dimensionnée, fait du DNS une cible de choix pour les attaquants.

Rappelez-vous que même si votre propre serveur n’est pas attaqué, une panne en aval pourrait amener un autre ensemble de serveurs DNS à submerger vos serveurs DNS de requêtes en tentant de remplir leurs propres caches. Dyn a signalé un volume de requêtes 10 à 20 fois supérieur à la normale lorsque cela lui est arrivé, et ces requêtes provenaient de serveurs DNS légitimes qui tentaient de faire face à la situation.

Recommandation : Une part importante des services DNS sont sous-dimensionnés au point de ne pas pouvoir résister à des attaques DDoS, même de faible ou moyenne ampleur. Les caches DNS se sont généralisés, car ils peuvent améliorer les performances perçues d’un service DNS et offrir une certaine résilience face aux attaques classiques par requêtes DNS. Les attaquants se sont tournés vers les attaques dites « domaine inexistant » (ou NXDOMAIN), qui réduisent rapidement à néant les gains de performances apportés par le cache.

Pour ses clients, F5 recommande de placer devant les services DNS le module proxy DNS appelé F5 DNS Express™. DNS Express agit comme un résolveur faisant autorité en amont des serveurs DNS existants. Il charge les informations de zone à partir des serveurs et résout chaque requête ou renvoie NXDOMAIN. Il ne s’agit pas d’un cache et il ne peut donc pas être vidé par des rafales de requêtes NXDOMAIN.

Conseil : N’oubliez pas que le DNS peut être votre allié lors d’une attaque DDoS. Utilisez Anycast pour vos centres de données mondiaux hébergeant du contenu répliqué afin de répartir les attaques DDoS lorsqu’elles se produisent.

Conseil : réfléchissez à l’emplacement des services DNS. Souvent, le service DNS repose sur son propre ensemble d’équipements, distinct du premier périmètre de sécurité. Cela permet de maintenir le DNS indépendant des applications qu’il dessert.

Certaines grandes entreprises disposant de plusieurs centres de données fournissent des services DNS en dehors du périmètre de sécurité principal en associant BIG-IP DNS avec DNS Express et le module de pare-feu BIG-IP AFM. Le principal avantage de cette approche est que les services DNS restent disponibles même si la couche de défense du réseau devient indisponible à la suite d’une attaque DDoS.

Ressources pertinentes :

• F5 Friday : pas de DNS ? Plus rien…
• Fiche technique de F5 DNS
• DevCentral : DNS Express et transferts de zone
• DevCentral : DNS Express - Partie 1
• L’infrastructure DNS dynamique
• Bonnes pratiques recommandées par F5 pour la protection contre les attaques DDoS
• Architecture de référence F5 pour la protection contre les attaques DDoS

Conclusion

Les attaques contre Krebs, OVH et Dyn marquent une nouvelle phase dans l’évolution des attaques DDoS. Elles témoignent également de l’arrivée à maturité de l’Internet des objets.

Comme vous pouvez le constater, F5 possède une solide expérience en matière de recherche, de lutte et de publication sur les attaques DDoS, et nous souhaitons collaborer avec nos clients afin de garantir la disponibilité de leurs applications. Cela exigera la vigilance de tous, de F5 aux clients en passant par les partenaires.

Si vous êtes client, ou même si vous ne l’êtes pas, et que vous subissez une attaque, n’oubliez pas que la solution F5 Silverline DDoS Protection est à votre disposition sur simple appel au 866-329-4253.

Quant à la menace liée à l’IoT, les pirates malveillants partagent constamment leurs ressources entre eux (ils ont diffusé Mirai après ses attaques contre Krebs et OVH, puis celui-ci a été utilisé lors de l’attaque contre Dyn). Au sein de la communauté de la sécurité informatique, nous devons nous inspirer de leurs méthodes et unir nos forces pour résoudre ce problème mondial lié à l’IoT. Nous n’avons pas d’autre choix. Il est dans la nature humaine de comprendre les problèmes, de les résoudre et, ainsi, d’évoluer.

Il y aura sans aucun doute quelques difficultés au cours des prochaines années, tandis que les attaques gagneront en ampleur, que les services de nettoyage augmenteront leur bande passante pour faire face à ces attaques massives et que les fabricants d’appareils IoT chercheront comment remédier aux failles de sécurité de leurs produits. Les organisations et les consommateurs devront s’adapter à cette menace en constante évolution, comme ils l’ont fait pour tous les autres problèmes majeurs qui l’ont précédée.

À propos de l’auteur

F5

Autres articles de F5