Em 13 de março, foi proposta à equipe de trabalho do RIPE para combate a abusos do sequestro de BGP (hjjack) como uma violação da política do RIPE. Caso a proposta seja aceita, o provedor de internet atacado por meio do sequestro de tráfego teria a possibilidade de enviar um pedido especial para expor o infrator. Se o grupo de especialistas reunir evidências suficientes, tal LIR, sendo a fonte do sequestro de BGP, seria considerado um infrator e poderia ser destituído do status de LIR. Foram apresentadas algumas argumentações mudança.
Neste artigo, queremos mostrar um exemplo de ataque em que não só o verdadeiro infrator estava em questão, mas também toda a lista de prefixos afetados. Além disso, tal ataque suscita novamente questões sobre os motivos para futuros sequestros de tráfego desse tipo.
Nos últimos anos, a mídia tem abordado como sequestros de BGP apenas conflitos do tipo MOAS (Multiple Origin Autonomous System). MOAS é um caso específico em que dois sistemas autônomos diferentes anunciam prefixos conflitantes com números ASN correspondentes no AS_PATH (o primeiro ASN no AS_PATH, daqui em diante - ASN de origem). Contudo, podemos identificar pelo menos de sequestro de tráfego que permitem ao infrator manipular o atributo AS_PATH com diferentes objetivos, incluindo a evasão das abordagens modernas de filtragem e monitoramento. Um tipo conhecido de ataque é o último tipo desse sequestro, mas não menos importante. É bem possível que tenhamos testemunhado esse tipo de ataque nas últimas semanas. Este evento é compreensível e possui consequências bastante sérias.
Aqueles que procuram uma versão TL;DR podem rolar até o subtítulo "Ataque Perfeito".
Contexto de Rede
(para que você compreenda melhor os processos envolvidos neste incidente)
Se você quiser enviar um pacote e tiver vários prefixos na tabela de roteamento que contenham o IP de destino, você usará a rota do prefixo com o comprimento máximo. No entanto, se houver várias rotas diferentes para um prefixo na tabela de roteamento, você escolherá a melhor (de acordo com o mecanismo de escolha do melhor caminho).
As abordagens existentes para filtragem e monitoramento tentam analisar rotas e tomar decisões analisando o atributo AS_PATH. O roteador pode alterar esse atributo para qualquer valor durante o anúncio. Apenas adicionar o ASN do proprietário no início do AS_PATH (como ASN de origem) pode ser suficiente para contornar os mecanismos de verificação de origem atuais. Além disso, se existir uma rota do ASN atacado até você, surge a possibilidade de extrair e usar o AS_PATH dessa rota em outros de seus anúncios. Qualquer validação apenas do AS_PATH para os seus anúncios forjados acabará sendo aprovada.
Ainda existem algumas limitações que merecem destaque. Primeiro, no caso de filtragem de prefixos por um provedor de nível superior, sua rota ainda pode ser filtrada (mesmo com um AS_PATH correto), se o prefixo não pertencer ao seu cone de clientes, configurado no upstream. Em segundo lugar, um AS_PATH válido pode se tornar inválido se a rota criada for anunciada em direções incorretas e, assim, violar a política de roteamento. E por último, qualquer rota com um prefixo que viola o comprimento do ROA pode ser considerada inválida.
Incidente
Há algumas semanas, recebemos uma reclamação de um de nossos usuários. Vimos rotas com seu ASN de origem e prefixos /25, enquanto o usuário afirmava que não os havia anunciado.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
Exemplos de anúncios no início de abril de 2019
O NTT em trânsito para o prefixo /25 torna-o especialmente suspeito. Durante o incidente, a LG NTT não sabia nada sobre essa rota. Então, sim, algum operador está criando um AS_PATH inteiro para esses prefixos! A verificação em outros roteadores permite destacar um ASN específico: AS263444. Ao olhar para outras rotas com esse sistema autônomo, nos deparamos com a seguinte situação:
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
Tente adivinhar o que está errado aqui
Parece que alguém pegou o prefixo de uma rota, dividiu-o em duas partes e anunciou uma rota com o mesmo AS_PATH para esses dois prefixos.
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
Exemplos de rotas para um dos pares de prefixos divididos
Levanta-se imediatamente várias perguntas. Alguém realmente tentou na prática esse tipo de interceptação? Alguém aceitou essas rotas? Quais prefixos foram afetados?
Aqui começa nossa série de fracassos e mais uma rodada de decepção com o atual estado de saúde da Internet.
Caminho de fracassos
Vamos por partes. Como podemos determinar quais roteadores aceitaram esses roteadores interceptados e cujo tráfego pode ser redirecionado já hoje? Pensamos em começar pelos prefixos /25, porque 'simplesmente não podem ter uma disseminação global'. Como você pode imaginar, estávamos muito enganados. Essa métrica se mostrou excessivamente ruidosa e roteadores com esses prefixos podem aparecer até mesmo de operadores Tier-1. Por exemplo, a NTT possui cerca de 50 desses prefixos que ela distribui entre seus próprios clientes. Por outro lado, essa métrica é ruim porque tais prefixos podem ser filtrados se o operador aplicar , em todas as direções. Portanto, esse método não é adequado para encontrar todos os operadores cujo tráfego foi redirecionado como resultado de tal incidente.
Outra boa ideia que nos pareceu foi olhar para . Em particular, para as rotas que violam a regra de maxLength do ROA correspondente. Assim, poderíamos encontrar o número de diferentes ASN de origem com status Invalid, que foram vistos por este AS. No entanto, há um 'pequeno' problema. A média (mediana e moda) desse número (número de diferentes ASN de origem) é de cerca de 150 e, mesmo se filtrarmos os pequenos prefixos, ela permanecerá acima de 70. Essa situação tem uma explicação bastante simples: há apenas alguns operadores que já aplicam filtros de ROA com a política de 'descartar rotas Invalid' nos pontos de entrada, portanto, onde quer que uma rota com violação de ROA apareça no mundo real, ela pode se espalhar em todas as direções.
As duas abordagens finais permitem encontrar os operadores que observaram nosso incidente (já que foi grande o suficiente), mas, de forma geral, são inaplicáveis. Bem, mas podemos encontrar o responsável? Quais são as características gerais dessa manipulação do AS_PATH? Existem algumas suposições básicas:
- O prefixo nunca foi visto antes;
- O ASN de origem (lembrete: o primeiro ASN no AS_PATH) é válido;
- O último ASN no AS_PATH é o ASN do atacante (caso seu vizinho verifique o ASN do vizinho em todas as rotas de entrada);
- O ataque vem de um único provedor.
Se todas as suposições estiverem corretas, então todos os caminhos incorretos apresentarão o ASN do invasor (exceto o ASN de origem) e, assim, isso é um ponto "crítico". Entre os verdadeiros sequestradores estava o AS263444, embora houvesse outros. Mesmo quando descartamos os caminhos do incidente da consideração. Por quê? Um ponto crítico pode permanecer crítico mesmo para caminhos corretos. Pode ser resultado de uma conectividade ruim em alguma região ou das limitações da nossa própria visibilidade.
Como resultado: há uma maneira de detectar o invasor, mas apenas se todas as condições citadas acima forem atendidas e apenas quando a interceptação for grande o suficiente para passar pelos limiares de monitoramento. Se algum desses fatores não for cumprido, podemos destacar os prefixos afetados por esse tipo de interceptação? Para certos operadores — sim.
Quando o atacante cria um caminho mais específico, esse prefixo não é anunciado pelo verdadeiro proprietário. Se você tiver uma lista dinâmica de todos os seus prefixos, então há a possibilidade de comparar e encontrar os caminhos mais específicos distorcidos. Coletamos essa lista de prefixos através de nossas sessões BGP, pois recebemos não apenas a lista completa de rotas visíveis para o operador agora, mas também a lista de todos os prefixos que ele deseja anunciar ao mundo. Infelizmente, existem atualmente várias dezenas de usuários do Radar que não estão executando essa última parte de maneira totalmente correta. Em breve, nós os notificaremos e tentaremos resolver esse problema. Todos os outros podem se juntar ao nosso sistema de monitoramento agora mesmo.
Voltando ao incidente original, tanto o invasor quanto a área de abrangência foram identificados por nós através da busca por pontos críticos. Surpreendentemente, o AS263444 estava enviando rotas forjadas para nem todos os seus clientes. Embora haja um aspecto ainda mais estranho.
BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
Um exemplo recente de tentativa de interceptação do nosso espaço de endereços
Quando os more specific foram criados para nossos prefixos, foi utilizado um AS_PATH especialmente criado. No entanto, esse AS_PATH não pôde ser retirado de nenhuma das nossas rotas anteriores. Não temos nem mesmo conexão com o AS6762. Observando outras rotas no incidente: algumas delas tinham um AS_PATH legítimo que foi utilizado anteriormente, enquanto outras não, mesmo que parecessem autênticas. Alterar o AS_PATH novamente não tem valor prático, uma vez que o tráfego será redirecionado para o invasor, mas rotas com um AS_PATH 'ruim' podem ser filtradas pelo ASPA ou qualquer outro mecanismo de verificação. Aqui refletimos sobre a motivação do sequestrador. Atualmente, nos faltam dados para afirmar que este incidente foi um ataque planejado. No entanto, é uma possibilidade. Vamos tentar imaginar uma situação ainda que hipotética, mas potencialmente bastante real.
Ataque ideal
O que temos? Suponha que você seja um provedor de trânsito, anunciando rotas para seus clientes. Se seus clientes têm presença múltipla (multihome), você irá receber apenas parte do tráfego deles. Mas quanto maior o tráfego, maior a sua receita. Portanto, se você começar a anunciar os prefixos de sub-redes dessas mesmas rotas com o mesmo AS_PATH, você capturará o restante do tráfego deles. Como consequência, a parte restante do dinheiro.
O ROA ajudará aqui? Talvez sim, se você decidir desistir completamente do uso . Além disso, é extremamente indesejado ter registros ROA com prefixos sobrepostos. Para alguns operadores, essas restrições são inaceitáveis.
Considerando outros mecanismos de segurança de roteamento, neste caso o ASPA também não ajudará (porque utiliza o AS_PATH de uma rota válida). O BGPSec ainda não é uma opção ideal devido à baixa taxa de aceitação e à possibilidade persistente de ataques de downgrade.
Assim, temos um lucro claro para o atacante e falta de segurança. Uma mistura excelente!
O que deve ser feito?
A medida óbvia e mais radical é revisar sua política de roteamento atual. Divida seu espaço de endereçamento em pedaços tão pequenos (sem sobreposições) quanto desejar anunciar. Assine o ROA apenas para eles, sem usar o parâmetro maxLength. Neste caso, o POV atual pode protegê-lo de tal ataque. No entanto, novamente, para alguns operadores, essa abordagem não é viável devido ao uso excepcional de rotas mais específicas. Todos os problemas do estado atual do ROA e de objetos de rota serão abordados em um de nossos materiais futuros.
Além disso, você pode tentar monitorar essas interceptações. Para isso, precisamos de informações confiáveis sobre seus prefixos. Assim, se você estabelecer uma sessão BGP com nosso coletor e nos fornecer informações sobre sua visibilidade na Internet — podemos identificar a área de abrangência e para outros incidentes. Para aqueles que ainda não estão conectados ao nosso sistema de monitoramento — inicialmente, um simples lista de rotas com seus prefixos será suficiente. Se você já estiver conectado conosco, verifique se todas as suas rotas foram enviadas. Infelizmente, isso precisa ser lembrado, pois alguns operadores esquecem um ou dois prefixos, criando assim interferências em nossos métodos de detecção. Se tudo for feito corretamente, teremos dados confiáveis sobre seus prefixos, que no futuro ajudarão a detectar automaticamente esse (e outros) tipos de interceptação de tráfego em seu espaço de endereçamento.
Se você tomou conhecimento em tempo real sobre tal interceptação de seu tráfego, pode tentar reagir por conta própria. A primeira abordagem é anunciar rotas com esses prefixos mais específicos por conta própria. No caso de um novo ataque a esses prefixos — repita o processo.
A segunda abordagem é punir o invasor e aqueles para quem ele é um ponto crítico (para boas rotas), cortando o acesso de suas rotas ao invasor. Isso pode ser feito adicionando o ASN do invasor ao AS_PATH de suas rotas mais antigas, forçando-as a evitar esta AS, usando o mecanismo embutido de detecção de ciclos no BGP. .
Fonte: habr.com
