58
57
<div class="sect1" lang="en">
59
58
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
60
59
<a name="Access_Control_Lists"></a>Access Control Lists</h2></div></div></div>
61
<p>Access Control Lists (ACLs), are address match lists that
62
you can set up and nickname for future use in <span><strong class="command">allow-notify</strong></span>,
63
<span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-recursion</strong></span>,
64
<span><strong class="command">blackhole</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
66
<p>Using ACLs allows you to have finer control over who can access
67
your name server, without cluttering up your config files with huge
68
lists of IP addresses.</p>
69
<p>It is a <span class="emphasis"><em>good idea</em></span> to use ACLs, and to
70
control access to your server. Limiting access to your server by
71
outside parties can help prevent spoofing and DoS attacks against
73
<p>Here is an example of how to properly apply ACLs:</p>
61
Access Control Lists (ACLs), are address match lists that
62
you can set up and nickname for future use in <span><strong class="command">allow-notify</strong></span>,
63
<span><strong class="command">allow-query</strong></span>, <span><strong class="command">allow-query-on</strong></span>,
64
<span><strong class="command">allow-recursion</strong></span>, <span><strong class="command">allow-recursion-on</strong></span>,
65
<span><strong class="command">blackhole</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
69
Using ACLs allows you to have finer control over who can access
70
your name server, without cluttering up your config files with huge
71
lists of IP addresses.
74
It is a <span class="emphasis"><em>good idea</em></span> to use ACLs, and to
75
control access to your server. Limiting access to your server by
76
outside parties can help prevent spoofing and denial of service (DoS) attacks against
80
Here is an example of how to properly apply ACLs:
74
82
<pre class="programlisting">
75
// Set up an ACL named "bogusnets" that will block RFC1918 space,
76
// which is commonly used in spoofing attacks.
77
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; };
83
// Set up an ACL named "bogusnets" that will block RFC1918 space
84
// and some reserved space, which is commonly used in spoofing attacks.
86
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;
87
10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
78
90
// Set up an ACL called our-nets. Replace this with the real IP numbers.
79
acl our-nets { x.x.x.x/24; x.x.x.x/21; };
91
acl our-nets { x.x.x.x/24; x.x.x.x/21; };
86
98
blackhole { bogusnets; };
89
102
zone "example.com" {
91
104
file "m/example.com";
92
105
allow-query { any; };
95
<p>This allows recursive queries of the server from the outside
96
unless recursion has been previously disabled.</p>
97
<p>For more information on how to use ACLs to protect your server,
98
see the <span class="emphasis"><em>AUSCERT</em></span> advisory at
99
<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>
109
This allows recursive queries of the server from the outside
110
unless recursion has been previously disabled.
113
For more information on how to use ACLs to protect your server,
114
see the <span class="emphasis"><em>AUSCERT</em></span> advisory at:
117
<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>
101
120
<div class="sect1" lang="en">
102
121
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
103
<a name="id2567222"></a><span><strong class="command">chroot</strong></span> and <span><strong class="command">setuid</strong></span> (for
104
UNIX servers)</h2></div></div></div>
105
<p>On UNIX servers, it is possible to run <span class="acronym">BIND</span> in a <span class="emphasis"><em>chrooted</em></span> environment
106
(<span><strong class="command">chroot()</strong></span>) by specifying the "<code class="option">-t</code>"
107
option. This can help improve system security by placing <span class="acronym">BIND</span> in
108
a "sandbox", which will limit the damage done if a server is compromised.</p>
109
<p>Another useful feature in the UNIX version of <span class="acronym">BIND</span> is the
110
ability to run the daemon as an unprivileged user ( <code class="option">-u</code> <em class="replaceable"><code>user</code></em> ).
111
We suggest running as an unprivileged user when using the <span><strong class="command">chroot</strong></span> feature.</p>
112
<p>Here is an example command line to load <span class="acronym">BIND</span> in a <span><strong class="command">chroot()</strong></span> sandbox,
113
<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
115
<p><strong class="userinput"><code>/usr/local/bin/named -u 202 -t /var/named</code></strong></p>
122
<a name="id2596516"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
123
</h2></div></div></div>
125
On UNIX servers, it is possible to run <acronym class="acronym">BIND</acronym> in a <span class="emphasis"><em>chrooted</em></span> environment
126
(using the <span><strong class="command">chroot()</strong></span> function) by specifying the "<code class="option">-t</code>"
127
option. This can help improve system security by placing <acronym class="acronym">BIND</acronym> in
128
a "sandbox", which will limit the damage done if a server is
132
Another useful feature in the UNIX version of <acronym class="acronym">BIND</acronym> is the
133
ability to run the daemon as an unprivileged user ( <code class="option">-u</code> <em class="replaceable"><code>user</code></em> ).
134
We suggest running as an unprivileged user when using the <span><strong class="command">chroot</strong></span> feature.
137
Here is an example command line to load <acronym class="acronym">BIND</acronym> in a <span><strong class="command">chroot</strong></span> sandbox,
138
<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
142
<strong class="userinput"><code>/usr/local/bin/named -u 202 -t /var/named</code></strong>
116
144
<div class="sect2" lang="en">
117
145
<div class="titlepage"><div><div><h3 class="title">
118
<a name="id2567366"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
119
<p>In order for a <span><strong class="command">chroot()</strong></span> environment to
120
work properly in a particular directory
121
(for example, <code class="filename">/var/named</code>),
122
you will need to set up an environment that includes everything
123
<span class="acronym">BIND</span> needs to run.
124
From <span class="acronym">BIND</span>'s point of view, <code class="filename">/var/named</code> is
125
the root of the filesystem. You will need to adjust the values of options like
126
like <span><strong class="command">directory</strong></span> and <span><strong class="command">pid-file</strong></span> to account
130
Unlike with earlier versions of BIND, you will typically
131
<span class="emphasis"><em>not</em></span> need to compile <span><strong class="command">named</strong></span>
132
statically nor install shared libraries under the new root.
133
However, depending on your operating system, you may need
134
to set up things like
135
<code class="filename">/dev/zero</code>,
136
<code class="filename">/dev/random</code>,
137
<code class="filename">/dev/log</code>, and/or
138
<code class="filename">/etc/localtime</code>.
146
<a name="id2596593"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
148
In order for a <span><strong class="command">chroot</strong></span> environment
150
work properly in a particular directory
151
(for example, <code class="filename">/var/named</code>),
152
you will need to set up an environment that includes everything
153
<acronym class="acronym">BIND</acronym> needs to run.
154
From <acronym class="acronym">BIND</acronym>'s point of view, <code class="filename">/var/named</code> is
155
the root of the filesystem. You will need to adjust the values of
157
like <span><strong class="command">directory</strong></span> and <span><strong class="command">pid-file</strong></span> to account
161
Unlike with earlier versions of BIND, you typically will
162
<span class="emphasis"><em>not</em></span> need to compile <span><strong class="command">named</strong></span>
163
statically nor install shared libraries under the new root.
164
However, depending on your operating system, you may need
165
to set up things like
166
<code class="filename">/dev/zero</code>,
167
<code class="filename">/dev/random</code>,
168
<code class="filename">/dev/log</code>, and
169
<code class="filename">/etc/localtime</code>.
141
172
<div class="sect2" lang="en">
142
173
<div class="titlepage"><div><div><h3 class="title">
143
<a name="id2567424"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
144
<p>Prior to running the <span><strong class="command">named</strong></span> daemon, use
145
the <span><strong class="command">touch</strong></span> utility (to change file access and
146
modification times) or the <span><strong class="command">chown</strong></span> utility (to
147
set the user id and/or group id) on files
148
to which you want <span class="acronym">BIND</span>
149
to write. Note that if the <span><strong class="command">named</strong></span> daemon is running as an
150
unprivileged user, it will not be able to bind to new restricted ports if the
151
server is reloaded.</p>
174
<a name="id2596652"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
176
Prior to running the <span><strong class="command">named</strong></span> daemon,
178
the <span><strong class="command">touch</strong></span> utility (to change file
180
modification times) or the <span><strong class="command">chown</strong></span>
182
set the user id and/or group id) on files
183
to which you want <acronym class="acronym">BIND</acronym>
186
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
187
<h3 class="title">Note</h3>
188
Note that if the <span><strong class="command">named</strong></span> daemon is running as an
189
unprivileged user, it will not be able to bind to new restricted
190
ports if the server is reloaded.
154
194
<div class="sect1" lang="en">
155
195
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
156
196
<a name="dynamic_update_security"></a>Dynamic Update Security</h2></div></div></div>
157
<p>Access to the dynamic
158
update facility should be strictly limited. In earlier versions of
159
<span class="acronym">BIND</span> the only way to do this was based on the IP
160
address of the host requesting the update, by listing an IP address or
161
network prefix in the <span><strong class="command">allow-update</strong></span> zone option.
162
This method is insecure since the source address of the update UDP packet
163
is easily forged. Also note that if the IP addresses allowed by the
164
<span><strong class="command">allow-update</strong></span> option include the address of a slave
165
server which performs forwarding of dynamic updates, the master can be
166
trivially attacked by sending the update to the slave, which will
167
forward it to the master with its own source IP address causing the
168
master to approve it without question.</p>
169
<p>For these reasons, we strongly recommend that updates be
170
cryptographically authenticated by means of transaction signatures
171
(TSIG). That is, the <span><strong class="command">allow-update</strong></span> option should
172
list only TSIG key names, not IP addresses or network
173
prefixes. Alternatively, the new <span><strong class="command">update-policy</strong></span>
174
option can be used.</p>
175
<p>Some sites choose to keep all dynamically updated DNS data
176
in a subdomain and delegate that subdomain to a separate zone. This
177
way, the top-level zone containing critical data such as the IP addresses
178
of public web and mail servers need not allow dynamic update at
198
Access to the dynamic
199
update facility should be strictly limited. In earlier versions of
200
<acronym class="acronym">BIND</acronym>, the only way to do this was
202
address of the host requesting the update, by listing an IP address
204
network prefix in the <span><strong class="command">allow-update</strong></span>
206
This method is insecure since the source address of the update UDP
208
is easily forged. Also note that if the IP addresses allowed by the
209
<span><strong class="command">allow-update</strong></span> option include the
211
server which performs forwarding of dynamic updates, the master can
213
trivially attacked by sending the update to the slave, which will
214
forward it to the master with its own source IP address causing the
215
master to approve it without question.
218
For these reasons, we strongly recommend that updates be
219
cryptographically authenticated by means of transaction signatures
220
(TSIG). That is, the <span><strong class="command">allow-update</strong></span>
222
list only TSIG key names, not IP addresses or network
223
prefixes. Alternatively, the new <span><strong class="command">update-policy</strong></span>
227
Some sites choose to keep all dynamically-updated DNS data
228
in a subdomain and delegate that subdomain to a separate zone. This
229
way, the top-level zone containing critical data such as the IP
231
of public web and mail servers need not allow dynamic update at
182
236
<div class="navfooter">
added
removed
doc/arm/Bv9ARM.ch07.html
