modeling dns security misconfiguration availability and visualization
Download
Skip this Video
Download Presentation
Modeling DNS Security: Misconfiguration, Availability, and Visualization

Loading in 2 Seconds...

play fullscreen
1 / 46

Modeling DNS Security: Misconfiguration, Availability, and Visualization - PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on

Modeling DNS Security: Misconfiguration, Availability, and Visualization. Casey Deccio Sandia National Laboratories. BYU Computer Science Dept. Colloquium Sep 9, 2010.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Modeling DNS Security: Misconfiguration, Availability, and Visualization' - wells


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
modeling dns security misconfiguration availability and visualization

Modeling DNS Security: Misconfiguration, Availability, and Visualization

Casey Deccio

Sandia National Laboratories

BYU Computer Science Dept. Colloquium

Sep 9, 2010

Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company, for the United States Department of Energy’s National Nuclear Security Administration under contract DE-AC04-94AL85000.

criticality of the dns
Criticality of the DNS
  • The DNS is the “phone book” for the Internet
    • Domain name to IP address translation
    • Mail server lookup
    • Service discovery
  • Most Internet applications rely on DNS name resolution

Query: www.foo.com/A ?

Answer:192.0.2.16

availability and security
Availability and security
  • DNS must be both available and accurate
  • Security was added as a retrofit
    • Security increases complexity
    • Troubleshooting is difficult
  • Misconfigurations abound, rendering name resolution unavailable
    • Examples:

medicare.gov, nasa.gov, arpa

objectives
Objectives

Establish model and metrics for assessing availability of DNSSEC deployments

Quantify complexity that may increase potential for DNSSEC misconfiguration

Introduce techniques to mitigate effects of misconfiguration

Query: www.foo.com/A ?

Answer:192.0.2.16

4

outline
Outline
  • DNS/DNSSEC background
  • DNSSEC availability model
  • DNS complexity analysis
  • Misconfiguration mitigation
  • DNSSEC visualization
  • Summary and future work
dns namespace
DNS namespace
  • Namespace is organized hierarchically
  • DNS root is top of namespace
  • Zones are autonomously managed pieces of DNS namespace
  • Subdomain namespace is delegated to child zones

.

com

net

baz.net

bar.com

foo.com

dns name resolution
DNS name resolution
  • Resolvers query authoritative servers
  • Queries begin at root zone, resolvers follow downward referrals
  • Resolver stops when it receives authoritative answer

.

Query: www.bar.com/A ?

com

Answer: 192.0.2.16

bar.com

stub resolver

recursive

resolver

authoritative servers

dns attacks
DNS attacks
  • Tainted DNS responses can direct users to malicious services
  • To forge DNS responses:
    • Guess query ID and UDP source port
    • Arrive before legitimate response
  • Attackers success rate increased by:
    • Eliciting queries of the resolver
    • Sending large number of responses

attacker

Query: www.bar.com/A ?

bar.com

Answer: ??

stub resolver

recursive

resolver

authoritative servers

dns security extensions dnssec
DNS Security Extensions (DNSSEC)
  • DNS data signed with private keys for authentication
  • Signatures (RRSIGs) and public keys (DNSKEYs) published in zone data
  • Resolver response
    • If authentic: Authenticated data (AD) bit is set
    • If bogus: SERVFAIL message is returned

Query: www.bar.com/A ?

Query: www.bar.com/A ?

bar.com

Answer: 192.0.2.16

RRSIG

Query: bar.com/DNSKEY ?

RRSIG

Answer: DNSKEY…

validate

Answer: 192.0.2.16

AD

authoritative server

recursive/validating

resolver

stub resolver

9

chain of trust
Chain of trust

Resolver

trust anchor

.

DNSKEY

  • DNSKEY must be authenticated
  • Resolver must have some notion of trust
  • Trust extends through ancestry to a trust anchor at resolver
  • DS resource record – provides digest of DNSKEY in child zone

Zone data

DS

com

DNSKEY

Zone data

DS

bar.com

DNSKEY

Zone data

10

insecure delegations
Insecure delegations

Resolver

trust anchor

  • If child zone is unsigned, resolver must be able to prove it is insecure
  • NSEC resource records provide proof of absence of DS

.

DNSKEY

Zone data

DS

net

DNSKEY

Zone data

NSEC/DS

baz.net

Zone data

11

dnssec maintenance
DNSSEC maintenance
  • RRSIGs must be periodically resigned to prevent expiration
  • DNSKEYs must be periodically rolled (replaced) to avoid prolonged exposure
  • Rollovers involving DS RRs must be coordinated with parent zones
  • Authoritative servers must serve consistent data

12

outline1
Outline
  • DNS/DNSSEC background
  • DNSSEC availability model
  • DNS complexity analysis
  • Misconfiguration mitigation
  • DNSSEC visualization
  • Summary and future work
classes of dnssec misconfiguration
Classes of DNSSEC misconfiguration
  • Zone misconfigurations
    • Missing, expired, or bogus RRSIG
    • Missing DNSKEYs
  • Delegation misconfigurations
    • No DNSKEY in child matching any DS in parent
    • Missing NSEC RRs for insecure delegation
  • Trust anchor misconfiguration
    • Stale trust anchor at resolver
failure potential
Failure potential
  • Probability of bogus validation
  • Based on fraction of responsive authoritative servers serving bogus or incomplete data
    • Resolvers will retry if server non-responsive
    • Not all servers will retry if server responds with bogus data
  • Assumption: resolver queries any authoritative server with equal probability

bar.com

Valid

Bogus

Non-responsive

