Identificando e neutralizando uma Botnet

Atualmente a maior preocupação de todo ISP (Internet Service Provider) e ITP (Internet Transit Provider) são os ataques DDoS (Distributed Denial of Service) recebidos em suas Redes e a indisponibilidade que eles podem causar derrubando sua infraestrutura e seus clientes. Criamos mecanismos de defesa como: sistemas de detecção de anomalias como por exemplo o Wanguard, anunciamos os prefixos atacados para nossas nuvens de mitigação e assim fazemos a limpeza do tráfego. Mas e quando sua rede também está fazendo parte dos ataques de DDoS e atacando outros ASNs na Internet? Poucas pessoas se preocupam com o que saem de suas Redes e isso pode estar impactando sua operação e causando insatisfação em seus clientes. As Portas de Amplificação abertas e Botnets são as principais causas para esses problemas. Como tratar Portas de Amplificação você pode ler nesse meu artigo Portas de Amplificação DDoS e Botnets mas aqui vamos falar de algo um pouco mais trabalhoso, que seria como identificar e neutralizar uma Botnet que se instalou na sua Rede.

Entendendo uma Botnet

Primeiro temos que entender como elas funcionam: são diversos, milhares de dispositivos vulneráveis que são invadidos e infectados com programas (bots) que se conectam em servidores chamados C&C (command and control). O dispositivo pode ser qualquer um infectado como CPEs, ONUs roteadas, computadores, enfim qualquer coisa que tenha um IP e possa acessar a Internet. Esses dispositivos infectados uma vez conectados nesses C&C podem receber e executar diversas tarefas para o cibercriminoso como por exemplo: envio de spam, roubo de informações e orquestrar ataques sincronizados em uma determinada vítima. Esses ataques saem com uma certa volumetria da sua rede e isso pode saturar diversos pontos da sua infraestrutura causando indisponibilidade para seus clientes. Seria um DDoS ao contrário, da sua Operação para a Internet.

Panorama de uma Botnet em andamento e atacando uma vítima

Para vermos os estragos que uma Botnet pode causar abaixo um gráfico dos momentos de ataques que saíam da Operação com destino à vítimas:

Na imagem acima podemos observar diversos picos de mais de 4Gbps com destino a Internet. Agora vamos imaginar o que esses picos estariam causando em suas portas PON das suas OLTs e quantos clientes poderiam estar sendo afetados. Quanto maior a infecção da Botnet maior será o poder de ataque desses cibercriminosos. Percebam que só é possível identificar visualmente essa situação, se vocês tiverem ferramentas de monitoramento como um Zabbix por exemplo. Monitoramento é vital e fundamental para identificarmos algo impactante em nossa Operação.

Coleta inicial de informações

Para tratar esse incidente, precisaremos identificar pelo menos 1 dispositivo infectado e observar o tráfego desse dispositivo para entendermos como é a comunicação entre os bots e seus C&C. Apenas pelo monitoramento acima não teremos essa resposta, nesse caso entra como um dos fatores de busca a ferramenta de análise de anomalias, como por exemplo: Fastnetmon, Wanguard, Kentik. A ideia é analisar os flows coletados na hora da saída do ataque, observar as anomalias de uploads que estourem thresholds de upload e ainda podemos analisar casos envolvendo pacotes UDP, que causam mais estragos. Desse jeito podemos eleger alguns possíveis candidatos infectados para que possamos monitorar de perto.

Próximo passo montar ambiente de análise da Botnet

Agora que temos alguns candidatos infectados, precisamos montar um ambiente lab para que possamos monitorar e registrar os ataques. Observar o comportamento deles e quem aciona eles. Para isso vamos precisar de um GNU/Linux, que neste artigo será um Debian mas poderá ser qualquer outra distribuição que tenha um tcpdump para fazermos a análise dos pacotes, precisaremos de uma interface apropriada que consiga receber o tráfego da interface por onde estão vindo os ataques. Exemplo:

Vamos supor que os ataques estejam vindo de uma interface onde tem um BNG/B-RAS PPPoE e o tráfego seja de uns 4Gbps, nesse caso colocaríamos uma interface de 10Gbps nesse GNU/Linux, ligamos na switch e fazemos um espelhamento (mirror) da porta do BNG/B-RAS para a porta onde temos nosso GNU/Linux. Dessa forma todo o tráfego passante na porta do BNG/B-RAS poderá ser analisado no GNU/Linux. Alguns teriam a ideia de fazer a análise diretamente no equipamento BNG, por exemplo em um Mikrotik usando o torch, mas não aconselho pois esse tipo de análise pode elevar o consumo de CPU do seu equipamento a 100% e isso não é bom. Então o jeito mais seguro e sem mexer muito no seu ambiente de produção, é esse que estou propondo.

