Advanced – Module 2

1. Advanced – Module 2 DNS Security (DNSSEC) Lecturer: Ron Aitchison

2. Course Objectives • Threat Analysis • Cryptographic Processes • Secure Zone Transfers • Secure DDNS • Secure Zones • Zone Maintenance • Understand when to use security

3. DNS Threat Analysis • Correct Data Gets to the requester • Correct Data sent from Authoritative DNS • Correct Data received at Requester • Remote Cache (resolver) • User resolver

4. Risk Overview

5. DNS Security Solutions • Zone Files (1) – File corruption (Admin) • Dynamic Updates(2) – Limit sources (IP spoofing) (TSIG, SIG0) • Zone Transfers(3) – Limit sources (IP spoofing) (TSIG) • Cache (Resolver) transfer(4) – Data integrity (DNSSEC) • Stub-Resolver transfer(5) – Data integrity (DNSSEC)

6. DNSSEC • The term DNSSEC is widely, and confusingly, used to describe three separate process • Securing zone transfers (RFCs 2845, 2931, 2930)‏ • Securing DDNS operations (RFC 3007)‏ • Zone integrity (signing) (RFCs 4033, 4034, 4035)‏ • Each of these processes solves a unique problem and has different characteristics, methods and RRs

7. DNS Admin Security • Update Software (track known exploits – evaluate impact) • Deployment checklist/procedure • Limit Functionality • Defensive configuration • run BIND with limited permissions • Verify accessed file permissions • Hide the master DNS (Stealth) • Change port numbers or host interfaces • Run BIND in chroot jail

8. Hidden Master

9. DNS Stealth (DMZ)

10. DNS Firewalls

11. DNS - External View • Internal DNS forwards all recursive queries to external DNS • May use a unique port number • Internal DNS has only results cache (minimum cache pollution) • External DNS has internal view (limited by match-client) which supports recursion • All others access supports Authoritative only

12. Securing Zone Transfer • allow-transfer {x.x.x.x;}; limits sources • Cryptographic security uses TSIG • Uses MAC with symmetric key....

13. Cryptographic Processes

14. DNSSEC - Cryptography • All DNSSEC processes use modern cryptographic techniques • Cryptography can be used for three functions • Confidentiality • Authentication • Data integrity • DNSSEC standards use only Authentication and Data Integrity

15. Data (Zone) Integrity • Proving that the data received was the data that was sent • Proving that the data came from the correct source • Proving a name is not present (NXDOMAIN) – Proof-of-non-existence (PNE)

16. Authentication • Proving that one or both parties to a communications session are who they say there are. • Methods • Hardware based (biometrics)‏ • Kerberos • Keys and certificates

17. Cryptographic Overview • Modern Techniques use keys – the algorithms are public • Not provably secure – repeated attacks by good guys (and bad guys) to find weaknesses • Algorithms are Computationally Infeasible – which changes over time • Two classes - Asymmetric (public key) and Symmetric (shared secret)

18. Symmetric Cryptography

19. Symmetric Cryptography • Single Key (shared-secret)‏ • Secure process distributes key to all parties before communications (mail, fax, sftp, email (pgp))‏ • Algorithms – DES, AES, IDEA, RC4 • Key sizes 64 – 192 bits • Used in DNS to secure zone transfers and DDNS (TSIG)‏ • Weakness – any party may be compromised

20. Asymmetric Cryptography Confidential – Host2 sends to Host1

21. Asymmetric Cryptography Digital Signature of Host1

22. Asymmetric Cryptography • Public-Private keys • Public key – trusted distribution but public data • Computationally infeasible to create private key from public key • Algorithms – RSA, DSA, elliptic curves • Key sizes 512 – 4096 • DNS use – zone transfers, DDNS, zone signing • Weakness – genuine public key?

23. Authentication and Integrity • DNS requires only Authentication and Integrity • Cryptographic techniques use serious processor resources – especially asymmetric techniques • Message Digests (one-way hash) used to reduce load (MD5, SHA)‏ • Symmetric cryptography – Message Authentication Code (MAC)‏ • Asymmetric cryptography – Digital signatures

24. Message Digests

25. Message Authentication Code (HMAC)

26. Digital Signatures

27. Securing Zone Transfer • allow-transfer {x.x.x.x;}; limits sources • Cryptographic security uses TSIG • Uses MAC with symmetric key....

28. Securing Zone Transfer

29. Securing Zone Transfer • Uses MAC with Symmetric Key • key generated with dnssec-keygen utility • can use MAC of HMAC-MD5, GSS-TSIG, HMAC-SHA1, HMAC-SHA256 and others • Generates two files • .key KEY RR (not used - delete) • .private – contains a secret key which is edited into a key clause used in named.conf • key clause is included in named.conf by both parties • each party has a server clause identifying that communication with the other will use a key • an allow-transfer statement references the use of keys

