[Análise Técnica] Aprofundado e fácil de entender: Introdução ao ataque de ataque em rede e defesa

Os ataques DDoS (Distributed Denial of Service) são um dos ataques mais poderosos e difíceis de defender, pois o principal objetivo dos ataques DDoS é impedir que um alvo designado forneça serviços normais ou até mesmo desapareça da Internet.

Os DDoS podem ser simplesmente divididos em três categorias de acordo com a forma como são iniciados.

A primeira categoria vence por forçaPacotes de dados massivos invadem todos os cantos da Internet, bloqueando a entrada do IDC, tornando vários sistemas poderosos de defesa por hardware e processos de emergência rápidos e eficientes inúteis. Exemplos típicos desse tipo de ataque são ICMP Flood e UDP Flood, que hoje são incomuns.

A segunda categoria vence por inteligência, inteligente e imperceptível, enviar um pacote a cada poucos minutos ou mesmo precisar apenas de um pacote pode fazer com que o luxuoso servidor de configuração não responda mais. Esse tipo de ataque é principalmente lançado explorando vulnerabilidades em protocolos ou softwares, como ataques Slowloris, ataques de colisão de hash, etc., e requer coincidências ambientais específicas.

A terceira categoria é uma mistura das duas acimaEle não apenas aproveita os defeitos do protocolo e do sistema, mas também possui uma grande quantidade de tráfego, como o ataque SYN Flood e o ataque DNS Query Flood, que é o método de ataque atual mais comum.

Este artigo descreverá esses métodos de ataque mais comuns e representativos um a um e apresentará suas opções de defesa.

O SYN Flood é um dos ataques DDoS mais clássicos na Internet, surgindo por volta de 1999, sendo o Yahoo a vítima mais famosa da época. Ataques SYN Flood exploram falhas de tripla handshake TCP que podem tornar o servidor alvo pouco responsivo e difícil de rastrear a um custo baixo.

O processo padrão de aperto de mão TCP em três partes é o seguinte:

• O cliente envia um pacote TCP contendo a flag SYN, o SYN é sincronizado, e o pacote de sincronização indica a porta usada pelo cliente e o número de série inicial da conexão TCP.
• Após receber o pacote SYN do cliente, o servidor retornará um pacote SYN+ACK (ou seja, confirmação de confirmação), indicando que a solicitação do cliente foi aceita, e o número de série inicial do TCP é automaticamente adicionado por 1.
• O cliente também retorna uma mensagem de confirmação ACK para o servidor, e o número de série TCP também é adicionado por 1.
  

Após essas três etapas, a conexão TCP é estabelecida. Para alcançar uma transmissão confiável, o protocolo TCP estabeleceu alguns mecanismos de tratamento de exceções durante os três handshakes. Na terceira etapa, se o servidor não receber o pacote final de confirmação ACK do cliente, o servidor permanecerá no estado SYN_RECV, adicionará o endereço IP do cliente à lista de espera e reenviará o pacote SYN+ACK na segunda etapa. Reposts geralmente são realizados de 3 a 5 vezes, e a lista de espera é consultada uma vez em intervalos de cerca de 30 segundos para tentar novamente todos os clientes. Por outro lado, após o servidor enviar o pacote SYN+ACK, ele pré-aloca recursos para armazenar informações para a próxima conexão TCP, que são mantidas enquanto aguardam a nova tentativa. Mais importante ainda, se os recursos do servidor forem limitados, o estado SYN_RECV que pode ser mantido não aceitará mais novos pacotes SYN após ultrapassar o limite, ou seja, novas conexões TCP serão rejeitadas.

O SYN Flood utiliza as configurações do protocolo TCP acima para alcançar o propósito do ataque. Atacantes disfarçam um grande número de endereços IP para enviar pacotes SYN ao servidor e, como os endereços IP falsificados são quase impossíveis de existir, quase nenhum dispositivo retornará qualquer resposta ao servidor. Como resultado, o servidor mantém uma enorme lista de espera e continua tentando novamente enviar pacotes SYN+ACK, o que consome muitos recursos e não pode ser liberado. Mais importante ainda, a fila SYN_RECV do servidor atacado está cheia de pacotes maliciosos, novas requisições SYN não são mais aceitas, e usuários legítimos não conseguem completar três handshakes para estabelecer conexões TCP. Em outras palavras, o servidor foi negado pelo SYN Flood.

