MANRS

Objetivo:

Preparar e/ou ajudar à configurar o ambiente de network de maneira segura, a fim de conseguir passar na certificação do MANRS (Mutually Agreed Norms for Routing Security) ou Normas de Acordo Mútuo para Segurança de Roteamento. Mas por que eu devo participar do MANRS? Porque fazendo isso estará contribuindo para uma Internet muito melhor para todos, tornando-a mais segura, mais robusta, limpeza do tráfego sujo, marketing positivo da sua empresa no mercado, etc. A limpeza do tráfego traz ganhos operacionais e financeiros, ganhos de tempo de pessoal de suporte, etc. É fácil e simples se certificar no MANRS? Algumas coisas sim e outras são mais complexas mas nada que um profissional de TI não consiga fazer com um certo estudo e dedicação, afinal essa é a graça e aí que está a comprovação do nosso valor no mercado.

Panorama:

Atualmente, durante a criação desse artigo, existem +6000 Sistemas Autônomos no Brasil e apenas 18 deles participam do MANRS. Muito pouco e para que tenhamos uma Internet melhor, todos precisamos fazer nossa lição de casa e participar desse projeto. Grandes players já estão fazendo sua parte. Recentemente a Microsoft virou participante conforme essa notícia.Tudo que é cobrado vai beneficiar seu AS, assim como os outros pelo mundo. Uma pergunta bem básica: você gosta de sofrer ataques de DDoS? Então não faça com os outros, o que não gostaria que fizessem com você. O que quero dizer é: não deixe que usem sua infra estrutura para promoverem DDoS pela Internet à fora. Grande parte dos ataques são executados usando técnicas de spoofing em cima do protocolo UDP para esconderem sua verdadeira origem e direcionando os ataques aos alvos que o agressor escolheu. Imagine uma carta e nela você tem o remetente e o destinatário ok? Você resolve enviar uma carta para alguém mas coloca como remetente o seu vizinho. Para quem a carta será respondida? Para você ou seu vizinho? Sim seu vizinho e é assim que funciona um ataque de amplificação por exemplo. Mas esse é apenas um dos problemas pois também sofremos com sequestros de IPs (hijacks). Estes ocorrem quando operadoras de trânsito não filtram corretamente os anúncios BGP que vão para o mundo, permitindo que um AS abaixo anuncie erradamente o prefixo pertencente à outro AS. Junto à isso ainda temos static loops, serviços vulneráveis rodando, etc.

Vamos começar?

Dois dos quatro itens avaliados pelo MANRS são relativamente tranquilos de configurarmos e indispensáveis para qualquer Sistema Autônomo. Eles são o PeeringDB e o IRR (Internet Routing Registry). O primeiro é gratuito mas o segundo eu recomendo usar o RADB. Este é pago anualmente mas vale cada centavo e possui uma interface de configuração extremamente fácil via web. Abaixo falarei sobre cada um e mostrarei exemplos de configuração para terem algo em que se basear, quando forem criar o de vocês.

PeeringDB:

O PeeringDB é uma enorme base de dados de informação sobre os Sistemas Autônomos espalhados pelo mundo. Nela colocamos informações como: contatos do NOC para resolução de problemas, quantidade de prefixos anunciados, looking glass, tipo de rede, pontos de troca de tráfego, facilities, protocolos suportados e muitas outras informações. Esse serviço é muito importante para que possamos localizar os dados de um AS, por exemplo, em caso de problemas. Nada melhor que saber pra quem ligar ou contactar e ter isso em fácil acesso. Outra que isso é indispensável para que outros Sistemas Autônomos te contacte para fechar algum peering interessante para ambas as partes. Empresas como Google, Netflix e Facebook exigem que você tenha cadastro no PeeringDB antes de qualquer negociação. Você pode iniciar seu registro aqui. Para que o cadastro do seu AS seja concluído de forma rápida e sem problemas, utilize o mesmo e-mail para registro, que consta como responsável pelo seu AS. Você pode checar isso facilmente usando o comando "whois as<número>" em um sistema que tenha whois, um Linux por exemplo, ou através de consulta web no Registro.BR mas precisa estar logado com seu usuário do RegistroBR. Abaixo umas telas exemplo:

Para ajudar na configuração do seu PeeringDB, abaixo mais telas com informações sensíveis protegidas:

IRR Internet Routing Registry:

