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

Raphael Pontara pontara at outlook.com
Sat Jul 28 12:28:58 -03 2018 

Certo, Davi.

Foi - também - com base neste TXT que eu constatei que as tentativas chegavam na sequência de numeração atribuída ao AS.

Assim que comecei a analizar os cenários que encontrei, eu realizava pesquisas manuais em alguns sites como qrator e bgp.he, bem como ao whois do registro.br.

Quando detectei este padrão (sequência), busquei por alguma base que pudesse fornecer estes dados, como no TXT disponível no ftp do Registro.br.

Daí pra frente, ficou mais fácil relacionar a nacionalidade dos IPs de origem e verificar que eles seguiam a tal sequência.

Dentre os IP que recebiam brute-forcing de IPs de blocos parecidos, posso citar 192.140.x.x, 45.7.x.x, 177.55.x.x, 128.201.x.x, dentre outros.

Já se a pergunta é relacionada às origens que tentaram contra um dos blocos acima, ou seja, se elas fazem parte do mesmo RIR/LIR, a resposta é sim. Comprovadamente.

Em pouquíssimos casos o - exemplo - 128.201.x.x vinha de outro país/região.


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

Em 28 de jul de 2018, à(s) 12:05, Davi Nunes <cahet.davi at gmail.com> escreveu:

> @Raphael, eu sei.
> 
> Eu perguntei, pois, iria verificar se de alguma forma eles estavam usando
> uma base irr ou até mesmo alguns anúncios recentemente disponibilizados em
> txt
> 
> Em sáb, 28 de jul de 2018 às 11:12, Raphael Pontara <pontara at outlook.com>
> escreveu:
> 
>> 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
>> --
>> 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