1 / 22

Perils of Transitive Trust in the Domain Name System

Venugopalan Ramasubramanian Emin G ü n Sirer Cornell University. Perils of Transitive Trust in the Domain Name System. Introduction. DNS is critical to the Internet DNS architecture is based on delegations control for names is delegated to name servers designated by the name owner

verne
Télécharger la présentation

Perils of Transitive Trust in the Domain Name System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Venugopalan Ramasubramanian Emin Gün Sirer Cornell University Perils of Transitive Trust in the Domain Name System

  2. Introduction • DNS is critical to the Internet • DNS architecture is based on delegations • control for names is delegated to name servers designated by the name owner • delegations facilitate high scalability and decentralized administration • what is the impact on security?

  3. zoneedit.com • com • gtld-servers.net • nstld.com • net Dependencies for www.fbi.gov root www.fbi.gov gov • gov.zoneedit.com • zoneedit.com fbi.gov dns[,2].sprintip.com ns[3,4,5,6].vericenter.com sprintip.com • sprintlink.net • telemail.net vericenter.com

  4. Subtle Dependencies in DNS • www.fbi.gov • 86 servers, 17 domains, depth 3 • www.cs.cornell.edu • cs.rochester.edu  cs.wisc.edu itd.umich.edu • 48 nameservers, 20 domains, depth 4 • DNS dependencies are subtle and complex • increases risk of domain hijacks • use of caching (TTL) worsens impact

  5. fbi.gov sprintip.com dns[,2].sprintip.com ns[3,4,5,6].vericenter.com ns[1,2,3]-auth.sprintlink.net reston-ns[1,3].telemail.net reston-ns[2].telemail.net Servers with Security Loopholes www.fbi.gov www.cs.cornell.edu  [slate,cayuga].cs.rochester.edu source: internet systems consortium (www.isc.org)

  6. Survey Goals • Which domain names have large dependencies and entail high risk? • Which domains are affected by servers with known security holes and can be easily taken over? • Which servers control the largest portion of the namespace and are thus likely to be attacked?

  7. Survey Methodology • 593160 domain names (Yahoo and Dmoz.org) • 166771 name servers • 535036 domains, 196 top-level-domains

  8. All Top 500 Mean 46 68 Max 604 342 Median 26 22 Number of Dependencies Number of Dependencies

  9. All Top 500 Mean 4.3 5.4 Max 27 22 Median 3 3 Length of Dependency Chains Length of Dependencies

  10. Dependencies by TLDs

  11. All Top 500 Mean 2.4 5 Max 9 9 Median 2 5 Bottleneck Servers Size of Bottlenecks

  12. Availability vs. Vulnerability

  13. Security Flaws in Nameservers Survey of BIND source: Internet Systems Consortium (ISC)

  14. Vulnerability to Security Flaws • 17% of servers have known loopholes • 45% of names are not totally safe • security through obscurity! • more than 40% of servers hide version numbers • 19/46 reports for cs.cornell.edu and 18/86 for fbi.gov

  15. All Top 500 Mean 1.7 4.5 Max 9 9 Median 2 4 Vulnerability in Bottlenecks Size of Safe Bottlenecks

  16. Valuable Nameservers

  17. Valuable Nameservers Top 5 Domains arizona.edu ucla.edu uoregon.edu nyu.edu berkeley.edu

  18. Summary and Discussions • Easy to take over the Internet • identify the domain you want to attack • determine a set of servers that control the domain • compromise or DoS the bottleneck servers

  19. DNS-SEC • Security Standard for DNS based on public-key cryptography and digitally signed certificates • Not widely used currently • security at delegation points • authenticated denials • islands of security • Does not eliminate risks of DoS attacks

  20. CoDoNS Approach • Separate name management from lookup resolution • No delegations • self-certifying data for authenticity • Fast, Robust, and Scalable Lookup Service • optimal proactive caching on structured overlays

  21. Conclusions • Domain names have subtle dependencies • name-based delegations • Blind delegation of trust to improve availability is counter-productive • High susceptibility to domain hijacks • Critical servers are not well-secured http://www.cs.cornell.edu/people/egs/beehive/codons.php

More Related