IRR é uma base de dados distribuída e sincronizada entre algumas organizações, que mantém informações sobre políticas de roteamento de Sistemas Autônomos e que usa uma linguagem chamada Routing Policy Specification Language (RPSL). Uma lista dessas organizações que mantém o IRR funcionando, pode ser encontrada aqui. Além das políticas de roteamento também informamos nossos prefixos IPv4 e IPv6 a fim de que possam ser usados como dados nos filtros de anúncios BGP de Sistemas Autônomos de Trânsito para evitar os chamados hijacks(sequestros) de IPs. Mas para que isso dê certo, é importante que esteja sempre atualizado. Nesse artigo vou citar como exemplo e recomendação o RADB, que é um serviço pago anualmente. Lembrem-se, o IRR é um dos 4 requisitos para ser aprovado no MANRS. Para criar seu registro acesse esse link. Procure fazer todos esses registros sempre usando o e-mail que consta como responsável pelo seu AS, conforme citei mais acima. Isso evitará problemas e atrasos nos processos de validação. Abaixo algumas telas de exemplo de objetos dos registros, com informações sensíveis mascaradas. Nesse caso tenho configurado os objetos: aut-num, mntner, route e route6. Os campos admin-c e tech-c são seus IDs do RegistroBR mais o sufixo -NICBR. Os campos import são onde especificamos o que aceitamos das nossas operadoras de trânsito, nesse caso ANY e nos campos export o que estamos anunciando para os nossos neighbors, ou seja, nosso próprio AS e/ou outros Sistemas Autônomos para os quais somos trânsito.

Lembra que comentei sobre os filtros de anúncios BGP? Todo AS de trânsito tem a obrigação de cuidar para que seus clientes, que também são Sistemas Autônomos, não façam anúncios errados para a Internet. Quando isso ocorre e o anúncio passa, acontece o que chamamos de Hijack (sequestro) de IP, derrubando todos os Sistemas Autônomos envolvidos no prefixo anunciado erradamente. Poucos dias atrás sofremos um Hijack de um AS que simplesmente anunciou como sendo dele o prefixo 186.0.0.0/8. Agora imagina quantas empresas que possuem prefixo que começa com 186.x.x.x, tiveram problemas. Se você é trânsito para alguém, existe uma ferramenta bem legal que roda em Linux chamada bgpq3 e que pode ser usada para fazer consultas IRR em um AS. Essa ferramenta retorna prefix-lists, extended access-lists, policy-statement terms e as-path lists já formatados de alguns fabricantes (Cisco e Juniper) e desenvolvedores de software de roteamento BGP (OpenBGP e BIRD). Em distribuições Linux like Debian, basta apenas instalar com o comando: apt install bgpq3

Um exemplo de saída do comando bgpq3 consultando um AS. Os prefixos estão mascarados por segurança:

Basta estudar a ferramenta e integrá-la com seus equipamentos para tentar automatizar o processo. Por padrão as saídas são no formato Cisco. Abaixo um exemplo em Juniper:

Perceberam a utilidade desse programa? Se você for um AS de trânsito converse com seus clientes e convença-os de terem um registro de IRR sempre atualizado, pois é uma excelente maneira de evitarmos problemas com anúncios BGP por erro humano.

Outro recurso que aconselho à todo AS utilizar é o Radar Qrator. Faça um registro nele, cadastre seu AS e periodicamente você receberá e-mails com relatórios sobre problemas encontrados como: serviços vulneráveis dentro da sua rede, hijacks, static loops e outros. Ele é muito útil no diagnóstico de problemas de segurança, te deixando ciente dos problemas e cabendo à você resolvê-los.

Filtrando anúncios BGP:

Nesse ponto se você fez seu registro no PeeringDB e no RADB, então 50% do MANRS já está garantido.Eles equivalem aos itens 3 e 4 solicitados. Agora veremos o primeiro item solicitado que é justamente como você trata os anúncios BGP do seu AS. Se você for trânsito para outros Sistemas Autônomos, garanta através de filtros, que somente passarão anúncios corretos para a Internet. Não aceite qualquer anúncio de seu cliente e assim evitará os conhecidos Hijacks. Isso é um verdadeiro crime contra a nossa grande comunidade. Todo AS de trânsito que permitisse um vazamento como esse, deveria ser penalizado de alguma forma. Com a ferramenta demonstrada acima pode-se tentar implementar algo mais automático mas mesmo não o fazendo, deve-se preocupar em filtrar os anúncios, pois isso será pedido pelo pessoal do MANRS. Normalmente eles te solicitam as regras que está usando para avaliar. Abaixo mostrarei um exemplo simples no Juniper de uma configuração de sessão BGP com uma Operadora, logicamente que você precisará modificar para a sua necessidade:

set protocols bgp group K5-V4 type external

set protocols bgp group K5-V4 description K5_LinkIP

