Weekly Edition
Return to the Press page| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
DNS Inventor Warns of Next Big Threat (Dark Reading)
(Log in to post comments)
Interesting, not unexpected.
Posted Feb 12, 2008 0:28 UTC (Tue) by jd (subscriber, #26381) [Link]
As soon as it became obvious to people that spoofing DNS or poisoning DNS caches was viable, this has been a potential threat. DNSSEC was supposed to improve the security of the "DNS food chain" (as the article puts it), but I know few people who have been impressed with it or deployed it. Either it's flawed and needs reworking, or the admins are whinging and the major DNS brokers should impose it. I don't see it matters too much which it is, as much as it matters that DNS security is improved.Actually, network security overall needs a serious examination. Between EAP, HIP, KITTEN, SASL, SKIP, IPSec, a billion other IETF and other published secure protocls, and secure versions of standard protocols, there is no excuse for unauthenticated or insecure traffic on the Internet today.
The fact that security is a problem at all is evidence that something in the process is broken. Maybe it's the protocols, maybe it's the level of QA, maybe it's the attitudes of admins, maybe it's the attitudes of managers. Doesn't matter. 17 million mis-configured DNS servers is a lot, and if we assume comparable numbers of other services being also mis-configured, you've way too many vulnerabilities.
Many, many years ago, I remember reading the article published by a group who claimed to have security audited the Internet. They claimed a third of the sites they scanned had known vulnerabilities, and their scanner (BASS) was designed for speed, not completeness. Despite all the availability of secure methods and secure software, it sounds to me like things haven't really changed.
Interesting, not unexpected.
Posted Feb 12, 2008 1:43 UTC (Tue) by jae (guest, #2369) [Link]
"The fact that security is a problem at all is evidence that something in the process is broken." Yeah, right... there is no perfect security, so security always will be a problem. That's... nature (and I don't mean human, though that is a factor too). Security vs Convenience. 'nuff said. (That is not to say that it isn't sad that so many great(?) protocols exist, but are not deployed)
Interesting, not unexpected.
Posted Feb 12, 2008 22:32 UTC (Tue) by jd (subscriber, #26381) [Link]
Yes, computer software must be theoretically insecure, but that does not mean it is necessarily exploitably insecure. You need a continuous exploitable series of vectors from outermost point to exploitable point, for the system to be vulnerable. There will always be such vectors, but the coders have an advantage in that they don't need to prove such a continuous chain exists to either find or fix a bug, and admins can always install software and/or policies that eliminate entire classes of vulnerabilities.I'm concerned (to an extent) that software QA is still often seen as an optional extra, and I'm very concerned that admins often ignore what solutions do exist for restricting how someone could attack a system. Systems security often reminds me of the story of the tortoise and the hare, with one minor difference. The hare at least entered the race; by using insecure configurations and avoiding secure protocols, I'm not convinced that admins have even reached that point yet.
Interesting, not unexpected.
Posted Feb 13, 2008 1:47 UTC (Wed) by drag (subscriber, #31333) [Link]
Well lets start with getting rid of Email. Just rip it out, it's a total mess. IM is pretty good at avoiding spam. Being fairly realtime means that it's difficult to hide the origins and such and authentication is stronger. And FTP. That's a good one to get rid of. What you'll do to replace it is anybody's guess. Unfortunately. So that's about, what, half the Internet? A big job to be sure. And then there is some issues with TCP/IP that would be lovely to have resolved. Oh well. Still I've always hated Email. I would applaud it's demise. I mean it was great when it was new, but it's time has moved on. Just like Gopher's.
Interesting, not unexpected.
Posted Feb 13, 2008 20:29 UTC (Wed) by muwlgr (guest, #35359) [Link]
What's instead if email ? "IM2000" by djb ? Instant messaging does not care about message storage. It does not offer something like IMAP.
I think they meant (E)SMTP.
Posted Feb 13, 2008 23:51 UTC (Wed) by jd (subscriber, #26381) [Link]
Their complaints wouldn't apply to X.400 (which is still e-mail), where something like IMAP or POP3 would certainly be very usable.I think most people have given up on Lotus Notes, and DEC Mail had numerous scripting vulnerabilities that made it a Really Bad System. Trying to think of any other half-decent mechanisms, but nothing springs to mind.
Since delivery of e-mail is essentially appending to files (a special case of patching), there are probably ways of using version control systems to deliver multiple e-mails (even to multiple users) in a single network transaction securely. Never heard of anyone doing this though.
I think they meant (E)SMTP.
Posted Feb 14, 2008 12:02 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
> Since delivery of e-mail is essentially appending to files ( Only if you've not switched to maildir-like stores yet
Interesting, not unexpected.
Posted Feb 13, 2008 23:35 UTC (Wed) by jd (subscriber, #26381) [Link]
SMTP is not that great, but if you're only addressing security then SMTP over SSL is perfectly good. If you want to replace SMTP altogether, then the most comprehensive e-mail messaging protocol in existance has to be X.400, which contains all kinds of features that SMTP-based e-mail users would just drool over. E-mail isn't the problem, vanilla SMTP is.Replacing FTP is easy. SCP is the usual alternative. RSync over a secure transport is another popular candidate. I've even seen people distribute binaries over Subversion. FSP (connectionless FTP-like protocol) never really took off, but that's probably as much because nobody provided content using it. For interactive downloads, you could use something like Gopher. Again, if the issue is only security, then SFTP is perfectly good.
A lot of the issues with TCP/IP were addressed in IPv5 (I think that's what TUBA got allocated) and IPv6, but again content is limited. C'mon, it's easy to complain about protocols, but if everybody just continues to use what they hate in preference to something they would logically want, nobody is going to believe the complaints. I consider some of the groups who use alternatives as being, well, over-the-top, but I respect them deeply nonetheless because they make a sincere effort.
Interesting, not unexpected.
Posted Feb 12, 2008 6:02 UTC (Tue) by jwb (subscriber, #15467) [Link]
Are we really supposed to believe this 17 million figure? Do you believe it? I cannot believe it. The level is simply too large. Are there Windows bot nets which serve DNS? That might explain it. Nothing else can explain it. Think about it. If the 17 million figure were accurate, you would be likely to find at least one open recursive resolver in any randomly selected /24 network. That's much too common. I just tried 16 random netblocks and didn't find any. I scanned some of my hosts for open recursive DNS and I noticed that some admins have ozymandns installed, and this can look like an open, malicious, recursive resolver, but really isn't. I wonder if ozymandns can partly explain the 68000 malicious servers.
Interesting, not unexpected.
Posted Feb 12, 2008 6:14 UTC (Tue) by jwb (subscriber, #15467) [Link]
Er, I'd like to revise and extend my remarks. After focusing on the widely-used 64/8 block, I did find 3 open resolvers in 128 random IPs. How depressing.
Interesting, not unexpected.
Posted Feb 12, 2008 22:40 UTC (Tue) by jd (subscriber, #26381) [Link]
The exact numbers are probably not accurate. It's in the interests of people running such tests to find problems to overstate, just as it's in the interests of corporations and networking companies to understate. The distribution of unpatched/insecure machines will also be non-uniform and non-random, making an overall statistic hard to interpret. The truth is rarely out there, in any objective sense, but a subjective feel for the scale of the problem is probably good enough and an order of magnitude error won't change that nearly as much as it'll change the number itself.
Interesting, not unexpected.
Posted Feb 12, 2008 11:07 UTC (Tue) by niner (guest, #26151) [Link]
If I may ask naively: what is the problem with open, recursive resolvers?
Interesting, not unexpected.
Posted Feb 12, 2008 11:56 UTC (Tue) by job (subscriber, #670) [Link]
I believe the idea is that open resolvers can be utilized as traffic boosters in a DoS situation, think spoofed source address and the fact that replies are much larger than queries. I am guilty of this myself but remain unconvinced so far that this attack is actually used in practice. Over the last five years I have never seen a DNS reply flood, and even if this becomes a problem traffic limiting may even be more effective. I find it important to keep the net as open as possible as this is what kept it functioning over the years. This of course is a separate problem from poisoning DNS caches. The easiest way to completely avoid those attacks is to separate the resolver and the authoritative DNS in two separate entities. This is considered best practice by now and something every administrator should do.
It's not too difficult
Posted Feb 12, 2008 15:27 UTC (Tue) by mgb (subscriber, #3226) [Link]
Using something like this you can use a single primary DNS server which is authoritative for
your own zones while limiting recursion to clients on your IP addresses.
acl my-recursers {
localhost;
localnets;
... my CIDR blocks ...
};
options {
allow-recursion {
my-recursers;
};
};
It is non-obvious for authoritative BIND views
Posted Feb 12, 2008 16:03 UTC (Tue) by hmh (subscriber, #3838) [Link]
Your example is not enough to properly configure an authoritative server (although it is good
enough for a recursion-only cache server, I think).
The proper configuration for an authoritative BIND server ends up requiring the use of views
if you also need it to be a recursive server for some clients, I think.
For the authoritative view, you need:
additional-from-auth no;
additional-from-cache no;
as well as the more obvious:
recursion no;
Otherwise, you are still a problem for others (DoS amplifier at the very least).
Open DNS resolvers
Posted Feb 13, 2008 1:50 UTC (Wed) by gdt (subscriber, #6284) [Link]
Denial of service traffic multiplier which is particularly difficult for ISPs to counter. See my AusCERT alert AL-1999.004 which describes the problems we had dealing with the first observed attacks.
Interesting, not unexpected.
Posted Feb 18, 2008 12:03 UTC (Mon) by IkeTo (subscriber, #2122) [Link]
> what is the problem with open, recursive resolvers? As far as I can understand, open recursive resolvers, or "open recursive name servers", are DNS servers that are incorrectly configured to answer DNS requests recursively for public. (Normally there are two types of DNS servers: authoritative ones which answers queries using their own information to the public and never initiates queries themselves, and caching (or recursive) ones which answer queries from only a limited (reads: trusted) set of computers and will "recurse", i.e., initiate queries to find answers to queries that they don't know how to answer themselves.) The two properties that don't mix are (1) public and (2) initiate requests to get others' information. With both of them, an intruder can make a request to that open recursive resolver, hoping that it will not know the answer right away and thus would initiate a request, and fake a reply to that anticipated request. (The DNS mechanisms to disambiguate different replies from requests are not meant to be secure and thus not strong enough to deter intruders.) This causes the cache of the resolver to be "poisoned", i.e., hold information that is faked and decided by the intruder. E.g., from then on mail.google.com might be pointing to their servers instead of yours. Such incorrectly configured servers are always a problem for the users of these servers. As other noticed, if they instead fake entries to point to a web site, that site will suddenly receive a huge load of traffic. So they are a problem for those running a server. But they can be problems for others if intruders can cause somebody to "become" a user of that server. E.g., if a worm somehow causes your /etc/resolver.conf to be overwritten and point to such a misconfigured DNS server, then you become a user. Admittedly this requires that the intruder already has access to your computer, but this can provide an easy back-door.
DNSSEC
Posted Feb 12, 2008 14:50 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
As I understand it, DNSSEC was designed with the DNS roots as the root of the public key system. This makes sense, operationally. However, DNSSEC arrived too late to take advantage of the old cabals which would have given this key and its associated responsibilies to some group of technicians. The existence of a DNSSEC root would effectively be authority to create TLDs. All the squabbling politicians now involved in "running" the Internet think this power ought to belong to them. If you can get them all to agree, you can have DNSSEC as originally envisioned. Good luck with that. Without DNSSEC on the root, it makes little sense to have it for the TLDs, since black hats can (as I understand it) just spoof a root server response telling you that the TLD doesn't have DNSSEC. Without DNSSEC on the TLDs, it's basically useless except for internal matters. There are basically two paths to getting things deployed on the root servers, either you secretly agree with the operators to just do it, and then act innocent when ICANN and similar bureaucracies notice a few months later and ask what happened, or you have to go through months and years of bullshit meetings in which everybody is engaged in silly political games of point scoring, empire building etc.
DNSSEC
Posted Feb 12, 2008 18:24 UTC (Tue) by miekg (subscriber, #4403) [Link]
> Without DNSSEC on the root, it makes little sense to have it for the TLDs, since black hats can (as I understand it) This isn't true, but you will need to have the public key of the specific TLD to make it all work. The idea of having DNSSEC deployed on the root, means you will only need one key configured at home (or where ever).
DNSSEC
Posted Feb 12, 2008 21:45 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Ah right, thank you for the correction.
DNSSEC
Posted Feb 13, 2008 10:34 UTC (Wed) by copsewood (subscriber, #199) [Link]
A DNS tree can be rooted anywhere people will use it. Good examples of this in connection with specialised services are DNSBLs and DNSWLs . These can contain information about every IP address or domain on the Net. This makes the current root operators subject to a kind of competition, in the sense that if an alternate DNS root server organisation starts to offer greater value in connection with generic DNS services, the political interest of the current root operators will be forced to offer users what they want or become irrelevant. Presumably this would also apply to unnecessary delays in rolling out DNSSEC - if the DNSSEC standards and implementations are considered stable and usable enough for more than experimental rollout based on alternate root servers.
Interesting, not unexpected.
Posted Feb 13, 2008 2:03 UTC (Wed) by gdt (subscriber, #6284) [Link]
Either it's flawed and needs reworking, or the admins are whinging and the major DNS brokers should impose it.
It's all three.
1) The design is broken. Implementing DNSSEC allows all DNS names in a zone to be ennumerated.
2) Admins are hopeless. Most can't even implement a non-open DNS forwarder correctly. DNSSEC is well beyond their knowledge.
3) Firms which have won major DNS maintenance contracts don't wish to incur the additional development and running costs of DNSSEC as they currently see no benefit.
All of these can be fixed. (1) by reserving the top-level zone of a delegation (ie: *.example.com) for only publicly-known hosts and using a DNSSEC zone with a different key for private hosts (ie: intranet.*.example.com) or no DNSSEC at all where the DNS name does not matter (*.dhcp.example.com). (2) by training. (3) by politics.
Interesting, not unexpected.
Posted Feb 13, 2008 12:50 UTC (Wed) by admcd (subscriber, #5415) [Link]
(1) is also being addressed with the development of NSEC3 records (currently awaiting publication as an RFC) which add a layer of indirection using hashing to avoid the zone walking problem.
Big solution based on faults with an insecure operating system
Posted Feb 14, 2008 14:10 UTC (Thu) by nstraz (subscriber, #1592) [Link]
I just don't seem to understand why this is needed at all. IIRC, the DNS servers used for resolving are set either by the user or the DHCP server. Given that most people enter their ISP's DNS servers, how are they using rogue DNS servers? Let's assume that there aren't any rogue DHCP servers on their networks. The article states that viri are doing drive by reconfiguration of DNS servers on some operating systems. Shouldn't that be the focus and not adding more layers onto a working system? As one person notes, couldn't network admins force their users to use the local DNS servers? I'm already forced to use the network's SMTP server.