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

Diogo Montagner diogo.montagner at gmail.com
Tue Dec 9 18:34:38 -02 2014


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 ?

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.

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 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

[]s

./diogo -montagner
JNCIE-SP 0x41A

2014-12-08 22:44 GMT+11:00 Joao Carlos Peixoto Ponce <jocapponce at gmail.com>:

> 2014-12-08 2:25 GMT-02:00 Diogo Montagner <diogo.montagner at gmail.com>:
>
> > 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>:
> >
> > > >
> > > > 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
>



More information about the gter mailing list