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

Até essa data 10/12/2019, existem +7000 Sistemas Autônomos no Brasil e apenas 33 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:

É de muita importância que seus dados de contato também estejam atualizado via whois. Outra coisa que muitos não adicionam no Registro.BR são as informações de AS-in e AS-out, ou seja, o que você está aceitando de anúncios de quem e o que está sendo anunciado pra quem. No PeeringDB eles também serão informados.

Agora vamos para o PeeringDB e 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.

Agora que você já fez seu registro IRR, volte no seu PeeringDB e atualize o campo Registro de IRR.

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 podem ser aplicadas em 2 lugares ao meu ver e explicarei cada uma delas: na Borda e nos B-RAS. Existem bloqueios através de features dos sistemas, existem bloqueios por filtro de pacotes e bloqueios que usam ambos. Explicando você 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. Se você tiver 100% de certeza que todo o tráfego de sua rede passou por um anti-spoofing antes de chegar no seu router, então você poderá desprezar esse filtro.
• 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ê precisará modificar para a sua necessidade.

Exemplo Juniper

Esse primeiro bloco é um exemplo de interface conectada à um Link IP de saída para a Internet. Nela bloqueamos os BOGONS e pacotes que entrem com o nosso próprio IP na origem:

set interfaces xe-0/1/2 unit 1512 description LinkIP

set interfaces xe-0/1/2 unit 1512 vlan-id 1512

set interfaces xe-0/1/2 unit 1512 family inet filter input BOGONS-BLOCOS-PROVEDOR_V4

set interfaces xe-0/1/2 unit 1512 family inet address 189.xxx.xxx.70/30

set interfaces xe-0/1/2 unit 1512 family inet6 filter input BOGONS-BLOCOS-PROVEDOR_V6

set interfaces xe-0/1/2 unit 1512 family inet6 address 2804:xxxx:xxxx:xxxx::56/126

Abaixo temos o bloco da interface conectada com a rede de assinantes. Aqui não deixaremos entrar pacotes com IP de origem que não seja de algum prefixo nosso. Se você já garantiu de alguma forma que todo o tráfego que chegue aqui não possa ser forjado, então pode desprezar esse filtro:

set interfaces et-0/0/3 unit 2126 description Rede-Assinantes

set interfaces et-0/0/3 unit 2126 vlan-id 2126

set interfaces et-0/0/3 unit 2126 family inet filter input BLOCOS-PROVEDOR_V4

set interfaces et-0/0/3 unit 2126 family inet address 186.xxx.xxx.1/27

set interfaces et-0/0/3 unit 2126 family inet6 filter input BLOCOS-PROVEDOR_V6

set interfaces et-0/0/3 unit 2126 family inet6 address 2804:xxxx:xxxx::1/64

Nesse próximo bloco definimos a lista com nossos prefixos IP (IPv4/IPv6) designados para o nosso AS:

set policy-options prefix-list BLOCOS_V4 131.xxx.xxx.0/22

set policy-options prefix-list BLOCOS_V4 138.xxx.xxx.0/22

set policy-options prefix-list BLOCOS_V4 168.xxx.xxx.0/22

set policy-options prefix-list BLOCOS_V6 2804:xxxx::/32

Bloco dos BOGONS IPv4 e IPv6:

set policy-options prefix-list BLOCOS_BOGONS_V4 0.0.0.0/8

set policy-options prefix-list BLOCOS_BOGONS_V4 10.0.0.0/8

set policy-options prefix-list BLOCOS_BOGONS_V4 100.64.0.0/10

set policy-options prefix-list BLOCOS_BOGONS_V4 127.0.0.0/8

set policy-options prefix-list BLOCOS_BOGONS_V4 169.254.0.0/16

set policy-options prefix-list BLOCOS_BOGONS_V4 172.16.0.0/12

set policy-options prefix-list BLOCOS_BOGONS_V4 192.0.2.0/24

set policy-options prefix-list BLOCOS_BOGONS_V4 192.168.0.0/16

set policy-options prefix-list BLOCOS_BOGONS_V4 198.18.0.0/15

set policy-options prefix-list BLOCOS_BOGONS_V4 198.51.100.0/24

set policy-options prefix-list BLOCOS_BOGONS_V4 203.0.113.0/24

