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

[Alexandre J. Correa (Onda)]

Juniper é possível fazer:

No firewall filter de upload (download também pode ser aplicado)

Você tem um "term" para o controle de banda (then policer xxxxx)
basta criar um term ANTES do controle de banda com um policer que limita 
PPS...

Exemplo:

set firewall family inet filter controle-banda-teste-upload-xpto ........
..
..
set firewall family inet filter controle-banda-teste-upload-xpto term 
PPS then policer policer-teste-pps
set firewall family inet filter controle-banda-teste-upload-xpto term 
QOS then policer policer-teste-banda
set firewall family inet filter controle-banda-teste-upload-xpto term 
DEFAULT then accept


O Policer de PPS assim:

    policer policer-teste-pps {
        logical-interface-policer;
        if-exceeding-pps {
            pps-limit 5k;
            packet-burst 500;
        }
        then discard;

    }


A lógica é aplicar o controle de PPS antes do controle de BANDA.

Não testei, mas se tiver como testar e dar um retorno.



Em 24/03/2022 09:22, Douglas Fischer via gter 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.
>

--