Conferência DEFCON 19. Três gerações de ataques de negação de serviço (envolvendo o público como vítimas). Parte 1Pior ainda ... Tentei desenvolver um projeto para meus alunos, e o resultado foi engraçado, mas o problema era que era impossível ver os endereços "mortos", pois era isso que você precisava para ver a configuração de IP. Mas se eu realizar o ataque muito rápido, o sistema responderá imediatamente e ninguém verá o que aconteceu com ele.
Eu fiz isso para que você pudesse ver toda a rede, todos os endereços dessa rede página por página. Essa lista pode ser ainda maior, pois foram adicionados 5 endereços IP por segundo. Quando iniciei esse projeto pela primeira vez, pareceu-me que nada estava acontecendo, pois minha máquina Windows parecia não reagir absolutamente ao que havia acontecido.
Os alunos não se interessariam, porque não aprenderão nada se não conseguirem ver os danos causados pelo ataque. Eu pensei “ok, este é um projeto ruim, o que devo fazer?”, Mas então me dei conta - isso mata um controlador de domínio, um servidor de email e tudo mais, é muito ruim. Isso é tão ruim que eu não posso contar aos meus alunos sobre isso, é melhor eu contar à Microsoft sobre isso em silêncio!
Então, enviei um tweet de que o Windows 7 contém uma vulnerabilidade perigosa, que, no entanto, não é de todo surpreendente. Eu disse que, em conexão com isso, preciso de contatos do serviço de segurança do Windows, e as pessoas no Twitter me ajudaram a encontrar as pessoas certas na Microsoft. Após 2 dias, recebi uma resposta oficial da Microsoft, na qual foi relatado que Mark Hughes lhes contou isso há um ano. Mas isso não importa, porque eles não pretendem fazer correções nas versões atuais do Windows, porque Vista, Windows 7, Windows Server 2003, Windows Server 2008, Windows XP estão morrendo gradualmente e deixam de apoiá-los. Em vez disso, eles corrigem essa vulnerabilidade no Windows 8 ou Windows 9 se ainda não tiverem alguma coisa.
Eu pensei - tudo bem, se você vai agir dessa maneira, vou contar ao mundo inteiro e deixar meus alunos testarem esse projeto como lição de casa, avisando-os para usá-lo em uma rede isolada, porque, caso contrário, você pode matar todos os computadores da faculdade , incluindo nossos servidores. Eles fizeram exatamente isso, então eu ainda ensino lá, em vez de ficar na rua com uma caneca de esmola.
De qualquer forma, este é um ataque muito poderoso, e eu gostaria de falar um pouco sobre como você pode se defender. Mas antes de começar, entregarei esse assunto a Matthew, e a única coisa que quero é que você teste agora o impacto desse ataque em si mesmo.
Todas as máquinas e computadores Windows com uma das versões do Free BSD Unix são suscetíveis ao ataque do RA Flood, mas as máquinas com MAC OS e Open BSD são invulneráveis. Se você observar a configuração do meu MacBook, verá que ele também é um host e ingressou em algumas das redes existentes aqui. Veja aqui a rede inet6 com um endereço a partir de 2001.
Ele se conectou a algumas dessas redes inúteis, mas não a todas as redes. Eu acho que poderia ser redes DefCon. Mas, de qualquer forma, você vê que o meu “MacBook” está conectado há algum tempo às 10 primeiras redes encontradas e não presta mais atenção ao RA. Essa é uma defesa muito boa, e acho que a Microsoft deveria ter vindo do Windows também, mas eles não estão interessados na minha opinião. A Cisco lançou um patch projetado para proteger seus equipamentos contra ataques desse tipo, e a Juniper ainda não o fez.
Portanto, se você tem dispositivos para teste, Ryan vai configurar sua rede isolada e matar alguém lá. Se você quiser participar disso, poderá ingressar na rede SSID denominada “Não use”, que usa criptografia WPA2, portanto, é necessário digitar a senha “Não usar”. Se você entrar nesta rede, Ryan verá quantas pessoas estão na rede e o matará. Essa matança é bastante interessante, pois ajuda a descobrir quais outros dispositivos são vulneráveis, exceto o Windows e o Free BSD.
Algumas pessoas disseram que iriam trazer dispositivos interessantes para cá, e eu gostaria de saber sobre isso, então, depois da demonstração, vou pedir para você ir à sala de perguntas e respostas e conversar sobre o assunto. Em seguida, poderíamos informar o fabricante para incentivá-lo a lançar um patch para a vulnerabilidade revelada de seu dispositivo. Eu acho que muitas pessoas são vulneráveis a ataques desse tipo, mas não sabem disso.
Agora vou passar a palavra a Matthew para contar a história do LulzSec, e depois continuarei a conversa sobre a defesa, se tivermos tempo. Por enquanto, fecharei todas as janelas para limpar a área de trabalho. Sinto muito, o nome da rede é "Não conectar" e a senha também é "Não conectar"!
Matthew Prince: Sam é a única pessoa que conheço que pode realizar um ataque DDoS com tanto charme. Meu nome é Matthew Prince, eu sei Sam, nós dois moramos em San Francisco e ambos estão envolvidos na história do LulzSec.
Portanto, contarei uma história sobre como eles me arrastaram para isso, sobre alguns ataques DDoS que observamos por 23 dias e sobre o que fizemos para detê-los.
Em 2 de junho de 2011, por volta das 16h54 (horário de Brasília), o LulzSec anunciou em sua conta do Twitter que havia criado a página Lulz Security em
lulzsecurity.com . O que foi surpreendente foi que esta página ficou offline por 15 minutos devido a um poderoso ataque DDoS. Não conheço os detalhes desse ataque em particular, porque ainda não estávamos envolvidos nisso.
Cerca de uma hora após a publicação da postagem na criação da página, o LulzSec twittou que eles eram capazes de resolver o problema de negação de serviço. A única coisa que mudou durante esse período, como fui informado mais tarde, é que eles se inscreveram no serviço CloudFlare 9 minutos antes desta mensagem. Tornamos os sites mais rápidos e os protegemos de alguns tipos de ataques, mas não nos consideramos um serviço para impedir ataques DDoS; portanto, alguns de nós foram surpreendidos por esse ato do LulzSec.
Outra grande surpresa foi quando, uma hora depois, os hackers publicaram uma mensagem endereçada a mim, na qual confessavam seu amor pelo CloudFlare e perguntavam se podiam contar com uma conta premium gratuita em troca de rum.
Eu não tinha idéia de quem eram os LulzSec naquela época, então escrevi uma mensagem no Twitter, que meu advogado disse para excluir: "Depende de quão bom seja o rum". Devo dizer imediatamente que eles nunca nos enviaram rum e nunca lhes fornecemos uma conta profissional. Mas o CloudFlare é um serviço gratuito, todos os dias temos milhares de sites registrados e, geralmente, não temos problemas com eles.
Então, nos próximos 23 dias, esses caras causaram estragos de várias maneiras. Finalmente, em 25 de junho, eles postaram um tweet que marcou o fim do ataque.
Era interessante que o CloudFlare funcionasse como um proxy reverso, portanto todo o tráfego que foi para o Lulz Security passou pela nossa rede, o que tem dois efeitos significativos. O primeiro - quem atacou o Lulz Security nos atacou, o segundo - graças a nós, o Lulz Security pôde ocultar a localização da fonte do ataque, ou seja, o local onde a hospedagem estava realmente localizada. Esses são efeitos colaterais da arquitetura de nosso sistema, mas os hackers os usaram em seu benefício.
Sam entrou em contato comigo há um tempo atrás e disse que iria falar sobre DDoS. Conversamos sobre a nossa experiência e ele perguntou se eu poderia compartilhar algumas informações sobre isso. Temos um consultor jurídico, somos uma empresa real com nossa própria política de privacidade e, mesmo que você esteja na lista internacional de procurados por crimes cibernéticos, tentamos respeitar sua privacidade. Portanto, escrevi uma carta para o LulzSec e a enviei para o endereço de e-mail indicado por eles na minha conta.
Eu disse a eles que fui convidado para a DefCon como palestrante, então falei sobre os ataques ao CloudFlare relacionados às atividades de sua comunidade. Escrevi que algumas das informações que desejo comunicar durante a minha apresentação estão protegidas por nossa política de privacidade, por isso peço à LulzSec consentimento para sua divulgação. Após 11 dias, alguém chamado Jack Sparrow me respondeu com o texto: "Você tem meu consentimento".
E aqui estou eu, para falar sobre algumas coisas sobre as quais eu não poderia falar sem essa permissão. Posso falar sobre como eles nos influenciaram, mas não divulgarei a você os hosts que eles costumavam atacar ou os endereços IP reais.
Deixe-me contar um pouco mais sobre o que aconteceu nesses 23 dias e mostrar uma análise do tráfego real no site da Lulz Security durante esse período.
Durante esse período, mais de 18 milhões de visualizações de página foram feitas quando as pessoas visitaram este site. Você pode ver que quase desde o início do ataque, de 22 de junho a 5 de julho, foi observado um pico de tráfego normal e, em seguida, o site parou de funcionar, embora ainda usasse o CloudFlare. Se você tentar visitar este site hoje, verá apenas a página de configuração do Apache e não sei o que eles planejam fazer a seguir.
É interessante observar o tráfego do ataque que derrubou o site.
Eu diria que todo o tráfego para o pico no meio é apenas um ruído de fundo normal, no qual não havia nada de especial e que não pressagiava nada do que mostrarei no slide em alguns segundos. De fato, as três semanas durante as quais o LulzSec usou o serviço CloudFlare foram bastante calmas em relação aos ataques de negação de serviço. Isso é estranho, porque muitas pessoas disseram que atacaram o LulzSec naquele momento.
O pico no meio do gráfico foi causado por alguns eventos muito óbvios, que discutirei mais adiante. Também falaremos sobre os tipos de ataques que foram usados contra o LulzSec e o que fizemos para nos proteger.
Um evento particularmente interessante ocorreu em 25 de junho. Foi associado ao Jester. Eu não sabia quem ele era, então Sam me forneceu algum material sobre ele.
Parece que Jester passou muito tempo tentando descobrir a localização do site da LulzSec e orgulhosamente publicou em sua página os endereços IP de seus recursos:
www.lulzsecurity.com : 204.197.240.133 e lulzsecurity.com: 111.90.139.55.
Sei o host do site LulzSec em 25 de junho e posso dizer que esses endereços não têm nada a ver com isso. Durante esses 23 dias, eles usaram 7 hosts diferentes, inicialmente o host estava localizado em Montreal, Canadá. Por algum tempo, no início de junho, a hospedagem malaia foi usada com um endereço IP 111.90.139.55. A maioria dos hosts que eles usam estavam localizados nos Estados Unidos, incluindo um grande host especializado em mitigar os efeitos dos ataques DoS e, no final, eles mudaram para o host alemão, onde o site está localizado hoje.
Curiosamente, muitas pessoas afirmaram que foram elas que derrubaram o site da LulzSec e postaram fotos relevantes na Internet. De fato, isso simplesmente demonstra o serviço que oferecemos no CloudFlare - se o servidor back-end estiver desconectado, mostraremos sua versão em cache, conforme evidenciado pela barra laranja na parte superior da página. Diz ao usuário que ele está navegando no cache, assim como acontece com o cache da página no Google.
Eu acho que quando as pessoas alegaram que haviam derrubado o site do LulzSec, o que realmente aconteceu foi que os caras do LulzSec foram simplesmente expulsos de seus anfitriões. Portanto, por um curto período de 36 horas, eles realmente indicaram o endereço IP 2.2.2.2 inválido como endereço, porque não há host ou servidor da web ativo nesse endereço. Eu acho que eles apenas escolheram um endereço IP aleatório para que nosso sistema simplesmente os "pressionasse" constantemente on-line, porque a versão do cache existe por um período limitado de tempo até expirar. Nesse momento, eles retornaram brevemente ao host e indicaram um endereço falso apenas para aparecer em nosso cache.
Não conheço uma única pessoa que indique que o site LulzSec funcionou offline por pelo menos um curto período de tempo, apesar de muitas pessoas terem tentado eliminá-lo do modo online. De fato, ao mesmo tempo, foi o LulzSec que derrubou sites de outras pessoas, por exemplo, o site da CIA, e foi interessante observar esses ataques. O slide lista exatamente quais ataques observamos.
Ficamos muito surpresos e literalmente "colocamos todos em alerta" durante o ataque DDoS, que tentou derrubar o site por três semanas, pois geralmente observávamos ataques que duravam um período de tempo significativamente menor. Não é tão perigoso provocar os hackers que atacam o Twitter como a máfia cibernética da China ou do Leste Europeu ou pessoas envolvidas em extorsão da Internet, porque são eles que são capazes de um poderoso ataque DDoS. Sim, esses caras também são inteligentes o suficiente, mas ainda assim, esses ataques não estão no nível deles.
Observamos vários ataques relativamente inofensivos no nível OSI 7, usando ferramentas como o Slowloris. Mas o servidor web interno do CloudFlare foi especialmente projetado para não apenas "matar" ataques até o 7º nível, mas também para corrigir todos os endereços IP dos quais esses ataques foram feitos. Na verdade, só ficamos felizes quando os hackers atacam nosso sétimo nível, porque os ataques DDoS nos níveis 3 ou 4 nos causam muito mais problemas.
Nesse caso, atenuamos suas consequências, pois usamos a rede Anycast. Isso significa que temos um monte de máquinas, centenas e centenas de computadores trabalhando em 14 data centers diferentes em todo o mundo e vinculados ao mesmo endereço IP.
Isso permite que você "pulverize" um DoS distribuído - ataque ou ataque com uma grande quantidade de tráfego para uma grande superfície de rede, o que dificulta muito o uso desses ataques contra nós.
Muito mais problemas nos trouxeram ataques de um tipo diferente. O primeiro foi produzido usando algo como uma rede muito grande com uma enorme quantidade de tráfego que os atacantes enviaram diretamente para nós. Essa rede estava localizada geograficamente perto de nosso data center em San Jose e eles usavam quase toda a sua largura de banda. Tivemos que transferir nossos clientes para outros data centers menos ocupados, para que isso não os afetasse. Mas o data center em San Jose naquela época só podia atender à Lulz Security, continuando a mantê-los online.
Um ataque ainda mais interessante, que ameaçou a maioria das pessoas conectadas conosco, usou o Google como um "refletor" de tráfego. Aderimos a regras específicas relacionadas aos endereços IP do Google para garantir que nunca bloqueemos o tráfego legítimo que chega até nós a partir daí. Alguém realmente inteligente descobriu que, se você enviar muitas solicitações SYN para o Google com cabeçalhos falsos apontando para o nosso endereço IP, o Google as devolverá de volta para nós. A solução para esse problema foi bastante simples e levou apenas alguns minutos - bloqueamos os ACKs aos quais os SYNs não estavam conectados e, em seguida, ligamos para nossos amigos no Google e dissemos que eles nunca receberiam tráfego dessas fontes; portanto, use um firewall contra eles. . Foi um ataque realmente inteligente que levou em conta a natureza de nossa infraestrutura e aproveitou os recursos de seu trabalho.
O último ataque, que nos causou muitos problemas, foi baseado no fato de que alguém examinou cuidadosamente os intervalos de nossos endereços IP e descobriu as interfaces do roteador que estavam sujeitas a influências externas. Usando isso, um invasor lançou um ataque do tipo dicionário e desativou vários de nossos roteadores, tendo conseguido contornar o Anycast.
A solução para o problema novamente se mostrou bastante simples - bloqueamos esses endereços IP que estão fora da nossa rede, mas o ataque nos causou danos, porque por alguns minutos nossos roteadores foram desativados offline.
Sabe, quando comparei os maiores ataques que testemunhamos, até assisti quando nosso cliente recebeu um e-mail com o texto: “Olá, somos uma agência governamental chinesa que descobriu que alguém na rede vai atacar você "e se você nos enviar US $ 10.000, provavelmente conseguiremos resolver esse problema". Obviamente, isso não é uma agência, mas eles realmente são capazes de resolver esse problema, porque eles mesmos o criam. No entanto, houve relativamente poucos desses ataques.
Vou falar sobre algumas coisas mais interessantes. O aumento no tráfego normal de segundo plano coincide com o depoimento da LulzSec de que eles travaram os servidores do Minecraft. Após o término do ataque, o tráfego diminuiu ligeiramente.
Os funcionários de nosso escritório, que são fãs do Minecraft, iniciaram um grande debate sobre se o LulzSec não deveria deixar nossa rede depois disso, porque eles mesmos causaram muitos danos e, em geral, isso não é nada legal. Assim, você pode aprender uma lição de que, se for organizar um ataque DDoS contra alguém, é melhor não tocar no Minecraft.
Tenho muito pouca informação sobre quem realmente é esse pessoal da Lulz Security. Para nós, é apenas um dos nomes de usuário que cria contas no Cloudflare. É muito parecido com o nome da pessoa que foi presa e não sei se isso é apenas uma coincidência ou se essas pessoas realmente derrubaram esses sites. Não notamos tanta atividade por trás deles para mover seus hosts, além disso, seu site está desativado.
No entanto, foi interessante observar como o mundo inteiro tentou “matá-los” por 23 dias e, mesmo assim, nós os ajudamos a permanecer à tona. Obrigado por me convidar aqui!
Sam Bone: Obrigado, Matthew, por ter decidido vir. Agora voltarei à minha apresentação. Ouvi muita conversa sobre como atacar é mais fácil do que defender, então mostrarei um ataque que vai acabar com ele. , , Microsoft , . . , RA Flood.
, IPv6, , , . Router Discovery , , IPv6, , , .
RA Windows, . , . Cisco RA Guard, Windows, . , Cisco . RA Guard , RA-, .
, : , . — , — , .
, , . , Mod Security, , DDoS 7- . , — IP- , , Tor , .
, Akamai, , . Load Balancer, , , . , , 4 , .
. , - HT More , DNS- C&C , . , . Flood- , Anonymous Low Orbit Ion Canon.
CloudFlare, , — , , , , . , , , . , CloudFlare, .
, . , , , . , – , , . , , .
, , ? - ? - ? ? , , . , . , !
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).
Dell R730xd 2 vezes mais barato? Somente temos
2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre
Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?