dns/dnssec workshop - wiki.apnictraining.net · –take advantage of dns and dnssec education and...
Post on 18-Sep-2018
241 Views
Preview:
TRANSCRIPT
| 1
Champika WijayatungaRegional Security Engagement Manager – Asia Pacific
22-24 January 2018
DNS/DNSSEC WorkshopIn Collaboration with APNIC and HKIRC – Hong Kong
| 2| 2
DNSSEC
2
| 3
DNS: Data Flow
3
Primary Caching Servers
Resolvers
Zone administrator
Zone file
Dynamicupdates
1
2
Secondaries
3
4
5
| 4
DNS Vulnerabilities
4
Primary Caching Servers
Resolver
Zone administrator
Zone file
Dynamicupdates
1
2
Secondaries
3
Server protection
4
5
Corrupting data Impersonating master
Unauthorized updates
Cache impersonation
Cache pollution byData spoofing
Data protection
Altered zone data
| 5
The Bad
• Cache Poisoning Attacks– Vulnerable resolvers add malicious data to local caches
• DNS Hijacking– A man in the middle (MITM) or spoofing attack intercept and forwards
DNS queries to a name server that returns forge responses– e.g. DNSChanger (One of the biggest cybercriminal takedown in
history)• 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.
| 6
How DNSSEC Works
| 7
Why DNSSEC?
Without DNSSEC
DNS
DNSmyexamplebank.com
IP address X
myexamplebank..com webserver
Attacker’s
webserver
myexamplebank.com= IP address A
myexamplebank.com= Attacker IP address X
Attacker’s page
Passwords
DNS
DNSmyexamplebank.com
IP address A
myexamplebank.comwebserver
myexamplebank.com= IP address A
myexamplebank.com= Attacker IP address X
Passwords
Desired page
With DNSSEC
| 8
DNSSEC ccTLD Map
| 9
DNSSEC Deployment – Current Status
| 10
DNSSEC Validation – Current Status
| 11
DNSSEC Validation – Current Status
| 12
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
| 13
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.
| 14
What you can do
• For Companies:– Sign your corporate domain names– Just turn on validation on corporate DNS resolvers
• For Users:– Ask ISPs/DNS Operators to turn on validation on their DNS resolvers
• For All:– Take advantage of DNS and DNSSEC education and training– Encourage to join TLD policy discussions through ICANN constituencies
such as gNSO and ccNSO.
| 15
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
| 16
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.
16
“.”
net
myzone
www
Secure Entry Point
| 17
Delegation of Trust
• 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
| 18
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
example.net. 43200 DNSKEY 256 3 7 (
AwEAAbinasY+k/9xD4MBBa3QvhjuOHIpe319SFbWYIRj/nbmVZfJnSw7By1cV3Tm7ZlLqNbcB86nVFMSQ3JjOFMr
....) ; ZSK; key id = 23807
OWNER TYPE FLAGSPROTOCOL
ALGORITHM
PUBLIC KEY(BASE64)
KEY ID
| 19
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)
| 20
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)
| 21
New RR: RRSIG (Resource Record Signature)
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
| 22
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
| 23
New RR: NSEC
• NXDomains also must be verified
• NSEC provides a pointer to the Next SECure record in the chain of records.
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.[
| 24
New RR: NSEC3
• To avoid concerns about “zone enumeration”
• To avoid large zone-files: opt-out concept
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.) ]
| 25
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)
myzone. DS 61138 5 1 F6CD025B3F5D0304089505354A0115584B56D683
myzone. DS 61138 5 2 CCBC0B557510E4256E88C01B0B1336AC4ED6FE08C8268CC1AA5FBF00 5DCE3210
Digest type 1 = SHA-1, 2 = SHA-256
| 26| 26
Signatures Expiration and Key Rollovers
| 27
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...
| 28
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
| 29
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.
| 30| 30
DNSSEC Deployment @Root
| 31
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
| 32
DNSSEC – Signing vs. Validation
¤ DNS Security Extensions¤ Digital signature is the basic element of work
¤ Signing¤ Zone Administrators add digital signatures
¤ Validation¤ DNS Caches, DNS Stubs check the signatures in a few ways, cryptographic
and other (time, etc.)
¤ Impact of DNSSEC root KSK rollover¤ DNSSEC validators (e.g., some ISPs) need to prepare, new "root" of trust
| 33
The Root Zone DNSSEC KSK
DATA
¤The Root Zone DNSSEC Key Signing Key “KSK” is the top most cryptographic key in the DNSSEC hierarchy
¤Public portion of the KSK is configuration parameter in DNS validating revolvers
KSK
| 34
Recognizing KSK-2017
. IN DS 20326 8 2E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D"Root"
¤The KSK-2017’s Key Tag is
20326
¤The Delegation Signer (DS) Resource Record for KSK-2017 is
Note: liberties taken with formatting for presentation purposes
| 35
KSK-2017 in a DNSKEY Resource Record
. IN DNSKEY 257 3 8AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
"Root"
¤The DNSKEY resource record will be:
Note: liberties taken with formatting for presentation purposes
| 36
Why are there DS and DNSKEY forms of KSK-2017?
¤Tools that you will use to manage DNSSEC trust anchor configurations work on either the DS form, the DNSKEY form or both¤For each tool there are historical reasons¤The DS record contains a hash of KSK-2017¤The DNSKEY record contains the public key of KSK-2017
¤Consult your tool’s documentation to know which is appropriate
| 37
Preferred Approach
¤Mindful that the choice is a matter of local policy
¤DNSSEC validation is for the benefit of the receiver¤Not all operational environments are the same, not all validating
tools implement Automated Updates¤ ICANN is doing its best to accommodate different approaches
¤Automated Updates is likely the preferred approach
¤Relies only on what has been trusted before¤ It's the most reliable/stable approach, simplest basis for trust
| 38
Be aware whether DNSSEC is enabled in your servers
Be aware of how trust is evaluated in your operations
Test/verify your set ups
Inspect configuration files, are they (also) up to date?
If DNSSEC validation is enabled or planned in your system
o Have a plan for participating in the KSK rollovero Know the dates, know the symptoms, solutions
What Do Operators Need to Do?
| 39
Latest update on the Root KSK Rollover Project
• https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project
Visit us at icann.org
| 40
Thank You and Questions
Email: champika.wijayatunga@icann.org
top related