BIND TRANSFER SECURITY ---------------------- We're going to limit zone transfer of your zones so that only your secondary/slave nameservers are allowed to request copies of the zones. Note: if the instructor group (for example, group 0) is providing slave (secondary) service for your domain, then the "partner" referred below is the instructor responsible for group 0. ACL based security ------------------ To start with, we'll enable IP based ACLs -- on the AUTH1 host: 1. Start by editing /etc/namedb/named.conf, and in the "options" section, let's define who is allowed to transfer your zone. allow-transfer { 127.0.0.1; ::1; YOUR_OWN_IP; myslaves; }; ... replace "YOUR_OWN_IP" with the IP of your machine :) Now we need to define the ACL "myslaves". To do so, AFTER the options section (find the '};' symbol at the end of the section), add something similar to this: (If the slave for your "MYTLD" domain is auth1.grp25, for example) acl myslaves { 10.10.25.1; }; // ACL with IP of Group25 master This means "myslaves is an ACL consisting of the IP 10.10.25.1. (this would be 10.10.0.2 if the instructor is providing slave service) If you are also running NSD, you will need to add the IP of your secondary on your network to the ACL (this only applies if you have configured NSD as a secondary server in your group. If not, just skip this) acl myslaves { 10.10.25.1; 10.10.Z.2; }; // ACL with IP of Group25 master and your NSD secondary 10.10.25.2. NOTE: remember to enter the correct values! You must write the IP of the machine who is your secondary in the class - remember ! 2. Restart named $ sudo service named restart 3. Make sure that you didn't break the zone transfer, by asking your slave partner to run a zone transfer against YOUR machine. From their server: $ dig @auth1.grpX.dns.nsrc.org MYTLD axfr Make sure that it still works. (X = you) 4. Now try and ask someone else in the class whose server is NOT in the ACL to try the same axfr command as above. Q: Do they succeed ? Q: What do you see in the logs in /etc/namedb/log/general ? What do you see in the logs in /etc/namedb/log/transfers ? TSIG KEY based security ----------------------- Instead of using IP addresses, we'll now be using cryptographic keys to authenticate zone transfer -- this uses TSIG, a mechanism by which the communication between the master and slave server will be authenticated using this key. 1. Run: $ dd if=/dev/random of=/dev/stdout count=1 bs=32 | openssl enc -base64 You will see something similar to this: 1+0 records in 1+0 records out 32 bytes transferred in 0.000034 secs (945195 bytes/sec) q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ= ... the last line is the important bit here, so copy "q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ=", but of course not the one above. We will use this in the next steps. 2. Modify your named.conf $ cd /etc/namedb/ Edit the file, and change the allow-transfer statement, so that it looks like this: options { ... allow-transfer { 127.0.0.1; ::1; }; // myslaves is removed! ... }; Note: We have removed "myslaves" Now, after the options (or at the bottom of the file), add a new declaration for the key key "mytld-key" { algorithm hmac-sha256; secret "q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ="; // Your REAL key goes here! }; Don't forget to replace "mytld" by the name of your domain! Change the definition for your zone: zone "MYTLD" { type master; file "/etc/namedb/master/mytld"; allow-transfer { key mytld-key; }; // <-- Add this! }; As you can see above, we've added an "allow-transfer" statement allowing transfer of the zone for holders of the "mytld-key". Note: the allow-transfer is now placed INSIDE the zone definition, and not globally inside the options section -- BIND can control zone transfer either globally, or by zone. We could have chosen to allow transfers GLOBALLY (for all zones), by leaving the allow-transfer statement in the main "options" section. 3. Restart named $ sudo service named restart 4. Try and make a zone transfer from ANOTHER machine -- ask your neighbors to do: $ dig @10.10.XX.1 MYTLD axfr Look at /etc/namedb/log/general and /etc/namedb/log/transfers Q: What do you notice ? 5. Then, ask them to try again with the key: $ dig @10.10.99.1 axfr MYTLD -y hmac-sha256:mytld-key:q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ= Q: what happens now ? Check the logs again, especially /etc/namedb/log/transfers 6. On your partner's SLAVE host (your secondary - again, this may be the instructor if they are providing secondary service for your domain). Start by asking your partner to delete their copy of your zone: - Have them remove the zone from /etc/namedb/slave/MYTLD -- remember, this is on the machine of your SLAVE partner: $ sudo rm /etc/namedb/slave/MYTLD - Ask them to restart named $ sudo service named restart Check with them that the zone is gone AND that their server wasn't able to reload it. Q: What do you see in the MASTER (auth1) logs (transfers and general) ? Q: What do you see in the SLAVE logs (transfers and general) ? 7. Still on the SLAVE (if the instructor is providing secondary service, they will perform this part) Find the statement for the zone: zone "MYTLD" { type slave; masters { 10.10.XX.1; }; file "slave/mytld"; }; ... and add the key, and a statement to tell which key to use when talking to "10.10.XX.1" (the master): key mytld-key { algorithm hmac-256; secret "q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ="; }; server 10.10.XX.1 { // here you put the IP of YOUR master keys { mytld-key; }; }; 8. Restart named $ sudo service named restart On the SLAVE server: Q: Is the zone "MYTLD" back in the slave/ directory ? Q: What do you see in the SLAVE logs (transfers and general) ? On the MASTER server: Q: What do you see in the MASTER (auth1) logs (transfers and general) ? Can you see a general benefit from using keys instead of IP ACLs ? Optional section if you are running a secondary yourself: --------------------------------------------------------- 9. Now, do the same for your NSD "auth2" server ... since you have disabled IP ACLs, your AUTH NSD server is not able to get the zone! Edit nsd.conf on AUTH2 and look at the comments inside nsd.conf on how to specify the key format in NSD for zone transfers. Update update the "zone:" definition for MYTLD, so that it now uses a KEY instead of NOKEY to transfer the zone from your MASTER (auth1). - find the line: request-xfr: AXFR 10.10.99.1 NOKEY - and make it: request-xfr: AXFR 10.10.99.1 mytld-key - add: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - key: name: "mytld-key" algorithm: hmac-sha256 secret: "q8y9VrmVTclnwL1R8eqVePxokn9OwJUpLYNUNWenovQ=" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - save and exit the file. After, you will need to restart nsd: # kill `cat /etc/namedb/master/nsd.pid` # nsd -c /usr/local/etc/nsd/nsd.conf Does the zone get transferred to AUTH2? Remember to check the logs! Optional section if you are using Swatch to monitor the logs: 10. If you set up Swatch in a previous exercise, make it complain if it sees a forbidden zone transfer: Edit /usr/local/etc/swatch.conf, and add a new section -- remember to use TAB for the space at the beginning of the lines: - - - - - - - - - - - - - - - cut below - - - - - - - - - - - - - - watchfor /client ([0-9.:]+)\D\d+: zone transfer '(.*)\/.XFR\/IN' denied$/ mail=%USER%,subject=Denied AXFR for zone '$2' from $1 threshold type=limit,count=1,seconds=600 - - - - - - - - - - - - - - - cut above - - - - - - - - - - - - - - 11. Kill Swatch $ ps ax | grep swatch Find the process ID (the number on the left), and run kill on it: $ sudo kill PID_OF_SWATCH Restart swatch (switch to root temporarily using the sudo -s command) $ sudo -s # /usr/local/bin/swatch -c /usr/local/etc/swatch.conf --tail-file=/etc/namedb/log/general --daemon # exit $ Note: Why are we telling swatch to look at the "general" log file ? If you remember from the previous logging lab, we configured BIND to log the security category into the general channel definition. Therefore, we need to monitor the /etc/namedb/log/general file. 12. Re-run the zone transfer as in step 4 (from another machine) and see if the %USER% user receives a mail when you test: $ mutt -f /var/mail/%USER% Try again 2 more times to do AXFR within a minute. Q: How many mails did you receive? Why?