MANRS

De Wiki BPF
Revisão de 15h07min de 29 de junho de 2019 por Gondim (discussão | contribs)
Ir para navegação Ir para pesquisar

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:

Registro.br.png
Tela2 whois.png

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

Tela3.png
Tela4.png

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.

Tela5.png
Tela6.png
Tela7.png
Tela8.png

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:

Tela10.png

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:

Tela11.png
Tela12.png

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.

Tela9.png

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:

Tela13.png

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:

Dns-amp-attack.png

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ê 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 deixamos entrar pacotes com IP de origem que não seja de algum prefixo nosso:

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. Isso ajuda no processamento da caixa. De posse desses dados vamos por a mão na massa:

# 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

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:

Disponível em “https://wiki.brasilpeeringforum.org/index.php?title=MANRS&oldid=947”