[GTER] [caiu] DDos em massa partindo de IPS nacionais

Sat Jul 28 11:01:16 -03 2018

Davi, os dois primeiros octetos são relativos aos ASes ‘atacados’.

Suponha que seu AS seja detentor do bloco 200.200.96.0/22.

As tentativas de brute-forcing vêm de IPs como 200.200.15.222, 200.200.122.9, 200.200.93.20, etc.

Foi só um exemplo.
Se o teu bloco é 45.7.x.x/22, as tentativas virão - majoritariamente - de IPs do 45.7.x.x/16
—-

Diego, 

Algumas vezes, sim.
É a CPE, o roteador depois da CPE...
Mas como citei, houve ataque vindo de servidores MS-SQL, DNS, NTP e outros tipos, quer comprovadamente estavam mau configurados.

Quando notifiquei os ASes, mandei um print da tentativa, contendo IP e porta de origem e destino. Também incluí informações sobre qual serviço estava comprometido e quais ações eram necessárias.

Em 4 casos - especificamente - o AS era atendido por alguma “EMPRESA” de gestão de provedores, a qual foi esculhambada pelo dono do ASN.

Os mesmos me ligaram e pediram desculpas pelo ataque e a confirmação de que eles haviam cessado.

Então, notificar é importante.
Mas notei que simplesmente notificar por notificar é uma falha, já que serviços mau configurados - em sua maioria - são ‘crias’ de leigos, que não sabem nem por onde começar para resolver o BO.

Desde quando passei a orientar - na notificação -, o percentual de resolução da falha no AS comprometido aumentou significativamente, bem como o feedback em relação às medidas que foram tomadas.

Raphael Pontara
+55 27 99252-5555 (Claro)
+55 27 99998-6904 (Vivo)

Em 28 de jul de 2018, à(s) 10:25, Diego Canton de Brito <diegocdeb at hotmail.com> escreveu:

