From 3436c60ec5098cfd48f7cc196f1d6012e26fa5cd Mon Sep 17 00:00:00 2001 From: gferg <> Date: Wed, 4 Jul 2001 17:47:16 +0000 Subject: [PATCH] updated --- LDP/howto/linuxdoc/Chroot-BIND-HOWTO.sgml | 358 ++++++++++------------ 1 file changed, 170 insertions(+), 188 deletions(-) diff --git a/LDP/howto/linuxdoc/Chroot-BIND-HOWTO.sgml b/LDP/howto/linuxdoc/Chroot-BIND-HOWTO.sgml index a8e67c28..c94d500c 100644 --- a/LDP/howto/linuxdoc/Chroot-BIND-HOWTO.sgml +++ b/LDP/howto/linuxdoc/Chroot-BIND-HOWTO.sgml @@ -6,11 +6,13 @@ Chroot-BIND HOWTO <author>Scott Wunsch, <tt>scott at wunsch.org</> -<date>v1.3, 24 February 2001 +<date>v1.4, 1 July 2001 <abstract> -This document describes installing the BIND 8 nameserver to run in a chroot +This document describes installing the BIND 9 nameserver to run in a chroot jail and as a non-root user, to provide added security and minimise the -potential effects of a security compromise. +potential effects of a security compromise. Note that this document has +been updated for BIND 9; if you still run BIND 8, you want the Chroot-BIND8 +HOWTO instead. </abstract> <!-- Table of contents --> @@ -21,19 +23,19 @@ potential effects of a security compromise. <sect>Introduction <p> -This is the Chroot-BIND HOWTO; see <ref id="where" Name="Where?"> for the master -site, which contains the latest copy. It is assumed that you already know how -to configure and use BIND (the Berkeley Internet Name Domain). If not, I would -recommend that you read the DNS HOWTO first. It is also assumed that you have -a basic familiarity with compiling and installing software on your UNIX-like -system. +This is the Chroot-BIND HOWTO; see <ref id="where" Name="Where?"> for the +master site, which contains the latest copy. It is assumed that you already +know how to configure and use BIND (the Berkeley Internet Name Domain). If +not, I would recommend that you read the DNS HOWTO first. It is also assumed +that you have a basic familiarity with compiling and installing software on +your UNIX-like system. <sect1>What? <p> This document describes some extra security precautions that you can take when you install BIND. It explains how to configure BIND so that it resides in a -``chroot jail'', meaning that it cannot see or access files outside its own +``chroot jail,'' meaning that it cannot see or access files outside its own little directory tree. We shall also configure it to run as a non-root user. The idea behind chroot is fairly simple. When you run BIND (or any other @@ -42,7 +44,14 @@ filesystem outside the jail. For example, in this document, we'll set BIND up to run chrooted to the directory <tt>/chroot/named</>. Well, to BIND, the contents of this directory will appear to be <tt>/</>, the root directory. Nothing outside this directory will be accessible to it. You've probably -encounted a chroot jail before, if you've ever ftped into a public system. +encounted a chroot jail before, if you've ever used <tt>ftp</> to log into a +public system. + +Because the chroot process is much simpler with BIND 9, I have started to expand +this document slightly, to include more general tips about securing a BIND +installation. Nevertheless, this document is not (and is not intended to be) a +complete reference for securing BIND. If you do only what is outlined in this +document, you're not finished securing your nameserver! <sect1>Why? @@ -52,7 +61,8 @@ any malicious individual could gain by exploiting vulnerabilities in BIND. It is for the same reason that we run BIND as a non-root user. This should be considered as a supplement to the normal security precautions -(running the latest version, using access control, etc.), not a replacement for +(running the latest version, using access control, etc.), certainly not as a +replacement for them. If you're interested in DNS security, you might also be interested in a few @@ -71,18 +81,21 @@ The latest version of this document is always available from the web site of the Linux/Open Source Users of Regina, Sask., at <url url="http://www.losurs.org/docs/howto/Chroot-BIND.html">. +There is now a Japanese translation of this document, maintained by Nakano +Takeo <tt>nakano at apm.seikei.ac.jp</>. This is available at <url +url="http://www.linux.or.jp/JF/JFdocs/Chroot-BIND-HOWTO.html">. + BIND is available from <url url="http://www.isc.org/" name="the Internet Software Consortium"> at <url url="http://www.isc.org/bind.html">. As of this -writing, the current version of BIND8 is 8.2.3. BIND 9.x has now been -released, but I haven't had time to look at it in depth yet, so I don't know -how much of this document will be applicable. Some administrators are now -putting BIND9 into production use, but it still requires a taste for living on -the bleeding edge (and upgrading every couple weeks), so you may be better off -staying with BIND8 for now. +writing, the current version of BIND 9 is 9.1.2. BIND 9 has been out for some +time now, and many people are using it in production. Nevertheless, if you +are the conservative sort, you may prefer to remain with BIND 8. If this is +the case, please see my Chroot-BIND8 HOWTO (available from the same loation) +for details on chrooting it. Be warned that BIND 8 is much messier to chroot +though. -Keep in mind that there are <bf>known</> security holes in all -versions of BIND8 less than <bf>8.2.3</>, so make very sure that you're -running the latest version! +Keep in mind that there are <bf>known</> security holes in many earlier +versions of BIND, so make very sure that you're running the latest version! <sect1>How? @@ -103,7 +116,7 @@ this. <sect1>Disclaimer <p> -These steps worked for me, on my system. Your mileage may vary. This is but +These steps worked for me, on my system; your mileage may vary. This is but one way to approach this; there are other ways to set the same thing up (although the general approach will be the same). It just happens that this was the first way that I tried that worked, so I wrote it down. @@ -113,6 +126,10 @@ of the instructions in this document should be easily applicable to other flavours of UNIX as well, and I shall try to point out differences of which I am aware. +If you run Linux, you need to make sure that you're running a 2.4 kernel before +attempting this. The <tt>-u</> switch (to run as a non-root user) requires +this newer kernel. + <sect>Preparing the Jail <sect1>Creating a User @@ -149,11 +166,10 @@ structure: <tscreen><verb> /chroot +-- named - +-- bin +-- dev +-- etc | +-- namedb - +-- lib + | +-- slave +-- var +-- run </verb></tscreen> @@ -172,16 +188,20 @@ and the zone files can go in <tt>/chroot/named/etc/namedb</>. For example: # cp -a /var/named/* /chroot/named/etc/namedb/ </verb></tscreen> -BIND will likely need to write to the <tt>namedb</> directory, and probably some -of the files in it. For example, if your DNS serves as a slave for a zone, it -will have to update that zone file. Also, BIND can dump statistical -information, and does so in this directory. For that reason, you should -probably make the <tt>named</> user the owner of this directory and its contents: +BIND would normally need to write to the <tt>namedb</> directory, but in the +interests of tightening security, we will not allow it to do this. If your +nameserver serves as a slave for any zones, it will need to update these zone +files, which means we'll have to store them in a separate directory, to which +BIND does have write access. <tscreen><verb> -# chown -R named:named /chroot/named/etc/namedb +# chown -R named:named /chroot/named/etc/namedb/slave </verb></tscreen> + +Keep in mind that'll you have to move any slave zones you have into this +directory, and update your <tt>named.conf</> accordingly. + BIND will also need to write to the <tt>/var/run</> directory, to put its -pidfile and ndc socket there, so let's allow it to do so: +pidfile and statistical information there, so let's allow it to do so: <tscreen><verb> # chown named:named /chroot/named/var/run </verb></tscreen> @@ -190,50 +210,27 @@ pidfile and ndc socket there, so let's allow it to do so: <p> Once BIND is running in the chroot jail, it will not be able to access files -outside the jail <bf>at all</>. However, it needs to access a few key files, such -as the system's C library. Exactly what libraries are required will depend on -your flavour of UNIX. For most modern Linux systems, the following commands -will be sufficient to put the necessary libraries in place: -<tscreen><verb> -# cd /chroot/named/lib -# cp -p /lib/libc-2.*.so . -# ln -s libc-2.*.so libc.so.6 -# cp -p /lib/ld-2.*.so . -# ln -s ld-2.*.so ld-linux.so.2 -</verb></tscreen> -As an alternative, you could simply build statically-linked versions of the BIND -binaries to put in your chroot jail. You should also copy <tt>ldconfig</> into -the jail, and run it to create an <tt>etc/ld.so.cache</> for the jail environment. -The following commands could take care of this: -<tscreen><verb> -# cp /sbin/ldconfig /chroot/named/bin/ -# chroot /chroot/named /bin/ldconfig -v -</verb></tscreen> +outside the jail <bf>at all</>. However, it needs to access a few key files, +although not nearly as many as BIND 8 did. -BIND needs one more system file in its jail: good ol' <tt>/dev/null</>. Again, -the exact command necessary to create this device node may vary from system to -system; check your <tt>/dev/MAKEDEV</> script to be sure. Some systems may also -require <tt>/dev/zero</>. For most Linux systems, we can use the following -command: +One file that BIND will need inside its jail is good ol' <tt>/dev/null</>. +Note that the exact command necessary to create this device node may vary from +system to system; check your <tt>/dev/MAKEDEV</> script to be sure. Some +systems may also require <tt>/dev/zero</>, which can created similarly. For +most Linux systems, we can use the following command: <tscreen><verb> # mknod /chroot/named/dev/null c 1 3 </verb></tscreen> -Finally, you need a couple extra files in the <tt>/etc</> directory inside the -jail. In particular, you must copy <tt>/etc/localtime</> (this sometimes known -as <tt>/usr/lib/zoneinfo/localtime</> on some systems) in there so that BIND -logs things with the right time on them, and you must make a simple <tt>group</> -file with the <tt>named</> group in it. The following two commands will take -care of this: +You also need another file in the <tt>/etc</> directory inside the jail. You +must copy <tt>/etc/localtime</> (this is sometimes known as +<tt>/usr/lib/zoneinfo/localtime</> on some systems) in there so that BIND logs +things with the right time on them. The following command will take care +of this: <tscreen><verb> # cp /etc/localtime /chroot/named/etc/ - -# echo 'named:x:200:' > /chroot/named/etc/group </verb></tscreen> -Keep in mind that the GID, 200 in this example, must match the one you defined -in the real <tt>/etc/group</> above. - <sect1>Logging<label id="logging"> <p> @@ -308,115 +305,99 @@ Alteratively, you can simply configure BIND to log to files instead of going through syslog. See the BIND documentation for more details if you choose to go this route. -<sect>Compiling BIND<label id="compiling"> +<sect1>Tightening Permissions<label id="perm"> <p> -You should be able to find the BIND source by visiting <url -url="http://www.isc.org/bind.html">. You need the <tt>bind-src.tar.gz</> -package. Be sure to get the latest version! +First of all, feel free to restrict access to the whole <tt>/chroot</> +directory to the <tt>root</> user. Of course, not everybody may want to do +this, especially if you have other software installed in that tree that +doesn't appreciate it. -<sect1>Modifying Paths +<tscreen><verb> +# chown root /chroot +# chmod 700 /chroot +</verb></tscreen> + +You can also safely restrict access to <tt>/chroot/named</> to the <tt>named</> +user. + +<tscreen><verb> +# chown named:named /chroot/named +# chmod 700 /chroot/named +</verb></tscreen> + +For even more tightening, on Linux systems we can make a few of the files and +directories immutable, using the <tt>chattr</> tool on ext2 filesystems. + +<tscreen><verb> +# cd /chroot/named +# chattr +i etc etc/localtime var +</verb></tscreen> + +It would be nice to do this for the <tt>dev</> directory too, but unfortunately +that would prevent <tt>syslogd</> from creating its <tt>dev/log</> socket. +You may also choose to set the immutable bit on other files in the jail as +well, such as your primary zone files, if they aren't expected to change. + +<sect>Compiling and Installing Your Shiny New BIND<label id="compiling"> <p> -Things can get a bit confusing at this point, because different parts of the -BIND package will be referring to the same directories by different names -(depending on whether or not they're running inside the jail). I'll try not to -confuse you <bf>too</> much :-). - -The main directory that we have to worry about here is <tt>/var/run</>, because -its contents are required for both the main <tt>named</> daemon (inside the -jail), and the <tt>ndc</> utility (on the outside). We'll start by setting -everything up to find this directory from the outside world. To do this, we -need to modify <tt>src/port/linux/Makefile.set</> (substitute your port's -directory if you're not running Linux), and change the line -<tscreen><verb> -DESTRUN=/var/run -</verb></tscreen> -to -<tscreen><verb> -DESTRUN=/chroot/named/var/run -</verb></tscreen> -While you're in there, you may want to change the other destination paths from -<tt>/usr</> to <tt>/usr/local</>. - -Now everything should be able to find that directory... except the <tt/named/ -daemon itself, to which it's still just <tt>/var/run</> inside the jail. We can -get around this by making a small change in the <tt/named/ source. In the file -<tt>src/bin/named/named.h</>, find the line -<tscreen><verb> -#include "pathnames.h" -</verb></tscreen> -and add the following line immediately after it -<tscreen><verb> -#define _PATH_NDCSOCK "/var/run/ndc" -</verb></tscreen> -This way, <tt/named/ will ignore our definition of <tt/DESTRUN/ over in -<tt/Makefile.set/ and use the correct location (from its perspective in the -chroot jail). You will notice some warnings about redefinitions of -_PATH_NDCSOCK when you do the build; just ignore them. - -<sect1>Doing the Build +<sect1>Doing the Compile <p> -You should now be able to compile BIND as normal, following the instructions in -the <tt/INSTALL/ file. At this stage, we only want to compile BIND, not install -it. Don't go too far when following the <tt/INSTALL/ file. Essentially, it's -just <tt/make clean/, <tt/make depend/, and <tt/make/. +Compiling BIND 9 for use in a chroot jail should be a much more pleasant +experience than BIND 8 was. In fact, you don't have to do anything special; +the standard <tt>./configure && make</> should suffice. + +Keep in mind that if you want to enable IPv6 support in BIND +(<tt>--enable-ipv6</>) on Linux systems, you need matching versions of kernel +and glibc. If you have kernel 2.2, you need glibc 2.1, and if you have kernel +2.4, you need glibc 2.2. BIND is quite picky about this. <sect>Installing Your Shiny New BIND<label id="installing"> <p> I should mention that if you have an existing installation of BIND, such as from an RPM, you should probably remove it before installing the new one. On Red Hat -systems, this probably means removing the packages <tt/bind/ and -<tt/bind-utils/, and possibly <tt/bind-devel/ and <tt/caching-nameserver/, if -you have them. +systems, this probably means removing the packages <tt>bind</> and +<tt>bind-utils</>, and possibly <tt>bind-devel</> and <tt>caching-nameserver</>, +if you have them. You may want to save a copy of the init script (e.g., <tt>/etc/rc.d/init.d/named</>), if any, before doing so; it'll be useful later on. -<sect1>Installing the Tools Outside the Jail +If you are upgrading from an older version of BIND, such as BIND 8, you will +want to read the migration documentation in the file <tt>doc/misc/migration</> +in the BIND source package. I don't deal with any migration issues in this +document; I simply assume that you are replacing an existing, working +installation of BIND 9. + +<sect1>Installing the Binaries <p> -This is the easy part :-). Just run <tt/make install/ and let it take care of -it for you. You may want to <tt>chmod 000 /usr/local/sbin/named</> afterwards, -to make sure you don't accidentally run the non-chrooted copy of BIND. (This -is <tt>/usr/sbin/named</> if you didn't tell it to go in <tt>/usr/local/sbin</> -like I suggested.) - -<sect1>Installing the Binaries in the Jail - -<p> -Only two parts of the package have to live inside the chroot jail: the main -<tt/named/ daemon itself, and <tt/named-xfer/, which it uses for zone transfers. -You can simply copy them in from the source tree: -<tscreen><verb> -# cp src/bin/named/named /chroot/named/bin - -# cp src/bin/named-xfer/named-xfer /chroot/named/bin -</verb></tscreen> +This is the easy part :-). Just run <tt>make install</> and let it take care of +it for you. Really, that's it! <sect1>Setting up the Init Script <p> -If you have an existing init script from your distribution, it would probably be -best simply to modify it to run <tt>/chroot/named/bin/named</>, with the -appropriate switches. The switches are... <it/(drumroll please...)/ +If you have an existing init script from your distribution, it would probably +be best simply to modify it to run the new binary, with the appropriate +switches. The switches are... <it>(drumroll please...)</> <itemize> -<item><tt/-u named/, which tells BIND to run as the user <tt/named/, rather than -<tt/root/. -<item><tt/-g named/, to run BIND under the group <tt/named/ too, rather than -<tt/root/ or <tt/wheel/. +<item><tt>-u named</>, which tells BIND to run as the user <tt>named</>, rather +than <tt>root</>. <item><tt>-t /chroot/named</>, which tells BIND to chroot itself to the jail that we've set up. +<item><tt>-c /etc/named.conf</>, which tells BIND where to find its +configuration file within the jail. </itemize> The following is the init script I use with my Red Hat 6.0 system. As you can -see, it is almost exactly the same as the way it shipped from Red Hat. I have -also modified the <tt>ndc restart</> command so that it restarts the server -properly, and keeps it chrooted. You should probably do the same in your init -script, even if you don't copy this one. +see, it is almost exactly the same as the way it shipped from Red Hat. I +haven't tried the <tt>rndc</> commands yet, but I can't see any reason why +they shouldn't work. <tscreen><code> #!/bin/sh # @@ -437,7 +418,7 @@ script, even if you don't copy this one. # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 -[ -f /chroot/named/bin/named ] || exit 0 +[ -f /usr/local/sbin/named ] || exit 0 [ -f /chroot/named/etc/named.conf ] || exit 0 @@ -446,7 +427,7 @@ case "$1" in start) # Start daemons. echo -n "Starting named: " - daemon /chroot/named/bin/named -u named -g named -t /chroot/named + daemon /usr/local/sbin/named -u named -t /chroot/named -c /etc/named.conf echo touch /var/lock/subsys/named ;; @@ -458,26 +439,27 @@ case "$1" in echo ;; status) - /usr/local/sbin/ndc status + status named exit $? ;; restart) - /usr/local/sbin/ndc -n /chroot/named/bin/named "restart -u named -g named -t /chroot/named" + $0 stop + $0 start exit $? ;; reload) - /usr/local/sbin/ndc reload + /usr/local/sbin/rndc reload exit $? ;; probe) # named knows how to reload intelligently; we don't want linuxconf # to offer to restart every time - /usr/local/sbin/ndc reload >/dev/null 2>&1 || echo start + /usr/local/sbin/rndc reload >/dev/null 2>&1 || echo start exit 0 ;; *) - echo "Usage: named {start|stop|status|restart}" + echo "Usage: named {start|stop|status|restart|reload}" exit 1 esac @@ -488,8 +470,8 @@ On Caldera OpenLinux systems, you simply need to modify the variables defined at the top, and it will apparently take care of the rest for you: <tscreen><verb> NAME=named -DAEMON=/chroot/named/bin/$NAME -OPTIONS="-t /chroot/named -u named -g named" +DAEMON=/usr/local/sbin/$NAME +OPTIONS="-t /chroot/named -u named -c /etc/named.conf" </verb></tscreen> <sect1>Configuration Changes @@ -502,18 +484,14 @@ section: <tscreen><verb> directory "/etc/namedb"; pid-file "/var/run/named.pid"; -named-xfer "/bin/named-xfer"; +statistics-file "/var/run/named.stats"; </verb></tscreen> Since this file is being read by the <tt>named</> daemon, all the paths are of -course relative to the chroot jail. - -Some people have also reported having to add an extra block to their -<tt>named.conf</> to get <tt>ndc</> working properly: -<tscreen><verb> -controls { - unix "/var/run/ndc" perm 0600 owner 0 group 0; -}; -</verb></tscreen> +course relative to the chroot jail. As of this writing, BIND 9 does not support +many of the statistics and dump files that previous versions did. Presumably +later versions will; if you are running such a version, you may have to add +additional entries to cause BIND to write them to the <tt>/var/run</> directory +as well. <sect>The End @@ -528,12 +506,6 @@ simply launch it as: </verb></tscreen> Make sure you kill any old versions of BIND still running before doing this. -If you take a look at your logs, you should find the initialisation messages -that BIND spits out when it loads. (If not, there's a problem with your <ref -id="logging" name="logging configuration"> that you need to fix.) Amongst those -messages, BIND should tell you that it chrooted successfully, and that it is -running as the user and group <tt>named</>. If not, you have a problem. - <sect1>That's It! <p> @@ -541,34 +513,44 @@ You can go take a nap now ;-). <sect>Appendix - Upgrading BIND Later<label id="upgrading"> -<p>So, you had BIND 8.2.2_P7 all nicely chrooted and tweaked to your taste... -and then you hear this nasty rumour that there's a remotely-exploitable root -hole in that version too, and you need to upgrade to 8.2.3 right away. Do -you have to go through this whole long process to install this new version? +<p>So, you had BIND 9.1.2 all nicely chrooted and tweaked to your taste... and +then you hear this nasty rumour that BIND 9.1.3 is finally out, and you just +have to give it a try right away. Do you have to go through this whole +long process to install this new version? -Nope. In fact, you really just need the section on <ref id="compiling" -name="Compiling BIND"> and the first two parts of the section on <ref -id="installing" name="Installing BIND"> (installing the binaries outside and -inside the jail, respectively). - -The rest of the HOWTO deals with setting up the jail and other things like -that, which shouldn't need to be altered between versions of BIND. You can -just dump the new binaries in over top of the old ones, and you're good to go. -But don't forget to kill and restart BIND afterwards, or the old, vulnerable -version will still be running! +Nope. In fact, you really just need to compile the new BIND and install it +over top of the old one. Just don't forget to kill the old version and restart +BIND, or it'll still be the old version running! <sect>Appendix - Thanks<label id="thanks"> <p> -I'd like to thank Lonny Selinger <tt><lonny at abyss.za.org></> for -"testing" this HOWTO and making sure that I didn't miss any steps. I'd also -like to thank Chirik <tt><chirik at CastleFur.COM></>, Dwayne Litzenberger -<tt><dlitz at cheerful.com></>, Phil Bambridge <tt><phil.b at +I'd like to thank the following people for their assistance in the creation +of this HOWTO: + +<itemize> + +<item>Lonny Selinger <tt><lonny at abyss.za.org></> for "testing" the +first version of this HOWTO and making sure that I didn't miss any steps. + +<item>Chirik <tt><chirik at CastleFur.COM></>, Dwayne Litzenberger +<tt><dlitz at dlitz.net></>, Phil Bambridge <tt><phil.b at cableinet.co.uk></>, Robert Cole <tt><rcole at metrum-datatape.com></>, Colin MacDonald <tt><colinm at telus.net></>, and others for pointing out errors, omissions, and providing other useful advice to make this HOWTO even better. +<item>Erik Wallin <tt><erikw at sec.se></> and Brian Cervenka +<tt><brian at zerobelow.org></> for providing good suggestions for +further tightening the jail. + +</itemize> + +And last but certainly not least, I'd like to thank Nakano Takeo <tt><nakano +at apm.seikei.ac.jp></> for translating the Chroot-BIND HOWTO into +Japanese. You can find his translation at <url +url="http://www.linux.or.jp/JF/JFdocs/Chroot-BIND-HOWTO.html">. + <sect>Appendix - Document Distribution Policy<label id="legal"> <p>