369N/A - Copyright (C) 2000-2015 Internet Systems Consortium, Inc. ("ISC") 369N/A - This Source Code Form is subject to the terms of the Mozilla Public 369N/A - License, v. 2.0. If a copy of the MPL was not distributed with this 369N/A<
meta http-
equiv="Content-Type" content="text/html; charset=ISO-8859-1">
369N/A<
title>Chapter�7.�BIND 9 Security Considerations</
title>
369N/A<
meta name="generator" content="DocBook XSL Stylesheets V1.78.1">
369N/A<
link rel="home" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
369N/A<
link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
2362N/A<
body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
2362N/A<
table width="100%" summary="Navigation header">
369N/A<
tr><
th colspan="3" align="center">Chapter�7.�<
acronym class="acronym">BIND</
acronym> 9 Security Considerations</
th></
tr>
5361N/A<
td width="20%" align="left">
5361N/A<
th width="60%" align="center">�</
th>
369N/A<
div class="titlepage"><
div><
div><
h1 class="title">
369N/A<
a name="Bv9ARM.ch07"></
a>Chapter�7.�<
acronym class="acronym">BIND</
acronym> 9 Security Considerations</
h1></
div></
div></
div>
369N/A<
p><
b>Table of Contents</
b></
p>
369N/A<
dt><
span class="section"><
a href="Bv9ARM.ch07.html#Access_Control_Lists">Access Control Lists</
a></
span></
dt>
369N/A<
dt><
span class="section"><
a href="Bv9ARM.ch07.html#chroot_and_setuid"><
span class="command"><
strong>Chroot</
strong></
span> and <
span class="command"><
strong>Setuid</
strong></
span></
a></
span></
dt>
369N/A<
dt><
span class="section"><
a href="Bv9ARM.ch07.html#chroot">The <
span class="command"><
strong>chroot</
strong></
span> Environment</
a></
span></
dt>
369N/A<
dt><
span class="section"><
a href="Bv9ARM.ch07.html#setuid">Using the <
span class="command"><
strong>setuid</
strong></
span> Function</
a></
span></
dt>
369N/A<
dt><
span class="section"><
a href="Bv9ARM.ch07.html#dynamic_update_security">Dynamic Update Security</
a></
span></
dt>
369N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
369N/A<
a name="Access_Control_Lists"></
a>Access Control Lists</
h2></
div></
div></
div>
369N/A Access Control Lists (ACLs) are address match lists that
369N/A you can set up and nickname for future use in
369N/A <
span class="command"><
strong>allow-notify</
strong></
span>, <
span class="command"><
strong>allow-query</
strong></
span>,
369N/A <
span class="command"><
strong>allow-query-on</
strong></
span>, <
span class="command"><
strong>allow-recursion</
strong></
span>,
369N/A <
span class="command"><
strong>blackhole</
strong></
span>, <
span class="command"><
strong>allow-transfer</
strong></
span>,
369N/A <
span class="command"><
strong>match-clients</
strong></
span>, etc.
369N/A Using ACLs allows you to have finer control over who can access
369N/A your name server, without cluttering up your config files with huge
369N/A It is a <
span class="emphasis"><
em>good idea</
em></
span> to use ACLs, and to
369N/A control access to your server. Limiting access to your server by
369N/A outside parties can help prevent spoofing and denial of service
369N/A (DoS) attacks against your server.
369N/A ACLs match clients on the basis of up to three characteristics:
369N/A 1) The client's IP address; 2) the TSIG or SIG(0) key that was
369N/A used to sign the request, if any; and 3) an address prefix
369N/A encoded in an EDNS Client Subnet option, if any.
369N/A Here is an example of ACLs based on client addresses:
369N/A<
pre class="programlisting">
369N/A// Set up an ACL named "bogusnets" that will block
369N/A// RFC1918 space and some reserved space, which is
369N/A// commonly used in spoofing attacks.
369N/A// Set up an ACL called our-nets. Replace this with the
369N/A allow-query { our-nets; };
369N/A allow-recursion { our-nets; };
369N/A blackhole { bogusnets; };
369N/A address, but recursive queries only from the networks specified
369N/A in "our-nets", and no queries at all from the networks
369N/A specified in "bogusnets".
369N/A In addition to network addresses and prefixes, which are
369N/A matched against the source address of the DNS request, ACLs
369N/A may include <
code class="option">key</
code> elements, which specify the
369N/A name of a TSIG or SIG(0) key, or <
code class="option">ecs</
code>
369N/A elements, which specify a network prefix but are only matched
369N/A if that prefix matches an EDNS client subnet option included
369N/A The EDNS Client Subnet (ECS) option is used by a recursive
369N/A resolver to inform an authoritative name server of the network
369N/A address block from which the original query was received, enabling
369N/A authoritative servers to give different answers to the same
369N/A resolver for different resolver clients. An ACL containing
369N/A <
span class="command"><
strong>ecs <
em class="replaceable"><
code>prefix</
code></
em></
strong></
span>
369N/A will match if a request arrives in containing an ECS option
369N/A encoding an address within that prefix. If the request has no
369N/A ECS option, then "ecs" elements are simply ignored. Addresses
369N/A in ACLs that are not prefixed with "ecs" are matched only
369N/A against the source address.
369N/A When <
acronym class="acronym">BIND</
acronym> 9 is built with GeoIP support,
369N/A ACLs can also be used for geographic access restrictions.
369N/A This is done by specifying an ACL element of the form:
369N/A <
span class="command"><
strong>geoip [<
span class="optional">db <
em class="replaceable"><
code>database</
code></
em></
span>] <
em class="replaceable"><
code>field</
code></
em> <
em class="replaceable"><
code>value</
code></
em></
strong></
span>
369N/A The <
em class="replaceable"><
code>field</
code></
em> indicates which field
369N/A to search for a match. Available fields are "country",
369N/A "region", "city", "continent", "postal" (postal code),
369N/A "metro" (metro code), "area" (area code), "tz" (timezone),
369N/A "isp", "org", "asnum", "domain" and "netspeed".
369N/A <
em class="replaceable"><
code>value</
code></
em> is the value to search
369N/A for within the database. A string may be quoted if it
369N/A contains spaces or other special characters. If this is
369N/A an "asnum" search, then the leading "ASNNNN" string can be
369N/A used, otherwise the full description must be used (
e.g. 369N/A "ASNNNN Example Company Name"). If this is a "country"
369N/A search and the string is two characters long, then it must
369N/A be a standard ISO-3166-1 two-letter country code, and if it
369N/A is three characters long then it must be an ISO-3166-1
369N/A three-letter country code; otherwise it is the full name
369N/A of the country. Similarly, if this is a "region" search
369N/A and the string is two characters long, then it must be a
369N/A standard two-letter state or province abbreviation;
369N/A otherwise it is the full name of the state or province.
369N/A The <
em class="replaceable"><
code>database</
code></
em> field indicates which
369N/A GeoIP database to search for a match. In most cases this is
369N/A unnecessary, because most search fields can only be found in
369N/A a single database. However, searches for country can be
369N/A answered from the "city", "region", or "country" databases,
369N/A and searches for region (
i.e., state or province) can be
369N/A answered from the "city" or "region" databases. For these
369N/A search types, specifying a <
em class="replaceable"><
code>database</
code></
em>
369N/A will force the query to be answered from that database and no
369N/A other. If <
em class="replaceable"><
code>database</
code></
em> is not
369N/A specified, then these queries will be answered from the "city",
369N/A database if it is installed, or the "region" database if it is
369N/A installed, or the "country" database, in that order.
369N/A By default, if a DNS query includes an EDNS Client Subnet (ECS)
369N/A option which encodes a non-zero address prefix, then GeoIP ACLs
369N/A will be matched against that address prefix. Otherwise, they
369N/A are matched against the source address of the query. To
369N/A prevent GeoIP ACLs from matching against ECS options, set
369N/A the <
span class="command"><
strong>geoip-use-ecs</
strong></
span> to <
code class="literal">no</
code>.
369N/A Some example GeoIP ACLs:
369N/A<
pre class="programlisting">geoip country US;
369N/Ageoip db country country Canada;
369N/Ageoip db region region WA;
369N/Ageoip city "San Francisco";
369N/Ageoip org "Internet Systems Consortium";
369N/A ACLs use a "first-match" logic rather than "best-match":
369N/A if an address prefix matches an ACL element, then that ACL
5870N/A is considered to have matched even if a later element would
369N/A have matched more specifically. For example, the ACL
369N/A <
span class="command"><
strong> { 10/8; !10.0.0.1; }</
strong></
span> would actually
369N/A match a query from 10.0.0.1, because the first element
369N/A indicated that the query should be accepted, and the second
369N/A When using "nested" ACLs (that is, ACLs included or referenced
369N/A within other ACLs), a negative match of a nested ACL will
369N/A the containing ACL to continue looking for matches. This
369N/A enables complex ACLs to be constructed, in which multiple
369N/A client characteristics can be checked at the same time. For
369N/A example, to construct an ACL which allows queries only when
369N/A it originates from a particular network <
span class="emphasis"><
em>and</
em></
span>
369N/A only when it is signed with a particular key, use:
369N/A<
pre class="programlisting">
369N/Aallow-query { !{ !10/8; any; }; key example; };
369N/A Within the nested ACL, any address that is
369N/A <
span class="emphasis"><
em>not</
em></
span> in the 10/8 network prefix will
369N/A be rejected, and this will terminate processing of the
369N/A ACL. Any address that <
span class="emphasis"><
em>is</
em></
span> in the 10/8
369N/A network prefix will be accepted, but this causes a negative
369N/A match of the nested ACL, so the containing ACL continues
369N/A processing. The query will then be accepted if it is signed
369N/A by the key "example", and rejected otherwise. The ACL, then,
369N/A will only matches when <
span class="emphasis"><
em>both</
em></
span> conditions
369N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
369N/A<
a name="chroot_and_setuid"></
a><
span class="command"><
strong>Chroot</
strong></
span> and <
span class="command"><
strong>Setuid</
strong></
span>
369N/A On UNIX servers, it is possible to run <
acronym class="acronym">BIND</
acronym>
369N/A in a <
span class="emphasis"><
em>chrooted</
em></
span> environment (using
369N/A the <
span class="command"><
strong>chroot()</
strong></
span> function) by specifying
369N/A the <
code class="option">-t</
code> option for <
span class="command"><
strong>named</
strong></
span>.
369N/A This can help improve system security by placing
369N/A <
acronym class="acronym">BIND</
acronym> in a "sandbox", which will limit
369N/A the damage done if a server is compromised.
369N/A Another useful feature in the UNIX version of <
acronym class="acronym">BIND</
acronym> is the
369N/A ability to run the daemon as an unprivileged user ( <
code class="option">-u</
code> <
em class="replaceable"><
code>user</
code></
em> ).
369N/A We suggest running as an unprivileged user when using the <
span class="command"><
strong>chroot</
strong></
span> feature.
369N/A Here is an example command line to load <
acronym class="acronym">BIND</
acronym> in a <
span class="command"><
strong>chroot</
strong></
span> sandbox,
369N/A <
span class="command"><
strong>/
var/
named</
strong></
span>, and to run <
span class="command"><
strong>named</
strong></
span> <
span class="command"><
strong>setuid</
strong></
span> to
369N/A<
div class="titlepage"><
div><
div><
h3 class="title">
369N/A<
a name="chroot"></
a>The <
span class="command"><
strong>chroot</
strong></
span> Environment</
h3></
div></
div></
div>
369N/A In order for a <
span class="command"><
strong>chroot</
strong></
span> environment
369N/A to work properly in a particular directory (for example,
369N/A <
code class="filename">/
var/
named</
code>), you will need to set
369N/A up an environment that includes everything
369N/A <
acronym class="acronym">BIND</
acronym> needs to run. From
369N/A <
acronym class="acronym">BIND</
acronym>'s point of view,
369N/A filesystem. You will need to adjust the values of
369N/A options like <
span class="command"><
strong>directory</
strong></
span> and
369N/A <
span class="command"><
strong>pid-file</
strong></
span> to account for this.
369N/A Unlike with earlier versions of BIND, you typically will
369N/A <
span class="emphasis"><
em>not</
em></
span> need to compile <
span class="command"><
strong>named</
strong></
span>
369N/A statically nor install shared libraries under the new root.
369N/A However, depending on your operating system, you may need
369N/A<
div class="titlepage"><
div><
div><
h3 class="title">
369N/A<
a name="setuid"></
a>Using the <
span class="command"><
strong>setuid</
strong></
span> Function</
h3></
div></
div></
div>
369N/A Prior to running the <
span class="command"><
strong>named</
strong></
span> daemon,
369N/A the <
span class="command"><
strong>touch</
strong></
span> utility (to change file
369N/A modification times) or the <
span class="command"><
strong>chown</
strong></
span>
369N/A to which you want <
acronym class="acronym">BIND</
acronym>
369N/A<
div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
369N/A<
h3 class="title">Note</
h3>
369N/A If the <
span class="command"><
strong>named</
strong></
span> daemon is running as an
369N/A unprivileged user, it will not be able to bind to new restricted
369N/A ports if the server is reloaded.
369N/A<
div class="titlepage"><
div><
div><
h2 class="title" style="clear: both">
369N/A<
a name="dynamic_update_security"></
a>Dynamic Update Security</
h2></
div></
div></
div>
369N/A update facility should be strictly limited. In earlier versions of
369N/A <
acronym class="acronym">BIND</
acronym>, the only way to do this was
369N/A address of the host requesting the update, by listing an IP address
369N/A network prefix in the <
span class="command"><
strong>allow-update</
strong></
span>
369N/A This method is insecure since the source address of the update UDP
369N/A is easily forged. Also note that if the IP addresses allowed by the
369N/A <
span class="command"><
strong>allow-update</
strong></
span> option include the
369N/A server which performs forwarding of dynamic updates, the master can
369N/A trivially attacked by sending the update to the slave, which will
369N/A forward it to the master with its own source IP address causing the
369N/A master to approve it without question.
369N/A For these reasons, we strongly recommend that updates be
369N/A cryptographically authenticated by means of transaction signatures
369N/A (TSIG). That is, the <
span class="command"><
strong>allow-update</
strong></
span>
369N/A list only TSIG key names, not IP addresses or network
369N/A prefixes. Alternatively, the new <
span class="command"><
strong>update-policy</
strong></
span>
369N/A Some sites choose to keep all dynamically-updated DNS data
369N/A in a subdomain and delegate that subdomain to a separate zone. This
369N/A way, the top-level zone containing critical data such as the IP
369N/A of public web and mail servers need not allow dynamic update at
369N/A<
table width="100%" summary="Navigation footer">
369N/A<
td width="40%" align="left">
369N/A<
td width="20%" align="center">�</
td>
369N/A<
td width="40%" align="left" valign="top">Chapter�6.�<
acronym class="acronym">BIND</
acronym> 9 Configuration Reference�</
td>
369N/A<
td width="20%" align="center"><
a accesskey="h" href="Bv9ARM.html">Home</
a></
td>
369N/A<
td width="40%" align="right" valign="top">�Chapter�8.�Troubleshooting</
td>