Hardening the Core of the Internet
•
0 likes•74 views
- DNSSEC and RPKI are protocols that aim to secure the core of the Internet by adding authentication and integrity to DNS and routing data. - DNSSEC works by digitally signing DNS records with private keys, and publishing the signatures and corresponding public keys. It builds a chain of trust from the root zone down by including fingerprints of child keys in parent zones. - RPKI uses a similar approach to secure routing by digitally signing routing announcements and filtering invalid routes. It establishes a framework for routers to validate the authenticity and authorization of routing information.
Report
Share
Hardening the Core of the Internet
- 1. Ondřej Caletka, Nathalie Trenaman (RIPE NCC) Hardening the core of the Internet DNSSEC and RPKI APTLD79 Virtual Meeting
- 2. DNSSEC par t • Basic DNS principle s • DNS vulnerabilitie s • DNSSEC introductio n • DNSSEC key type s • Parent-child interactio n • How to deploy DNSSEC Agenda 2 RPKI par t • Introduction to Routing Securit y • Internet Routing Registr y • Resource Public Key Infrastructur e • Router Origin Authorizatio n • Router Origin Validation
- 4. Example of a DNS query 4 CLIENT RECURSIVE RESOLVER <<.>> (root) AUTHORITATIVE SERVER AUTHORITATIVE SERVER STUB RESOLVER www.yahoo.com? www.yahoo.com? ask .com DNS www.yahoo.com? ask Yahoo DNS www.yahoo.com? 87.140.2.33 87.140.2.33
- 5. Terminology 5 CLIENT RECURSIVE RESOLVER ROOT SERVER AUTHORITATIVE SERVER STUB RESOLVER RESOLVER CACHING SERVER CACHING FORWARDER NAMESERVER VALIDATING SERVER NAME SERVER MASTER / SLAVE
- 7. DNS Data Flow 7 CACHE / RECURSIVE SERVER PRIMARY SECONDARIES RESOLVER SR SR SR SR SR SR DDNS Authoritative servers
- 9. DNS Vulnerabilities 9 Data Corruption Cache Poisoning DNS Amplification CACHE / RECURSIVE SERVER PRIMARY SECONDARIES RESOLVER SR SR SR SR SR SR MITM DoS DDNS Authoritative servers Spoofing DDNS AXFR Spoofing DNS Configuration DNS-SD mDNS LLMNR IPv6 DNS Autodiscovery
- 10. • Mail goes to the server in the MX resource recor d • Path only visible in the email headers DNS exploit example 10 MX RR MX RR resolver Question Answer receiving mail server Spoofed answer MX RR Black Hat sending mail server
- 11. • Using UDP makes it easy to send spoofed datagram s • Only 16-bit transaction id make brute force guessing possibl e • Fragmentation of large datagrams presents another family of vulnerabilitie s • Broken resolver implementations using predictable outgoing port numbe r • Side-channel attacks like SAD DNS (2020) Factors making DNS attacks feasible 11
- 12. • BGP hijack of IP pre fi xes used by Amazon Route5 3 • Fake authoritative DNS servers installed on hijacked pre fi xe s • DNS responses redirected MyEtherWallet.com to a phishing sit e • Cache of DNS resolver was poisone d • Cryptocurrencies were stolen Real world example: MyEtherWallet attack in 2018 12
- 13. DNSSEC Adding trust to the DNS
- 14. • A solution to secure DNS data with asymmetric cryptograph y • Provides authenticity and integrity, but no con fi dentiality (encryption) of dat a • Publisher signs data with a private key and publish the signatures and public key inside the DNS zon e • A fi ngerprint of the zone's public key is published in its paren t • Validator checks signatures and fi lters out compromised dat a • A backward-compatible protocol allowing a gradual rollout What is DNSSEC 14
- 15. DNSSEC Protected Vulnerabilities 15 Data Corruption Cache Poisoning CACHE / RECURSIVE SERVER PRIMARY SECONDARIES RESOLVER SR SR SR SR SR SR MITM (if resolver is validating) DDNS Authoritative servers AXFR Spoofing
- 16. • Signing the Resource Records Sets with private key • Publishing DNSKEYs and RRSIGs inside the zone • Children sign their zones with their private key • Parent guarantees authenticity of child’s key by signing the hash of it (DS) • Repeat for parent … • …and grandparent DNSSEC Summary 16 signature Delegation Signer public key TLD ROOT DS NSEC3 DNSKEY DNSKEY DS DNSKEY DNSKEY SLD1 DS A DNSKEY DNSKEY AAAA SLD2 A AAAA
- 17. www.ripe.net IN A 193.0.0.214 www.ripe.net IN RRSIG A … 26523 ripe.net. ripe.net IN DNSKEY 256 26523 … ripe.net. ripe.net IN RRSIG DNSKEY 32987 … ripe.net. ripe.net IN DNSKEY 257 32987 … ripe.net. ripe.net IN DS 26523 8 1 … ripe.net IN RRSIG DS … 43249 net. net IN DNSKEY 256 43249 … net. DNSSEC Example 17 ripe.net. net.
- 18. • Mostly caching/recursive server s • It is expected to shift validation closer to the user for speci fi c protocols like DAN E • No integrity is guaranteed between validator and end use r • Forged data are hidden from end user s • According to APNIC Labs measurements, more than 30 % of internet users are using DNSSEC-validating resolver Who is validating DNSSEC data? 18
- 19. • Secure • Validator can build chain of signed records from trust anchor all the way down to the desired record • Insecure • Validator found a signed proof of an unsigned subtree • Bogus • It was not possible to build chain of signed records • May indicate attack, con fi guration error, data corruption or clock di ff erence • Indeterminate • There is no trust anchor con fi gured for that particular subtree Validation results 19
- 20. 20 Demo time ! Determining validation status from output of command dig
- 21. DNSSEC secure 21 $ dig www.ripe.ne t ; <<>> DiG 9.16.11 <<>> www.ripe.ne t ;; global options: +cm d ;; Got answer : ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6415 1 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION : ; EDNS: version: 0, flags:; udp: 51 2 ;; QUESTION SECTION : ;www.ripe.net . I N A ;; ANSWER SECTION : www.ripe.net . 7653 2 IN A 193.0.6.13 9 ;; Query time: 13 mse c ;; SERVER: 192.168.178.1#53(192.168.178.1 ) ;; WHEN: Tue Feb 16 13:40:50 CET 202 1 ;; MSG SIZE rcvd: 57 authenticated data
- 22. DNSSEC insecure/indeterminate 22 $ dig www.aptld.or g ; <<>> DiG 9.16.11 <<>> www.aptld.or g ;; global options: +cm d ;; Got answer : ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1267 1 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION : ; EDNS: version: 0, flags:; udp: 51 2 ;; QUESTION SECTION : ;www.aptld.org . I N A ;; ANSWER SECTION : www.aptld.org . 676 4 I N A 93.125.99.13 2 ;; Query time: 9 mse c ;; SERVER: 192.168.178.1#53(192.168.178.1 ) ;; WHEN: Tue Feb 16 13:47:44 CET 202 1 ;; MSG SIZE rcvd: 58 no ad fl ag
- 23. DNSSEC bogus 23 $ dig www.dnssec-failed.or g ; <<>> DiG 9.16.11 <<>> www.dnssec-failed.or g ;; global options: +cm d ;; Got answer : ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2551 9 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION : ; EDNS: version: 0, flags:; udp: 51 2 ;; QUESTION SECTION : ;www.dnssec-failed.org . IN A ;; Query time: 297 mse c ;; SERVER: 192.168.178.1#53(192.168.178.1 ) ;; WHEN: Tue Feb 16 13:51:03 CET 202 1 ;; MSG SIZE rcvd: 50 server failure no answer returned
- 24. Is this DNSSEC problem? 24 $ dig www.dnssec-failed.org +cdfla g ; <<>> DiG 9.16.11 <<>> www.dnssec-failed.org +cdfla g ;; global options: +cm d ;; Got answer : ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1570 2 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION : ; EDNS: version: 0, flags:; udp: 51 2 ;; QUESTION SECTION : ;www.dnssec-failed.org . I N A ;; ANSWER SECTION : www.dnssec-failed.org . 6380 IN A 68.87.109.24 2 www.dnssec-failed.org . 638 0 I N A 69.252.193.19 1 ;; Query time: 1 mse c ;; SERVER: 192.168.178.1#53(192.168.178.1 ) ;; WHEN: Tue Feb 16 13:53:37 CET 202 1 ;; MSG SIZE rcvd: 82 answer returned checking disabled
- 25. DNSSEC Key types
- 26. DNSSEC Made simple 26 Parent Key Child key Key 1 Key Hash Key 1 Key Hash Grandchild key Signs Signs
- 27. • Interaction with parent administratively expensiv e • Should only be done when neede d • Bigger keys are bette r • Signing zones should be fas t • Memory restriction s • Space and time concern s • Smaller keys with short lifetimes are bette r Key problem 27
- 28. • Large keys are more secur e • Can be used longer • Large signatures => large zone fi les • Signing and verifying computationally expensive • Small keys are fas t • Small signatures • Signing and verifying less expensive • Short lifetime Key functions 28 ✖ ✖ ✖
- 29. • Key Signing Key (KSK) only signs DNSKEY RRset - all public key s • Zone Signing Key (ZSK) signs all records in zone • Parent DS points to child’s KS K • Parent’s ZSK signs D S • Signature transfers trust from parent key to child key More than one key 29
- 30. Key split - ZSK and KSK 30 Parent Key Child KSK Key 1 Key Hash Key 1 Key Hash Grandchild key Signs Signs Child key Child ZSK
- 31. • Used to sign all data in the zone • Can be lower strength than the KSK • No need to coordinate with parent zone if change is needed • Can be changed very often Zone Signing Key - ZSK 31
- 32. • Only signs the public keys of the zone – KSK and ZSK • Delegates trust to the ZSK • Serves as a trust anchor – is referenced from the parent zone • Its replacement requires changing DS record in the parent zone Key Signing Key - KSK 32
- 33. • Only one key that signs all records and also serves as trust ancho r • Used mostly in small deployments with ECC-based algorithms : • unlike RSA, key size is fi xed for Elliptic-curve algorithm s • keys are small, fast to sign and secure at the same tim e • therefore KSK/ZSK split may not be necessary Combined Signing Key - CSK 33
- 34. 34 MX MX MX Record Set A A A Record Set RRSIG MX RRSIG A signed by (private) ZSK signed by (private) ZSK DNSKEY (ZSK) DNSKEY (KSK) RRSIG DNSKEY RRSIG DNSKEY signed by (private) ZSK (this is actually not necessary) signed by (private) KSK DS hash of child’s (public) KSK DNSKEY (ZSK) DNSKEY (KSK) RRSIG DS CHILD signed by Parent’s (private) ZSK PARENT (public) ZSK (public) KSK
- 36. • Each DNS zone is self-containe d - publishes actual DNS data, their signatures and a public key to check the m • The Chain of trust is built by inserting fi ngerprint of the public key to the parent zon e - if there is no DS record in the parent zone, the zone is always considered insecur e • TLD registry and registrars have to support publishing DS record s • Two possible ways : - publishing user-provided DS record directl y - calculating their own DS records out of user-provided DNSKEY Building the chain of trust 36
- 37. • Child zone publishes special CDS and/or CDNSKEY recor d • Parent zone operator periodically scans all the child zones for such record s • DS records in the parent zone are updated according to CDS or CDNSKEY content s - for already secure zones, this update is authorised by DNSSEC signature s - for insecure zones, another mechanism has to be deployed to avoid spoo fi n g • Automating secure delegation updates 37
- 38. DNSSEC How to deploy it
- 39. • On a resolver: almost no effort needed; on by default for : - BIN D - Unboun d - Knot Resolve r • On the authoritative side: proper planning is necessary (DNSSEC Practice Statement ) - Key and Signature Policy: what algorithm to use, how often to change the key s - Where to store key s - Adapt provisioning syste m - Prepare for disaster recovery How to deploy DNSSEC 39
- 40. • Most cloud resolvers (Google, Quad9, Cloud fl are,… ) • It is on by default for most common open source DNS resolver s • According to APNIC Labs measurements, more than 30 % of internet users are using DNSSEC-validating resolve r • Only signed domains are protected by DNSSEC validatio n • The path between validating resolver and client has to be protected, for instance : - DNS-over-TL S - DNS-over-HTTPS Who deploys DNSSEC validation 40
- 41. • The root zone itsel f • 1371 out of 1504 Top Level Domains (91 % ) • Second Level Domain numbers vary a lot per different TLDs : - 3.3 million domains under .COM (2 % ) - 3.4 million domains under .NL (56 % ) • there is registration fee discount for DNSSEC-enabled domain s - 800 000 domains under .CZ (60 % ) - 515 000 domains in .EU (14 %) Which domain names are signed 41
- 42. 111 ccTLDs are still without DNSSEC 42
- 43. • The bulk of DNSSEC-protected domain names come from web hosting companie s • DNSSEC is usually on-by-default by the hosting compan y • Many high-value domains are still not protecte d - complex task for Content Delivery Networks, where DNS responses are dynami c - no/hard support by many registrar s - lack of understanding of the DNSSEC technology There is still work to do 43
- 44. Questions 44
- 47. RPKI
- 48. Introduction to Routing Security
- 49. Routing on the Internet 49 “BGP protocol” Can I trust B? Routing table 194.x.x.x = B Routing table 193.x.x.x = A Is A correct? A 193.x.x.x B 194.x.x.x B: “I have 194.x.x.x” A: “I have 193.x.x.x”
- 50. Routing on the Internet 50 Can I trust B? Routing table 194.x.x.x = B Routing table 193.x.x.x = A Is A correct? A 193.x.x.x B 194.x.x.x B: “I have 194.x.x.x” A: “I have 193.x.x.x” RIPE Database “Internet Routing Registry”
- 51. • Fat fi nger s - 2 and 3 are really close on our keyboard s • Policy violation s - Oops, we did not want this to go on the public Interne t - Infamous incident with Pakistan Telecom and YouTube Accidents happen 51
- 54. • Many exist, most widely use d - RIPE Databas e - APNIC Databas e - RAD B • Veri fi cation of holdership over resource s - RIPE Database for RIPE Region resources onl y - RADB allows paying customers to create any objec t - Lots of the other IRRs do not formally verify holdership Internet Routing Registry 54
- 55. • Some IRR data cannot be fully truste d - Accurac y - Incomplete dat a - Lack of maintenanc e • Not every RIR has an IR R - Third party databases need to be used (RADB, NTTCOM ) - No veri fi cation of who holds IPs/ASNs Problem Statement 55
- 57. Resource Public Key Infrastructure (RPKI)
- 58. • Ties IP addresses and AS numbers to public key s • Follows the hierarchy of the IP address registrie s • Allows for authorised statements from IP address holder s - AS X is authorised to announce my pre fi x Y - Signed, holder of Y Resource Public Key Infrastructure 58
- 59. RPKI Certi fi cate Structure 59 Certificate hierarchy follows allocation hierarchy Member Member Member ROA ROA ROA ARIN APNIC RIPE LACNIC AFRINIC
- 60. Two Elements of RPKI 60 Signing Create your ROAs Validating Verifying others
- 61. RPKI Chain of Trust 61 RIPE NCC Root Certificate Self-signed ALL Resources Root’s private key signature public key
- 62. RPKI Chain of Trust 62 LIR Certificate Signed by the Root private key LIR’s Resources Root’s private key signature public key
- 63. RPKI Chain of Trust 63 ALL Resources LIR’s Resources Root’s private key signature signature public key public key
- 64. RPKI Chain of Trust 64 LIR’s Resources signature public key ALL Resources signature public key ROA signature
- 66. Route Origin Authorisation 66 Prefix is authorised to be announced by AS Number LIR’s private key ROA signature
- 67. Coverage ROAs 67
- 68. Accuracy ROAs 68
- 69. ROAs in some Asia Paci fi c countries 69 Country % Pre fi xes % Addreses Accuracy AU 26% 44% 100,0% KZ 12% 5% 100,0% JP 12% 25% 100,0% MN 99% 85% 100,0% AE 36% 29% 99,9% IR 90% 97% 99,9% RU 27% 31% 99,9% PK 91% 97% 99,8% IN 43% 57% 99,4% ID 39% 15% 97,6% CN 2% 2% 93,2% source: https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html
- 70. Number of ROAs Globally IPv4 70 • Source: https://stat.ripe.net/widget/rpki-by-trust-anchor
- 71. Number of ROAs Globally IPv6 71 • Source: https://stat.ripe.net/widget/rpki-by-trust-anchor
- 73. Two Elements of RPKI 73 Signing Create your ROAs Validating Verifying others
- 74. • Serious uptake in Route Origin Validation at Internet Exchange Points and Transit Provider s • Resulting in decrease of invalid BGP announcement s • High uptake in signing objects at all Regional Internet Registrie s • All major router vendors are now on boar d • Also some outages at different Trust Anchors 2020: The Year of RPKI 74
- 75. Status of Transit and Cloud Providers 75 Name Type Details Status Telia Transit Signed & Filtering Safe Cogent Transit Signed & Filtering Safe GTT Transit Signed & Filtering Safe NTT Transit Signed & Filtering Safe Hurricane Electric Transit Signed & Filtering Safe Tata Transit Signed & Filtering Safe PCCW Transit Signed & Filtering Safe RETN Transit Partially Signed & Filtering Safe Cloud fl are Cloud Signed & Filtering Safe Amazon Cloud Signed & Filtering Safe Net fl ix Cloud Signed & Filtering Safe Wikimedia Foundation Cloud Signed & Filtering Safe Scaleway Cloud Signed & Filtering Safe • Source: isbgpsafeyet.com
- 76. More Work Underway 76 Name Type Details Status Telstra Transit AS1221 done, AS4637 planned Partially Safe AT&T ISP Signed & Filtering peers Partially Safe Google Cloud Signed & Filtering planned Partially Safe You? ? ? ? • Source: isbgpsafeyet.com
- 77. Why This Matters for TLDs 77 • Route hijacks are a threat to the availability of the DN S • A successful hijack can make a domain name server unreachabl e • Or cause DNS queries to be diverted to malicious server s • ROAs are important to state routing intention s • So validating parties can make secure routing decision s • Registrars play an important role in protecting domain name s • Creating ROAs is easy!
- 78. How To Get Started? 78 • Read up! This is a great starting point : - https://rpki.readthedocs.io/en/latest / • Create your ROA s - In my.apnic.net or my.ripe.net • Share your experience or ask for advic e - https://www.ripe.net/mailman/listinfo/routing-wg/ - https://www.apnic.net/community/participate/sigs/routing-security-sig/
- 79. Questions 79
- 80. Title Text Learn something new today ! academy.ripe.ne t RIPE NC C Academy
- 82. Title Text Fin Ende Kpaj Konec Son Fine Pabaiga Einde Fim Finis Koniec Lõpp Kрай Sfârşit Конeц Kraj Vége Kiнець Slutt Loppu Τέλος Y Diwedd Amaia Tmiem Соңы Endir Slut Liðugt An Críoch Fund הסוף Fí Ënn Finvezh Beigas վերջ დასასრული النهاية پایان 82