Travailler au sein de l’équipe Incapsula chez Imperva, c’est être exposé à des attaques DDoS en permanence. Qu’il s’agisse des assauts à 100 Gbit/s qui affolent les écrans de nos ordinateurs ou des rapports d’attaques neutralisées qui bombardent nos messageries, le DDoS est notre pain quotidien.

Pourtant, de temps à autre, une attaque sort de l’ordinaire et retient véritablement notre attention. Ces sont ces attaques dont nous nous échangeons des copies d’écran et parlons dans les médias et sur notre blog.

Souvent, ces épisodes nous alertent sur l’émergence de nouvelles tendances. C’est de l’une de ces attaques que je souhaiterais vous en parler ici, car elle remet en question notre vision de la protection contre les attaques DDoS applicatives.

Rappel sur les attaques DDoS applicatives

Dans les grandes lignes, les attaques DDoS au niveau de la couche 7– la couche application, d’où le qualificatif « applicatives » – sont des tentatives d’épuiser les ressources d’un serveur (par exemple la capacité de sa mémoire et de son processeur) en lançant un grand nombre de tâches de traitement à travers une multitude de requêtes HTTP GET/POST.

Dans le contexte de cet article, je me dois de préciser que, bien que fatales pour les serveurs, les attaques applicatives ne sont pas particulièrement volumineuses. Elles n’ont d’ailleurs pas besoin de l’être car de nombreux responsables d’applications ne prévoient que 100 requêtes par seconde (RPS) au maximum, de sorte que même des attaques de moindre ampleur peuvent gravement handicaper des serveurs non protégés.

En outre, même à un débit de requêtes extrêmement élevé (nous avons vu des attaques atteindre 268 000 RPS), la bande passante consommée par les attaques applicatives demeure généralement faible car la taille des paquets composant chaque requête ne dépasse souvent guère quelques centaines d’octets.

En conséquence, les attaques applicatives les plus intenses restent bien au-dessous des 500 Mbit/s. C’est pourquoi certains fournisseurs et architectes dans le domaine de la sécurité avancent qu’il suffit ; pour les contrer, de solutions de filtrage n’offrant pas nécessairement une capacité de montée en charge supplémentaire.

Une gigantesque attaque HTTP POST Flood

L’attaque qui remet en question cette théorie s’est produite il y a quelques semaines de cela, lorsque l’un de nos clients – un site de loterie basé en Chine – a été la cible d’une attaque de type HTTP POST Flood culminant à pas moins de 163 000 RPS.

Trafic d’attaque en RPS (requêtes par seconde)

Pour élevé que soit ce nombre de requêtes, la véritable surprise est venue lorsque nous avons constaté que l’attaque culminait également à 8,7 Gbit/s (!) de bande passante, un record pour une attaque applicative, sans conteste la plus volumineuse que nous ayons jamais observée ou dont nous ayons même entendu parler jusqu’alors.

Trafic d’attaque en Gbit/s (gigabits par seconde)

Cherchant à comprendre comment une attaque applicative pouvait atteindre de tels sommets, nous avons inspecté les requêtes POST malveillantes. Nous avons alors découvert un script qui génère de manière aléatoire de très gros fichiers et tente de les envoyer (par la commande « POST ») vers le serveur.

Ce faisant, les auteurs des attaques ont pu créer un gigantesque flux HTTP, composé de requêtes d’une longueur démesurée. Celles-ci ne paraissaient pas suspectes, du moins jusqu’à ce que les connexions TCP soient établies et les requêtes inspectées par notre solution de neutralisation des attaques DDoS applicatives, Website Protection.

Exemple de requête d’attaque POST

L’algorithme s’exécutait sur des machines infectées par une variante du malware Nitol. Dès lors, il accédait au site Web en se faisant passer pour un robot d’indexation (spider) du moteur de recherche Baidu, au moyen de l’agent utilisateur suivant :

