DDoS : OVHcloud met en garde contre l’essor des attaques par haut débit de paquets

DDoS : OVHcloud met en garde contre l’essor des attaques par haut débit de paquets

Les petits paquets font les grands DDoS

11

DDoS : OVHcloud met en garde contre l’essor des attaques par haut débit de paquets

Dans un long exposé, OVHcloud est revenu sur la problématique des attaques par haut débit de paquets, l’une des formes des attaques par déni de service distribué. Selon l’hébergeur, elles sont en recrudescence, avec une nouvelle tendance : l’utilisation d’appareils situés dans les cœurs de réseau, pouvant rendre les attaques plus complexes à absorber.

Avant de plonger dans les informations données par OVHcloud, revenons à l’essentiel : qu’est-ce qu’une attaque par déni de service distribué, ou DDoS ?

L’idée principale est toujours la même : submerger un serveur ou un équipement réseau sous un flot de requêtes ou de données. Face à cette vague, la ou les ressources réseau se retrouvent en situation d’embouteillage. Selon les cas, la cyberattaque peut saturer la liaison, le processeur, la mémoire ou plusieurs éléments. Il y a simplement trop de travail.

Le trafic légitime se retrouve pris dans ce torrent. La charge ne pouvant plus être répartie, des lenteurs plus ou moins importantes se font sentir, jusqu’à l’indisponibilité complète si l’attaque réussit.

Le moyen le plus couramment utilisé pour provoquer un tel déluge est de multiplier les sources d’émissions de paquets ou de requêtes. Souvent, l’attaque est produite depuis un botnet, une armée d’équipements « zombies ». Les pirates en prennent le contrôle par l’exploitation de failles de sécurité ou en détournant le fonctionnement à cause d’accès insuffisamment protégés. Le cas le plus emblématique est sans doute Mirai en 2016. Le logiciel malveillant avait créé un immense botnet d’appareils connectés, capable de créer de puissantes attaques DDoS.

Les attaques par déni de service distribué sont très courantes. La semaine dernière, Cloudflare dressait, par exemple, un bilan des attaques ayant eu lieu en France avant et après le premier tour des élections législatives. De nombreux sites de partis politiques ont ainsi été affectés. Les grands acteurs sont également visés. L'année dernière, Microsoft avait subi une vaste attaque et nombre de ses services avaient été perturbés pendant plusieurs jours.

Des bombardements de petits paquets

Dans ce domaine de cyberattaque, celles par débit de paquets ne sont pas nouvelles. Elles prennent cependant de l’ampleur, selon OVHcloud.

Ces attaques visent tout particulièrement la chaine de traitement des paquets transmis par réseau. Contrairement, par exemple, à l’envoi de données très volumineuses pour saturer la bande passante d’un ou plusieurs serveurs, le but est cette fois de minimiser leur taille pour en envoyer le plus grand nombre possible.

Le coût informatique est alors plus élevé, car chaque paquet, quelle que soit sa taille, suppose au minimum un accès à la mémoire. La succession d’un grand nombre de petits paquets va mobiliser tous les éléments de la chaine de traitement. Avantage pour les pirates : plutôt que d’essayer de trouver des failles dans le système anti-DDoS de l’infrastructure visée, l’attaque peut le détruire, résume OVHcloud.

La force de ces attaques se chiffre en millions de paquets par seconde, ou Mpps. « En bref, une attaque DDoS de 10 Gbps avec de gros paquets (1480 octets) produit environ 0,85 Mpps : en comparaison, 10 Gbps avec les plus petits paquets (84 octets sur le fil pour Ethernet) produit un énorme 14,88 Mpps environ », indique l’hébergeur. Jusqu’à récemment, la plus grosse attaque par débit de paquets connue était celle contre Akamai en 2020. Elle avait atteint le chiffre un peu fou de 809 Mpps.

La place des attaques par haut débit de paquets

S’il est plus difficile de gérer ce type d’attaque, il est également plus complexe de les mettre en œuvre. Le tsunami engendré contre Akamai n’est ainsi pas représentatif, même s’il montre le potentiel. Selon les chiffres d’OVHcloud, qui enregistre régulièrement ce type d’activité, la grande majorité des attaques par débit de paquets se situe sous la barre des 100 Mpps.

