BGP Security: Validação RPKI contra Hijacks
Após quase trinta anos após a sua especificação inicial, podemos sem dúvida afirmar que o BGP é o protocolo de roteamento mais amplamente utilizado e versátil que existe atualmente.
Seguindo uma lógica Path Vector, o BGP possui um papel vital em interconectar sistemas autônomos na internet — propagando informações de reachability e calculando o melhor caminho para alcançar um determinado destino.
No entanto, vimos um ‘boom’ exponencial em todos os aspectos da internet — um crescimento inimaginável a uns 20 anos atrás. Um exemplo prático disso foi a concepção do IPv6 em 1998 (devido a escassez de prefixos IPv4) e a expansão do número de ASNs de 16 para 32 bits (RFC 4893).
No cenário atual, a “internet” é composta por mais ou menos 800.000 prefixos, e dividido entre aproximadamente 65.000 sistemas autônomos, fica cada vez mais acessível ter um acesso a rede pública. Praticamente qualquer organização consegue obter um ASN e se conectar à internet, depois de preencher uma certa papelada.
Para que esses diversos sistemas consigam coexistir e se interconectar, o uso do BGP é essencial na borda das organizações —exigindo também um certo nível de confiança entre as partes.
Tal fator expõe uma falha de design extremamente crítica — o protocolo simplesmente aceita e anuncia os prefixos aprendidos e selecionados (a menos que exista algum tipo de política alterando este comportamento).
Ou seja, em outras palavras, qualquer um destes 65.000 ASNs “podem” anunciar qualquer prefixo, independente de qualquer acordo ou restrição no âmbito legal.
Tal vulnerabilidade permite que indivíduos ou organizações maliciosas, com um acesso básico à internet (e a um “peer” mal configurado) possam originar ou alterar o caminho de determinados prefixos, efetivamente “sequestrando” o tráfego destinado à estas redes. Este tipo de ataque é popularmente conhecido como BGP Hijack.
Porém, um Hijack não é somente algo malicioso e intencional. Muito mais frequente que ataques, erros operacionais podem causar “Hijacks acidentais”, gerando a mesma indisponibilidade para os (infelizes) prefixos e ASN afetados.
O problema
Em poucas palavras, o problema maior que facilita um Hijack é a precariedade e falta de cuidado ao se implementar uma policy.
Sendo responsáveis por alocar e administrar blocos de endereços e ASNs, os IRR (Internet Routing Registry) também fornecem uma listagem de todos os ASNs e blocos associados à estes ASN — nada mais que um banco de dados dos registros.
Uma breve consulta no RIPE, nos indica que o prefixo 208.67.220.0/24 pertence ao ASN 36692 (OPENDNS), por exemplo:
route: 208.67.220.0/24descr: OPENDNS-208–67–220–0–24origin: AS36692member-of: RS-OPENDNS-ANYCASTnotify: noc@opendns.commnt-by: MAINT-AS36692source: RADB-GRSremarks: ****************************remarks: * THIS OBJECT IS MODIFIEDremarks: * Please note that all data that is generally regarded as personalremarks: * data has been removed from this object.remarks: * To view the original object, please query the RADB Database at:remarks: * http://www.radb.net/remarks: ****************************
Como uma alternativa a consulta aos IRR, existem alguns banco de dados públicos que nos fornecem uma informação similar, como o serviço RADB da Merit Networks.
No entanto, tais bancos de dados ainda sim são vulneráveis a ataques sofisticados, onde o acesso a estes bancos de dados é relativamente “fácil”, e um atacante pode eventualmente “falsificar” entradas no banco, tornando o ataque legítimo do ponto de vista do IRR em questão — como ocorreu com uma das fraudes mais sofisticadas da história da internet.
Ou seja, até mesmo com o cuidado adicional de se consultar tais bases, a vulnerabilidade ainda existe!
E aí? Como prevenir?!
Criado em 2007, o grupo SIDR (Secure Inter-Domain Routing) do IETF tem como propósito reduzir vulnerabilidades em sistemas de roteamento entre domínios. As vulnerabilidades endereçadas são:
- O ASN é autorizado a anunciar um determinado prefixo?
- O AS-PATH junto ao prefixo é o idêntico ao caminho pelo qual o NLRI foi propagado?
A partir daí, surgiu o conceito de uma arquitetura dedicada à suportar a segurança no roteamento da internet — se utilizando de uma base de dados hierárquica de alocação de IPs e ASNs. Além disso, estes recursos seriam baseados em uma cadeia criptográfica de confiança — o que é conhecido como RPKI (Resource Public Key Infrastructure).
Utilizando a estrutura RPKI, um determinado AS obtêm um certificado digital, que é utilizado para “assinar” entradas na base de dados, o que é chamado de ROA (Routing Origination Authorization). Em outras palavras, o ASN registra como ROA seu ASN autorizado a originar seus prefixos — e os limites de máx/min tamanho da máscara (/24, /22, etc).
Podemos acessar os ROA publicados e validados no validator do RIPE.
Com a estrutura de confiança e o banco de dados devidamente populado, estas informações podem ser utilizadas para determinar se um prefixo é válido ou não — de acordo com os requisitos de validação registrados no banco de dados. Atualmente, existem dois tipos de validação que podem se utilizar de toda essa arquitetura: BGP Origin Validation e BGP Path Validation.
Ambas as técnicas mencionadas acima foram concebidas e melhoradas através de uma série de RFCs. Podemos ver todas elas neste link: https://datatracker.ietf.org/wg/sidr/documents/
BGP Origin Validation
Em poucas palavras, o BGP Origin Validation consiste em examinar cada anúncio em uma mensagem de update, e comparar o valor (prefix, length, origin_asn) com o seu respectivo ROA — resultando em um simples “Válido” ou “Inválido” para tal anúncio.
Este ROA é obtido através de uma sessão com um “Validador” (uma base de dados acessível que possui toda ou parte da base de dados pública). Essa sessão, por sua vez, utiliza o protocolo RTR (RPKI to Router protocol) — especificado na RFC 6810/8210. O protocolo RTR utiliza TCP, e pode operar nas portas 323 (rpki-rtr), 324 (rpki-rtr-tls) ou 22 (SSH).
A utilização deste Validador é de extrema importância para que a solução seja viável, onde toda a validação criptográfica de cada ROA é centralizada. No fim, o validador mantém um cache da validação de toda a base, e é fornecida ao router através do protocolo RTR..
A infraestrutura, do ponto de vista lógico, é mais ou menos assim:
O ponto importante aqui é que o objetivo desta validação é verificar se quem originou o prefixo (isto é, primeiro ASN no AS_PATH) está autorizado a fazê-lo publicamente, e com o tamanho da máscara dentro do que foi registrado.
Tal mecanismo já está disponível em uma série de plataformas (Junos, IOS-XR, Bird) para implementação.
BGP Path Validation
O BGP Path Validation (ou BGPSec), publicado inicialmente em 2017, propõe um novo atributo (opcional, não transitivo) que contém a assinatura digital de cada ASN que propaga uma determinada mensagem de update (ou anúncio NLRI). Tal assinatura é associada a um certificado individual de um determinado router (Router Certificate) que está “autorizado” a inserir um determinado ASN no PATH.
No caso do BGPSec, os neighbors devem indicar que possuem suporte ao atributo BGPSec_PATH — o que substitui completamente o atributo AS-PATH. Ou seja, uma mensagem com um atributo BGPSec_PATH nunca terá um atributo AS-PATH (e vice versa).
O BGPSec_PATH é composto de diversos blocos, onde cada ASN se refere à uma determinada assinatura digital — que foi criada a partir de um determinado Router Certificate de um dispositivo autorizado a propagar aquele ASN no NLRI.
Ao receber um UPDATE de um neighbor BGPSec, uma série de validações sintáticas são executadas. Após estas validações, inicia-se o processo de validar os blocos de assinatura que constam no BGPSec_PATH. Cada segmento destes blocos possuem os dados do Router Certificate para consulta à base RPKI (ASN, Public key, Identificação da chave) — que são as informações necessárias para poder validar a autenticidade de uma determinada parte do caminho.
Esta validação é executada em cada bloco (correspondente a um ASN em que o NLRI se propagou), gerando, por fim, um resultado de “Válido” ou “Inválido”.
Cenário Atual
Como vimos, ambas as validações (origem e caminho) se completam. Tendo a capacidade de validar a origem e a legitimidade do caminho, pode-se reduzir severamente a superfície de ataques de Hijack. No entanto, a adoção a tais mecanismos ainda é muito limitada. Para que se possa obter o melhor cenário possível, cada ASN deve manter atualizada suas informações na base RPKI, além de implementar tais funcionalidades em sua rede.
O BGP Origin Validation já pode ser implementado, e temos diversos cases mostrando que a implementação está amadurecendo — e ganhando espaço entre os blocos mais fundamentais da internet. Alguns exemplos são DE-CIX, AMS-IX, Cloudflare
Já o Path Validation ainda está em fase de desenvolvimento, onde ainda não temos os devidos certificados propriamente registrados e nenhuma implementação “pré-rfc” (visto que a especificação ainda não foi oficializada).
No mais, ambas as ferramentas despertaram um grande interesse na comunidade, e a expectativa é que a implementação vá ganhando espaço por meios de divulgação, experimentos, e até de projetos que facilitam a adoção dos mecanismos; como o routinator e o GoRTR, por exemplo.
Conclusão
Hoje falamos um pouco sobre BGP Hijacks, e como está o esforço no desenvolvimento de ferramentas de segurança para prevenir ou reduzir tal vulnerabilidade. Falamos também um pouco de como funciona cada tipo de validação (Origin e Path validation), e demos exemplos de algumas implementações que já estão em produção por aí.
Gostou da leitura? Seguem algumas referências adicionais sobre o tema!
https://www.noction.com/blog/bgp_security_rpki_overview
https://blog.cloudflare.com/rpki/
https://www.lacnic.net/778/3/lacnic/informac%C3%A3o-geral-sobre-certificac%C3%A3o-de-recursos-rpki
https://datatracker.ietf.org/doc/rfc8205/
https://datatracker.ietf.org/doc/rfc8481/
Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor:
Bernardo, CCIE #57862
Cloud Network Engineer
