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

Raphael Pontara pontara at outlook.com
Sun May 27 23:21:55 -03 2018 

Joao Paulo, inicialmente eu levei pelo mesmo raciocínio. Principalmente porque havia algumas rotas velhas apontadas para o nosso /32.

Até RFC1918 aparecia como destino nos logs da interface (mesmo quando não ocorria o ‘ataque’)

Alterado o circuito, os bogons deixaram de chegar...

Porém, confiando no N2 da Oi que afirmou não ser possível (no equipamento que eles utilizam) rotear tráfego com destino a uma interface, apenas com destino a um IP (e neste caso, o nosso /32), descartei também a possibilidade que você levantou.

Até porque, no wireshark o destino dos pacotes capturados durante o incidente têm como destino - também - ao nosso /32 (unicast),  mas em nenhum momento para  broadcast (FF:FF:FF:FF:FF:FF), o que denotaria flood causado por estouro da tabela de MAC.

No entanto, qualquer MAC atribuído à interface também não fazia o flood cessar.

Portanto, vamos evoluindo essa conversa. Quem sabe alguém consiga detalhar as causas disso.

Raphael Pontara
+55 27 99252-5555 (Claro)

Em 27 de mai de 2018, à(s) 22:23, Raphael Pontara <pontara at outlook.com> escreveu:

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

More information about the gter mailing list