C’était du moins le cas jusqu’à il y a deux ans. Pendant six heures, l’hébergeur a écopé d’un gigantesque flux UDP, atteignant les 700 Mpps pendant quatre heures. D’un caractère inhabituel, elle a mis l’entreprise française en alerte. Celle-ci indique qu’au cours des 18 derniers mois, le nombre d’attaques supérieures à 100 Mpps a été décuplé, passant de quelques attaques par semaines « à des dizaines, voire centaines d’attaques par semaine ».

Depuis le début de l’année, plusieurs attaques ont franchi les 500 Mpps et une a même culminé à 620 Mpps. OVHcloud annonce même avoir atténué en avril la plus grosse attaque par débit de paquets connue à ce jour, avec 840 Mpps, « juste au-dessus du précédent record rapporté par Akamai ». Les paquets étaient tous de type TCP ACK (accusés de réception).

Un changement dans les sources

C’est dans cette attaque que l’hébergeur a trouvé un élément troublant. Elle avait été générée à partir de 5 000 IP sources environ, une caractéristique classique. Cependant, les deux tiers de tous les paquets provenaient de quatre IP seulement, toutes situées aux États-Unis, dont trois sur la côte ouest.

OVHcloud indique que ce scénario était jugé peu probable, car impliquant des ressources beaucoup plus importantes qu’une collection d’appareils connectés. L’entreprise a donc creusé le sujet en analysant une série d’attaques dont la puissance variait de 100 à 500 Mpps. À sa surprise, la plupart avaient été générés par un nombre relativement faible de sources.

De cette analyse, la société a retiré une liste d’adresses IP « offensives bien connues », capables de générer 1 Mpps au moins, et jusqu’à 14,8 Mpps. Une majorité de ces adresses appartiennent à des systèmes autonomes asiatiques, mais d’autres proviennent d’Europe, du Moyen-Orient, ainsi que des Amériques du Nord et du Sud.

La vraie surprise : les cœurs de réseau

Pour en savoir plus sur ces adresses IP, OVHcloud s’est ensuite servi d’Onyphe. Lancé en 2017, ce moteur de recherche est spécialisé dans la cyberdéfense. Il concentre les données de renseignement en sources ouvertes et de cybermenaces « collectées en explorant diverses sources disponibles sur Internet ou en écoutant le bruit de fond Internet ». Il s’est avéré que la plupart des adresses IP étaient liées à des routeurs de marque MikroTik, un constructeur européen (Lettonie).

OVHcloud en a déduit qu’il s’agissait probablement d’appareils compromis. Le système d’exploitation de ces appareils, RouterOS, a en effet « souffert de plusieurs CVE critiques au cours des dernières années ». Cependant, l’hébergeur a été surpris en constatant qu’une partie des routeurs examinés disposaient d’une version récente. Or, depuis avril, aucune vulnérabilité affectant RouterOS n’a été publiée. OVHcloud suppose que ces appareils ont été mis à jour plus tard, mettant fin à la compromission. En d’autres termes, l’hébergeur aurait regardé trop tard. Ou alors, il s’agit d’un type inconnu de compromission.

L’équipe s’est ensuite tournée vers SNMP pour obtenir des informations sur les équipements. D’après les résultats obtenus, ils appartiennent tous à la série CCR (Cloud Core Routers) de MikroTik. Une nouvelle recherche sur Onyphe a permis de lister 99 382 appareils CCR « largement ouverts » sur internet, tout particulièrement le modèle CCR1036-8G-2S+ (30 972 occurrences). OVHcloud dit avoir averti le constructeur letton, qui a répondu hier « enquêter sur les causes possibles du problème ».

L’hébergeur, qui se doutait qu’il ne s’agissait pas de simples appareils domestiques, a eu la confirmation que les IP sources étaient en grande partie liées à des équipements de cœurs de réseaux. L’hébergeur s’est livré à quelques calculs théoriques en prenant comme base les informations techniques de ces modèles. Selon lui, ces équipements avaient les capacités pour déclencher les attaques observées.

Une remise en cause des protections

