[GTER] Contato do AS28220

Tue Nov 19 17:16:24 -03 2024

Aoba Bruno!

Então... Tava relendo minha mensagem aqui, e realmente me expressei de
maneira horrível! Foi resultado de um "dom" que eu tenho... Que é de ser
grosseiro quando estou querendo ser conciso.

Vou tentar me explicar melhor:
- O ataque é de reflexão de SYN/ACK através de spoofing do host que abre a
conexão.
- Resumindo muito, existem 4 figuras nesse ataque:
A- A rede que está sendo atacada.
B- A rede que está sendo usada para refletir o ataque.
C- A maledeta da rede que está deixando um spoofing sair de sua rede.
D- O atacante que é um fébi-du-rato!

"E agora Douglas? Vai dizer de quem é a culpa?"
Vou sim! Mas vamos como o Jack Estripador... Por partes.

Antes de mais nada, falar de "culpa" só pelo prazer sádico de achar
culpados e apontar o dedo é coisa de pessoas más!
Objetivo de analisar "culpa" deve ser muito parecido com como é na aviação,
onde se procura achar onde ocorre/ocorreu o erro, e fazer com que ele não
aconteça mais.

Nesse thread aqui, tem um monte de "culpas" sobre as quais devemos nos
atentar.

TL;DR.
1ª - Não responder contato de ABUSE.
2ª - Não ter um monitoramento de comportamento anômalo em sua rede.
3ª - Não implementar políticas de filtragem de tipos de tráfego, com a
possibilidade de OPT-OUT.
4ª - (Mais Grave) Não implementação de filtros anti-spoofing conforme BCP38.

A primeira "culpa" decorre da falta de resposta de algumas entidades para
os contatos de Whois, especialmente os contatos de ABUSE.
Isso ficou bem evidente, e foi até como o Bruno abriu esse thread.
Isso é um problemão! E a meu ver, tem que ser reportado ao CERT.BR, pois
existe no LACNIC uma política de validação de contatos de ABUSE, e se algo
não está funcionando nisso temos que fazer saber de maneira formal quem
pode intervir para ajudar a melhorar esse processo.
Obs.: Eu tenho notado(aqui nas estatísticas só da minha cabeça) que esse
problema com ABUSE sem dono acontece com muito mais frequência em empresas
que passaram ou estão passando por fusões e consolidações. Alguém tem o
mesmo sentimento?

A segunda "culpa" decorre de organizações que, sendo prestador de serviço
de conectividade Internet, não terem implementado ferramentas de
monitoramento que lhe indiquem que existe um tráfego anômalo em sua
infraestrutura.
Denovo uso exemplo da aviação: Vocês achariam "OK" uma empresa de aviação
que não monitora os indicadores de como se comportam seus aviões?
E uma empresa que tem um zilhão de PPS em conexões half-open e nem percebe
que isso tá acontecendo?
"Ahhh Douglas, mas nem todo mundo tem como fazer isso..."
Ah... Pera lá! Existem umas 4-5 maneiras de se ter indicadores para isso. A
melhor obviamente é que a empresa que está sendo usada como reflexão tenha
uma ferramenta de análise de flow configure indicadores para isso.
E existem outras formas indiretas de se chegar a essa conclusão, como por
exemplo com monitoramento TR-069/CWMP e ver como anda a memória RAM dos
CPEs.
Mais simples que isso? Gráfico de upload dos seus clientes obtido via SNMP
de pps e bps com uma baita anomalia na curva.
Mesmo com equipamentos mais baratos, ou até os mais renomados podem fazer
coisas assim. E isso tudo pode ser feito com ferramentas pagas ou
OpenSource.
Então, se os dispositivos de sua rede estão fazendo reflexão e você nem tá
sabendo disso, você não está sendo um bom operador de rede.

A terceira "culpa" é sobre deixar os webservers dos CPEs abertos, de cara
pra rua, sem nenhuma restrição.
Existem 2 extremos num range grande de possíveis postura sobre isso:
- Um são entidades relapsas que não fazem nenhum tipo de controle de nenhum
tipo. Deixam tudo escancarado, de cara pra rua.
- Outro são entidades que tem atitudes de filtragem extrema e resolvem
bloquear tudo e o usuário que se lasque.
Nem um nem outro extremos são aceitáveis!
Existem diversas maneiras de se resolver isso. O ideal (a meu ver) é que
regras de firewall no B-RAS sejam(de maneira direta ou indireta)
dinamicamente definidas para cada cliente dependendo de flags no ERP. Mais
isso entra numa briga monstra que alguns aqui conhecem. Mas com alguma
organização num bom plano de endereçamento e regras por blocos de IP
pode-se resolver isso.
Mas além da possibilidade de resolver isso no B-RAS, pode-se resolver isso
também com uma simples regra de firewall nos CPEs. Tem muitas possíveis
implementações disso, mas é necessário lembrar que para não funcionar como
reflexão de SYN/ACK essa regra tem que impedir que qualquer pacote que não
seja originado pela lista de IPs confiáveis seja sequer respondido.
Aplicar essas regras dá um trabalhão! E para isso recomendo denovo o
TR-069/CWMP.

- A quarta "culpa" é de redes que não implementam o BCP38, principalmente
os filtros anti-spoofing. Éa mais grave na minha opinião, é e de onde saiu
o tiquinho de raiva que me fez me expressar pessimamente na minha outra
interação nesse thread.
Se não tivéssemos redes/ASNs relapsos que não implementam spoofing, eu
afirmo que esse ataque de reflexão de SYN/ACK não ocorreria!

Pra quem ficou curioso como esse tal ataque acontece, Vou tentar explicar
com palavras simples. Peço compreensão dos mais experientes sobre uso
inadequado de termos e técnicas.

Começamos lembrando do triple handshake de TCP
1- A manda um "olá! para o B.
2- B manda um "olá recebido. vai aqui meu olá!" para o A
3- A manda um "olá recebido" para o B

Esse acima é o jeito "certo" de acontecer...
Mas se um equipamento X comprometido e capaz de fazer spoofing enviar um
"olá" para o B fingindo ser o A, o B vai responder para o A verdadeiro, e o
A verdadeiro vai receber um pacote que ele nem sabe de onde veio.
E se o X mandar 1000 desses "olás!"?
E se existirem centenas de milhares de equipamentos comprometidos e capazes
de fazer Spoofing assim como o X?

Pronto, essa é a explicação do tal ataque de reflexão de SYN/ACK através de
spoofing.

Se eu falei alguma bobagem aqui, peço a gentileza de me ajudar a
corrigir-me.

Na Internet, principalmente no que diz respeito a DDoS, as suas atitudes
vão ter muito mais efeito protegendo outras redes que a sua. Logo, a
segurança de sua rede depende de ações de outros operadores de rede.

Em sáb., 16 de nov. de 2024, 19:30, Bruno Vane via gter <
gter at eng.registro.br> escreveu:

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