DNS Security. APNIC42 Colombo Sri Lanka 01 October 2016 Champika Wijayatunga

Size: px

Start display at page:

Download "DNS Security. APNIC42 Colombo Sri Lanka 01 October 2016 Champika Wijayatunga"

Ambrose Walton
6 years ago
Views:

1 DNS Security APNIC42 Colombo Sri Lanka 01 October 2016 Champika Wijayatunga

2 2 Brief Overview of DNS

3 What is the Domain Name System? A distributed database primarily used to obtain the IP address, a number, e.g., or fe80::226:bbff:fe11:5b32 that is associated with a user-friendly name ( Why do we need a DNS? It s hard to remember lots of four decimal numbers and it s impossibly hard to remember hexadecimal ones 3 3

4 History 1983 DNS was designed/invented by Paul Mockapetris (RFC882 & 883) 1984 Berkeley Internet Name Domain (BIND) Server developed Original Seven Generic TLDs (.com,.edu,.gov,.int,.mil,.net, and.org) 1985 First country codes assigned.us,.uk, and.il 1986.au,.de,.fi,.fr,.jp,.kr,.nl and.se 1987 RFC1034 (Considered the first full DNS Specification).. Country Code TLDs continue to be added Seven new TLDs added (.aero,.coop,.museum,.biz,.info,.name, and.pro) 2012 New round of applications for gtlds opened by ICANN 4

5 DNS Structure A domain is a node in the Internet name space A domain includes all its descendants Domains have names Top-level domain (TLD) names are generic or country-specific org TLD registries administer domains in the top-level TLD registries delegate labels beneath their top level delegation. gov com... AF... ZW icann ncfta irs ftc google msn co www ssac google Names in generic Top Level Domains Names in country-code TLDs 5

6 6 Root Server Operation

7 What do the Root-Server Operators do? Copy a very small database, the content of which is currently decided by IANA Put that database in the servers called Root Servers. Make the data available to all Internet users Work stems from a common agreement about the technical basis Everyone on the Internet should have equal access to the data The entire root system should be as stable and responsive as possible 7

8 What do the Root-Server Operators do not do? Interfere with the content of the database E.g. run the printing presses, but don't write the book Make policy decisions Who runs TLDs, or which domains are in them What systems TLDs use, or how they are connected to the Internet 8

9 Who are the Root Server operators? Not "one group", 12 distinct operators Operational and technical cooperation Participate in RSSAC as advisory body to ICANN High level of trust among operators Show up at many technical meetings, including IETF, ICANN, RIR meetings, NOG meetings, APRICOT etc. 9

10 How Secure are the Root Servers? Physically protected Tested operational procedures Experienced, professional, trusted staff Defense against major operational threat i.e. DDoS. Anycast Setting up identical copies of existing servers Same IP address Exactly the same data. Standard Internet routing will bring the queries to the nearest server Provides better service to more users. 10

11 Avoiding Common Misconceptions Not all internet traffic goes through a root server Not every DNS query is handled by a root server Root servers are not managed by volunteers as a hobby Professionally managed and well funded No single organization(neither commercial nor governmental) controls the entire system The "A" server is not special. Root Server Operators don't administrate the zone content They publish the IANA-approved data 11

Root Server Operation @ICANN + ICANN is the L-Root Operator + L-Root nodes keep Internet traffic local and resolve queries faster +

12 Root Server + ICANN is the L-Root Operator + L-Root nodes keep Internet traffic local and resolve queries faster + Make it easier to isolate attacks + Reduce congestion on international bandwidth + Redundancy and load balancing with multiple instances 12

13 L-Root presence 13

14 L-Root presence +Geographical diversity via Anycast +Around 160 dedicated servers +Presence on every continent +On normal basis 15 ~ 25 kqps +That is app 2 billion DNS queries a day +Interested in hosting a L-Root +Contact your ICANN Global Stakeholder Engagement Representative 14

15 DNS Servers DNS is a distributed database Types of DNS servers DNS Authoritative Primary (Master) Secondary (Slaves) DNS Resolver Recursive Cache Stub resolver 15 15

16 Operational elements of the DNS Authoritative Name Servers host zone data The set of DNS data that the registrant publishes Recursive Name Resolvers ( resolvers ) Systems that find answers to queries for DNS data Caching resolvers Recursive resolvers that not only find answers but also store answers locally for TTL period of time Client or stub resolvers Software in applications, mobile apps or operating systems that query the DNS and process responses 16

17 DNS Resolution Client Resolver (ISP) a.server.net Root Server l.root-servers.net :500:3::42 example.net nameserver.net nameserver 17 ns.example.net a.server.net

18 The Registry/Registrar Ecosystem 18 18

19 Domain Name Registration 101 How to register a domain: Choose a string e.g., example Visit a registrar to check string availability in a TLD Pay a fee to register the name Submit registration information Registrar and registries manage: string + TLD (managed in registry DB) Contacts, DNS (managed in Whois) DNS, status (managed in Whois DBs) Payment information 19

20 DNS Resource Records (RR) Unit of data in the Domain Name System Define attributes for a domain name Label TTL Class Type RData www 3600 IN A Most common types of RR o o o o o o A AAAA NS SOA MX CNAME 20

21 What is a DNS zone data? DNS zone data are hosted at an authoritative name server Each cut has zone data (root, TLD, delegations) DNS zones contain resource records that describe name servers, IP addresses, Hosts, Services Cryptographic keys & signatures Only US ASCII-7 letters, digits, and hyphens can be used as zone data. In a zone, IDNs strings begin with XN-- 21

Common DNS Resource Records Time to live (TTL) How long RRs are accurate Start of Authority (SOA) RR Source: zone created here Administrator s email Revision number of zone

22 Common DNS Resource Records Time to live (TTL) How long RRs are accurate Start of Authority (SOA) RR Source: zone created here Administrator s Revision number of zone file Name Server (NS) IN (Internet) Name of authoritative server Mail Server (MX) IN (Internet) Name of mail server Sender Policy Framework (TXT) Authorized mail senders 22

23 Common DNS Resource Records Name server address record NS1 (name server name) IN (Internet) A (IPv4) * AAAA is IPv6 IPv4 address ( ) Web server address record www (world wide web) IN (Internet) A (IPv4) * AAAA is IPv6 IPv4 address ( ) File server address record FTP (file transfer protocol) IN (Internet) CNAME means same address spaces and numbers as www 23

24 Places where DNS data lives Changes do not propagate instantly Might take up to refresh to get data from master Slave Upload of zone data is local policy Not going to net if TTL>0 Cache server Master Registry DB Slave server 24

25 25 DNS Security

26 DNS Data Flow MASTER zone file (text, DB) DATA STUB Resolver caching resolver (recursive) dynamic updates SLAVES SLAVES ATTACK VECTORS man in the middle cache poisoning modified data spoofing master (routing/dos) spoofed updates corrupted data 26 26

27 What is TSIG - Transaction Signature? A mechanism for protecting a message from a primary to secondary and vice versa A keyed-hash is applied (like a digital signature) so recipient can verify the message DNS question or answer & the timestamp Based on a shared secret - both sender and receiver are configured with it TSIG/TKEY uses DH, HMAC-MD5, HMAC- SHA1, HMAC-SHA224, HMAC-SHA512 among others 27

28 What is TSIG - Transaction Signature? TSIG (RFC 2845) authorizing dynamic updates & zone transfers authentication of caching forwarders Used in server configuration, not in zone file 28

29 TSIG Steps steps 1. Generate secret 2. Communicate secret 3. Configure servers 4. Test 29

30 TSIG - Names and Secrets TSIG name A name is given to the key, the name is what is transmitted in the message (so receiver knows what key the sender used) TSIG secret value A value determined during key generation Usually seen in Base64 encoding 30

31 TSIG Generating a Secret dnssec-keygen Simple tool to generate keys Used here to generate TSIG keys > dnssec-keygen -a <algorithm> -b <bits> -n host <name of the key> 31

32 TSIG Generating a Secret Example > dnssec-keygen a HMAC-MD5 b 128 n HOST ns1- ns2.pcx.net This will generate the key > Kns1-ns2.pcx.net >ls Kns1-ns2.pcx.net key Kns1-ns2.pcx.net private 32

33 TSIG Generating a Secret TSIG should never be put in zone files might be confusing because it looks like RR: ns1-ns2.pcx.net. IN KEY nefrx9 bbpn7lyqte= 33

34 TSIG Configuring Servers Configuring the key in named.conf file, same syntax as for rndc key { algorithm...; secret...;} Making use of the key in named.conf file server x { key...; } where 'x' is an IP number of the other server 34

35 Configuration Example named.conf Primary server Secondary server key ns1-ns2.pcx. net { algorithm hmac-md5; secret "APlaceToBe"; }; server { keys {ns1-ns2.pcx.net;}; }; zone "my.zone.test." { type master; file db.myzone ; allow-transfer { key ns1-ns2.pcx.net ;}; }; key ns1-ns2.pcx.net { algorithm hmac-md5; secret "APlaceToBe"; }; server { keys {ns1-ns2.pcx.net;}; }; zone "my.zone.test." { type slave; file myzone.backup ; masters { ;}; }; You can save this in a file and refer to it in the named.conf using include statement: include /var/named/master/tsig-key-ns1-ns2 ; 35

36 TSIG Testing: : dig You can use dig to check TSIG configuration <zone> AXFR -k <TSIG keyfile> $ example.net AXFR \ -k Kns1-ns2.pcx.net key Wrong key will give Transfer failed and on the server the security-category will log this. 36

37 TSIG Testing - TIME! TSIG is time sensitive - to stop replays Message protection expires in 5 minutes Make sure time is synchronized For testing, set the time In operations, (secure) NTP is needed 37

38 DNS Data Flow - Recap DATA STUB Resolver caching resolver (recursive) MASTER zone file (text, DB) dynamic updates SLAVES SLAVES ATTACK VECTORS man in the middle cache poisoning modified data spoofing master (routing/dos) spoofed updates corrupted data 38 38

The Bad DNSChanger* Biggest Cybercriminal Takedown in History 4M machines, 100 countries, $14M And many other DNS hijacks in recent times** SSL / TLS doesn't tell you if you've been sent to the

39 The Bad DNSChanger* Biggest Cybercriminal Takedown in History 4M machines, 100 countries, $14M And many other DNS hijacks in recent times** SSL / TLS doesn't tell you if you've been sent to the correct site, it only tells you if the DNS matches the name in the certificate. Unfortunately, majority of Web site certificates rely on DNS to validate identity. DNS is relied on for unexpected things though insecure. * End-2-end DNSSEC validation would have avoided the problems ** A Brief History of DNS Hijacking - Google 39

Basic Cache Poisoning Attacker Launches a spam campaign where

com Attacker s name server will respond to a DNS query for

com Vulnerable resolvers add malicious data to local caches

for the lifetime of the cached entry My Mac My local resolver

40 Basic Cache Poisoning Attacker Launches a spam campaign where spam message contains Attacker s name server will respond to a DNS query for loseweightnow.com with malicious data about ebay.com Vulnerable resolvers add malicious data to local caches The malicious data will send victims to an ebay phishing site for the lifetime of the cached entry My Mac My local resolver loseweightfastnow.com IPv4 address is ALSO is at What is the IPv4 address for loseweightfastnow.com I ll cache this response and update ecrime name server 40 40

Query Interception (DNS Hijacking) A man in the middle

name server that returns forge responses Can be done

recursor, ARP poisoning, or evil twin Wifi access

router redirects DNS queries to attacker s name server

banking transactions Attacker s name server returns

41 Query Interception (DNS Hijacking) A man in the middle (MITM) or spoofing attack forwards DNS queries to a name server that returns forge responses Can be done using a DNS proxy, compromised access router or recursor, ARP poisoning, or evil twin Wifi access point Attacker s resolver Evil twin AP or compromised router redirects DNS queries to attacker s name server Redirected path Evil Twin AP Intended path for online banking transactions Attacker s name server returns fake bank web site address Fake Bank Web Site Bank Web Site 10/1/

42 Where DNSSEC fits in CPU and bandwidth advances make legacy DNS vulnerable to MITM attacks DNS Security Extensions (DNSSEC) introduces digital signatures into DNS to cryptographically protect contents With DNSSEC fully deployed a business can be sure a customer gets un-modified data (and visa versa) 42

43 What DNSSEC solves and what s not MASTER zone file (text, DB) DATA STUB Resolver caching resolver (recursive) dynamic updates SLAVES SLAVES ATTACK VECTORS man in the middle cache poisoning DNSSEC scope modified data spoofing master (routing/dos) spoofed updates corrupted data 43

44 Brief reminder on Cryptography Nowadays most of our Security Services are based in one (or a combination) of the following areas: One-way hash functions Symmetric key crypto Public-key crypto (or asymmetric) 44 44

45 45 How DNSSEC Works?

46 How DNSSEC Works Client Resolver (ISP) a.server.net. Root Server example.net nameserver.net nameserver 46 46

47 How DNSSEC Works Data authenticity and integrity by signing the Resource Records Sets with a private key Public DNSKEYs published, used to verify the RRSIGs Children sign their zones with their private key Authenticity of that key established by parent signing hash (DS) of the child zone's key Repeat for parent Not that difficult on paper Operationally, it is a bit more complicated DS KEY KEY signs zone data 47 47

48 The Business Case for DNSSEC Cyber security is becoming a greater concern to enterprises, government, and end users. DNSSEC is a key tool and differentiator. DNSSEC is the biggest security upgrade to Internet infrastructure in over 20 years. It is a platform for new security applications (for those that see the opportunity). DNSSEC infrastructure deployment has been brisk but requires expertise. Getting ahead of the curve is a competitive advantage. 48

49 DNSSEC cctld Map 49

50 DNSSEC Deployment Where we are? 50

51 DNSSEC: So what s the problem? Not enough IT departments know about it or are too busy putting out other security fires. When they do look into it they hear old stories of FUD and lack of turnkey solutions. Registrars*/DNS providers see no demand leading to chicken-and-egg problems. *but required by new ICANN registrar agreement 51

52 What you can do For Companies: Sign your corporate domain names Just turn on validation on corporate DNS resolvers For Users: Ask ISP to turn on validation on their DNS resolvers For All: Take advantage of DNSSEC education and training 52

53 Hmm how do I trust it?

ICANN DNSSEC Deployment @Root Multi-stakeholder, bottom-up trust

Ceremonies and public docs SysTrust audited FIPS 140-2 level 4 HSMs

54 ICANN DNSSEC Multi-stakeholder, bottom-up trust model* /w 21 crypto officers from around the world Broadcast Key Ceremonies and public docs SysTrust audited FIPS level 4 HSMs Root DPS DNSSEC Practice Statement *Managed by technical community+icann 54

55 55 New concepts

56 New Concepts Secure Entry Point and Chain of Trust Delegating Signing Authority New packet options (flags) CD, AD, DO New RRs DNSKEY, RRSIG, NSEC/NSEC3 and DS Signature expiration Key Rollovers 56 56

57 Chain of Trust and Secure Entry Point Using the existing delegation based model of distribution Don t sign the entire zone, sign a RRset Parent DOES NOT sign the child zone. The parent signs a pointer (hash) to the key used to sign the data of the child zone (DS record) Example with Secure Entry Point net myzone 57 www 57

58 New Fields and Flags DNSSEC Updates DNS protocol at the packet level Non-compliant DNS recursive servers should ignore these: CD: Checking Disabled (ask recursing server to not perform validation, even if DNSSEC signatures are available and verifiable, i.e.: a SEP can be found) AD: Authenticated Data, set on the answer by the validating server if the answer could be validated, and the client requested validation DO: DNSSEC OK. A new EDNS0 option to indicate that client supports DNSSEC options 58 58

59 59 New Resource Records

60 New RRs Adds five new DNS Resource Records: 1. DNSKEY: Public key used in zone signing operations. 2. RRSIG: RRset signature 3. NSEC & 4. NSEC3: Returned as verifiable evidence that the name and/or RR type does not exist 5. DS: Delegation Signer. Contains the hash of the public key used to sign the key which itself will be used to sign the zone data. Follow DS RR's until a trusted zone is reached (ideally the root)

61 New RR: DNSKEY PROTOCOL OWNER TYPE FLAGS ALGORITHM example.net DNSKEY ( AwEAAbinasY+k/9xD4MBBa3QvhjuOHIpe319SFbWYIRj /nbmvzfjnsw7by1cv3tm7zllqnbcb86nvfmsq3jjofmr PUBLIC KEY (BASE64)...) ; ZSK; key id = KEY ID FLAGS determines the usage of the key PROTOCOL is always 3 (DNSSEC) ALGORITHM can be (3: DSA/SHA-1, 5: RSA/SHA1, 8: RSA/SHA-256, 12: ECC-GOST)

62 DNSKEY: Two Keys, not one There are in practice at least two DNSKEY pairs for every zone Originally, one key-pair (public, private) defined for the zone private: key used to sign the zone data (RRsets) public: key published (DNSKEY) in the zone DNSSEC works fine with a single key pair Problem with using a single key: Every time the key is updated, the DS record must be updated on the parent zone as well Introduction of Key Signing Key (flags=257) 62 62

63 KSK and ZSK Key Signing Key (KSK) Pointed to by parent zone in the form of DS (Delegation Signer). Also called Secure Entry Point. Used to sign the Zone Signing Key Flags: 257 Zone Signing Key (ZSK) Signed by the KSK Used to sign the zone data RRsets Flags: 256 This decoupling allows for independent updating of the ZSK without having to update the KSK, and involve the parents (i.e. less administrative interaction) 63 63

64 New RR: RRSIG (Resource Record Signature) example.net. 600 A example.net. 600 A OWNER TYPE TYPE COVERED ALG #LABELS TTL example.net. 600 RRSIG A ( SIG. EXPIRATION SIG. INCEPTION KEY IDSIGNER NAME example.net. SIGNATURE CoYkYPqE8Jv6UaVJgRrh7u16m/cEFGtFM8TArbJdaiPu W77wZhrvonoBEyqYbhQ1yDaS74u9whECEe08gfoe1FGg... ) 64 64

65 RRSIG Typical default values Signature inception time is 1 hour before. Signature expiration is 30 from now Proper timekeeping (NTP) is required What happens when signatures run out? SERVFAIL Domain effectively disappears from the Internet for validating resolvers Note that keys do not expire No all RRSets need to be resigned at the same time 65 65

66 New RR: NSEC NXDomains also must be verified NSEC provides a pointer to the Next SECure record in the chain of records. omega.myzone? RESOLVER NSEC ] delta.myzone., zulu.myzone.[ AUTH for myzone. myzone. NS alpha.myzone. A beta.myzone. CNAME charlie.myzone. A delta.myzone. MX zulu.myzone. A 66 66

67 New RR: NSEC3 To avoid concerns about zone enumeration To avoid large zone-files: opt-out concept omega.myzone? RESOLVER NSEC3 ] H(charlie.myzone.), H(alpha.myzone.) [ 1-Way Hash AUTH for myzone digests. H(zulu.myzone.) H(myzone.) H(delta.myzone.) H(charlie.myzone.) H(beta.myzone.) H(alpha.myzone.) 67 67

68 New RR: DS (Delegation Signer) Hash of the KSK of the child zone Stored in the parent zone, together with the NS RRs indicating a delegation of the child zone. The DS record for the child zone is signed together with the rest of the parent zone data NS records are NOT signed (they are a hint/pointer) Digest type 1 = SHA-1, 2 = SHA-256 myzone. DS F6CD025B3F5D A B56D683 myzone. DS CCBC0B557510E4256E88C01B0B1336AC4ED6FE08C8268CC1AA5FBF00 5DCE

69 Signatures expiration and Key Rollovers 69

70 Signature Expiration Signatures are per default 30 days (BIND) Need for regular resigning: To maintain a constant window of validity for the signatures of the existing RRset To sign new and updated Rrsets Use of jitter to avoid having to resign all expiring RRsets at the same time The keys themselves do NOT expire But they may need to be rolled over

71 Key Rollovers Try to minimise impact Short validity of signatures Regular key rollover Remember: DNSKEYs do not have timestamps the RRSIG over the DNSKEY has the timestamp Key rollover involves second party or parties: State to be maintained during rollover Operationally expensive 71 71

72 Key Rollovers Two methods for doing key rollover Pre-Publish Double Signature KSK and ZSK rollover use different methods. Remember that KSK needs to interact with parent zone to update DS record

73 Key Rollovers: Pre-Publish method KSK ZSK ZSK ZSK ZSK ZSK ZSK Glossary *SK Signing *SK Present TTL TTL TTL *SK Inactive Signs 73 73

74 Key Rollovers: Double Signature KSK KSK KSK KSK ZSK KSK KSK Glossary *SK Signing *SK Present TTL TTL TTL *SK Inactive Signs 74 74

75 75 Setting Up a Secure Zone

76 Steps Enable DNSSEC in the configuration file (named.conf) dnssec-enable yes; dnssec-validation yes; Create key pairs (KSK and ZSK) dnssec-keygen -a rsasha1 -b n zone myzone.net dnssec-keygen -a rsasha1 -b f KSK -n zone myzone.net Publish your public key $INCLUDE /path/kmyzone.net key ; ZSK $INCLUDE /path/kmyzone.net key ; KSK Signing the zone Update the config file Modify the zone statement, replace with the signed zone file Test with dig 76

77 77 Tools to help the process

78 Tools to use in DNSSEC Authoritative Servers that support DNSSEC NSD (by NLNetLabs) Knot (by CZ NIC Labs) BIND (by ISC) Vantio (by Nominum) YADIFA (by EURid) MS DNS Server (by Microsoft) TinyDNSSEC (based on tinydns by D.J. Bernstein) 78 78

79 Tools to use in DNSSEC Resolvers that support DNSSEC Unbound (by NLNetLabs) BIND (by ISC) MS Windows Server (by Microsoft) Tools to automate DNSSEC OpenDNSSEC (by NLnetLabs,.SE, Nominet et al) DNSSEC-Tools (by Sparta) BIND (by ISC) 79 79

80 Useful links

81 Questions?

DNS/DNSSEC Workshop. In Collaboration with APNIC and HKIRC Hong Kong. Champika Wijayatunga Regional Security Engagement Manager Asia Pacific

DNS/DNSSEC Workshop. In Collaboration with APNIC and HKIRC Hong Kong. Champika Wijayatunga Regional Security Engagement Manager Asia Pacific DNS/DNSSEC Workshop In Collaboration with APNIC and HKIRC Hong Kong Champika Wijayatunga Regional Security Engagement Manager Asia Pacific 22-24 January 2018 1 DNSSEC 2 2 DNS: Data Flow Zone administrator