Mozilla/5.0 (compatible ; Baiduspider/2.0 ; +http://www.baidu.com/search/spider.html

Au niveau mondial, le trafic d’attaque provenait de 2700 adresses IP, la plupart d’entre elles étant situées en Chine, comme le montre la carte ci-dessous.

Géolocalisation des machines infectées utilisées dans l’attaque

Une attaque DDoS à 8,7 Gbit/s qui met en question la protection DDoS hybride

En dehors de tout contexte, une attaque de 8,7 Gbit/s pourrait ne pas sembler préoccupante, en particulier de nos jours, alors que les prestataires de services de sécurité, y compris nous-mêmes, communiquent régulièrement sur des assauts de 200, 300 et 400 Gbit/s.

Cependant, ces attaques dites volumétriques se situent toutes au niveau de la couche réseau et il est donc habituel qu’elles soient de grande ampleur. En revanche, une attaque applicative de plusieurs gigabits constitue une menace inattendue. A ce titre, elle est susceptible de faire mouche là où une attaque plus violente sur la couche réseau serait déjouée.

En effet, le trafic applicatif ne peut être filtré qu’après l’établissement de la connexion TCP. Cela signifie qu’en l’absence d’une solution de neutralisation en amont, les requêtes malveillantes peuvent pénétrer dans votre canal réseau, ce qui pose un problème considérable dans le cas d’attaques de plusieurs gigabits.

C’est ici qu’entrent en jeu les solutions de protection DDoS hybrides, qui associent un service hors site, destiné à contrer les menaces au niveau de la couche réseau, à une appliance sur site qui neutralise les attaques applicatives.

Le goulet d’étranglement de la topologie de protection DDoS hybride

Si elle est efficace sur le plan conceptuel, cette topologie présente un talon d’Achille, à savoir la capacité du canal réseau. Par exemple, pour faire face à une attaque de l’ordre de 9 Gbit/s – comme celle décrite ici – au niveau de la couche 7, le réseau a besoin d’une liaison montante de 10 Gbit, faute de quoi la connexion sera tout simplement saturée par les requêtes DDoS, lesquelles ne peuvent pas être identifiées comme telles tant qu’une connexion n’a pas été établie avec l’appliance.

Une liaison montante de capacité insuffisante dans cette situation aboutirait à un déni de service, même si l’appliance filtre les requêtes après qu’elles ont franchi le canal.

Certes, bon nombre de grandes entreprises disposent aujourd’hui d’une liaison montante dotée d’une capacité de dépassement de 10 Gbit. Cependant, les auteurs des attaques peuvent facilement en intensifier l’ampleur, soit en déclenchant davantage de requêtes, soit en mobilisant des ressources de botnets supplémentaires. Par conséquent, l’attaque suivante pourrait très bien atteindre voire dépasser 12 ou 15 Gbit/s. Très peu d’entreprises, en dehors des FAI, ont les moyens de neutraliser sur site des attaques de ce volume.

En outre, les attaques applicatives sont faciles à prolonger dans le temps. Récemment, nous en avons observé une pendant 101 jours d’affilée, alors même que dix jours de dépassement de capacité engendrent déjà le paiement de frais considérables. Du point de vue financier, c’est l’une des principales raisons d’être des solutions de neutralisation DDoS, offrir une capacité économique de montée en charge évitant d’avoir à payer de coûteux frais d’engagement ou de dépassement.

Un signal d’alerte

L’expérience montre que les méthodes anti-DDoS efficaces font rarement exception à la règle. A l’heure où j’écris, le botnet décrit plus haut est toujours actif et le script en question toujours employé dans l’attaque. En outre, il est probable qu’il se répande davantage à mesure que d’autres opérateurs de botnets découvrent son potentiel de nuisance.

L’existence de ces menaces apporte une justification supplémentaire pour les solutions de neutralisation hors site qui terminent les connexions TCP en dehors du périmètre réseau. Celles-ci ne sont pas bridées par la capacité de votre canal réseau et peuvent monter en charge à la demande pour filtrer tout volume de trafic applicatif.

C’est précisément ce qui s’est passé dans le cas de l’attaque de 8,7 Gbit/s au niveau de la couche 7, lorsque notre solution Website Protection a pu traiter le vecteur spécifique d’attaque HTTP Flood automatiquement et immédiatement.

Cela dit, nous sommes conscients que certaines entreprises ont l’obligation réglementaire de terminer les connexions TCP sur site et n’ont donc d’autre choix que d’utiliser des appliances de neutralisation. Si tel est votre cas, notre meilleur conseil est d’envisager une augmentation de capacité de votre liaison montante de sorte qu’elle puisse au moins contrer les attaques inférieures à 10 Gbit/s.

D’une manière ou d’une autre, cette attaque doit servir de piqûre de rappel pour la prise en compte de la capacité de montée en charge lors de l’élaboration des plans de défense contre les attaques applicatives.