[GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC
Lista
lista.gter at gmail.com
Wed Dec 10 16:09:08 -02 2014
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> escreveu:
> 2014-12-09 18:34 GMT-02:00 Diogo Montagner <diogo.montagner at gmail.com>:
>
> > 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
> > >:
> >
> > > 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
> > >
> > --
> > 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