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 <eks...@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 - vi...@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 > 316...@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 ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
