Download to read offline
Uploaded bySam Bowne
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
Chapter 5 discusses strategies for preventing DNS service disruptions, emphasizing the architecture of distributed systems and various types of DoS protection. It covers DNS security measures, including DNSSEC for data integrity and authenticity, and techniques for managing server failover and monitoring. The chapter also highlights the importance of regular backups and the use of firewalls and scrubbers to protect against attacks.
More Related Content
![Understanding and Deploying DNSSEC, by Champika Wijayatunga [APRICOT 2015]](https://cdn.slidesharecdn.com/ss_thumbnails/dnssec-final1425360815-150318234332-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
- 1. Ch 5: Prevention,Protection and Mitigation of DNS Service Disruption Updated 11-1-16
- 2. Prevention of DNSService Disruption
- 3. Architecture to ResistDoS • Authoritative servers typically need to accept queries from every device on the Internet • A network distributed system places authoritative servers in multiple networks – Small scale: different subnets with different gateways – Large scale: different Autonomous Systems (AS) • Geographically distributed systems are in different regions or countries
- 4. Types of DoSProtection • Host authoritative DNS servers at an ISP or Content Distribution Network (CDN) • Purchase caching acceleration service and delegate DNS resolution with a CNAME record – Risky because the authoritative server is still needed to provide the CNAME record • Direct delegation from the TLD to the ISP's or CDN's authoritative servers • Better, like Cloudflare
- 5. Caching Acceleration Client SOA DNS Server Whereis example.com? example.com is a CNAME for x99.cache.com Where is x99.cache.com? x99.cache.com is at 1.2.3.4 Caching Acceleration DNS Server
- 6. Project 6x • Protectinga domain with Cloudflare
- 7. Anycast • Multiple geographicallyseparated servers use the same IP address • This spreads attacks over the whole network • Used by the root DNS servers and Cloudflare
- 8.
- 9. Partially Hidden AuthoritativeServers • Some of the authoritative servers are placed behind the firewalls of large ISPs or other organizations • They act as SOA for only the users of the private network (using BGP) • They are slave servers, updated from the master servers • This is how UltraDNS works
- 11. UltraDNS DNS Shield •Link Ch 5a
- 12. Software • Whatever youuse, keep it updated • Bind – The standard • djbdns – Intended to be more secure than bind, but no longer centrally maintained (links Ch 5b) • There are many others (link Ch 5c)
- 13.
- 14. Purpose of DNSSEC •Ensure authenticity of data origin • And integrity of data received by a resolver from an authoritative DNS server • Done by signing Resource Record (RR) sets – With a private key – And including the signature (RRSIG) with the record
- 15. Chain of Trust •Resolver can verify the RRSIG with the server's Public Key – Published by the server in its zone file (DNSKEY) – Vouched for by the parent zone – Vouched for by its parent... – Unbroken chain of trust up to the root zone • Only works if all higher-level zones are signed
- 16. DNSSEC Chain ofTrust Root key self-signed .org key signed by root ietf.org key signed by .org
- 17. Detailed Chain ofTrust • Root (.) now also has RRSIG • Link Ch 5d
- 18. Root Signed in2010 • Link Ch 5e
- 19. Demonstration • dig any. – Shows RRSIG and DNSKEY records for the root • dig ds org. • dig dnskey org. • dig rrsig org. • dig any ietf.org
- 20.
- 21.
- 22.
- 23. DNSSEC of Top-LevelDomains Nov. 2013 Nov. 2016 • Link Ch 5f
- 24. DNSSEC Validator Browser Extension •Link Ch 5j
- 25. DNS-based Authentication ofNamed Entities (DANE) • Uses DNSSEC to validate SSL certificates, not Certificate Authorities • Link Ch 5k
- 26. DNSSEC Issues • Protocolstill changing • Only secures record to resolver, not traffic from resolver to client • Another reason to disallow external DNS servers like 8.8.8.8 – To keep all resolver traffic local
- 27. Authenticated Denial ofExistence • There is no fred.ccsf.edu – Three systems to prove that • NXT record (1999); insecure & replaced by • NSEC record (2005); insecure & replaced by • NSEC3 record (2008) • All incompatible with one another
- 28. Transaction Signatures: TSIG •Maintains integrity of DNS messages between two severs • Cryptographically signs messages with TSIG – Calculates a Message Authentication Code – Encrypts it with a secret key – Key shared by the two end-nodes – Includes the time, to prevent replay attacks – TSIG expires after the "time fudge factor" • You must generate secret key and securely transmit it to the other server
- 29. Transaction Signatures: SIG(0) •Alternative signature method using public key cryptography • Public key stored in a KEY record
- 30. Transaction Keys (TKEY) •Establishes a shared secret using – Diffie-Hellman key exchange, or – General Security Service API (based on Kerberos) • TKEY record contains the keying material required • Vulnerable to man-in-the-middle attacks – Should be secured with SIG(0) (shared secret)
- 31. Software Diversification • Mostroot servers use Bind • K and H servers use NSD from NLnetlabs
- 32. Master-Slave Setup • Changesare made at the master • Replicate to the slaves • Slaves can be masters of lower- level slaves
- 33. Configuring a SlaveServer in Bind
- 34. Limitation of 512Bytes • Running many slave servers is good for fault-tolerance – But they all need to be listed as authoritative servers in DNS responses – Limited to 512 bytes in legacy systems • Failover via multiple NS records is slow – Requires several seconds for timeout of a bad server
- 35. CCSF.EDU has 4NS Records on 4-28-15
- 36. Automatic Failover • Use aload balancer • Appears to be a single server to external nodes
- 37. Protection of DNSService
- 38. Firewalls, IDS/IPS • Runon hardened systems • Port 53 UDP/TCP open • Management ports only open to internal hosts • IDS/IPS blocks known attacks by signatures • Firewalls limit traffic with Access Control Lists (ACLs) • Older firewalls limit DNS packets to 512 bytes – Now obsolete; EDNS allows UDP packets up to 4096 bytes (link Ch 5i)
- 39. Scrubbers • DDoS attackslook like many legitimate customers • Scrubbers block packets that meet DDoS criteria – Not usually fully automated • When under attack, BGP updates are sent to redirect traffic to the scrubbers
- 40.
- 41.
- 42.
- 43. Monitoring • Send periodicprobes from multiple ISPs and geographic regions – Such as DNS requests – Send directly to monitored servers – Verify that responses are accurate
- 44. Backups • Regular backupsof the DNS servers are essential • Can be full or incremental • Could back up whole OS, or just DNS configuration files • Cloud DNS servers must be backed up too – Using backup tools appropriate for the cloud service • MUST TEST YOUR BACKUPS
- 45. Slow DNS Response •If a DNS server is down, it slows responses • Because the dead server must time out before another server is queries • Remove NS and A records for failed server to avoid this