Track2Agenda: 03-dns-acl-tsig-transfer-security.txt

File 03-dns-acl-tsig-transfer-security.txt, 8.2 KB (added by Andy Linton, 6 years ago)
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
8Note: if the instructor group (for example, group 0) is providing slave
9(secondary) service for your domain, then the "partner" referred below
10is the instructor responsible for group 0.
11
12ACL based security
13------------------
14
15To start with, we'll enable IP based ACLs -- on the AUTH1 host:
16
171. Start by editing /etc/namedb/named.conf, and in the "options" section,
18   let's define who is allowed to transfer your zone.
19
20   allow-transfer { 127.0.0.1; ::1; YOUR_OWN_IP; myslaves; };
21
22   ... replace "YOUR_OWN_IP" with the IP of your machine :)
23
24   Now we need to define the ACL "myslaves".  To do so, AFTER the options
25   section (find the '};' symbol at the end of the section), add something
26   similar to this:
27
28   (If the slave for your "MYTLD" domain is auth1.grp25, for example)
29
30acl myslaves { 10.10.25.1; }; // ACL with IP of Group25 master
31
32        This means "myslaves is an ACL consisting of the IP 10.10.25.1.
33
34
35        If you are also running NSD, you will need to add the IP of your secondary
36        on your network to the ACL (this only applies if you have configured NSD as
37        a secondary server in your group. If not, just skip this)
38
39acl myslaves { 10.10.25.1; 10.10.X.2; }; // ACL with IP of Group25 master
40        and your NSD secondary 10.10.25.2.
41
42        NOTE: remember to enter the correct values! You must write the IP
43        of the machine who is your secondary in the class - remember !
44
452. Restart named
46
47        $ sudo service named restart
48
493. Make sure that you didn't break the zone transfer, by asking your
50   slave partner to run a zone transfer against YOUR machine.
51
52   From their server:
53
54   $ dig @auth1.grpX.dns.nsrc.org MYTLD axfr
55
56   Make sure that it still works.
57
584. Now try and ask someone else in the class whose server is NOT in the
59   ACL to try the same axfr command as above.
60
61   Q: Do they succeed ?
62
63   Q: What do you see in the logs in /etc/namedb/log/general ?
64      What do you see in the logs in /etc/namedb/log/transfers ?
65
66TSIG KEY based security
67-----------------------
68
69Instead of using IP addresses, we'll now be using cryptographic keys
70to authenticate zone transfer -- this uses TSIG, a mechanism by which
71the communication between the master and slave server will be authenticated
72using this key.
73
741. Run:
75
76        $ cd /tmp/
77        $ sudo dnssec-keygen -a HMAC-MD5 -b 128 -n HOST mydomain.key
78
79        You will see something similar to this:
80
81Kmydomain.key.+157+32373   (the last number will change)
82
83        Two files have been created:
84
85        $ ls -l K*
86
87Kmydomain.key.+157+32373.key
88Kmydomain.key.+157+32373.private
89
902. View the contents of the private key
91
92        $ cat Kmydomain.key.+157+32373.private
93
94        You will see something similar to:
95
96Private-key-format: v1.2
97Algorithm: 157 (HMAC_MD5)
98Key: tHTRSKKrmyGmPnzNCf2IRA==
99Bits: AAA=
100
101        ... the "Key:" is the important bit here, so copy
102        "tHTRSKKrmyGmPnzNCf2IRA==", but of course not the one above, the one
103        in YOUR file :)
104
105        We will use this in the next steps.
106
1073.  Modify your named.conf
108
109        $ cd /etc/namedb/
110
111        Edit the file, and change the allow-transfer statement, so that it looks
112        like this:
113
114options {
115        ...
116        allow-transfer { 127.0.0.1; ::1; };  // myslaves is removed!
117        ...
118};
119
120        Note: We have removed "myslaves"
121
122        Now, after the options (or at the bottom of the file), add a new
123        declaration for the key
124
125key "mydomain-key" {
126        algorithm hmac-md5;
127        secret "tHTRSKKrmyGmPnzNCf2IRA=="; // Your REAL key goes here!
128
129};
130
131    Don't forget to replace "mydomain" by the name of your domain!
132
133        Change the definition for your zone:
134
135zone "MYTLD" {
136        type master;
137        file "/etc/namedb/master/mytld";
138
139        allow-transfer { key mydomain-key; };   // <-- Add this!
140};
141
142As you can see above, we've added an "allow-transfer" statement
143allowing transfer of the zone for holders of the "mydomain-key".
144
145Note: the allow-transfer is now placed INSIDE the zone definition,
146and not globally inside the options section -- BIND can control zone
147transfer either globally, or by zone. We could have chosen to allow
148transfers GLOBALLY (for all zones), by leaving the allow-transfer
149statement in the main "options" section.
150
1514. Restart named
152
153        $ sudo service named restart
154
1555. Try and make a zone transfer from ANOTHER machine -- ask your neighbors
156   to do:
157
158        $ dig @10.10.XX.1 MYTLD axfr
159
160        Look at /etc/namedb/log/general and /etc/namedb/log/transfers
161
162        Q: What do you notice ?
163
1646. Then, ask them to try again with the key:
165
166        $ dig @10.10.XX.1 axfr mydomain -y mydomain-key:tHTRSKKrmyGmPnzNCf2IRA==
167
168        Q: what happens now ?
169
170        Check the logs again, especially /etc/namedb/log/transfers
171
172
1737. On your partner's SLAVE host (your secondary - again, this may be
174   the instructor if they are providing secondary service for your
175   domain).
176
177        Start by asking your partner to delete their copy of your zone:
178
179        - Have them remove the zone from /etc/namedb/slave/MYTLD --
180          remember, this is on the machine of your SLAVE partner:
181
182        $ sudo rm /etc/namedb/slave/MYTLD
183
184        - Ask them to restart named
185       
186        $ sudo service named restart
187
188        Check with them that the zone is gone AND that their server wasn't
189        able to reload it.
190
191        Q: What do you see in the MASTER (auth1) logs (transfers and general) ?
192
193        Q: What do you see in the SLAVE logs (transfers and general) ?
194
1958. Still on the SLAVE (if the instructor is providing secondary service,
196   they will perform this part)
197
198Find the statement for the zone:
199
200zone "MYTLD" {
201        type slave;
202        masters { 10.10.XX.1; };
203        file "slave/mydomain.dns";
204};
205
206... and add the key, and a statement to tell which key to use
207when talking to "10.10.XX.1" (the master):
208
209key mydomain-key {
210        algorithm hmac-md5;
211        secret "tHTRSKKrmyGmPnzNCf2IRA==";
212};
213server 10.10.XX.1 {             // here you put the IP of YOUR master
214        keys { mydomain-key; };
215};
216
2179. Restart named
218
219        $ sudo service named restart
220
221        On the SLAVE server:
222
223        Q: Is the zone "MYTLD" back in the slave/ directory ?
224
225        Q: What do you see in the SLAVE logs (transfers and general) ?
226
227        On the MASTER server:
228
229        Q: What do you see in the MASTER (auth1) logs (transfers and general) ?
230
231        Can you see a general benefit from using keys instead of IP ACLs ?
232
233Optional section if you are running a secondary yourself:
234---------------------------------------------------------
235
23610. Now, do the same for your NSD "auth2" server
237
238        ... since you have disabled IP ACLs, your AUTH NSD server is not
239        able to get the zone!
240
241        Read the NSD manual page (man nsd.conf) if you are in doubt about
242        how to specify the key format in NSD for zone transfers. Update
243        update the "zone:" definition for MYTLD, so that it now uses
244        a KEY instead of NOKEY to transfer the zone from your MASTER (auth1).
245
246        After, you will need to run "nsdc restart".  Does the zone get
247        transferred ?  Remember to check the logs on the MASTER (auth1) as
248        well!
249
250Optional section if you are using Swatch to monitor the logs:
251
25211. If you set up Swatch in a previous exercise, make it complain if it
253   sees a forbidden zone transfer:
254
255        Edit /usr/local/etc/swatch.conf, and add a new section -- remember
256        to use TAB for the space at the beginning of the lines:
257
258- - - - - - - - - - - - - - -  cut below - - - - - - - - - - - - - -
259
260
261watchfor /client ([0-9.:]+)\D\d+: zone transfer '(.*)\/.XFR\/IN' denied$/
262        mail=%USER%,subject=Denied AXFR for zone '$2' from $1
263        threshold type=limit,count=1,seconds=600
264
265- - - - - - - - - - - - - - -  cut above - - - - - - - - - - - - - -
266
26712. Kill Swatch
268
269        $ ps ax | grep swatch
270
271        Find the process ID (the number on the left), and run kill on it:
272
273        $ sudo kill PID_OF_SWATCH
274
275        Restart swatch (switch to root temporarily using the sudo -s command)
276
277        $ sudo -s
278        # /usr/local/bin/swatch -c /usr/local/etc/swatch.conf --tail-file=/etc/namedb/log/general --daemon
279        # exit
280        $
281
282
283        Note: Why are we telling swatch to look at the "general" log file ?
284
285        If you remember from the previous logging lab, we configured BIND
286        to log the security category into the general channel definition.
287        Therefore, we need to monitor the /etc/namedb/log/general file.
288
28913. Re-run the zone transfer as in step 4 (from another machine) and see if
290    the %USER% user receives a mail when you test:
291
292        $ mutt -f /var/mail/%USER%
293
294   Try again 2 more times to do AXFR within a minute.
295
296   Q: How many mails did you receive? Why?
297