[GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC
Joao Carlos Peixoto Ponce
jocapponce at gmail.com
Mon Dec 8 09:44:34 -02 2014
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
>
More information about the gter
mailing list