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.

Cisco BGP default-information originate

Não é um cenário muito comum utilizar uma rota default dentro do BGP para roteamento na Internet, no entanto, uma rota default é muito útil quando estamos falando de redes baseadas na tecnologia MPLS (utilizando BGP entre o CE e o PE), principalmente em topologias HUB-and-SPOKE.

Basicamente, é possível anunciar uma rota default de duas maneiras: 1) utilizando o comando default-information originate e 2) utilizando o comando network 0.0.0.0. A questão é: qual a diferença entre estes dois comandos ? (afinal de contas, os dois anunciam uma rota default! :-)

1) Default-information originate

Para utilizar o comando default-information originate dentro da configuração do BGP é necessário que uma rota default seja redistribuída para o BGP de outro protocolo de roteamento (dinâmico ou estático). Por exemplo:

ip route 0.0.0.0 0.0.0.0 189.1.1.1
!
router bgp 65000
default-information originate
redistribute static

2) Network 0.0.0.0

Se utilizarmos o comando network 0.0.0.0 dentro da configuração do BGP, desde que uma rota default esteja instalada na tabela de roteamento, o roteador passará a anunciar uma rota default para seus peers BGP (independente de como esta rota default foi instalada na tabela, via protocolo dinâmico ou uma simples rota estática).

ip route 0.0.0.0 0.0.0.0 189.1.1.1
!
router bgp 65000
network 0.0.0.0

Mais informações em: Cisco IP Routing Protocols Command Reference: Default-information originate

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
  

Cisco IOS 12.4(20)T e 12.4(15)T

Este mês a Cisco lançou para utilização a versão 12.4(20)T do IOS. Com esta versão a Cisco também anunciou algumas mudanças interessantes que quero destacar aqui. Algumas plataformas deixam de ter suporte no ciclo de desenvolvimento a partir da versão 12.4(20)T e passam a ter suporte somente na versão 12.4(15)T e nas atualizações já previstas no release notes de cada uma das plataformas. As plataformas que deixam de ter suporte são:

• Cisco SOHO 90 Series

• Cisco 831, 836, and 837 Series

• Cisco 1701, 1711, 1712, 1721, 1751, 1751-V, and 1760 Series

• Cisco 2610XM-2611XM, 2620XM-2621XM, 2650XM-2651XM, and 2691 Series

• Cisco 3631 and 3660 Series

• Cisco 3725 and 3745 Series

• Cisco 7400 Series

• Cisco AS5850 Universal Gateway

Para mais informações consulte o Cisco IOS Software Release 12.4T Q&A. Enquanto isso, a Cisco também anunciou que a versão 12.4(20)T não terá mais suporte à fast switching (entre muitas outras coisas), o que nos deixará apenas com process switching ou CEF. Há também alguns avanços consideráveis para as features existentes, como por exemplo a possibilidade de fazer logging do CEF ou a captura de pacotes diretamente no IOS. Para mais informações sobre novas features consultar o Cisco IOS Software 12.4T Features and Hardware Support.