Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Comments Requested: Chrooting Bind9 on FreeBSD

1 view
Skip to first unread message

Philip J. Koenig

unread,
Apr 27, 2002, 6:48:42 AM4/27/02
to
A few months back when I first needed to put together a DNS server
using Bind9, I was disappointed to discover that not only FreeBSD
still shipped Bind8, but there was no recent Bind9 port at the time
either. (this has since changed)

I also wanted to run this server chrooted, and there were no "howto"
documents on this. After spending quite a while agonizing through
this process, and also running into some early Bind9 bugs, I decided
to make the best of the time spent by documenting the process so at
least other people could bypass some of the tribulations.

I initially wanted to put this document out there a few months ago,
but I lost track of where I saved it. :-/ Since someone recently
asked on the group about this exact subject, and because there had
been some misinformation given out, I figured I'd look for it again,
and lo-and-behold, finally dug it up.

I'd like to eventually put this on a webpage, or even contribute it
to some kind of documentation project if that seems appropriate. At
this time I'd like to solicit comments on the document so I can
correct any obvious errors before claiming any sort of authoritative
status for it.

Thanks for your input.

Phil

=================================================

USING BIND9 SECURELY ON FREEBSD

FreeBSD 4.x includes Bind as part of the base system, but
currently it is version 8. There is a Bind9 port, but at
various times it falls behind the current release and by
default it is not setup to run in the most secure manner.

This document details how to install a current version of
Bind9 on FreeBSD 4.x, and how to make it work in a "chroot
jail"*, which is a standard practice to help secure any
public internet server running under Unix or its workalikes.

*(FreeBSD also incorporates a special feature simply called
"Jail" which goes even further than chroot to isolate a
running process for security purposes. For more information,
type "man jail" for the jail manpage)


CHROOT OVERVIEW

What chroot essentially does is to create a "fake root"
directory - from the perspective of the daemon, the whole
file system is rooted at this "chroot" directory. Therefore
the only files/directories the daemon can see, are those
located within this directory. (In some ways this is not
unlike the view of the filesystem given to ftp users when
the default "ftp root" of an ftp server is set to something
other than the "real" root directory.)


FREEBSD DETAILS

On FreeBSD, the default location for Bind's configuration
files is /etc/namedb. Sometimes we also use a subdirectory
/etc/namedb/s, this is used to create a "sandbox", which
limits some of the access the named daemon has but not
nearly as securely as using chroot. Bind9 now has a special
feature which makes it a little easier to chroot, among
other things eliminating the need to place shared libraries
and other executables in the "chroot jail".

Since Bind already exists in the base FreeBSD system, for
thoroughness we should consider renaming the existing files
in order to minimize confusion and mixed versions. Here is
a list of files to consider renaming or removing:

/usr/bin/dig
/usr/bin/dnsquery
/usr/bin/host
/usr/libexec/dnskeygen
/usr/libexec/named-xfer
/usr/sbin/named
/usr/sbin/ndc
/usr/sbin/nslookup
/usr/sbin/nsupdate

For those who regularly rebuild their system from source,
once you've installed an independent version of Bind it's
best to configure your system to no longer build the version
in the base system. This is done by adding the following
entry to /etc/make.conf (if this file doesn't exist, just
create it and add the following line - like rc.conf it
only contains items which override default settings):

NO_BIND= true

We will move our configuration and other necessary files
to /var/chroot/named, which will allow us to create logfiles
within the chroot jail without filling up ie the / filesystem.

Create the necessary directories and permissions:

mkdir /var/chroot
mkdir /var/chroot/named
chown bind.bind /var/chroot/named
chmod 750 /var/chroot/named
cd /var/chroot/named
mkdir etc
mkdir etc/namedb
mkdir var
mkdir dev

Create the special files and set permissions:

cp -p /etc/localtime /var/chroot/named/etc
cp -p /etc/syslog.conf /var/chroot/named/etc
cd /var/chroot/named/dev
mknod zero c 2 12
chmod 666 zero
mknod random c 2 4
chmod 644 random
mknod null c 2 2
chmod 666 null

Create a chrooted syslog socket by adding or editing syslog
parameters in /etc/rc.conf thusly:

syslogd_flags="-s -l /var/chroot/named/dev/log"


Build the distribution:

- Extract the distribution into a suitable directory (I use
/usr/local/src)
- run ./configure and customize the destination paths if
necessary.

./configure --sysconfdir=/etc/namedb


Bear in mind that the "sysconfdir" is from the perspective of
the chrooted daemon - thus make sure it is *relative* to the
chrooted directory. Actually if you create a directory structure
in the chrooted directory which is identical to the normal one
as seen from /, you can leave all the path declarations at their
defaults. I just chose to emulate the default named.conf location
in FreeBSD.