Ce constat a amené OVHcloud à se questionner sur la pertinence des protections mises en place jusqu’ici. Il était en effet estimé très complexe de générer une telle quantité de petits paquets depuis un faible nombre de sources.

« Cela met en évidence la capacité de l'adversaire à envoyer un taux de paquets énorme à travers seulement quelques peerings, ce qui peut s'avérer très problématique. En général, les équipes de réponse anti-DDoS – et pas uniquement chez OVHcloud – supposent qu'il est très difficile d'envoyer des DDoS massifs à partir d'un petit nombre d'emplacements géographiques. Sur la base de cette hypothèse, nos infrastructures sont mises à l'échelle horizontalement, réparties dans le monde entier, et elles absorbent la charge plus facilement », explique ainsi l’hébergeur.

L’attaque d’avril a « fortement remis en question » cette vision. « Nous envisagerons d'ajuster le modèle général de dimensionnement et de distribution de nos infrastructures anti-DDoS afin de pouvoir faire face à de futures (et probablement plus importantes) attaques, comme nous le faisons aujourd'hui », indique OVHcloud.

L’hébergeur indique que les éléments collectés suggèrent une nouvelle tendance. Si des équipements de cœurs de réseau sont compromis, ils peuvent être utilisés pour déclencher des attaques plus puissantes. OVHcloud parle de « nouvelle ère » potentielle pour ce type d’attaques, avec des botnets possiblement « capables d'émettre des milliards de paquets par seconde ».

Pour l’hébergeur, c’est même toute l’infrastructure anti-DDoS actuelle qui pourrait être remise en question. D’autant que sur les attaques analysées, les équipements identifiés sont taillés pour les réseaux de petite et moyenne taille. « Des équipements beaucoup plus puissants sont disponibles aujourd'hui », ajoute OVHcloud.

Commentaires (11)


Merci pour cet article intéressant 👍
Pour celles et ceux qui se demanderaient "mais pourquoi on ne fait pas des patchs pour détecter les attaques DDoS ? ", sachez que le plus gênant est que les failles exploitée pour faire ces attaques sont des failles dans les protocoles d'Internet eux-mêmes, et PAS dans leur implémentation.

Si je devais trouver une image pour clarifier la situation, ce serait celle-ci :
- Vous êtes un humain qui donne l'heure aux autres qui lui demandent dans la rue.
- Avant de pouvoir parler avec un autre humain, vous DEVEZ répondre "Bonjour" à CHAQUE "Bonjour".
- Tout vas bien en temps normal, mais à un concert d'un grand groupe, tout le public crie "Bonjour" : vous avez donc plusieurs milliers de "Bonjour" auxquels répondre, et il y a justement quelqu'un qui vient de vous dire bonjour car il souhaite vous demander l'heure.
=> DDoS
- Le protocole a une faille, et il faut le changer. Mais il faut alors que TOUT LE MONDE change de protocole. Mais le pire : comment changer ce protocole ?
On peut utiliser les statistiques, le % de bonjour sur le reste et ban IP la source.
Sur les 100 dernières trames TCP, il y a > 90% de ACK = ban.
Bannir ou ignorer le paquet, ça marche aussi.

Ça demande par contre des ressources de calculs.

mrintrepide

On peut utiliser les statistiques, le % de bonjour sur le reste et ban IP la source.
Sur les 100 dernières trames TCP, il y a > 90% de ACK = ban.
Bannir ou ignorer le paquet, ça marche aussi.

Ça demande par contre des ressources de calculs.
Donc si je veux éviter ton ban, il faut que j'utilise une adresse IP différente à chaque paquet (simple).
Ou sinon, j'utilise ton système à mon avantage en envoyant plein de requêtes avec une IP qui va se faire bannir, et je recommence avec une autre et ainsi de suite jusqu'à ce que tu ai ban tout Internet, et j'ai plus besoin de t'attaquer : tu te coupe tout seul d'Internet.

Ah, et aussi, s'il est vaguement envisageable de stocker une liste de toutes les IPv4 à bannir, si tu essaies de faire de même avec IPv6, tu vas très vite remplir ta mémoire.
Modifié le 12/07/2024 à 23h13

Historique des modifications :

