A frequência e força dos ataques de negação de serviço distribuído (DDoS) está em ascensão. Por meio da da exploração de milhões de dispositivos inseguros da Internet-of-Things (IoT), a criação de botnets que causam ataques volumétricos altamente distribuídos está mais fácil e mais impactante do que nunca. Além dos volumes maiores de ataque, os esforços estão mudando das camadas de rede e de transporte para a camada de aplicativo (camada 7). Os ataques de camada de aplicativo são muito mais sofisticados, muitas vezes necessitando de menos recursos para derrubar um site ou aplicativo, e pode interromper as operações com impacto ainda maior.
Os ataques de DDoS interrompem as operações normais de negócios, degradando o desempenho e a disponibilidade do site e do aplicativo, algumas vezes derrubando-os completamente. O custo médio por hora de inatividade devido a uma falha de infraestrutura é de US$ 100.000 por hora. Os ataques dessa natureza provavelmente causam irritação nos clientes, degradação da marca e perda de negócios.
Websites e aplicativos exigem a resiliência e a inteligência de uma rede ajustável para combater os ataques mais novos e maiores. A proteção contra ameaças não deve prejudicar o desempenho causados pelas latências induzidas pelos serviços de segurança e deve ser fácil de configurar para eliminar erros de configuração, que introduzem outras vulnerabilidades.
Defenda-se contra os maiores ataques
A capacidade da rede de Cloudflare é % _NetworkCapacityLargestDDOS_% maior do que o maior ataque de DDoS já registrado. Com 30 Tbps da capacidade, é capaz de lidar com qualquer ataque distribuído atual, inclusive os ataques concentrados na infraestrutura de DNS.
Inteligência de rede compartilhada
Com cada nova propriedade, a rede da Cloudflare se torna mais inteligente. O banco de dados de reputação de IPs da Cloudflare identifica e bloqueia as novas e crescentes ameaças em todas as 7 milhões de propriedades da rede.
Sem comprometimento do desempenho
Eliminar latências induzidas pela segurança por meio da integração com serviços de desempenho incluídos do Cloudflare, inclusive CDN, roteamento inteligente, otimizações de sites e os mais recentes padrões da web.
Perturbando a resolução de DNS, um ataque de inundação de DNS fará um site, uma API, ou um aplicativo Web fora de conformidade ficar totalmente indisponível.
O atacante tira proveito da funcionalidade do DNS aberto ou de servidores NTP para sobrecarregar um servidor ou uma rede alvo com tráfego de solicitação amplificada, onde o tamanho da carga é maior do que o tamanho de uma solicitação de origem.
Os ataques de inundação de HTTP geram grandes volumes de solicitações HTTP, GET ou POST de várias fontes, tendo como alvo a camada de aplicativos, causando degradação ou indisponibilidade do serviço.
A abordagem de segurança em camadas da Cloudflare combina vários recursos de segurança em um único serviço. Ela impede as perturbações causadas pelo tráfego ilegítimo, permitindo a passagem do tráfego legítimo, mantendo websites, aplicativos e APIs com alta disponibilidade e desempenho elevado.
Principais resultados
226.500.000
ataques bloqueados entre agosto de 2015 e novembro de 2016 - 500.000 ataques por dia - e nenhum deles foi bem-sucedido.
95%
total mensal de economia com largura de banda.
US$ 250.000
Leia o estudo de caso
Brad Parscale
Presidente da Giles-Parscale
Diretor Digital da campanha de Trump
Todos os planos da Cloudflare oferecem mitigação limitada e ilimitada de ataques distribuídos de negação de serviço (DDoS), independentemente do tamanho de ataque, sem nenhum custo extra. Nenhum cliente deve ser penalizado por picos de tráfego de rede associadas a ataques distribuídos. A proteção da Cloudflare contra DDoS garante que todas as propriedades de Internet permaneçam online, enquanto os custos com infraestrutura continuam previsíveis.
Os engenheiros da Cloudflare testemunharam o desenrolar de alguns dos maiores ataques da história. Saiba como lidamos com eles em nossoblog de desenvolvedores.
No inverno de 2016, a Cloudflare mitigou seu maior ataque distribuído de camada 3 até então. Não só foi interrompido, como também medido e analisados com precisão. Leia mais
Os ataques distribuídos adotam todos os formatos e tipos. Neste ataque de amplificação de 400 Gbps, o responsável usou 4.529 servidores NTP para ampliar um ataque de um servidor de origem de apenas 87 Mbps.
Leia mais
A Cloudflare combate ataques históricos distribuídos há mais de 7 anos. Em 2013, o ataque de 120 Gbps sobre a Spamhaus foi considerado um ataque de grandes proporções e a Cloudflare manteve seu site online. Leia mais
Impeça que atacantes comprometam dados sigilosos de clientes, como credenciais de usuário, informações de cartões de crédito e outras informações de identificação pessoal.
Impeça que bots abusivos danifiquem propriedades da Internet por meio de de raspagem de conteúdo, pagamentos fraudulentos e invasão de contas.
Os Serviços de Desempenho e Segurança da Cloudflare trabalham em conjunto para reduzir a latência de sites, aplicativos móveis e APIs de ponto a ponto, além de proteger de ataque de DDoS, bots abusivos e violação de dados.
Os Serviços de Desempenho da Cloudflare melhoram as conversões, reduzem as taxas de abandono e aprimoram a experiência dos visitantes, acelerando o desempenho no celular e na web e mantendo os aplicativos disponíveis.
Os Serviços de Segurança da Cloudflare reduzem o risco de perda de clientes, declínio das receitas e degradação das marcas, protegendo contra ataques de DDoS, bots abusivos e violação de dados.
Como a Cloudflare atua como um proxy para todo o seu tráfego de rede, podemos protegê-lo de qualquer tipo de ataque de negação de serviço distribuído, inclusive contra todos os seguintes:
A maioria dos ataques têm como alvo as camadas de transporte e de rede de um sistema de comunicações. Estas camadas são conhecidas como camadas 3 e 4 do modelo OSI. A chamada camada de “transporte” da pilha de rede especifica o protocolo (por exemplo, TCP ou UDP) pelo qual dois hosts em uma rede se comunicam entre si. Os ataques direcionados às camadas 3 e 4 são projetados para inundar uma interface de rede com tráfego do ataque, a fim de dominar seus recursos e negar a possibilidade de responder ao tráfego legítimo. Mais especificamente, os ataques dessa natureza visam saturar a capacidade de um switch de rede, ou sobrecarregar a placa de rede de um servidor ou a capacidade de sua CPU lidar com o tráfego de ataque.
Os ataques das camadas 3 e 4 são difíceis, se não impossíveis, de mitigar com uma solução local. Se um atacante for capaz de enviar mais tráfego do que um link de rede é capaz de aguentar, nenhuma quantidade de recursos de hardware adicionais ajudará a mitigar esse tipo de ataque. Por exemplo, se você tiver um roteador com uma porta de 10 Gbps e um atacante enviar 11 Gbps de tráfego do ataque, nenhuma quantidade de software ou hardware inteligente será capaz de conter o ataque se o link de rede estiver completamente saturado.
Ataques de camada 3 e 4 muito grandes quase sempre se originam de muitas fontes. Cada uma dessas fontes envia tráfego de ataque a um único local na Internet, criando uma onda que supera os recursos do alvo. Neste sentido, o ataque é distribuído. As fontes de tráfego do ataque podem ser um grupo de pessoas trabalhando em conjunto, um botnet de PCs comprometidos, um botnet de servidores comprometidos, servidores de DNS mal configurados ou até mesmo roteadores domésticos de Internet com senhas fracas.
Como um atacante que lança um ataque de camadas 3 e 4 não está interessado em receber respostas às solicitações que envia, os pacotes que compõem o ataque não precisam ser formatados corretamente. Os atacantes falsificam regularmente todas as informações contidas nos pacotes de ataque, inclusive o IP de origem, fazendo com que o ataque pareça ser proveniente de um número praticamente infinito de fontes. Como os dados de pacotes podem ser totalmente aleatórios, até mesmo técnicas como a filtragem de IP de subida tornam-se praticamente inúteis.
Com a Cloudflare, todo o tráfego de ataque que de outra forma teria atingido diretamente sua infraestrutura de servidores é automaticamente encaminhado para a rede Anycast global da Cloudflare de data centers da Cloudflare. Depois que o tráfego de ataque é desviado, podemos utilizar a capacidade global considerável da nossa rede, bem como muitos e muitos racks de infraestrutura de servidores, para absorver as inundações de tráfego de ataque em nossa borda de rede. Isso significa que a Cloudflare é capaz de impedir, até mesmo um único pacote de tráfego de ataque de um ataque tradicional de camadas 3 e 4, de chegar a um site protegido pela Cloudflare.
Os ataques de amplificação de DNS, uma forma de DRDOS, estão em ascensão e se tornaram a maior fonte de ataques às camadas 3 e 4 ataques. A Cloudflare mitiga rotineiramente ataques que excedem os 100 Gpbs e recentemente protegeu um cliente de um ataque que excedeu os 300 Gbps, um ataque que o New York Times considerou o “maior ataque de DDoS anunciado publicamente na história da Internet.”
Em um ataque de reflexão de DNS o atacante envia uma solicitação para um grande arquivo de zona de DNS, com o endereço IP de origem falsificado como o endereço IP da vítima, a um grande número de servidores de DNS abertos. Os servidores, em seguida, respondem à solicitação enviando a resposta de grande porte da zona de DNS ao endereço IP da vítima. As próprias solicitações dos atacantes têm apenas uma fração do tamanho das respostas, permitindo que o invasor amplie muitas vezes seu ataque multiplicando muitas vezes o tamanho dos recursos de banda que eles próprios controlam.
O atacante reúne recursos, como botnets ou recursos DNS não protegidos, e falsifica o endereço IP do alvo. Os recursos então enviam uma enxurrada de respostas para o alvo, tirando-o do ar.
O atacante reúne recursos, como botnets ou recursos DNS não protegidos, e falsifica o endereço IP do alvo. Os recursos então enviam uma enxurrada de respostas para o alvo, mas eles são bloqueados regionalmente por data centers da Cloudflare. O tráfego legítimo continuará acessando a propriedade da Web.
Há dois critérios para um ataque de amplificação: 1) uma consulta pode ser enviada com um endereço de origem falsificado (por exemplo, por meio de um protocolo como ICMP ou UDP que não exige uma negociação); e 2) a resposta à consulta é consideravelmente maior do que a própria consulta. O DNS é uma plataforma de Internet onipresente e central, que atende a esses critérios e, portanto, tornou-se a maior fonte de ataques de amplificação.
As consultas DNS são normalmente transmitidas por meio de UDP, o que significa que, como as consultas ICMP utilizadas em ataques SMURF (descrito abaixo), são praticamente infalíveis. Consequentemente, o atributo de origem de uma consulta de DNS pode ser falsificado e o receptor não tem meios para determinar sua validade antes de responder. O DNS também é capaz de gerar uma resposta muito maior do que a consulta. Por exemplo, é possível enviar a seguinte consulta (minúscula), (onde xxxx é o IP de um servidor de DNS aberto):
dig ANY isc.org @x.x.x.x +edns=0
E retornar a seguinte resposta gigantesca:
; <<>> 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
Trata-se de uma consulta de 64 bytes que resultou em uma resposta de 3.223 bytes. Em outras palavras, o atacante é capaz de conseguir uma ampliação 50 vezes maior do que qualquer tráfego que puderem iniciar em um servidor de DNS aberto.
A rede “Anycast” da Cloudflare foi projetada especificamente para bloquear ataques maciços de camadas 3 e 4. Por meio da utilização do Anycast, conseguimos anunciar os mesmos endereços IP de cada um dos nossos 200 data centers em todo o mundo. A própria rede faz o balanceamento de carga das solicitações para as instalações mais próximas. Em circunstâncias normais, isso nos ajuda a garantir que os visitantes do seu site serão automaticamente encaminhados para o data center mais próximo em nossa rede, para garantir o melhor desempenho. Se houver um ataque, o Anycast atua para dispersar e diluir o tráfego de ataque com eficácia em toda a rede de data centers. Como cada data center anuncia o mesmo endereço IP para qualquer cliente Cloudflare, o tráfego não pode ser direcionado para qualquer local. Em vez de o ataque ser muitos-para-um, torna-se muitos-para-muitos sem nenhum ponto de falha.
Uma nova forma de ataques tem como alvo a camada 7 do modelo OSI, a camada de “aplicativos”. Esses ataques se concentram em características específicas de aplicativos Web que criam gargalos. Por exemplo, o ataque conhecido como "Slow Read Atack", ou ataque de leitura lenta, envia pacotes lentamente por meio de múltiplas conexões. Como o Apache abre um novo thread para cada conexão, e como as conexões são mantidas enquanto houver tráfego sendo enviado, o atacante pode sobrecarregar um servidor Web exaurindo o pool de threads de forma relativamente rápida.
A Cloudflare conta com proteções contra muitos desses ataques, e em experiências reais geralmente reduzimos o tráfego de ataque HTTP em 90%. Para a maioria dos ataques, e para a maioria dos nossos clientes, isso é suficiente para mantê-los online. No entanto, os 10% do tráfego que passam pelas proteções tradicionais ainda podem sobrecarregar os clientes com recursos limitados ou que estiverem enfrentando grandes ataques. Nesse caso, a Cloudflare oferece um ambiente de segurança chamado de modo "I'm Under Attack" (IUAM).
O modo IUAM é um nível de segurança que você pode definir para o seu site se estiver sob ataque. Se o IUAM for ativado, a Cloudflare aplicará uma camada adicional de proteção para impedir que o tráfego HTTP malicioso passe para o seu servidor. Enquanto um número de verificações adicionais estiverem sendo realizadas em segundo plano, será apresentada uma página intermediária aos visitantes do seu site durante cinco segundos, enquanto as verificações estão sendo concluídas. Pense nisso como um desafio onde os testes são automáticos e os visitantes nunca precisam preencher um CAPTCHA.
Depois de confirmada como legítima pelos testes automatizados, os visitantes podem navegar no site sem restrições. JavaScript e cookies são necessários para os testes e para registrar o fato de que os testes foram aprovados corretamente. A página que seus visitantes verão durante o modo IUAM pode ser totalmente personalizada com a sua marca. O modo "I'm Under Attack" não bloqueia rastreadores e indexadores de sistemas de pesquisa nem a lista de permissões atual da Cloudflare.
Um dos primeiras ataques de amplificação ficou conhecido como ataque SMURF. Num ataque SMURF um invasor envia solicitações ICMP (ou sejam, solicitações de ping) ao endereço de transmissão de uma rede (ou seja, X.X.X.255) anunciado a partir de um roteador configurado para retransmitir ICMP para todos os dispositivos localizados por trás do router. O atacante, em seguida, falsifica a origem da solicitação ICMP como o endereço IP da vítima. Como o ICMP não inclui negociação, o destino não tem meios para verificar se IP de origem é legítimo. O roteador recebe a solicitação e envia a todos os dispositivos que se encontrarem atrás. Todos esses dispositivos, em seguida, responderão ao ping. O atacante poderá amplificar o ataque multiplicado pelo número de dispositivos por trás do roteador (ou seja, se houver cinco dispositivos atrás do roteador, o atacante será capaz de amplificar o ataque em cinco vezes. Consulte o diagrama abaixo).
Os ataques SMURF são em grande parte algo do passado. Na maioria dos casos, os operadores de redes já configuraram seus roteadores para desativarem a transmissão de pedidos ICMP enviados ao endereço de transmissão de uma rede.
