Agenda: dns-acl-tsig-transfer-security.txt

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