Posté le 12/07/2024 à 23h12


Donc si je veux éviter ton ban, il faut que j'utilise une adresse IP différente à chaque paquet (simple), ou j'utilise ton système à mon avantage en envoyant plein de requêtes avec une IP qui va se faire bannir, et je recommence avec une autre et ainsi de suite jusqu'à ce que tu ai ban tout Internet, et j'ai plus besoin de t'attaquer : tu te coupe tout seul d'Internet.

Ah, et aussi, s'il est vaguement envisageable de stocker une liste de toutes les IPv4 à bannir, si tu essaies de faire de même avec IPv6, tu vas très vite remplir ta mémoire.

potn

Donc si je veux éviter ton ban, il faut que j'utilise une adresse IP différente à chaque paquet (simple).
Ou sinon, j'utilise ton système à mon avantage en envoyant plein de requêtes avec une IP qui va se faire bannir, et je recommence avec une autre et ainsi de suite jusqu'à ce que tu ai ban tout Internet, et j'ai plus besoin de t'attaquer : tu te coupe tout seul d'Internet.

Ah, et aussi, s'il est vaguement envisageable de stocker une liste de toutes les IPv4 à bannir, si tu essaies de faire de même avec IPv6, tu vas très vite remplir ta mémoire.
C'est plus compliqué, une personne ne peut obtenir le contrôle de toutes les IPs. (Si cela arrive, il y aura d'autres problèmes plus urgents)
On peut ignorer les paquets pendant 5,15 ou 60 minutes avant expiration.
Je n'ai pas dit que c'était simple et peut coûteux. C'est une solution par dessus des protocoles où des abus peuvent être faits.

Pour le SPAM, il y a bien des listes d'IPs, de blocs d'adresses et même d'ASN complet blacklisté.
Aux FAI de faire le travail d'avertissement lorsque blacklisté et aux clients de la sécurisation de leurs réseaux.

mrintrepide

C'est plus compliqué, une personne ne peut obtenir le contrôle de toutes les IPs. (Si cela arrive, il y aura d'autres problèmes plus urgents)
On peut ignorer les paquets pendant 5,15 ou 60 minutes avant expiration.
Je n'ai pas dit que c'était simple et peut coûteux. C'est une solution par dessus des protocoles où des abus peuvent être faits.

Pour le SPAM, il y a bien des listes d'IPs, de blocs d'adresses et même d'ASN complet blacklisté.
Aux FAI de faire le travail d'avertissement lorsque blacklisté et aux clients de la sécurisation de leurs réseaux.
C'est pas une question de contrôler une adresse IP, c'est juste que rien (à ma connaissance) n'interdit d'envoyer un packet IP en falsifiant l'adresse source : on envoie donc une requête en disant qu'on est X et, même si on n'aura jamais de réponse (puisqu'elle sera adressée à X), pour le destinataire, c'est X qui a envoyé la requête.

Mais je suis d'accord qu'on peut mettre en place des systèmes de protection par-dessus les protocoles, mais comme tu le dis ce n'est pas simple.

Mon point était avant tout d' expliquer un peu le problème pour les néophytes de ces questions. 😉
Passionnant ! Et désolant aussi...
Merci pour cette enquête fort intéressante. Et il semblerait donc qu'il y ai un cheveu dans routeros.
Les routeurs Mikrotik sont de très bon matériels avec de très grandes capacités logicielles (en gros ils peuvent tout faire sauf le café). Ils sont très utilisés en Italie par certains grand opérateurs, ou même en France par des opérateurs fibre. J'en utilise moi-même. Comme tous les autres routeurs, il faut suivre les mises à jour et les appliquer rapidement. L'avantage, c'est que c'est le même OS (un linux) pour tous les modèles, même très ancien. Il n'y a donc pas d'obsolescence logicielle comme avec les autres marques, il suffit de mettre à jour.
Certes de capacités complètes mais finalement, il doit certainement exister un 0-Day (Faille non encore découverte) pour que ce genre d'opérations soit possible avec.
Je me demande bien quelle mitigation mener face à ce genre de problème quand on exploite ce matériel particulièrement.
Merci pour cet article très intéressant et instructif !
Fermer