Ten Percent of DNS Servers Still Vulnerable 170
maotx writes "Even with the uproar caused by the recent DNS attacks, a recent study shows that roughly 10% of 2.5 million DNS servers show that they are still vulnerable to DNS cache poisoning. To put that a little bit more in perspective, of that 10% discovered, 230,000 were identified as potentially vulnerable, 60,000 are very likely to be open to this specific type of attack, and 13,000 have a cache that can definitely be poisoned." From the article: "The use of DNS cache poisoning to steal personal information from people by sending them to spoofed sites is a relatively new threat. Some security companies have called this technique pharming."
Admins - Take some initiative! (Score:5, Insightful)
This is strikingly similar to the Cisco OS debacle, where a patch had been available for some time, yet Admins failed to patch their hardware on their own. Yes, it's a pain in the ass to take your network down, but look at the alternative...Hacked!
Re:Admins - Take some initiative! (Score:2, Insightful)
bad math (Score:4, Insightful)
How can I check my own DNS configuration for this? (Score:4, Insightful)
Any good tools to (or sites to help) check for those?
Re:DJBDNS -- rocks (Score:3, Insightful)
Re:Admins - Take some initiative! (Score:3, Insightful)
No, it isn't. Before the IOS "debacle" it was assumed that remote code execution on IOS was impossible. It's pretty hard to compromise an unpatched system if it's impossible to execute code on it, so admins didn't bother taking down their networks to run the (mostly aesthetic) patches.
Re:Admins - Take some initiative! (Score:3, Insightful)
You are assuming the fix is a patch. I get vulnerability reports for my servers every week.
And then there are patches like the last two Oracle patches which - get this - actually made it worse.
Sometimes it's a good idea to wait for them to patch the patch.
Re:Admins - Take some initiative! (Score:5, Insightful)
to be patched. That was the biggest part of the problem: Cisco's
silence.
When you run services that must be up 24x7, you don't donwload every new
IOS release and load it on dozens or hundreds (or more) of devices just
because there was a new release. IOS often has more new bugs in each
release than bugs fixed; when you find a release that has the features
you require and is stable with those features running, you don't touch
it until you find a bug, require a new feature, or Cisco announces a
security problem.
I run a relatively small network, and I'm looking at having to upgrade
around two dozen devices running IOS in six cities (a number of which
require visiting an unmanned office because some things can't be
upgraded remotely) plus another dozen or so devices in our spares
inventory in two cities. I'm not going to upgrade any operating devices
until I can test new releases in a test setup. All of that takes a lot
of time, which means something else has to get pushed back.
Re:DJBDNS -- rocks (Score:4, Insightful)
Apples and oranges.
There are places where you would have to use BIND and places where you can get away with a partial implementation. If an ISP is using DJB-DNS I would recommend to stay away from it. There is a number of neat tricks in the bind cache expiration algorithm (from late 8 and early 9 onwards) which DJB has blamed unnecessary (see the BUGTRAQ archives for the discussion). While they are not necessary they are essential to ensure that operational mistakes have a limited life. That does not happen with DJB implementation as well as some other ones. So if you screw up your TTL or serial no on the zone files - this is it. Same for poisoned entries.
Further to this. DNS is the most easily upgradeable service. Clients fallback automatically and a few seconds of downtime are in the "who cares" area. In fact every ISP out there has scheduled daily mandatory reloads which update configs. Do users notice - nope.
Even further to that, there are methods to make any number of dns servers answer the same address and because DNS is stateless this can be done without any clustering crap. ISC which writes bind have done this for 7+ years. Most global telcos and ISPs do it as well.
And, in order for DNS poisoning attacks to be effective name servers usually need to have both recursion turned on and return authoritative answers. Doing this on an internet facing server is an idiocy. If your ISP does that and serves authoritative requests from the same server which is used for name resolution in clients - RUN. They have NO CLUE WHATSOEVER. If they use clustering for resilience - run even faster.
wait!! (Score:2, Insightful)
Now that's it's Bind, it's the admin's fault?
Re:Admins - Take some initiative! (Score:3, Insightful)
In any case, it isn't a good idea to do a remote upgrade of a critical piece of equipment when, if there's a failure, it'll take a couple of hours to get there.
Who owes anything to you? (Score:3, Insightful)
That's what admins/geeks are. Think of the classic 'Hackers' movie, and the big admin with the password of 'God'. Admins love thier l33t Perl, C, TCL, Shell scripts because they do everything they need. We have contests as to who can make code that does something in the fewest number of lines (many references on Slashdot) and who can make the code decievingly complex (again many references).
DJB made something that fits with his views. He made it available to the public and people liked it so much they started to use it. The best part about DJBs stuff is that it does it's job and does it well.
I hear the big anti-qmail and anti-djbdns debate all the time about people who want tons of features in there. All of the features you can want are in patches, and patch collections that you can safely add. DJB has a mail system that does what he wants, and does it securely. He's not willing to accept patches into the mail distro because it taints its quality. That's his choice.
He wrote the code, he puts it up there. If you like it, use it. If you don't, avoid it. If you want features, make a patch for yourself or for others.
He's a smart guy who produced some damn good software that has a following for good reason. He doesn't want patched binary distributions floating around, as security issues in those reflect negatively on his word. As well, it keeps those who don't take the time to learn the basics of administration from operating misconfigured qmail installations. All good reason- I'd agree with most of it.
-M