Difference between revisions of "DNSSEC"

From IIW
Jump to: navigation, search
(Undo revision 2943 by Igiwydijok (Talk))
 
Line 3: Line 3:
 
'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW 10]  May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes ]
 
'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW 10]  May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes ]
  
>=Issue/Topic:  DNSSEC explained=
+
=Issue/Topic:  DNSSEC explained=
  
 
==Wednesday – Session 2 - A==
 
==Wednesday – Session 2 - A==
Line 25: Line 25:
  
  
===DNS & vulnerabilities===
+
===DNS & vulnerabilities===
  
 
'''DNS (domain name system)'''
 
'''DNS (domain name system)'''
Line 58: Line 58:
 
[[File:Dnssec-attackingdns2.png|none|frame|Attacking DNS (2)]]
 
[[File:Dnssec-attackingdns2.png|none|frame|Attacking DNS (2)]]
  
'''Chances to spoof a resolver''' (Based on research by Bert Hubert (PowerDNS)) <br>
+
'''Chances to spoof a resolver''' (Based on research by Bert Hubert (PowerDNS)) <br>
 
In theory (50,000 queries/second)
 
In theory (50,000 queries/second)
 
* static source port – 10 seconds  
 
* static source port – 10 seconds  
* random source port – 36 hours &lt;br&gt;
+
* random source port – 36 hours <br>
 
In practice
 
In practice
 
* slow attack, 100 queries/second– 30 weeks
 
* slow attack, 100 queries/second– 30 weeks
Line 68: Line 68:
 
[[File:Dnssec-slowattack.png|none|frame|Slow attack]]
 
[[File:Dnssec-slowattack.png|none|frame|Slow attack]]
  
'''The (slow) attack is happening'''&lt;br&gt;
+
'''The (slow) attack is happening'''<br>
 
Scarce media reports about attacks
 
Scarce media reports about attacks
 
* Users from several large ISP’s and telco’s have suffered from misdirection and outages, but also specific spyware, spam and pay-per-click trojans.  
 
* Users from several large ISP’s and telco’s have suffered from misdirection and outages, but also specific spyware, spam and pay-per-click trojans.  
Line 194: Line 194:
 
* Independent site with lots of information  http://dnssec.net
 
* Independent site with lots of information  http://dnssec.net
 
* DNSSEC.nl - Platform aimed at finding solutions for open issues that are blocking widespread DNSSEC deployment in the Netherlands  http://www.dnssec.nl
 
* DNSSEC.nl - Platform aimed at finding solutions for open issues that are blocking widespread DNSSEC deployment in the Netherlands  http://www.dnssec.nl
 
----
 
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
 
----
 
