[GTER] Contato do AS28220

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

Na verdade Fernando o cara já deveria estar organizado com vlan de gerência
pra nem precisar deixar essa porta rodando de cara pra internet.

Em qui., 14 de nov. de 2024 às 14:47, Fernando Frediani via gter <
gter at eng.registro.br> escreveu:

> O duro que esse tipo de cenário faz algumas pessoas colocarem ACL de
> bloqueio de portas entrantes nos BNGs para não permitir tráfego entrante
> em portas comuns (22,80,443, etc) "para segurança" atrapalhando a vida
> de clientes tem necessidade de usar elas ao invés de fazer o certo e
> assegurar-se que as ONUs vão para os clientes com o firewall ligado.
>
> Fernando
>
> On 14/11/2024 14:05, Bruno Vane via gter wrote:
> > 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list