Bv9ARM.ch07.html revision dcebbac4f62ffa1a8c907095c85c4bea110216ff
<HTML
><HEAD
><TITLE
>BIND 9 Security Considerations</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.41"><LINK
REL="HOME"
HREF="Bv9ARM.html"><LINK
REL="PREVIOUS"
TITLE="BIND 9 Configuration Reference"
HREF="Bv9ARM.ch06.html"><LINK
REL="NEXT"
TITLE="Troubleshooting"
HREF="Bv9ARM.ch08.html"></HEAD
><BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch06.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch08.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="ch07"
>Chapter 7. <SPAN
CLASS="acronym"
>BIND</SPAN
> 9 Security Considerations</A
></H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>7.1. <A
HREF="Bv9ARM.ch07.html#Access_Control_Lists"
>Access Control Lists</A
></DT
><DT
>7.2. <A
HREF="Bv9ARM.ch07.html#AEN3876"
><B
CLASS="command"
>chroot</B
> and <B
CLASS="command"
>setuid</B
> (for
UNIX servers)</A
></DT
><DT
>7.3. <A
HREF="Bv9ARM.ch07.html#AEN3922"
>Dynamic Updates</A
></DT
></DL
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="Access_Control_Lists"
>7.1. Access Control Lists</A
></H1
><P
>Access Control Lists (ACLs), are address match lists that
you can set up and nickname for future use in <B
CLASS="command"
>allow-query</B
>, <B
CLASS="command"
>allow-recursion</B
>, <B
CLASS="command"
>blackhole</B
>, <B
CLASS="command"
>allow-transfer</B
>,
etc.</P
><P
>Using ACLs allows you to have finer control over who can access
your nameserver, without cluttering up your config files with huge
lists of IP addresses.</P
><P
>It is a <I
CLASS="emphasis"
>good idea</I
> to use ACLs, and to
control access to your server. Limiting access to your server by
outside parties can help prevent spoofing and DoS attacks against
your server.</P
><P
>Here is an example of how to properly apply ACLs:</P
><PRE
CLASS="programlisting"
>&#13;// Set up an ACL named "bogusnets" that will block RFC1918 space,
// which is commonly used in spoofing attacks.
acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
// Set up an ACL called our-nets. Replace this with the real IP numbers.
acl our-nets { x.x.x.x/24; x.x.x.x/21; };
options {
...
...
allow-query { our-nets; };
allow-recursion { our-nets; };
...
blackhole { bogusnets; };
...
};
zone "example.com" {
type master;
file "m/example.com";
allow-query { any; };
};
</PRE
><P
>This allows recursive queries of the server from the outside
unless recursion has been previously disabled.</P
><P
>For more information on how to use ACLs to protect your server,
see the <I
CLASS="emphasis"
>AUSCERT</I
> advisory at
<A
HREF="ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos"
TARGET="_top"
>ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</A
></P
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN3876"
>7.2. <B
CLASS="command"
>chroot</B
> and <B
CLASS="command"
>setuid</B
> (for
UNIX servers)</A
></H1
><P
>On UNIX servers, it is possible to run <SPAN
CLASS="acronym"
>BIND</SPAN
> in a <I
CLASS="emphasis"
>chrooted</I
> environment
(<B
CLASS="command"
>chroot()</B
>) by specifying the "<TT
CLASS="option"
>-t</TT
>"
option. This can help improve system security by placing <SPAN
CLASS="acronym"
>BIND</SPAN
> in
a "sandbox," which will limit the damage done if a server is compromised.</P
><P
>Another useful feature in the UNIX version of <SPAN
CLASS="acronym"
>BIND</SPAN
> is the
ability to run the daemon as a nonprivileged user ( <TT
CLASS="option"
>-u</TT
> <TT
CLASS="replaceable"
><I
>user</I
></TT
> ).
We suggest running as a nonprivileged user when using the <B
CLASS="command"
>chroot</B
> feature.</P
><P
>Here is an example command line to load <SPAN
CLASS="acronym"
>BIND</SPAN
> in a <B
CLASS="command"
>chroot()</B
> sandbox,
<B
CLASS="command"
>/var/named</B
>, and to run <B
CLASS="command"
>named</B
> <B
CLASS="command"
>setuid</B
> to
user 202:</P
><P
><TT
CLASS="userinput"
><B
>/usr/local/bin/named -u 202 -t /var/named</B
></TT
></P
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN3899"
>7.2.1. The <B
CLASS="command"
>chroot</B
> Environment</A
></H2
><P
>In order for a <B
CLASS="command"
>chroot()</B
> environment to
work properly in a particular directory (for example, <TT
CLASS="filename"
>/var/named</TT
>),
you will need to set up an environment that includes everything
<SPAN
CLASS="acronym"
>BIND</SPAN
> needs to run. From <SPAN
CLASS="acronym"
>BIND</SPAN
>'s point of view, <TT
CLASS="filename"
>/var/named</TT
> is
the root of the filesystem. You will need <TT
CLASS="filename"
>/dev/null</TT
>,
and any library directories and files that <SPAN
CLASS="acronym"
>BIND</SPAN
> needs to run on
your system. Please consult your operating system's instructions
if you need help figuring out which library files you need to copy
over to the <B
CLASS="command"
>chroot()</B
> sandbox.</P
><P
>If you are running an operating system that supports static
binaries, you can also compile <SPAN
CLASS="acronym"
>BIND</SPAN
> statically and avoid the need
to copy system libraries over to your <B
CLASS="command"
>chroot()</B
> sandbox.</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN3914"
>7.2.2. Using the <B
CLASS="command"
>setuid</B
> Function</A
></H2
><P
>Prior to running the <B
CLASS="command"
>named</B
> daemon, use
the <B
CLASS="command"
>touch</B
> utility (to change file access and
modification times) or the <B
CLASS="command"
>chown</B
> utility (to
set the user id and/or group id) on files to which you want <SPAN
CLASS="acronym"
>BIND</SPAN
>
to write.</P
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN3922"
>7.3. Dynamic Updates</A
></H1
><P
>Access to the dynamic update facility should be strictly limited.
In earlier versions of <SPAN
CLASS="acronym"
>BIND</SPAN
> the only way to do this was based on
the IP address of the host requesting the update. <SPAN
CLASS="acronym"
>BIND9</SPAN
> also
supports authenticating updates cryptographically by means of transaction
signatures (TSIG). The use of TSIG is strongly recommended.</P
><P
>Some sites choose to keep all dynamically updated DNS data
in a subdomain and delegate that subdomain to a separate zone. This
way, the top-level zone containing critical data such as the IP addresses
of public web and mail servers need not allow dynamic update at
all.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="Bv9ARM.ch06.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="Bv9ARM.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="Bv9ARM.ch08.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><SPAN
CLASS="acronym"
>BIND</SPAN
> 9 Configuration Reference</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Troubleshooting</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>