[GTER] ISP - Clientes Infectados Originando ataques com muitos PPS - Afetando equipamentos internos

[Lucas Willian Bocchi]

Bom dia Douglas

Tenho, com muito sucesso, convencido clientes que passam por esse problema
a adotarem firmwares alternativos nos seus dispositivos, ou até mesmo
customizar individualmente para o seu provedor. Além de ser possível a
customização ao ponto de você criar via sistema e API regras de firewall,
etc, lá no dispositivo do cliente, é possível até mesmo criar um controle
de banda lá que ajude a mitigar o problema.

Em se falando de solução já pronta, os fiberhome, etc, não aceitam TR-069?
Não é possível tentar algo com ele?

Outra coisa importante Douglas: esses botnets se espalham dentro da rede do
indivíduo se houver comunicação inter-cliente. Eles estão isolados ou
conseguem se ver? É um ponto de detalhe.

Quando o assunto é a diversidade de dispositivos aí é complicado. Eu tenho
alguns scripts que analisam o controle de banda do cliente via snmp e
verificam se o mesmo está com uma taxa altíssima de upload / download
dropped ou se a banda do cara está estourada a mais de 5 minutos (analisa
de 1 em 1 minuto e olha se o consumo está sempre o mesmo e acima de 1 mega,
por exemplo) e já dá um drop no cara via API. Só que isso funciona bem pra
quando tem um ou dois clientes com o tal botnet. Depois que a coisa já
desandou fica difícil não ser manual o controle.



Em qui., 24 de mar. de 2022 às 09:23, Douglas Fischer via gter <
gter at eng.registro.br> escreveu:

> Gostaria de compartilhar um caso que vivenciamos num cliente nosso de
> consultoria ontem.
> E quem sabe pensarmos em alguma solução mais efetiva...
>
> Um ISP cliente nosso de consultoria está com alguns clientes infectados com
> alguma BotNet.
> Estamos trabalhando para tentar identificar a botnet, comando e controle, e
> bloquear essa comunicação para tornarmos inertes esse zombies.
> E o cliente também está trabalhando para corrigir (dentro da medida do
> possível) esses clientes infectados (pensa no trabalhão lascado!).
>
> Porém o foco desse contato NÃO É falar sobre o bloqueio da comunicação com
> o Comando e Controle da Botnet!
>
> Quero primeiro relatar como isso afetou o bom funcionamento da rede do
> cliente.
> Trata-se de uma rede mista, com B-RAS feitos por Mikrotik e Juniper, e
> CGNAT feitos por Mikrotik e A10.
>
> Quando os ataques iniciam chegamos a ver clientes domésticos enviando até
> 12-15 mil PPS, todo de 64 bytes.
> Ainda não temos mapeados isso com precisão, mas vimos que equipamentos com
> DVR e caixinhas de IPTV "alternativo" como sendo algumas das origens.
>
> P.S.1: Ainda não confirmei, mas tenho a impressão de que as ONUs mas
> fraquinhas estão até amenizando o problema...
> Por não ter torque o suficiente, não chegam a conseguir passar adiante
> tantos pacotes quanto os que vem do dispositivo infectado.
>
> Falando de B-RAS:
> Quando algum cliente desses Infectados estava em um B-RAS Mikrotik, a CPU
> da caixa subia BASTANTE e a CPU subia MUITO, mas o impacto no tráfego dos
> demais clientes era muito baixo ou quase não exisitia.
> Quando algum cliente desses Infectados estava em um B-RAS Juniper, nem
> fazia cócegas...
>
> Falando de CGNAT:
> Quando o tráfego de um(ou mais) desses clientes infectados subia passando
> por um CGNAT feito com Mikrotik, o pico de consumo de CPU era TÃO INTENSO
> que quase imediatamente a caixa parava de responder.
> Quando o tráfego de um(ou mais) desses clientes infectados subia passando
> por um CGNAT feito com A10, havia algum aumento de uso de recursos, mas não
> afetava os demais clientes.
>
> Até agora tomamos algumas medidas paliativas nos B-RAS e CGNAT para
> rastrear e bloquear esses clientes temporariamente, e depois manualmente
> movê-los para um conjunto de B-RAS+CGNAT criado especialmente para isso.
> Mas, isso é uma medida reativa, que depende de ação manual.
>
> P.S.2: Cabe lembrar que lá em cima já mencionei que outras ações envolvendo
> análise e filtragem de domínio de DNS e bloqueio de comunicação com IPs de
> comando e controle já foram iniciadas.
>
> ------------------------------------
> AGORA VEM O PEDIDO de BRAINSTORM
> ---------------------------------
>
> Do meu ponto de vista, o mais lógico a fazer nesse contexto é criar uma
> limitação de PPS condizente com a demanda corriqueira de um usuário normal,
> e talvez multiplicar isso por 2 ou 3 como limitador.
> Pensei em aplicar isso em 2 pontos:
>
> No B-RAS, onde além da limitação de Banda, limitaríamos também o PPS.
>  - Para Juniper, imagino que isso seja possível, porém ainda não consegui
> chegar nessa receita de Bolo usando Dynamic-Profiles.
>  - Para Mikrotik, mesmo que consigamos criar esse modelo de regras, é bem
> provável que a caixa vá "sentar" do mesmo jeito... Pois esse controle de
> PPS e limitação também seria processado pela CPU.
>
> Na camada de Acesso, lá na OLT.
>  - Mas para minha ingrata surpresa, até agora tanto em Fiberhome e Huawei
> não encontramos (até agora) formas de fazer esse controle de PPS.
> P.S.3: Paliativamente, para esses clientes infectados, está se aplicando
> profiles limitando o Upload em 1Mbps. Porém, ainda assim com 1Mbps e
> pacotes de 64Bytes, se pode chegar a 2 mil PPS.
>
> No Switch de transporte da OLT até o B-RAS
>  - Pensei em um controle no estilo Traffic Policing aplicado na interface
> que recebe a ligação da OLT. Porém não achei até agora uma forma de fazer
> uma regra genérica que faça essa limitação por MAC.
>  - Essa é a opção menos preferida, pois certamente conflitará com cenário
> de transporte MPLS das Vlans de PPP.
>
> E aí?
> Além de falar de cessar a comunicação entre os Zombies e Comando e Controle
> ( em que já estamos trabalhando)...
> Alguma sugestão que permita limitar o PPS que vem dos clientes?
> Se além de limitar, conseguirmos gerar um gatilho de notificação, melhor
> ainda! Vais ser ideal para rastrear os clientes infectados.
>
> Agradeço desde já a atenção de todos.
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>