{"id":31415,"date":"2019-10-31T21:41:08","date_gmt":"2019-10-31T18:41:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika\/"},"modified":"2019-10-31T21:41:08","modified_gmt":"2019-10-31T18:41:08","slug":"vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","title":{"rendered":"Tudo est\u00e1 muito mal ou um novo tipo de intercepta\u00e7\u00e3o de tr\u00e1fego.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Em 13 de mar\u00e7o, foi proposta \u00e0 equipe de trabalho do RIPE para combate a abusos a considera\u00e7\u00e3o<\/a><\/noindex> do sequestro de BGP (hjjack) como uma viola\u00e7\u00e3o da pol\u00edtica do RIPE. Caso a proposta seja aceita, o provedor de internet atacado por meio do sequestro de tr\u00e1fego teria a possibilidade de enviar um pedido especial para expor o infrator. Se o grupo de especialistas reunir evid\u00eancias suficientes, tal LIR, sendo a fonte do sequestro de BGP, seria considerado um infrator e poderia ser destitu\u00eddo do status de LIR. Foram apresentadas algumas argumenta\u00e7\u00f5es contra tal<\/a><\/noindex> mudan\u00e7a.<\/p>\n

Neste artigo, queremos mostrar um exemplo de ataque em que n\u00e3o s\u00f3 o verdadeiro infrator estava em quest\u00e3o, mas tamb\u00e9m toda a lista de prefixos afetados. Al\u00e9m disso, tal ataque suscita novamente quest\u00f5es sobre os motivos para futuros sequestros de tr\u00e1fego desse tipo.
\n<\/a><\/noindex>
\nNos \u00faltimos anos, a m\u00eddia tem abordado como sequestros de BGP apenas conflitos do tipo MOAS (Multiple Origin Autonomous System). MOAS \u00e9 um caso espec\u00edfico em que dois sistemas aut\u00f4nomos diferentes anunciam prefixos conflitantes com n\u00fameros ASN correspondentes no AS_PATH (o primeiro ASN no AS_PATH, daqui em diante - ASN de origem). Contudo, podemos identificar pelo menos 3 tipos adicionais<\/a><\/noindex> de sequestro de tr\u00e1fego que permitem ao infrator manipular o atributo AS_PATH com diferentes objetivos, incluindo a evas\u00e3o das abordagens modernas de filtragem e monitoramento. Um tipo conhecido de ataque Piloso-Kapela<\/a><\/noindex> \u00e9 o \u00faltimo tipo desse sequestro, mas n\u00e3o menos importante. \u00c9 bem poss\u00edvel que tenhamos testemunhado esse tipo de ataque nas \u00faltimas semanas. Este evento \u00e9 compreens\u00edvel e possui consequ\u00eancias bastante s\u00e9rias.<\/p>\n

Aqueles que procuram uma vers\u00e3o TL;DR podem rolar at\u00e9 o subt\u00edtulo \"Ataque Perfeito\".<\/p>\n

Contexto de Rede<\/h3>\n

(para que voc\u00ea compreenda melhor os processos envolvidos neste incidente)<\/i><\/p>\n

Se voc\u00ea quiser enviar um pacote e tiver v\u00e1rios prefixos na tabela de roteamento que contenham o IP de destino, voc\u00ea usar\u00e1 a rota do prefixo com o comprimento m\u00e1ximo. No entanto, se houver v\u00e1rias rotas diferentes para um prefixo na tabela de roteamento, voc\u00ea escolher\u00e1 a melhor (de acordo com o mecanismo de escolha do melhor caminho).<\/p>\n

As abordagens existentes para filtragem e monitoramento tentam analisar rotas e tomar decis\u00f5es analisando o atributo AS_PATH. O roteador pode alterar esse atributo para qualquer valor durante o an\u00fancio. Apenas adicionar o ASN do propriet\u00e1rio no in\u00edcio do AS_PATH (como ASN de origem) pode ser suficiente para contornar os mecanismos de verifica\u00e7\u00e3o de origem atuais. Al\u00e9m disso, se existir uma rota do ASN atacado at\u00e9 voc\u00ea, surge a possibilidade de extrair e usar o AS_PATH dessa rota em outros de seus an\u00fancios. Qualquer valida\u00e7\u00e3o apenas do AS_PATH para os seus an\u00fancios forjados acabar\u00e1 sendo aprovada.<\/p>\n

Ainda existem algumas limita\u00e7\u00f5es que merecem destaque. Primeiro, no caso de filtragem de prefixos por um provedor de n\u00edvel superior, sua rota ainda pode ser filtrada (mesmo com um AS_PATH correto), se o prefixo n\u00e3o pertencer ao seu cone de clientes, configurado no upstream. Em segundo lugar, um AS_PATH v\u00e1lido pode se tornar inv\u00e1lido se a rota criada for anunciada em dire\u00e7\u00f5es incorretas e, assim, violar a pol\u00edtica de roteamento. E por \u00faltimo, qualquer rota com um prefixo que viola o comprimento do ROA pode ser considerada inv\u00e1lida.<\/p>\n

Incidente<\/h3>\n

\nH\u00e1 algumas semanas, recebemos uma reclama\u00e7\u00e3o de um de nossos usu\u00e1rios. Vimos rotas com seu ASN de origem e prefixos \/25, enquanto o usu\u00e1rio afirmava que n\u00e3o os havia anunciado.<\/p>\n

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0\/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128\/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0\/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128\/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||<\/code>
\nExemplos de an\u00fancios no in\u00edcio de abril de 2019<\/i><\/p>\n

O NTT em tr\u00e2nsito para o prefixo \/25 torna-o especialmente suspeito. Durante o incidente, a LG NTT n\u00e3o sabia nada sobre essa rota. Ent\u00e3o, sim, algum operador est\u00e1 criando um AS_PATH inteiro para esses prefixos! A verifica\u00e7\u00e3o em outros roteadores permite destacar um ASN espec\u00edfico: AS263444. Ao olhar para outras rotas com esse sistema aut\u00f4nomo, nos deparamos com a seguinte situa\u00e7\u00e3o:<\/p>\n

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||<\/code>
\nTente adivinhar o que est\u00e1 errado aqui<\/i><\/p>\n

Parece que algu\u00e9m pegou o prefixo de uma rota, dividiu-o em duas partes e anunciou uma rota com o mesmo AS_PATH para esses dois prefixos.<\/p>\n

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||
\nTABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0\/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_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||
\nTABLE_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||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||<\/code>
\nExemplos de rotas para um dos pares de prefixos divididos<\/i><\/p>\n

Levanta-se imediatamente v\u00e1rias perguntas. Algu\u00e9m realmente tentou na pr\u00e1tica esse tipo de intercepta\u00e7\u00e3o? Algu\u00e9m aceitou essas rotas? Quais prefixos foram afetados?<\/p>\n

Aqui come\u00e7a nossa s\u00e9rie de fracassos e mais uma rodada de decep\u00e7\u00e3o com o atual estado de sa\u00fade da Internet.<\/p>\n

Caminho de fracassos<\/h3>\n

\nVamos por partes. Como podemos determinar quais roteadores aceitaram esses roteadores interceptados e cujo tr\u00e1fego pode ser redirecionado j\u00e1 hoje? Pensamos em come\u00e7ar pelos prefixos \/25, porque 'simplesmente n\u00e3o podem ter uma dissemina\u00e7\u00e3o global'. Como voc\u00ea pode imaginar, est\u00e1vamos muito enganados. Essa m\u00e9trica se mostrou excessivamente ruidosa e roteadores com esses prefixos podem aparecer at\u00e9 mesmo de operadores Tier-1. Por exemplo, a NTT possui cerca de 50 desses prefixos que ela distribui entre seus pr\u00f3prios clientes. Por outro lado, essa m\u00e9trica \u00e9 ruim porque tais prefixos podem ser filtrados se o operador aplicar filtragem de pequenos prefixos<\/a><\/noindex>, em todas as dire\u00e7\u00f5es. Portanto, esse m\u00e9todo n\u00e3o \u00e9 adequado para encontrar todos os operadores cujo tr\u00e1fego foi redirecionado como resultado de tal incidente.<\/p>\n

Outra boa ideia que nos pareceu foi olhar para POV<\/a><\/noindex>. Em particular, para as rotas que violam a regra de maxLength do ROA correspondente. Assim, poder\u00edamos encontrar o n\u00famero de diferentes ASN de origem com status Invalid, que foram vistos por este AS. No entanto, h\u00e1 um 'pequeno' problema. A m\u00e9dia (mediana e moda) desse n\u00famero (n\u00famero de diferentes ASN de origem) \u00e9 de cerca de 150 e, mesmo se filtrarmos os pequenos prefixos, ela permanecer\u00e1 acima de 70. Essa situa\u00e7\u00e3o tem uma explica\u00e7\u00e3o bastante simples: h\u00e1 apenas alguns operadores que j\u00e1 aplicam filtros de ROA com a pol\u00edtica de 'descartar rotas Invalid' nos pontos de entrada, portanto, onde quer que uma rota com viola\u00e7\u00e3o de ROA apare\u00e7a no mundo real, ela pode se espalhar em todas as dire\u00e7\u00f5es.<\/p>\n

As duas abordagens finais permitem encontrar os operadores que observaram nosso incidente (j\u00e1 que foi grande o suficiente), mas, de forma geral, s\u00e3o inaplic\u00e1veis. Bem, mas podemos encontrar o respons\u00e1vel? Quais s\u00e3o as caracter\u00edsticas gerais dessa manipula\u00e7\u00e3o do AS_PATH? Existem algumas suposi\u00e7\u00f5es b\u00e1sicas:<\/p>\n