set policy-options prefix-list BLOCOS_BOGONS_V4 224.0.0.0/4

set policy-options prefix-list BLOCOS_BOGONS_V4 240.0.0.0/4

set policy-options prefix-list BLOCOS_BOGONS_V6 ::/8

set policy-options prefix-list BLOCOS_BOGONS_V6 0100::/64

set policy-options prefix-list BLOCOS_BOGONS_V6 2001:2::/48

set policy-options prefix-list BLOCOS_BOGONS_V6 2001:10::/28

set policy-options prefix-list BLOCOS_BOGONS_V6 2001:db8::/32

set policy-options prefix-list BLOCOS_BOGONS_V6 3ffe::/16

set policy-options prefix-list BLOCOS_BOGONS_V6 fc00::/7

set policy-options prefix-list BLOCOS_BOGONS_V6 fec0::/10

set policy-options prefix-list BLOCOS_BOGONS_V6 ff00::/8

Aqui temos as regras de filtragem em si. Aqui dizemos o seguinte: o que forem nossos prefixos IPv4 e IPv6, accept e o restante discard neles:

set firewall family inet filter BLOCOS-PROVEDOR_V4 term 1 from source-prefix-list BLOCOS_V4

set firewall family inet filter BLOCOS-PROVEDOR_V4 term 1 then accept

set firewall family inet filter BLOCOS-PROVEDOR_V4 term 2 then discard

set firewall family inet6 filter BLOCOS-PROVEDOR_V6 term 1 from source-prefix-list BLOCOS_V6

set firewall family inet6 filter BLOCOS-PROVEDOR_V6 term 1 then accept

set firewall family inet6 filter BLOCOS-PROVEDOR_V6 term 2 then discard

Esses filtros abaixo são para as interfaces públicas. Dizem o seguinte: o que forem origem nossos IPs e BOGONS, discard e o restante accept:

set firewall family inet filter BOGONS-BLOCOS-PROVEDOR_V4 term 1 from source-prefix-list BLOCOS_V4

set firewall family inet filter BOGONS-BLOCOS-PROVEDOR_V4 term 1 from source-prefix-list BLOCOS_BOGONS_V4

set firewall family inet filter BOGONS-BLOCOS-PROVEDOR_V4 term 1 then discard

set firewall family inet filter BOGONS-BLOCOS-PROVEDOR_V4 term 2 then accept

set firewall family inet6 filter BOGONS-BLOCOS-PROVEDOR_V6 term 1 from source-prefix-list BLOCOS_V6

set firewall family inet6 filter BOGONS-BLOCOS-PROVEDOR_V6 term 1 from source-prefix-list BLOCOS_BOGONS_V6

set firewall family inet6 filter BOGONS-BLOCOS-PROVEDOR_V6 term 1 then discard

set firewall family inet6 filter BOGONS-BLOCOS-PROVEDOR_V6 term 2 then accept

Exemplo Netfilter/IPTables

Estarei usando o Debian nos exemplos mas qualquer Distribuição Linux poderá executar as regras abaixo. Lembrando que farei apenas comentários sobre regras de filtro e não sobre tunigs necessários para configuração de um router. Existe um pacote chamado ipset no Debian que nos permitirá criarmos listas de prefixos para nossos bloqueios. No exemplo a interface bond0 será a interface que fala diretamente com a rede de assinantes e a interface enp66s0f0 fechará uma sessão BGP com uma Operadora pra lhe fornecer o Link IP IPv4/IPv6 para falar com o mundo. Outro detalhe: procure trabalhar as regras de DROP na chain PREROUTING da table raw. Não use NAT no router e pelo amor de Deus desabilite o nf_conntrack, isso mesmo não use regras stateful no seu router. Isso ajuda no processamento da caixa. De posse desses dados vamos por a mão na massa.

Para desabilitar o nf_conntrack, execute o comando abaixo e reinicie o sistema. ATENÇÃO! Ao fazer isso estará desabilitando o NAT e qualquer regra de stateful no seu sistema:

# echo "install nf_conntrack /bin/true" > /etc/modprobe.d/nf_conntrack.conf

Instalando o pacote ipset no Debian:

# apt install ipset

Após a instalação criamos as listas assim:

# ipset create blocosv4 hash:net family inet comment

# ipset create blocosv6 hash:net family inet6 comment