In my case the build process did not put any default files in
/var/chroot/named/etc/namedb, so I copied the ones from the Bind8
installation in /etc/namedb: make-localhost, PROTO.localhost.rev,
named.root. (make-localhost is used to create a localhost reverse
zone)

Setup rndc:

rndc-confgen -a -t /var/chroot/named -u bind

The above should create a rndc-key file under /etc and the
chrooted configuration directory.

Create rndc configuration strings:

rndc-confgen >rndc.out

Inside the file just created above are 2 clearly marked sections:
one to place inside your named.conf file, and the other to form
a new configuration file /etc/rndc.conf. If these files don't
exist when Bind is started it will complain and exit.


BIND9 CONFIGURATION DETAILS

Most of Bind9 is similiar syntax-wise to Bind8, with a few
notable exceptions.

If you are customizing the logging parameters, bear in mind
that Bind9 does not parse customized logging parameters
immediately on startup. This means that regardless your
customizations, startup messages will always go to the Bind
default location. (syslog)

Also the logging categories have changed, if you've customized
the defaults don't forget to look at this. Check in section
6.2 of the Bind9 Administrators Reference Manual for complete
details. Quick summary as of v9.2.0:

Removed
cname, db, eventlib, insists, load, maintenance,
ncache, os, packet, panic, parser, response-checks,
statistics
New
client, database, dispatch, dnssec, general, network,
resolver, unmatched

Remember that when you're running chrooted, logfiles need
to be located somewhere under the chroot directory, and paths
listed in named.conf are all relative to the chroot directory,
not to the "real" root. Make sure the directories that Bind
needs to write to (to backup zone files for secondary zones,
and update the named.pid file) are writable to the user the
daemon is running under.


LAUNCHING THE DAEMON

I prefer to stick with existing scripts so I can continue to use
rc.conf to enable/disable Bind or modify launch parameters. To
adapt it to our needs, make sure the following appears in rc.conf:

named_enable="YES"
named_program="/usr/local/sbin/named"
named_flags="-u bind -t /var/chroot/named"

(Bind9 has changed the meaning of the "-g" param, so make sure
to remove it if it was there for Bind8. "-t" activates Bind9's
special chroot feature.)

Acknowledgements:

Information on the necessary steps for this project was
acquired from both ISC Bind documentation and certain
posters on the comp.protocols.dns.bind newsgroup. In
particular I want to acknowledge Will Yardley, Mark
Andrews, Joseph Begumisa, "Exile" and Ralf Hildebrandt
for his excellent piece on chrooting Bind on HP-UX 9/10
at http://www.stahl.bau.tu-bs.de/~hildeb/bind/.


Bind9_FreeBSD_chroot.txt v0.9 2002-04-27
Phil Koenig <pjk...@ekahuna.com>


=================================================

--
Philip J. Koenig pjk...@ekahuna.com
Electric Kahuna Systems -- Computers & Communications for the New Millenium


To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message

Zach Thompson

unread,
Apr 27, 2002, 7:07:38 PM4/27/02
to
* Philip J. Koenig <pjk...@ekahuna.com> [2002-04-27 04:48]:

> I also wanted to run this server chrooted, and there were no "howto"
> documents on this. After spending quite a while agonizing through
> this process, and also running into some early Bind9 bugs, I decided
> to make the best of the time spent by documenting the process so at
> least other people could bypass some of the tribulations.
>
> I initially wanted to put this document out there a few months ago,
> but I lost track of where I saved it. :-/ Since someone recently
> asked on the group about this exact subject, and because there had
> been some misinformation given out, I figured I'd look for it again,
> and lo-and-behold, finally dug it up.
>
> I'd like to eventually put this on a webpage, or even contribute it
> to some kind of documentation project if that seems appropriate. At
> this time I'd like to solicit comments on the document so I can
> correct any obvious errors before claiming any sort of authoritative
> status for it.
>

Phil,

Your post was rather fortuitous for me as I was just considering
installing bind9 this weekend ;-) Anyhow, I decided to give your doc a
spin and everything seems to be working fine.

I actually installed it twice. First, I specified sysconfdir as you did
just to find out if it worked. Then I uninstalled and reinstalled
without specifying it. I figured that if the new sysconfdir was
/usr/local/etc why not just switch to it now.

Also, though you didn't specify it, I installed from ports. I think this
would be a good change to your doc as it makes removing it simpler in
the event that something goes wrong. Also, you get the other
CONFIGURE_ARGS checks thrown in.

What about removing the files /usr/sbin/named.restart and
/usr/sbin/named.reload?

Thanks for the doc! It's definitely something I wouldn't mind being able
to look up on bsdsearch, bsdvault, etc.

Cheers,
Zach Thompson

0 new messages