dns security - wiki.apnictraining.net · | 3 what is the domain name system? a distributed database...
TRANSCRIPT
DNS SecurityAPNIC42 | Colombo – Sri Lanka | 01 October 2016Champika Wijayatunga <[email protected]>
Brief Overview of DNS
2
| 3
What is the Domain Name System?
A distributed database primarily used to obtain the
IP address, a number, e.g., 192.168.23.1 or fe80::226:bbff:fe11:5b32
that is associated with a
user-friendly name (www.example.com)
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
| 4
History
1983 DNS was designed/invented by Paul Mockapetris (RFC882 & 883)
1984 Berkeley Internet Name Domain (BIND) Server developedOriginal Seven Generic TLDs (.com, .edu, .gov, .int, .mil, .net, and .org)
1985 First country codes assigned .us, .uk, and .il1986 .au, .de, .fi, .fr, .jp, .kr, .nl and .se 1987 RFC1034 (Considered the first full DNS Specification)
…….. Country Code TLDs continue to be added….
2000 Seven new TLDs added (.aero, .coop, .museum, .biz, .info, .name, and .pro)
2012 New round of applications for gTLDs opened by ICANN
| 5
Names in country-code TLDsNames in generic Top Level Domains
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– TLD registries administer domains in the top-level – TLD registries delegate labels beneath their top level delegation
. org
icann ncfta
www ssac
gov
irs
com ...ftc google msn
AF ... ZW
co
Root Server Operation
6
| 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
| 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
| 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.
| 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.
| 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
| 12
Root Server Operation @ICANN
+ 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
| 13
L-Root presence
| 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
| 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
| 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
| 17
Client Resolver(ISP)
www.example.net. ? www.example.net. ?
a.server.net.1.2.3.4
DNS Resolution
17
10.1.2.3
.netnameserver
a.server.net.1.2.3.4
RootServer
l.root-servers.net.199.7.83.422001:500:3::42
example.netnameserver
ns.example.net.5.6.7.8
| 18
The Registry/Registrar Ecosystem
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
| 20
DNS Resource Records (RR)
• Unit of data in the Domain Name System• Define attributes for a domain name
Label TTL Class Type RDatawww 3600 IN A 192.168.0.1
• Most common types of RRo A
o AAAA
o NS
o SOA
o MX
o CNAME
| 21
What is a DNS zone data?
• DNS zone data are hosted atan 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 hyphenscan be used as zone data.
In a zone, IDNs strings begin with XN--
| 22
Common DNS Resource Records
Time to live (TTL)• How long RRs are accurateStart of Authority (SOA) RR• Source: zone created here• Administrator’s email • Revision number of zone fileName Server (NS)• IN (Internet)• Name of authoritative serverMail Server (MX)• IN (Internet) • Name of mail serverSender Policy Framework (TXT)• Authorized mail senders
| 23
Common DNS Resource Records
Name server address record• NS1 (name server name)• IN (Internet)• A (IPv4) * AAAA is IPv6• IPv4 address (192.168.0.1)Web server address record• www (world wide web)• IN (Internet)• A (IPv4) * AAAA is IPv6IPv4 address (192.168.0.2)File server address record• FTP (file transfer protocol)• IN (Internet)• CNAME means “same address
spaces and numbers as www”
| 24
Places where DNS data lives
Changes do not propagate instantly
Registry DB
Master
Slave server
Slave
Cache server
Not going to net if TTL>0
Might take up to ‘refresh’ to get data from master
Upload of zone data is local policy
DNS Security
25
| 26
DNS Data Flow
26
STUBResolver
cachingresolver
(recursive)
MASTER
SLAVESSLAVES
zonefile
(text, DB)
dynamicupdates
man in the middle
cachepoisoning
modifieddata
spoofingmaster
(routing/DoS)spoofedupdates
corrupteddata
DAT
AAT
TAC
KVE
CTO
RS
| 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
| 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
| 29
TSIG steps
1. Generate secret
2. Communicate secret
3. Configure servers
4. Test
TSIG Steps
| 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
| 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>
| 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.+157+15921
>lsKns1-ns2.pcx.net.+157+15921.keyKns1-ns2.pcx.net.+157+15921.private
| 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 128 3 157 nEfRX9…bbPn7lyQtE=
| 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
| 35
Configuration Example – named.conf
Primary server 10.33.40.46
key ns1-ns2.pcx. net {algorithm hmac-md5;secret "APlaceToBe";
};server 10.33.50.35 {
keys {ns1-ns2.pcx.net;};};zone "my.zone.test." {
type master;file “db.myzone”;allow-transfer {key ns1-ns2.pcx.net ;};
};
Secondary server 10.33.50.35
key ns1-ns2.pcx.net {algorithm hmac-md5;secret "APlaceToBe";
};server 10.33.40.46 {
keys {ns1-ns2.pcx.net;};};zone "my.zone.test." {
type slave;file “myzone.backup”;masters {10.33.40.46;};
};
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”;
| 36
TSIG Testing : dig
• You can use dig to check TSIG configuration– dig @<server> <zone> AXFR -k <TSIG keyfile>
$ dig @127.0.0.1 example.net AXFR \-k Kns1-ns2.pcx.net.+157+15921.key
• Wrong key will give “Transfer failed” and on the server the security-category will log this.
TSIG Testing: dig
| 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
| 38
DNS Data Flow - Recap
38
STUBResolver
cachingresolver
(recursive)
MASTER
SLAVESSLAVES
zonefile
(text, DB)
dynamicupdates
man in the middle
cachepoisoning
modifieddata
spoofingmaster
(routing/DoS)spoofedupdates
corrupteddata
DAT
AAT
TAC
KVE
CTO
RS
| 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.
* http://www.fbi.gov/news/stories/2011/november/malware_110911/malware_110911 End-2-end DNSSEC validation would have avoided the problems
** A Brief History of DNS Hijacking - Googlehttp://costarica43.icann.org/meetings/sanjose2012/presentation-dns-hijackings-marquis-boire-12mar12-en.pdf
| 40
Basic Cache Poisoning
Attacker – Launches a spam campaign
where spam message contains http://loseweightfastnow.com
– 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
40
What is the IPv4 address for
loseweightfastnow.com
My Mac
My local resolver
ecrime nameserver
loseweightfastnow.com IPv4 address is 192.168.1.1
ALSO www.ebay.com is at 192.168.1.2
I’ll cache this response… and
update www.ebay.com
| 41
Query Interception (DNS Hijacking)
10/1/16 41
• 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
Bank Web SiteIntended path for online banking transactions
Redirected path
FakeBank Web Site
EvilTwinAP
Attacker’sresolverEvil twin AP or
compromised router redirects DNS queries
to attacker’s name server
Attacker’s name server returns fake
bank web site address
| 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)
| 43
What DNSSEC solves and what’s not
STUBResolver
cachingresolver
(recursive)
MASTER
SLAVESSLAVES
zonefile
(text, DB)
dynamicupdates
man in the middle
cachepoisoning
modifieddata
spoofingmaster(routing/DoS)
spoofedupdates
corrupteddata
DAT
AAT
TAC
KVE
CTO
RS
DNSSEC scope
| 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
How DNSSEC Works?
45
| 46
Client Resolver(ISP)
www.example.net. ? www.example.net. ?
a.server.net.
How DNSSEC Works
46
10.1.2.3
.netnameserver
RootServer
example.netnameserver
| 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– DSKEY → KEY –signs→ zone data
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.
| 49
DNSSEC ccTLD Map
https://rick.eng.br/dnssecstat/
| 50
DNSSEC Deployment – Where we are?
https://rick.eng.br/dnssecstat/
| 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
| 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
Hmm…how do I trust it?
| 54
ICANN DNSSEC Deployment @Root
• Multi-stakeholder, bottom-up trust model* /w 21 crypto officers from around the world
• Broadcast Key Ceremonies and public docs• SysTrust audited• FIPS 140-2 level 4 HSMs
Root DPSDNSSEC Practice Statement *Managed by technical community+ICANN
New concepts
55
| 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 Rollovers56
| 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 www.myzone.net.
57
“.”
net
myzone
www
Secure Entry Point
| 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
New Resource Records
59
| 60
New RRs
• Adds five new DNS Resource Records:1. DNSKEY: Public key used in zone signing operations.2. RRSIG: RRset signature3. NSEC &4. NSEC3: Returned as verifiable evidence that the name
and/or RR type does not exist5. DS: Delegation Signer. Contains the hash of the public
key used to sign the key which itself will be used to signthe zone data. Follow DS RR's until a ”trusted” zone isreached (ideally the root).
60
| 61
New RR: DNSKEY
• 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)– http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-
numbers.xml
61
example.net. 43200 DNSKEY 256 3 7 (
AwEAAbinasY+k/9xD4MBBa3QvhjuOHIpe319SFbWYIRj/nbmVZfJnSw7By1cV3Tm7ZlLqNbcB86nVFMSQ3JjOFMr
....) ; ZSK; key id = 23807
OWNER TYPE FLAGSPROTOCOL
ALGORITHM
PUBLIC KEY(BASE64)
KEY ID
| 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
| 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
| 64
New RR: RRSIG (Resource Record Signature)
64
example.net. 600 A 192.168.10.10example.net. 600 A 192.168.23.45
example.net. 600 RRSIG A 7 2 600 (
20150115154303 20141017154303 23807 example.net.
CoYkYPqE8Jv6UaVJgRrh7u16m/cEFGtFM8TArbJdaiPuW77wZhrvonoBEyqYbhQ1yDaS74u9whECEe08gfoe1FGg. . .)
OWNER TYPETYPE COVERED
ALG#LABELS
TTL
SIG. EXPIRATION SIG. INCEPTION KEY IDSIGNER NAME
SIGNATURE
| 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
| 66
New RR: NSEC
• NXDomains also must be verified
• NSEC provides a pointer to the Next SECurerecord in the chain of records.
66
myzone. NS …alpha.myzone. A …beta.myzone. CNAME …charlie.myzone. A …delta.myzone. MX …
zulu.myzone. A …
RESOLVER
AUTH for myzone.omega.myzone ?
NSEC] delta.myzone. , zulu.myzone.[
| 67
New RR: NSEC3
• To avoid concerns about “zone enumeration”
• To avoid large zone-files: opt-out concept
67
H(zulu.myzone.)H(myzone.)H(delta.myzone.) H(charlie.myzone.) H(beta.myzone.)H(alpha.myzone.)
1-Way HashAUTH for myzone digests.
RESOLVER
omega.myzone ?
NSEC3] H(charlie.myzone.) , H(alpha.myzone.) [
| 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)
68
myzone. DS 61138 5 1 F6CD025B3F5D0304089505354A0115584B56D683
myzone. DS 61138 5 2 CCBC0B557510E4256E88C01B0B1336AC4ED6FE08C8268CC1AA5FBF00 5DCE3210
Digest type 1 = SHA-1, 2 = SHA-256
Signatures expiration andKey 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...
70
| 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
| 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.
72
| 73
Key Rollovers: Pre-Publish method
73
KSK
ZSK
TTL
ZSK ZSK
TTL
ZSK
ZSK
TTL
ZSK
*SK Signing
*SK Present
Glossary
*SK Inactive
Signs
| 74
Key Rollovers: Double Signature
74
KSK
ZSK
TTL
KSK KSK
TTL TTL
KSK KSK KSK
*SK Signing
*SK Present
Glossary
*SK Inactive
Signs
Setting Up a Secure Zone
75
| 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 1024 -n zone myzone.netdnssec-keygen -a rsasha1 -b 1400 -f KSK -n zone myzone.net
• Publish your public key$INCLUDE /path/Kmyzone.net.+005+33633.key ; ZSK$INCLUDE /path/Kmyzone.net.+005+00478.key ; KSK
• Signing the zone• Update the config file
– Modify the zone statement, replace with the signed zone file• Test with dig
Tools to help the process
77
| 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
| 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
| 80
Useful links
• https://www.dnssec-deployment.org• http://www.internetsociety.org/deploy360/dnssec• http://dnssec-debugger.verisignlabs.com• http://dnsviz.net• http://www.dnssec-failed.org
80
Questions?