Teste o seu DNS recursivo!

É possível testar se o seu DNS recursivo está atualizado utilizando (além do teste disponível na página do Dan Kaminsky) o teste on-line disponibilizado pelo DNS-OARC ou através da linha de comando abaixo.

$ dig +short porttest.dns-oarc.net TXT
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"x.x.x.x is GREAT: 26 queries in 5.1 seconds from 26 ports with std dev 18219"

Para testar on-line (com gráficos!!) :-), basta clicar AQUI.

Você está vulnerável a DNS cache-poisoning?

Seguindo os artigos já publicados neste blog sobre a vulnerabilidade de cache-poisoning do BIND, descoberta acidentalmente durante as pesquisas de Dan Kaminsky, ainda há muito o que ser feito para que se chegue realmente a solução definitiva.

Mas... como saber de forma prática e rápida se seus servidores de DNS estão vulneráveis a este problema? A dica é para um applet disponível no blog DoxPara (do próprio Dan) que faz a validação. Basta clicar em Check My DNS.

O seu DNS ainda está vulnerável?

Bem, nem tudo está perdido, pois há serviços na Internet que fazem a resolução de nomes (sim, é o que o DNS/BIND faz) "de graça" e em servidores que contem os últimos patches de segurança aplicados. Segundo a OpenDNS, os servidores deles não possuem esta vulnerabilidade.

É ver para crer.

Qual é a versão do seu BIND?

Esse é um problema velho, muito velho... Velho mesmo! Mais ainda existem servidores de DNS que possuem essa feataure habilitada. Nos tempos em que se fala em vulnerabilidades do protocolo DNS (que sempre existiram, é bom ressaltar) muita gente além de não atualizar a versão do BIND, não segue as melhores práticas de segurança para servidores de DNS.

É possível, com uma query de DNS simples, descobrir a versão do BIND instalada do servidor de DNS (e não é só do BIND não...). Os exemplos abaixo são de dois grandes provedores de Internet no Brasil:

$ nslookup -type=txt -class=chaos version.bind ns1.xxxx.com.br
Server: ns1.xxxx.com.br
Address: 200.xxx.x.172#53

version.bind text = "9.3.1"

$ dig @ns1.xxxxxxx.com.br version.bind chaos txt
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.3.4-P1 <<>> @ns1.xxxxxxx.com.br version.bind chaos txt
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4419
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 5 IN TXT "Served by POWERDNS 2.9.20 $Id: packethandler.cc 539 2005-11-11 11:17:47Z ahu $"

;; Query time: 34 msec
;; SERVER: 200.xxx.xxx.4#53(200.234.202.4)
;; WHEN: Tue Jul 22 17:04:44 2008
;; MSG SIZE rcvd: 121

Para não permitir que o BIND forneça sua versão com este tipo de consulta é necessário configurar a opção:

options {
version "Not disclosed";
}

Para mais informações, consultar este link.

Vulnerabilidades no DNS

Se você esteve viajando pela galáxia neste mês de férias e chegou na Terra agora provavelmente não percebeu que no último dia 8 de julho o US-CERT em coordenação com os principais desenvolvedores de sistemas de DNS (tal como o ISC e a Microsoft) divulgou um alerta sobre algumas vulnerabilidades inerentes ao protocolo DNS e que estão presentes em quase todas as implementações disponíveis hoje. Estas deficiências do protocolo DNS destacadas no alerta do US-CERT podem levar ao envenenamento do sistema de cache do DNS (DNS cache poisoning). Antes de você terminar de ler esse post, vá aplicar os patches nos seus servidores de DNS!

Estas vulnerabilidades vieram à tona devido ao trabalho desenvolvido por Dan Kaminsky da IOActive e o resultado nós poderemos ver em uma apresentação na próxima Black Hat no dia 7 de agosto ou talvez um pouco mais cedo já que o SANS ISC divulgou hoje que esta vulnerabilidade talvez já esteja sendo explorada.

É certo, também, que a idéia básica de spoofing no DNS não é nova. Paul Vixie - que para quem não conhece é o criador do BIND - destacou essa vulnerabilidade em um artigo da Usenix em 1995:

