View
21
Download
0
Category
Preview:
Citation preview
DNSSEC Tutorial champika.wijayatunga@icann.org
Acknowledgements
• Rick Lamb – Senior Program Manager, DNSSEC @ICANN
• APNIC Training
DNS Basics
• DNS converts names (www.icann.org) to numbers (192.0.32.7)
• ..to idenOfy services such as www and e-‐mail • ..that idenOfy and link customers to business and visa versa
Reminder: DNS Resolving
Resolver
Question:
www.example.net A
www.example.net A ?
Caching forwarder (recursive)
www.example.net A ?
“go ask net server @ X.gtld-servers.net” (+ glue)
gtld-server www.example.net A ?
“go ask ripe server @ ns.example.net” (+ glue)
example-server
www.example.net A ?
“x.y.z.1”
x.y.z.1
1" 2"
3"
4"
5"
6"
7"
Add to cache 9"
8"
10" TTL
root-server
DNS: Data Flow
master Caching forwarder
Zone administrator
Zone file
Dynamic updates
1"
2"
slaves
3"
4"
5"
resolver
DNS VulnerabiliOes
master Caching forwarder
Zone administrator
Zone file
Dynamic updates
1"
2"
slaves
3"
4"
5"
resolver
Server protection! Data protection!
Corrupting data" Impersonating master"
Unauthorized updates"
Cache impersonation"
Cache pollution by"Data spoofing"
lamb@
xtcn.com
+1-‐202-‐709-‐5262 VoIP
mydomainname.com
DNS is a part of all IT ecosystems US-‐NSTIC effort
Smart Electrical Grid
OECS ID effort
Where DNSSEC fits in
• ..but CPU and bandwidth advances make legacy DNS vulnerable to MITM aWacks
• 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)
The Bad: DNSChanger -‐ ‘Biggest Cybercriminal Takedown in History’ – 4M machines, 100 countries, $14M
Nov 2011 h[p://krebsonsecurity.com/2011/11/malware-‐click-‐fraud-‐kingpins-‐arrested-‐in-‐estonia/ End-‐2-‐end DNSSEC valida_on would have avoided the problems
The Internet’s Phone Book -‐ Domain Name System (DNS)
www.majorbank.se=?
Get page webserverwww @ 1.2.3.4
Username / Password Account Data
DNS Hierarchy
se com
root
majorbank.se
www.majorbank.se
DNS Resolver
www.majorbank.se = 1.2.3.4 DNS Server 1.2.3.4
Login page
ISP Majorbank (Registrant)
Caching Responses for Efficiency
www.majorbank.se=?
Get page webserverwww @ 1.2.3.4
Username / Password Account Data
DNS Resolver
www.majorbank.se = 1.2.3.4 DNS Server 1.2.3.4
Login page
The Problem: DNS Cache Poisoning AWack
www.majorbank.se=? DNS Resolver
www.majorbank.se = 1.2.3.4 DNS Server 5.6.7.8
Get page Attacker webserverwww @ 5.6.7.8
Username / Password Error
Attacker www.majorbank.se = 5.6.7.8
Login page
Password database
Argghh! Now all ISP customers get sent to aWacker.
www.majorbank.se=? DNS Resolver
www.majorbank.se = 1.2.3.4 DNS Server 5.6.7.8
Get page Attacker webserverwww @ 5.6.7.8
Username / Password Error
Login page
Password database
Securing The Phone Book -‐ DNS Security Extensions (DNSSEC)
www.majorbank.se=? DNS Resolver with DNSSEC
www.majorbank.se = 1.2.3.4 DNS Server with DNSSEC
1.2.3.4
Get page webserverwww @ 1.2.3.4
Username / Password Account Data
Login page
Attacker www.majorbank.se = 5.6.7.8
Attacker’s record does not validate – drop it
Resolver only caches validated records
www.majorbank.se=? DNS Resolver with DNSSEC
www.majorbank.se = 1.2.3.4 DNS Server with DNSSEC
1.2.3.4
Get page webserverwww @ 1.2.3.4
Username / Password Account Data
Login page
The Bad: Other DNS hijacks*
*A Brief History of DNS Hijacking -‐ Google h[p://costarica43.icann.org/mee_ngs/sanjose2012/presenta_on-‐dns-‐hijackings-‐marquis-‐boire-‐12mar12-‐en.pdf
• 25 Dec 2010 -‐ Russian e-‐Payment Giant ChronoPay Hacked • 18 Dec 2009 – Twi[er – “Iranian cyber army” • 13 Aug 2010 -‐ Chinese gmail phishing a[ack • 25 Dec 2010 Tunisia DNS Hijack • 2009-‐2012 google.*
– April 28 2009 Google Puerto Rico sites redirected in DNS a[ack – May 9 2009 Morocco temporarily seize Google domain name
• 9 Sep 2011 -‐ Diginotar cer_ficate compromise for Iranian users • 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 cer_ficate. Unfortunately, majority of Web site cer_ficates rely on DNS to validate iden_ty.
• DNS is relied on for unexpected things though insecure.
The Business Case for DNSSEC
• Cyber security is becoming a greater concern to enterprises, government, and end users. DNSSEC is a key tool and differenOator.
• DNSSEC is the biggest security upgrade to Internet infrastructure in over 20 years. It is a pla`orm for new security applicaOons (for those that see the opportunity).
• DNSSEC infrastructure deployment has been brisk but requires experOse. Gecng ahead of the curve is a compeOOve advantage.
• Deployed on 462/654 TLDs (29 July 2014 70% .com .hr .es .in .af .ee .lb .bg .tm .cz .nl .uk .de .jp .cn .ru .рф .my مليسيا .asia .tw 台灣, .kr 한국 .net, .org, .post, +gtlds)
• Root signed** and audited • Required in new gTLDs. Basic support by ICANN registrars • Growing ISP support*. • 3rd party signing soluOons*** • Growing S/W H/W support: NLNetLabs, ISC, Microsop,
PowerDNS, Secure64…? openssl, pos`ix, XMPP, mozilla: early DANE support
• IETF standard on DNSSEC SSL cerOficates (RFC6698) • Growing support from major players…(Apple iPhone/iPad,
Google 8.8.8.8,…)
DNSSEC -‐ Where we are
**Int’l bo[om-‐up trust model /w 21 TCRs from: TT, BF, RU, CN, US, SE, NL, UG, BR, Benin, PT, NP, Mauri_us, CZ, CA, JP, UK, NZ…
*** Par_al list of registrars: h[ps://www.icann.org/en/news/in-‐focus/dnssec/deployment
* COMCAST /w 20M and others; most ISPs in SE ,CZ. AND ~12% of resolvers validate using DNSSEC
But… • But deployed on ~1-‐2% (3.5M) of 2nd level domains. Many have plans. Few have taken the step (e.g., yandex.com, paypal.com*, comcast.com).
• DNSChanger and other aWacks highlight today’s need. (e.g end-‐2-‐end DNSSEC validaOon would have avoided the problems)
• InnovaOve security soluOons (e.g., DANE) highlight tomorrow’s value.
* h[p://fedv6-‐deployment.antd.nist.gov/cgi-‐bin/generate-‐com h[p://www.thesecurityprac_ce.com/the_security_prac_ce/2011/12/all-‐paypal-‐domains-‐are-‐now-‐using-‐dnssec.html h[p://www.nacion.com/2012-‐03-‐15/Tecnologia/Si_os-‐web-‐de-‐bancos-‐_cos-‐podran-‐ser-‐mas-‐seguros.aspx
DNSSEC: So what’s the problem?
• Not enough IT departments know about it or are too busy pucng out other security fires.
• When they do look into it they hear old stories of lack of turnkey soluOons.
• Registrars*/DNS providers see no demand leading to “chicken-‐and-‐egg” problems.
*but required by new ICANN registrar agreement
Too many CAs. Which one can we trust? DNSSEC to the rescue….
CA CerOficate roots ~1482
Login security SSHFP RFC4255
DANE and other yet to be discovered security innovaOons, enhancements, and synergies
Content security Commercial SSL CerOficates for Web and e-‐mail
Content security “Free SSL” cerOficates for Web and e-‐mail and “trust agility”
Network security IPSECKEY RFC4025
Cross-‐organizaOonal and trans-‐naOonal idenOty and authenOcaOon
E-‐mail security DKIM RFC4871
DNSSEC root -‐ 1
Domain Names
Securing VoIP
hWps://www.eff.org/observatory hWp://royal.pingdom.com/2011/01/12/internet-‐2010-‐in-‐numbers/
• For Companies: – Sign your corporate domain names – Just turn on validaOon on corporate DNS resolvers
• For Users: – Ask ISP to turn on validaOon on their DNS resolvers
• For All: – Take advantage of organizaOons offering DNSSEC educaOon and training
What you can do
DNSSEC ImplementaOon
DNSSEC Resource Records
• 3 Public key crypto related RRs – RRSIG = Signature over RRset made using private key – DNSKEY = Public key, needed for verifying a RRSIG – DS = DelegaOon Signer; ‘Pointer’ for building chains of authenOcaOon
• One RR for internal consistency – NSEC = Next Secure; indicates which name is the next one in the zone and which typecodes are available for the current name
• authenOcated non-‐existence of data
RFC 4034
DNSKEY
• Contains the zone’s public key • Uses public key cryptography to sign and authenOcate DNS resource record sets (RRsets).
• Example:
myzone.net. IN DNSKEY 256 3 5 ( AwEAAagrVFd9xyFMQRjO4DlkL0dgUCtogviS+FG9Z6Au3h1ERe4EIi3L X49Ce1OFahdR2wPZyVeDvH6X4qlLnMQJsd7oFi4S9Ng+hLkgpm/n+otE kKiXGZzZn4vW0okuC0hHG2XU5zJhkct73FZzbmBvGxpF4svo5PPWZqVb H48T5Y/9 ) ; key id = 3510
Public key (base64)
RRSIG • The private part of the key-‐pair is used to sign the resource
record set (RRset) per zone • The digital signature per RRset is saved in an RRSIG record
myzone.net. 86400 NS ns.myzone.net. 86400 NS ns.yourzone.net. 86400 RRSIG NS 5 2 86400 ( 20121202010528 20121102010528 3510
myzone.net.
Y2J2+CVqQRjQvcWY256ffiw5mp0OQTQUF8vUHSHyUbbhmE56eJimqDhXb8qwlFjl40kmlzmQC5CmgugBqjgLHZbuvSfd9+Ucwkxbwx3HonAPr3+0HVqP8rSqGRqSq0VbR7LzNeaylBkumLDoriQxceV4z3d2jFv4ArnM= )
Types of Keys
• Zone Signing Key (ZSK) – Sign the RRsets within the zone – Public key of ZSK is defined by a DNSKEY RR
• Key Signing Key (KSK) – Signed the keys which includes ZSK and KSK and may also be used outside the zone
• Using a single key or both keys is an operaOonal choice (RFC allows both methods)
NSEC Record example $ORIGIN myzone.net.!@!SOA …!
! !NS !NS.myzone.net.!
! !DNSKEY !…!! !NSEC mailbox.myzone.net. SOA NS NSEC DNSKEY RRSIG!
!
mailbox !A !192.168.10.2 !!! ! !NSEC www.myzone.net. A NSEC RRSIG!
WWW ! !A !192.168.10.3 !!
! ! !TXT !Public webserver!
! ! !NSEC myzone.net. A NSEC RRSIG TXT!
DelegaOon Signer (DS) • Establishes the chain of trust from parent to child zones
• Found in the parent’s zone file • In this example, myzone.net has been delegated from .net. This is how it looks like in .net zone file
myzone.net. IN NS ns1.myzone.net.
NS ns2.myzone.net. IN DS 19996 5 1 ( CF96B018A496CD1A68EE7 C80A37EDFC6ABBF8175 ) IN DS 19996 5 2 ( 6927A531B0D89A7A4F13E11031 4C722EC156FF926D2052C7D8D70C50 14598CE9 )
DelegaOon Signer (DS)
• DelegaOon Signer (DS) RR indicates that: – delegated zone is digitally signed – indicated key is used for the delegated zone
• Parent is authoraOve for the DS of the childs zone – Not for the NS record delegaOng the childs zone! – DS should not be in the childs zone
DNSSEC ValidaOon • Recursive servers that are dnssec-‐enabled can validate signed
zones • The AD bit in the message flag shows if validated • Other opOons if you don’t have a validaOng resolver
– Use a validator add-‐on for your web browser • ex: hWps://www.dnssec-‐validator.cz/
– Online web tools • hWp://dnsviz.net/ • hWp://dnssec-‐debugger.verisignlabs.com/
– Use an open DNSSEC-‐validaOng resolver • Some open validaOng resolvers
– DNS-‐OARC’s ODVR (link) • 149.20.64.20 (BIND9), 149.20.64.21 (Unbound)
– Google Public DNS • 8.8.8.8 or 8.8.4.4
DNSSEC -‐ Secng up a Secure Zone • Enable DNSSEC in the configuraOon file (named.conf)
dnssec-enable yes; dnssec-validation yes;
• Create key pairs (KSK and ZSK) dnssec-keygen -a rsasha1 -b 1024 -n zone \ myzone.net
• Publish your public key • Signing the zone • Update the config file
– Modify the zone statement, replace with the signed zone file • Test with dig
Signing the Zone • Sign the zone using the secret keys: dnssec-signzone –o <zonename> -N INCREMENT -f <output-file> -k <KSKfile> <zonefile> <ZSKfile> dnssec-signzone –o myzone.net db.myzone.net Kmyzone.net.+005+33633
• Once you sign the zone a file with a .signed extension will be created – db.myzone.net.signed
TesOng with dig: an example dig @localhost www.apnic.net +dnssec +multiline
Pushing the DS record
• The DS record must be published by the parent zone.
• Contact the parent zone to communicate the KSK to them.
Ways to Deploy DNSSEC • As part of the DNS sopware used
– Manual key management – Can be quite complex – For staOc environment – Some means of automaOon using
• opOon commands and scripts • Use with a hardware security module (HSM)
– Semi-‐automaOc – Good for dynamic environment
• Using an external appliance – ‘dnssec-‐in-‐a-‐box’ – Fully automates key generaOon, signing and rollover
DNSSEC tools for BIND, NSD, PowerDNS, etc
HSM, OpenDNSSEC
DNS Appliance
DNSSEC: Internet infrastructure upgrade to help address today’s needs and create tomorrow’s opportunity.
Thank you!
Recommended