Se você se interessa por SYN Flood, pode dar uma olhada no http://www.icylife.net/yunshu/show.php?id=367, que escrevi em 2006, e que depois fiz várias mudanças, corrigi bugs e reduziu a agressividade, sendo usado exclusivamente para testes.

Como o serviço mais básico e central da Internet, o DNS é naturalmente um dos alvos importantes dos ataques DDoS. Derrubar um serviço DNS pode derrubar indiretamente todo o negócio de uma empresa, ou um serviço de rede em uma região. Algum tempo atrás, o popular grupo de hackers anônimo também anunciou que atacaria 13 servidores DNS na Internet global, mas no final não teve sucesso.

Ataques UDP são o método mais fácil para iniciar tráfego massivo, e falsificação de IP de fonte aleatória é difícil de rastrear. No entanto, filtrar é mais fácil porque a maioria dos IPs não oferece serviços UDP, então você pode simplesmente descartar o tráfego UDP. Portanto, ataques puramente de tráfego UDP são relativamente raros atualmente, e são substituídos por ataques DNS Query Flood carregados pelo protocolo UDP. Simplificando, ataques DDoS lançados quanto mais alto o protocolo, mais difícil é defendê-lo, pois quanto mais alto o protocolo, mais relacionado aos negócios ele é e mais complexo o sistema de defesa enfrenta.

Inundação de Consultas DNS ocorre quando um atacante manipula um grande número de máquinas sockpuppet para lançar um grande número de solicitações de consulta de nome de domínio ao alvo. Para evitar filtragem baseada em ACL, a aleatoriedade dos pacotes deve ser aprimorada. Uma prática comum é forjar aleatoriamente o endereço IP de origem, falsificar aleatoriamente a porta de origem e outros parâmetros na camada UDP. Na camada do protocolo DNS, o ID da consulta é forjado aleatoriamente junto com o nome de domínio a ser resolvido. Além de evitar filtros, nomes de domínio falsificados aleatórios a serem resolvidos também podem reduzir a probabilidade de acessar o cache DNS e consumir o máximo de recursos da CPU possível do servidor DNS.

Sobre o código para o DNS Query Flood, escrevi um código em julho de 2011 para testar o desempenho do servidor, e o link está http://www.icylife.net/yunshu/show.php?id=832. Da mesma forma, esse código é artificialmente menos agressivo e serve apenas para fins de teste.

O SYN Flood e o DNS Query Flood descritos acima podem ser efetivamente defendidos neste estágio, e o verdadeiro problema para grandes fabricantes e empresas de Internet são os ataques HTTP Flood. HTTP Flood é um ataque a um serviço web em um protocolo de sétima camada. Seu grande dano se manifesta principalmente em três aspectos: iniciação conveniente, filtragem difícil e impacto de longo alcance.

Tanto o SYN Flood quanto o DNS Query Flood exigem que atacantes controlem um grande número de bots com privilégios root. Leva tempo e esforço coletar um grande número de privilégios de raiz, e durante o ataque, a máquina fantoche demora a reabastecer devido à rápida perda de recursos pelo atacante devido ao tráfego anormal descoberto pelo administrador, resultando em uma redução significativa na intensidade do ataque e não podendo ser sustentada por muito tempo. Os ataques HTTP Flood são diferentes, os atacantes não precisam controlar um grande número de bots, mas sim usar scanners de portas para encontrar proxies HTTP anônimos ou proxies SOCKS na Internet, através dos quais o atacante inicia requisições HTTP para o alvo do ataque. Proxies anônimos são um recurso relativamente rico, e não é difícil obter proxies em poucos dias, então ataques são fáceis de iniciar e podem durar muito tempo.

Por outro lado, ataques de inundação HTTP são lançados na camada HTTP, que imita vigorosamente o comportamento de solicitação de página web dos usuários comuns, o que está intimamente relacionado ao negócio do site, dificultando que fornecedores de segurança forneçam uma solução comum que não afete a experiência do usuário. Regras que funcionam bem em um só lugar, mudando de cenário pode levar a um grande número de homicídios culposos.

Por fim, ataques de inundação HTTP podem causar reações em cadeia sérias, não apenas causando resposta lenta diretamente da interface web atacada, mas também atacando indiretamente a lógica Java e outras camadas de negócio e serviços de banco de dados back-end, aumentando sua pressão e até afetando servidores de armazenamento de log.

