Conferência CHAPÉU PRETO. Lições de como sobreviver a um ataque DDOS de 300 Gb / s. Parte 1O interessante desse ataque foi que não ousamos atacar diretamente, mas seguimos a cadeia de nossos fornecedores. Eles começaram a atacar provedores upstream localizados acima do CloudFlare, e a origem do ataque estava de fato em Londres. No começo, eu não tinha certeza disso, mas como Spamhaus também estava em Londres, talvez o hacker quisesse colocá-los em uma posição vergonhosa. Como eu disse, o inspirador técnico do ataque parecia ser um adolescente de Londres, talvez dessa maneira ele pudesse rastrear com mais eficácia o efeito do ataque. Este slide mostra a rota de tráfego BGP, que incluiu no máximo 30 nós de trânsito do próximo salto.
Eu escondi as extensões de endereço do provedor de banda larga de Londres, o último salto é um dos endereços IP da Spamhaus, havia vários em nossa rede. Você vê como o tráfego foi roteado, é difícil determinar o caminho exato a partir dos dados acima, mas ele foi enviado para o nosso equipamento em Londres, onde obteve 17 milissegundos após passar o endereço IP de borda da nossa rede, que funcionava em Londres.
A princípio, o atacante atacou esse endereço marcado com uma flecha e, como o DNS distribuído é usado aqui, ele atingiu ligeiramente Londres, um pouco para Amsterdã e Frankfurt, para os EUA, Ásia e um pouco para a Austrália. Em seguida, o hacker percebeu que o ataque estava disperso e não era eficaz e decidiu subir a cadeia de roteamento por partes adicionais da infraestrutura. Portanto, após o último endereço IP, ele foi para o penúltimo endereço IP. Novamente, se você não souber como o roteamento e as conexões da Internet funcionam, direi que parcialmente o tráfego é trocado diretamente entre as redes quando eu conecto minha rede diretamente a outra rede. Nesse caso específico, o tráfego entra na nossa rede a partir da rede Sky, passando pelo que é conhecido como London Internet Exchange ou LINX.
Os atacantes começaram a passar toneladas de tráfego através do LINX como uma porta. Temos uma porta no LINX com recursos relativamente modestos, portanto, se você enviar 300 gig de tráfego para a porta LINX, sobrecarregará nossa porta e outras portas dessa troca. Portanto, a solução mais razoável para nós foi derrubar a conexão por essa porta, assim que vimos que estava sendo atacada e o tráfego "fluiu" em torno de outras maneiras.
O problema era que houve danos colaterais que afetaram as outras portas LINX, de modo que outros provedores de grandes redes de Internet também tiveram problemas porque diminuímos o tráfego. Isso foi bastante desagradável e, posteriormente, trabalhamos com eles para ajudá-los a proteger suas redes.
O ataque causou violações regionais temporárias, mas tivemos uma boa oportunidade de redirecionar o tráfego para outros nós, a fim de criar a capacidade de permanecer on-line para o Spamhaus e todos os outros clientes. Os invasores também afetaram nossos provedores de transporte de nível superior, enviando um monte de tráfego para as pessoas com quem tínhamos contratos de serviços de rede. Seu objetivo era causar o máximo de inconveniência possível aos nossos clientes, para que partes da infraestrutura de rede que não estavam diretamente relacionadas à nossa rede fossem afetadas.
É possível que os ataques tenham atingido um nível mais alto, no entanto, não tenho dados que confirmem isso, mas eles atacaram os roteadores básicos que operam no núcleo de várias redes. De fato, esse ataque serviu como um protesto gigantesco não apenas para nossa rede, mas também para as redes que nos cercavam, os provedores que usamos e os provedores que esses provedores usavam. Aconteceu que, graças a esse ataque, realizamos uma auditoria de nossas vulnerabilidades. Mais tarde, fomos a várias trocas na Internet, como Londres, e implementamos as melhores soluções em termos de configuração de suas redes, a fim de aumentar a eficácia da oposição a esses ataques. Descobrimos que todo o tráfego interno da organização não deve ser roteado através de roteadores de borda de rede. Portanto, se você não deseja acessar uma dessas trocas na rede de trocas da Internet, seu endereço IP não deve ser roteado por essas trocas. Idealmente, você deve usar 192.168, um dos endereços RFC 1918 não resolvíveis que não podem ser roteados e passar o tráfego por si próprio, ou seja, uma rede que não requer acesso externo para operar. Essa é a melhor coisa que você pode fazer para combater esse ataque.
Há outras coisas que você pode fazer, como roteamento interno do Next Hop, para garantir que o tráfego destinado à transmissão na rede não use pacotes vindos de fora. Você não deve fazer isso apenas para sua própria rede, mas também convencer os fornecedores upstream a fazer o mesmo.
Há outra coisa útil - a filtragem de limites para um endereço IP específico, com base no entendimento da operação de nosso aplicativo. Por exemplo, nosso aplicativo funciona com protocolos diferentes e, se virmos um pacote UDP que não é destinado ao servidor DNS, algo deu errado.
Desde então, segmentamos nossas redes de forma que os endereços IP dos servidores Web sejam diferentes dos endereços IP dos servidores DNS, e podemos solicitar aos nossos fornecedores upstream que simplesmente bloqueiem todo o tráfego UDP que chega a esse endereço IP específico para garantir a segurança do nosso segmento de rede. Essa separação de endereços nos permitiu realizar uma filtragem mais agressiva do tráfego de alto nível.
O filtro BGP Flowspec é nosso verdadeiro amigo, é o protocolo que a Cisco propôs. Apesar de existirem erros, usamos esse protocolo e preferimos que os provedores de trânsito também o utilizem, porque nos permite transferir nossas regras para nós de rede remotos que afetam nossas rotas. Isso permite que você responda rapidamente a esse ataque.
A arquitetura do nLayer de três camadas merece menção especial e quero expressar minha profunda gratidão aos criadores do GTT, que fizeram um trabalho tremendo para tornar sua rede especialmente resistente a ataques. Assim que viram os picos desse ataque, eles rapidamente venceram o tráfego, mesmo nas fronteiras de sua rede. Você já se perguntou como é legal ser um provedor de Camada 1, Camada 3 ou NTT? Todo o seu trabalho é um fim de semana sólido, porque os provedores de primeiro nível não pagam a ninguém por conexões, e isso também significa que eles não podem transferir o trânsito para ninguém. Quando começamos a bloquear o ataque desconectando segmentos de nossa rede, o impacto se concentrou em um pequeno número de provedores de Nível 1 que estavam no centro do ataque, e um "buraco negro" se formou dentro de sua rede, para o qual todo o tráfego corria, porque não havia para onde ir . Portanto, foi um teste difícil para muitos provedores de primeira linha.
Essa é uma das razões pelas quais você viu o Open Resolver Project criado na primeira segunda-feira após o ataque. Os caras do nLayer são realmente uma equipe experiente em tecnologia e nos ajudaram bastante. Eles nos trataram com compreensão, e não apenas disseram: "Saia daqui, você cria muitos problemas para nós". Por isso, desenvolvemos etapas práticas que você pode executar para garantir que suas redes estejam seguras.
Estas são quatro recomendações, a primeira das quais parece boba, mas óbvia: primeiro, verifique se você não faz parte do problema! Eu acho que muitas pessoas lhe disseram isso nos últimos anos. Apenas pare por pelo menos um segundo e verifique se esses dois componentes não estão em execução na sua rede.
O primeiro são os resolvedores abertos. Se eles estiverem no espaço de endereço IP da empresa, se seus clientes os usarem, será necessário bloqueá-los ou limitar a velocidade do tráfego. É ainda melhor configurar os resolvedores para que eles aceitem apenas o tráfego que vem diretamente da sua rede.
Neste slide, você vê meu artigo favorito no The Register, escrito por Trevor Pott. É chamado de "Reconhecendo um profissional de TI: como ajudei o maior ataque DDoS".
Trevor escreve: “Eu pensei que estava fazendo tudo certo. Mas aconteceu que eu tinha um resolvedor aberto e vi nos logs de tráfego como as solicitações atingiam o Spamhouse. ” Eu sei que existem pessoas responsáveis pela operação de redes muito grandes que possuem resolvedores de DNS abertos. Ao fazer isso, você contribui para a criação do problema acima, por isso peço que você gaste literalmente um segundo de tempo e se livre deles.
Segundo, verifique se você está usando o BCP38. Os caras da rede iBall fizeram um ótimo trabalho, mas muitas das pessoas que fornecem as grandes redes acreditam que a rede está fechada se não permitirem acesso externo.
No entanto, suponha que você tenha um servidor WordPress comprometido em sua rede que possa iniciar a falsificação de pacotes de origem que não são destinados à sua rede e isso causará um grande problema para o resto da Internet.
O problema são resolvedores abertos, são 28 milhões de resolvedores, cujo número está aumentando a cada semana. Só podemos derrotar esse problema através de esforços conjuntos. Você deve definir sinalizadores nos roteadores de borda para garantir que eles recebam apenas pacotes de fontes confiáveis dentro da sua rede. Se você fizer isso, negue aos invasores a oportunidade de explorar essa vulnerabilidade. A dificuldade é descobrir grandes máquinas comprometidas que operam em redes e que permitem falsificação.
Se você observar ataques de força bruta no WordPress e houver outros ataques, por exemplo, usando a rede de botnets, será difícil adivinhar que o motivo é precisamente a capacidade de usar a falsificação.
Outra recomendação é usar protocolos realmente confiáveis. Você pode dizer: "Ei, eu obtive esse endereço IP e inicio o serviço usando UDP, e o serviço está usando TCP e outro tráfego via ICMP, e vincularei todos esses protocolos ao mesmo IP". Quero avisar que, se surgir um problema, limite sua capacidade de responder com flexibilidade a esse tipo de ataque, especialmente porque você pode segmentar facilmente a rede para que cada protocolo funcione em seu próprio endereço IP. Melhor se você puder filtrar o tráfego upstream. O objetivo de qualquer um desses ataques não é interromper o tráfego na sua rede, mas bloqueá-lo o mais próximo possível da fonte de tráfego, portanto, dando a alguém a oportunidade de bloquear todo o tráfego UDP direcionado a cada IP, exceto o endereço selecionado, você reduzirá significativamente a superfície de ataque. que pode ser usado por um invasor.
Assim, protocolos separados para IPs individuais funcionam efetivamente ao interagir com provedores upstream. Você acabou de fazer a pergunta: "Ei, você pode implementar esses tipos de filtragem?". A propósito, uma das razões pelas quais nós, como fornecedores, apoiamos a Flowspec é que podemos perguntar-lhes, com razão: "Pessoal, vocês apoiam a Flowspec?". E se eles responderem "Sim", a conversa acabou e podemos implantar nossos próprios filtros na borda da rede o mais rápido que quisermos.
A terceira recomendação é a implementação da infraestrutura da ACL, ou seja, o uso de listas de controle de acesso. Quero dizer, um pacote não pode ser destinado à sua rede interna se sua origem não pertencer a essa rede interna. Se um pacote vier da sua rede ou entrar na rede a partir de um roteador de borda, ele não deverá "viajar" pela infraestrutura da sua rede interna. Existem muitas maneiras de implementar essa disposição. Você pode aplicar a filtragem para impedir que alguns endereços IP atinjam os limites da rede, use o roteamento automático do próximo salto para impedir o acesso a alguns endereços internos, use os protocolos RFC 1918 dentro da rede para garantir que seus IPs internos não sejam usado para endereçar do mundo exterior.
Realmente pode trazer uma dor de cabeça adicional, pois obriga a verificar as configurações do roteador, realmente usar a rede VPN, em vez de fingir usá-lo e assim por diante. Essas não são as soluções mais populares, mas se não forem implementadas, o invasor poderá examinar sua rede e apontar para seus segmentos individuais para causar ainda mais danos.
A quarta recomendação é que você conheça bem seu tráfego upstream. Quero enfatizar mais uma vez que esse ataque não usou aplicativos complexos ou pacotes syn, era apenas um homem das cavernas com um clube pesado. De certa forma, você deve ter mais trânsito do que o bandido. Ele pode gerar 300 Gbps de tráfego, e tenho certeza de que poucos dos presentes podem se orgulhar de redes com esse volume de tráfego. Isso significa que você deve ter um amigo que tenha muito tráfego de saída e, atraindo-o para a cooperação, você se protege contra esse ataque. Somos muito seletivos quanto ao tráfego de saída com o qual trabalhamos para poder perceber um ataque desse tipo a tempo.
Outro dia, conversei com o diretor técnico de um grande fornecedor de transporte público e perguntei se ele iria me vender o transporte público, ao qual ele respondeu - não, pessoal, com isso, você teria apenas uma dor de cabeça extra como cliente.
No entanto, procuramos esse tráfego e até pagamos aos provedores os bônus de trânsito que usamos, porque quando ocorrem ataques desse tipo, queremos poder chamá-los e pedir ajuda para mitigar as conseqüências do ataque. Você não precisa construir redes com uma taxa de transferência de 3-4-5 terabits, se conseguir distribuir o pico de tráfego entre redes parceiras.
Elas não precisam ser empresas com poderosa proteção contra DDoS, elas só precisam usar a arquitetura do nLayer para realmente fazer seu trabalho e ajudá-lo quando surgirem problemas. Trabalhe em estreita colaboração com eles para expandir os limites da sua rede. Use uma política de configuração de rede que permita ingressar na fronteira de suas redes, e os provedores estão dispostos a fazer isso se você tiver provedores de rede competentes. Essa é a história completa sobre o ataque de 300 gigabits. Temos cerca de 10 minutos para responder às suas perguntas.
Peço que você use um microfone se concordar em ficar na fila para fazer uma pergunta. Outra inovação que esqueci de dizer: os organizadores do Blackhat querem receber feedback do orador e, se você "acender" seu crachá do lado de fora, eles transferirão suas informações para a NSA e também receberão feedback. Eu brinquei com a primeira parte, mas a segunda relativa é verdadeira - você pode usar o feedback para me chamar de idiota e geralmente fazer alguma pergunta.
Pergunta: Quais protocolos de amplificação, além do UDP e 53, você encontrou ao executar o CloudFlare?
Resposta: você pergunta, havia outros protocolos de amplificação além dos mencionados? Ainda estamos observando o uso do ICMP na execução do bom e velho ataque Smurf, mas nada é comparável à escala do ataque que lhe falei. Portanto, no próximo ano, insistiremos categoricamente que as pessoas não usem resolvedores abertos, mas que usem um servidor DNS legítimo e autorizado. Use CloudFlare, Bind ou UltraDNS para iniciar suas redes e, se você puder listar todos os domínios pelos quais o servidor autorizado é responsável, encontrar domínios com listas muito grandes de nomes, poderá proteger sua rede, pois esse servidor pode limitar, se necessário velocidade de tráfego. Dedicamos muito tempo à implementação desta solução, e ficarei feliz em contar isso para aqueles que estão realmente interessados.
Pergunta: A botnet não foi usada neste ataque, mas você pode recomendar recursos que possibilitem detectar se as grandes redes que você controla estão usando a botnet para realizar um ataque DDoS?
Resposta: depende de onde você está localizado - por exemplo, você pode procurar essas ferramentas em organizações que monitoram o comportamento da rede de bots e encontrar uma que atenda às suas necessidades. Se você precisar de um projeto de código aberto, recomendo o Honeypot, que apareceu há alguns anos atrás. Com isso, monitoramos efetivamente uma parte significativa das redes globais de botnets, você pode especificar o intervalo de seus endereços IP e ele mostrará se existem redes maliciosas lá. Este é apenas um de muitos desses projetos. Você pode simplesmente procurar padrões de tráfego anormal encontrados em sua rede; portanto, se você vir gigabit de tráfego roteado para um único endereço IP e não houver uma razão razoável para que isso esteja acontecendo em um determinado momento, esse tráfego provavelmente estará chegando não de um servidor web, mas de uma rede de botnet. Isso deve fazer você suspeitar.
Pergunta: O Google possui um dos resolvedores de DNS abertos mais populares. Você não acha que isso pode causar problemas?
Resposta: eles fizeram muito trabalho para limitar o tráfego, e a melhor maneira de verificar isso é usar a mesma solicitação digANY que eu lhe dei como exemplo e substituir o endereço IP da rede PCCW por 888. Qualquer um dos presentes pode enviar essa solicitação apenas um vezes, repita não funcionará. . , – UDP, , , , .
: , BGP Flowspec, , , , , , BGP Flowspec?
: , BGP Flowspec, - Cisco, . , , , . , Flowspec , . , Juniper, Flowspec. , 12 Cisco .
: Flowspec CloudFlare?
: , . , , Flowspec. , . , Flowspec, , . , , upstream-.
: CloudFlare, . , - , . , : «, »?
: , , . , , , , . , DDoS- , , 300 / . , Akamai, . , , «», , . , , .
, , , , . , , , . , , Akamai, Amazon, CloudFlare, Google, , , . , , ?
: , BC38, , DNSSec…
: , DNSSec!
: , , DNSSec, , ?
: . , DNSSec , . ? . , , – DNSSec , . , DNSSec, , , DNS-, .
DNSSec, , , , DNSSec. , Cloudflare, DNS, , . DNS- .
: upstream- ? .
: , , , upstream-. , . CloudFlare , , .
, , , - . , DNS DDoS: , , , .
: , DDoS- , , ?
: , !
, , , , .
Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um
desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 núcleos) 10 GB DDR4 240 GB SSD de 1 Gbps até a mola gratuitamente, ao pagar por um período de seis meses, você pode fazer o pedido
aqui .
Dell R730xd 2 vezes mais barato? Somente nós temos
2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre
Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?