[GTER] Um DDoS lotou seu enlace. Você sabe para onde estão indo seus pacotes BGP?

Diogo Montagner diogo.montagner at gmail.com
Tue Feb 22 10:20:39 -03 2011


Com relação ao item 3, você pode evitar a instabilidade do BGP fazendo
uso de CoS para corretamente classificar os seus pacotes BGP na fila
de alta prioridade. O fato é que você tem que garantir que o upstream
provider que você está conectado honra o CoS pelo menos para o
control-plane. Por exemplo, os pacotes BGP gerados no roteador do
upstream provider devem ser colocados na fila de alta prioridade
enquanto que o resto do tráfego deve ser colocado na classe de
internet (geralmente BE). Se o seu upstream provider não faz isto,
certamente o seu BGP irá oscilar quando o link atingir 100%.

Geralmente a principal causa de BGP instável é link instável ou com
altíssima taxa de erro. Neste caso, a melhor solução é desativar o
link até o problema seja resolvido. Flaps em link desencadeiam uma
série de tarefas nos roteadors: updates de bgp (next-hop), updates de
LSAs, LSPs (ISIS), LDP, etc. Isto também incorrerá em aumento na
utilização de CPU e memória. Em casos de roteadores de arquitetura
distribuida, a CPU/memória dos slots também irá aumentar e você terá
outro problema que, dependendo de cada caso, afetará a convergência da
rede devido ao retardo no update do forward-plane.

O pior ataque, na minha opnião, é aquele contra o control-plane,
especialmente quando se tem multicast envolvido.

[]s
./diogo -montagner



2011/2/22 Henrique de Moraes Holschuh <henrique.holschuh at ima.sp.gov.br>:
> Senhores (as),
>
> Provavelmente a estas alturas, todos já devem estar a par da mais nova
> forma de amplificar o estrago que uma instabilidade BGP forçada pode
> causar (CXPST).
>
> Alguns detalhes que me saltaram à vista, depois de ler os devidos papers
> (nem em resumos da New Scientist dá para confiar hoje em dia...):
>
> Ref:
>    http://www-users.cs.umn.edu/~schuch/papers/lci-ndss.pdf
>
> http://www.isoc.org/isoc/conferences/ndss/07/papers/low-rate_TCP-targeted_DOS_attacks.pdf
>
>
> Eis uma listinha estilo "opsec lite" para pensar:
>
> 1.  Proteção do tráfego de roteamento contra sufocamento no data plane:
>
>    1a. Quantos de nós realmente testam se os pacotes BGP, OSPF, RIP,
>        estão passando no enlace marcados com a prioridade mais alta?
>
>        Era para o roteador/Quagga/Bird/Vyatta já marcar isso de forma
>        padrão, mas...
>
>    1b. Quantos de nós realmente testam se o roteador está priorizando
>        na fila de saída os pacotes marcados?
>
>    1c. Quantos de nós remarcam outros pacotes de alta prioridade para
>        alguma coisa mais baixa que a prioridade dos pacotes do control
>        plane?  Sem isso, basta a origem do DDoS marcar os pacotes
>        dele...
>
>    * Note que a marcação não precisa ser honrada no backbone inteiro,
>      é apenas no(s) enlace(s) entre os eBGP speakers.
>
>    * Sessões eBGP multihop dificilmente vão sobreviver a um ataque
>      destes, algo que se deve levar em conta...
>
> 2.  Proteção do control plane contra sufocamento via data plane:
>    (isso está nos slides da Cisco, tenho certeza)
>
>    2a. Quantos de nós protege o roteador contra DDoS direto, usando
>        GTSM, ACLs, e o engine de QoS para evitar que uma enxurrada
>        de tráfego consiga chegar na CPU / software router?
>
>    2b. E quantos tiveram o cuidado de garantir que, ao proteger
>        contra DDoS a CPU, deixaram a porta aberta para o tráfego
>        que PRECISA chegar na CPU do roteador a qualquer custo
>        (tráfego BGP, OSPF... legítimo) ?
>
>
> 3.  Proteção do BGP contra sufocamento por instabilidade (excesso
>    de updates)
>
>    Não sei o suficiente para opinar.  Ideias ?
>
>    Como evitar que uma enxurrada de updates _válidas_ torne o
>    roteador instável, ou atrapalhe tanto a convergência a ponto
>    de muitas rotas serem perdidas ou incorretas (ou seja
>    causar blackholes) ?
>
> --
> Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
> IM@ - Informática de Municípios Associados
> Engenharia de Telecomunicações
> TEL +55-19-3755-6555/CEL +55-19-9293-9464
>
> Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
> e do custo que você pode evitar.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list