Curiosamente, HTTP Flood também tem um apelido histórico chamado ataque CC. CC é uma abreviação de Challenge Collapsar, que é um dispositivo de proteção contra DDoS de uma empresa de segurança renomada na China. A julgar pela situação atual, não só o Collapsar, mas todo o equipamento de defesa de hardware ainda está sendo desafiado, e o risco não foi eliminado.

Quando se trata de ataques, a primeira reação é um tráfego massivo e pacotes enormes. Mas existe um ataque que faz o oposto, conhecido por ser lento, de modo que alguns alvos de ataque são mortos sem saber como morrem, que é o ataque de conexão lenta, sendo o mais representativo o Slowloris inventado pelo rsnake.

O protocolo HTTP estipula que as requisições HTTP terminam em \r\n\r\n, indicando que o cliente terminou de enviar e o servidor começou a processar. E o que acontece se você nunca enviar \r\n\r\n? Slowloris usa isso a seu favor em ataques DDoS. O atacante configura a Conexão para Keep-Alive no cabeçalho da requisição HTTP, pede ao servidor web que mantenha a conexão TCP não desconectada e então envia lentamente um formato chave-valor para o servidor a cada poucos minutos, como a:b\r\n, fazendo o servidor pensar que o cabeçalho HTTP não foi recebido e esperar. Se um atacante usar multithreading ou um fantoche para fazer o mesmo, o contêiner web do servidor rapidamente será sobrecarregado pelo atacante e não aceitará mais novas solicitações.

Logo, várias variantes dos Slowloris começaram a aparecer. Por exemplo, o método POST envia dados para o servidor Web, preenche um grande conteúdo de comprimento de conteúdo, mas lento byte a byte, conteúdo real de dados POST, etc. Sobre o ataque dos Slowloris, o rsnake também fornece um código de teste, veja http://ha.ckers.org/slowloris/slowloris.pl.

O que foi dito acima introduz vários métodos básicos de ataque, qualquer um dos quais pode ser usado para atacar a rede e até mesmo derrotar grandes sites como Alibaba, Baidu e Tencent. Mas não é só isso, diferentes níveis de atacantes podem lançar ataques DDoS completamente diferentes, e o uso deles é a mesma coisa.

Atacantes avançados nunca usam um único vetor para atacar, mas os combinam de forma flexível com base no ambiente alvo. O Flood SYN comum é fácil de ser filtrado por dispositivos de limpeza de tráfego por meio de detecção reversa, cookies SYN e outros meios técnicos, mas se pacotes SYN+ACK forem misturados no SYN Flood, de modo que cada pacote SYN falsificado tenha um pacote de confirmação de cliente falsificado correspondente, o correspondente aqui refere-se ao endereço IP de origem, porta de origem, IP de destino, porta de destino, tamanho da janela TCP, TTL, etc., todos alinhados com as características do mesmo host e do mesmo Fluxo TCP. A pressão sobre o desempenho da detecção reversa e dos cookies SYN dos equipamentos de limpeza de fluxo aumentará significativamente. Na verdade, pacotes de dados SYN e vários outros bits de flag possuem efeitos especiais de ataque, que não são introduzidos aqui. Também existem técnicas únicas para o DNS Query Flood.

Primeiramente, o DNS pode ser dividido em DNS comum e DNS de domínio autorizado, atacando DNS comum, o endereço IP precisa ser forjado aleatoriamente, e o servidor requer resolução recursiva; No entanto, ao atacar o DNS de domínio autorizado, o endereço IP de origem forjado não deve ser puramente aleatório, mas sim os endereços DNS dos provedores de internet ao redor do mundo coletados antecipadamente, para alcançar o máximo efeito de ataque, de modo que o dispositivo de limpeza de tráfego fique na situação constrangedora de adicionar ou não adicionar a lista negra de IP. Adicioná-la levará a um grande número de homicídios culposos e, se você não adicionar uma lista negra, cada pacote precisa ser investigado ao contrário, o que aumenta a pressão de desempenho.

Por outro lado, como mencionado anteriormente, para aumentar a pressão de limpeza do dispositivo, é necessário randomizar o nome de domínio solicitado sem acessar o cache, mas deve-se notar que o nome de domínio a ser resolvido deve ter certa regularidade na falsificação, como falsificar apenas uma parte específica do nome de domínio e solidificar uma parte para romper a lista branca estabelecida pelo dispositivo de limpeza. A razão é simples: os servidores da Tencent só conseguem resolver os nomes de domínio da Tencent, e nomes de domínio completamente aleatórios podem ser descartados diretamente e precisam ser consolidados. Mas se estiver completamente consertado, é fácil descartá-lo diretamente, então precisa ser forjado.

