[GTER] Contato do AS28220

Fri Nov 15 13:06:24 -03 2024

"vítima", mais ou menos!

É obrigação do operador de ASN bloquear Spoofing de SEUS prefixos saindo de
SUA rede.
OBRIGAÇÃO DE CADA UM DE NÓS OPERADORES DE ASNs!

Em sex., 15 de nov. de 2024 às 02:36, Junior Corazza via gter <
gter at eng.registro.br> escreveu:

> Senhores,
>
> Nesse ataque o IP da vitima é spoofado e refletido no AS28220 (e em varios
> outros conforme foi dito aqui), isso quer dizer que em um servidor web que
> escuta na porta 443 não há muito que se fazer, mas se realmente for porta
> de gerencia de ONU aberta na internet basta fazer a ACL e resolver.
>
> Abracos.
>
> Junior Corazza
>
> From: gter <gter-bounces at eng.registro.br> on behalf of Lucas Willian
> Bocchi via gter <gter at eng.registro.br>
> Date: Thursday, 14 November 2024 at 13:03
> To:
> Cc: Grupo de Trabalho de Engenharia e Operacao de Redes <
> gter at eng.registro.br>
> Subject: Re: [GTER] Contato do AS28220
> Gustavo: o problema é que _não são eles_ lançando o ataque. Esses ips são
> spoofados, como explicado pelo Fred! São provedores que não possuem filtros
> em suas saídas e acabam deixando sair ip que _não são deles_ pra rede dos
> outros. Você tem a impressão que é de um determinado AS, mas se for ver a
> fundo o ataque pode estar sendo originado até mesmo em links
> _internacionais_ (aqui já chegamos a ver ataque vindo da Angola Cables).
> Entramos em contato com eles e falaram que não podem fazer nada para ajudar
> a não ser que seja algo judicial. Pois então, que seja! Mas também já
> encontramos provedores nacionais com problema. Tivemos um caso curioso de
> alguém que estava usando um mesmo provedor de trânsito que a gente em um
> colega, e o ataque estava chegando por dentro do backbone do mesmo. Foi
> fácil identificar. Aí entramos em contato com o dono do provedor que deu de
> ombros, falando que o volume do ataque é "muito pequeno" e "irrelevante".
> Irrelevante na saída dele, mas no destino estava saturando o link, e que
> inserir regras de firewall pra filtrar lixo saindo da rede dele "iria
> sobrecarregar o roteador de borda" (aquela clássica RB1100 que já está
> amarela de velha, com uma rotinha padrão lá). Aí fica complicado a gente
> tentar fazer algo sem que seja por força de lei ou causando dor de cabeça
> para o cara. Ele está tranquilo, usa CGNAT e ip do backbone pra tudo na
> rede dele (nem BGP não tem), e aí é cômodo pra esse pessoal simplesmente
> fechar a porta na tua cara.
>
> Em qui., 14 de nov. de 2024 às 12:14, Gustavo Santos via gter <
> gter at eng.registro.br> escreveu:
>
> > Já cheguei a entrar em conato, mas até então continuam usando eles como
> > refletores..
> >
> > Como não teve nenhuma ação por parte deles  até o momento, o que origina
> > estes syn/ack floods partindo deste ASN
> > são CPEs da Nokia com a porta 443 aberta ( Gerência) aberta para o mundo.
> > Coisa que uma ACL simples
> > na gestão da rede xPON deles resolveria.
> >
> > É só verificar no log do ataque, e acessar os hosts na porta 443...
> >
> >
> >
> > Em qui., 14 de nov. de 2024 às 12:09, Fred Pedrisa via gter <
> > gter at eng.registro.br> escreveu:
> >
> > > Bom dia, Bruno. **(Texto Retificado)**
> > >
> > >
> > >
> > >
> > > Apenas acrescentando no que já foi dito por ti, que embora muitos
> > > provedores não estejam seguindo as melhores práticas, esse caso dos
> > > ataques
> > > TCP SYN+ACK em específico, está ocorrendo até mesmo com grandes players
> > de
> > > cloud, como Google Cloud, Amazon AWS, Microsoft Azure e etc. Então acho
> > > que
> > > isso vai longe.
> > >
> > >
> > >
> > >
> > > Mas saliento que realmente pelo menos um registro do que anda
> ocorrendo,
> > > deveria ser feito pelas partes interessadas, quanto mais casos forem
> > > relatados melhor serão as evidências para que as autoridades possam se
> > > movimentar melhor a respeito, se ninguém reportar nada qualquer
> possível
> > > chance de melhorar esse cenário de alguma forma, deixa de existir.
> > >
> > >
> > >
> > >
> > > E embora nós sejamos um "fornecedor de soluções" nessa área, acredito
> que
> > > estamos aqui para atendermos problemas reais e não uma suposta "demanda
> > > artificial" que realmente é a impressão que fica de tudo isso.
> > > Principalmente considerando a quantidade de empresas que estão sofrendo
> > > "ao
> > > mesmo tempo" dessa mesma situação e sem qualquer "padrão ou conexão
> > > aparente" entre elas.
> > >
> > >
> > >
> > >
> > > Att,
> > >
> > >
> > > --
> > > Fred Pedrisa  - CEO / +55 (11) - 97177-7000
> > > HyperFilter DDoS Protection Solutions
> > > A FNXTEC Company
> > > https://www.hyperfilter.com/
> > > A 14 de novembro de 2024 12:05:14, Fred Pedrisa via gter
> > > <gter at eng.registro.br> escreveu:
> > >
> > > > Bom dia, Bruno.
> > > >
> > > > Apenas acrescentando no que já foi dito por ti, que embora muitos
> > > > provedores não estejam seguindo as melhores práticas, esse caso dos
> > > ataques
> > > > TCP SYN+ACK em específico, está ocorrendo até mesmo com grandes
> players
> > > de
> > > > cloud, como Google Cloud, Amazon AWS, Microsoft Azure e etc. Então
> acho
> > > que
> > > > isso vai longe.
> > > >
> > > > Mas saliento que realmente pelo menos um registro do que anda
> > ocorrendo,
> > > > deveria ser feito pelas partes interessadas, quanto mais casos forem
> > > > relatados melhor serão as evidências para que as autoridades possam
> se
> > > > movimentar melhor a respeito, se ninguém reportar nada
> > > >
> > > > E embora nós sejamos um "fornecedor de soluções" nessa área, acredito
> > que
> > > > estamos aqui para atendermos problemas reais e não uma suposta
> "demanda
> > > > artificial" que realmente é a impressão que fica de tudo isso.
> > > > Principalmente considerando a quantidade de empresas que estão
> sofrendo
> > > "ao
> > > > mesmo tempo" dessa mesma situação e sem qualquer "padrão ou conexão
> > > > aparente" entre elas.
> > > >
> > > > Att,
> > > >
> > > > --
> > > > Fred Pedrisa  - CEO / +55 (11) - 97177-7000
> > > > HyperFilter DDoS Protection Solutions
> > > > A FNXTEC Company
> > > > https://www.hyperfilter.com/
> > > > A 14 de novembro de 2024 11:40:27, Lucas Willian Bocchi via gter
> > > > <gter at eng.registro.br> escreveu:
> > > >
> > > >> Bom dia Bruno, tudo bem?
> > > >> A tempos atrás já falei sobre o problema no grupo. É um crime, e
> como
> > > tal,
> > > >> precisa ser investigado. Alguns de nossos parceiros provedores já
> > > abriram
> > > >> boletim de ocorrência na delegacia de crimes digitais para
> investigar
> > ou
> > > >> pelo menos fazer alguém tomar alguma atitude contra o problema, já
> que
> > > quem
> > > >> deveria fazer o dever de casa, ou seja, os provedores, não deixando
> > sair
> > > >> lixo da sua rede, não o fazem. A investigação já está bem
> encaminhada
> > e
> > > >> veremos onde vai dar. Se o "pula pirata" der resultado vai aparecer
> o
> > > >> engraçado que está fazendo isso. Pra mim é gente com interesse
> > comercial
> > > >> encima disso.
> > > >>
> > > >> Em qui., 14 de nov. de 2024 às 10:35, Bruno Vane via gter <
> > > >> gter at eng.registro.br> escreveu:
> > > >>
> > > >>> Bom dia senhores,
> > > >>>
> > > >>> Por acaso há um representante do AS28220 no grupo?
> > > >>> Temos recebidos ataques constantes deste ASN, do tipo SYN+ACK com
> SRC
> > > PORT
> > > >>> 443.
> > > >>> Já tentei entrar em contato com eles pelo e-mail
> > > noc at alaresinternet.com.br
> > > >>> mas sem resposta.
> > > >>>
> > > >>> AS28220 SYN+ACK Attack <https://imgur.com/a/XXsWeGK>
> > > >>> --
> > > >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >>>
> > > >> --
> > > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação