[GTER] Incidente (possível) Layer2 em circuito de operadora sendo atacado
Jean Carlos Bartzen
jean at deltatele.com.br
Mon May 28 03:04:25 -03 2018
Talvez, um problema de aprendizado de macs no switch da operadora tenha uma característica parecida, porem afetaria mais clientes deles. Veja apresentação do Douglas Fisher no ultimo GTER, talvez lhe de um norte.
Enviado do meu iPhone
Em 27 de mai de 2018, à(s) 23:21, Raphael Pontara <pontara at outlook.com> escreveu:
> 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
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list