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

[Patrick Tracanelli]

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 em 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 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"