Proteção DDoS

Como a Cloudflare serve como proxy para todo o tráfego de rede, podemos proteger você contra qualquer tipo de ataque de negação de serviço distribuído, incluindo todos os seguintes:

Ataques de Camada 3/4

A maioria dos ataques DDoS se dirigem as camadas de transporte e rede de um sistema de comunicações. Estas camadas são representadas como camadas 3 e 4 do modelo OSI. A camada chamada 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 dirigidos às camadas 3 e 4 são projetados para inundar uma interface de rede com tráfego de ataque, a fim de esgotar seus recursos e negar a capacidade de responder ao tráfego legítimo. Mais especificamente, ataques dessa natureza visam saturar a capacidade de um switch de rede, sobrecarregar a placa de rede de um servidor ou a capacidade da CPU de lidar com o tráfego de ataque.

Os ataques de camada 3 e 4 são difíceis, senão impossíveis, de mitigar com uma solução baseada em hardware (on-premise). Se um invasor pode enviar mais tráfego do que um link de rede pode suportar, nenhuma quantidade de recursos de hardware adicionais ajudará a mitigar esse ataque. Por exemplo, se você tem um roteador com uma porta de 10Gbps e um invasor envia 11Gbps de tráfego de ataque, nenhuma quantidade de software ou hardware inteligente permitirá que você pare o ataque se o link de rede estiver completamente saturado.

Ataques de camada 3/4 muito grandes quase sempre se originam de várias de fontes. Essas muitas fontes enviam tráfego de ataque para um único local da Internet, criando uma avalanche que supera os recursos de um alvo. Nesse sentido, o ataque é distribuído. As fontes de tráfego de ataque podem ser um grupo de indivíduos trabalhando juntos, uma rede botnet de PCs comprometidos, uma rede botnet de servidores comprometidos, endereços de DNS mal configurados ou até mesmo roteadores de Internet domésticos com senhas fracas.

Como um invasor que inicia um ataque de camada 3/4 não se preocupa em receber uma resposta às requisições que eles enviam, os pacotes que compõem o ataque não precisam ser precisos ou formatados corretamente. Os invasores regularmente falsificam todas as informações nos pacotes de ataque, incluindo o IP de origem, fazendo parecer que o ataque é proveniente de um número praticamente infinito de fontes. Como os dados de pacotes podem ser totalmente aleatórios, mesmo técnicas como a filtragem de IP tornam-se praticamente inúteis.

Com a Cloudflare, todo o tráfego de ataque que de outra forma atingiria diretamente a infra-estrutura do seu servidor, será roteado automaticamente para a rede de data centers Anycast global da Cloudflare. Uma vez que o tráfego de ataque é deslocado, somos capazes de aproveitar a significativa capacidade global da nossa rede, bem como a grande quantidade de racks de servidores, para absorver as inundações de tráfego de ataque em nossa borda da rede. Isso significa que a Cloudflare é capaz de impedir que até mesmo um único pacote de tráfego de ataque de um ataque tradicional de camada 3/4, alcance um site protegido pela Cloudflare.

Ataques de Amplificação de DNS

Os ataques de amplificação de DNS, uma forma de DRDoS, estão em ascensão e se tornaram a maior fonte de ataques DDoS de camada 3/4. A Cloudflare mitiga rotineiramente ataques que excedem 100Gpbs e recentemente protegeu um cliente de um ataque que ultrapassou 300Gbps, um ataque que o New York Times considerou o "maior ataque DDoS anunciado publicamente na história da Internet".

Em um ataque de reflexão de DNS, o invasor envia um pedido para uma zona grande de DNS, com o endereço IP de origem falsificado como o endereço IP da vítima pretendida para um grande número de resolvedores de DNS abertos. Os resolvedores então respondem ao pedido, enviando a resposta da zona grande de DNS para o endereço IP da vítima pretendida. Os próprios pedidos dos invasores são apenas uma fração do tamanho das respostas, permitindo ao invasor amplificar seu ataque à muitas vezes o tamanho dos recursos de largura de banda que eles próprios controlam.

Ataque de Reflexão de DNS sem a Cloudflare

Um invasor reúne recursos, como botnets ou DNS recursivos abertos, e imita o endereço IP do alvo. Os recursos enviam então uma inundação das respostas ao alvo, fazendo com que fique offline.

Ataque de Reflexão de DNS com a Cloudflare

Um invasor reúne recursos, como botnets ou DNS recursivos abertos, e imita o endereço IP do alvo. Os recursos enviam então uma inundação das respostas ao alvo, mas são obstruídos regionalmente por pontos de presença da Cloudflare. O tráfego legítimo ainda pode acessar a propriedade da web.

Existem dois critérios para um ataque de amplificação: 1.) uma consulta pode ser enviada com um endereço de origem falsificado (por exemplo, através de um protocolo como ICMP ou UDP que não requer um handshake); E 2.) a resposta à consulta é significativamente maior que a própria consulta. O DNS é uma plataforma de Internet central e ubíqua que atende a esses critérios e, portanto, tornou-se a maior fonte de ataques de amplificação.

As consultas DNS normalmente são transmitidas por UDP, o que significa que, como as consultas ICMP usadas em um ataque SMURF (descrito abaixo), elas são enviadas sem confirmação. Como resultado, o atributo de origem de uma consulta de DNS pode ser falsificado e o receptor não tem nenhuma maneira de determinar a sua veracidade antes de responder. DNS também é capaz de gerar uma resposta muito maior do que consulta. Por exemplo, você pode enviar a seguinte (minúscula) consulta (onde x.x.x.x é o IP de um resolvedor DNS aberto):

