[GTER] Contato do AS28220

Lucas Willian Bocchi lucas.bocchi at gmail.com
Thu Nov 14 14:07:57 -03 2024 

Entendi pessoal. Agora, com mais detalhes, vejo que é o perfeito exemplo do
provedor sem gerência e mal administrado. Esse tipo de coisa é que ajuda a
disseminar o problema.


Em qui., 14 de nov. de 2024 às 14:06, Bruno Vane via gter <
gter at eng.registro.br> escreveu:

> Boa tarde pessoal,
>
> Como foi dito aqui, o ataque não se origina neles, sabemos disso, porém
> como bem apontado pelo Gustavo, são ONU da Nokia com gerência aberta na
> 443.
> Quem em sã consciência deixa a gerência de suas ONU em IP público e sem
> nenhum firewall?
> Não está *ainda* afetando minha rede, temos banda sobrando e também temos
> mitigação DDoS em nuvem, mas esse não é o ponto, o ponto é o cara não fazer
> o básico e nem se dar ao trabalho de colaborar.
>
>
> Em qui., 14 de nov. de 2024 às 13:42, Gustavo Santos via gter <
> gter at eng.registro.br> escreveu:
>
> > 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
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list