[conspire] DNS vulnerability details
Rick Moen
rick at linuxmafia.com
Sun Aug 3 19:18:37 PDT 2008
Quoting Eric De MUND (ead-conspire at ixian.com):
> Ok, I believe I've completed phase 1 of 2 of eliminating my DNS vul-
> nerability, that of fixing my SOHO network. Phase 2 will be to patch
> my debian laptop which travels out into the world. Please educate me
> if I've missed anything in phase 1. In particular, given "GREAT" test
> results in step d, below, why might I still need to install BIND on any
> of the SOHO systems behind my router?
Apologies, but this will be a bit rushed -- very rushed, really, length
notwithstanding. As chance would have it, I have a _Linux Gazette_
article from last Friday: http://linuxgazette.net/153/moen.html
Title: DNS Source Port Randomisation
It includes a sidebar on "Picking a local caching recursive-resolver
nameserver", as follows:
In an ideal world, I'd have tested candidates and be able to give
you simple, foolproof instructions and recommendations. But alas, I
haven't even kicked the tires of most -- which illustrates why progress
in this area has been slow: too many sysadmins making do with BIND9. The
good news is that all you really do with DNS servers in this category is
start them and point /etc/resolv.conf at them.
The following, in no special order, seem worth trying:
* BIND9: The only one yr. humble servant has used extensively.
Maddeningly slow, bloated, overfeatured monolithic binary
(optionally doing all other conceivable types of nameservice,
as well). Cryptic and brittle (but "standard", for better or
worse) configuration and zonefile formats.
* Unbound: By design, excellent in all areas where BIND9 is
lackluster. The only obvious problem is that it's brand-new --
* which, in security-sensitive code is a point of concern.
* PowerDNS Recursor: Dedicated recursor component (newly made
available separately) of the respected do-it-all PowerDNS
package. Probably requires a SQL database for back-end
storage. Fast. PowerDNS as a whole -- but I'm not sure how
much of this applies to the separely packaged recursor -- is
somewhat bloated, has an over-large tree of required libraries
and other dependencies), and has a fair (but not stellar)
reputation for security.
* dnscache: Dan Bernstein's caching recursive-resolver, part of
the djbdns suite, and the first to randomise source ports as a
security precaution. Eccentric style of coding and operation.
(Let me just leave it at that.) Unsurpassed security history.
Said to be a bit of a challenge to set up, and at present you
must immediately patch it to compensate for Dan not having
maintained it since 2001. Has problems resolving some domains
(such as Akamai), and in general is by design a bit
underfeatured, which accounts in part for both its superb
security history and its problem areas.
* MaraDNS: Lightweight, fast, and well-maintained. Like BIND9,
does all conceivable DNS roles, but without the bloat.
Excellent security.
My pessimistic speculation about PowerDNS Recursor turned out to be
incorrect (see below): It does _not_ have a huge dependency chain
nor does it require a SQL database, those being drawbacks of the full
PowerDNS package.
This afternonn, while working on other things, I did test installs on a
few of the above, reporting back to _LG's_ editor-in-chief, Ben Okopnik.
Here are notes:
Date: Sun, 3 Aug 2008 16:39:19 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Ben Okopnik <ben at linuxgazette.net>
Subject: BIND9 default installation (was: pdnsd)
Quoting Ben Okopnik (ben at linuxmafia.com):
> Rick, I've been researching and experimenting, and that statement of "no
> muss, no fuss, no greasy aftertaste" for DNS RR server installation may
> have been a bit too optimistic. BIND9, MaraDNS, and PowerDNS all fail
> the "turnkey" test;
I'm now a little confused, and am wondering if I've missed something.
To be sure, I'm so used to dealing with bizarre nameserver issues that
I probably don't even notice having worked past a problem that would
stump a nameserver novice. Anyhow, here's a from-scratch package
install of BIND9 on Ubuntu Gutsy Gibbon:
# apt-get install bind9
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libdns35 libisc32 libisccc30 libisccfg30 libssl-dev libssl0.9.8
Suggested packages:
bind9-doc resolvconf
The following NEW packages will be installed:
libdns35
The following packages will be upgraded:
bind9 libisc32 libisccc30 libisccfg30 libssl-dev libssl0.9.8
6 upgraded, 1 newly installed, 0 to remove and 255 not upgraded.
Need to get 5718kB of archives.
After unpacking 1237kB of additional disk space will be used.
Do you want to continue [Y/n]?
[snip package fetches:]
Checking for services that may need to be restarted...done.
Checking init scripts...
Restarting services possibly affected by the upgrade:
* Restarting OpenBSD Secure Shell server sshd
* [ OK ]
Services restarted successfully.
Setting up libssl-dev (0.9.8g-4ubuntu3.3) ...
Setting up libisc32 (1:9.4.2-10ubuntu0.1) ...
Setting up libdns35 (1:9.4.2-10ubuntu0.1) ...
Setting up libisccc30 (1:9.4.2-10ubuntu0.1) ...
Setting up libisccfg30 (1:9.4.2-10ubuntu0.1) ...
Setting up bind9 (1:9.4.2-10ubuntu0.1) ...
Installing new version of config file /etc/bind/db.local ...
Installing new version of config file /etc/bind/db.root ...
Installing new version of config file /etc/bind/named.conf ...
Installing new version of config file /etc/init.d/bind9 ...
Reloading AppArmor profiles : done.
* Starting domain name service... bind
* [ OK ]
Processing triggers for libc6 ...
ldconfig deferred processing now taking place
# dig linuxmafia.com @localhost
; <<>> DiG 9.4.1-P1.1 <<>> linuxmafia.com @localhost
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52490
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0
;; QUESTION SECTION:
;linuxmafia.com. IN A
;; ANSWER SECTION:
linuxmafia.com. 86400 IN A 198.144.195.186
;; AUTHORITY SECTION:
linuxmafia.com. 86400 IN NS ns1.thecoop.NET.
linuxmafia.com. 86400 IN NS ns2.linuxmafia.com.
linuxmafia.com. 86400 IN NS ns.tx.primate.NET.
linuxmafia.com. 86400 IN NS ns.primate.NET.
linuxmafia.com. 86400 IN NS ns1.linuxmafia.com.
;; Query time: 2164 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Aug 3 16:21:57 2008
;; MSG SIZE rcvd: 158
In other words, the one command to install package BIND9 _did_ suffice
to set up a fully functional caching recursive-resolver nameserver,
which I verified by using "dig" to query nameservice specifically at
localhost.
Now, I have to tell you, I am _very_ disapointed in Ubuntu's default
configuration: They put _no_ limitations in
/etc/bind/named.conf.options on who is allowed to send queries or even
specifically recursive queries -- and there is nothing to alert users to
the security risk of omitting those controls. But, beyond doubt, this
does work.
You would, of course, need to change /etc/resolv.conf to force the local
DNS resolver library to _consult_ the local nameserver (as opposed to
making "dig" do so via a command-line directive). And, for DHCP users,
making that resolv.conf change be permanent requires even more pesky
work, because I figure you'd end up having to enforce your "leave the
damned nameserver line alone!" wishes somehow in the DHCP client
configuration.
I'll eventually get around to trying out other relevant offerings.
Above was just a quick-test "Hey, are you _sure_ BIND9 doesn't do a good
turnkey setup?" effort.
So, what am I missing?
Date: Sun, 3 Aug 2008 18:31:21 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Ben Okopnik <ben at linuxmafia.com>
Subject: MaraDNS default installation (was: pdnsd)
Quoting Ben Okopnik (ben at linuxmafia.com):
> Rick, I've been researching and experimenting, and that statement of "no
> muss, no fuss, no greasy aftertaste" for DNS RR server installation may
> have been a bit too optimistic. BIND9, MaraDNS, and PowerDNS all fail
> the "turnkey" test;
Again, this is a from-scratch package install on Ubuntu Gutsy Gibbon:
~$ sudo apt-get install maradns
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
maradns
0 upgraded, 1 newly installed, 0 to remove and 254 not upgraded.
Need to get 479kB of archives.
After unpacking 1139kB of additional disk space will be used.
[snip package fetch]
Fetched 479kB in 0s (9016kB/s)
Selecting previously deselected package maradns.
(Reading database ... 135280 files and directories currently installed.)
Unpacking maradns (from .../maradns_1.2.12.08-1_i386.deb) ...
Setting up maradns (1.2.12.08-1) ...
creating MaraDNS system user...
adduser: Warning: that home directory does not belong to the user you
are currently creating.
Starting maradns: maradns.
Starting zoneserver: No zone ACL's configured for /etc/maradns/mararc --
not starting zoneserver for it.
zoneserver.
I believe you told me by telephone that you gave up upon seeing that
message about zoneserver ACLs, but ironically _that_ was OK. That
merely meant that MaraDNS wasn't going to be able to do authoritative
service -- which we don't _want_ it to. However, there were other
problems:
First, find out the homedir MaraDNS user, since we'll need it later:
~$ grep maradns /etc/passwd
maradns:x:113:123::/etc/maradns:/bin/false
And what's the ownership of the conffile directory?
$ ls -l /etc/maradns/
total 12
-rw-r--r-- 1 root root 10311 2007-09-19 03:11 mararc
Last, is the recursive-resolver daemon _working_?
$ dig linuxmafia.com @localhost +short
;; connection timed out; no servers could be reached
$
So, oops, the recursive service simply doesn't work, out of the box.
We then have to find out why, and fix it:
/var/log/daemon.log includes:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: POSSIBILITY OF SUCH DAMAGE.
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: To not display this message, add the follwing to your mararc file:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: hide_disclaimer = "YES"
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc:
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Root directory changed
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Binding to address 127.0.0.3
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Socket opened on UDP port 53
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Root privileges dropped
Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: All RRs have been loaded
~$ dig linuxmafia.com @127.0.0.3 +short
;; connection timed out; no servers could be reached
(My recollection was that all IP addresses in the loopback network were
interchangeable, but I just wanted to make sure.)
/usr/share/doc/maradns/README.Debian starts out with:
maradns for Debian
------------------
This version of MaraDNS works as authoritative or/and recursive server.
Below are guides to two typical setups:
Recursive:
----------
Usually good enough to:
sudo cp /usr/share/doc/maradns/en/examples/example_recursive_mararc.txt /etc/maradns/mararc
BUT please use the uid and gid of the default mararc. Look up the
maradns uid and gid with `id`.
You might want to throw in:
hide_disclaimer = "YES"
And use icann root servers instead.
[...]
~$ id maradns
uid=113(maradns) gid=123(maradns) groups=123(maradns)
(Actually, we already knew that from when I looked up that user's
homedir.)
After following the above ("sudo cp") advice, including making sure the
following lines were in /etc/maradns/mararc:
# The numeric UID MaraDNS will run as
maradns_uid = 123
# Recursive ACL: Who is allowd to perform recursive queries.
recursive_acl = "127.0.0.0/8"
hide_disclaimer = "YES"
I did:
$ sudo /etc/init.d/maradns start
Starting maradns: maradns.
$ dig linuxmafia.com @localhost +short
198.144.195.186
Yay, works as intended.
(It was not necessary to give the maradns user or group ownership over
/etc/maradns/ .)
So, indeed it wasn't _quite_ turnkey, and could use a bit of improvement
from the package maintainer to optimise for the most common case. The
package maintainer might have two objections, if I were to so suggest:
1. "The target audience can take care of such things, because the target
audience are sysadmins." Which is where we get the chicken-and-egg
problem of regular users never running their own caching nameservers
because it's too difficult, and package maintainers never bothering to
remove the difficulty because regular users don't use the software.
2. "The MaraDNS package includes two separate daemon processes, the
recursiver-resolver daemon and the zoneserver, with separate
configuration needs. Some people will need one function but not the
other; some will need both. So, there's no such thing as an optimised
configuration for the most common case."
There would be some justice to that -- but I frankly don't think it'd be
difficult to ask the user a few questions, construct a mararc file to
suit, and only _then_ start the daemon(s).
Not surprisingly, there is not yet an Ubuntu package for "Unbound" -- at
least, not in Gutsy Gibbon. (In fact, it appears to be present only in
the Intrepid Ibis beta.)
That leaves only PowerDNS Recursor and dnscache (from djbdns). Gutsy
Gibbon has package "djbdns-installer - Source only package for building
djbdns" (reflecting the pre-"public domain" status of the djbdns 1.06
source code at the time the package was put together).
To my surprise and delight, there's a pdns-recursor package:
Description: PowerDNS recursor
PowerDNS is a versatile nameserver which supports a large number
of different backends ranging from simple zonefiles to relational
databases and load balancing/failover algorithms.
PowerDNS tries to emphasize speed and security.
.
This is the recursive nameserver that goes out to the internet and
resolve queries about other domains.
I'll try that one, and then probably call it quits -- until the Ubuntu
folks catch up with the licence change on djbdns, and re-packages it to
get around a number of problems that will suddenly be fixable (if anyone
still cares): I hear that among the problems with default djbdns is
that it needs an immediate source-level security patch, plus you need to
fetch the current named.root file from ftp.internic.net , as the one
provided is out of date.
And, even after that, it's my understanding that djbdns has problems
resolving some domains (such as Akamai). There may or may not be
suitable patches, and I can either gamely try to chase down that sort of
stuff or just say to myself "Screw it. Nobody should have to go to that
sort of trouble, and desktop users sure ain't going to."
Date: Sun, 3 Aug 2008 18:38:36 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Ben Okopnik <ben at linuxgazette.net>
Subject: PowerDNS Recursor default install (was: pdnsd)
Quoting Ben Okopnik (ben at linuxmafia.com):
> Rick, I've been researching and experimenting, and that statement of "no
> muss, no fuss, no greasy aftertaste" for DNS RR server installation may
> have been a bit too optimistic. BIND9, MaraDNS, and PowerDNS all fail
> the "turnkey" test;
Did you install the _full_ PowerDNS package? (You don't need all that,
just the recursor.) If so, that's your problem. Here:
$ sudo apt-get install pdns-recursor
Reading package lists... Done
Building dependency tree
Reading state information... Done
Recommended packages:
pdns-doc
The following NEW packages will be installed:
pdns-recursor
0 upgraded, 1 newly installed, 0 to remove and 254 not upgraded.
Need to get 403kB of archives.
After unpacking 1061kB of additional disk space will be used.
[snip fetching the package]
Fetched 403kB in 0s (655kB/s)
Selecting previously deselected package pdns-recursor.
(Reading database ... 135360 files and directories currently installed.)
Unpacking pdns-recursor (from .../pdns-recursor_3.1.4-3_i386.deb) ...
Setting up pdns-recursor (3.1.4-3) ...
Creating user and group pdns...done
* Starting PowerDNS recursor pdns-recursor
* Aug 03 18:30:35 PowerDNS recursor 3.1.4 (C) 2001-2006 PowerDNS.COM BV
* (May 1 2007, 06:32:16, gcc 4.1.3 20070429 (prerelease) (Ubuntu
* 4.1.2-5ubuntu1)) starting up
Aug 03 18:30:35 PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free
software, and you are welcome to redistribute it according to the terms
of the GPL version 2.
Aug 03 18:30:35 Operating in 32 bits mode
Aug 03 18:30:35 Only allowing queries from: 127.0.0.0/8, 10.0.0.0/8,
192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10
Aug 03 18:30:35 Inserting rfc 1918 private space zones
Aug 03 18:30:35 Listening for UDP queries on 127.0.0.1:53
Aug 03 18:30:35 Listening for TCP queries on 127.0.0.1:53
Aug 03 18:30:35 Done priming cache with root hints
Aug 03 18:30:35 Calling daemonize, going to background [ OK ]
$ dig linuxmafia.com @localhost +short
198.144.195.186
_Man_, that was short and sweet. Pretty small process, too:
$ ps auxw | grep pdns | grep -v grep
pdns 12273 0.0 0.0 4064 1516 ? Ss 18:30 0:00 /usr/sbin/pdns_recursor --daemon
$
Once again, I frown mildly on the bit about defaulting to permitting
queries from loopback and _all_ RFC1918 (NAT) addresses, however, that's
easily fixable in /etc/powerdns/recursor.conf .
Ben commented about the overwriting-nameserver-lines-in- /etc/resolv.conf
problem, as follows:
That's supposed to be done via 'resolvconf'. In fact, I suspect that's
what the comment+line in /etc/default/bind9 means:
``
# If you have resolvconf installed, you can enable the following to have
# resolvconf update an recursor line in the pdns config, as determined by
# resolvconf.
RESOLVCONF_UPDATE_FORWARDERS=no
''
*However*... the fact that it's simple to do is meaningless - the users
simply wouldn't know enough to do it. That's a problem. It is, in fact,
_the_ problem, not only with this DNS hack but with the majority of
other security-related problems. I don't know what we can do about that,
except possibly pub a follow-up article on how to actually do this step
by step.
Hope that helps. Looks to me like PowerDNS Recursor is pretty good
for SOHO use.
Eric wrote:
> Here at home, in phase 1:
>
> a. I upgraded the firmware of my Linksys WRT54G v2.2 router to
> "DD-WRT v24-sp1 (07/27/08) std". Though dd-wrt.com noted in [1],
> "We'd like to make clear that the DD-WRT default configuration in
> v23 / v24 is not vulnerable, so there was and is no risk for dd-wrt
> users," their list of overall enhancements for v24 sp1 included, on
> the very first line:
> o DNS security fix for dnsmasq
Notice that dnsmasq does not itself resolve recursive queries: It hands
off such outbound queries to elsewhere. pdnsd does likewise.
I see (at a very quick glance) that you appear to be aiming to hand off
to OpenDNS. I have mixed feelings about them. On the one hand, they're
helping their users' security, and seem pretty benign. On the other
hand, (1) breaking NXDOMAIN results is never good, and (2) I just get
really queasy about some firm being a choke point both controlling the
return values of my DNS queries and being able to easily log everything
I ask about.
> So, to inquire again, why am I not done with phase 1? Why might I need
> to install BIND on a system behind my router?
Later, I'm going to go back and read your post more carefully. For now,
I quick-scanned it and imported the text of my messages to Ben, for a
first-level response.
Again, simply as a really quick first-level comment, you might wish to
install a real caching, recursive-resolver nameserver daemon if you want
to ensure, from your own resources, that the daemon conducting that
service on your behalf is sound.
History has shown that sharing a recursive-resolver nameserver with a
large number of strangers is part of what makes cache-poisoning likely,
and the easy way to fix _that_ part of the problem is to run your own.
As noted above, defaulting to BIND9 for any and all nameservice problems
is a bad habit, because it's not very good software, and because the
trait of thinking only in terms of BIND has created a number of
problems. I'm trying to cure myself of that habit.
More information about the conspire
mailing list