|
|
| Linha 1: |
Linha 1: |
| | {{DISPLAYTITLE:Static Loop - um erro que pode matar seu ISP/ITP}} | | {{DISPLAYTITLE: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:
| |
| − | [[Arquivo:Static loop.drawio.png|esquerda|miniaturadaimagem|751x751px]]
| |
| − | 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.
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − |
| |
| − | == 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:
| |
| − | [[Arquivo:Static loop report.png|nenhum|miniaturadaimagem|1192x1192px]]
| |
| − |
| |
| − | == 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 comecar|IPv6 - Por onde começar]]. Após corrigir o static loop teríamos a seguinte situação:
| |
| − | [[Arquivo:Static loop.drawio2.png|esquerda|miniaturadaimagem|748x748px]]
| |
| − | 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.
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br>
| |
| − | <br><br><br><br><br>
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − |
| |
| − | == 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: [[Usuário:Gondim|Marcelo Gondim]]
| |
| | [[Categoria:Infraestrutura]] | | [[Categoria:Infraestrutura]] |
