Upload
others
View
16
Download
0
Embed Size (px)
Citation preview
1
APNIC Online Tutorial – DNS/DNSSEC
22
OutlineDay 2• DNSSEC Concept
• DNSSEC Deployment
• Hands-on Lab– Part 1: DNSSEC Validation– Part 2: Manual DNSSEC Signing– Part 3: Automatic DNSSEC Signing– Part 4: Chain of Trust
33
Housekeeping• Please note that this session will be recorded
• Please mute your microphone when the Instructor is presenting to avoid disruptions to the class;
• For Q&As please use the google document;
• After every 30 minutes we will discuss the Q&A;
• The chat section will be used to share information, URLs, etc;
• If you raise your hand be sure to lower it again;
• If something goes wrong, re-join the meeting;
• If you have any trouble please email [email protected]
44
Resources • Course Materials
– https://wiki.apnictraining.net/dns20200722-online
• Lab– https://academy.apnic.net/en/virtual-labs?labId=75818
55
Ask Questions• Google Doc
– https://docs.google.com/document/d/1VZ6DqBqPwNiHMTyp0XE4mL9OHEcqd8BTMyqYOaYGuPs/edit?usp=sharing
• Email the mailing list– [email protected]
6
DNS SECURITY OVERVIEW Module 1:
77
DNS: Data Flow
master Caching forwarder
Zone administrator
Zone file
Dynamicupdates
1
2
slaves
3
4
5
resolver
8
master Caching forwarder
Zone administrator
Zone file
Dynamicupdates
1
2
slaves
3
4
5
resolver
Server protection Data protection
Corrupting data Impersonating master
Unauthorized updates
Cache impersonation
Cache pollution byData spoofing
DNS Vulnerabilities
99
Issues with DNS• DNS data can be corrupted
• There is no way to check the validity of DNS data
• Transactions between DNS servers and clients can be compromised
• And what about privacy of your DNS data?
9
10
DNS Cache Poisoning
(pretending to be the authoritative
zone)
ns.example.com
Webserver(192.168.1.12001:DB8::1)
DNS Caching Server
Client
I want to access www.example.com
1
QID=645712
QID=64569
QID=64570
QID=64571
www.example.com 192.168.1.1www.example.com 2001:DB8::1
match!
www.example.com 192.168.1.99www.example.com 2001:DB8::9
3
3
Root/GTLD
QID=64571
1111
Attacks on DNS
11
https://www.icann.org/news/announcement-2019-02-15-en
1212
Basic DNS Security Practices• Update and patch DNS software• Restrict queries• Prevent unauthorized zone transfers• Run BIND with the least privilege (use chroot)• Randomize source ports• Secure the box• Implement TSIG and DNSSEC• DoH and DoT
13
14
DNSSEC TECHNICAL OVERVIEWModule 2:
1515
Vulnerabilities protected by DNSKEY / RRSIG / NSEC
Cache impersonation
Cache pollution byData spoofing
master Caching forwarder
Zone administrator
Zone file
Dynamicupdates
slavesresolver
1616
What is DNSSEC?• DNS Security Extensions
• Protects the integrity of data in DNS
• A form of digitally signing the data to attest its validity
• Provides a mechanism to:– establish authenticity and integrity of data– delegate trust to third parties or parent zones
17
How DNSSEC WorksAuthoritative server
• Signs the zones• Answers queries with the record
requested • Also sends the digital signature
corresponding to the record
Validating Resolvers • Authenticates the responses from
the server• Data that is not validated results to a
“SERVFAIL” error
DNS Resolver
DNS Auth Server
1818
How DNSSEC Works• Records are signed with private key to prove its
authenticity and integrity
• The signatures are published in DNS
• Public key is also published so record signatures can be verified
• Child zones also sign their records with their private key
• Parent signs the hash of child zone public key to prove authenticity
18
1919
How DNSSEC Works• RRsets are signed with private key to prove its authenticity
and integrity
• The signatures are published in DNS as RRSIG• Public DNSKEY is also published so RRSIG can be verified
• Child zones also sign their records with their private key
• Parent signs the child zone’s DS record to prove authenticity
19
2020
New Resource Records
Resource Record
Function
RRSIG Resource Record Signature Signature over RRset made using private key
DNSKEY DNS Key Public key needed for verifying a RRSIG
DS Delegation Signer Pointer for building chains of authentication
NSEC / NSEC3
Next Secure indicates which name is the next one in the zone and which type codes are available for the current name
2121
RRs and RRsets• Resource Record – each entry in the zonefile
www.example.net. 7200 IN A 192.168.1.1
• RRset - RRs with same name, class and type
www.example.net. 7200 IN A 192.168.1.1web1.example.net. 7200 IN A 10.0.0.1web2.example.net. 7200 IN A 172.16.0.20
In DNSSEC, RRsets are signed and not the individual RRs
2222
RRSIG• The private part of the key-pair is used to sign the resource record set (RRset)• The digital signature per RRset is saved in an RRSIG record
irrashai.net. 86400 NS NS.JAZZI.COM.86400 NS NS.IRRASHAI.NET.86400 RRSIG NS 5 2 86400 (
20190314010528 20190214010528 3510 irrashai.net.
Y2J2NQ+CVqQRjQvcWY256ffiw5mp0OQTQUF8vUHSHyUbbhmE56eJimqDhXb8qwl/Fjl40/kmlzmQC5CmgugB/qjgLHZbuvSfd9W+UCwkxbwx3HonAPr3C+0HVqP8rSqGRqSq0VbR7LzNeaylBkumLDoriQxceV4z3d2jFv4ArnM= )
22
RR type signed
Digital signature algorithmNumber of labels in the signed name
Signature expiry
Date signed
2323
DNSKEY• Contains the zone’s public key
• Uses public key cryptography to sign and authenticate DNS resource record sets (RRsets).
• Example:
irrashai.net. IN DNSKEY 256 3 5 ( AwEAAagrVFd9xyFMQRjO4DlkL0dgUCtogviS+FG9Z6Au3h1ERe4EIi3L X49Ce1OFahdR2wPZyVeDvH6X4qlLnMQJsd7oFi4S9Ng+hLkgpm/n+otEkKiXGZzZn4vW0okuC0hHG2XU5zJhkct73FZzbmBvGxpF4svo5PPWZqVb H48T5Y/9 ) ; key id = 3510
16-bit field flag; 256 if ZSK, 257 if KSK
Protocol octet
DNSKEY algorithm number
Public key (base64)
2424
NSEC Record• Next Secure
• Forms a chain of authoritative owner names in the zone
• Also proves the non-existence of a domain
• Each NSEC record also has a corresponding RRSIG
myzone.net. NSEC blog.myzone.net. A NS SOA MX RRSIG NSEC DNSKEY
2525
NSEC3• NSEC allows an attacker to walk through the linked list to
find all the records in the zone file. This is called zone walking.
• NSEC3 uses a hashing algorithm to list the next available domain in “hashed” format
• It is still possible for an attacker to do zone walking, although at a higher computation cost.
2626
DS Record• Delegation Signer• Establishes authentication chains between DNS zones• Must be added in the parent’s zonefile• In this example, irrashai.net has been delegated from .net. This record
is added in the.net zone file
irrashai.net. IN NS ns1.irrashai.net.NS ns2.irrashai.net.
IN DS 19996 5 1 ( CF96B018A496CD1A68EE7C80A37EDFC6ABBF8175 )
IN DS 19996 5 2 (6927A531B0D89A7A4F13E110314C722EC156FF926D2052C7D8D70C50 14598CE9 )
Key IDDNSKEY algorithm (RSASHA1)
Digest type: 1 = SHA12 = SHA256
2727
DS Record• indicates that delegated zone is digitally signed
• Verifies that indicated key is used for the delegated zone
• Parent is authoritative for the DS of the child zone– Not for the NS record delegating the child zone– DS should not be added in the child zone
2828
Chain of Trust• Establishes a chain of trust from parent to child zone
– Parent does not sign child zone– Parent only signs a pointer to the child zone (key) – DS RECORD
• The root is on top of the chainRoot.
.net
.apnic.net
2929
Creation of keys• In practice, we use two keypairs
– one to sign the zones, another to sign the other key
• Using a single key or both keys is an operational choice (RFC allows both methods)
• If using a single key-pair:– Zones are digitally signed using the private key– Public key is published using DNSKEY RR– When key is updated, DS record must again be sent to parent zone
• To address this administrative load, two keypairs will be used
30
Types of KeysZone Signing Key (ZSK)
Sign the RRsets within the zoneSigned by the KSKUses flag 256
Key Signing Key (KSK) Signs the ZSKPointed to by the parent zoneActs as the security entry point
3131
Signature Expiration• Keys do not expire
– Still a good practice to generate new ones regularly for added security
• Signatures have validity period– By default set to 30 days– This info is added in the key metadata
• Expired signatures will not validate– Must re-sign the zones
3232
DNSSEC Algorithms
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
New algorithms such as ECDSA and GOST are faster and can generate smaller keys and signatures
33
34
DNSSEC VALIDATIONModule 3:
3535
DNSSEC Validation Rate
35
http://stats.labs.apnic.net/dnssec
3636
DNSSEC in the Resolver• Recursive servers that are DNSSEC-enabled can validate
signed zones
• To enable DNSSEC validation:
dnssec-validation yes;
• The AD bit in the message flag shows if validated
36
3737
DNSSEC Validation
37
dig @localhost www.apnic.net +dnssec +multiline
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53884 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION: www.apnic.net. 300 IN CNAME www.apnic.net.cdn.cloudflare.net. www.apnic.net. 300 IN RRSIG CNAME 8 3 300 ( 20190608045355 20190509035355 43023 apnic.net. oX8qHhFXJLyu3TKru/1sGrDZnnyq3+aI2zhIFk6IF6PK nTXrzFE/USOjDffJI5+x3QAzPzBKDKXB1+XaXHq1lgw9 Mw6i3mx+NTkjfq7m1bN/wbZD8ddzjY1GK4lrZ/zM39WL 5GQ+2ryIMY0aQFdQzufnHkGHMlqJM6fbHdREwPY= )
3838
DNSSEC Validation
38
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47652 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; >>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21978 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
'ad’ bit – authenticated data
If dnssec validation is yes, and validation fails
3939
DNSSEC Validation• Other options if you don’t have a validating resolver
– Online web tools– Browser plugins
• Use public DNS serverdig @1.1.1.1 www.apnic.net +dnssec +multilinedig @8.8.8.8 www.apnic.net +dnssec +multiline
39
40
DNSSEC ValidationWithout validation With validation
41
DNSSEC Validation
Without validation With validation
4242
DNSSEC for Network Service Providers• Enable DNSSEC on your recursive servers and validate
responses– Deploy DNSSEC-validating resolvers
• Before you fully implement:– Domains that can’t be validated will be inaccessible– Be prepared to answer helpdesk queries related to this
42
4343
DNSSEC for End-users• Use a dnssec-validating resolver
• If not available, use other tools (such as browser plugin)
43
44
DNSSEC SIGNINGModule 3:
44
4545
DNSSEC Deployment Maps
45
https://www.internetsociety.org/deploy360/dnssec/maps/
4646
DNSSEC Deployment Maps (AP)
46
https://www.internetsociety.org/deploy360/dnssec/maps/
4747
DNSSEC for Registries and Hosting Providers• Sign your zones
• Before fully implementing:– Plan about key rollover – Think about securing your keys– What happens if your key gets compromised
• Support more and newer algorithms (such as ECDSA)
47
4848
DNSSEC - Deploy a Secure Zone1. Enable DNSSEC in the config file
2. Generate key pairs (KSK and ZSK)
3. Publish your public key
4. Signing the zone
5. Publish the new zonefile
6. Test the server
7. Push the DS record (to parent zone)
48
4949
1. Enable dnssec• Enable DNSSEC in the configuration file (named.conf)
options {
directory “….”dnssec-enable yes;
dnssec-validation yes;
};
• Other options to automate signing and key rolloverauto-dnssec { off | allow | maintain} ;
49
5050
2. Generate key pairs• Generate ZSK and KSK
dnssec-keygen -a rsasha256 -b 1024 -n zone <myzone>
Or simply:dnssec-keygen –f KSK <myzone>
• This generates four files.– Note: There has to be at least one public/private key pair for each
DNSSEC zone
50
Notes: Algorithm and keysize is an operational choice, but generally:- ECDSA is recommended- Keysize must be at least 2048
5151
2. Generate key pairs• To create ZSK
dnssec-keygen -a rsasha256 -b 1024 -n zone myzone.net
• To create KSK
dnssec-keygen -a rsasha256 -b 2048 -f KSK -n zone myzone.net
51
5252
2. Generate key pairs (reverse DNS)• To create ZSK
dnssec-keygen -a rsasha256 -b 1024 -n zone 100.168.192.in-addr.arpa
• To create KSK
dnssec-keygen -a rsasha256 -b 2048 -f KSK -n zone 100.168.192.in-addr.arpa
52
5353
Using NSEC3• Generate keys
dnssec-keygen -r /dev/urandom -a RSASHA256 -3 -b 1024 -n ZONE irrashai.netdnssec-keygen -r /dev/urandom -f KSK -a RSASHA256 -b 2048 -3 -n ZONE irrashai.net
5454
3. Publish the public key• A few options to do this:
– Using $INCLUDE you can call the public key (DNSKEY RR) inside the zone file
$INCLUDE /path/Kmyzone.net.+005+33633.key ; ZSK
$INCLUDE /path/Kmyzone.net.+005+00478.key ; KSK
– You can also manually enter the DNSKEY RR in the zone file– Or add the files into a key directory
zone { key-directory “/etc/bind/keys”; };
54
5555
4. Sign 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.netKmyzone.net.+005+33633
• Once you sign the zone a file with a .signed extension will be createddb.myzone.net.signed
55
Notes: Most of the following steps have been automatically done by the software. The manual steps are shown to understand the signing process.
5656
4. Sign the zone• Note that only authoritative records are signed
– NS records for the zone itself are signed– NS records used for delegations are not signed– DS records are signed– Glue records are not signed
• Notice the difference in file size– db.myzone.net vs. db.myzone.net.signed
56
5757
Inline Signing• Searches the key repository for any keys that will match the
zone being signed
options {keys-directory { “path/to/keys”;
};
• Then the zone statement must have these lines:auto-dnssec maintain;
inline-signing;
57
5858
Inline Signing• The use RNDC to load the new keys and do inline signing.
rndc reconfigrndc loadkeys myzone.netrndc signing –list myzone.net
58
5959
Using NSEC3• Load the keys and sign the zone
rndc loadkeys irrashai.netrndc signing –NSEC3PARAM 1 0 10 <some-salt> irrashai.net.
– To randomly generate a salt used aboveopenssl rand -hex 4
• Get the DS record and upload to the parent zone dig @localhost dnskey irrashai.net | dnssec-dsfromkey -f –irrashai.net
6060
5. Publish the new zonefile• Reconfigure to load the signed zone. Edit named.conf and
point to the signed zone.
zone “<myzone>” { type master; # file “db.myzone.net”; file “db.myzone.net.signed”;
};
60
6161
5. Publish the new zonefile (reverse)• Reconfigure to load the signed zone. Edit named.conf and
point to the signed zone.
zone “<myzone>” { type master; # file “db.192.168.100”; file “db.192.168.100.signed”;
};
61
6262
6. Test the server• Ask a dnssec-enabled server and see whether the answer
is signed
dig @localhost www.apnic.net +dnssec +multiline
62
6363
Testing with Dig
63
dig @localhost www.irrashai.net +dnssec (+multiline)
6464
Testing with Dig – Reverse
64
dig @localhost -x 192.168.100.100 +dnssec
6565
7. Push the DS record• The DS record must be published by the parent zone.
• Contact the parent zone to communicate the KSK to them.
• The following RFCs address this:– RFC 7344 : Automating DNSSEC Delegation Trust Maintenance– RFC 7477 : Child to Parent Synchronization in DNS– RFC 8078 : Managing DS Records from the Parent via
CDS/CDNSKEY
65
6666
Pushing DS Records for Forward Zone
66
Example form for Godaddy
6767
Pushing DS Record for Reverse Zone
67
DS record added in the domain object in a ds-rdata field
Using MyAPNIC
6868
Tools: DNSViz
68
http://dnsviz.net/
DNSViz can be used to see the chain of authentication
6969
Ways to Deploy DNSSEC• As part of the DNS software used
– Manual key management– Can be quite complex– For static environment– Some means of automation
• Use with a hardware security module (HSM)– Semi-automatic – Good for dynamic environment
• Using an external appliance – ‘dnssec-in-a-box’– Fully automates key generation, signing and rollover
69
DNSSEC tools for BIND, NSD, PowerDNS, etc
HSM, OpenDNSSEC
DNS Appliance
70
DNSSEC Signer Appliance
DNS Master• Creates the zones
as per usual
DNSSEC Signer• Signs the zones• Propagates the
signed zones
DNS Server• Answer queries
• Can be a pure signer or packaged with an IPAM or a DNS server
• In pure signer, the hardware appliance interfaces between the master/slave servers
• Examples: Secure64, Xelerance, SolidDNS, etc
70
71