set protocols bgp group K5-V4 import K5-IMPORT

set protocols bgp group K5-V4 family inet unicast

set protocols bgp group K5-V4 export PREFIXOS_PARA_K5_V4

set protocols bgp group K5-V4 peer-as XXXXX

set protocols bgp group K5-V4 neighbor 191.XXX.XXX.1 local-address 191.XXX.XXX.2

set protocols bgp group K5-V6 type external

set protocols bgp group K5-V6 description K5_LinkIP

set protocols bgp group K5-V6 import K5-IMPORT

set protocols bgp group K5-V6 family inet6 unicast

set protocols bgp group K5-V6 export PREFIXOS_PARA_K5_V6

set protocols bgp group K5-V6 peer-as XXXXX

set protocols bgp group K5-V6 neighbor 2804:XXXX:XXXX:XXXX::71 local-address 2804:XXXX:XXXX:XXXX::72

set policy-options policy-statement K5-IMPORT term A from protocol bgp

set policy-options policy-statement K5-IMPORT term A from neighbor 191.XXX.XXX.1

set policy-options policy-statement K5-IMPORT term B from protocol bgp

set policy-options policy-statement K5-IMPORT term B from neighbor 2804:XXXX:XXXX:XXXX::71

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from family inet

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 186.XXX.XXX.0/21 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 186.XXX.XXX.0/21 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 177.XXX.XXX.0/22 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 177.XXX.XXX.0/22 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 177.XXX.XXX.0/22 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 177.XXX.XXX.0/22 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 138.XXX.XXX.0/23 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 138.XXX.XXX.0/23 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 186.XXX.XXX.0/20 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 168.XXX.XXX.0/23 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 168.XXX.XXX.0/23 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 131.XXX.XXX.0/23 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 131.XXX.XXX.0/23 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 170.XXX.XXX.0/23 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 170.XXX.XXX.0/23 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A from route-filter 191.XXX.XXX.0/20 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V4 term A then accept

set policy-options policy-statement PREFIXOS_PARA_K5_V4 then reject

set policy-options policy-statement PREFIXOS_PARA_K5_V6 term A from family inet6

set policy-options policy-statement PREFIXOS_PARA_K5_V6 term A from route-filter 2804:XXXX::/33 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V6 term A from route-filter 2804:XXXX:8000::/33 exact

set policy-options policy-statement PREFIXOS_PARA_K5_V6 term A then accept

set policy-options policy-statement PREFIXOS_PARA_K5_V6 then reject

Com as regras acima estou demonstrando que somente estou anunciando prefixos do meu AS e rejeitando o restante. Você precisará ter algo semelhante em sua caixa BGP. Mostrar ao pessoal do MANRS que você filtra os anúncios, pois tem cuidado com o que é exportado para a Internet. Fazendo isso passará pelo primeiro item de check do MANRS. Até aqui tranquilo? Estamos quase lá.

Bloqueio de Spoofing:

Spoofing é uma técnica utilizada para esconder o verdadeiro IP de origem de um pacote, trocando-o por um outro qualquer. Dependendo do tipo de ataque o IP de origem é substituído pelo IP da vítima. Um exemplo desse tipo de ataque é o DDoS amplificado. O Spoofing é o maior mal que assola a Internet nos dias de hoje. Se todo ISP, Operadora e Data Center no mundo bloqueassem o Spoofing, com certeza teríamos uma Internet muito mais segura e livre de muitos problemas. Vamos ver alguns exemplos e entender como é o comportamento disso. Vamos observar o diagrama abaixo:

No diagrama acima o Dispositivo A envia um pacote para o Dispositivo B. Até aqui tudo bem mas o Dispositivo A utilizou a técnica de spoofing e alterou o seu IP origem do pacote de 172.16.0.2 para 1.1.1.1. Tendo em mente isso, faço as seguintes perguntas:

• O Router A conseguiria detectar esse spoofing e bloqueá-lo para que não chegasse no Router B?
• No caso do pacote chegar no Router B, este conseguiria detectar o spoofing e impedir que o pacote chegasse no Dispositivo B?

Para a primeira pergunta a resposta é sim. Como o Router A conhece a sub-rede da qual o Dispositivo A faz parte, então este pode aplicar um filtro para bloquear o pacote forjado, deixando o tráfego mais limpo. Para a segunda pergunta infelizmente é não. Porque o Router B não conhece a sub-rede atrás do Router A e por isso não pode garantir que 1.1.1.1 seja um IP forjado. É por isso que o primeiro lugar que teremos que fazer os bloqueios de anti-spoofing, é dentro da nossa própria rede e também por esse motivo que precisamos que todos na Internet pratiquem essa boa prática. Só assim conseguiremos parar ou diminuir esse tipo de ataque. Quanto mais pessoas aderirem, mais seguros ficaremos.

