1 / 82

Advanced – Module 2

Advanced – Module 2. DNS Security (DNSSEC). Lecturer: Ron Aitchison. Course Objectives. Threat Analysis Cryptographic Processes Secure Zone Transfers Secure DDNS Secure Zones Zone Maintenance Understand when to use security. DNS Threat Analysis. Correct Data Gets to the requester

erna
Download Presentation

Advanced – Module 2

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. 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

More Related