# ipset create bogonsv4 hash:net family inet comment

# ipset create bogonsv6 hash:net family inet6 comment

Sempre antes de usarmos as listas, precisaremos criá-las. Por isso coloque esses comandos acima para serem executados sempre que houver um restart do servidor. Agora vamos ao script:

#!/bin/bash

IPTABLES="`type -p iptables`"

IP6TABLES="`type -p ip6tables`"

LO_IFACE="lo"

IPSET="`type -p ipset`"

#

$IPSET flush blocosv4

$IPSET flush blocosv6

$IPSET flush bogonsv4

$IPSET flush bogonsv6

#

$IPSET add bogonsv4 0.0.0.0/8 comment "this network [RFC1122]"

$IPSET add bogonsv4 10.0.0.0/8 comment "private space [RFC1918]"

$IPSET add bogonsv4 100.64.0.0/10 comment "CGN Shared [RFC6598]"

$IPSET add bogonsv4 127.0.0.0/8 comment "localhost [RFC1122]"

$IPSET add bogonsv4 169.254.0.0/16 comment "link local [RFC3927]"

$IPSET add bogonsv4 172.16.0.0/12 comment "private space [RFC1918]"

$IPSET add bogonsv4 192.0.2.0/24 comment "TEST-NET-1 [RFC5737]"

$IPSET add bogonsv4 192.168.0.0/16 comment "private space [RFC1918]"

$IPSET add bogonsv4 198.18.0.0/15 comment "benchmarking [RFC2544]"

$IPSET add bogonsv4 198.51.100.0/24 comment "TEST-NET-2 [RFC5737]"

$IPSET add bogonsv4 203.0.113.0/24 comment "TEST-NET-3 [RFC5737]"

$IPSET add bogonsv4 224.0.0.0/4 comment "multcast"

$IPSET add bogonsv4 240.0.0.0/4 comment "reserved for future use"

#

$IPSET add bogonsv6 ::/8 comment "BOGONS"

$IPSET add bogonsv6 0100::/64 comment "Discard-Only [RFC6666]"

$IPSET add bogonsv6 2001:2::/48 comment "BMWG [RFC5180]"

$IPSET add bogonsv6 2001:10::/28 comment "ORCHID [RFC4843]"

$IPSET add bogonsv6 2001:db8::/32 comment "docu range [RFC3849]"

$IPSET add bogonsv6 3ffe::/16 comment "Old 6bone"

$IPSET add bogonsv6 fc00::/7 comment "unique local unicast"

$IPSET add bogonsv6 fec0::/10 comment "old site local unicast"

$IPSET add bogonsv6 ff00::/8 comment "multicast"

#

$IPSET add blocosv4 131.xxx.xxx.0/22 comment "Blocos do Provedor"

$IPSET add blocosv4 138.xxx.xxx.0/22 comment "Blocos do Provedor"

$IPSET add blocosv4 168.xxx.xxx.0/22 comment "Blocos do Provedor"

$IPSET add blocosv6 2804:xxxx::/32 comment "Blocos do Provedor"

#

$IPTABLES -t raw -P OUTPUT ACCEPT

$IPTABLES -t raw -P PREROUTING ACCEPT

$IPTABLES -t filter -P INPUT ACCEPT

$IPTABLES -t filter -P FORWARD ACCEPT

$IPTABLES -t filter -P OUTPUT ACCEPT

$IPTABLES -t mangle -P PREROUTING ACCEPT

$IPTABLES -t mangle -P POSTROUTING ACCEPT

$IPTABLES -t mangle -P INPUT ACCEPT

$IPTABLES -t mangle -P OUTPUT ACCEPT

$IPTABLES -t mangle -P FORWARD ACCEPT

$IP6TABLES -t raw -P OUTPUT ACCEPT

$IP6TABLES -t raw -P PREROUTING ACCEPT

$IP6TABLES -t filter -P INPUT ACCEPT

$IP6TABLES -t filter -P FORWARD ACCEPT

$IP6TABLES -t filter -P OUTPUT ACCEPT

$IP6TABLES -t mangle -P PREROUTING ACCEPT

$IP6TABLES -t mangle -P POSTROUTING ACCEPT

$IP6TABLES -t mangle -P INPUT ACCEPT