Monte um equipamento para esse tipo de análise e já deixe pré configurado em seu ambiente:

CPU	Sistema	Memória	Disco	Interface de Rede
Quad Core	Debian GNU/Linux	8 a 16Gb	SSD 120Gb	Intel X520-SR2 (2 portas de 10GbE)

Analisando os pacotes

Para analisarmos os pacotes do dispositivo infectado vamos utilizar o programa tcpdump. Caso não conheça e não tenha familiaridade com ele, recomendo a leitura deste livro Análise de Tráfego em Redes TCP/IP do autor João Eriberto Mota Filho.

Após eleger um dispositivo infectado, pegamos o IP dele para monitorarmos suas atividades em busca dos ataques quando ocorrem. Irei colocar aqui exemplos reais de uma recente Botnet descoberta e neutralizada. Colocamos nosso sniffer (tcpdump) monitorando conforme o exemplo abaixo:

# tcpdump -i enp2s0f0 -n | egrep "100\.64\.224\.6\." | tee botnet.txt

Nesse exemplo acima estamos monitorando a interface de 10GbE enp2s0f0 , observando os pacotes com IP do dispositivo 100.64.224.6 e armazenando no arquivo botnet.txt. Quando perceber o pico sainte de ataque no flow da ferramenta de análise que comentei, por exemplo o Wanguard, teremos registrado os pacotes que precisamos e então podemos encerrar o comando acima e analisar nosso botnet.txt. Faremos o comando abaixo e observem meu nosso exemplo:

# egrep "100\.64\.224\.6\." botnet.txt |less

Dentro da janela 2 podemos ver o início do disparo do ataque para a vítima IP 103.216.154.99, diversos pacotes ACK para a porta de destino 88/TCP. Na janela 1 podemos perceber o início da comunicação entre o dispositivo infectado e o servidor C&C no IP 77.105.138.202 porta 35342/TCP. Logo após a comunicação entre eles, se inicia o ataque para a vítima.

Podemos fazer uma busca via whois nesse IP e coletar dados para posterior contato com o ASN responsável pelo IP e também consultar o PeeringDB. Para cortar a comunicação com o C&C, a forma mais efetiva e sem gerar custos de CPU é criado uma blackhole na sua borda para esse IP do servidor C&C. Infelizmente esse trabalho não tão rápido pois em uma Botnet pode haver mais de um servidor C&C e por isso precisamos continuar monitorando e bloqueando os IPs até que os ataques parem.

Depois de uma análise melhor percebemos que todos os servidores C&C estavam escutando na porta 35342/TCP e então começamos a monitorar o IP e porta assim:

# tcpdump -i enp2s0f0 -n | egrep "100\.64\.224\.6\." | egrep "\.35342:"

Então pegamos todos os servidores C&C e adicionamos em blackhole na borda, cortando a comunicação dos dispositivos infectados. De tempo em tempo o dispositivo tentava se comunicar com algum C&C conforme abaixo. Podemos observar os pacotes SYN da tentativa de comunicação com os servidores do Botnet.

Panorama após os bloqueios da Botnet

Depois de todos os bloqueios realizados não foram mais registrados ataques saintes para a Internet. Esse tipo de ação não limpa o dispositivo infectado mas lhe dá tempo para fazer essa limpeza posteriormente, sem que os clientes sejam penalizados no processo.

Conclusão

Precisamos manter nossa Infraestrutura de Redes sempre segura e principalmente os ativos na ponta do cliente como é o caso das CPEs. Escolham equipamentos corretamente, onde os fornecedores tenham preocupação com segurança, que suportem corretamente o IPv6. Equipamentos com usuário e senha padrão de fábrica são alvos fáceis para formação de Botnets. Procurem equipamentos que sigam a BCOP de CPEs Trocar equipamentos de core, pode ser mais simples que trocar milhares de CPEs infectadas nos clientes. Pensem sempre nisso.

Essa documentação foi útil? Compartilhe, divulgue e ajude outras pessoas.

Autor: Marcelo Gondim