"With only 16 bits worth of query ID and 16 bits worth of UDP port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available BIND code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all."

Portanto, mais uma vez, mantenha os seus sistemas atualizados (leia novamente a frase anterior). Vale lembrar também que a aplicação das atualizações de segurança não garantem a total segurança de um servidor pois, como já foi comentado, este problema é intrínseco do protocolo. A única forma de resolver definitivamente este problema é a adoção de DNSSEC, o que hoje é quase impossível.

Mais informações em:

• ISC SANS - http://isc.sans.org/diary.html?storyid=4765
• US-CERT Vulnerability Note VU#800113 - http://www.kb.cert.org/vuls/id/800113
• BIND Vulnerabilities - http://www.isc.org/index.pl?/sw/bind/bind-security.php
• Microsoft Security Bulletin MS08-037 - http://www.microsoft.com/technet/security/bulletin/ms08-037.mspx
  

DNS e os Ataques de Negação de Serviço

Desde a última semana nós temos ouvido falar de ataques de DoS (ou negação de serviço) e de servidores DNS e, por isso, acho interessante observar o que está acontecendo na rede mundial.

Não é de hoje que sabemos da existência de algumas falhas no protocolo de resolução de nomes na Internet (DNS) que permitem a exploração e a amplificação dos ataques de negação de serviço. Por exemplo, a própria escolha de rodar o DNS sobre o UDP (protocolo não orientado a conexão e que pode ser facilmente forjado para enviar falsas requisições) é uma falha que é muito discutida - veja o draft do Frederico Neves (Registro.br) e do João Damas (ISC) no Working Group dnsop do IETF: "Preventing Use of Recursive Nameservers in Reflector Attacks" e o white paper da Verisign intitulado "Anatomy of Recent DNS Reflector Attacks from the Victim and Reflector Point of View".

A principal questão é: o que eu estou fazendo para me proteger? A resposta desta pergunta pode parecer simples, mas não é. Eu comecei a perceber isso quando me deparei com administradores de DNS que nem ao menos sabiam dizer o que é uma "DNS recursivo". Então, vamos lá:

Um servidor de DNS recursivo está configurado para responder a qualquer requisição de DNS independentemente do IP de origem da requisição ou do tipo da requisição. Esta é uma configuração que permite fazer funcionar qualquer servidor DNS em qualquer rede conectada à Internet - e acredito que muitos servidores estejam configurados desta forma.

O problema começa a ocorrer quando alguém resolve atacar o IP 10.10.10.1 (note: somente como exemplo estamos utilizando endereços inválidos). Este atacante envia uma requisição de DNS com IP de origem 10.10.10.1 para um servidor DNS recursivo qualquer e este servidor responde para o IP 10.10.10.1. Multiplique esta resposta pelo número de servidores que respondem requisições recursivas na Internet e você poderá estimar a quantidade de pacotes (teórica) que pode ser gerada para a vítima do ataque. Mais informações técnicas estão disponíveis no site o CERT.br.

No entanto, adotar políticas de segurança pontuais quando o "burburinho" está acontecendo não é a solução de todos os problemas. Por exemplo, como o endereço IP de requisições de DNS pode ser facilmente falsificado é relativamente fácil fazer um ataque utilizando servidores de DNS recursivos configurados para responder consultas recursivas para um grupo restrito de hosts e atacar um host desse grupo restrito, principalmente se existe um grupo grande de servidores DNS recursivos para este grupo de hosts. Por isso é importante implementar políticas de anti-spoofing no perímetro da rede - ou seja, não é permitido tráfego da parte externa para a parte interna da minha rede com endereço de origem de um host interno.

Apesar da possibilidade remota de fazer um ataque que seja suficientemente grande para prejudicar o funcionamente normal de um servidor vítima, o exemplo acima ilustra perfeitamente como a segurança deve ser implementada em diversas camadas quanto possível e que é absolutamente necessário conhecer todos os aspectos do ambiente que queremos proteger.

Para verificar se o servidor de DNS do seu domínio responde consultas recursivas, basta utilizar um das ferramentas publicamente disponíveis neste site. Destaque para o site DNSreport (ou DNSstuff).