[GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC
Diogo Montagner
diogo.montagner at gmail.com
Wed Dec 10 17:01:27 -02 2014
Em algum lugar da sua rede voce deve ter a rota agregada de cada bloco que
voce vai anunciar via BGP. Isto pode ser no roteador de borda, no RR, no
roteador de RTBH ou mesmo no roteador que agrega todos os clientes de um
mesmo prefixo. Em un destes eh que vice deve ter a rota aggregada com
discard. Isto deve ser suficiente para ininit os loops causados pela
situacao que ei descrevi.
Abs
On Thursday, 11 December 2014, Lista <lista.gter at gmail.com> wrote:
> Pergunta?
>
> E qual seria o procedimento para descartar esses pacotes sem remover a rota
> default que o nosso amigo precisa?
>
> O que vejo seria o seguinte, se você publica no seu core somente em /32,
> poderia jogar todo o seu prefixo em blackhole dentro da sua cx, assim se
> for problema de ttl expire isso irá ser quebrado, pois se a rede não
> estiver sendo divulgada irá matar isso na borda e não entrará em loop entre
> vc e a gblx. agora para que isso tenha efeito teríamos que saber qual o
> prefixo mínimo que vc divulga no seu igp.
>
> Em 10 de dezembro de 2014 00:01, Joao Carlos Peixoto Ponce <
> jocapponce at gmail.com <javascript:;>> escreveu:
>
> > 2014-12-09 18:34 GMT-02:00 Diogo Montagner <diogo.montagner at gmail.com
> <javascript:;>>:
> >
> > > Se a taxa de arrival to ARP para cada FPC não está violada, em teoria
> > você
> > > está operando na faixa que o equipamento suporta.
> > >
> > > A proteção de DDoS do control-plane vem habilitada por padrão. Se você
> > não
> > > possui nenhuma configuração em system/ddos-protection significa que ela
> > > está habilitada, como você pode ver pelo output que você enviou.
> > >
> > > Quando o problema está ocorrendo, o show ddos-protection violations
> > mostra
> > > alguma coisa ?
> > >
> >
> > Da ultima vez nada.
> > O único não zerado era IPv6 Unclassified mas também não violado o rate
> > configurado.
> >
> >
> > >
> > > Você pode estar sofrendo the TTL expired, geralmente causado por loops
> de
> > > roteamento. Se ao aplicar uma rota com discard o problema se resolve,
> > você
> > > tem que investigar isto.
> > >
> >
> > Eu não apliquei o descarte na roda padrão como recomendado pelo Rubens
> pois
> > tenho uma rota padrão apontando para GLBX.
> > Algumas rotas não chegam para mim pela GVT, ou demoram para chegar e
> então
> > sempre uso a GLBX como default ou CTBC se existe o prefixo.
> > Dessa forma não gerei descarta na 0.0.0.0/0.
> >
> >
> > > Por exemplo, tráfego vindo da Internet atraído para o seu roteador por
> um
> > > anúncio de BGP, ao chegar ao seu roteador, aquele IP não está presente
> na
> > > tabela de roteamento, então o tráfego segue pela rota default, mas ao
> > sair
> > > da caixa, ele voltará pois o seu anuncio BGP atrai ele.
> > >
> >
> > Eu teria um excesso de logs de icmp ttl expired não teria?
> > Ja que após 256 loops desse tipo o resultado seria um expired.
> > O que você está explicando faz sentido, posso estar mandando pra GLBX e
> > voltando pra mim.
> > Mas eu precisaria ter como tirar isso a limpo sem null routing na
> default.
> > Mas isso é possível eu fazer so para o teste.
> > Anotado.
> >
> >
> > >
> > > Eu posso tentar ajudar em pvt se você me enviar os outputs abaixo:
> > >
> > > # repita os comandos 5 vezes em intervalos de 10 segundos durante o
> > > problema
> > > set cli timestamp
> > > show chassis routing-engine | no-more
> > > show system processes extensive | no-more
> > > show pfe traffic exceptions | no-more
> > > show ddos-protection protocols violations | no-more
> > > show ddos-protection protocols | no-more
> > >
> >
> > Combinado irei me programar para tirar o firewall e coletar essas saídas.
> > Muito obrigado desde ja pela ajuda,
> >
> > []s
> > >
> > > ./diogo -montagner
> > > JNCIE-SP 0x41A
> > >
> > > 2014-12-08 22:44 GMT+11:00 Joao Carlos Peixoto Ponce <
> > jocapponce at gmail.com <javascript:;>
> > > >:
> > >
> > > > 2014-12-08 2:25 GMT-02:00 Diogo Montagner <diogo.montagner at gmail.com
> <javascript:;>>:
> > > >
> > > > > Complementando a informação do Rubens, no MX há a proteção de DDoS
> do
> > > > > control-plane.
> > > > >
> > > > Diogo,
> > > >
> > > > Como valido se está ligado?
> > > >
> > > >
> > > > > Entretanto, se o seu ataque estiver vindo pela porta FXP, essa
> > proteção
> > > > não
> > > > > terá efeito, pois a FXP não é uma porta de revenue.
> > > > >
> > > > > Para conter um ataque vindo pela porta FXP, você terá que criar um
> > > > policer
> > > > > e aplicar na interface fxp0.
> > > > >
> > > > > Em um dos meus e-mails nesta thread explica o que você deve olhar
> > caso
> > > o
> > > > > ataque de arp esteja vindo pela interface fxp0 (interruptions
> > causando
> > > > high
> > > > > CPU).
> > > > >
> > > > > admin at BNG-960-F> show ddos-protection protocols arp
> > > > > Packet types: 1, Modified: 0, Received traffic: 1, Currently
> > violated:
> > > 0
> > > > > Currently tracked flows: 0, Total detected flows: 0
> > > > > * = User configured value
> > > > >
> > > > > Protocol Group: ARP
> > > > >
> > > > > Packet type: aggregate (Aggregate for all arp traffic)
> > > > > Aggregate policer configuration:
> > > > > Bandwidth: 20000 pps
> > > > > Burst: 20000 packets
> > > > > Recover time: 300 seconds
> > > > > Enabled: Yes
> > > > > Flow detection configuration:
> > > > > Detection mode: Automatic Detect time: 3 seconds
> > > > > Log flows: Yes Recover time: 60 seconds
> > > > > Timeout flows: No Timeout time: 300 seconds
> > > > > Flow aggregation level configuration:
> > > > > Aggregation level Detection mode Control mode Flow rate
> > > > > Subscriber Automatic Drop 10 pps
> > > > > Logical interface Automatic Drop 10 pps
> > > > > Physical interface Automatic Drop 20000 pps
> > > > > System-wide information:
> > > > > Aggregate bandwidth is never violated
> > > > > Received: 14929 Arrival rate: 0 pps
> > > > > Dropped: 0 Max arrival rate: 2 pps
> > > > > Routing Engine information:
> > > > > Bandwidth: 20000 pps, Burst: 20000 packets, enabled
> > > > > Aggregate policer is never violated
> > > > > Received: 14929 Arrival rate: 0 pps
> > > > > Dropped: 0 Max arrival rate: 4 pps
> > > > > Dropped by individual policers: 0
> > > > > FPC slot 0 information:
> > > > > Bandwidth: 100% (20000 pps), Burst: 100% (20000 packets),
> > enabled
> > > > > Aggregate policer is never violated
> > > > > Received: 2793 Arrival rate: 0 pps
> > > > > Dropped: 0 Max arrival rate: 2 pps
> > > > > Dropped by individual policers: 0
> > > > > Dropped by flow suppression: 0
> > > > > FPC slot 2 information:
> > > > > Bandwidth: 100% (20000 pps), Burst: 100% (20000 packets),
> > enabled
> > > > > Aggregate policer is never violated
> > > > > Received: 12136 Arrival rate: 0 pps
> > > > > Dropped: 0 Max arrival rate: 1 pps
> > > > > Dropped by individual policers: 0
> > > > > Dropped by flow suppression: 0
> > > > >
> > > > > admin at BNG-960-F>
> > > > >
> > > >
> > > > Entendi, é só isso? Se estiver enabled esta habilitado?
> > > > Esse counter reseta sem boot?
> > > > Porque no meu está dando:
> > > >
> > > > Aggregate bandwidth is never violated
> > > >
> > > > Veja:
> > > >
> > > > Packet type: aggregate (Aggregate for all arp traffic)
> > > > Aggregate policer configuration:
> > > > Bandwidth: 20000 pps
> > > > Burst: 20000 packets
> > > > Recover time: 300 seconds
> > > > Enabled: Yes
> > > > Flow detection configuration:
> > > > Detection mode: Automatic Detect time: 3 seconds
> > > > Log flows: Yes Recover time: 60 seconds
> > > > Timeout flows: No Timeout time: 300 seconds
> > > > Flow aggregation level configuration:
> > > > Aggregation level Detection mode Control mode Flow rate
> > > > Subscriber Automatic Drop 10 pps
> > > > Logical interface Automatic Drop 10 pps
> > > > Physical interface Automatic Drop 20000 pps
> > > > System-wide information:
> > > > Aggregate bandwidth is never violated
> > > > Received: 23921 Arrival rate: 0 pps
> > > > Dropped: 0 Max arrival rate: 4 pps
> > > > Routing Engine information:
> > > > Bandwidth: 20000 pps, Burst: 20000 packets, enabled
> > > > Aggregate policer is never violated
> > > > Received: 23937 Arrival rate: 0 pps
> > > > Dropped: 0 Max arrival rate: 6 pps
> > > > Dropped by individual policers: 0
> > > > FPC slot 0 information:
> > > > Bandwidth: 100% (20000 pps), Burst: 100% (20000 packets),
> enabled
> > > > Aggregate policer is never violated
> > > > Received: 8328 Arrival rate: 0 pps
> > > > Dropped: 0 Max arrival rate: 4 pps
> > > > Dropped by individual policers: 0
> > > > Dropped by flow suppression: 0
> > > > FPC slot 2 information:
> > > > Bandwidth: 100% (20000 pps), Burst: 100% (20000 packets),
> enabled
> > > > Aggregate policer is never violated
> > > > Received: 92134 Arrival rate: 0 pps
> > > > Dropped: 0 Max arrival rate: 3 pps
> > > > Dropped by individual policers: 0
> > > > Dropped by flow suppression: 0
> > > >
> > > > Diogo como posso olhar outros contadores de consumo de CPU?
> > > > Por exemplo pelo que entendi essa policy evita high-rate de arp
> > request.
> > > > Mas e se houver lookup excessivo acontecendo?
> > > > Não sei por que haveria mas estou as cegas tentando procurar outras
> > > coisas.
> > > > Depois de aplicadas dicas dos colegas da lista e mudado a versão do
> > JunOS
> > > > minhas taxas de CPU, interrupt etc normalizaram, mas o DoS volta a
> > > ocorrer
> > > > sem firewall na frente.
> > > > Então quero saber onde mais posso olhar.
> > > > Onde vejo o consumo de CPU do Trio?
> > > > Pois me parece que todos comandos que dou mostram CPU de system,
> user e
> > > > interrupt da CPU mesmo e não do chip Trio.
> > > > Onde posso ver saturação de barramento por exemplo?
> > > >
> > > > Dei um "show ddos-protection protocols" sem argumento para ver o
> > > restante.
> > > > Todos exceto IPv6 Unclassified e ARP estão zerados.
> > > > ARP e IPv6 Unclassified apesar de não zerados continuam apontando
> > "never
> > > > violated".
> > > > E com counters de drop sempre zerados.
> > > >
> > > >
> > > >
> > > >
> > > > > ./diogo -montagner
> > > > > JNCIE-SP 0x41A
> > > > >
> > > > > 2014-12-08 12:22 GMT+11:00 Rubens Kuhl <rubensk at gmail.com
> <javascript:;>>:
> > > > >
> > > > > > >
> > > > > > > Como eu disse e estou tentando descobrir não sei qual o
> problema,
> > > > mas o
> > > > > > > roteador perde servico na porta com mais de 600kpps com ou sem
> > > > > firewall.
> > > > > > >
> > > > > >
> > > > > > Algum tipo de policy-routing ligado ?
> > > > > >
> > > > > >
> > > > > > > Isso não é apenas descarte da rota padrão?
> > > > > > >
> > > > > > >
> > > > > > Sim, é. Mas mesmo assim necessário, mesmo que não seja o que está
> > > sendo
> > > > > > explorado nesse ataque em particular.
> > > > > >
> > > > > >
> > > > > > > > A rede diretamente conectada é uma parte vulnerável, porque
> > pode
> > > > > > induzir
> > > > > > > o
> > > > > > > > roteador a fazer ARP para esses destinos. A que está 1 salto
> > pra
> > > > > dentro
> > > > > > > não
> > > > > > > > é problema.
> > > > > > > >
> > > > > > >
> > > > > > > Arp request voce diz ou arp lookup?
> > > > > > > De qualquer forma poucos pacotes passam.
> > > > > > > Os que passam e fariam arp lookup ou request de qualquer forma
> > são
> > > > > > poucos.
> > > > > > >
> > > > > >
> > > > > > Porque essa afirmação ?
> > > > > >
> > > > > > >
> > > > > > > Além disso o Juniper como qualquer sistema guarda cache de arp
> o
> > > que
> > > > > > > geraria lookup intenso mas não request.
> > > > > > > Mas "lookup intenso" na taxa de 600kpps e num prefixo
> limitado a
> > > 254
> > > > > > > hosts, qualquer hipótese do Juniper não dar conta, Deus pai né?
> > > > > > > É pouca coisa demais.
> > > > > > >
> > > > > >
> > > > > > Os lookups nunca completam, então é possível sim saturar CPUs de
> > > > > tratamento
> > > > > > de exceção com isso. Na série M essa limitação era hard-coded, e
> > > talvez
> > > > > > você precisa habilitá-la explicitamente.
> > > > > >
> > > > > > Se fossem 254 hosts que respondem ARP e completam as adjacências,
> > não
> > > > > seria
> > > > > > problema... mas enquanto um IP não tem adjacência completa, um
> > pacote
> > > > > > destinado a ele não é roteado em hardware, vai para tratamento de
> > > > exceção
> > > > > > (que é poucos kpps, não de Mpps).
> > > > > >
> > > > > > Rubens
> > > > > >
> > > > > >
> > > > > > > --
> > > > > > > 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
--
./diogo -montagner
JNCIE-SP 0x41A
More information about the gter
mailing list