[GTER] Contato do AS28220

Thu Nov 14 13:42:18 -03 2024

Lucas,

Eu sei que eles não estão "lançando" o ataque, porém como comentei, eles
tem as CPE abertas para o mundo.
O que facilita qualquer um a enviar requisições com a origem spoofed (
destino do ataque).

No caso deles o tráfego vem deste ASN pois como informei anteriormente é só
fazer o teste, e vai acessar
as CPE Nokia... E como disse, se eles filtrarem requisições de fora da
rede, ou simplesmente desativar o acesso
a GUI de gerência via WAN, mitigar este problema que eles estão causando
indiretamente.

E é claro que também existe o caso que comentou, de até a origem ser
spoofed, no caso de equipamentos infectados como
As famigeradas caixinhas de IPTV Pirata que podem sim originar ataques com
qualquer endereço IP mesmo não pertencendo a rede.

Mas no caso do AS da thread, existe realmente uma falta de colaboração e
pelo tamanho e volume ( já chegou por aqui partindo deste ASN quase
20Mpps ( milhoes de pacotes por segundo)).

Em qui., 14 de nov. de 2024 às 13:03, Lucas Willian Bocchi via gter <
gter at eng.registro.br> escreveu:

> 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
>