Como identificar e corrigir loops de roteamento
Uma das questões mais importantes a ser considerada ao preparar a sua rede para resistir contra ataques de negação de serviço, é a eliminação de loops de roteamento.
Parafraseando o Daniel Damito, que é o maior especialista em DDoS que eu conheço: Os efeitos causados por um loop de roteamento durante um ataque de negação de serviço, geralmente é muito maior e pior que o ataque em si.
O que são loops de roteamento?
Observe o seguinte cenário onde a topologia possui um roteador de borda e um BRAS/BNG onde se concentram as conexões dos assinantes:
Considere o CIDR 203.112.0/22 como uma rede IPv4 pública alocada para o AS65535, sendo este prefixo anunciado para uma operadora de trânsito.
O roteador de borda possui uma rota padrão (0.0.0.0/0) instalada, tendo a operadora de trânsito como gateway.
Há uma rota estática no roteador de borda, indicando o BRAS/BNG (172.16.0.2) como next-hop da sub-rede 203.0.113.0/24.
O BRAS/BNG possui como gateway, somente o roteador de borda(172.16.0.1) através de uma rota padrão (0.0.0.0/0).
Esta topologia não possui rotas de blackhole para redes ociosas e/ou menos específicas do CIDR público alocado para o AS.
Agora imagine um pacote vindo da internet com destino ao ip 203.0.113.200, que está alocado e ativo na conexão de um cliente. Este pacote e terá o seu TTL (time to live) extinguido após 2 ou no máximo 3 saltos dentro da topologia,pois alcançará o seu destino, que é o host no qual a conexão está ativa.
Nesta mesma topologia, imagine um pacote vindo da internet com destino ao IP 203.0.113.100 que está ocioso, ou seja, não está ativo ou sequer alocado em nenhuma conexão. Este pacote encontrará seu caminho pelo roteamento eBGP até o roteador de borda, que irá encaminhar o pacote para o BRAS. Porém como no BRAS não uma conexão ativa para este host, a rota mais específica para alcança-lo torna-se a rota padrão do BRAS. Logo, o pacote será encaminhado de volta para o router de borda, que irá enviar novamente o pacote para o BRAS.
Este processo irá se repetir até esgotar o tempo de vida do pacote, que geralmente é de 30 saltos.
Ainda nesta mesma topologia, imagine um pacote sendo enviado para o host 203.0.112.50, que não faz parte da sub-rede 203.0.113.0/24 que está configurada no BRAS. Como não há rota mais específica no router de borda para alcançar este host, o next-hop novamente torna-se a rota padrão do router de borda, que neste caso é a operadora de trânsito.
Então, um pacote direcionado a este host entrará no roteador de borda através do eBGP e será novamente encaminhado para a operadora, repetindo este ping-pong até que o pacote esgote o seu Time to Live.
Mas é só um pacote, o que pode dar errado? Realmente, um único pacote pode não apresentar uma ameaça neste cenário. No entanto, e se estivermos lidando com um ataque de negação de serviço, com milhares ou milhões de pacotes por segundo sendo encaminhados para estes hosts inalcançáveis?
Em um cenário de ataque DDoS, os roteadores terão que processar os mesmos pacotes em loop até esgotar o seu TTL, ocupando e exaurindo recursos computacionais. E se você utiliza soft-routers como: frr, quagga, mikrotik, vyos, etc... o impacto geralmente é devastador, causando desde perdas de pacote, inacessibilidade à gerencia do equipamento até o travamento/crashing do equipamento.
Como você pode prevenir que este cenário aconteça?
Observe a mesma topologia, porém foram configuradas rotas de blackhole tanto no roteador de borda, quanto no BRAS, para as redes menos específicas distribuídas aos mesmos.
Neste cenário, um pacote enviado para o host 203.0.113.200 que não está alocado ou ativo em nenhum cliente, possui como saltos o Roteador de borda e o BRAS/BNG respectivamente.
Ao alcançar o BRAS/BNG, não havendo um next-hop mais específico (/29, /30, /32) para a conexão de um assinante, o próximo salto torna-se a interface Null0, através da rota 203.0.113.0/24. Logo, o pacote será descartado em apenas 2 saltos dentro desta topologia de rede.
Agora imagine o outro cenário, onde o destino do pacote seria o host 203.0.112.50 que não faz parte da sub-rede 203.0.113.0/24 que está roteada para o BRAS/BNG:
O pacote alcançará o roteador de borda através do roteamento eBGP, onde devido a falta de uma rota mais específica, o next-hop para alcançar este host torna-se a interface Null0 do roteador de borda, através da rota 203.0.112.0/22, onde o mesmo será descartado em apenas 1 salto dentro da sua rede.
É importante entender que essa medida sozinha não eliminará todos os efeitos colaterais causados por um ataque DDoS, mas possui um importante papel para tornar a sua rede mais resiliente em conjunto a outras medidas anti-ddos.
Lembre-se: o termo "mitigar" ou "mitigação", que significa suavizar, ou minimizar os impactos dos ataques à sua rede.
Mas como detectar loops de roteamento na minha rede?
O site radar.qrator.net, possui uma ferramenta que reporta loops de roteamento e outras vulnerabilidades, sendo possível inclusive configurar o envio de relatórios semanais.
Apesar de ser uma boa ferramenta, a mesma carece de transparência e versatilidade, ao menos em sua versão aberta, principalmente se você não é o "dono" do AS e da sub-rede que pretente analisar.
Ainda hoje eu verifico as estatísticas do radar.qrator.net como referencia cruzada. Mas visando um maior controle sob a tarefa e a possibilidade de realizar verificações sob demanda e agendadas, escrevi uma ferramenta em shell que me possibilita verificar periodicamente o nosso ASN, além dos ASN em nosso cone de downstream em busca de loops de roteamento.
Informando o ASN a ser analisado para a ferramenta, ela irá buscar no whois.nic.br pelos CIDRs públicos alocados ao mesmo e verificará se essas sub-redes possuem algum host com loop de roteamento, podendo emitir um relatório em formato de LOG, EMAIL ou mesmo uma notificação via TELEGRAM.
Se o AS analisado possuir suas políticas de roteamento definidas no portal do registro.br informando os seus clientes de transito (ver BCP para roteamento eBGP, aka MANRS), a ferramenta permitirá também verificar loops de roteamento nos CIDR públicos do seu cone de downstream de forma automática, possibilitando inclusive o envio automático de uma notificação para o mesmo. Isso irá manter a verificação dos seus clientes de transito sempre atualizada, sem a necessidade de adicionar ou remover estes ASN no agendamento da ferramenta, economizando tempo e evitando retrabalhos.
Sempre que possível eu busco contribuir para uma internet mais estável e segura, e por este motivo decidi abrir o código da ferramenta através do git-hub, para ser utilizada, personalizada e amadurecida por qualquer um que achar conveniente.
A ferramenta e maiores detalhes de como utiliza-la, pode ser obtida através do link: https://github.com/evandroalves28/RoutingLoopCheck
Obrigado, fui!
Artigo por: Evandro Alves