This was updated version of my famous “Seven Deadliest Sins” talk, intended for a technical audience.

The slides with speakers notes are here:

• DNS Security: The Seven Deadliest Sins

OASK is a new security group in Ottawa. It’s supposed to be technical, informal and free. If you’re in town, check out the OASK web site for meeting dates and location.

Related posts:

• DNS security: The seven deadliest sins
• (Unencrypted) site security confirmed!
• DNS root zone getting DNSSEC

This is an important move to mitigate the worst vulnerabilities in DNS. As I presented recently, design flaws in the DNS protocol make it impossible to prevent attackers from spoofing DNS records, among other vulnerabilities.

DNSSEC signs responses from DNS servers, making it possible to detect fake records. However, DNSSEC is only trustworthy if the tree is signed from the root on down. ICANN has a summary of the issues here: DNSSEC – What Is It and Why Is It Important?

Signing of the root zone has been delayed by political issues… what organization would be trusted with owning the root key, whether it would be distrusted by other nations or abused because of the U.S. origins and other issues.

Ironically, due to the complexities of all the crypto code needed to support this we’ll probably see more vulnerabilities in DNS server software… at least in the short term. As the history of OpenSSL and other crypto libraries demonstrates, implementing crypto code is difficult to get right. Slapping crypto onto existing software initially makes it more exploitable, not less.

Related posts:

• DNS cache poisoning made easy
• Securing DNS with a validating resolver
• Fast flux botnets

In honor (?) of that that, I gave a quick presentation last week to the Ottawa CitySec group on Domain Name System security. Since the Kaminsky issue has been pretty well covered, I focused on all the other DNS security issues that are often overlooked.

I only had 30 minutes to present, so this is a cut-down version intended for a technical audience who already understand what DNS is and how it works.

The slide deck (with notes) is now online:

• DNS Security: The seven deadliest sins (PDF)

Related posts:

• DNS security talk
• (Unencrypted) site security confirmed!

Will IPv6 adoption be a disaster for information security? Of course it will: every new thing is a disaster: email, instant messaging, wireless, VOIP, mobile devices, social networks, e-commerce, cloud computing… and of course the granddaddy and still reigning champions of security disasters: web browsers and web applications.

We’ve all heard the “IPv4 is running out” admonition for a decade, but now it may finally be true. Still, most still see no business need for IPv6. Adoption will probably languish until it’s no longer feasible to acquire IPv4 netblocks, then IPv6 will be rushed into place without proper design, testing or understanding of the issues.

But IPv6 is not just another protocol or type of application. Nor is it just IPv4 with more numbers. Consider the following:

• Mandatory IPSEC (with all the associated crypto code)
• Mandatory multicast
• Mandatory QoS
• Automatic configuration of interfaces (DHCP replacement)
• All devices Internet addressable (no more NAT)
• Massive (up to 4GB) packet sizes
• Many new rules for routing, private addresses, DNS, packet analysis, fragmentation, and so on.

Lots of complex new code at the driver, network and application layers must be written to implement all the above. Like all new code, it will be buggy as hell for many years. But slowly the implementation flaws will get patched.

However, the above also means a fair-sized learning curve for developers, network architects, operation staff and security folk. If organizations just treat IPv6 like it’s IPv4 with more addresses, it’s going to be a mess for quite a while.

