mitigating dns dos attacks · 2018-01-04 · dos attacks on dns attack: flood the nameservers of a...
Post on 04-Aug-2020
5 Views
Preview:
TRANSCRIPT
Mitigating DNS DoS Attacks
Hitesh Ballani and Paul FrancisCornell University
ACM CCS 2008
DoS attacks on DNS
Attack: Flood the nameservers of a DNS zone
Goal: Disrupt the resolution of
I The zone’s resource recordsI And the records for any of the sub-zones
.
edu. com. us. jp.
cornell.edu. cmu.edu mit.edu
cs.cornell.edu. eng.cornell.edu.
DoS attacks on DNS
Attack: Flood the nameservers of a DNS zone
Goal: Disrupt the resolution of
I The zone’s resource recordsI And the records for any of the sub-zones
.
edu. com. us. jp.
cornell.edu. cmu.edu mit.edu
cs.cornell.edu. eng.cornell.edu.
ATTACKFLOOD
DoS attacks on DNS
Attack: Flood the nameservers of a DNS zone
Goal: Disrupt the resolution of
I The zone’s resource recordsI And the records for any of the sub-zones
Attacks aplenty (some successful, other not!)
I Microsoft attacked (2001)
I DNS Root Servers attacked (2002)
I SCO attacked (2003)
I Akamai attacked (2004)
I Root Servers, TLDs and UltraDNS (2006)I Root Servers attacked (2007)
Networking community to the rescue
I Kangasharaju et. al.(g [INFOCOM’00]
I Cox et. al.(g [IPTPS’02]
I Theimer et. al(g [ICDCS’02]
I Ramasubramaniam et. al.(g [SIGCOMM’04]
I Handley et. al.(g [HotNets’05]
I Deegan et. al.(g [SIGCOMM CCR’05]
Networking community to the rescue
I Kangasharaju et. al.(g [INFOCOM’00]
I Cox et. al.(g [IPTPS’02]
I Theimer et. al(g [ICDCS’02]
I Ramasubramaniam et. al.(g [SIGCOMM’04]
I Handley et. al.(g [HotNets’05]
I Deegan et. al.(g [SIGCOMM CCR’05]
Decouple data distribution from authority hierarchy
Ensure availability of data distribution mechanism
Networking community to the rescue
I Kangasharaju et. al.(g [INFOCOM’00]
I Cox et. al.(g [IPTPS’02]
I Theimer et. al(g [ICDCS’02]
I Ramasubramaniam et. al.(g [SIGCOMM’04]
I Handley et. al.(g [HotNets’05]
I Deegan et. al.(g [SIGCOMM CCR’05]
Decouple data distribution from authority hierarchy
Ensure availability of data distribution mechanism
I Centralized approaches(g
Networking community to the rescue
I Kangasharaju et. al.(g [INFOCOM’00]
I Cox et. al.(g [IPTPS’02]
I Theimer et. al(g [ICDCS’02]
I Ramasubramaniam et. al.(g [SIGCOMM’04]
I Handley et. al.(g [HotNets’05]
I Deegan et. al.(g [SIGCOMM CCR’05]
Decouple data distribution from authority hierarchy
Ensure availability of data distribution mechanism
I Centralized approaches(g
I Peer-to-peer approaches(g
A complementary tact to handle DoS attacks
Do away with the need for 100% availability
Clients are able to resolve a zone’s records evenwhen the zone’s nameservers are not available
In this paper
A minor modification in the caching behavior of DNSresolvers
I Reduces the need for nameserver availability inthe existing DNS framework
I Mitigates the impact of DoS attacks on DNS
Talk Outline
I Introductiong(
I DNS Resolvers Todayg(
I Proposed Modificationg(
I Evaluationg(
I The Goodg(
I The Bad and the Uglyg(
DNS Resolvers Today(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
A? www.cornell.edu
DNS Resolvers Today(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
A? www.cornell.edu
LookupA? www.cornell.edu
Resolution Process1. Lookup the resolver cache
2. Traverse down the DNS hierarchy
3. Traversal fails ⇒ Resolution fails
DNS Resolvers Today(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
A? www.cornell.edu
LookupNS? .cornell.eduNS? .edu
Resolution Process1. Lookup the resolver cache
2. Traverse down the DNS hierarchy
3. Traversal fails ⇒ Resolution fails
DNS Resolvers Today(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
Resolution Process1. Lookup the resolver cache
2. Traverse down the DNS hierarchy
3. Traversal fails ⇒ Resolution fails
DNS Resolvers Today(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
A=128.253.161.221 www.cornell.edu
Resolution Process1. Lookup the resolver cache
2. Traverse down the DNS hierarchy
3. Traversal fails ⇒ Resolution fails
DNS Resolvers Today(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
Traversal fails
Resolution Process1. Lookup the resolver cache
2. Traverse down the DNS hierarchy
3. Traversal fails ⇒ Resolution fails
DNS Resolvers Today(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
Cache responsesfor TTL period
Resolver caching behavior
Cached records expunged after their TTL expires
Proposed Modification(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
Stale Cache
StaleRecords
Cached records expunged to a Stale Cache
Proposed Modification(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
Stale Cache
Lookup.edu NS
Modified Resolution Process1. Lookup the resolver cache
2. Traverse down the DNS hierarchy
3. Traversal fails ⇒ Resolution can continue
Proposed Modification(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
Stale Cache
Lookupsuccessful
Modified Resolution Process1. Lookup the resolver cache
2. Traverse down the DNS hierarchy
3. Traversal fails ⇒ Resolution can continue
Proposed Modification(g
Client
Resolver
Cache
Root-Server
Nameserver(.edu TLD)
Nameserver(.cornell.edu)
Stale Cache
Lookupsuccessful
Stale records for a zone used only when thenameservers for the zone are unavailable
Stale Cache Details(g
Expunging records from the Stale Cache
Responses from nameservers used to clean up thestale cache
Stale Cache lookup time not critical
Lookups can be done while querying thenameservers
Talk Outline
I Introductiong(
I DNS Resolvers Todayg(
I Proposed Modificationg(
I Evaluationg(
I The Goodg(
I The Bad and the Uglyg(
DNS Trace Collection
CornellCS Dept.
INTERNET
DNS TraceCollector
Anonymise DNS Trace
65-Day DNS Trace
I 138 million DNS packetsI 4.5 million unique DNS names
Trace collected at Border Router
I Network’s resolvers could not answer thecollected queries
Stale Cache Simulation
Simulation Variables
I Stale Cache Size
I Number of days for which stale records arekept
I Varied from 1 to 30 days
I Attack DurationI Varied from 3 to 24 hours
Is History Useful?
Attack: Entire DNS Fails
Is History Useful?
Attack: Entire DNS Fails
0.4
0.5
0.6
0.7
0.8
0.9
1
3021141075321Fra
ctio
n of
Que
ries
Ans
wer
ed
Stale Cache Size (days)
03 Hr06 Hr12 Hr24 Hr
0.4
0.5
0.6
0.7
0.8
0.9
1
3021141075321Fra
ctio
n of
Que
ries
Ans
wer
ed
Stale Cache Size (days)
03 Hr06 Hr12 Hr24 Hr
14-Day Stale Cache can answer ∼80% queries
Is History Useful?
Attack: Entire DNS Fails
0.984 0.986 0.988
0.99 0.992 0.994 0.996 0.998
1
3021141075321Fra
ctio
n of
Acc
urat
e R
ecor
ds
Stale Cache Size (days)
03 Hr06 Hr12 Hr24 Hr
0.984 0.986 0.988
0.99 0.992 0.994 0.996 0.998
1
3021141075321Fra
ctio
n of
Acc
urat
e R
ecor
ds
Stale Cache Size (days)
03 Hr06 Hr12 Hr24 Hr
99.6% accurate answers with 14-Day Stale Cache
Other Attack Scenarios
Root-Servers Fail
I Queries for Top-level Domains (TLDs) notresolved
I Stale Cache can answer all such queries
TLD Nameservers Fail
I Queries for two-level names (eg, a.com) notresolved
I Stale Cache can answer >75% such queriesI Accuracy of answers is 99.4%
Memory Footprint
Depends on network
I Number of hostsI Query-rate
For the collected trace
I 1300 hosts and ≈25 DNS pkts/secI Month-long Stale Cache = 313MB
Proposed Modification: Pros
Increased DNS Robustness
I Nameserver availability less crucialI Mitigates the impact of DoS attacks
Simplicity
I Does not change the basic protocol operation
I Does not impose any load on DNSI Does not impact the query resolution latency
Incremental Deployment
I Motivation for deployment
Talk Outline
I Introductiong(
I DNS Resolvers Todayg(
I Proposed Modificationg(
I Evaluationg(
I The Goodg(
I The Bad and the Uglyg(
Obsolete Autonomy Attack Latency Too specific
Ballani
Vixie
Obsolete Autonomy Attack Latency Too specific
Ballani
Vixie
Possibility of obsolete information being used
Obselete zone records used by a resolver only if
I Zone’s records have been updated since the lastaccess by the resolver
I Zone’s nameservers are inaccessible
Obsolete Autonomy Attack Latency Too specific
Ballani
Vixie
Possibility of obsolete information being used
Obselete zone records used by a resolver only if
I Zone’s records have been updated since the lastaccess by the resolver
I Zone’s nameservers are inaccessible
Trade-off between the possibility of obsoleteinformation being used and the inability to resolvequeries
Obsolete Autonomy Attack Latency Too specific
Ballani ✓
Vixie ✗
Possibility of obsolete information being used
Obselete zone records used by a resolver only if
I Zone’s records have been updated since the lastaccess by the resolver
I Zone’s nameservers are inaccessible
Trade-off between the possibility of obsoleteinformation being used and the inability to resolvequeries
Restrict the Stale Cache size
Obsolete Autonomy Attack Latency Too specific
Ballani ✓
Vixie ✗
Greg Minshall’s former CEO: “. . . he would sign(almost) any contract, as long as he could get outof it in a finite period of time”
Obsolete Autonomy Attack Latency Too specific
Ballani ✓
Vixie ✗
Greg Minshall’s former CEO: “. . . he would sign(almost) any contract, as long as he could get outof it in a finite period of time”
Zone AutonomyDoes the .com zone operator control access to the
.xxx.com sub-zone?
Today
.xxx.com NS recordsexpire after a TTL period
Proposed
?
Obsolete Autonomy Attack Latency Too specific
Ballani ✓ ✓
Vixie ✗ ✗
Greg Minshall’s former CEO: “. . . he would sign(almost) any contract, as long as he could get outof it in a finite period of time”
Zone AutonomyDoes the .com zone operator control access to the
.xxx.com sub-zone?
Today
.xxx.com NS recordsexpire after a TTL period
Proposed
Can respond with a NXDOMAINfor queries for .xxx.com
Zone operators still control access to their sub-zones
Obsolete Autonomy Attack Latency Too specific
Ballani ✓ ✓
Vixie ✗ ✗
Attackers forcing the use of obsolete records for azone by
I Waiting for the zone’s records to be updatedI And then flooding the zone’s nameservers
Obsolete Autonomy Attack Latency Too specific
Ballani ✓ ✓ ✗
Vixie ✗ ✗ ✓
Attackers forcing the use of obsolete records for azone by
I Waiting for the zone’s records to be updatedI And then flooding the zone’s nameservers
Obsolete Autonomy Attack Latency Too specific
Ballani ✓ ✓ ✗
Vixie ✗ ✗ ✓
Resolution latency in the face of attacks
I Resolver must query each nameserver of a zonebefore using the zone’s records from the stalecache
I Given default resolver timeout configurations,this can lead to high resolution latencies
Obsolete Autonomy Attack Latency Too specific
Ballani ✓ ✓ ✗ ✓
Vixie ✗ ✗ ✓ ✗
Resolution latency in the face of attacks
I Resolver must query each nameserver of a zonebefore using the zone’s records from the stalecache
I Given default resolver timeout configurations,this can lead to high resolution latencies
Alleviative: Resolvers configured with aggressiveretry and timeout values
Obsolete Autonomy Attack Latency Too specific
Ballani ✓ ✓ ✗ ✓
Vixie ✗ ✗ ✓ ✗
DNS servers can still be overwhelmed
I Unable to update the zone’s records
Application servers can still be DoS’ed
Obsolete Autonomy Attack Latency Too specific
Ballani ✓ ✓ ✗ ✓ –
Vixie ✗ ✗ ✓ ✗ –
DNS servers can still be overwhelmed
I Unable to update the zone’s records
Application servers can still be DoS’ed
I Do DNS servers and Application servers sharethe network bottleneck?
Summary
A minor modification in the caching behavior ofDNS resolvers
I Reduces the need for nameserver availability inthe existing DNS framework
I Mitigates the impact of DoS attacks on DNS
Stale CacheI Modifies the DNS caching semanticsI Does not impact fundamental DNS
characteristics
Thank You!
top related