Slashdot Mirror
Securing DNS From The Roots Up
jeffy124 writes: "This article at ComputerWorld tells the story of how ICANN would like to replace the root DNS systems with secured servers. Lars-Johan Liman, one of the root operators, spoke about the concept at ICANN's annual meeting today. He discussed how the world's current redundant DNS system is vulnerable to DDOS attacks and yet-to-be-discovered root holes in bind that can ultimately undermine the entire Internet by taking away the name-IP mappings that are relied upon by just about everyone."
I know this is slightly offtopic, but this was there on the bugtraq mailing list, thought ppl here may find it interesting:
/var logging is recoverable. This machine was running
/usr/bin/bin/u/src/ircd
/u/, mysqld klogd ...)
.dk domain, as well
.cais.net .cais.com
/usr/sbin/init.d
/sbin/ipchains -I input -p tcp -d 0/0 3879 -j DENY
To: bugtraq@securityfocus.com
Subject: Fwd: Possible DDOS network being built through ssh1 crc compromised hosts
I am making this notification to assist in determining whether other
folks have been affected by this attack.
An associate's home NAT gateway linux box was hacked by what I am
guessing was the ssh1 crc bug (ssh1 was the only exposed service).
This
machine looks to have been compromised on Nov 2nd at 1:15pm PST, I
won't know for certain until I obtain his hard disk later today, and
provided that
redhat 6.2, reasonably patched except for the fact that he was still
running ssh1.
It appears that someone may be building up a network of (potentially)
DDOS hosts. I have done some quick research and found no matches for
the signatures I have been able to identify so far.
Using the Chkrootkit (www.chkrootkit.org) utilities did not identify
a known trojan pack, so if this isn't identified in the wild, I'm
already referring to it as the LIMPninja.
It also appears that this particular host was used as a central host
for other LIMPninja zombies. Also, haven't been able to determine
what the command structure it is that the remote bots act upon.
The following is by no means complete, even after a full examination
of the drive has been completed, as there was never any file
integrity base line completed(a shame).
The attack appears to be scripted as all changes happened within a
minute, except for the IRC server which was not installed until 2
days later (and manually). When I found this particular irc net
there were over 120 hosts all communicating via IRC. This host was
found to be running an unrealircd daemon from
listening at port 6669.
All other compromised hosts were joining this irc network
(ircd.hola.mx holad) on channel #kujikiri with a channel key of
'ninehandscutting'. All bots joined as the nick ninjaXXXX where XXXX
is some RANDOM? selection of 4 upper case letters.
Several ports were listening
3879 term (this port had an ipchains rule blocking all external
traffic - placed by the attacker's script)
6669 ircd
9706 term
42121 inetd spawned in.telnetd
Logs were wiped, and couldn't find a wiping utility so I'm thinking a
simple rm or unlink was used, so I'm hoping to find more details when
the disk is in hand. File modifications that were made follow:(not
necessarily a complete analysis yet)
clearly Trojaned binaries (probably others)
/bin/ps
/bin/netstat
/bin/ls (this ls binary was hiding several things, directory
structures named
/usr/local/bin/sshd1 (the file was just several hundred bytes larger
than previously)
Binary file/directory additions
/usr/bin/bin/u/ An entire directory structure containing the ircd
server source
/usr/bin/share/mysqld (looks like some type of irc spoofing proxy)
/bin/klogd (almost looks like an ftp proxy)
/bin/term (A bindshell of some sort)
/usr/sbin/init.d was added and is exactly the same file size as term
System configuration files that were modified/added
/etc/hosts.allow made specific allowances for the
as
/etc/passwd two new accounts were added with the same password (des
hashes -NOT MD5)
/etc/shadow The added accounts were lpd 1212:1212, and admin 0:0
/etc/inetd.conf 200+ lines of whitespace added, and then the single
telnet entry
/etc/services was modified for telnet to start on port 42121
/etc/resolv.conf a new nameserver was added...
/etc/psdevtab haven't examined closely yet
/etc/rc.sysinit a line was added to start the
trojan/backdoor
/etc/rc.local after much whitespace was added.... following lines at
the bottom of the rc.local file
killall -9 rpc.statd
killall -9 gdm
killall -9 gpm
killall -9 lpd
term
klogd
"/usr/bin/share/mysqld"
-----
This should assist other ppl who have had similar attacks...
There are 13 root servers in the world, I believe. Their locations are well known. Yes, they are well secured, but still, if terrorsts want to more or less shut down the ENTIRE NET from the point of view of end users, they'd just have to take out the root servers and presto!
.net, .org, .edu)? That makes matters even worse.
Is there any other critical network as vulrenable as the Internet? Telephone, Electricity, Water, etc... they are all much more harder and less vulrenable than the Net in terms of their architecture.
Don't some of the root servers, or at least their datacenters, handle the gTLDs as well (.com,
With the Net no longer a academic resource, but mission critical for business today, I'm surprised that only NOW people are starting to find that this COULD be a single point of failure for the Internet.
George W. Bush
President, United States of America
Untrue, DNS is like www.whitehouse.gov under permanent attack. The article is based on a number of assumptions that are not true of all the root servers.
Steve Bellovin is somewhat inaccurate in his statement about BIND. While it is true that most of the Root servers run code that originated in BIND most of the heavy lifting is done by a few servers that sit on the fattest pipes that run a stripped code base. The code paths of that code base have at this point been as near to completely tested as anything gets.
The real problem is that most of the root servers are still maintained by the ad-hoc volunteer network of the 1980s Internet. As a result many of the 'root servers' are hosted on drinking straws rather than pipes.
There are 13 servers however and all have to go down to take out the Internet. Even then the effect would take some time to be felt. The root servers only manage the top level domains. These tend not to change very often and so the TTL on the root records can be made very long without causing operational difficulty.
A much more serious problem would be if someone brought up a fake root server. DNS does not provide authentication.
Rather than obsess about the code base problem ICANN should be either deploying BIND or telling the IETF the characteristics of the security protocol it really needs.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Read his license and see for yourself.
Linux: Because a PC is a terrible thing to waste.
James Brents
It seems like its think inside the box day (why is it I've said this for the first two times of my life today?)...
:-) Other than his dislike for distributors (does he roll his own?) DJB seems like a cool guy.
"You can distribute your patches for other people to use."
"You may distribute a precompiled package if installing your package produces exactly the same files, in exactly the same locations, that a user would obtain by installing one of my packages listed above"
"You may distribute exact copies of any of the following packages"
It seems DJB is A-OK with the raw source or raw binaries being on the CD. He's also OK with patches and patch distribution.
So here's how to "get around" his license if you are a distributor (which isn't all that bad except for distributors, who generally have better things to deal with than "attitude" -- which it appears DJB has against software distributors, and is why his software is doomed to fail in the market, even if it won't fail in the computer):
- djbdns
[ ] Install virgin djbdns binary
[ ] Install virgin djbdns source
- patches
[ ] Install binary patch for djbdns for correct operation with your platform
[ ] Install source patch for djbdns for correct operation with your platform
Problem solved. He's happy, you're happy, I'm happy. We're all a happy family. Well, maybe DJB isn't happy, but then again maybe he should get back to coding more good software rather than writing software licenses (which it appears he isn't particularly good at... I'm no legal expert and I saw that gaping hole a mile away).
Can't we just all get along?
[IANAL. If you wanted legal advice, you looked at the wrong post.]
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
check here:
http://cr.yp.to/djbdns/axfrdns.html
this supports outgoing transfers. Incoming are a possible security risk (NO authentication happens in most cases, other than IP address checking, IIRC), making this a prudent decision, IETF or no.
BBK
What on earth for? SQL is a general purpose query language designed to maximize flexibility over performance. SQL lets you do all sorts of complex nested subqueries and joins which simply aren't needed for DNS, so why have the overhead? It all comes down to using the right tool for the job. And in this case, a fast non-SQL database (such as Berkeley DB, for example) is far more suited to the job. Too many people equate the term "database" with "SQL", when that's just one of the options. Often it's the right choice, but sometimes it isn't, and this is one of those times.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Yes, there are independantly coded closed-source solutions which perform better and presumably are better all around (Nominum has written a program that they use as the basis for their Global Name Service, which does not contain any code from BIND).
However, these are closed-source implementations, and the folks who operate the various root servers are doing so on a volunteer basis, and are not interested in just handing everything over to some company who operates a "black box" -- regardless of who that company is.
Indeed, it's the root server operators that have really spared us from the worst of the damage that ICANN has tried to inflict upon us. For the stupidest things, the root server operators simply said "Not only NO, but HELL NO!", and ICANN was forced to back down.
Brad Knowles
http://daily.daemonnews.org/ -- if you're not
-
By default, tinydns does not hand out referrals to questions it is asked about zones it does not control. I believe that this violates the spirt of the RFCs, if not the letter.
-
By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt of the RFCs, as well as the letter (if a DNS query via UDP results in truncation, you're supposed to re-do the query using TCP instead).
-
The suggested method for copying contents of DNS zones is rsync, scp, or other remote copy tools. The DNS standard method of zone transfers (query type "axfr") is only supported as an additional, disrecommended method.
-
Without a patch from a third party, tinydns does not listen to more than one IP address. If you have a multi-homed server, you have to apply a patch from someone other than they author, before you can get it to listen on more than one address/interface.
-
Without a patch from a third party, tinydns does not support the standard "NOTIFY" protocol of informing secondary nameservers that the zone has been updated, and that they need to check the SOA serial number and download a new copy (if they don't already have it).
-
Without a third party patch, tinydns does not support standard SRV records (which are intended to ultimately replace MX records, as well as perform similar functions for services other than mail).
-
Like tinydns, dnscache will not bind to more than one IP address without a third party patch.
-
Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.
-
There aren't even any patches that can get djbdns to implement TSIG, Dynamic DNS, or DNSSEC, nor are they ever likely to be created (my understanding is that the author is strongly opposed to them).
-
There are a number of things that djbdns does which I believe to be outright bugs. However, the author of this package simply refuses to accept that his code could be anything less than 100% perfect, and while he claims to have a "bounty" that he will pay for any bug that is found, in reality he is the one that gets to define what he accepts as a "bug", and has repeatedly demonstrated a tendancy to openly refuse to accept some purported bug, but then to quietly fix the code with future releases.
-
When an IQUERY is sent to a djbdns server, it will respond with opcode set to QUERY. (it should simply copy the opcode, not make something up).
-
DNSCACHE (the caching server) does not respond to queries with the RD bit clear in the query. (Instead of simply answering from cache without recursing the dns-tree).
-
One argument frequently used to support the use of djbdns over BIND is performance. Upon further investigation, this claim simply does not hold water.
-
Unfortunately, a lot of the reasons the author gives for running djbdns instead of BIND are related to problems in older versions of BIND which have been fixed or are largely non-issues in later releases of BIND 9.
And this doesn't even begin to get to the more core philosophical issues that Dan gives for running djbdns instead of BIND. I can easily rip him apart in these areas as well, but this takes more space than I think that I should devote here.Indeed, if you want to support TCP under tinydns, you have to configure an optional program called "axfrdns", which was intended to handle zone transfers, but also happens to share the same database as tinydns, and can handle generic TCP queries.
The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed. Contrariwise, if you use the standard zone transfer mechanism, then the zone transfer should fail if the master is munged, and the slaves should keep a good working copy for a while and give you time to notice that the master is munged and needs to be fixed.
While this is not the recommended mode of configuration, some sites don't have the luxury of having separate authoritative-only and caching/recursive-only server(s), and need to mix them both on one machine (or set of machines). With the BIND 9 "view" mechanism, this is relatively easy to do. With djbdns, this is impossible.
Unfortunately, as time goes on and more and more people are doing things like IPv6, VPNs based on IPSec, or people just care about being able to cryptographically prove that their servers are handing out the only correct information and that the clients are able to cryptographically verify this fact (think: electronic banking), these kinds of features are going to become ever more commonplace.
Note that, with the advent of BIND 9, you can create a caching-only server that will validate cryptographically signed records, and all clients can benefit even if they do not themselves implement any of the new DNSSEC features.
So, let's look at some of these bugs:
Benchmarks published by Rick Jones have clearly shown that BIND can scale up to at least 12,000 DNS queries per second, and there is every indication that BIND 9.2 will be able to go considerably higher. The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second, but that is the highest number reported. Other people on the bind-users mailing list have indicated that they have performed their own (as yet unpublished) benchmarks of tinydns, and that it had notable performance problems that BIND did not suffer.
The best published benchmarks from the author for dnscache report a query handling rate of less than one million records over a 4.5 hour period of time, which works out to an average of less than sixty-two queries per second. Even if you look at numbers of queries per CPU second, the best numbers they can provide are 13.7 million queries over a four week period of time with 128 minutes of CPU time used (an average of slightly less than 1784 queries per CPU second).
Compare this with the requirement from RFC 2010 "Operational Criteriafor Root Name Servers" (since obsoleted by RFC 2870 "Root Name Server Operational Requirements") is that the machine and software in question be able to handle at least 2000 queries per second, and be scalable to levels higher than that. Indeed, recent reports have indicated that a.root-servers.net (considered by many to be the "primary" root nameserver) is currently handling around 12,000 DNS queries per second at peak.
Preliminary benchmarks published on the bind-users mailing list have indicated that, on the same hardware, there is little or no performance benefit to using dnscache as opposed to BIND 9.1.2, and when these tests are re-run with BIND 9.2, I'm sure that it will come out even faster.
For example, he makes a big point of tinydns being better than BIND, because while the process is starting up, it still answers queries. While previous versions of BIND would not answer queries during startup, this is no longer a problem with BIND 9.
Dan also makes a great deal of the fact that the djbdns tools run as a user other than root, and in chroot() environments. While the "monolithic setuid root" situation was an issue with older versions of BIND, even more recent releases of BIND 8 could be easily run as a non-priviledged user in a chroot() environment, and this is the preferred method of running BIND 9.
Contrariwise, one of the legitimate big complaints about older versions of BIND is that they implemented zone transfers in a separate program. If the database was large, then the fork()/exec() overhead was large, and the system could seriously thrash itself to death as it copied all those pages (for systems without copy-on-write), only to immediately throw them away again when it fired up the named-xfer program. With BIND 9, this problem is solved by having a separate thread inside the server handling zone transfers, and no fork()/exec() is done. However, tinydns/axfrdns goes back to the fork()/exec() model that was so greatly despised.
Suffice it to say that there is absolutely nothing that djbdns does that I believe can't be done at least as well (or considerably better) with BIND, and there are no security benefits it provides that cannot be provided at least as well (or much better) by a proper installation of a modern version of BIND.
I believe in the "security through diversity" scheme as much as anyone, but I'd take root nameservers running a program written in Bourne shell over djbdns. Hell, I'd rather fall back to using HOSTS.TXT than use djbdns.
Unfortunately, the other alternative of DENTS is also unsuitable for use as a production nameserver.
Show me something that is sufficiently better than BIND (and open source), and I'm sure that everyone will quickly gravitate towards it. Until then, BIND is the best we've got.
Brad Knowles
http://daily.daemonnews.org/ -- if you're not
Use BIND 9! A new security hole is discovered in BIND 4 and BIND 8 every couple of months. The quality of the BIND 8 code is so poor, that a complete rewrite was needed for BIND 9. Consequently, BIND 9 is much less likely than BIND 8 to throw up new security holes.
The story can be found here. The differences between BIND 8 and BIND 9 are highlighted in this quote:
"The basic sleazeware produced in a drunken fury by a bunch of U C Berkeley grad students was still at the core of BIND", according to Paul Vixie, BIND9 architect. This rickety software structure was not judged an adequate basis for the complex changes needed by DDNS and DNSSec, so a decision was made to completely rewrite bind. In 1998, Jerry Scharf, who was the Executive Director of ISC, convinced the remaining UNIX vendors and a few government agencies that the only way to support all of the new DNS protocol enhancements was to totally rewrite BIND. As a result, in August of 1998 DARPA awarded a contract to TIS (NAI labs) to write the software in collaboration with ISC.
By default, tinydns does not hand out referrals to questions it is asked about zones it does not control. I believe that this violates the spirt of the RFCs, if not the letter.
Please indicate where do you think that this breaks the RFCs.
By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt of the RFCs, as well as the letter (if a DNS query via UDP results in truncation, you're supposed to re-do the query using TCP instead).
Truncation only happens when the reply doesn't fit in 512 bytes. As the administrator of a DNS server, you're in control of the data you publish. If you want to do stupid and publish data that doesn't fit in 512 bytes, you have the possibility to do so. It's just FUD to say that djbdns doesn't support TCP; the nice thing is that if you don't need TCP service, you don't even have to install it.The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.
This is entirely untrue, and show that you've never even used djbdns. If you make a mistake in your data, you'll get a nice notification of that fact and nothing will stop working, including slave DNS servers. When you correct your mistake, the new data is instantly used and replicated to your slaves. Unlike BIND, which won't load the zone when it has errors in it. This means that BIND will stop publishing data about that zone.
Without a patch from a third party, tinydns does not listen to more than one IP address.
Or you could just run multiple instances of tinydns. Which costs almost nothing, since multiple tinydns'es can use the same data.cdb file. And even several tinydns processes running consume much less resources than even 1 BIND.
Without a third party patch, tinydns does not support standard SRV records
Entirely untrue. tinydns supports all (even not-yet-defined!) types of records. Unlike BIND, which barfs when an unknown record type is fed to it via a zone transfer.
reality he is the one that gets to define what he accepts as a "bug", and has repeatedly demonstrated a tendancy to openly refuse
When a dispute about the bounty (which is for security holes, not bugs in general) occurs, it will be reported on his website. Since there isn't any dispute mentioned, you didn't even try to report one, did you?
Lots of people are running one or more programs of the djbdns suite, and are really happy with them. If you want to use another program, that's perfectly fine of course. It's not fine when you start talking non-sense about a product that you've never even used.
Lots of people have:
DJB DNS
Custom DNS
MaraDNS
Posadis (though I've no experience with it yet)
The list goes on and on.. hit Freshmeat.net for some possibilties.
Proteus' Child
Doko ni datte; hito wa, tsunagette iru.
http://nms.lcs.mit.edu/papers/dns-imw2001.html
-Patrick
djbdns (and qmail, etc) are NOT under a restrictive license as you like to argue. In fact, they are under no license. DJB simply doesn't believe that software licenses are valid, so he doesn't grant one. His "license" page that you refer to simply reiterates his right of first distribution, as well as waiving some of his right to first distribution under certain circumstances. Read this for more background on why DJB doesn't issue licenses.
The only appearance of the word license on that page is in a quote from a RedHat employee, not DJB. It would seem impossible to me to grant a license without specifically stating that you are granting a license.
The inability to change pathnames is a bunch of hooey. I've seen packages included with a major distribution that could have been modified to use paths that make more sense, but have been packaged with the author's defaults instead.
xjosh
See here. kthx.