$IP6TABLES -t mangle -P OUTPUT ACCEPT

$IP6TABLES -t mangle -P FORWARD ACCEPT

#

$IPTABLES -t raw -F

$IPTABLES -t mangle -F

$IPTABLES -t filter -F

$IPTABLES -t raw -X

$IPTABLES -t mangle -X

$IPTABLES -t filter -X

$IPTABLES -t raw -Z

$IPTABLES -t mangle -Z

$IPTABLES -t filter -Z

$IP6TABLES -t raw -F

$IP6TABLES -t mangle -F

$IP6TABLES -t filter -F

$IP6TABLES -t raw -X

$IP6TABLES -t mangle -X

$IP6TABLES -t filter -X

$IP6TABLES -t raw -Z

$IP6TABLES -t mangle -Z

$IP6TABLES -t filter -Z

#

$IP6TABLES -t raw -A PREROUTING -s fe80::/64 -j ACCEPT

#

# Bloqueando pacotes que venham da Internet cujo IP origem seja algum BOGON

$IPTABLES -t raw -A PREROUTING -m set --match-set bogonsv4 src -i enp66s0f0 -j DROP

$IP6TABLES -t raw -A PREROUTING -m set --match-set bogonsv6 src -i enp66s0f0 -j DROP

#

# Bloqueando pacotes que venham da Internet cujo IP origem seja você mesmo

# Nao esqueca de liberar as conexões de sessão BGP (179/tcp) caso esteja usando algum IP seu para fechar a sessão. Mas normalmente a operadora quem cede os IPs da sessão.

$IPTABLES -t raw -A PREROUTING -m set --match-set blocosv4 src -i enp66s0f0 -j DROP

$IP6TABLES -t raw -A PREROUTING -m set --match-set blocosv6 src -i enp66s0f0 -j DROP

#

# Bloqueando pacotes da rede de Assinantes cujo IP origem seja diferente de algum IP dos seus prefixos.

$IPTABLES -t raw -A PREROUTING -m set ! --match-set blocosv4 src -i bond0 -j DROP

$IP6TABLES -t raw -A PREROUTING -m set ! --match-set blocosv6 src -i bond0 -j DROP

Com a chegada de novas versões das maiores Distribuições Linux, faz-se necessário começar à aprender sobre o nf_tables, que é o sucessor do x_tables. Esse recurso usa o aplicativo nft no lugar do iptables, embora existam ferramentas iptables que convertem suas regras iptables para o nftables. Criar suas regras em nftables é muito mais simples que no iptables, sem falar que vamos usar um novo recurso que é a table netdev que é 2x mais rápido em processamento que a table raw do iptables. A netdev não existe no iptables e os pacotes são avaliados antes da camada 3. Outro detalhe é que o nftables não é compatível com o ipset mas podemos criar listas dentro do nosso script sem a necessidade dele. Vamos olhar como seriam as regras acima no formato novo:

#!/usr/sbin/nft -f

flush ruleset

define bogons_v4 = { 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.2.0/24, 192.168.0.0/16, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 240.0.0.0/4 }

define bogons_v6 = { ::/8, 0100::/64, 2001:2::/48, 2001:10::/28, 2001:db8::/32, 3ffe::/16, fc00::/7, fec0::/10, ff00::/8 }

define blocosv4asn = { 131.xxx.xxx.0/22, 138.xxx.xxx.0/22, 168.xxx.xxx.0/22 }

define blocosv6asn = 2804:xxxx::/32

add table netdev filter

add chain netdev filter enp66s0f0 { type filter hook ingress device enp66s0f0 priority 0; policy accept; }

add rule netdev filter enp66s0f0 ip6 saddr fe80::/64 counter accept

# Bloqueando pacotes que venham da Internet cujo IP origem seja algum BOGON

add rule netdev filter enp66s0f0 ip saddr $bogons_v4 counter drop

add rule netdev filter enp66s0f0 ip6 saddr $bogons_v6 counter drop

# Bloqueando pacotes que venham da Internet cujo IP origem seja você mesmo

# Nao esqueca de liberar as conexões de sessão BGP (179/tcp) caso esteja usando algum IP seu para fechar a sessão. Mas normalmente a operadora quem cede os IPs da sessão.

add rule netdev filter enp66s0f0 ip saddr $blocosv4asn counter drop

