[GTER] Contato do AS28220

Sat Nov 16 19:29:26 -03 2024

Douglas,

Acho que você viajou aí na sua contribuição.
Veio seco pra criticar e não entendeu o que está acontecendo,

Em sex., 15 de nov. de 2024 às 13:06, Douglas Fischer via gter <
gter at eng.registro.br> escreveu:

> "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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>