La fréquence et la force des attaques par déni de service distribué (DDoS) sont en hausse. Grâce à l'exploitation de millions d'appareils liés à l'Internet des objets (Ido) non sécurisés, la création de botnets capables de lancer des attaques volumétriques hautement distribuées est plus facile et plus efficace que jamais. En plus des volumes plus importants, les attaques délaissent les couches réseau et de transport pour viser la couche d'application (couche 7). Les attaques contre la couche applicative sont beaucoup plus sophistiquées ; elles nécessitent souvent moins de ressources pour rendre un site Web ou une application indisponible, et elles peuvent avoir un impact encore plus important sur l'activité.
Les attaques DDoS perturbent les opérations commerciales normales en dégradant les performances et la disponibilité des sites Web et des applications, voire en les déconnectant parfois complètement. Le coût horaire moyen des temps d'arrêt dus à une défaillance de l'infrastructure est de 100 000 $ par heure. Les attaques de cette nature entraînent généralement l'attrition de la clientèle, la dégradation de la marque et la perte d'activité.
Les sites Web et les applications nécessitent la résilience et l'intelligence d'un réseau évolutif pour lutter contre les attaques les plus importantes et les plus récentes. La protection contre les menaces ne doit pas dégrader les performances en renforçant la latence, et les services de sécurité doivent être faciles à configurer pour éliminer les erreurs de configuration, qui introduisent de nouvelles vulnérabilités.
Protection contre les attaques majeures
La capacité du réseau de Cloudflare est 15x plus grande que la plus grande attaque DDoS jamais enregistrée. Avec une capacité de 30 Tbps, il peut gérer n'importe quelle attaque distribuée moderne, y compris celles qui ciblent l'infrastructure DNS.
Intelligence réseau partagée
Avec chaque nouvelle propriété, le réseau de Cloudflare devient plus intelligent. La base de données de réputation IP de Cloudflare identifie et bloque les menaces émergentes à travers les 7 millions de propriétés du réseau.
Sécurité et performances sans compromis
Éliminez la latence provoquée par la sécurité grâce aux services intégrés d'amélioration des performances de Cloudflare, comprenant notamment le CDN, le routage intelligent, l'optimisation des sites Web et les dernières normes Web.
En perturbant la résolution DNS, une attaque de flood DNS peut rendre un site web, une API ou une application Web sous-performant, voire indisponible.
En exploitant les résolveurs DNS ou NTP ouverts, un pirate peut saturer un serveur ou un réseau avec du trafic amplifié, où la charge utile a une taille supérieure à la requête d'origine.
Les attaques de flood HTTP génèrent des volumes élevés de requêtes HTTP, GET ou POST provenant de sources multiples. Elles ciblent la couche d'application et provoquent la dégradation ou l'indisponibilité du service.
Avec son approche multicouche de la sécurité, Cloudflare combine plusieurs fonctionnalités en un seul service. Cette approche permet de bloquer le trafic illégitime et d'éviter les interruptions, tout en autorisant le trafic légitime pour que les sites Web, les applications et les API restent disponibles et performants.
Résultats principaux
226 500 000
attaques bloquées entre août 2015 et novembre 2016 (500 000 attaques par jour), et pas une seule n'a abouti.
95 %
de bande passante totale économisée mensuellement.
250 000 $
Lire l'étude de cas
Brad Parscale
Président de Giles-Parscale
Responsable des plates-formes numériques pour la campagne de Donald Trump
Toutes les offres Cloudflare comprennent l'atténuation illimitée des attaques par déni de service distribué (DDoS), quelle que soit leur taille, sans coût supplémentaire. Aucun client ne devrait être pénalisé pour les pics de trafic réseau associés à une attaque distribuée. La protection DDoS Cloudflare garantit que toutes les propriétés Internet restent en ligne et que les coûts d'infrastructure sont prévisibles.
Les ingénieurs de Cloudflare ont assisté à certaines des plus grandes attaques de l'histoire. Découvrez comment nous les avons repoussées sur notre blog.
En hiver 2016, Cloudflare a atténué sa plus grande attaque distribuée contre la couche 3 à ce jour. Et en plus de l'arrêter, nous l'avons mesurée et analysée en détail. En savoir plus
Les attaques distribuées peuvent prendre différentes formes. Le pirate qui a lancé cette attaque d'amplification de 400 Gbits/s a utilisé 4 529 serveurs NTP pour amplifier une attaque depuis un serveur source de 87 Mbits/s seulement.
En savoir plus
Depuis plus de 7 ans, Cloudflare repousse des attaques distribuées historiques. En 2013, les 120 Gbits/s contre Spamhaus étaient considérés comme une attaque d'envergure, et Cloudflare a été en mesure de maintenir leur site Web en ligne. En savoir plus
Empêchez les pirates de compromettre les données client sensibles, comme les informations de connexion ou de carte de crédit, ou d’autres données personnelles.
Empêchez les bots malveillants d’endommager vos ressources Internet par extraction de contenu, transaction frauduleuse ou usurpation de compte.
Les services de sécurité et d'amélioration des performances de Cloudflare fonctionnent de pair pour réduire la latence des sites Web, applications et API de bout en bout, tout en les protégeant contre les attaques DDoS, les bots malveillants et le vol de données.
Les services d'amélioration des performances de Cloudflare augmentent les taux de conversion, diminuent l'attrition et améliorent l'expérience des visiteurs, tout en protégeant la disponibilité des applications.
Les services de sécurité Cloudflare réduisent les risques de perte de clients, de baisse des revenus et de dégradation de la réputation en bloquant les attaques DDoS, les bots malveillants et le vol de données.
Étant donné que Cloudflare agit comme un proxy pour l'ensemble de votre trafic réseau, nous pouvons vous protéger contre toute forme d'attaque par déni de service distribué, y compris :
La plupart des attaques ciblent les couches de transport et de réseau d'un système de communication. Dans le modèle OSI, elles sont représentées par les couches 3 et 4. La couche dite « de transport » de la pile réseau détermine le protocole (par exemple, TCP ou UDP) suivant lequel deux hôtes d'un réseau communiquent entre eux. Les attaques dirigées contre les couches 3 et 4 sont conçues pour inonder une interface réseau avec du trafic hostile afin de saturer ses ressources et de lui empêcher de répondre au trafic légitime. Plus spécifiquement, les attaques de cette nature visent à saturer la capacité d'un commutateur réseau, ou à surcharger la carte réseau ou le processeur d'un serveur, et donc sa capacité à gérer le trafic de l'attaque.
Les attaques visant les couches 3 et 4 sont difficiles, voire impossibles à atténuer avec une solution sur site. Face à un pirate capable d'envoyer un volume supérieur au trafic qu'un lien réseau peut supporter, les ressources matérielles supplémentaires sont inutiles. Par exemple, si vous disposez d'un routeur avec un port de 10 Gbits/s et qu'un pirate vous envoie 11 Gbits/s de trafic hostile, tous les logiciels et le matériel combinés ne vous permettraient pas de mettre un terme à l'attaque, puisque le lien réseau est complètement saturé.
Les plus grandes attaques contre les couches 3 et 4 proviennent presque toujours d'un nombre important de sources. Ces nombreuses sources envoient chacune du trafic hostile vers un emplacement Internet unique, créant un raz-de-marée qui submerge les ressources de la cible. En ce sens, l'attaque est distribuée. Les sources de trafic d'attaque peuvent être un groupe d'individus travaillant ensemble, un botnet de PC compromis, un botnet de serveurs compromis, des résolveurs DNS mal configurés ou même des routeurs Internet privés avec des mots de passe faibles.
Comme un pirate qui lance une attaque contre les couches 3 et 4 ne se soucie pas de recevoir une réponse aux requêtes qu'il envoie, les paquets qui composent l'attaque n'ont pas besoin d'être précis ou correctement formatés. Les attaquants falsifient régulièrement les informations contenues dans les paquets de l'attaque, y compris l'adresse IP source, ce qui donne l'impression que l'attaque provient d'un nombre pratiquement infini de sources. Comme les données des paquets peuvent être entièrement randomisées, même des techniques telles que le filtrage IP en amont deviennent pratiquement inutiles.
Avec Cloudflare, tout le trafic d'attaque qui atteindrait directement l'infrastructure de votre serveur est automatiquement acheminé vers le réseau Anycast mondial de datacenters Cloudflare. Une fois que le trafic hostile est déplacé, nous sommes en mesure de tirer parti de l'importante capacité globale de notre réseau, ainsi que des baies d'infrastructure serveur, pour absorber les flots de trafic en périphérie. Lors d'une attaque classique contre les couches 3 et 4, pas un seul paquet de trafic d'attaque n'atteindra donc un site protégé par Cloudflare.
Les attaques d'amplification DNS, une forme de DRDoS, sont en augmentation et sont devenues la plus grande source d'attaques contre les couches 3 et 4. Cloudflare atténue régulièrement des attaques dépassant les 100 Gbits/s et a récemment protégé un client contre une attaque de plus de 300 Gbits/s que le New York Times a qualifiée de « plus grande attaque DDoS publiquement annoncée dans l'histoire d'Internet ».
Lors d'une attaque par réflexion DNS, le pirate envoie une requête pour un fichier zone DNS volumineux à un grand nombre de résolveurs DNS ouverts en usurpant l'adresse IP de sa victime. Les résolveurs répondent à la requête en envoyant chacun une réponse de zone DNS à l'adresse IP de la victime. Les requêtes du pirate sont beaucoup plus petites que les réponses, ce qui lui permet d'amplifier son attaque pour qu'elle atteigne une taille plusieurs fois supérieure aux ressources de bande passante dont il dispose.
Un pirate rassemble des ressources, telles que des botnets ou des récurseurs DNS non sécurisés, et imite l'adresse IP de sa cible. Les ressources envoient ensuite un flot de réponses à la cible, la mettant ainsi hors ligne.
Un pirate rassemble des ressources, telles que des botnets ou des récurseurs DNS non sécurisés, et imite l'adresse IP de sa cible. Les ressources envoient ensuite un flot de réponses à la cible, mais elles sont bloquées régionalement par les datacenters Cloudflare. Le trafic légitime peut toujours atteindre la ressource Web.
Il y a deux critères pour une attaque d'amplification : 1.) une requête peut être envoyée avec une adresse source usurpée (par exemple, via un protocole comme ICMP ou UDP qui ne nécessite pas d'établissement de liaison) ; et 2.) la réponse à la requête est significativement plus volumineuse que la requête elle-même. Le DNS est une plate-forme Internet omniprésente qui répond à ces critères et est devenue la principale source d'attaques d'amplification.
Les requêtes DNS sont généralement transmises via UDP, ce qui signifie que, comme les requêtes ICMP utilisées dans une attaque SMURF (décrites ci-dessous), elles sont autonomes une fois lancées. Par conséquent, l'attribut source d'une requête DNS peut être usurpé et le destinataire n'a aucun moyen de déterminer sa véracité avant de répondre. Le DNS est également capable de générer une réponse beaucoup plus volumineuse que la requête. Par exemple, vous pouvez envoyer la requête (minuscule) suivante (où x.x.x.x est l'adresse IP d'un résolveur DNS ouvert) :
dig ANY isc.org @x.x.x.x +edns=0
Et obtenir la réponse gigantesque suivante :
; <<>> DiG 9.7.3 <<>> ANY isc.org @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5147
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;isc.org. IN ANY
;; ANSWER SECTION:
isc.org. 4084 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012102700 7200 3600 24796800 3600
isc.org. 4084 IN A 149.20.64.42
isc.org. 4084 IN MX 10 mx.pao1.isc.org.
isc.org. 4084 IN MX 10 mx.ams1.isc.org.
isc.org. 4084 IN TXT "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 4084 IN TXT "$Id: isc.org,v 1.1724 2012-10-23 00:36:09 bind Exp $"
isc.org. 4084 IN AAAA 2001:4f8:0:2::d
isc.org. 4084 IN NAPTR 20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org. 484 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org. 4084 IN DNSKEY 256 3 5 BQEAAAAB2F1v2HWzCCE9vNsKfk0K8vd4EBwizNT9KO6WYXj0oxEL4eOJ aXbax/BzPFx+3qO8B8pu8E/JjkWH0oaYz4guUyTVmT5Eelg44Vb1kssy q8W27oQ+9qNiP8Jv6zdOj0uCB/N0fxfVL3371xbednFqoECfSFDZa6Hw jU1qzveSsW0=
isc.org. 4084 IN DNSKEY 257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org. 4084 IN SPF "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 484 IN RRSIG NS 5 2 7200 20121125230752 20121026230752 4442 isc.org. oFeNy69Pn+/JnnltGPUZQnYzo1YGglMhS/SZKnlgyMbz+tT2r/2v+X1j AkUl9GRW9JAZU+x0oEj5oNAkRiQqK+D6DC+PGdM2/JHa0X41LnMIE2NX UHDAKMmbqk529fUy3MvA/ZwR9FXurcfYQ5fnpEEaawNS0bKxomw48dcp Aco=
isc.org. 484 IN RRSIG SOA 5 2 7200 20121125230752 20121026230752 4442 isc.org. S+DLHzE/8WQbnSl70geMYoKvGlIuKARVlxmssce+MX6DO/J1xdK9xGac XCuAhRpTMKElKq2dIhKp8vnS2e+JTZLrGl4q/bnrrmhQ9eBS7IFmrQ6s 0cKEEyuijumOPlKCCN9QX7ds4siiTIrEOGhCaamEgRJqVxqCsg1dBUrR hKk=
isc.org. 484 IN RRSIG MX 5 2 7200 20121125230752 20121026230752 4442 isc.org. VFqFWRPyulIT8VsIdXKMpMRJTYpdggoGgOjKJzKJs/6ZrxmbJtmAxgEu /rkwD6Q9JwsUCepNC74EYxzXFvDaNnKp/Qdmt2139h/xoZsw0JVA4Z+b zNQ3kNiDjdV6zl6ELtCVDqj3SiWDZhYB/CR9pNno1FAF2joIjYSwiwbS Lcw=
isc.org. 484 IN RRSIG TXT 5 2 7200 20121125230752 20121026230752 4442 isc.org. Ojj8YCZf3jYL9eO8w4Tl9HjWKP3CKXQRFed8s9xeh5TR3KI3tQTKsSeI JRQaCXkADiRwHt0j7VaJ3xUHa5LCkzetcVgJNPmhovVa1w87Hz4DU6q9 k9bbshvbYtxOF8xny/FCiR5c6NVeLmvvu4xeOqSwIpoo2zvIEfFP9deR UhA=
isc.org. 484 IN RRSIG AAAA 5 2 7200 20121125230752 20121026230752 4442 isc.org. hutAcro0NBMvKU/m+2lF8sgIYyIVWORTp/utIn8KsF1WOwwM2QMGa5C9 /rH/ZQBQgN46ZMmiEm4LxH6mtaKxMsBGZwgzUEdfsvVtr+fS5NUoA1rF wg92eBbInNdCvT0if8m1Sldx5/hSqKn8EAscKfg5BMQp5YDFsllsTauA 8Y4=
isc.org. 484 IN RRSIG NAPTR 5 2 7200 20121125230752 20121026230752 4442 isc.org. ZD14qEHR7jVXn5uJUn6XR9Lvt5Pa7YTEW94hNAn9Lm3Tlnkg11AeZiOU 3woQ1pg+esCQepKCiBlplPLcag3LHlQ19OdACrHGUzzM+rnHY50Rn/H4 XQTqUWHBF2Cs0CvfqRxLvAl5AY6P2bb/iUQ6hV8Go0OFvmMEkJOnxPPw 5i4=
isc.org. 484 IN RRSIG NSEC 5 2 3600 20121125230752 20121026230752 4442 isc.org. rY1hqZAryM045vv3bMY0wgJhxHJQofkXLeRLk20LaU1mVTyu7uair7jb MwDVCVhxF7gfRdgu8x7LPSvJKUl6sn731Y80CnGwszXBp6tVpgw6oOcr Pi0rsnzC6lIarXLwNBFmLZg2Aza6SSirzOPObnmK6PLQCdmaVAPrVJQs FHY=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 4442 isc.org. i0S2MFqvHB3wOhv2IPozE/IQABM/eDDCV2D7dJ3AuOwi1A3sbYQ29XUd BK82+mxxsET2U6hv64crpbGTNJP3OsMxNOAFA0QYphoMnt0jg3OYg+AC L2j92kx8ZdEhxKiE6pm+cFVBHLLLmXGKLDaVnffLv1GQIl5YrIyy4jiw h0A=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 12892 isc.org. j1kgWw+wFFw01E2z2kXq+biTG1rrnG1XoP17pIOToZHElgpy7F6kEgyj fN6e2C+gvXxOAABQ+qr76o+P+ZUHrLUEI0ewtC3v4HziMEl0Z2/NE0MH qAEdmEemezKn9O1EAOC7gZ4nU5psmuYlqxcCkUDbW0qhLd+u/8+d6L1S nlrD/vEi4R1SLl2bD5VBtaxczOz+2BEQLveUt/UusS1qhYcFjdCYbHqF JGQziTJv9ssbEDHT7COc05gG+A1Av5tNN5ag7QHWa0VE+Ux0nH7JUy0N ch1kVecPbXJVHRF97CEH5wCDEgcFKAyyhaXXh02fqBGfON8R5mIcgO/F DRdXjA==
isc.org. 484 IN RRSIG SPF 5 2 7200 20121125230752 20121026230752 4442 isc.org. IB/bo9HPjr6aZqPRkzf9bXyK8TpBFj3HNQloqhrguMSBfcMfmJqHxKyD ZoLKZkQk9kPeztau6hj2YnyBoTd0zIVJ5fVSqJPuNqxwm2h9HMs140r3 9HmbnkO7Fe+Lu5AD0s6+E9qayi3wOOwunBgUkkFsC8BjiiGrRKcY8GhC kak=
isc.org. 484 IN RRSIG A 5 2 7200 20121125230752 20121026230752 4442 isc.org. ViS+qg95DibkkZ5kbL8vCBpRUqI2/M9UwthPVCXl8ciglLftiMC9WUzq Ul3FBbri5CKD/YNXqyvjxyvmZfkQLDUmffjDB+ZGqBxSpG8j1fDwK6n1 hWbKf7QSe4LuJZyEgXFEkP16CmVyZCTITUh2TNDmRgsoxrvrOqOePWhp 8+E=
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; AUTHORITY SECTION:
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; ADDITIONAL SECTION:
mx.ams1.isc.org. 484 IN A 199.6.1.65
mx.ams1.isc.org. 484 IN AAAA 2001:500:60::65
mx.pao1.isc.org. 484 IN A 149.20.64.53
mx.pao1.isc.org. 484 IN AAAA 2001:4f8:0:2::2b
_sip._udp.isc.org. 4084 IN SRV 0 1 5060 asterisk.isc.org.
;; Query time: 176 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Oct 30 01:14:32 2012
;; MSG SIZE rcvd: 3223
C'est une requête de 64 octets qui a abouti à une réponse de 3 223 octets. En d'autres termes, un attaquant est capable d'obtenir une amplification de 50x sur le trafic qu'il peut initier vers un résolveur DNS ouvert.
Le réseau Anycast de Cloudflare a été spécifiquement conçu pour stopper les attaques massives contre les couches 3 et 4. En utilisant Anycast, nous sommes en mesure d'annoncer les mêmes adresses IP depuis chacun de nos 200 datacenters mondiaux. Le réseau équilibre lui-même la charge des requêtes vers le datacenter le plus proche. Dans des circonstances normales, cela nous permet de veiller à ce que les visiteurs de votre site soient automatiquement redirigés vers le datacenter le plus proche de notre réseau pour garantir les meilleures performances. En cas d'attaque, Anycast permet de disperser et de diluer efficacement le trafic hostile sur l'ensemble de notre réseau de datacenters. Étant donné qu'ils annoncent tous la même adresse IP pour tous les clients Cloudflare, le trafic ne peut être dirigé vers un emplacement unique. De cette façon, l'équilibre est rétabli, et un point isolé du réseau ne pourra pas subir individuellement l'attaque de masse.
Un nouveau type d'attaque cible la couche 7 du modèle OSI, dite couche applicative. Ces attaques visent des caractéristiques spécifiques des applications Web pour créer des goulots d'étranglement. Par exemple, les attaques dites de lecture lente envoient des paquets lentement sur plusieurs connexions. Mais comme Apache ouvre un nouveau thread pour chaque connexion et que les connexions sont maintenues tant que le trafic est envoyé, un attaquant peut saturer un serveur web en épuisant son pool de threads relativement rapidement.
Cloudflare est équipé contre bon nombre de ces attaques, et dans les faits, nous parvenons généralement à réduire le trafic d'attaque HTTP de 90 %. Pour la plupart des attaques, et pour bon nombre de nos clients, c'est suffisant pour maintenir l'activité en ligne. Cependant, les 10% du trafic qui échappent aux protections classiques peuvent toujours être désastreux pour les clients avec des ressources limitées ou dans le cas de très grandes attaques. Dans ce cas, Cloudflare propose un paramètre de sécurité appelé le mode « I'm Under Attack » (IUAM).
IUAM est un niveau de sécurité que vous pouvez définir pour votre site lorsque vous êtes victime d'une attaque. Lorsque IUAM est activé, Cloudflare ajoute une couche de protection supplémentaire pour empêcher le trafic HTTP malveillant d'être transmis à votre serveur. Alors qu'un certain nombre de vérifications supplémentaires sont effectuées en arrière-plan, une page interstitielle est présentée aux visiteurs de votre site pendant 5 secondes pendant que les vérifications sont effectuées. Il s'agit en quelque sorte de tests automatiques ; d'ailleurs, les visiteurs n'ont jamais besoin de répondre à un CAPTCHA.
Après avoir passé la vérification, les visiteurs légitimes peuvent naviguer sur votre site sans entrave. JavaScript et les cookies sont nécessaires pour les tests et pour enregistrer le fait qu'ils ont été réussis. La page qui s'affiche quand IUAM est activé peut être personnalisée pour refléter votre image. Le mode I'm Under Attack ne bloque pas les robots de moteur de recherche ni vos adresses autorisées.
L'une des premières attaques d'amplification était connue sous le nom d'attaque SMURF. Une attaque SMURF consiste à envoyer des requêtes ICMP (par exemple, des requêtes ping) à l'adresse de diffusion d'un réseau (X.X.X.255) annoncé par un routeur configuré pour relayer les requêtes ICMP à tous les périphériques dépendant du routeur. Le pirate falsifie alors la source de la requête ICMP et la remplace par l'adresse IP de la victime. Étant donné que le protocole ICMP n'inclut pas d’établissement de liaison, la destination n'a aucun moyen de vérifier si l'adresse IP source est légitime. Le routeur reçoit la requête et la transmet à tous ses périphériques. Chacun de ces appareils répond ensuite au ping. Le pirate est ainsi capable d'amplifier l'attaque autant de fois qu’il y a d'appareils qui dépendent du routeur (par exemple, s’il y a cinq appareils, l’ attaque est amplifiée cinq fois, voir le diagramme ci-dessous).
Aujourd’hui, les attaques SMURF appartiennent au passé. La plupart des opérateurs réseau ont en effet configuré leurs routeurs pour désactiver le relais des requêtes ICMP envoyées à l'adresse de diffusion d'un réseau.
