1 / 61

Internet Infrastructure Protection

Internet Infrastructure Protection . May 23, 2006 Steve Crocker, steve@shinkuro.com ICANN Security and Stability Committee Shinkuro, Inc. My Primary Message. Build security into the infrastructure Good architecture is cheaper and better than chasing the bad guys

rhoda
Télécharger la présentation

Internet Infrastructure Protection

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. Internet Infrastructure Protection May 23, 2006 Steve Crocker, steve@shinkuro.com ICANN Security and Stability Committee Shinkuro, Inc.

  2. My Primary Message • Build security into the infrastructure • Good architecture is cheaper and better than chasing the bad guys • It’s less sexy but more effective • CERTs, Firewalls, Honeynets, etc. are all good • Networking the security community is good • Do all of this, but also invest in the architecture 2

  3. Latin America has unique opportunity • Plenty of technical talent • Networks are still in a growth stage • Not as much legacy as North America, Europe • Good communication, cooperation • Opportunity to leap ahead 3

  4. Incidents Reported to CERT/CC 4

  5. Vulnerabilities Reported to CERT/CC 5

  6. Attack Sophistication vs. Intruder Knowledge email propagation of malicious code DDoS attacks “stealth”/advanced scanning techniques increase in worms sophisticated command & control widespread attacks using NNTP to distribute attack widespread attacks on DNS infrastructure executable code attacks (against browsers) anti-forensic techniques Attack Sophistication automated widespread attacks home users targeted GUI intruder tools distributed attack tools hijacking sessions increase in wide-scale Trojan horse distribution widespread denial-of-service attacks Internet social engineering attacks Windows-based remote controllable Trojans (Back Orifice) techniques to analyze code for vulnerabilities without source code automated probes/scans packet spoofing Intruder Knowledge 6 1990 2004

  7. Internet Infrastructure Threats • Physical disruption of major lines and switching centers • Loss of DNS service continuity and/or fidelity • Loss of routing infrastructure continuity and/or fidelity • Flooding of network or specific sites, i.e. denial of service attack 7

  8. Internet Infrastructure Protection • DNSSEC • Address Security • DDoS suppression 8

  9. DNSSEC Deployment

  10. Segments • Demo • DNS & DNSSEC basics • Deployment Issues • Opportunity!

  11. Hijack Demo • Connect to BADNET network • We will intercept your queries…

  12. DNSSEC Basics Slides from RIPE NCC

  13. Why DNSSEC? • DNS is not secure • Known vulnerabilities • People depend more and more on DNS • DNSSEC protects against data spoofing and corruption 13

  14. DNS: Known Concepts • Known DNS concepts: • Delegation, Referral, Zone, RRs, label, RDATA, authoritative server, caching forwarder, stub and full resolver, SOA parameters, etc 14

  15. 2 1 3 Caching forwarder (recursive) 4 8 5 9 Add to cache 6 10 TTL 7 Reminder: DNS Resolving Question: www.ripe.net A root-server www.ripe.net A ? “go ask net server @ X.gtld-servers.net” (+ glue) www.ripe.net A ? Resolver 193.0.0.203 www.ripe.net A ? gtld-server “go ask ripe server @ ns.ripe.net” (+ glue) www.ripe.net A ? “193.0.0.203” ripe-server

  16. Zone administrator 1 2 3 4 5 Zone file slaves DNS: Data Flow master Caching forwarder Dynamic updates resolver

  17. Zone administrator 3 5 4 2 1 Zone file slaves DNS Vulnerabilities Corrupting data Impersonating master Cache impersonation master Caching forwarder Dynamic updates resolver Cache pollution by Data spoofing Unauthorized updates Altered zone data Server protection Data protection

  18. DNSSEC protects.. DNSSEC protects against data spoofing and corruption • DNSKEY/RRSIG/NSEC: provides mechanisms to establish authenticity and integrity of data • DS: provides a mechanism to delegate trust to public keys of third parties • A secure DNS will be used as an infrastructure with public keys • However it is NOT a PKI 18

  19. DNSSEC Current State • RFC 4033 • DNS Security Introduction and Requirements • RFC 4034 • Resource Records for the DNS Security Extensions • RFC 4035 • Protocol Modifications for the DNS Security Extensions • March 2005 • Obsoletes RFC 2535 19

  20. DNSSEC hypersummary • Data authenticity and integrity by signing the Resource Records Sets • Public DNSKEYs used to verify the RRSIGs • Children sign their zones with their private key • Authenticity of that key established by signature/checksum by the parent (DS) • Ideal case: one public DNSKEY distributed 20

  21. Deployment Issues • Getting the Root Signed • Getting TLDs Signed • Getting Enterprises Signed • Resolvers • Applications

  22. Key Generation A Key Distribution B Root Signing C Serving Signed Root D TLD Key Acquisition E Serving Signed Root with TLD Keys F Root Signing Road Map

  23. Current Status Zone Walking Zone Size Getting TLDs Signed -- Issues

  24. TLD Zone Status • .SE (Sweden) is signed and operational • RIPE’s portion of in-addr.arpa is signed • .ORG, .COM and .NET have test beds • More coming

  25. NSEC (“Next Secure”) makes it possible to “walk the zone” to find all entries Some (many?) TLD operators object NSEC3, using hashes, solves this problem NSEC3 design is done(?) Shakedown workshop at DENIC in early May Good progress. Further testing and documentation needed Zone Walking

  26. Memory requirements expand three to five times for a fully signed zone Significant impact on large zones -- COM, NET, ORG, DE, UK, … Current design requires one NSEC record for every delegation, even if it’s not signed “Opt-in” requires NSEC (or NSEC3) record only for signed zones (Some call this “opt-out”. Same thing.) Slightly different but equivalent security Much lower initial impact Opt-in is coming with NSEC3 Zone Size

  27. In house operation Outsourced operation Getting Enterprises Signed

  28. Software Possible hardware Operations Policies Key lifetimes, management chain Procedures, Training Become a founding operator… In House Operation

  29. Many enterprises outsource DNS service Registrars, hosting services Managed DNS Service Providers UltraDNS, VeriSign, Akamai, Netriplex, Infoblox, EasyDNS, DNS Made Easy DNS Service Providers can add DNSSEC with zero imposition on domain name holder Except perhaps for a charge DNS Service Providers will be the source of many signed zones Outsourced Operation

  30. Opportunity! • Meanwhile, in the short run, it’s up to us. • Be a DNSSEC founding operator • Sign your zone • Be the primary for others • Be a secondary • Tuesday we will announce a small directory of primary and secondary signer/operators • http://www.dnssec-deployment.org/zones • Sign up. Talk to us today. Send email.

  31. DNSSEC Deployment is… • … the transition from specs to operation • … a multinational effort • … a complex process • … a project that needs your help 31

  32. Organizational Matters • Pockets of expertise • Sweden, Netherlands, U.S., Japan • Active test bed and deployment in a few places • Deployment Working Group active 32

  33. What’s Needed • Local efforts in each country • Regional cooperation for training, etc. • Awareness campaigns • Testing • Application development 33

  34. Government Role(s) • Awareness, motivation • Prioritization – protect critical infrastructure • Funding of key local activities • Participation in global forum • Adoption and leadership internally 34

  35. Contacts & Resources • steve.shinkuro.com • www.dnssec-deployment.org • Slides and other DNSSEC material at: www.ripe.net/training/dnssec/ • http://www.nlnetlabs.nl/dnssec/ • http://www.dnssec.net/ ===================================== Support provided by U.S. Dept. of Homeland Security, Science and Technology Directorate Cooperative work with Sparta, NIST, MIT Lincoln Laboratory

  36. Acknowledgements • Olaf Kolkman, RIPE • Edward Lewis, NeuLevel • The Whole DNSSEC Deployment Working Group 36

  37. Address Validation

  38. Address Validation is Essential • Address spoofing is a key component of multiple attacks • Must check at ingress • Every ISP must do this 38

  39. What is Address Validation? • Does the source address belong to this customer? • Requires knowing authorized source addresses • Same as destination addresses • Requires checking • Adds cost, hardware • Do it anyway • Insist your peers do it too 39

  40. Suppression of Distributed Denial of Service (DDoS) Attacks 40

  41. The Denial of Service Problem • Denial of service attacks are increasing • This will get worse – probably much worse • Law enforcement is important but necessarily at the wrong end of the problem • Technical changes in the Internet would help a lot 41

  42. A modest(?) proposal for controlling DDoS Attacks • Identify sources of traffic • Identify “well managed” computers on “well managed” networks • Traffic from well managed networks gets preference 42

  43. “Well managed” • “Well managed” computers aren’t zombies • Details on the next slide • Well managed networks quarantine computers which appear to be infected or misbehaving • Well managed networks report misbehaviors and accept reports of misbehaviors 43

  44. Weeding out Zombies • Regular configuration checking • Either within the enterprise • Or by an outside service • Tight configuration control • (Eventually) certified appliances 44

  45. Network Wide Cooperation • Traffic among well managed networks gets preference • Traffic from same sites is labeled with a “good” bit • Eerily similar to Bellovin’s “evil” bit(!) • When there is congestion, traffic from unmanaged hosts on unmanaged networks is dropped • How is traffic labeled? • Diffserv? IP header bit? MPLS? Other? 45

  46. DDoS Policy Approaches • Pressure on the vendor to supply machines that are safe out of the box • Establishment of an ethic that machines should be safe, i.e. it’s the vendor’s problem, not the user’s. This all requires R&D, clarity of vision, and perseverance. Not an overnight process. 46

  47. Arguments in Favor • Similar to VPN over private lines, but potentially more efficient • Adds incentive to improve security in hosts and networks • Raises DDoS protection to a primary goal • Incremental – works well with a small set of core ISPs and expands smoothly • Robust – does not require 100% correct operation • Failures can be detected; adjustments can be made 47

  48. Critique • Sharp shift in policy • Requires strong cooperation among ISPs • Who sets the rules? • Enforcement issues • Who determines when an ISP or a customer isn’t complying? • What appeals process? • Efficiency issue for large ISPs: Is it feasible to filter traffic at high speed? 48

  49. Shinkuro Overview

  50. Working Together? • Why is so hard to work closely together over the net? • Email and Instant Messaging… Is that all there is? • Need flexible, easily configurable, user-controlled file-sharing, screen-sharing, etc. • Need very low cost 50

More Related