[FUG-BR] [OFF] DoS DNS (DNSSEC) :(

[Marcus Grando]

Dae,

Hehehehe… foda isso né. Também não sei ainda como resolver esse tipo de problema.

Esse post deveria ir para o GTER :)

Abraços

On 18/09/2012, at 12:47, Patrick Tracanelli <eksffa at freebsdbrasil.com.br> wrote:

> Uma coisa que eu aprendi com o tempo é que algumas pessoas tem um belo olfato pra coisas que podem cheirar mal nem que seja em anos. No passado o Theo de Raadt disse que os IDs aleatórios do BIND9 era previsíveis e isso geraria envenamento de cache; 3 anos depois deu no que deu e somente o BIND9 do OpenBSD com o patch do Theo não estava vulnerável.
> 
> Ha alguns anos o Daniel J. Bernstein disse que o Domain Keys do Yahoo ia gerar negação de serviço numa proporção maior que impedir Spam. Periodicamente o Yahoo sofre de exaustão de CPU tentando validar chaves DK erradas; eu mesmo já sofri só que diferente do Yahoo! não tenho CPU suficiente ou clusters de e-mail suficientes para "dar conta" da pancada, e tive que tirar do ar.
> 
> Há cerca de 1 ano e meio algo cheirou mal ao mesmo tempo pro Theo de Raadt e pro DJB sobre uma possível amplificação de DNSSEC no draft final que levaria a grandes taxas de negação de serviço, que mereceu comentários no blog do Bruce Schneier.
> 
> Como a gente se sente quando algo "novo" na tecnologia e num processo rápido de adoção como DNSSEC e, em tese, muito importante para aumentar a "segurança do subsistema de DNS como um todo" (segundo a própria RFC) é de repente "gorado" por ninguém menos que o DJB, Theo De Raadt e Bruce Schneier?
> 
> O Bernstein foi além e primeiro causou um DoS de "exemplo" no www.vix.com (website do P. Vixie - vixie at freebsd.org - autor do BIND e o cara no ISC e diversas operações críticas na Internet), e como se não bastasse postou um paper recentemente (ha 3 meses) como praticamente uma "receita de bolo" de como causar um ataque de amplificação DNSSEC de 51x.
> 
> http://cr.yp.to/talks/2012.06.04/slides.pdf
> 
> Alguns estudos tinham apontado um consumo grande de banda, CPU e memória na adoção do DNSSEC:
> 
> http://www.net.t-labs.tu-berlin.de/papers/ADF-PDODT-06.pdf
> 
> Mas alguns talks e inclusive uma boa palestra no GTER apontavam que o mero cache ameniza e torna viável todo o consumo adicional imposto do DNSSEC. Verdade. Num perfil de uso autêntico do DNSSEC é verdade.
> 
> Bom, pra resumir, coloquei DNSSEC a rodo em zonas próprias e de clientes da empresa.
> 
> Essa semana diz a lenda que o GoDaddy sofreu DoS de DNSSEC. Mesma coisa com SpamHaus segundo o próprio djb. E finalmente um data center que eu dou suporte entrou na roda.
> 
> Fui olhar as "counter measures" e vi que a resposta do Vixie pro PoC do djb é uma solução ainda mais criticada na segurança da informação: rate-limiting.
> 
> O Vixie fez essa especificação e esse patch:
> 
> http://ss.vix.com/~vixie/isc-tn-2012-1.txt
> http://ss.vix.com/~vixie/rl-9.8.3-P2.patch
> 
> Que adicionam rate-limite nas respostas DNS do BIND:
> 
> named.conf (options):
> 
> rate-limit {
>    responses-per-second 25;
>    window 5;
> };
> 
> Que é claro como todos podem imaginar, rate-limit desse tipo, tão "amplo" e genérico não separa joio do trigo. Simplesmente muda o problema podendo causar negação de serviço em perfil autêntico de uso já que as confs são globais. Além da própria implementacão ao meu ser também falha gerando no MAX-TABLE-SIZE outra entrada de DoS em potencial por exaustão de tamanho da tabela de controle.
> 
> Bom, resolvi tentar "amenizar" a coisa da forma FreeBSD mesmo, a que me pareceu mais óbvia o possível, e coloquei via dummynet um controle de banda que não gerasse outro vetor de negação de serviço amplo.
> 
> Com o rate:
> 
> rate -f 'port 53' -i re0 -n -wc -Ab -a 20 -lc 0/0 -O
> 
> Descobri que nesse data center os consumidores mais "frenéticos" de DNS de autoridade (não estou contando clientes autenticos com recursão liberada, apenas autoridade que é o que vem do mundo) mas ainda assim autênticos convivem bem com 2Kbit/s de banda (até 6 pra DNSSEC)
> 
> Então coloquei um limite de 2Kbit/s de banda por IP único (mask src-ip 0xffffffff no pipe) e 256Kbit/s de cada CIDR /24 único (mask src-ip 0xffffff00 no pipe).
> 
> Ainda não desativei o DNSSEC e enquanto o dummynet der conta vou manter esse controle. Mas claro que o dummynet pode abrir o bico dependendo da quantidade de IPs únicos e prefixos /24 únicos que chegarem ao meu servidor DNS. Se chegar perto disso vou ter que começar desativar o DNSSEC de centenas de domínios desse data center :-(
> 
> Agora o triste é ver na prática o DNSSEC em favor do pilar da integridade (ISO 27002) poder ser usado como vetor de ameaça e risco ao pilar da disponibilidade.
> 
> Só que no "negócio" da Internet se tiver que escolher, aparentemente todos darão prioridade a disponibilidade. Podem até suportar um envenenamento de cache aqui e ali, e uma corrida de última hora para atualizar servidores DNS (pq atualização pro-ativa é lenda quase pra todos) mas uma falha DNS aqui e ali, não vejo ninguém disposto conviver. Especialmente quando geram negative cache.
> 
> Fica a dica e o alerta, espero que ninguém ache útil nem precise se preocupar.
> 
> --
> Patrick Tracanelli
> 
> FreeBSD Brasil LTDA.
> Tel.: (31) 3516-0800
> 316601 at sip.freebsdbrasil.com.br
> http://www.freebsdbrasil.com.br
> "Long live Hanin Elias, Kim Deal!"
> 
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

--
Marcus Grando