30. Securing Zone Transfers // named.conf example.com master fragment ... options { .... directory "/var/named"; dnssec-enable yes; .... }; // include the key clause for example.com key name include "keys/example.com.key"; // include the key clause // server clause references the key clause included above server 10.1.2.3 { keys {"example.com";}; // name used in key clause }; .... zone "example.com" in{ type master; file "master.example.com"; // allow transfer only if key (TSIG) present allow-transfer {key "example.com";}; }; ....

31. Key Clause # .private file contents Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: JuxDyYXIJhAia5WQe9oqUA== Bits: AAA= # edited into key clause for include into named.conf key "example.com" ( alogorithm hmac-md5; secret JuxDyYXIJhAia5WQe9oqUA==; };

32. Securing DDNS • allow-update with IP address • standard BIND utility nsupdate • feature used by users and DHCP to auto-update forward and reverse maps (Windows AD) • Crypto uses update-policy statement with either: • TSIG (same config as for zone transfers except nsupdate needs KEY RR both .private and .key files moved) • SIG(0) – public key security (RSA-SHA1, DSA etc.) • both cases keys generated with dnssec-keygen • same keys can be used for TSIG zone transfer and DDNS – but not good policy

33. Securing DDNS - TSIG options { .... directory "/var/named"; dnssec-enable yes; .... }; include "keys/example.com.key"; // include the key clause server 10.1.2.3 { keys {"example.com";}; // name used in key clause }; .... zone "example.com" in{ type master; file "master.example.com"; allow-update {key "example.com";}; }; .... zone "example.net" in{ type master; file "master.example.net"; update-policy { grant example.com subdomain example.net ANY;}; update-policy { grant * self * A;}; update-policy { grant fred.example.net name example.net MX;}; }; .... nsupdate -k Kexample.com.+157+31313.private

34. Securing DDNS - SIG(0) options { .... directory "/var/named"; dnssec-enable yes; .... }; .... zone "example.com" IN{ type master; file master.example.com; update-policy {grant update.example.com subdomain example.com ANY}; };

35. Securing DDNS - SIG(0) • Public Key is stored in the zone file being updated • Private key is used by nsupdate ; example.com zone file fragment $TTL 2d ; zone TTL default of 2 days $ORIGIN example.com. .... $INCLUDE keys/Kupdate.example.com.+001+00706.key ;DDNS key .... nsupdate -k Kexample.com.+001+00706.private

36. Zone Integrity

37. Cache Poisoning Effect

38. Cache Poisoning Effect

39. SSL Protection

40. DNSSEC - Cache Poisoning

41. DNSSEC – Zone Integrity • DNSSEC (RFCs 4033, 4034, 4035)‏ • Asymmetric (Public Key) process • Assuming cryptographically secured - Signed -Zone • A Security – Aware DNS can: • Prove data came from the source (authentication)‏ • Actual data was sent by source (data integrity)‏ • Prove an NXDOMAIN response is correct (proof of non-existence PNE)

42. DNSSEC – Zone Integrity • Zones are cryptographically signed using asymmetric (public) keys (DNSKEY RRs) • Two keys (conceptual but best practice) • Key Signing Key (KSK) • Zone signing Key (ZSK) • Zone Record Sets are signed (RRSIG RR created) using ZSK (Digital Signature) • DNSKEY RRs are signed (RRSIG RR created) using KSK (Digital Signature) • Zone Record Sets are chained (NSEC RRs) • Delegations from parents are chained (DS RRs) using KSK Fingerprint (Secure Delegation)

43. DNSSEC – Zone Signing

44. DNSSEC – Chain of Trust • How do we know if we can trust the DS RR from .com? • We cannot trust anything from an unsigned zone • We cannot trust anything whose signature we cannot verify • chicken-and-egg situation • Create a Trust Anchor (Public Key of a signed zone) • Distribute the Trust Anchor by a trusted out-of-band process • Create a Chain of Trust

45. DNSSEC – Trust Anchors

46. DNSSEC – Trust Anchors

47. DNSSEC – Trust Anchors

48. Zone Signing – Trust Anchors • Security-Aware Resolvers have a trust anchor to a Secure Entry Point (SEP) • Public Key configured into BIND using trusted-keys clause • Public Key obtained via out-of-band process – prevents chicken-and-egg and spoof attacks • May be a large number of trust anchors – Islands of Security

49. Zone Signing – Chains of Trust

50. DNSSEC – Islands of Trust