People, policy, standardds and procedures are not so easy to patch. RFC 4942 and a few other guides exist to help people get up to speed, but a lot of unlearning will need to be done. Cherished concepts like firewalls, NAT and IDS must be re-thought (heh… the Jericho folks finally get some traction .

Will large-scale rollout of IPv6 be a reiteration of the last 15 years? Are we about to see this century’s version of open ports, ping of death, source routing, IP spoofing, tunneling, cache poisoning, buffer overflows and denial of service attacks?

We defenders have a lot of learning and research to do: learn the new packet structure, fuzz every vendor’s IPv6 stack, test firewalls and IDS, add IPv6 capabilities to existing assessment tools and write many new ones.

(Speaking of firewalls: there are a disturbing number of products that handle IPv4 packets fine but either let IPv6 packets though, permit source routing or just overflow badly when they see a bad packet.)

The assessment tools are not there yet. For example, Nmap has had basic support for IPv6 for years, but only for simple connect() scans. Support in Nessus is similarly limited, and Nessus replacement OpenVAS can’t do IPv6 at all.

But evaluating the security of IPv6 implementations doesn’t just require an IPv6-enabled version of existing tools. The differences and new features in IPv6 mean we’ll see many new types of vulnerabilities, and need new tools to detect them.

As usual, expect the attackers to lead the way. Then expect the current cycle to continue: implementation errors will be ignored and disputed by the vendors then grudgingly patched, networks will be restructured, and ugly hacks will be invented to work around fundamental vulnerabilities in the protocol specifications themselves.

It’s going to be a great time to be in networking and security. I just hope it won’t take another 15 years to get back to where we are now.

No related posts.

We’ve had DNS security checks as part of our vulnerability assessments for years, and I’ve yet to encounter a provider’s DNS that is properly protected against attack. DNS tends to be yet another security blind spot, though it did get attention for a while when Dan Kaminsky’s cache poisoning exploit exploit made headlines last summer.

On the client side you can bypass your ISPs DNS with OpenDNS. It’s well maintained and offers a few other benefits like phishing filters.

However, OpenDNS is not meant for servers. For web servers or entire intranets, install a local resolver to go directly to the authoritative servers for each domain.

Using BIND is the default choice for this… it comes with all versions of Linux, but it’s memory intensive and has a history of security issues. Another popular choice is DNSCache, but it’s unmaintained and has some annoying dependencies and requirements.

A better choice is Unbound, a newer DNS caching resolver specifically designed for performance and security.

Unbound is developed by a NLNet, a Netherlands applied research group and supported by big names Verisign and Nominet. Its purpose is to be validating, recursive, and caching DNS resolver with good support for DNSSEC.

To be clear: Unbound is not for providing authoritative DNS. If you need to host DNS records so Internet users can can find your web sites and mail servers use BIND or other authoritative DNS configured to act only as an authoritative server.

Several DNS forgery protections are built in such as filtering private IP addresses from external DNS replies.

Want to block access to certain sites or services? Unbound also has handy features administrative features like  redirecting specific DNS queries to your own IP addresses… whether an entire domain or just specific records.

All this in a package that can be compiled easily on nearly any Linux or Unix, uses as much or as little memory as you tell it to, and has an easy configuration syntax. In short, Unbound rocks.

Compiling from source

Packaged versions of Unbound are in the Ubuntu Linux Universe repository starting with Hardy. Redhat doesn’t offer it yet. Regardless, new releases with many improvements come often and it’s easy to compile, so you’re better off building it yourself:

Download the latest source, extract the tarball then do the usual “./configure; make”. It depends on the libevent library, but the source includes an alternative if that is not installed.

Do “make install” to copy the libraries, executables and man pages to the right places (/usr/local/). A well-commented config file is installed in /usr/local/etc/unbound that has sensible defaults, but you should read through it. The daemon also runs chrooted from that directory.

Installing

Add a user and group to the OS named “unbound” and lock it from interactive access with “passwd -l”.

Download the latest root DNS hints file from ftp://FTP.INTERNIC.NET/domain/named.cache and place it in /usr/local/etc/unbound. Make sure user “unbound” has read permissions on the named.cache file. Edit the unbound.conf file to change the setting “root-hints” to point to /usr/local/etc/unbound/named.cache.

To test the installation, start the daemon from the command line by typing “unbound”. If it works, you will see a process named “unbound” running. If not, errors are written to syslog: check /var/log/daemon.log, /var/log/messages or whereever your system’s syslog writes daemon messages.

Once running, try a few lookups using dig, e.g.:

dig @127.0.0.1 www.advosys.ca

Configure the server to use Unbound for DNS lookups by editing file /etc/resolv.conf to add the following to the top:

nameserver 127.0.0.1

Now the part everyone hates: writing the startup script. For Unbound to start automatically when the server boots, a suitable script must be placed in /etc/init.d (for most Unix and Linux systems) then symlinked to appropriately named files in the /etc/rc.x directories.

To save you some work, we’ve written the following simple startup scripts for Unbound:

• Redhat / CentOS 5.x
• Ubuntu / Debian

Place the appropriate script in directory /etc/init.d, rename it to “unbound” then use the install method appropriate to your version of Linux:

Redhat / CentOS:

chkconfig --add unbound
chkconfig unbound on

Ubuntu / Debian:

update-rc.d unbound defaults

There are several options in the unbound.conf configuration file worth customizing, e.g. to disable IPv6 if you’re not using that, add sanity checks to weed out spoofed DNS replies, etc.  However, Unbound works well right out of the box in most situations.

With a good caching resolver like Unbound, your servers can directly query authoritative DNS servers, bypassing your provider’s probably polluted DNS. At the cost of slightly more network traffic and more memory usage, you can be reasonably confident that DNS answers legitimate and not pointing to malicious IP addresses.

Related posts:

• Hardening DNS with the Cymru Secure BIND template
• DNS cache poisoning made easy

“This is a powerful attack, as it retracts the security of BIND 9 to almost where it was over a decade ago,” says the “executive summary ” from the group who published the flaw. All versions of BIND 9.x are affected, which is what the majority of DNS servers on the Internet are running.

The worst flaw gives attackers a “1 in 8 chance of guessing the next query id for 50% of the query ids” coming from a DNS server, which are excellent odds. The attacker only has to get a victim’s DNS server to query a domain hosted on server he controls (e.g. by sending email to the victim’s SMTP server, causing it’s spam filters to do a lookup on the attacker’s domain). Then it’s just a matter of predicting the next query ID to send spoofed answers to the victim DNS and suddenly update.microsoft.com starts resolving to an IP in Siberia.

New versions of point releases in the BIND 9.x series are available that fix the flaws. You need BIND 9.2.8-P1, BIND 9.3.4-P1, BIND 9.4.1-P1 or BIND 9.5.0a6.

A decade ago when I first started working in Internet security I would’ve been very excited by this kind of flaw: an easy exploit that affects pretty much the entire Internet… the phishers and other criminals are going do lots of damage with this. However now I’ve seen too many major organizations (especially government) who still haven’t taken even basic steps to secure their name servers : they’re still running ancient versions of BIND, allowing recursive queries from outside, no split DNS, and so on. This predicable query ID issue is nasty, but in reality it’s so far down the list of issues for most organization’s DNS infrastructure that it’s hard to get too excited about it.

Related posts:

• Hardening DNS with the Cymru Secure BIND template
• DNS root zone getting DNSSEC
• Securing DNS with a validating resolver