Infelizmente, nos dias de hoje, é muito comum ataque DDoS.
Se você tem ASN e ainda não levou ataque, calma... a única certeza é que esse momento chegará para você também.
Existem muitas pessoas de má fé na internet.
Por estar há muito tempo trabalhando nessa área, já escutei rumores de práticas de DDoS entre ISPs de uma mesma região.
Uma das práticas ocorre no início de mês, que geralmente é o vencimento da mensalidade do serviço prestado.
Um outro player contrata um ataque DDoS, causando intermitência de navegação, indisponibilidades e acaba por gerar instatisfação sobre o serviço prestado.
Ou seja, a intenção do ataque é tentar arrecadar os clientes do concorrente.
É a triste realidade do mercado brasileiro.
Esse artigo tem como foco principal explicar o comportamento do junos ao exportar alguns tipos de prefixos do que com o DDoS em si. Hoje em dia, existem empresas que vendem solução de mitigação de DDoS, onde o tráfego é analisado e tratado em um scrubbing center, que é menos intrusivo do que descartar totalmente o tráfego de um IP do seu ASN.
Antes de começarmos, estou supondo que você leu a RFC6192 [1] e já tem algum filtro do tipo "PROTECT-RE".
É imprescindível ter esse filtro aplicado em roteadores que estão em produção, descartando tráfego indesejado direcionado à Control-Plane da sua caixa.
Agora focando na parte técnica, existem algumas formas de minimizar o impacto de um DDoS.
Uma delas é manter a estabilidade da caixa durante um evento desse porte.
Manter a control-plane do roteador operando sem quedas de BGP é imprescindível nesse momento.
Algumas coisas que você terá de validar antes de começar:
- Sua(s) operadora(s) aceita(m) anúncios blackhole?
- Está habilitado juntamente na sua sessão BGP de trânsito ou é uma sessão separada apenas para blackhole?
- Qual o limite de prefixos que está liberado na sua sessão BGP?
- Qual é a community BGP que a operadora exige que marque no prefixo?
Eis a topologia desse lab, mais simples impossível.
É apenas uma sessão BGP entre dois routers, simulando um upstream para validação dos anúncios.
Primeiramente, vamos verificar qual é o comportamento do Junos e como exportar esses endereços locais.
Os IPs da caixa são considerados "protocol local", você pode validar com o comando:
Repare que todos os IPs da caixa já estão com a máscara /32, o que facilita muito exportá-los para blackhole.
No juniper, todo tipo de anúncio BGP é feito via policy.
Então vamos montar uma policy simples para exportá-los:
Repare aqui na policy que estou filtrando exatamente o que eu quero que seja anunciado, evitando que vaze algum prefixo indevidamente, como a loopback, por exemplo.
Vamos aplicar a policy na sessão BGP para exportar os prefixos:
Notaram que, apesar da policy estar aplicada corretamente na sessão BGP, o Junos não está exportando os prefixos? Por padrão, o Junos não envia os prefixos do tipo "local". É necessário que a gente altere o comportamento padrão dele, cfe abaixo:
Logo após o commit, os prefixos já estão sendo exportados, como podemos verificar:
Perfeito!
Essa é a teoria por trás de como habilitar o export dos prefixos "protocol local" no Juniper.
Agora vamos colocar isso em prática.
Vamos simular que esse ISP está conectado ao IX.br.
O material necessário está no site: https://ix.br/documentacao.
A documentação da utilização está na página 4 do documento abaixo:
https://docs.ix.br/doc/politica-de-tratamento-de-communities-no-ix-br-v4_3.pdf.
A tabela completa está no documento abaixo:
https://docs.ix.br/doc/communities-table-ix-br-v2_1-14082024.pdf.
Procurem por "BH announce" (anúncio para blackhole), na tabela consta como sendo a community 65535:666.
Com essa informação, mãos à obra.
Primeiro passo é marcar a community exigida no IX.br para que os route-servers passem a aceitar os anúncios.
A policy de export já está marcando a community BGP nos anúncios, vamos validar se eles já estão sendo exportados ao neighbor:
Parece promissor!
Agora você pode utilizar a ferramenta de looking glass do IX.br para validar se os seus anúncios estão sendo aceitos por lá.
Se por acaso a sessão BGP cair após você incluir os anúncios de blackhole, é muito provável que o limite de prefixos esteja apertado. É necessário que você abra um ticket para aumento do limite.
Uma outra boa prática é manter seu PeeringDB atualizado. Lá existe um campo específico para você informar quantos prefixos v4 e v6 o seu ASN poderá exportar no máximo, aqui você deve considerar seus prefixos de blackhole.
Espero que esse artigo tenha sido útil de alguma forma.
Obrigado.
--
Referências:
[1] https://www.rfc-editor.org/rfc/rfc6192.html, apêndice A.2.
[2] https://ix.br/documentacao
[3] https://docs.ix.br/doc/politica-de-tratamento-de-communities-no-ix-br-v4_3.pdf
[4] https://docs.ix.br/doc/communities-table-ix-br-v2_1-14082024.pdf
[5] https://lg.ix.br/
[6] https://www.peeringdb.com/
[7] Mais boas práticas em https://bcp.nic.br/
Top comments (0)