Em 13 de março, o Grupo de Trabalho Anti-Abuso do RIPE
recebeu uma proposta para considerar o seqüestro como uma violação da política do RIPE. Se a oferta fosse aceita, o provedor da Internet atacado pelo tráfego interceptador poderia enviar uma solicitação especial para levar o invasor à água limpa. Se o grupo de especialistas coletar evidências de apoio suficientes, esse LIR, que é a fonte da interceptação de BGP, seria considerado um invasor e poderia ser privado do status de LIR. Houve alguns argumentos
contra essa mudança.
Nesta publicação, queremos mostrar um exemplo de ataque quando não apenas o atacante real estava em dúvida, mas toda a lista de prefixos afetados. Além disso, esse ataque novamente levanta questões sobre os motivos para futuras interceptações desse tipo de tráfego.
Nos últimos anos, apenas conflitos como o MOAS (Sistema Autônomo de Origem Múltipla) foram relatados na imprensa à medida que o BGP intercepta. MOAS é um caso especial quando dois sistemas autônomos diferentes anunciam prefixos conflitantes com os números ASN correspondentes em AS_PATH (o primeiro ASN em AS_PATH, a seguir denominado ASN de origem). No entanto, podemos nomear pelo menos
três tipos adicionais de interceptação
de tráfego que permitem que um invasor manipule o atributo AS_PATH para diferentes fins, inclusive para contornar as abordagens modernas de filtragem e monitoramento. O tipo bem conhecido de
ataque de
Pilosov-Kapela é o último tipo de tal interceptação, mas nada significativo. É possível que esse seja exatamente o ataque que observamos nas últimas semanas. Tal evento tem um caráter compreensível e consequências bastante graves.
Quem procura uma versão TL; DR pode rolar para a subposição "Perfect Attack".
Contexto da rede
(para entender melhor os processos envolvidos nesse incidente)Se você deseja enviar um pacote e possui vários prefixos na tabela de roteamento que contém o endereço IP de destino, você usará a rota para o prefixo com o tamanho máximo. Se na tabela de roteamento houver várias rotas diferentes para um prefixo, você escolherá a melhor (de acordo com o mecanismo para escolher o melhor caminho).
As abordagens de filtragem e monitoramento existentes 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. A adição do ASN proprietário no início do AS_PATH (como o ASN de origem) pode ser suficiente para ignorar os mecanismos de verificação da fonte atual. Além disso, se houver uma rota do ASN atacado para você, será possível extrair e usar o AS_PATH dessa rota em seus outros anúncios. Eventualmente, a validação de apenas AS_PATH para seus anúncios criados será aprovada.
Existem várias limitações dignas de nota. Primeiramente, no caso de filtrar prefixos por um provedor mais alto, sua rota ainda poderá ser filtrada (mesmo com o AS_PATH correto) se o prefixo não pertencer ao cone do cliente configurado no upstream. Segundo, um AS_PATH válido pode se tornar inválido se a rota criada for anunciada nas direções incorretas e, assim, violar a política de roteamento. E a última - qualquer rota com um prefixo que viole o comprimento do ROA pode ser considerada inválida.
Incidente
Algumas semanas atrás, recebemos uma reclamação de um dos usuários. Vimos rotas com sua origem ASN e / 25 prefixos, enquanto o usuário alegou que não as havia anunciado.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||Exemplos de anúncios no início de abril de 2019A NTT em trânsito para o prefixo / 25 o torna particularmente suspeito. Durante o incidente, a LG NTT não sabia nada sobre essa rota. Então, sim, algum tipo de operador cria um AS_PATH inteiro para esses prefixos! Os testes em outros roteadores permitem destacar um ASN especial: AS263444. Observando outras rotas com esse sistema autônomo, enfrentamos 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 há de errado aquiParece que alguém pegou o prefixo da rota, dividiu-o em duas partes e anunciou a 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 divididosVárias perguntas surgem ao mesmo tempo. Alguém realmente tentou esse tipo de interceptação na prática? Alguém já tomou essas rotas? Quais prefixos foram afetados?
É aqui que nossa série de falhas começa e mais uma rodada de decepções na saúde atual da Internet.
O caminho do fracasso
Primeiras coisas primeiro. Como podemos determinar quais roteadores aceitaram essas rotas interceptadas e cujo tráfego pode ser redirecionado hoje? Pensamos em começar com os prefixos / 25, porque "simplesmente não podem ter distribuição global". Como você pode imaginar, estávamos muito errados. Essa métrica era muito barulhenta e as rotas com esses prefixos podem aparecer mesmo nos operadores de nível 1. Por exemplo, a NTT possui cerca de 50 desses prefixos que distribui entre seus próprios clientes. Por outro lado, essa métrica é ruim porque esses prefixos podem ser filtrados se o operador aplicar a
filtragem de prefixos pequenos em todas as direções. Portanto, esse método não é adequado para procurar todos os operadores cujo tráfego foi redirecionado como resultado de um incidente desse tipo.
Outra boa ideia que pensamos foi olhar para
POV . Especialmente em rotas que violam a regra maxLength do ROA correspondente. Assim, pudemos encontrar o número de ASNs de origem diferentes com status Inválido que eram visíveis para esse AS. No entanto, há um problema "pequeno". O valor médio (mediana e modo) desse número (o número de ASNs de origem diferente) é de cerca de 150 e, mesmo que filtremos pequenos prefixos, ele permanecerá acima de 70. Essa situação tem uma explicação muito simples: existem apenas alguns operadores que já usam o ROA- filtra com a política "redefinir rotas inválidas" nos pontos de entrada; portanto, sempre que uma rota com uma violação de ROA aparecer no mundo real, ela poderá se espalhar em todas as direções.
As duas últimas abordagens nos permitem encontrar os operadores que viram nosso incidente (por ser bastante grande), mas em geral eles não são aplicáveis. Ok, mas podemos encontrar o atacante? Quais são os recursos comuns dessa manipulação do AS_PATH? Existem várias suposições básicas:
- O prefixo nunca foi visto em nenhum lugar antes;
- ASN de origem (lembrete: o primeiro ASN em AS_PATH) é válido;
- O último ASN em AS_PATH é o ASN do atacante (se o vizinho verificar o ASN do vizinho em todas as rotas de entrada);
- O ataque vem de um provedor.
Se todas as suposições forem verdadeiras, em todas as rotas incorretas o ASN do atacante será apresentado (exceto a origem do ASN) e, portanto, esse é um ponto "crítico". Entre os verdadeiros seqüestradores estava o AS263444, embora houvesse outros. Mesmo quando retiramos as rotas de incidentes de consideração. Porque Um ponto crítico pode permanecer crítico mesmo para rotas corretas. Pode ser o resultado de baixa conectividade em qualquer região ou as limitações de nossa própria visibilidade.
Como resultado: existe uma maneira de detectar um invasor, mas apenas se todas as condições acima forem atendidas e somente quando a interceptação for grande o suficiente para passar os limites de monitoramento. Se algum desses fatores não for respeitado, podemos destacar os prefixos afetados por essa interceptação? Para certos operadores, sim.
Quando um invasor cria uma rota mais específica, esse prefixo não é anunciado pelo verdadeiro proprietário. Se você tiver uma lista dinâmica de todos os seus prefixos, poderá fazer uma comparação e encontrar rotas mais específicas distorcidas. Coletamos essa lista de prefixos usando nossas sessões de BGP, já que recebemos não apenas uma lista completa de rotas visíveis ao operador no momento, mas também uma lista de todos os prefixos que ele deseja anunciar ao mundo. Infelizmente, agora existem várias dezenas de usuários de radar que não concluíram a última parte corretamente. Em um futuro próximo, iremos notificá-los e tentar resolver esse problema. Todos os outros podem se juntar ao nosso sistema de monitoramento agora.
Se retornarmos ao incidente original, o invasor e a área de distribuição foram descobertos por nós, procurando pontos críticos. Surpreendentemente, o AS263444 não enviou rotas fabricadas para todos os seus clientes. Embora haja um momento 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 uma tentativa de interceptar nosso espaço de endereçoQuando mais específicos para nossos prefixos foram criados, o AS_PATH especialmente criado foi usado. No entanto, este AS_PATH não pôde ser retirado de nenhuma de nossas rotas anteriores. Nem sequer temos uma conexão com o AS6762. Observamos outras rotas no incidente: algumas delas tinham um AS_PATH real, que foi usado anteriormente, enquanto outras não, mesmo que pareçam reais. Uma alteração adicional no AS_PATH não faz nenhum sentido prático, pois, em qualquer caso, o tráfego será redirecionado para o invasor, mas as rotas com um AS_PATH "ruim" podem ser filtradas pelo ASPA ou por qualquer outro mecanismo de verificação. Aqui nós pensamos sobre a motivação do seqüestrador. Agora, não temos dados suficientes para afirmar que esse incidente foi um ataque planejado. No entanto, é possível. Vamos tentar imaginar uma situação hipotética, mas potencialmente bastante real.
Ataque perfeito
O que nós temos? Suponha que você seja um provedor de transporte público que transmita rotas para seus clientes. Se seus clientes tiverem presença múltipla (hospedagem múltipla), você receberá apenas parte do tráfego deles. Mas quanto mais tráfego - mais sua renda. Portanto, se você começar a anunciar prefixos de sub-rede das mesmas rotas com o mesmo AS_PATH, receberá o restante do tráfego. Como resultado, o resto do dinheiro.
O ROA ajudará aqui? Talvez sim, se você decidir abandonar completamente o uso de
maxLength . Além disso, é altamente indesejável ter entradas de ROA com prefixos cruzados. Para alguns operadores, essas restrições são inaceitáveis.
Considerando outros mecanismos de segurança de roteamento, o ASPA também não ajudará neste caso (porque o AS_PATH é usado a partir de uma rota válida). O BGPSec ainda não é a melhor opção devido à baixa taxa de aceitação e à possibilidade restante de ataques de downgrade.
Assim, temos um lucro claro para o invasor e uma falta de segurança. Ótima mistura!
O que eu preciso fazer?
A etapa óbvia e mais radical é revisar sua política de roteamento atual. Divida seu espaço de endereço nas partes menores (sem interseções) que você deseja anunciar apenas. Assine ROAs apenas para eles, sem usar o parâmetro maxLength. Nesse caso, o POV atual pode salvá-lo de um ataque assim. No entanto, novamente, para alguns operadores, essa abordagem não é razoável devido ao uso exclusivo de rotas mais específicas. Todos os problemas do estado atual do ROA e dos objetos de rota serão descritos em um de nossos materiais futuros.
Além disso, você pode tentar monitorar essas interceptações. Para fazer 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 da Internet, também podemos encontrar a área de distribuição para outros incidentes. Para aqueles que ainda não estão conectados ao nosso sistema de monitoramento - para começar, uma lista de rotas apenas com seus prefixos será suficiente para nós. Se você tiver uma sessão conosco, verifique se todas as suas rotas foram enviadas. Infelizmente, vale a pena lembrar, pois alguns operadores esquecem um ou dois prefixos e, portanto, interferem em nossos métodos de pesquisa. Se tudo for feito corretamente, teremos dados confiáveis sobre seus prefixos, que no futuro ajudarão a detectar e detectar automaticamente esses (e outros) tipos de interceptação de tráfego para o seu espaço de endereço.
Se você descobrir em tempo real sobre essa interceptação do seu tráfego, poderá tentar contê-lo. A primeira abordagem é anunciar rotas com esses prefixos mais específicos. No caso de um novo ataque a esses prefixos - repita.
A segunda abordagem é punir o atacante e aqueles para quem ele é um ponto crítico (para boas rotas) cortando o acesso de suas rotas ao atacante. Isso pode ser feito adicionando o ASN do atacante ao AS_PATH de suas rotas antigas e, assim, evitando esse AS usando o mecanismo de detecção de loop interno no BGP
para seu próprio benefício .