13 de março para o grupo de trabalho antiabuso RIPE considere o sequestro de BGP (hjjack) como uma violação da política RIPE. Se a proposta fosse aceita, o provedor de Internet atacado pela interceptação de tráfego teria a oportunidade de enviar uma solicitação especial para expor o invasor. Se a equipe de revisão coletasse evidências de apoio suficientes, o LIR que foi a fonte da interceptação do BGP seria considerado um intruso e poderia perder seu status de LIR. Houve também alguns argumentos alterar.
Nesta publicação queremos mostrar um exemplo de ataque onde não apenas o verdadeiro atacante estava em questão, mas também toda a lista de prefixos afetados. Além disso, tal ataque levanta novamente questões sobre os motivos para futuras intercepções deste tipo de tráfego.
Nos últimos anos, apenas conflitos como o MOAS (Sistema Autônomo de Origem Múltipla) foram cobertos pela imprensa como interceptações de BGP. MOAS é um caso especial onde dois sistemas autônomos diferentes anunciam prefixos conflitantes com ASNs correspondentes em AS_PATH (o primeiro ASN em AS_PATH, doravante denominado ASN de origem). Contudo, podemos citar pelo menos interceptação de tráfego, permitindo que um invasor manipule o atributo AS_PATH para diversos fins, incluindo contornar abordagens modernas de filtragem e monitoramento. Tipo de ataque conhecido - o último tipo de interceptação, mas sem importância. É bem possível que este seja exatamente o tipo de ataque que vimos nas últimas semanas. Tal evento tem uma natureza compreensível e consequências bastante graves.
Quem procura a versão TL; DR pode rolar até o subtítulo “Perfect Attack”.
Plano de fundo da rede
(para ajudá-lo a entender melhor os processos envolvidos neste 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 comprimento mais longo. Se houver diversas rotas diferentes para o mesmo prefixo na tabela de roteamento, você escolherá a melhor (de acordo com o melhor mecanismo de seleção de caminho).
As abordagens existentes de filtragem e monitoramento tentam analisar rotas e tomar decisões analisando o atributo AS_PATH. O roteador pode alterar este atributo para qualquer valor durante o anúncio. Simplesmente adicionar o ASN do proprietário no início de AS_PATH (como o ASN de origem) pode ser suficiente para ignorar os mecanismos atuais de verificação de origem. Além disso, se houver uma rota do ASN atacado para você, será possível extrair e utilizar o AS_PATH dessa rota em seus outros anúncios. Qualquer verificação de validação somente AS_PATH para seus anúncios elaborados será eventualmente aprovada.
Ainda existem algumas limitações que vale a pena mencionar. Primeiramente, no caso de filtragem de prefixo pelo provedor upstream, sua rota ainda poderá ser filtrada (mesmo com o AS_PATH correto) se o prefixo não pertencer ao cone do seu cliente configurado no upstream. Segundo, um AS_PATH válido pode tornar-se inválido se a rota criada for anunciada em direções incorretas e, portanto, violar a política de roteamento. Por último, qualquer rota com um prefixo que viole o comprimento do ROA pode ser considerada inválida.
O 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 alegou que não as anunciava.
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 para o início de abril de 2019
NTT no caminho para o prefixo /25 o torna especialmente suspeito. A LG NTT não tinha conhecimento desta rota no momento do incidente. Então sim, algum operador cria um AS_PATH inteiro para esses prefixos! A verificação de outros roteadores revela um ASN específico: AS263444. Depois de analisar outras rotas com este sistema autônomo, encontramos 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 aqui
Parece 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||
Rotas de exemplo para um dos pares de prefixos divididos
Várias questões surgem ao mesmo tempo. Alguém realmente tentou esse tipo de interceptação na prática? Alguém já fez esses caminhos? Quais prefixos foram afetados?
É aqui que começa a nossa série de fracassos e mais uma rodada de decepções com o estado atual da saúde da Internet.
O caminho do fracasso
Primeiras coisas primeiro. Como podemos determinar quais roteadores aceitaram tais rotas interceptadas e cujo tráfego poderia ser redirecionado hoje? Pensamos em começar com prefixos /25 porque eles “simplesmente não podem ter distribuição global”. Como você pode imaginar, estávamos muito errados. Essa métrica revelou-se muito barulhenta e rotas com esses prefixos podem aparecer até mesmo em operadoras de nível 1. Por exemplo, a NTT possui cerca de 50 desses prefixos, que distribui aos seus próprios clientes. Por outro lado, esta métrica é ruim porque tais prefixos podem ser filtrados se o operador usar , em todas as direções. Portanto, este método não é adequado para localizar todos os operadores cujo tráfego foi redirecionado em consequência de tal incidente.
Outra boa ideia que pensamos foi dar uma olhada . Especialmente para rotas que violam a regra maxLength do ROA correspondente. Desta forma poderíamos encontrar a quantidade de ASNs de origem diferentes com status Inválido que estavam visíveis para um determinado AS. No entanto, existe um “pequeno” problema. A média (mediana e moda) deste número (o número de ASNs de origem diferentes) é de cerca de 150 e, mesmo se filtrarmos os prefixos pequenos, permanece acima de 70. Este estado de coisas tem uma explicação muito simples: há apenas um poucas operadoras que já utilizam filtros ROA com uma política de “redefinir rotas inválidas” nos pontos de entrada, para que sempre que uma rota com violação de ROA aparecer no mundo real, ela possa se propagar em todas as direções.
As duas últimas abordagens permitem-nos encontrar operadores que viram o nosso incidente (uma vez que foi bastante grande), mas em geral não são aplicáveis. Ok, mas podemos encontrar o intruso? Quais são as características gerais desta manipulação AS_PATH? Existem algumas suposições básicas:
- O prefixo não havia sido visto em lugar nenhum antes;
- O ASN de origem (lembrete: primeiro ASN em AS_PATH) é válido;
- O último ASN em AS_PATH é o ASN do atacante (caso seu vizinho verifique o ASN do vizinho em todas as rotas de entrada);
- O ataque se origina de um único provedor.
Se todas as suposições estiverem corretas, então todas as rotas incorretas apresentarão o ASN do atacante (exceto o ASN de origem) e, portanto, este é um ponto “crítico”. Entre os verdadeiros sequestradores estava o AS263444, embora houvesse outros. Mesmo quando descartamos as rotas do incidente. Por que? Um ponto crítico pode permanecer crítico mesmo para rotas corretas. Pode ser o resultado de uma fraca conectividade numa região ou de limitações na nossa própria visibilidade.
Como resultado, existe uma maneira de detectar um invasor, mas somente se todas as condições acima forem atendidas e somente quando a interceptação for grande o suficiente para ultrapassar os limites de monitoramento. Se alguns desses fatores não forem atendidos, será que podemos identificar os prefixos que sofreram tal interceptação? Para alguns operadores - sim.
Quando um invasor cria uma rota mais específica, tal prefixo não é anunciado pelo verdadeiro proprietário. Se você tiver uma lista dinâmica de todos os seus prefixos, será possível fazer uma comparação e encontrar rotas mais específicas distorcidas. Coletamos essa lista de prefixos usando nossas sessões BGP, porque recebemos não apenas a lista completa de rotas visíveis para a operadora no momento, mas também uma lista de todos os prefixos que ela deseja anunciar para o mundo. Infelizmente, existem agora várias dezenas de usuários do Radar que não completam a última parte corretamente. Iremos notificá-los em breve e tentaremos resolver esse problema. Todos os outros podem aderir ao nosso sistema de monitoramento agora mesmo.
Se voltarmos ao incidente original, tanto o invasor quanto a área de distribuição foram detectados por nós através da busca por pontos críticos. Surpreendentemente, o AS263444 não enviou rotas fabricadas para todos os seus clientes. Embora haja um momento 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 interceptar nosso espaço de endereço
Quando outros mais específicos foram criados para nossos prefixos, foi utilizado um AS_PATH especialmente criado. Entretanto, este AS_PATH não poderia ter sido obtido de nenhuma de nossas rotas anteriores. Nem temos comunicação com o AS6762. Observando as outras rotas do incidente, algumas delas tinham um AS_PATH real que foi usado anteriormente, enquanto outras não, mesmo que pareça o real. Além disso, alterar o AS_PATH não faz sentido prático, pois o tráfego será redirecionado para o invasor de qualquer maneira, mas as rotas com um AS_PATH “ruim” podem ser filtradas pelo ASPA ou qualquer outro mecanismo de inspeção. Aqui pensamos na motivação do sequestrador. Atualmente não temos informações suficientes para confirmar que este incidente foi um ataque planejado. No entanto, é possível. Vamos tentar imaginar uma situação, embora ainda hipotética, mas potencialmente bastante real.
Ataque Perfeito
O que nós temos? Digamos que você seja um provedor de transporte público transmitindo rotas para seus clientes. Se seus clientes tiverem presença múltipla (multihome), você receberá apenas uma parte do tráfego deles. Mas quanto mais tráfego, maior será sua receita. Portanto, se você começar a anunciar prefixos de sub-rede dessas 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 parar de usá-lo completamente . Além disso, é altamente indesejável ter registros ROA com prefixos que se cruzam. Para alguns operadores, tais restrições são inaceitáveis.
Considerando outros mecanismos de segurança de roteamento, o ASPA também não ajudará neste caso (porque utiliza AS_PATH de uma rota válida). O BGPSec ainda não é uma opção ideal devido às baixas taxas de adoção e à possibilidade remanescente de ataques de downgrade.
Então temos um claro ganho para o atacante e uma falta de segurança. Ótima mistura!
O que devo fazer?
A etapa óbvia e mais drástica é revisar sua política de roteamento atual. Divida seu espaço de endereço nos menores pedaços (sem sobreposições) que você deseja anunciar. Assine o ROA apenas para estes, sem usar o parâmetro maxLength. Nesse caso, seu ponto de vista atual pode salvá-lo desse ataque. Contudo, mais uma vez, para alguns operadores esta abordagem não é razoável devido à utilização exclusiva de rotas mais específicas. Todos os problemas com o 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 na Internet, poderemos encontrar espaço para outros incidentes. Para quem ainda não está conectado ao nosso sistema de monitoramento, para começar, uma lista de rotas apenas com seus prefixos será suficiente. Se você tiver uma sessão conosco, verifique se todos os seus roteiros foram enviados. Infelizmente, vale a pena lembrar disso porque alguns operadores esquecem um ou dois prefixos e, portanto, interferem em nossos métodos de pesquisa. Se feito corretamente, teremos dados confiáveis sobre seus prefixos, que no futuro nos ajudarão a identificar e detectar automaticamente este (e outros) tipos de interceptação de tráfego para o seu espaço de endereço.
Se você tomar conhecimento de tal interceptação de seu tráfego em tempo real, poderá tentar neutralizá-la sozinho. A primeira abordagem é você mesmo anunciar rotas com esses prefixos mais específicos. No caso de um novo ataque a esses prefixos, repita.
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 antigas e, assim, forçá-lo a evitar esse AS usando o mecanismo de detecção de loop integrado no BGP .
Fonte: habr.com