2015-01-07 19:59 GMT-02:00 Eduardo Schoedler :
> Em 7 de janeiro de 2015 19:50, Evandro Nunes
> escreveu:
>
> > 2015-01-07 14:14 GMT-02:00 Eduardo Schoedler :
> >
> > > Em 6 de janeiro de 2015 15:42, Evandro Nunes >
> > > escreveu:
> > >
> > > > > Não esqueçam de ver se tem DNSSEC.
> > > >
> > > > exatamente
> > > > e se tiver DESLIGA
> > > >
> > >
> > > Pelo contrário, se tiver, LIGA.
> >
> > --
> > > Eduardo Schoedler
> > >
> >
> > rss rs rs
> > por mim desliga
> >
> > em um mundo onde ninguém segue BCP nenhuma
> > ninguém tem filtros ingress mínimos
> > diversas aplicações ainda fazem consultas q=ANY
> > onde milhões de androids infectados são vetores de início de amplificação
> > nesse mundo, eu troco explicitamente a confidencialidade pela
> > disponibilidade
> > e desligo DNSSEC
>
> É, não contribuir só ajuda a piorar.
>
não usar DNSSEC não piora em nada as amplificações
ao contrário ajuda
> Se cada um fizer sua parte, já é algo.
>
eu estou fazendo a minha, não ajudando chin xang xai peis a amplificarem
ataques e me usando pra isso
o djb, autor do qmail, não é das pessoas que mais admiro
inclusive o abandonware do qmail dele é um dos q fazem query type ANY
mas ainda assim se tem um ponto que o DJB tem toda razão do mundo é que
DNSSEC é uma arma na mão de kids
Eu implemento BCPs (principalmente rpf-check, proteção de route engines,
> etc), habilito DNSSEC nos servidores DNS e nunca tive problemas.
>
não ter problemas não é sinônimo de não ser causa de problemas
se isso um dia acontecer talvez você mude de opinião
o proprio DJB em 2009 palestrou e divulgou um paper como amplificar um
trafego astronômico com um shell script, wget+dig
pouco depois disso vimos o maior ddos da historia contra o spamhaus
foram 90Gbit/s de amplificação DNS causada por diversos servidores, tanto
com recursivo aberto quanto apenas autoritativos, desse trafego segundo a
cloudfare mais de 80% em volume (quantidade não frequência) eram respostas
de consultas DNSSEC nunca feitas pelo spamhaus mas com IP forjado
os problemas que o DNSSEC resolve são de autenticidade, cache poisoning,
SPOF, Random ID Guessing
os problemas que o DNSSEC cria ou exponencialmente amplia são os de
disponibilidade (ou falta dela)
então entre a a escolha de disponibilidade vs autenticidade, cada um faz a
sua, eu fiz a minha
a ampla adoção de DNSSEC não caminha a passos lentos apenas por preguiça e
desleixo dos sysadmins
nem pelo aumento da tarefas operacionais na manutenção do DNS
bancos, sites de e-commerce que priorizarem a autenticidade, que coloquem
DNSSEC
todos os outros 99% do planeta cujo domínio raramente sera usado/evenenado
para ataques de phishing e qualquer outro tipo de fraude que tenha spoofing
como vetor primário de ataque risco, se esses 99% do mundo continuarem sem
DNSSEC o mundo será um lugar mais seguro
enfim, a diferença entre a vacina e o veneno é a dosagem
http://www.internetsociety.org/deploy360/blog/2014/09/cloudflare-re-affirms-goal-of-dnssec-support-by-end-of-2014/
http://london50.icann.org/en/schedule/wed-dnssec/presentation-dnssec-dns-proxying-25jun14-en.pdf
http://cr.yp.to/talks/2009.08.10/slides.pdf
http://dankaminsky.com/2011/01/05/djb-ccc/#dnsamp
https://twitter.com/hashbreaker/status/246746124222865409
>
> --
> Eduardo Schoedler
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
