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.
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.
My Sysadmin Blog
How can I know if my ISP has patched its DNS servers?
My ISP has a monopoly over internet services in my area you insensitive clod.
Fortunately my domain name is not recursive therefore I am safe.
Don't we already all have our own patched DNS servers at home?
Click here.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Yes, this is a simple way: https://www.dns-oarc.net/oarc/services/porttest
Dan Kaminski's website has a DNS checker on it.
My Sysadmin Blog
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!
Seven puppies were harmed during the making of this post.
Here in Belgium, I use Scarlet as my ISP.
It seems that dns queries have become much slower. With opera I can see what urls are being requested (main page, images/flash or ads).I can see that for every new page the first thing opera does is doing the dns queries for all the urls. And this has become very slow from time to time.
I've read somewhere that the randomization really slows down bind, but that the team is working on a patch to solve that.
(I also don't understand why opera need to execute dns queries every time I click a link, why can't opera have a tiny cache for the ip addresses? They don't chance that often, do they? I'm not very paranoid about the security implication, either.)
Dependency hell? =>
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.
If your ISP isn't patched, perhaps it is time to switch.
To whom, exactly?
Sincerely,
A US ISP customer.
How would one potentially do something like this? Is it a setting inside the modem or router's firmware?
It's a setting found when you RTFM!!. Try Google, in fact I recommend also visiting this site http://www.justfuckinggoogleit.com/. Yes that's a real site, it's safe to visit, and it's very funny although somehow you yourself might not think so.
So yes, for common knowledge that is easily looked up via Google, remember that RTFM stands for READ THE FUCKING MANUAL and Google is a great method of fulfilling "manual". Thank you.
Note that some DNS servers do not trust DNS glue in such a way that they need source port randomization for recursive lookups.
I know of at least one DNS server implementation that only trusts glue from root server responses and only the first delegation, and only for domains specifically and exactly queried for.
Who uses their ISPs DNS servers? Most people probably. Well, I don't trust them. My friends and I run a recursing nameserver that we access over a VPN link.
ISPs just aren't trustworthy.
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
I tried to RTFA, but upon clicking the link I was directed to a porn site.
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.
obviously no deficiencies vs. no obvious deficiencies
You should probably use http://66.240.226.139 if you're not sure.
... or should you?
I'll get this patch applied as soon as I reconfigure my entire network topology.
OpenDNS returns their own search page for bad lookups, rather than NXDOMAIN, breaking various things. They also send queries for www.google.com to their own server. (I wrote about this recently.)
damn, it's www.doxpara.com, and it resolves to 157.22.245.20. But I can't directly access it with that IP address.
Easiest is to temporarily put it in /etc/hosts.
New things are always on the horizon
It's one single change on the firewalls, nobody needs to "reconfigure [their] entire network." And should be easier if as most large organizations the DNS servers are on a DMZ.
and, how is this a problem?
In addition to the metasploit module published yesterday, another exploit has just been posted to dailydave...
If you get your queries redirected you either have a virus or you have mistyped Google.
Love many, trust a few, do harm to none.
"404 error: File not found" is more useful then the OpenDNS search result page?
Love many, trust a few, do harm to none.
It's odd how much traffic is being sent to openDNS now. Only one source for ips sounds like a very bad idea. It's only a matter of time before folks find flaws in openDNS.
... now might be the time to look into stateful firewalls, huh?
Well, okay, 'stateful', most modern firewalls should be able to fake a stateful connection for UDP.
I'm surprised that more folks here aren't running their own resolvers. It isn't that hard, especially if you don't need to act as an authoritative server for serving your own domains and just need a recursive resolver. One nice hack you can configure if you run your own resolver is dnssec - cryptographically secured dns lookup. While there aren't many dns zones that are cryptographically signed yet, there are a little over 10,000 (see http://secspider.cs.ucla.edu/ ). That is a start. Unless people start using dnssec and demanding that their websites be in secured dns zones, companies won't be bother to do the work needed to configure their dns zones with dnssec. A pdf with simple instructions for setting up dnssec can be found here. I set up my domains and resolvers this way, and it only took an afternoon to get acquainted enough with the concepts to bumble through the instructions. I've been running it for a few days now and it seems to be working just fine. http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf
I posted this also at Secrecy and the DNS flaw :
The solution is apparently to start used random selected UDP source ports on the nameserver when answering to DNS requests. Well the new problem has with this solution already been created : "Vulnerability in IANA root servers, servers go down after UDP port storm."
The only sensible solution is to create a hierarchical slaves.conf access list. WHO are allowed recursive access to higher up bind servers? Besides selection using ip-numbers, one can also be awarded with a valid DNS SEC hmac-md5 key. Ok I know this is Big Brother style stuff. But i don't know of any DNS hackers who like to leave their identity inside nameserver logs.
The core problem is recursive access to upstream authoratitive DNS servers. ISC should fix this inside bind9. But using random UDP ports opens up a whole new range of even more nasty DoS problems.
a caching DNS server which gets its cache polluted. If the attack setup is such that faulty DNS info is cached, is then the caching DNS server in error? I don't think so. What is needed is authentication and pgp/checksum info to see if the offered DNS info to be cached is valid.
Robert
primary: 4.2.2.1 secondary: 4.2.2.2
YMMV, but I found it much faster (in terms of pageloads) than OpenDNS's.
Tech Public Policy stuff
How many people have a DNS server that sits behind a small network device of some sort that does NAT and assigns port numbers in sequence, destroying any internal randomness?
dns-oarc.net? I think something is wrong at their end. (either they're FUBAR or the 4.2.2.* nameservers are down, and if the nameservers are down, I'm not connecting to anyone... which would appear not to be the case)
Tech Public Policy stuff
I don't even know what the hell this is supposed to mean. "create a hierarchical slaves.conf access list. WHO are allowed recursive access to higher up bind servers?".
a) what do you mean by "higher up"? Higher up the namespace hierarchy, e.g. the .com servers as opposed to the root servers? They don't offer recursive access today, so your statement has no meaning.
b) why call it slaves.conf? Are you suggesting that everyone start slaving zones from each other? I don't get it.
AT&T Wireless isn't patched, according to doxpara.com. I can't exactly just switch carriers for my iPhone, though, and I can't reconfigure the network settings to use a different DNS, either. I guess I'll have a good excuse for browsing porn on it now: "But I typed google, I swear!"
So, which ISP do you choose if you live in a country that has only TWO, who happen to choose to share the monopoly ?
Free speech was meant to be free for all... how can anyone grow up in a nanny state ?
I have an OpenSuSe 10.2 x86_64 machine and have manually upgrade-installed the x86_64 RPMs from the security announcement (http://lists.opensuse.org/opensuse-security-announce/2008-07/msg00003.html). Yast2 has some problems due to this release being old and mirrors not available so I did a manual "rpm -Uhv".
Still, from a traffic dump it seems that on SuSe 10.2 the caching Bind nameserver sends out queries with predictable source ports (incrementing by 1).
Fedora's patched Bind sends from random ports (didn't run statistical randomness test on them, though).
if all else fails, i can always use my isp's nameserver, which should be fixed by now.
Tech Public Policy stuff