authoritative server

recursive/validating

resolver

failure potential1
Failure potential
  • Formula extends to chain of trust in ancestor zones
  • Failure potential of each zone is combined independently of one another

.

com

bar.com

Recursive/validating

resolver

16

authoritative servers

dnssec deployment survey
DNSSEC Deployment Survey
  • Polled ~1500 production signed zones over a six-week period
  • Recorded validation errors resulting from misconfiguration
outline2
Outline
  • DNS/DNSSEC background
  • DNSSEC availability model
  • DNS complexity analysis
  • Misconfiguration mitigation
  • DNSSEC visualization
  • Summary and future work
complexity analysis
Complexity analysis
  • Complexity creates potential for misconfiguration
  • Hierarchical complexity:
    • Size of ancestry (zone depth)
  • Administrative complexity:
    • Servers administered by distinct organizations

.

com

bar.com

20

20

hierarchical reduction potential
Hierarchical reduction potential
  • If ancestry might reasonably be consolidated, what is the reduction?
  • Ancestry reduced, but original namespace can be preserved

.

.

com

com

= 0.25

bar.com

bar.com

sub.bar.com

administrative complexity
Administrative Complexity
  • How diverse is the set of organizations administering a zone?
  • Complexity measured by random sampling (with replacement) of authoritative servers to determine the probability that two organizations are selected

bar.com

ns.bar.com

me.baz.net

= 0.5

outline3
Outline
  • DNS/DNSSEC background
  • DNSSEC availability model
  • DNS complexity analysis
  • Misconfiguration mitigation
  • DNSSEC visualization
  • Summary and future work
avoiding and mitigating effects of misconfiguration
Avoiding and mitigating effects of misconfiguration
  • Follow best practice operational standards (RFCs)
    • Key rollover procedures
    • Trust anchor rollover procedures
  • Validation diligence
    • Resolver keeps trying alternative authoritative servers to find valid response
    • Optimality can be difficult – where is the break in the chain?
    • Implemented in BIND 9
soft anchoring
Soft anchoring

.

DNSKEY

  • DNSKEYs typically don’t change often
  • Resolvers configured with “hard” (traditional) trust anchors
  • “Soft” anchors are derived from DNSKEYs authenticated from existing hard anchors

Zone data

DS

com

DNSKEY

Zone data

DS

Resolver

Hard anchor

bar.com

DNSKEY

Soft anchor

Soft anchor

Zone data

impact of soft anchoring
Impact of soft anchoring

.

DNSKEY

  • Resolution not inhibited by:
    • zone-class misconfigurations in ancestry
    • delegation-class misconfigurations

Zone data

DS

com

DNSKEY

Zone data

DS

Resolver

Hard anchor

bar.com

DNSKEY

Soft anchor

Soft anchor

Zone data

maintaining soft anchors
Maintaining soft anchors
  • Resolvers follow procedure similar to that used for rolling hard trust anchors (RFC 5011)
  • Resolver periodically polls soft anchor zone
  • Soft anchor addition:
    • Newly authenticated DNSKEYs persist for “hold down” period
    • New DNSKEY seen with corresponding DS
  • Soft anchor removal:
    • Delegation to soft anchor made insecure
    • DNSKEY is revoked
    • DNSKEY and its DS RR are removed
soft anchoring limitations
Soft anchoring limitations
  • Doesn’t help when misconfigurations are at or below the bottom “link” in the chain of trust
  • Resolver must have authenticated soft anchors through valid chain of trust before misconfiguration
  • Scalability
    • Maintenance overhead of all trust anchors may be intense
    • Least-recently used policy may help
outline4
Outline
  • DNS/DNSSEC background
  • DNSSEC availability model
  • DNS complexity analysis
  • Misconfiguration mitigation
  • DNSSEC visualization
  • Summary and future work
dnssec visualization
DNSSEC Visualization
  • Live analysis of DNS authentication chain at: http://dnsviz.net/
slide34
arpa: the “root” of reverse name resolution

RRSIG expired, invalidating NSEC necessary to prove insecure delegation

slide37
medicare.gov:

missing appropriate DNSKEY, resulting in broken delegation

outline5
Outline
  • DNS/DNSSEC background
  • DNSSEC availability model
  • DNS complexity analysis
  • Misconfiguration mitigation
  • DNSSEC visualization
  • Summary and future work
summary
Summary

DNS responses must be both accurate and available

DNSSEC deployment requires careful deployment and maintenance

Soft anchoring can mitigate effects of misconfiguration

DNSSEC visualization helps understanding and troubleshooting

Query: www.foo.com/A ?

Answer:192.0.2.16

future work
Future work
  • Internet draft of soft anchoring to gain community support
  • Improved usability of DNS visualization tool
    • Monitoring and alerting
    • Better analysis of server inconsistencies
acknowledgements
Acknowledgements
  • Jeff Sedayao, Krishna Kant at Intel Corporation
  • Prasant Mohapatra at UC Davis
questions
Questions?
  • ctdecci@sandia.gov
visualization components
Visualization components

Domain name

DNSKEY/DS RR

SEP

Revoke

Published

DNSKEY attributes

Missing

Trust anchor

Missing

NSEC proving non-existence of

DS RRs (insecure delegation)

visualization components1
Visualization components

Alias dependency

Valid

Bogus

Expired

Missing

Signature or digest

Secure

Bogus

Insecure

Misconfigured

Delegation

Sufficient

Insufficient

Proof of insecure

delegation

the bottom line
The bottom line
  • Status of nodes in graph, based on chain of trust

Secure

Bogus

Insecure

ad