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. A causa do problema é uma rota estática para um prefixo IP (seja IPv4 ou IPv6), que aponta para um next-hop e nesse destino não existe nenhuma informação sobre o prefixo IP na tabela de rotas local, obrigando o pacote a retornar para o seu gateway default e ficando nesse loop até que expire o TTL (Time To Live) do pacote. Isso ocorre muito 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 e interno ao seu ASN; faça o teste de dentro do seu próprio ASN e também de fora dele. De fora do ASN pode ser através de algum VPS (Virtual Private Server) seu hospedado em algum Datacenter fora do seu ASN. Já para testes de dentro da sua rede, procure usar um sistema que dele você tenha alcance a todos os ativos da sua infraestrutura. Para testarmos usaremos um sistema 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.

# >/tmp/static_loop.txt; 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.

Autor: Marcelo Gondim