> Posso estar errado, mas isso tem cara de CPE comprometida.
> 
> Quando você notifica, o outro ASN não sabe como resolver, ou quem está lá tem tanta coisa acumulada pra fazer que não dá atenção, e claro, tem os que não abrem o e-mail de abuse ou que mandam pra /deve/null, principalmente quando as notificações ficam mais frequentes.
> 
> Já tentaram verificar quais portas estão abertas nesses IPs?
> 
> 
> Obter o Outlook para Android<https://aka.ms/ghei36>
> 
> ________________________________
> From: gter <gter-bounces at eng.registro.br> on behalf of Raphael Pontara <pontara at outlook.com>
> Sent: Friday, July 27, 2018 10:01:01 PM
> To: Grupo de Trabalho de Engenharia e Operacao de Redes
> Subject: Re: [GTER] [caiu] DDos em massa partindo de IPS nacionais
> 
> Em todas as ocasiões em que mencionei o fato de que as tentativas de brute-forcing contra um AS vinham de IPs com os dois primeiros octetos IGUAIS, a maioria das pessoas levantou o argumento de spoofing.
> 
> Não só isso, uns mencionaram a ineficiência de um ‘ataque’ vindo APENAS de IPs parecidos e outros levantaram a ideia de que IPs parecidos geralmente estão sob o mesmo RIR/LIR, o que reforçaria a suspeita de spoofing.
> 
> Bem...
> 
> Durante minhas análises, pude notar uma outra ‘coincidência’, a de que os blocos ‘atacantes’ seguiam a sequência numérica designada a cada ASN (Ex: AS001, AS002, AS003, etc), saltando os ASes que não possuíam blocos ‘parecidos’ e, no caso dos ‘parecidos’ saltados, talvez estes não estivessem comprometidos.
> 
> É importante dizer que - SIM - estes blocos tentavam iniciar a conexão e nos casos em que o equipamento serviu de isca, o atacante (com o bloco parecido) realizou o ‘aperto de mãos’ e ‘se despediu’ em seguida.
> 
> Não posso afirmar que seja algo restrito às terras Tupiniquins, pois não tive a oportunidade de observar este ‘fenômeno’ em outras nacionalidades.
> 
> Porém, o fato marcante de seguir uma sequência E, usar blocos parecidos, levanta a hipótese de que o atacante quer explorar ‘dedos gordos’ que deixaram passar um /16 no lugar de um /22 ou /20.
> 
> Há outras possibilidades, claro.
> Mas não me aprofundei o suficiente para afirmar nada além do que vi.
> 
> E posso garantir que não estou falando ‘leiguices’.
> 
> Raphael Pontara
> +55 27 99252-5555 (Claro)
> +55 27 99998-6904 (Vivo)
> 
> Em 27 de jul de 2018, à(s) 20:20, Fred Pedrisa <pedrisa at hyperfilter.com> escreveu:
> 
>> Aí depende muito... Se forem conexões TCP capazes de realizar o 3WH, vão realmente ser maquinas comprometidas, não se tratando de spoofing (neste caso, como eles mesmos disseram, brute forcing).
>> 
>> IPs Spoofados não conseguem fechar o Handshake do TCP jamais. :)
>> 
>>> On 27/07/2018 14:02, Antonio Carlos Pina wrote:
>>> Pessoal, só não esqueçam que em se tratando de ataque DDoS, os IPs podem
>>> ser esses mas também podem não ser. Ataques spoofing são muito mais comuns.
>>> ou seja, o ataque pode estar vindo da Coreia do Norte com os IPs do UOL e
>>> não se pode acreditar piamente que é do UOL. Pode falar com o administrador
>>> mas entendendo que pode não ser real.
>>> 
>>> Abs
>>> 
>>> Em 27 de julho de 2018 13:20, Rafael Galdino <sup.rafaelgaldino at gmail.com>
>>> escreveu:
>>> 
>>>> meu xará Raphael. já tenho um caso parecido cliente com o 143.255.x.x ai
>>>> tem um cara no mesmo octeto, digo o primeiro e segundo, o cara é
>>>> diretoooooo telnet e ssh para a rede desse meu cliente, já consegui ate o
>>>> WhatsApp do dono, reportei, expliquei, mandei print. sabe a resposta?
>>>> 
>>>> vou verificar...
>>>> ai mando depois perguntando e ai conseguiu bloquear?
>>>> 
>>>> resposta: .... .... .......
>>>> 
>>>> enfim o povo acha que ter provedor é: ping abrir facebook e já era
>>>> 
>>>> Em sex, 27 de jul de 2018 às 13:10, Raphael Pontara <pontara at outlook.com>
>>>> escreveu:
>>>> 
>>>>> Thiago, só aproveitando o gancho.
>>>>> 
>>>>> Eu gostaria de relatar que percebi um comportamento parecido quando ativo
>>>>> assinantes de link dedicado nos provedores que atendo.
>>>>> 
>>>>> Curiosamente, clientes residenciais - que se conectam por PPPoE - não
>>>>> apresentam a mesma dinâmica.
>>>>> 
>>>>> Trata-se do seguinte:
>>>>> Ao ativar o cliente corporativo com IP estático na interface de acesso,
>>>>> basta estabelecer rota default no cliente e o tráfego da porta “TOPA”
>>>>> (limitado ao controle de banda setado no cliente) no sentido de upload
>>>> (do
>>>>> cliente para fora) por aproximadamente 10 segundos
>>>>> 
>>>>> Imediatamente também ocorre brute-force, vindo de IPs com o primeiro e o
>>>>> segundo octetos IGUAIS aos do cliente ativado (obviamente, o terceiro e o
>>>>> quarto são diferente).
>>>>> 
>>>>> Isso me chamou a atenção e resolvi coletar algumas informações.
>>>>> 
>>>>> Para minha surpresa, a maioria dos ASes que realizam brute-force (com o
>>>> 1º
>>>>> e 2º octetos iguais ao do AS atacado), são do Brasil e de fato estavam
>>>>> comprometidos.
>>>>> 
>>>>> Não consegui - ainda - coletar o que sai do cliente recém ativado.
>>>>> Na próxima ativação eu pretendo coletar com o wireshark ou outra
>>>>> ferramenta.
>>>>> 
>>>>> Raphael Pontara
>>>>> +55 27 99252-5555 (Claro)
>>>>> +55 27 99998-6904 (Vivo)
>>>>> 
>>>>> Em 27 de jul de 2018, à(s) 09:50, THIAGO AYUB <thiago.ayub at upx.com>
>>>>> escreveu:
>>>>> 
>>>>>> Olá Rafael,
>>>>>> 
>>>>>> 
>>>>>> Esse assunto é off-topic para a lista CAIU e mas é on-topic na GTER.
>>>>>> 
>>>>>> Isso acontece o tempo todo. Já há alguns anos quando acompanho algum
>>>>>> prefixo que nunca foi anunciado na tabela global de roteamento assim
>>>> que
>>>>>> ele o é pela primeira vez, em segundos (5 ou menos) já vejo brute force
>>>>>> chegar. É tão certeiro que suponho que exista sim gente monitorando os
>>>>>> anúncios na tabela global para focar brute force em sistemas autônomos
>>>>>> recém-inaugurados, mal configurados etc.
>>>>>> 
>>>>>> A conduta correta é reportar todos os casos. Fazemos isso para os
>>>>> endereços
>>>>>> que constam no WHOIS dos IPs (e sinto falta de um explícito contato de
>>>>>> ABUSE nos registros brasileiros). Somente neste ano cerca de 26% dos AS
>>>>>> brasileiros já receberam algum abuse report nosso. Mas a esmagadora
>>>>> maioria
>>>>>> faz pouco caso, ignora, não responde, não toma providências. Seguem a
>>>>>> errônea filosofia do "Se meu cliente não tá reclamando, não tenho que
>>>>> tomar
>>>>>> providências.".
>>>>>> 
>>>>>> Diante disso, passamos a reportar os casos para várias blacklists as
>>>>> quais
>>>>>> temos convênio para relatar incidentes, como por exemplo a
>>>>>> https://www.abuseipdb.com/user/15015 que é patrocinada pela
>>>>> DigitalOcean.
>>>>>> Temos obtido com essas inclusões em blacklists os melhores resultados,
>>>> já
>>>>>> que os IPs citados param de conseguir acessar servidores de IRC,
>>>> passam a
>>>>>> ter e-mails rejeitados, não entram mais em servidores de jogos e até
>>>>> alguns
>>>>>> tribunais de justiça brasileiros rejeitam o login de IPs nessas
>>>>> blacklists.
>>>>>> Aí sim os clientes do ISP/datacenter começam a reclamar e o responsável
>>>>>> pelo AS toma as devidas providências.
>>>>>> 
>>>>>> Abraços,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> *Thiago Ayub *| Network Director
>>>>>> 
>>>>>> +55 (11) 2626-3952 <(11)%202626-3952>
>>>>>> upx.com
>>>>>> 
>>>>>> 
>>>>>> 2018-07-26 3:04 GMT-03:00 Rafael VOlpe TI <rafaelvolpeti at gmail.com>:
>>>>>> 
>>>>>>> Bom dia galera,
>>>>>>> 
>>>>>>> mais alguém tem enfrentado ataques DDos (Geralmente em Webservers), em
>>>>>>> LARGA escala (mais de 5000 ips nacionais - Vivo/Claro/Ctbc) para
>>>>> aplicações
>>>>>>> WEB?
>>>>>>> 
>>>>>>> Rapaz, eu tenho recebido muito, mais muito ataque de bots partindo
>>>>> desses
>>>>>>> endereços.
>>>>>>> Geralmente atacam WEB/Banco/Ftp, tudo junto.
>>>>>>> 
>>>>>>> Mais alguém tem enfrentado isso? As operadoras tem feito algo sobre
>>>>> isso?
>>>>>>> Abraços.
>>>>>>> _______________________________________________
>>>>>>> caiu mailing list
>>>>>>> caiu at eng.registro.br
>>>>>>> https://eng.registro.br/mailman/listinfo/caiu
>>>>>>> 
>>>>>>> 
>>>>>>> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
>>>>>>> 
>>>>>>> https://eng.registro.br/mailman/options/caiu
>>>>>>> 
>>>>>> --
>>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>> --
>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>> 
>>>> 
>>>> --
>>>> 
>>>> *Rafael Galdino*
>>>> 
>>>> 
>>>> *      Analista de redes*
>>>> 
>>>>       Inoc: 265147*100
>>>> 
>>>>      Phone:
>>>> 
>>>> *+55 (83) 99600-0242*
>>>> --
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>> 
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>> 
>> --
>> Fred Pedrisa - CEO/CTO
>> HyperFilter DDoS Protection Solutions
>> A FNXTEC, Company.
>> https://www.hyperfilter.com
>> 
>> --
>> 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