dig ANY isc.org @x.x.x.x +edns=0

E receber 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

Essa é uma consulta de 64 bytes que resultou em uma resposta de 3.223 bytes. Em outras palavras, um invasor é capaz de obter uma amplificação de 50 vezes sobre qualquer tráfego que pode iniciar a um resolvedor de DNS aberto.

A rede "Anycast" da Cloudflare foi especificamente projetada para parar ataques maciços de camada 3/4. Ao usar o Anycast, podemos anunciar os mesmos endereços IP de cada um dos nossos 102 centros de dados em todo o mundo. A própria rede faz o balanceamento de carga para o ponto de presença mais próximo. Em circunstâncias normais, isso nos ajuda a garantir que os visitantes do seu site sejam roteados automaticamente para o data center mais próximo de nossa rede para garantir o melhor desempenho. Quando existe um ataque, o Anycast serve para dispersar e diluir eficazmente o tráfego de ataque em toda a nossa rede de data centers. Como cada data center anuncia o mesmo endereço IP para qualquer cliente da Cloudflare, o tráfego não pode ser direcionado para um único local. Em vez do ataque ser muitos-para-um, torna-se muitos-para-muitos sem um único ponto na rede e sem um único ponto de falha.

Ataques SMURF

Um dos primeiros ataques de amplificação ficou conhecido como ataque SMURF. Em um ataque SMURF, um invasor envia requisição ICMP (isto é, requisição de ping) para o endereço de broadcast de uma rede (isto é, X.X.X.255) anunciado a partir de um roteador configurado para retransmitir ICMP para todos os dispositivos atrás do roteador. O invasor então falsifica a origem da requisição ICMP como sendo o endereço IP da vítima pretendida. Como o ICMP não inclui um handshake, o destino não tem meios de verificar se o IP de origem é legítimo. O roteador recebe o pedido e passa para todos os dispositivos que se sentam atrás dele. Cada um desses dispositivos responde então ao ping. O atacante é capaz de amplificar o ataque por um múltiplo igual ao número de dispositivos por trás do roteador (isto é, se você tem 5 dispositivos por trás do roteador, em seguida, o invasor é capaz de amplificar o ataque 5 vezes, consulte o diagrama abaixo).

Ataques SMURF são em grande parte algo do passado. Em maior parte, os operadores de rede têm configurado seus roteadores para desativar o relay de requisições ICMP enviadas para o endereço de broadcast de uma rede.

Ataques ACK

Para entender um ataque ACK, é preciso mergulhar no mundo do TCP. Quando uma conexão TCP é estabelecida há um handshake. O servidor que inicia a sessão TCP primeiro envia uma requisição SYN (para sincronização) ao servidor de recebimento. O servidor de recepção responde com um ACK (para confirmação). Após esse aperto de mão (handshake), os dados podem ser trocados.

Assim como os ataques de reflexão DNS, os ataques ACK disfarçam a origem do ataque, fazendo com que pareça vir de servidores legítimos. No entanto, ao contrário de um ataque de reflexão de DNS, não há fator de amplificação: a largura de banda dos ACKs é simétrica à largura de banda que o atacante tem para gerar os SYNs. A rede Cloudflare é configurada para eliminar os ACKs sem respostas, o que mitiga esses tipos de ataques.

Ataques de camada 7

Uma nova geração de ataques têm como alvo a camada 7 do modelo OSI, a camada de "aplicação". Esses ataques focam em características específicas de aplicações Web que criam gargalos. Por exemplo, o chamado ataque Slow Read envia pacotes lentamente através de várias conexões. Devido ao fato de o Apache abrir uma nova thread para cada conexão, e de que as conexões são mantidas enquanto houver tráfego sendo enviado, um invasor pode sobrecarregar um servidor web esgotando seu pool de threads relativamente rápido.

A Cloudflare tem proteções habilitadas contra muitos desses ataques, e em experiências do mundo real, geralmente reduz o tráfego de ataque HTTP em 90%. Para a maioria dos ataques, e para a maioria de nossos clientes, isso é suficiente para mantê-los online. No entanto, os 10% do tráfego que se recebe através de proteções tradicionais ainda pode ser esmagadora para clientes com recursos limitados ou em face a ataques muito grandes. Nesse caso, a Cloudflare oferece uma configuração de segurança chamada "I'm Under Attack" (IUAM).

IUAM é um nível de segurança que você pode definir para o seu site quando você está sofrendo um ataque. Quando o IUAM estiver ativado, a Cloudflare adicionará uma camada adicional de proteções para impedir que o tráfego HTTP malicioso seja transmitido ao servidor. Enquanto uma série de verificações adicionais são realizadas em segundo plano, uma página intersticial é apresentada aos visitantes do seu site durante 5 segundos enquanto as verificações são concluídas. Pense nisso como um desafio onde os testes são automáticos e os visitantes nunca precisam preencher um CAPTCHA.

Depois de verificado como legítimo pelos testes automatizados, os visitantes são capazes de navegar no seu site sem problemas. JavaScript e cookies são necessários para os testes e para registrar o fato de que os testes foram corretamente aprovados. A página que seus visitantes vêem quando estão em IUAM pode ser totalmente personalizada para refletir sua marca. O modo Estou Sofrendo um Ataque ("I'm Under Attack") não bloqueia os rastreadores do mecanismo de pesquisa ou sua lista branca (whitelist) existente na Cloudflare.