[GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC

[Patrick Tracanelli]

Boa madrugada. 

Discussão longa muito estranho os dados compartilhados pelo pouco que consegui ver.

>> Balanceamento de porta IP é feito para evitar dessequenciamento de pacotes,
>> então dependendo do perfil de tráfego poderá ir tudo para uma única porta.
>> Assim, um tráfego de 1.1G pode saturar um port-bundle de n x 1G.
>> 
> 
> OK, só não é o que está acontecendo.
> 
>> Além disso, uma porta Giga não consegue transmitir 1 Gbps de pacotes
>>>> pequenos. Por causa do inter-frame gap, uma porta giga transmite algo
>> 600
>>>> Mbps de pacotes desse tamanho se fiz as contas direito.
>>>> 
>>> 
>>> OK, não é o que está acontecendo de qualquer forma.
>>> 
>>> 
>> Porque você diz isso ? Quantos Mpps em cada interface física nos momentos
>> de ataque ?
>> 
> 
> Variando de 300 a 360Mbit/s por porta de tráfego quando o ataque chega a
> mim.
> De 860Kpps a 1.3Mpps por porta.
> Ja tive picos de 2Mpps por porta.
> Ja tive trafego de até 1.6Mpps por porta para pacotes TCP bem pequenos, na
> casa de 200 bytes, em momentos de menor tempestade, trafego muito estranho

Desculpe mas citando nosso querido Padre Quevedo, “isso non ecziste!”. O line-rate máximo possível para é de 1.488,095 pps em uma porta de 1Gbit/s (aka wire-speed). Ainda que você consiga enfiar 1Gbit/s em 1.6Mpps ou 2Mpps não vai conseguir essa taxa de PPS na porta em questão.

Por melhor que seja um Juniper, o paradigma padre quevedo fala mais falto. Alguma base de entendimento no porque isso não é possível:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB14737

Mas como você está se baseando em uma memória passada do que acredita ter vivenciado, vamos assumir que você errou ao monitorar ou está falando de portas agregadas.

Em outro e-mail você menciona que está com LACP, se for em uma porta trunking OK esses valores são possíveis, se for “on the wire”, padre quevedo!

Olha existem mais comunidades BGP, no caso da GVT que podem ter ajudar. Sugiro que tente encontrar o Romao da GVT, tente escalar o ticket dentro de uma questão “BGP” até chegar nele. Que acredito esteja nessa lista e talvez veja isso. Todos problemas que tive e dependia da GVT para uma solução, foi com ele que me entendi. Excelente profissional.

Li em seu e-mail que amanhã de manhã você talvez receba o ataque de volta na caixa. Colete todas as saídas que os amigos solicitaram, Rodrigo, Rubens, Diogo em especial, e cole todas as saídas no pior momento do ataque se sua caixa tiver condições de gerar essa saída (se estiver responsivo). Temos informações desencontradas na mesa e a saída mais recentes desses comandos vai ajudar todos nós a ajudarmos seu caso.

Sem dúvidas se tem uma caixa MX/40 segundo a pancada, tem algo estranho na sua Mx/5 já que basicamente são a mesma coisa em termos de processamento que parece na sua avaliação e na sua saída ser gargalo. Está subindo pra CPU o que deveria não estar sendo processado la.

Adicione aos comandos pra você coletar pra gente, o seguinte:

show security idp status
show security idp counters packet
show security idp counters ips
show security idp attack table
show security idp qmodule statistics
request security idp security-package install detail-status
request pfe execute command "show usp idp status" target fwdd

Acima são associados a firewall e IPS. Mesmo que voce acredite não estar em uso, envie as saídas. Se não quiser expor detalhes do seu ambiente envie em PVT as pessoas tentando te ajudar. Esse consumo parece vir de outro lugar. Sua caixa está como BGP, vamos avaliar se não tem firewall stateful e outras coisas do IDP ligadas.

Execute ainda:

show system core-dumps no-forwarding

E se der erro de not found não se preocupe, problema se encontrar algo me fale para seguirmos com debug, isso significa que sua caixa MORREU alguma vez.

Execute:

show system processes extensive no-forwarding

Isso é o “top” do FreeBSD. Procure as colunas com alto consumo de WCPU e tome nota do que está na coluna CPU pra sabermos quem está processando o que. Será possível identificar o que o Trio está ou não está processando.

Execute:

show pfe statistics error
show pfe statistics traffic

show chassis routing-engine no-forwarding
show chassis environment no-forwarding

Execute tambem:

show system boot-messages  no-forwarding

Isso é o “dmesg” do FreeBSD.

Nele procure esse trecho e nos envie:

real memory  = 2147483648 (2048MB)
avail memory = 1073795072 (1024MB)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Security policy loaded: JUNOS MAC/pcap (mac_pcap)
Security policy loaded: JUNOS MAC/runasnonroot (mac_runasnonroot)
netisr_init: !debug_mpsafenet, forcing maxthreads from 2 to 1
cpu0 on motherboard
CAVIUM's OCTEON 5020 CPU Rev. 0.1 with no FPU implemented
        L1 Cache: I size 32kb(128 line), D size 8kb(128 line), sixty four way.
        L2 Cache: Size 128kb, 8 way

Quero saber qual CPU, algo na linha desse CAVIUM’s OCTEON da vida pode surgir. Esta vendo a parte ali com Security policy loaded? Procure ali por perto algo com AUDIT ou CASPER ja que pelo que vi nos seus e-mails anteriores você está usando JunOS versão 13. Se tiver habilitado isso vamos ter que desabilitar.

Execute também:

show system buffer no-forwarding

Isso é o “netstat -m” do FreeBSD e vai ser significativo ver o que ele tem a dizer.

Alias outra coisa que me ocorreu, quando executar o "show security idp counters packet” procure por:

"jbuf pullup failed"

E garanta que esse contador esteja zerado.

Aproveitando salve também a saída de:

request pfe execute command "show  security utm status all" target fwdd
request pfe execute command "show usp flow tcp-proxy all" target fwdd

Sei que não tem qualquer graças pra quem está na sua posição mas é um caso de expressivo interesse técnico de muitos aqui. É um problema que não afeta apenas uma caixa Juniper, é bem genérico.

Esse seu perfil de tráfego mencionado é tráfego UDP das câmeras de segurança andam virando até notícia no fantástico hehe, voce sabe disso ne?

Envie também por favor, se voce julgar adequado, a saída de:

show configuration

Ou para preservar sua segurança:

show configuration | grep -v SECRET-DATA

Se achar que está se expondo demais envie em pvt essas saídas mas não deixe de enviar, creio que temos um número bom de especialistas em Juniper aqui na lista e provavelmente no seu PVT. E esse e-mail da CTBC Telecom @gmail.com ai interagindo nessa thread, abuse desses caras! Esse e-mail é “grupal” (não no sentido de sacanagem hehehe) e tem muita gente boa lendo ele. 

Tenho um conhecido, professor Ricardo da FUMEC e CEMIG TELECOM, sei que você também é de MG então se precisar de um apoio no Juniper, recomendo entrar em contato. Se quiser posso apresenta-los (pvt), segue contato:

Ricardo Bernardo dos Santos, MSc.
ricardobernardosantos at gmail.com
MCSE, CCNP, JNCIA

Abraços. Qualquer coisa fique a vontade para entrar em contato.

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"