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

[Lucas Willian Bocchi]

Douglas, lembrei agora.

No caso das ONU FiberHome, teve um cliente que teve a brilhante idéia de
fixar a negociação da porta em 10 Mega Half Duplex. O sistema dele
conversava com as ONU's e pra acabar dando uma amenizada ele fez isso. Quem
sabe seja uma idéia também.

Em qui., 24 de mar. de 2022 às 09:34, Lucas Willian Bocchi <
lucas.bocchi at gmail.com> escreveu:

> 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
>>
>