Identificando e neutralizando uma Botnet - Histórico de revisão

Gondim em 04h15min de 11 de julho de 2023

2023-07-11T04:15:41Z

← Edição anterior		Edição das 04h15min de 11 de julho de 2023
Linha 47:		Linha 47:
	Obs.: o exemplo acima está sendo feito com egrep para enxergarmos os pacotes encapsulados mas se quisesse ver os pacotes PPPoE por exemplo: '''tcpdump -i enp2s0f0 -n "pppoes and host 100.64.224.6"'''		Obs.: o exemplo acima está sendo feito com egrep para enxergarmos os pacotes encapsulados mas se quisesse ver os pacotes PPPoE por exemplo: '''tcpdump -i enp2s0f0 -n "pppoes and host 100.64.224.6"'''

	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:<pre>		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 nosso exemplo:<pre>
	# egrep "100\.64\.224\.6\." botnet.txt \|less		# egrep "100\.64\.224\.6\." botnet.txt \|less
	</pre>[[Arquivo:Botnet4.png\|semmoldura\|1289x1289px]]		</pre>[[Arquivo:Botnet4.png\|semmoldura\|1289x1289px]]

Gondim em 03h11min de 9 de julho de 2023

2023-07-09T03:11:49Z

← Edição anterior		Edição das 03h11min de 9 de julho de 2023
Linha 52:		Linha 52:
	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.		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 [https://www.peeringdb.com/ '''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.		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 [https://www.peeringdb.com/ '''PeeringDB''']. Para cortar a comunicação com o C&C, a forma mais efetiva e sem gerar custos de CPU é criando 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:		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:

Gondim em 18h33min de 8 de julho de 2023

2023-07-08T18:33:54Z

← Edição anterior		Edição das 18h33min de 8 de julho de 2023
Linha 68:		Linha 68:
	Essa documentação foi útil? Compartilhe, divulgue e ajude outras pessoas.		Essa documentação foi útil? Compartilhe, divulgue e ajude outras pessoas.

	Autor: [[~~Usuário:Gondim~~\|Marcelo Gondim]]		Autor: [[Sobre mim\|Marcelo Gondim]]
			[[Categoria:Artigos Técnicos]]

Gondim em 18h31min de 8 de julho de 2023

2023-07-08T18:31:29Z

← Edição anterior		Edição das 18h31min de 8 de julho de 2023
Linha 13:		Linha 13:
	== Coleta inicial de informações ==		== 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.		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.
	[[Arquivo:Botnet2.~~png~~\|nenhum\|commoldura]]		[[Arquivo:Botnet2.jpg\|nenhum\|commoldura]]

	== Próximo passo montar ambiente de análise da Botnet ==		== Próximo passo montar ambiente de análise da Botnet ==
Linha 36:		Linha 36:
	\|}		\|}

	[[Arquivo:Botnet7.~~png~~\|semmoldura\|536x536px]]		[[Arquivo:Botnet7.jpg\|semmoldura\|536x536px]]

	== Analisando os pacotes ==		== Analisando os pacotes ==

Gondim em 18h27min de 8 de julho de 2023

2023-07-08T18:27:45Z

← Edição anterior		Edição das 18h27min de 8 de julho de 2023
Linha 1:		Linha 1:
	__TOC__		__TOC__
	[[Arquivo:Botnet banner.png\|nenhum\|commoldura]]		[[Arquivo:Botnet banner.png\|nenhum\|commoldura]]

	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\|'''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.		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\|'''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.

Gondim em 18h25min de 8 de julho de 2023

2023-07-08T18:25:58Z

← Edição anterior		Edição das 18h25min de 8 de julho de 2023
Linha 1:		Linha 1:
	aa		__TOC__
			[[Arquivo:Botnet banner.png\|nenhum\|commoldura]]

			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\|'''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:
			[[Arquivo:Botnet1.png\|nenhum\|commoldura]]
			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.
			[[Arquivo:Botnet2.png\|nenhum\|commoldura]]

			== 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:
			{\| class="wikitable"
			\|+
			!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)
			\|}

			[[Arquivo:Botnet7.png\|semmoldura\|536x536px]]

			== 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'''.

			[[Arquivo:Botnet3.jpg\|semmoldura\|404x404px]]

			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
			Obs.: o exemplo acima está sendo feito com egrep para enxergarmos os pacotes encapsulados mas se quisesse ver os pacotes PPPoE por exemplo: '''tcpdump -i enp2s0f0 -n "pppoes and host 100.64.224.6"'''

			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:<pre>
			# egrep "100\.64\.224\.6\." botnet.txt \|less
			</pre>[[Arquivo:Botnet4.png\|semmoldura\|1289x1289px]]
			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 [https://www.peeringdb.com/ '''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.
			[[Arquivo:Botnet5.jpg\|nenhum\|commoldura]]

			== 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.
			[[Arquivo:Botnet6.png\|nenhum\|commoldura]]

			== 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 configurados 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 [https://www.lacnog.net/docs/lac-bcop-1 '''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: [[Usuário:Gondim\|Marcelo Gondim]]

Gondim: Criou página com 'aa'

2023-07-08T18:25:27Z

Criou página com 'aa'

Página nova