Patch DNS Servers Faster

51mon writes "Austrian CERT used data from one of their authoritative DNS server to measure the rate at which the latest DNS patch (source port randomization) is being rolled out to larger recursive name servers. While about half the traffic (PDF) they receive is now using source port randomization, their data suggest that this is due to ISPs who roll out such fixes immediately. The rate of patching has fallen to disappointingly low levels since. If your ISP isn't patched, perhaps it is time to switch." After details of the DNS vulnerability leaked, researchers |)ruid and HD Moore released attack code; ZDNet's security blog has an analysis.

Comments

Switch DNS Servers, NOT ISPs

[masdog]

You don't need to switch to a new ISP if they haven't patched yet - just switch to a new DNS server such as OpenDNS.

Re:Switch DNS Servers, NOT ISPs

[masdog]

You can change this in your DHCP or IP configuration settings on your home router or PC. On my home network, for instance, my DD-WRT router isn't running a DNS server on it, and the DHCP static DNS settings are set for my Server 2008 box and the two OpenDNS resolvers. My Server 2008 box also has its forwarders set to OpenDNS.

That's probably more complicated than it needs to be, but better safe than sorry.

On Windows XP, 2000, and I think Vista, you can tell Windows to ignore the DNS server settings provided by DHCP by going into the IP properties for the connection and hard coding in the IP addresses under Local Area Connection Properties > Internet Protocol Properties > Use the Following DNS Server Addresses.

This can also be done under linux, but I don't know the particular commands for it.

Re:Switch DNS Servers, NOT ISPs

[A beautiful mind]

I digress. If an ISP didn't patch yet, it means they are incompetent. When the Debian SSL vulnerability was discovered, I sent two emails out, one to my server hosting company and one to my phone company. The server hosting company replaced their ssl cert within a day, the phone company took 4 months, meanwhile their online user gateway was open to sniffing.

I ditched the phone company when my email didn't get a reply in a week.

Re:Switch DNS Servers, NOT ISPs

[Anonymous Coward]

I had been using OpenDNS. I stopped when I realized they were monitoring my traffic. When I go to Google, they were returning their own Google-like page, to which my browser would submit the query, and then redirect me to Google.

I stopped using them after that discovery.

Re:Switch DNS Servers, NOT ISPs

[Woy]

I used OpenDNS and gave it up because it replaced firefox's feature to search google with what you type on the address bar with its own crappy search.

Re:Switch DNS Servers, NOT ISPs

[Ciarang]

It always surprises me how much love there seems to be for OpenDNS on /.

A DNS server returns you a result, or tells you that it can't resolve the domain. Instead of doing the latter, OpenDNS redirects you somewhere you didn't intend to go and attempts to hit you with some advertising. That seems more like typosquatting to me, although admittedly it's with your permission.

Re:Switch DNS Servers, NOT ISPs

[eln]

resolv.conf will be written over by DHCP unless you set PEERDNS=no in the /etc/sysconfig/network-scripts/ifcfg-ethX file.

Monopoly

[Anonymous Coward]

If your ISP isn't patched, perhaps it is time to switch.

My ISP has a monopoly over internet services in my area you insensitive clod.

Re:Am I safe?

[masdog]

Dan Kaminski's website has a DNS checker on it.

time to switch?

[Dunbal]

If your ISP isn't patched, perhaps it is time to switch.

      Thanks to the "free market economy" in my capitalist country I can't switch, you insensitive clod!

AT&T Southeast way behind the curve

[BDaniels]

We use AT&T (formerly Bellsouth) and their servers are not fixed according to the 'dig +short porttest.dns-oarc.net TXT' test.
I contacted their NOC about the problem yesterday and got the following reply:

"Patching for these servers are scheduled to begin next week."

So, major vulnerability, two weeks advance notice, exploit code released - we'll get around to it later.

Re:Am I safe?

[Nos.]

There's a couple issues with the one Dan created. First, its slashdotted. Secondly, some ISPs don't allow querying from just anywhere, only from its own customers (IPs). Here's a test you can run from any machine with dig on it:
https://www.dns-oarc.net/oarc/services/porttest

Re:Am I safe?

[Lennie]

dig +short porttest.dns-oarc.net TXT

Oops.

[Chameleon Man]

I tried to RTFA, but upon clicking the link I was directed to a porn site.

Easier Said Than Done

[foo fighter]

These kind of systems are really hard for security guys to get changed.

It's like updating switch and routing firmware. Most network engineers who know what they're doing and that have been around for awhile have been burned by "simple" or "easy" patches and config changes going tits up.

When your core network infrastructure goes tits up your phone tends to light up like a christmas tree. (Granted, when your web presence is redirected to porn or a copy that hides an iframe exploiting customers with unpatched browsers, well, you'll maybe get some phone calls.)

This DNS patch is a case-in-point: Microsoft's fix is rather ham-fisted and broke stuff; the BIND-Users list is full of people troubleshooting ISC's patch.

Also, many organizations (like mine) are taking this as an opportunity to reengineer their DNS architecture. This is the perfect time to reevaluate using TSIG and DNSSEC if you don't already.

It has only been just over two weeks since the initial "announcement". The progress so far is really amazing when you consider how big a ship the Internet is.

Rediculious requirements

[Coolhand2120]

Maybe if the patch didn't require that open up all incoming and outgoing UDP ports on the DNS interface I could implement it faster. Seeing how most people use firewalls it makes it really quite a bit more difficult than just "apply the patch".

NOTE WELL: This update causes BIND to choose a new, random UDP port for each new query; this may cause problems for some network configurations, particularly if firewall(s) block incoming UDP packets on particular ports.

I'll get this patch applied as soon as I reconfigure my entire network topology.

Re:Rediculious requirements

[billcopc]

You can restrict it to a port range... even giving it access to 2048 ports gives you 2^11 randomness, which is still better than 2^0.

The issue I'm facing, which I find terribly frustrating, is in upgrading older distros. I'm now looking at completely reinstalling a bunch of older BSD servers just to get this idiotic vulnerability resolved, because the maintainers aren't backporting the patch and upgrading BIND itself would be a royal pain. Given how DNS servers tend to run unattended for eons, I suspect this near-sightedness is respnosible to a large degree for the slow patching. It's not that I don't want to patch my servers, it's that I now have to waste a day at the colo doing physical reinstalls. If it weren't for that hitch, I'd be done already!

Re:Rediculious requirements

[molo]

Maybe if the patch didn't require that open up all incoming and outgoing UDP ports [securitytracker.com] on the DNS interface I could implement it faster.

That is not the case at all. First off, on outbound requests, the destination port is still 53. The _source_ port is what gets randomized. On inbound replies to the randomized port, your stateful firewall will see this as an ESTABLISHED connection and you can safely let it in without blindly opening up the entire UDP port space.

You _are_ running a stateful firewall, right? Its not 1998 anymore.

-molo