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

Mon May 28 07:49:40 -03 2018

Ao meu ver, infelizmente você precisa escalar isso para outro nível na OI e
procurar alguém que possa interagir diretamente e simultaneamente com você
neste caso, sei que isso parece difícil, principalmente quando se trata da
OI, mas sem interação nas duas pontas você vai ficar no jogo de tentativa e
erro por muito tempo e com a chance de não resolver o problema.

Att.

Em 28 de maio de 2018 03:04, Jean Carlos Bartzen <jean at deltatele.com.br>
escreveu:

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

-- 
Paulo Henrique Fonseca
paulohenriquef at gmail.com