[lacnog] Hijack de prefixo em IRR
Darwin Da Costa
dacostadarwin en gmail.com
Mar Sep 10 17:54:11 -03 2019
@BPF team & All,
Acabei de ver os meus records e será que o artigo abaixo não ajuda a todos aqueles que tenham dificuldades?
https://wiki.brasilpeeringforum.org/w/MANRS#IRR_Internet_Routing_Registry
Bastante detalhado.
Se os maiores IX(es) internacionais já validam a origem via IRR e alguns (ex: DE-CIX) https://www.de-cix.net/en/locations/germany/frankfurt/routeserver-guide IRR+RPKI imaginem quando o Facebook, Amazon e outros começarem a fazer.
Best Regards,
Cumprimentos,
Darwin-.
> On Sep 10, 2019, at 22:12, Darwin Da Costa <dacostadarwin en gmail.com> wrote:
>
> Douglas,
>
> Muito obrigado pela partilha e análise a fundo dos casos anteriormente espelhados.
>
> Como se não bastasse “routing-hijack” agora vamos partir para o “IRR-hijack”... Insane....
>
> Pior é que o anteriormente dito é verdade: Apenas no futuro, depois de ter uma melhor referência de qual o tamanho do dragão com que terão que lutar, é que decidirão como esses prefixos serão descartados.
>
> @BPF team, escrever um artigo “on how to do it” não seria uma mais valia?
>
> Best Regards,
> Cumprimentos,
> Darwin-.
>
>> On Sep 10, 2019, at 21:51, Luis Balbinot <luis en luisbalbinot.com> wrote:
>>
>> Ótimo trabalho! Eu também gostaria de entender essa lógica. Aqui na empresa fazemos cadastro de proxy quando não existe entrada, mas muitas vezes elas existem e estão erradas. Olha o exemplo do prefixo 177.152.184.0/22 de um de nossos ASs abaixo. Ele está registrado como proxy por nós (MAINT-AS14840), mas aparece com o AS errado em outras duas.
>>
>> $ whois -h whois.radb.net 177.152.184.0/22
>> route: 177.152.184.0/22
>> descr: Vultr Customer Route
>> origin: AS264409
>> notify: network en choopa.com
>> mnt-by: MAINT-AS20473
>> changed: network en choopa.com 20190603 #12:36:37Z
>> source: RADB
>>
>> route: 177.152.184.0/22
>> descr: This is a Commcorp Telecom customer proxy route object that was created because no existing route object with the same origin was found. Please contact noc en commcorp.com.br if you have any questions regarding this object.
>> origin: AS61889
>> mnt-by: MAINT-AS14840
>> changed: gacosta en commcorp.com.br 20151028 #11:12:00Z
>> source: RADB
>>
>> route: 177.152.184.0/22
>> descr: G8 Networks
>> origin: AS264409
>> mnt-by: MAINT-AS28329
>> changed: no-reply en g8.net.br 20190909
>> source: BBOI
>>
>> Me parece que tem alguém utilizando o IRR com outra finalidade e pedindo o cadastro desses objetos por algum motivo bizarro.
>>
>> Luis
>>
>>
>>> On Tue, Sep 10, 2019 at 4:37 PM Douglas Fischer <fischerdouglas en gmail.com> wrote:
>>> TL-DR;
>>> ------
>>> - Vários ASNs registrando em IRRs prefixos de seus clientes como se fosse de seus ASNs.
>>> - Principalmente no RADB.
>>> - Está gerando sujeira nas bases de IRR.
>>> - Prefix-lists geradas automaticamente estão ficando muito longas, consumindo recurso do routers.
>>> - Impossibilita a validação de AS-Path.
>>>
>>> Fizemos uma consulta nos IRR dos prefixos delegados pelo NIC.BR que estavam registrados para outros ASNs.
>>> Agrupamos esses prefixos pelo campo maintainer e contamos a quantidade. Segue a lista dos mais significativos:
>>> Quantidade - Maintainer
>>> 2686 - MAINT-AS8966
>>> 865 - MAINT-AS18678
>>> 604 - MAINT-AS28283
>>> 494 - MAINT-AS28329
>>> 453 - MAINT-AS20473
>>>
>>> Este é o Link para a planilha com as informações.
>>> https://drive.google.com/file/d/1KFUfptAnZsAmbSVvVFyHK8bPH7yrOOhr/view?usp=sharing
>>> Lá consta uma planilha dinâmica, e também planilhas com o detalhado dos 5 Mantainers com mais registro errados.
>>>
>>>
>>> Contando a historinha do problema
>>> -----------------------------------
>>> Há cerca de uns 4 meses, um amigo identificou que algumas empresas brasileiras estavam fazendo registros ERRADOS nos IRRs.
>>> Ele me passou a informação e eu fiquei bastante triste com o que vi.
>>>
>>> O procedimento deles era:
>>> - Listar todos os prefixos do cone de AS do cliente deles
>>> - Registrar como sendo de seu próprio ASN.
>>>
>>> Eu pessoalmente entrei em contato por telefone com algumas dessas empresas, e questionei o porque de eles fazerem isso.
>>>
>>> A resposta deles foi:
>>> "Muitos desses prefixos já estão registrados como proxyed por outros ASNs, e quando tentamos registrar esses prefixos, não conseguimos... Então registramos como nossos."
>>> - Eu expliquei a eles porque fazer esse registro como seu próprio ASN era errado, que era uma solução grosseira e de força bruta.
>>> - Mencionei que dependendo de como as empresas consultem as bases de IRR isso iria fazer com que os as prefix-Lists geradas automaticamente ficassem com entradas duplicadas, muito longas, aumentando os recursos de processamento dos routers para processar as mensagens de anúncio de rotas.
>>> - E expliquei também que isso iria prejudicar os próximos passos de segurança de roteamento, que é a validação de caminho(além da de origem).
>>>
>>> Felizmente por algumas empresas essa informação foi muito bem recebida.
>>> Inclusive desenvolvi relação de amizade por conta disso com um técnico dessas empresas.
>>> Tive a oportunidade de sugerir que no script de automação deles incluíssem o teste:
>>> (Se prefixo já existe registrado, usa registro atual.
>>> Se prefixo não existe registrado, cria registro como proxyed.)
>>>
>>> Infelizmente, algumas poucas empresas encararam a crítica negativamente.
>>> - Alguns me atenderam, fizeram mil elogios por telefone, se comprometeram a corrigir, e não fizeram nada.
>>> - Alguns se sentiram ofendidos com a crítica(se sentiram ofendidos, e me ofenderam).
>>> - Alguns nem se deram ao trabalho de responder.
>>>
>>>
>>> O problema só está aumentando!
>>> ------------------------------
>>> Observando a lista dos TOP-5, podemos ver que o MAINT-AS8966 - Emix - Emirates Telecommunications - está no topo da lista, com mais do que 3 vezes mais prefixos errados que o segundo colocado.
>>>
>>> Bom, eu confesso que não entendi direito qual é o objetivo desses registros...
>>> Mas a grande maioria(talvez até a totalidade) dos prefixos estão com a "descr: ChinaTel via EMIX".
>>>
>>> Outra coisa que só aumentou as minhas dúvidas é que existem casos em que o MAINT-AS8966 registrou um prefixos para vários Origin.
>>> Como é o caso do prefixo 45.70.72.0/22, que está registrado pela EMIX para AS266319, AS52965, AS53144.
>>> https://www.radb.net/query?advanced_query=&keywords=45.70.72.0%2F22&-T+option=&ip_option=&-i+option=
>>>
>>> Segue uma lista dos Prefixos Brasileiros registrados pelo MAINT-AS8966.
>>> Quantidade AS-Origin IRR
>>> 773 AS61832 RADB
>>> 475 AS53144 RADB
>>> 450 AS52965 RADB
>>> 313 AS52551 RADB
>>> 154 AS52720 RADB
>>>
>>> Alguém conseguiu entender a lógica disso?
>>> Isso está correto?
>>> Se não está correto, quem deve ser acionado para corrigir?
>>>
>>> Porque estou cutucando isso agora?
>>> ----------------------------------
>>> O Google, em seus GGCs e PNIs, começou a fazer filtrar prefixos baseado em registros de IRR.
>>> Isso foi informado em maio [1][2] deste ano no Lacnic 31 pelo Sr. Arturo.
>>> E os triangulozinhos de alerta nos prefixos mostrados em https://peering.google.com/ estão gerando um alvoroço entre os ISPs.
>>> E eu estou feliz por isso!
>>> Depois de 20 anos de RPSL, os ASNs estão se preocupando em cadastrar seus prefixos corretamente nos IRRs.
>>>
>>> Eu acredito que o medo de ficar sem acesso ao ASN do Google é que está desencadeando essas ações um pouco desesperadas...
>>>
>>> P.S.1: Tenham calma!
>>> Segundo informações do próprio Google, por enquanto esses prefixos estão apenas sendo tageados.
>>> Apenas no futuro, depois de ter uma melhor referência de qual o tamanho do dragão com que terão que lutar, é que decidirão como esses prefixos serão descartados.
>>>
>>> P.S.2: Reitero meu agradecimento ao Google por isso!
>>> E aproveito para provocar Facebook, Cloudflare, Netflix, e até o ICCAN, a fazerem o mesmo.
>>>
>>> [1] https://www.lacnic.net/innovaportal/file/3635/1/26-route-filtering-at-the-edge-as15169.pdf
>>> [2] https://youtu.be/OT9at07N7qM
>>>
>>> --
>>> Douglas Fernando Fischer
>>> Engº de Controle e Automação
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190910/659205c4/attachment-0001.html>
Más información sobre la lista de distribución LACNOG