add rule netdev filter enp66s0f0 ip6 saddr $blocosv6asn counter drop

add chain netdev filter bond0 { type filter hook ingress device bond0 priority 0; policy accept; }

add rule netdev filter bond0 ip6 saddr fe80::/64 counter accept

# Bloqueando pacotes da rede de Assinantes cujo IP origem seja diferente de algum IP dos seus prefixos.

add rule netdev filter bond0 ip saddr != $blocosv4asn counter drop

add rule netdev filter bond0 ip6 saddr != $blocosv6asn counter drop

Anti-spoofing no B-RAS

Existe um recurso chamado Reverse Path Filtering que faz a seguinte mágica: bloqueia spoofing, isso mesmo. Qualquer pacote que chega no sistema, ele checa se aquele IP de origem pode ser roteado de volta por onde ele veio e se não puder, ele descarta o pacote. Muitos fabricantes inclusive já habilitam por default este recurso dependendo do uso da caixa. É um recurso muito importante e vou mostrar aqui como habilitar em uma caixa Mikrotik e como habilitar em um Linux. Imagine o seguinte: você tem distribuído diversas caixas Mikrotik fazendo PPPoE (concentradores) e em cada uma delas iremos habilitar esse recurso. Só cuidado com uma coisa: se tiver usando marcação de pacotes para influenciar um tráfego, por exemplo para um servidor CGNAT, você terá problemas com RPF no modo strict. Para resolver o problema, mude para PBR (Policy Based Routing) ou use o RPF no modo loose. Eu sugiro você mudar para PBR mas isso já é papo para outro artigo. Consulte o fabricante do seu equipamento sobre esse recurso e como habilitá-lo.

RPF no RouterOS

No RouterOS é muito simples habilitar o RPF, faça isso nos seus concentradores PPPoE. Abaixo a tela mostrando onde habilitar:

Ou simplesmente execute o comando abaixo no terminal do RouterOS:

/ip settings

set rp-filter=strict

RPF no Linux

No Linux é bem simples habilitar esse recurso quando falamos de IPv4 mas para fazer o mesmo em IPv6 é um pouco diferente e depois de garimpar na Internet um tempo atrás, encontrei.

Para IPv4 basta habilitar seguinte sysctl:

net.ipv4.conf.all.rp_filter=1

Já para fazer isso no IPv6 existe uma outra técnica utilizando o Netfilter/IPTables. Aqui uma referência da própria RedHat sobre isso. Basta usar o seguinte comando:

# ip6tables -t raw -A PREROUTING -m rpfilter --invert -j DROP

Na reta da linha de chegada

Se você chegou até aqui e não jogou a toalha no chão, então você está de parabéns pela força de vontade e empenho. Chegou a hora de testar o seu ambiente e saber se está tudo implementado corretamente. Vamos usar para isso um software chamado Spoofer da CAIDA. Esse software foi criado justamente para testar se uma rede está permitindo tráfego de pacotes forjados. O MANRS vai te solicitar esse teste então já podemos preparar um ambiente e testar. Você vai precisar de um equipamento com um Windows ou Ubuntu Linux ou um Mac OSX. Você vai precisar fazer esse teste de 2 segmentos de rede diferentes, o pessoal do MANRS te pede isso. O Spoofer deve ser rodado de um sistema que está diretamente conectado à Internet sem a utilização de NAT. Se sua rede suporta IPv4 e IPv6 configure as duas no seu equipamento de teste. Após os testes eles gerarão links com os relatórios. Abaixo um exemplo de quando você faz o teste atrás de NAT. Você não pode estar atrás de NAT algum, para validar o teste:

Agora um exemplo de relatório que passaria no MANRS. Esse por um acaso é referente ao AS do NIC.BR:

Se possível faça um diagrama de rede mostrando de onde estão sendo feitos os testes com o Spoofer para demonstrar que são de segmentos de rede diferentes. Junte isso com os reports gerados pelo Spoofer para enviar pro pessoal do MANRS quando for solicitado.

Finalmente depois de tudo concluído e devidamente testado, você pode acessar esse link e solicitar ser um participante do MANRS. Caso esse artigo venha lhe ajudar à ingressar no MANRS, eu ficaria muito feliz em receber um feedback seu por e-mail.

Autor: Marcelo Gondim