Agenda: dns-bind-transfer-security.txt

File dns-bind-transfer-security.txt, 6.3 KB (added by regnauld, 8 years ago)

dns-bind-transfer-security.txt

Line 
1BIND TRANSFER SECURITY
2----------------------
3
4We're going to limit zone transfer of your zones so that only
5your secondary/slave nameservers are allowed to request copies
6of the zones.
7
8ACL based security
9------------------
10
11To start with, we'll enable IP based ACLs -- on the MASTER host:
12
131. Start by editing /etc/namedb/named.conf, and in the "options" section,
14   let's define who is allowed to transfer your zone.
15
16   allow-transfer { 127.0.0.1; ::1; myslaves; };
17
18   Now we need to define the ACL "myslaves".  To do so, AFTER the options
19   section (find the '};' symbol at the end of the section), add something
20   similar to this:
21
22   (If the slave for your "MYTLD" domain is master.grp25, for example)
23
24acl myslaves { 10.10.25.1; 10.10.X.3; }; // ACL with IP of Group25 master
25
26        This means "myslaves is an ACL consisting of the IP 10.10.25.1,
27        and your NSD secondary 10.10.25.3.
28
292. Restart named
30
31        # /etc/rc.d/named restart
32
333. Make sure that you didn't break the zone transfer by asking your
34   slave partner to run a zone transfer against YOUR machine.
35
36   From their server:
37
38   # dig @master.grpX.ws.nsrc.org MYTLD axfr
39
404. Now try and ask someone else who is NOT in the ACL to try the same
41   axfr command as above.
42
43   Q: Do they succeed ?
44   Q: What do you see in the logs in /etc/namedb/log/transfers ?
45
46
475. Let's make swatch complain if it sees a forbidden zone transfer:
48
49        Edit /usr/local/etc/swatch.conf, and add a new section -- remember
50        to use TAB for the space at the beginning of the lines:
51
52- - - - - - - - - - - - - - -  cut below - - - - - - - - - - - - - -
53
54
55watchfor /client ([0-9.:]+)\D\d+: zone transfer '(.*)\/.XFR\/IN' denied$/
56        mail=adm,subject=Denied AXFR for zone '$2' from $1
57        threshold type=limit,count=1,seconds=600
58
59- - - - - - - - - - - - - - -  cut above - - - - - - - - - - - - - -
60
616. Kill swatch
62
63        # ps ax | grep swatch
64
65        Find the process ID (the number on the left), and run kill on it:
66
67        # kill PID_OF_SWATCH
68
69        Restart swatch
70
71        # /usr/local/bin/swatch -c /usr/local/etc/swatch.conf --tail-file=/etc/namedb/log/general --daemon
72
73        Note: we ask SWATCH to look at the /etc/namedb/log/general file now,
74        since BIND logs failed attempts to AXFR in the security category, and
75        we have configued bind to log the security category in the general log
76        file.
77
787. Re-run the zone transfer as in step 4 (from another machine) and see if
79   you receive a mail when that happens.
80
81   Try again 2 more times to do AXFR within a minute.
82
83   Q: How many mails did you receive ?
84
85
86KEY based security
87------------------
88
89Instead of using IP addresses, we'll now be using cryptographic keys
90to authenticate zone transfer -- this uses TSIG, a mechanism by which
91the communication between the master and slave server will be authenticated
92using this key.
93
941. Run:
95
96# cd /tmp/
97# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST mydomain.key
98
99        You will see something like:
100
101Kmydomain.key.+157+32373   (the last number will change)
102
103        Two files have been created:
104
105        # ls -l K*
106
107Kmydomain.key.+157+32373.public
108Kmydomain.key.+157+32373.private
109
1102. View the contents of the private key
111
112        # cat Kmydomain.key.+157+32373.private
113
114        You will see something similar:
115
116Private-key-format: v1.2
117Algorithm: 157 (HMAC_MD5)
118Key: tHTRSKKrmyGmPnzNCf2IRA==
119Bits: AAA=
120
121        ... the "Key:" is the important here, so copy "tHTRSKKrmyGmPnzNCf2IRA=="
122        (not THIS one, the one in YOUR file :)
123
1243.  Modify your named.conf
125
126        # cd /etc/namedb/
127
128        Edit the file, and change the allow-transfer statement, so that it looks
129        like this:
130
131options {
132        ...
133        allow-transfer { 127.0.0.1; ::1; };  // myslaves is removed!
134        ...
135};
136
137        Note: We have removed "myslaves"
138
139        Now, after the options (or at the bottom of the file), add a new
140        declaration for the key
141
142key "mydomain-key" {
143        algorithm hmac-md5;
144        secret "tHTRSKKrmyGmPnzNCf2IRA==";
145};
146
147        Change the definition for your zone:
148
149zone "MYTLD" {
150        zone "mytld" { type master; ... };
151
152        allow-transfer { key mydomain-key; };   // <-- Add this!
153};
154
155As you can see above, we've added an "allow-transfer" statement
156allowing transfer of the zone for holders of the "mydomain-key".
157
158Note that the allow-transfer is now placed INSIDE the zone definition,
159and not globally inside the options section -- BIND can control zone
160transfer either globally, or by zone.
161
1624. Restart named
163
164        # /etc/rc.d/named restart
165
1665. Try and make a zone transfer from ANOTER machine -- ask your neighbors:
167
168        # dig @10.10.XX.1 MYTLD axfr
169
170        Look at /etc/namedb/logs/general and /etc/namedb/logs/transfers
171
172        Q: What do you notice ?
173
1746. Try again with the key:
175
176        # dig @10.10.XX.1 axfr mydomain.dns -y mydomain-key:tHTRSKKrmyGmPnzNCf2IRA==
177
178        Q: what happens now ?
179
180        Check the logs again, especially /etc/namedb/log/transfers
181
182
1837. On your slave:
184
185        Start by deleting the copy of the slave zone:
186
187        - Remove the zone from /etc/namedb/slave/MYTLD -- remember, this
188          is on the machine of your SLAVE partner
189
190        # rm /etc/namedb/slave/MYTLD
191
192        - Restart named
193       
194        # /etc/rc.d/named restart
195
196        Check that the zone is gone AND that the slave wasn't able to reload it.
197
198        Q: What do you see in the MASTER logs (transfers and general) ?
199        Q: What do you see in the SLAVE logs (transfers and general) ?
200
2018. Still on the SLAVE:
202
203Find the statement for the zone:
204
205zone "MYTLD" {
206        type slave;
207        masters { 10.10.XX.1; };
208        file "slave/mydomain.dns";
209};
210
211... and add the key, and a statement to tell which key to use
212when talking to "10.10.XXX.1" (the master):
213
214key mydomain-key {
215        algorithm hmac-md5;
216        secret "tHTRSKKrmyGmPnzNCf2IRA==";
217};
218server 10.10.XX.1 {
219        keys { mydomain-key; };
220};
221
2229. Restart named
223
224        # /etc/rc.d/named restart
225
226        On the SLAVE server:
227
228        Q: Is the zone "MYTLD" back in the slave/ directory ?
229        Q: What do you see in the MASTER logs (transfers and general) ?
230        Q: What do you see in the SLAVE logs (transfers and general) ?
231
232        Can you see a general benefit from using keys instead of IP ACLs ?
233
23410. Now, do the same for your NSD "auth" server
235
236        ... since you have disabled IP ACLs, your AUTH NSD server is not
237        able to get the zone!
238
239        On AUTH, using the examples in /usr/local/etc/nsd/nsd.conf.sample, near
240        the end, update the "zone:" definition for MYTLD, so that it now uses
241        a KEY instead of NOKEY to transfer the zone from your MASTER.
242
243        After, you will need to run "nsdc restart".  Does the zone get
244        transferred ?  Remember to check the logs on the MASTER as well!