=[http://odebasu.co.cc Page Is Unavailable Due To Site Maintenance, Please Visit Reserve Copy Page]=
 
----
 
=[http://odebasu.co.cc CLICK HERE]=
 
----
 
</div>
 

Latest revision as of 16:56, 1 February 2011

Session: Wed Session 3 Space A

Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes

Issue/Topic: DNSSEC explained

Wednesday – Session 2 - A

  • Convener: Esther Makaay
  • Notes-taker(s): Esther Makaay

A. Tags for the session - technology discussed/ideas considered:

#DNSSEC #DNS

B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Presentation about DNS vulnerabilities and DNSSEC as a solution.

Excerpt of a presentation given at Infosecurity Brussels. The more elaborate slideshow on this topic can be found at: http://www.slideshare.net/esthermakaay/dnssec-towards-enhanced-internet-security




DNS & vulnerabilities

DNS (domain name system)

  • Road signs
  • Hierarchical and distributed. Highly scalable and robust.
  • Scalable, distributed data, delegated (tree-structure)
  • ‘DNS = the internet’ (no, but it is to the vast majority of the end-users)
  • One of the oldest protocols out there
DNS tree structure
DNS is everywhere

DNS is vulnerable

  • Never designed for trust
  • Nothing really changed since 1983
  • Usage has broadened (functionality and quantity)
  • Everybody wants (to handle) your DNS

Risks:

  • Availability (no DNS – no internet)
  • Integrity (wrong DNS – wrong internet)

DNS integrity

Querying DNS
DNS UDP Packet
Attacking DNS (1)
Attacking DNS (2)

Chances to spoof a resolver (Based on research by Bert Hubert (PowerDNS))
In theory (50,000 queries/second)

  • static source port – 10 seconds
  • random source port – 36 hours

In practice

  • slow attack, 100 queries/second– 30 weeks
  • 50% success after only 6 weeks
Slow attack

The (slow) attack is happening
Scarce media reports about attacks

  • Users from several large ISP’s and telco’s have suffered from misdirection and outages, but also specific spyware, spam and pay-per-click trojans.
  • Customers of a large bank were redirected to fraudulent websites that attempted to steal passwords and install mallware
Statistics show peaks for NXDOMAIN answers (courtesy of SURFnet)

Countermeasures:

  • Patch against attacks
    • add entropy by port randomisation, case sensitivity (DNS 0x20) or EDNS-PING
    • cache time-outs, ask twice/ask thrice, use TCP
  • Monitor your network and servers
    • look for brute force attempts
    • count ‘near misses’ (correct port / failed ID)
    • Restrict queries to the intended users

Or implement DNSSEC

DNSSEC

A set of extensions to DNS which provide:

  • origin authentication
  • data integrity
  • authenticated denial of existence

Metaphor (Olaf Kolkman)

  • Compare DNSSEC to a sealed transparent envelope.
  • The seal is applied by whoever closes the envelope
  • Anybody can read the message
  • The seal is applied to the envelope, not to the message

“The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System.” (RFC 4033)

Verifying authentic answers

  • Authoritative servers:
    • Add digital signatures to resource record sets
    • Add public key to domain zone
  • Resolvers:
    • Validate the signatures to the public key
    • Only accept verified responses

Public key cryptography (RSA, DSA, (Elliptic Curve))

  • Private key for signing (protected and hidden)
  • Public key for verification (widely published)

Mini-howto (simplified)

  • Create the keypairs
  • Add the public keys to the zone
  • Sign the zone
  • Publish the signed zone
  • Notify parent
Building the chain of trust
Walking the chain of trust

Validating and resolving

  • Validating resolver needs configured trust anchors
    • Will only need the root zone key in the future
  • Possible types of answers (security status of data – RFC 4035)
    • secure – chain of trust is built from trust anchor
    • insecure – chain of trust can not be built from trust anchor (confirmed)
    • bogus – chain of trust should be built, but can not be built from trust anchor
    • indeterminate – unable to determine whether an RRset should be signed

Resolver will only answer queries that are secure or insecure.

ccTLD deployment forecast 31 December 2010

DNSSEC Software Tools are being developed and have become available:

  • OpenDNSSEC (www.opendnssec.org)
  • Signers: Secure64, Xelerance
  • PowerDNSSEC
  • Windows Server 2008 R2
  • other vendors have (announced) products

Resolver software widely available:

  • Unbound (NLnetLabs)
  • BIND 9.x and up
  • Windows Server 7

OpenDNSSEC OpenDNSSEC takes in unsigned zones, adds the signatures and other records for DNSSEC and passes it on to the authoritative name servers for that zone.

DNSSEC is complex

  • Operational issues
    • Domain transfers result in outage
    • Key rollovers need coördinated timing
    • Multiple scenario’s and policies at different parents
  • One size does not fit all
  • Small errors and bugs take time to resolve

DNSSEC does not

  • protect against packet sniffing
  • provide confidentiality
  • protect against DoS attacks (contrary)
  • protect against phishing, pharming, typosquatting

There will always be other risks!

No real alternatives

  • SSL / TLS
    • Doesn’t prevent cache-poisoning
    • Too heavy to be deployed for name servers
  • TSIG / SIG (0)
    • Not scalable (shared secrets)
    • Only secures transactions, not records
  • DNScurve
    • No operational implementation or widescale deployment yet


What you can do

  • Start resolving and validating DNSSEC
    • Gain early real-life DNSSEC experience
    • Detect and solve issues before the root is signed
  • Put DNSSEC-support in the requirements for new equipment
  • Plan for the future
  • Clean your house:
    • current DNS implementations and administration
    • network-components that impact DNS

Resources and further reading