Vamos pegar um exemplo de situação real e analisar o quanto isso pode te afetar. Abaixo uma imagem bem conhecida em palestras sobre segurança da informação:

Essa é uma situação bem comum de se encontrar pela Internet. Algumas CPEs de determinados fabricantes vem com serviço de DNS aberto, as vezes técnicos de TI na busca de configurarem um DNS recursivo, acabam deixando o serviço aberto não só para a sua rede mas também para todo o mundo, outros dispositivos que podem vir com o DNS aberto e também servidores de DNS autoritativos mal configurados permitindo recursividade para qualquer um. Enfim o fato é que existem muitas portas 53/udp abertas por aí.

Funciona assim: o atacante já possui um servidor de DNS comprometido ou que ele mesmo resolveu criar em algum Data Center qualquer. Ele cria um registro TXT muito grande no DNS dele, para gerar volume nas consultas. Feito isso ele forja o IP origem colocando o IP da vítima, como se ela estivesse consultando, e envia milhares e milhares de consultas do registro TXT para toda a sua rede de DNS recursivo aberta. Todo o volume dessa consulta passa à ser respondida para o IP da vítima. O ataque acima é de amplificação e pode ser amplificado em até 54x o tráfego inicial das consultas, segundo a CISA. Agora pense comigo, se o ISP do atacante bloqueasse spoofing dentro de sua infra estrutura, esse ataque aconteceria? Não porque ele não conseguiria sair para a Internet com o seu IP origem forjado. Por isso que todos nós precisamos criar essa política anti-spoofing em nossas redes para limpar nosso tráfego, limpar a Internet.

Agora que entendemos a importância disso vamos começar os trabalhos. :)

As técnicas de anti-spoofing devem ser aplicadas em 2 lugares ao meu ver e explicarei cada uma delas: na Borda e nos B-RAS. Mas por que Gondim? Existem bloqueios através de features dos sistemas, existem bloqueios por filtro de pacotes e bloqueios que se misturam. Explicando você vai entender.

Anti-spoofing na Borda:

De forma direta o que precisamos bloquear na Borda do AS?

• Não deixar ir para a Internet, qualquer tráfego cuja origem não seja de algum prefixo IP seu vindo de sua rede. Por que de sua rede? Porque se você for trânsito para alguém, deveria conversar com seu cliente e orientar à ele fazer o mesmo na rede dele ou melhor, incentivar ele à participar do MANRS.
• Não permitir tráfego de BOGONS vindo dos seus Sistemas Autônomos vizinhos. A CYMRU possui um serviço bem interessante mas trabalha apenas na tabela de rotas. Abaixo o que precisamos filtrar na entrada dos nossos Sistemas Autônomos vizinhos:

• • 0.0.0.0/8 [RFC1122]
  • 10.0.0.0/8 [RFC1918]
  • 100.64.0.0/10 [RFC6598]
  • 127.0.0.0/8 [RFC1122]
  • 169.254.0.0/16 [RFC3927]
  • 172.16.0.0/12 [RFC1918]
  • 192.0.2.0/24 [RFC5737]
  • 192.168.0.0/16 [RFC1918]
  • 198.18.0.0/15 [RFC2544]
  • 198.51.100.0/24 [RFC5737]
  • 203.0.113.0/24 [RFC5737]
  • 224.0.0.0/4 "multcast"
  • 240.0.0.0/4 "reserved for future use"
  • ::/8
  • 0100::/64 [RFC6666]
  • 2001:2::/48 [RFC5180]
  • 2001:10::/28 [RFC4843]
  • 2001:db8::/32 [RFC3849]
  • 3ffe::/16 "Old 6bone"
  • fc00::/7 "unique local unicast"
  • fec0::/10 "old site local unicast"
  • ff00::/8 "multicast"
• Finalmente não permitir tráfego vindo dos seus Sistemas Autônomos vizinhos, cuja origem do tráfego seja um IP de um prefixo seu. Esse aqui é o que mais falha nos testes do MANRS de pessoas que me pediram ajuda. Muita gente não implementa esse filtro que nada mais faz que bloquear alguém tentando se fazer passar por você mesmo, enviando pacotes pra você mesmo. Na Borda só precisamos disso. Vou mostrar uns exemplos abaixo em Juniper e para o pessoal que usa FRR com Linux, em Netfilter/iptables. mas tenha em mente que você precisa modificar para a sua necessidade.