Segundo, ataques ao DNS não devem focar apenas nas portas UDP, que também são serviços padrão segundo o protocolo DNS. Em caso de ataque, tanto ataques UDP quanto TCP podem ser realizados ao mesmo tempo.

O foco do HTTP Flood é romper o cache no frontend e acessar diretamente o próprio Servidor Web através das configurações de campo no cabeçalho HTTP. Além disso, o HTTP Flood também é muito crítico para a seleção de alvos, e atacantes comuns escolherão páginas que exigem muitas consultas de dados, como busca, como o alvo do ataque, o que é muito correto e pode consumir o máximo de recursos possível do servidor. Mas esse ataque é fácil de ser identificado por equipamentos de limpeza por meio de identificação humano-máquina, então como resolver esse problema? É muito simples, tente escolher páginas que usuários comuns também acessam pelo APP, geralmente várias APIs Web. Usuários normais e tráfego malicioso vêm do APP, e a diferença entre homem e máquina é muito pequena, sendo difícil distinguir entre integração básica.

Cada conexão TCP existe tanto no lado do servidor quanto em si mesma, e também precisa consumir recursos para manter o estado TCP, então a conexão não pode ser mantida demais. Se isso puder ser resolvido, a agressividade será muito aumentada, ou seja, o Slowloris pode lançar ataques de forma sem estado, capturar o número de série do TCP e confirmar a manutenção das conexões TCP no cliente por meio do sniffing, e o kernel do sistema não precisa prestar atenção às várias mudanças de estado do TCP, e um notebook pode gerar até 65.535 conexões TCP.

As descrições anteriores são todas aprimoramentos técnicos de ataque. No lado humano, existem outros meios. Se o SYN Flood envia um grande número de pacotes e é acompanhado por conexões lentas do Slowloris, quantas pessoas vão descobrir o segredo? Mesmo que o servidor caia, apenas ataques SYN podem ser encontrados, tentando fortalecer a limpeza da camada TCP e ignorando o comportamento da camada da aplicação. Todos os tipos de ataques podem trabalhar juntos para alcançar o máximo efeito. A escolha do horário de ataque também é um ponto chave, como escolher o pessoal de manutenção quando eles estão almoçando, quando o pessoal de manutenção fica preso na estrada após sair do trabalho ou quando não há sinal no cartão de rede sem fio do metrô, e quando a empresa-alvo está realizando um evento de grande escala e o tráfego aumenta.

Este é um ataque puro, então não há código ou explicação detalhada.

Os métodos de ataque anteriores mais ou menos exigem alguns bots, até mesmo HTTP Flood exige buscar um grande número de proxies anônimos. Se houver um ataque, você só precisa emitir algumas instruções, e a máquina automaticamente se aproximará para executá-lo, o que é a solução perfeita. Esse ataque já apareceu, e isso vem de redes P2P.

Como todos sabemos, usuários e tráfego P2P na Internet são um número extremamente grande. Se todos forem a um local designado para baixar dados e conectar milhares de endereços IP reais, nenhum dispositivo pode suportar isso. Pegue o download do BT como exemplo: falsificar torrents de alguns vídeos populares e postá-los em mecanismos de busca é suficiente para enganar muitos usuários e tráfego, mas isso é apenas um ataque básico.

Ataques avançados P2P são falsificações diretas de servidores de gerenciamento de recursos. Por exemplo, o cliente Thunder enviará os recursos encontrados para o servidor de gerenciamento de recursos e depois os enviará para outros usuários que precisam baixar os mesmos recursos, para que um link seja publicado. Por meio da reversão de protocolos, os atacantes forjam uma grande quantidade de informações populares de recursos e as distribuem pelo centro de gerenciamento de recursos, que podem ser instantaneamente espalhadas por toda a rede P2P. O que é ainda mais assustador é que esse ataque não pode ser detido, nem mesmo pelo próprio atacante, e o ataque continua até que o oficial P2P encontre o problema, atualize o servidor e o usuário de download reinicie o software baixado.

É só isso que há sobre a introdução aos ataques DDoS, e não quero ir além — basta entender que tanta defesa é o bastante.

Em geral, ataques DDoS podem ser habilidosos e graciosos. A beleza da aplicação está na unidade da mente.