Static Loop - um erro que pode matar seu ISP/ITP
Introdução
O static loop é algo que, definitivamente, pode derrubar toda a sua operação se não for devidamente tratado e pode ser facilmente explorado por pessoas mal intencionadas. Simplesmente é falta de uma configuração de Rede, que ocorre com prefixos tanto em IPv4 quanto em IPv6; que não existem na tabela de rotas do sistema, até que haja uma conexão no equipamento e que insira o prefixo nela (famosas rotas conectadas). Isso ocorre sempre nos casos em que temos concentradores PPPoE (BNG) e caixas CGNAT. Vamos exemplificar com a seguinte situação:
Na figura ao lado temos um concentrador entregando, via PPPoE, o prefixo 198.18.0.0/24 para os clientes. Nesse caso um cliente pegou o IP 198.18.0.0/32. Esse prefixo foi inserido da tabela de rotas do BNG e por isso se alguém da Internet tentasse enviar um ping para ele, provavelmente seria respondido. Isso porque na borda existe uma rota onde diz que tudo que for para 198.18.0.0/24 deve ser encaminhado para o next-hop 172.20.0.2 e no BNG existe uma rota default apontando para a borda no IP 172.20.0.1.
Até aqui tudo funcionaria bem mas um indivíduo mal intencionado resolveu scanear sua Rede a procura de algum static loop, encontrou o IP 198.18.0.10 e então começou a disparar um ataque para esse IP descoberto.
O ataque então se inicia e um pacote com destino ao IP 198.18.0.10 chega na borda do seu Provedor. O router então encaminha o pacote para o BNG que possui o prefixo 198.18.0.0/24. O pacote ao chegar no BNG é checado na tabela de rotas para onde deverá ser encaminhado, mas só existe o prefixo 198.18.0.0/32 na tabela de rotas, que é do cliente que está conectado. Não existe qualquer outra rota para que seja entregue o pacote no IP 198.18.0.10, então só resta ao BNG devolver o pacote para a borda, através do default gateway. Então começará o processo de loop porque a borda reencaminhará o pacote novamente para o BNG e este devolverá novamente para a borda. Esse loop continuará até que o TTL do pacote se esgote e seja descartado. Vale ressaltar que esse loop resulta em um ataque de amplificação que pode derrubar sua Infraestrutura de Redes, de dentro para fora. Esse efeito foi exemplificado aqui usando o IPv4 mas o mesmo também pode ocorrer com IPv6, sendo eles privados ou públicos.
Como testar se o seu ASN possui static loop
Precisaremos de um ambiente externo ao seu ASN; não adianta testar de dentro da sua rede mas você pode pedir a um Provedor parceiro, fazer o teste para você ou se você possuir alguma VM em algum Datacenter fora do seu ASN, você mesmo pode testar. Para testar usaremos um GNU/Linux qualquer com o pacote fping. Aqui usaremos o Debian como sempre.
# apt install fping
Após instalar você pode rodar o comando para checar um prefixo por vez dessa forma:
# fping -gae 198.18.0.0/24
Ou se quiser passar em todo o seu ASN e gerar um relatório, eu elaborei o comando abaixo substituindo o <ASN> pelo seu ASN, por exemplo AS65000. Não esqueça de adicionar o "AS" e o número juntos.
# for lista in `whois <ASN>|grep "inetnum:"|awk '{print $2}'| grep -v ":"`; do (fping -gae $lista 2>> /tmp/lista; cat /tmp/lista| grep -v "<-" |grep "Time Exceeded"|sort -u > /tmp/static_loop.txt; rm -f /tmp/lista); done
O comando acima fará um scaner em todos os seus prefixos IPv4 do seu ASN e gerará um arquivo com o resultado em /tmp/static_loop.txt. Se quando acabar o arquivo estiver vazio, é porque você não possui static loop na sua rede. Parabéns!
Agora se o arquivo contiver uma listagem, sinal que você precisa acertar esses problemas antes que você seja vítima de um static loop. Abaixo um exemplo de como seria essa lista:
Como eu fixo o problema do static loop
Para fixar é bem simples mas dependerá do vendor do seu equipamento. Normalmente você aplicará esse fix nas caixas BNGs e em caixas de CGNAT. Você precisará criar uma rota cheia para cada prefixo usado nos pools de PPPoE e nos pools de CGNAT, apontando para discard ou jogando para blackhole com um distance alto. Abaixo nosso exemplo como seria em um Mikrotik concentrador PPPoE:
/ip route add distance=254 dst-address=198.18.0.0/24 type=blackhole add distance=254 dst-address=100.64.0.0/10 type=blackhole /ipv6 route add distance=254 dst-address=2001:db8::/32 type=unreachable
Embora no nosso diagrama não tenha IPv6, porque não é saudável fazer um scaner em um prefixo IPv6 devido ao seu enorme tamanho, mesmo assim ele precisa ser configurado, caso você entregue IPv6 aos seus clientes. Não tem IPv6 ainda? É melhor você repensar suas prioridades e olhar esse meu artigo IPv6 - Por onde começar. Após corrigir o static loop teríamos a seguinte situação:
Observando o exemplo ao lado, após incluir as correções, quando o atacante enviar o pacote para o IP 198.18.0.10, este chegará até o BNG, contudo se não houver um cliente conectado utilizando o 198.18.0.10/32, haverá uma rota de discard ou blackhole para o prefixo cheio 198.18.0.0/24, que descartará o pacote não deixando entrar no static loop. Se algum cliente estiver conectado e que tenha recebido o IP 198.18.0.10/32, este prefixo estará na tabela de rotas e ganhará por ser mais específico do que nossa rota de descarte.
Para testar se resolveu mesmo o problema rode novamente o comando, conforme explicado anteriormente, e confirme se ficou tudo OK.
Finalizando
Devemos resolver o quanto antes os problemas de static loop, antes que eles comecem a afetar a estabilidade e qualidade dos serviços entregues. Se você tem clientes que utilizam seus recursos IP e estão vulneráveis a esse tipo de problema, converse com eles, explique sobre o problema, o que isso pode vir a prejudicar os negócios deles e implemente a correção o quanto antes. Quer dar um UP! no seu Provedor? Aqui está algo que te trará uma melhoria de segurança na sua Infraestrutura de Redes.
Essa documentação foi útil? Compartilhe, divulgue e ajude outras pessoas. Meus contatos podem ser vistos aqui.