[GTER] Incidente (possível) Layer2 em circuito de operadora sendo atacado

Raphael Pontara pontara at outlook.com
Sun May 27 21:05:39 -03 2018


Paulo, infelizmente o AS é atendido apenas por uma operadora e não há viabilidade técnica para a contratação de outro fornecedor.

Sendo assim, reitero que o ataque ocorre sem que haja sequer um IP na interface ou então, mesmo que a mídia seja colocada em outro equipamento. (Sem IP, outro MAC).

O incidente faz com que a interface fique saturada, impossibilitando sequer uma tentativa de manipulação de anúncios.

Detectamos também que a saturação não gera registro de logs específicos para os IPs do BGP nem do AS.

Em tempo, antes de subir o BGP no novo circuito, fizemos a preparação dos anúncios do nosso /32 do /30 de enlace, bem como a inclusão de todo o /30 usado anteriormente com a operadora, na tentativa de subir uma sessão ‘limpa’ e com o nosso IP de enlace ‘indisponível’ para fora.

No entanto, ‘a paz’ durou menos de 27 horas.

Hoje mesmo, ocorreu em intervalos de uma hora.

Lamentável.



Raphael Pontara
+55 27 99252-5555 (Claro)

Em 27 de mai de 2018, à(s) 18:44, Paulo Henrique <paulohenriquef at gmail.com> escreveu:

> Existe conectividade por outra operadora? Se sim, vc pode manipular dar
> seus anúncios para esta outra operadora e então verificar se o
> comportamento vai migrar para esta operadora q certamente está em outra
> interface ou se este comportamento vai cessar.
> 
> Se realmente vc estiver diante de um DDoS o comportamento deve persistir na
> outra operadora, exceto é claro se ela tiver algum recurso para "limpar" o
> tráfego.
> 
> Vamos conversando pra tentar esclarecer isso.
> 
> Paulo Henrique Fonseca - mobile
> 
> Em dom, 27 de mai de 2018 14:27, Raphael Pontara <pontara at outlook.com>
> escreveu:
> 
>> Sim, é possível.
>> 
>> Você poderia exemplificar qual seria informação - diferente do que eu
>> mencionei - que você gostaria de ter?
>> 
>> De repente, pode ser algo que eu não tenha notado, mas no Torch aparecem
>> várias origens com destino ao meu IP do /30 com a Oi (a maioria) e alguns
>> destinos diferentes do /30 e dos blocos do AS em questão.
>> 
>> 
>> Raphael Monteiro
>> +55 (27)99252-5555 (Claro)
>> 
>> 
>> Em 27 de mai de 2018, à(s) 11:18, savio.marques <
>> savio.marques at sustentatelecom.com.br> escreveu:
>> 
>>> Seria possível enviar a imagem do touch?
>>> 
>>> 
>>> Enviado do meu smartphone Samsung Galaxy.
>>> -------- Mensagem original --------De: Raphael Pontara <
>> pontara at outlook.com> Data: 26/05/18  14:00  (GMT-04:00) Para:
>> gter at eng.registro.br Cc: ld-numeracaoip at oi.net.br, ouvidoria at anatel.gov.br,
>> abuse at oi.net.br Assunto: [GTER] Incidente (possível) Layer2 em circuito
>> de operadora sendo atacado
>>> Olá a todos,
>>> 
>>> 
>>> Estou envolvido na tentativa de resolução de um incidente com o circuito
>> IP de um cliente Oi.
>>> 
>>> 
>>> Inicialmente, o incidente estava sendo tratado como um possível ataque
>> DDoS, mas após alguns procedimentos de troubleshooting, foi verificado que
>> o circuito também recebia tráfego que não era direcionado nem ao /30 de
>> enlace com a Oi nem ao AS.
>>> 
>>> Inclusive, não é possível sequer estabelecer uma conexão com uma
>> mitigadora de ataques, já que o incidente compromete o Layer 2 do circuito.
>>> 
>>> 
>>> Em resumo, o equipamento fica com a WAN saturada, mesmo sem haver fluxo
>> (todas as interfaces do equipamento estão desativadas, com exceção da
>> interface ligada à operadora), conforme a imagem neste link
>> https://ibb.co/ghxxmT
>>> 
>>> 
>>> 
>>> O incidente perdura por 22 dias consecutivos e contém as seguintes
>> características:
>>> 
>>> 
>>> 1 - Ocorrência apenas no período entre 7:00 e 23:00 (UTC-4:00);
>>> 
>>> 2 - Atividade: tempo exato em horas, ocorrendo por uma ou três horas
>> consecutivas, com intervalos de uma hora quando o incidente ocorre por três
>> horas e o contrário quando o incidente ocorre por uma hora. Também há a
>> ocorrência em horas alternadas (hora sim, hora não);
>>> 
>>> 3 - Frequência de atividade:  4 à 8 vezes por dia;
>>> 
>>> 4 - Procolos: TCP, UDP, ICMP;
>>> 5 - Portas: Predominância de portas com dígitos repetidos como 5555,
>> 6666, 7777, 8888, 6688, 1122, etc;
>>> 6 - Foram capturados pacotes com destino ao nosso enlace e ao AS, mas
>> também para outros destinos na porta 6 UDP e TCP;
>>> 7 -Sintoma: Tráfego no sentido de download da interface física, no valor
>> máximo admitido pela interface;
>>> 7 - Tráfego com destino a outros IPs que não são do /30 do BGP nem dos
>> IPs do AS;
>>> 
>>> Características do cenário:
>>> 
>>> 1 - Equipamento: MikroTik CCR1036-12G-4S (RouterOs 6.40.8 BugFix -
>> Firmware 3.41)
>>> 2 - Gbic: HG Genuine MXPD-243S
>>> 3 - Portas do equipamento testadas: sfp1 a sfp4
>>> 4 - Segundo equipamento utilizado no TS: MikroTik CCR1036-12G-4S
>> (RouterOs 6.42.1 Current - Firmware 6.42.1)
>>> 
>>> Explanação sobre o fato:
>>> 
>>> - Foi percebido  tráfego em máxima capacidade da interface e para tentar
>> cessar o tráfego, a vlan entre o ISP e a Operadora foi desativada.
>>> Porém, o tráfego não cessava.
>>> 
>>> - Foram desativadas as demais interfaces que estavam ativas no
>> equipamento, com exceção das interfaces físicas onde chegava o link, bem
>> como a interface de gerência, a qual estava diretamente conectada a um
>> computador. porém, o tráfego também não cessava.
>>> 
>>> - Foram desativados IPs, rotas e quaisquer outras configurações que
>> pudessem propiciar o fluxo na interface. O tráfego permaneceu saturado.
>>> 
>>> - Foi realizada a troca da Gbic, o que também não surtiu efeito.
>>> 
>>> - A fibra foi colocada em um novo equipamento (retirado da caixa), sem
>> qualquer configuração prévia (default configuration) e o mesmo sintoma
>> ocorria.
>>> 
>>> - Durante a captura de pacotes, percebeu-se que o tráfego era
>> proveniente do MAC ADDRESS do equipamento da operadora (fora do site) e o
>> destino não era broadcast;
>>> 
>>> 
>>> Algum de vocês já teve alguma experiência neste sentido ou sabe o que
>> pode estar ocorrendo?
>>> 
>>> 
>>> Atenciosamente,
>>> Raphael Monteiro - MontNet
>>> +5527992525555
>>> --
>>> 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