1 / 13

Advanced DNS and DHCP Management: Best Practices and Security Techniques

This module delves into advanced DNS and DHCP topics, covering Dynamic DNS (DDNS) configuration for auto-updating zones, and security measures like allow-update and update-policy using cryptographic methods. It addresses the crucial interaction between Active Directory (AD) and BIND9 DNS, detailing security overview and best practices for managing authoritative servers, zone transfers, and recursion controls. The module emphasizes the importance of closed resolvers to prevent DDoS amplification attacks and provides insights into DNS Blacklist (DNSBL) and Whitelist functionalities.

zia-beck
Télécharger la présentation

Advanced DNS and DHCP Management: Best Practices and Security Techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Module 10 Advanced Topics

  2. DNS and DHCP • DHCP can be configured to auto-update (using DDNS) the forward and reverse map zones • Can be secured using allow-update (IP and crypto) or update-policy (crypto only) • Crypto may use TSIG or SIG(0) • Used by AD extensively • Interaction between AD and BIND9

  3. DNS - DHCP

  4. DNS - Security Overview

  5. DNS and Security • Local (1) is admin based • Variety of sysadmin techniques (permissions) • Chroot (jail) • DDNS (2) - inhibit or use IP/Crypto controls • Zone Transfers (3) - inhibit or use IP/Crypto controls • Resolver (4) - DNSSEC - viable • Resolver (5) - DNSSEC - not viable

  6. Open vs Closed Resolvers • Allows anyone, anywhere to query your resolver • DDoS amplification attacks • recursion yes; defaulted • Big Deal • ~50% of resolvers were open • BIND9.4 partial close using allow-query-cache {localnets; localhost;}; • Always use allow-recursion with explicit list (use ACL clause for big lists)

  7. Closing DNS - Techniques # If authoritative servers (master/slave) # inhibit all recursion recursion no; # if master/slave with caching (hybrid) or caching only (resolver) # use an appropriate local address scope statement # to limit recursion requests to local users allow-recursion {192.168.2.0/24;}; // change IPs as required # OR if the DNS server's IPs and netmasks cover the whole # local network you can use: allow-recursion {"localnets";”localhost”;}; # personal DNS # hard limits on reading listen-on {127.0.0.1;}; // or listen-on {localhost;}; listen-on-v6 {::1;}; // OR listen-on-v6 {localhost;}; # OR allow-recursion {"localhost";};

  8. DNS - Uses • DNSBL - DNS Blacklist • Used for email blacklists • Whitelists • ENUM • Maps E.164 (Telephone numbers) • Generic Principle of adding some (processed) name to a base name to get a DNS response

  9. DNS - DNSBL $TTL 2d # default RR TTL $ORIGIN blacklist.example.com. IN SOA ns1.example.com. hostmaster.example.com.( 2003080800 ; se = serial number 3h ; ref = refresh 15m ; ret = update retry 3w ; ex = expiry 3h ; min = minimum ) IN NS ns1.example.com. IN NS ns2.example.com. # black list records - uses origin substitution rule (order unimportant) 2.0.0.127 IN A 127.0.0.2 # allows testing # black list RRs 135.2.168.192 IN A 127.0.0.2 # or some result code address IN TXT "Optional-explanation for black listing" # the above entries expands to 135.2.168.192.blacklist.example.com ... 135.17.168.192 IN A 127.0.0.2 # generic list ...

  10. DNS - Other Lists $TTL 2d # default RR TTL $ORIGIN whitelist.example.com. ... # white list records - using origin substitution rule # order not important other than for local usage reasons # normal whitelist RRs # by convention this address should be listed to allow for external testing 2.0.0.127 IN A 127.0.0.2 # black list RRs 135.2.168.192 IN A 127.0.0.2 # or some result code address IN TXT "Optional-explanation for listing" # the above entries expand to 135.2.168.192.blacklist.example.com ... 135.17.168.192 IN A 127.0.0.2 # generic list ... # name based RRs for white listing friend.com IN A 127.0.0.1 # all domain email addresses IN TXT "Optional-explanation for listing" # expands to friend.com.whitelist.example.com joe.my.my IN A 127.0.0.2 # single address # expands to joe.my.my.whitelist.example.com ...

  11. DNS - Best Practices • Don't mix Authoritative and caching • practical only for big sites • Configurations • document config file changes • don't assume defaults - be explicit • Closed resolvers • Zone files • document changes • use $ORIGIN (with dot!) • Be consistent with names (w/o $ORIGIN)

  12. DNS Resources • http://www.zytrax.com/books/dns • http://www.isc.org (BIND 9) • www.dnssec-deployment.org • www.dnssec.net (info portal) • Pro DNS and BIND!

  13. Quick Quiz • Can DHCP be used to update the reverse map file? • Name at least two security threats. • Why is an OPEN DNS a Bad Thing? • Name at least one other use for DNS. • Why is $ORIGIN important?

More Related