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

[Diogo Montagner]

Complementando a informação do Rubens, no MX há a proteção de DDoS do
control-plane.

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>

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