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 - [email protected] - 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 [email protected] 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
