0N/A - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") 0N/A - Copyright (C) 2000-2003 Internet Software Consortium. 0N/A - Permission to use, copy, modify, and distribute this software for any 0N/A - purpose with or without fee is hereby granted, provided that the above 0N/A - copyright notice and this permission notice appear in all copies. 0N/A - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH 0N/A - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 0N/A - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, 0N/A - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM 0N/A - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE 0N/A - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 0N/A - PERFORMANCE OF THIS SOFTWARE. 0N/A<
meta http-
equiv="Content-Type" content="text/html; charset=ISO-8859-1">
0N/A<
title>Chapter�7.�BIND 9 Security Considerations</
title>
0N/A<
meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
0N/A<
link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
0N/A<
link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
0N/A<
body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
0N/A<
div class="navheader">
0N/A<
table width="100%" summary="Navigation header">
0N/A<
tr><
th colspan="3" align="center">Chapter�7.�<
span class="acronym">BIND</
span> 9 Security Considerations</
th></
tr>
0N/A<
td width="20%" align="left">
0N/A<
th width="60%" align="center">�</
th>
92N/A<
div class="chapter" lang="en">
92N/A<
div class="titlepage"><
div><
div><
h2 class="title">
92N/A<
a name="Bv9ARM.ch07"></
a>Chapter�7.�<
span class="acronym">BIND</
span> 9 Security Considerations</
h2></
div></
div></
div>
92N/A<
p><
b>Table of Contents</
b></
p>
92N/A<
dt><
span class="sect1"><
a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</
a></
span></
dt>
0N/A<
dt><
span class="sect1"><
a href="Bv9ARM.ch07.html#id2559345"><
span><
strong class="command">chroot</
strong></
span> and <
span><
strong class="command">setuid</
strong></
span> (for
0N/A UNIX servers)</
a></
span></
dt>
92N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch07.html#id2559421">The <
span><
strong class="command">chroot</
strong></
span> Environment</
a></
span></
dt>
92N/A<
dt><
span class="sect2"><
a href="Bv9ARM.ch07.html#id2559481">Using the <
span><
strong class="command">setuid</
strong></
span> Function</
a></
span></
dt>
92N/A<
dt><
span class="sect1"><
a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</
a></
span></
dt>
92N/A<
div class="sect1" lang="en">
92N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
92N/A<
a name="Access_Control_Lists"></
a>Access Control Lists</
h2></
div></
div></
div>
92N/A Access Control Lists (ACLs), are address match lists that
92N/A you can set up and nickname for future use in <
span><
strong class="command">allow-notify</
strong></
span>,
0N/A <
span><
strong class="command">allow-query</
strong></
span>, <
span><
strong class="command">allow-recursion</
strong></
span>,
0N/A <
span><
strong class="command">blackhole</
strong></
span>, <
span><
strong class="command">allow-transfer</
strong></
span>,
92N/A Using ACLs allows you to have finer control over who can access
92N/A your name server, without cluttering up your config files with huge
92N/A lists of IP addresses.
92N/A It is a <
span class="emphasis"><
em>good idea</
em></
span> to use ACLs, and to
92N/A control access to your server. Limiting access to your server by
92N/A outside parties can help prevent spoofing and DoS attacks against
92N/A Here is an example of how to properly apply ACLs:
92N/A<
pre class="programlisting">
92N/A// Set up an ACL named "bogusnets" that will block RFC1918 space,
92N/A// which is commonly used in spoofing attacks.
92N/A// Set up an ACL called our-nets. Replace this with the real IP numbers.
92N/A allow-query { our-nets; };
92N/A allow-recursion { our-nets; };
92N/A blackhole { bogusnets; };
92N/A allow-query { any; };
92N/A This allows recursive queries of the server from the outside
92N/A unless recursion has been previously disabled.
92N/A For more information on how to use ACLs to protect your server,
92N/A see the <
span class="emphasis"><
em>AUSCERT</
em></
span> advisory at
0N/A<
div class="sect1" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
0N/A<
a name="id2559345"></
a><
span><
strong class="command">chroot</
strong></
span> and <
span><
strong class="command">setuid</
strong></
span> (for
0N/A UNIX servers)</
h2></
div></
div></
div>
0N/A On UNIX servers, it is possible to run <
span class="acronym">BIND</
span> in a <
span class="emphasis"><
em>chrooted</
em></
span> environment
0N/A (<
span><
strong class="command">chroot()</
strong></
span>) by specifying the "<
code class="option">-t</
code>"
0N/A option. This can help improve system security by placing <
span class="acronym">BIND</
span> in
0N/A a "sandbox", which will limit the damage done if a server is
0N/A Another useful feature in the UNIX version of <
span class="acronym">BIND</
span> is the
0N/A ability to run the daemon as an unprivileged user ( <
code class="option">-u</
code> <
em class="replaceable"><
code>user</
code></
em> ).
0N/A We suggest running as an unprivileged user when using the <
span><
strong class="command">chroot</
strong></
span> feature.
0N/A Here is an example command line to load <
span class="acronym">BIND</
span> in a <
span><
strong class="command">chroot()</
strong></
span> sandbox,
0N/A <
span><
strong class="command">/
var/
named</
strong></
span>, and to run <
span><
strong class="command">named</
strong></
span> <
span><
strong class="command">setuid</
strong></
span> to
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2559421"></
a>The <
span><
strong class="command">chroot</
strong></
span> Environment</
h3></
div></
div></
div>
0N/A In order for a <
span><
strong class="command">chroot()</
strong></
span> environment
0N/A work properly in a particular directory
0N/A (for example, <
code class="filename">/
var/
named</
code>),
0N/A you will need to set up an environment that includes everything
0N/A <
span class="acronym">BIND</
span> needs to run.
0N/A From <
span class="acronym">BIND</
span>'s point of view, <
code class="filename">/
var/
named</
code> is
0N/A the root of the filesystem. You will need to adjust the values of
0N/A like <
span><
strong class="command">directory</
strong></
span> and <
span><
strong class="command">pid-file</
strong></
span> to account
0N/A Unlike with earlier versions of BIND, you will typically
0N/A <
span class="emphasis"><
em>not</
em></
span> need to compile <
span><
strong class="command">named</
strong></
span>
0N/A statically nor install shared libraries under the new root.
0N/A However, depending on your operating system, you may need
89N/A to set up things like
0N/A<
div class="sect2" lang="en">
0N/A<
div class="titlepage"><
div><
div><
h3 class="title">
0N/A<
a name="id2559481"></
a>Using the <
span><
strong class="command">setuid</
strong></
span> Function</
h3></
div></
div></
div>
0N/A Prior to running the <
span><
strong class="command">named</
strong></
span> daemon,
0N/A the <
span><
strong class="command">touch</
strong></
span> utility (to change file
89N/A modification times) or the <
span><
strong class="command">chown</
strong></
span>
89N/A to which you want <
span class="acronym">BIND</
span>
89N/A to write. Note that if the <
span><
strong class="command">named</
strong></
span>
92N/A daemon is running as an
89N/A unprivileged user, it will not be able to bind to new restricted
89N/A server is reloaded.
89N/A<
div class="sect1" lang="en">
92N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
89N/A<
a name="dynamic_update_security"></
a>Dynamic Update Security</
h2></
div></
div></
div>
0N/A Access to the dynamic
0N/A update facility should be strictly limited. In earlier versions of
0N/A <
span class="acronym">BIND</
span> the only way to do this was
0N/A address of the host requesting the update, by listing an IP address
0N/A network prefix in the <
span><
strong class="command">allow-update</
strong></
span>
0N/A This method is insecure since the source address of the update UDP
0N/A is easily forged. Also note that if the IP addresses allowed by the
0N/A <
span><
strong class="command">allow-update</
strong></
span> option include the
0N/A server which performs forwarding of dynamic updates, the master can
0N/A trivially attacked by sending the update to the slave, which will
0N/A forward it to the master with its own source IP address causing the
0N/A master to approve it without question.
0N/A For these reasons, we strongly recommend that updates be
0N/A cryptographically authenticated by means of transaction signatures
0N/A (TSIG). That is, the <
span><
strong class="command">allow-update</
strong></
span>
0N/A list only TSIG key names, not IP addresses or network
0N/A prefixes. Alternatively, the new <
span><
strong class="command">update-policy</
strong></
span>
0N/A Some sites choose to keep all dynamically updated DNS data
0N/A in a subdomain and delegate that subdomain to a separate zone. This
0N/A way, the top-level zone containing critical data such as the IP
0N/A of public web and mail servers need not allow dynamic update at
58N/A<
div class="navfooter">
58N/A<
table width="100%" summary="Navigation footer">
0N/A<
td width="40%" align="left">
0N/A<
td width="20%" align="center">�</
td>
0N/A<
td width="40%" align="left" valign="top">Chapter�6.�<
span class="acronym">BIND</
span> 9 Configuration Reference�</
td>
0N/A<
td width="20%" align="center"><
a accesskey="h" href="Bv9ARM.html">Home</
a></
td>
0N/A<
td width="40%" align="right" valign="top">�Chapter�8.�Troubleshooting</
td>