Mitigating DNS DoS Attacks H. Ballani and P.Francis Presented for CSCE 715 class by Ahmad Almadhor...
-
date post
19-Dec-2015 -
Category
Documents
-
view
216 -
download
0
Transcript of Mitigating DNS DoS Attacks H. Ballani and P.Francis Presented for CSCE 715 class by Ahmad Almadhor...
Mitigating DNS DoS AttacksH. Ballani and P.Francis
Presented for CSCE 715 class
by Ahmad Almadhor
On Nov. 4th 2010
2Almadhor 715
outline
1. Background: DNS and resolvers
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4
3Almadhor 715
What is DNS? Resolver? DNS :
hierarchical naming system built on a distributed database for computers, services, or any resource connected to the Internet or a private network.
translates human-friendly computer hostnames into IP addresses.(phone book)
Ex.: the domain name www.example.com translates to the addresses 192.0.32.10 (IPv4) and 2620:0:2d0:200::10 (IPv6).
Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains and so on for sub-domains.
DNS resolver: determines the appropriate domain name servers responsible for the domain name in
question by a sequence of queries starting with the right-most (top-level).
Caching is a technique to solve DNS overhead problem
Nov. 4
Source: Wikipedia
outline
1. Background: DNS and resolvers.
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4 6Almadhor 715
7Almadhor 715
Introduction Recently, many DoS attacks on DNS to prevent client from resolving resource records
from an under attack zone.
Many proposals suggesting new architecture for the naming system in the internet to decentralize data distribution.
The authors think that no need to have a new architecture.
So, just a new technique built on the current framework would allow availability in resources.
Resolvers use caching to improve performance (reduce overhead) by using TTL “time to live” then discard them.
The new proposal is to modify resolvers operation: data from cache memory is stored to a new memory “Stale Cache” after TTL expired.
So when an authoritative name server is not available, stale cache can be used to answer queries
Problems: Obsolete data in stale cache will be showed small (<0.5%)
DNS semantics violation but is not adversely impact the fundamentals of DNS
Nov. 4
9Almadhor 715
DNS poisoning attack
DNS cache poisoning (sometimes referred to as cache pollution) is an attack technique that allows an attacker to introduce forged DNS information into the cache of a caching nameserver.
The impact is all web traffic, email, and other important network data can be redirected to systems under the attacker's control.
Solutions: Apply a patch from the vendor
Restrict access
Filter traffic at network perimeters
Run a local DNS cache
Disable recursion
Nov. 4
Source: US-CERT.
outline
1. Background: DNS and resolvers.
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4 11Almadhor 715
12Almadhor 715
DNS resolvers today and flooding attacks
Resolvers: Get queries, map them to a matching resource record, get responses (not
necessary answer the query), cache answers with TTL (either positives or negatives).
Check the cache for matching, if yes return a response; otherwise:
• Determine the closest zone, if it’s cached then traverse it down.
• if not go to TLD and traverse it down.
Failure scenario when a name server is not available fig 1.
Attacks: Flooding (e.g. by requests) name servers of a zone to disrupt the resolution process and its
sub-zones.
Denying the service between servers and clients.
Nov. 4
outline
1. Background: DNS and resolvers.
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4 14Almadhor 715
15Almadhor 715
Resolvers adjustments and the new cache Resolvers have a new job:
Storing cache data with expired TTL into the stale cache.
when the authoritative name servers are unavailable during the process of resolution as in fig 1, a resolver only now has a right to check the stale cache to find the queried record figure 2.
Resolvers can do resolution process and stale cache lookup concurrently.
Stale cache cleaning: When a normal response from resolution process is received, it’ll be cached; besides the
corresponding record in the stale cache will be removed. So, the new record will be in the stale cache after TTL expires (even negative responses).
This cleaning procedure helps keeping the stale cache updated with latest authoritative info.
Stale cache storage space requires small amount, even with a month’s worth of stale records.
Nov. 4
outline
1. Background: DNS and resolvers.
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4 17Almadhor 715
18Almadhor 715
Evaluation Collected DNS traffic from CS dept. @ Cornell network link to the internet
(using the network border router not at the resolvers), queries responses from cache were not observed.
Roughly 1300 hosts during 65 days
There were 84,580,513 DNS queries and 53,848,115 DNS responses for a total of 4,478,731 unique names
Packets were anonymized for privacy purposes.
The simulation was trace-based and controlled by two parameters: Stale cache size: X= 1 to 30 in days
Attack duration: 3,6,12 and 24 hours
Took the 7 days trace data into the stale cache and simulated an attack lasted for 3 hours. So, it was flexible to adjust the stale cache size and the attack period.
Nov. 4
19Almadhor 715
Implementation They used extreme scenarios (more than realistic flooding attacks) to test the stale info.
Fig 3 shows 1-day stale cache answers 68% queries in 3hr attack, and the fraction increases by the days. However, it diminishes after 14 days as shown in previous studies that the popularity of DNS names follows a zipf distr.
From fig 3, the fraction of queries answered increases with attack duration. Why?
Nov. 4
20Almadhor 715
Resolver cache has valid info., so no need to use the stale cache.
Now, Note: the trace did not include network’s resolvers, so this underestimated the actual fraction of successful answered queries in presence of stale cache.
Since stale cache has records with expired TTL, then accuracy problem arises.
To test the accuracy of the responses, they compared the simulation result with real resolution responses from the NS. Fig 4
Nov. 4
21Almadhor 715
In fig 5, is a comparison between the responses for A-queries(records) and NS-queries(records) using only the stale cache (no resolver cache) under 3 hr attack.
Notice that NS has much less responses that A. Why? NS has longer TTL, so they are still in the resolver cache, or not used in the past.
However, the accuracy fraction is surprisingly high for both (>99.5%). Fig 5
Nov. 4
outline
1. Background: DNS and resolvers.
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4 22Almadhor 715
23Almadhor 715
Three attacks: 1. Queries for NS-records corresponding to TLDs are failed.
• Such queries are successful with the stale cache because they were captured during the trace and hence will be in the cache or stale cache.
2. A client is not able to access TLD name serves(second-level ”a.com”).
• Fig 6, the queries answered increased but stable later because longer TTL
Nov. 4
24Almadhor 715
3. Similar to the previous attack; so third-level ”b.a.com” name servers are not accessible.
Focused on queries are not cached by the network’s resolvers.
Both A and NS records for names are accessed by clients with higher fraction of queries answered fig 7. Why?
• Lower TTL –values.
Nov. 4
outline
1. Background: DNS and resolvers.
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4 25Almadhor 715
26Almadhor 715
Memory requirements for the stale cache:
1. Number of clients
2. Query patterns
3. Resolver may use some rules for stale cache eviction algorithms (i.e. Least Recently Used)
In their simulation, they used: 1 to 30 days stale cache, 1300 hosts and query response rate 25 DNS packets/second; hence they used <313 MB only!!
Nov. 4
outline
1. Background: DNS and resolvers.
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4 27Almadhor 715
28Almadhor 715
Pros
1. DNS robustness: resolvers surly can respond to queries; also this approach can be adopted by the resolver operators.
2. Simplicity: No change in the protocol operation neither infrastructure.
No extra load on DNS
Does not impact the patency of query resolution (it’s used only when a query resolution fails)
3. Incremental deployment: any resolver can adopt this proposal easily and successfully.
4. Motivation for deployment: since it’s beneficial for the clients and resolver
Nov. 4
29Almadhor 715
Cons
Nov. 4
Objections Defenses
Change DNS semantics Does not affect the fundamentals of DNS
Inaccurate information being used Happens only under two conditions: A- NS for a zone are inaccessibleB- records are updated since last access by the resolver, so:1-When the records are moved to a new address nowadays the old address is still up to guide the misbehaving resolvers who keep cached info even after TTL expired.2- records have been changed to balance client loadrare Poole et.al. showed that it’s <2%So, it’s a small price to pay for robustnessOr use RCODE field in DNS header to inform the querying client that response is based on the stale cache
Autonomy for zone operators: Moving it to resolver operators; so zone op will lose control on their sub-zone.
Not affected since they didn’t modify DNS hierarchical resolution process, so resolvers still need to traverse the tree
Attackers attempting to force the use of inaccurate info.: they may take advantage of stale cache
It’s a concern but such attacks are not practical and the duration of a sub-zone to be alive is not too long
Privacy concerns: storing records beyond their TTL-values.
Stale cache does not provide an attacker about identities.
30Almadhor 715 Nov. 4
Objections Defenses
Resolution latency in the face of an attack: when a resolver query each NS at a zone and wait the query to timeout, that would increase the latency
the lookup latency problem can be solved by using aggressive values for these timers
DoS’ing the application servers: This approach does not reduce the vulnerability of name servers to DoS attacks.Also, intend to measure this for name servers on the Internet as part of the authors future work.
Interaction with DNSSec The proposal does not have any harmfulinteractions with or implications for DNSSec
outline
1. Background: DNS and resolvers.
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4 31Almadhor 715
32
Related work
R. Cox, A. Muthitacharoen, and R. T. Morris, “Serving DNS using a Peer-to-Peer Lookup Service,” in Proc. Of IPTPS, 2002, M. Handley and A. Greenhalgh, “The Case for Pushing DNS,” in Proc. of Hotnets-IV, 2005. those papers and many others are proposing a new naming system architecture and others
to multicast the global DNS to specialized servers.
V. Pappas, D. Massey, and L. Zhang, “Enhancing DNS Resilience against Denial of Service Attacks,” in Proc. Of Conference on Dependable Systems and Networks (DSN), 2007. This paper suggests to make DNS TTL-values higher for infrastructure records which is
similar but it is harder for operators to update records.
K. Park, V. Pai, L. Peterson, and Z. Wang, “CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups,” in Proc. of USENIX OSDI, 2004. It is introduced cooperating DNS resolvers within the a zone to avoid DoS.
Nov. 4Almadhor 715
outline
1. Background: DNS and resolvers.
2. Introduction
3. The basic idea: DNS resolvers today
DNS flooding attacks
Resolver modification
Stale cache
4. Evaluation Implementation
Performance under different attacks
Memory
5. Pros and Cons
6. Related work
7. Future work
Nov. 4 33Almadhor 715
34Almadhor 715
Future work
Extensive work on DNS records accuracy at the stale cache which has been
one big opposition on this work.
Combining this approach “stale cache” with others such as Co-operating
DNS resolvers proposal and studying their performance together.
Studying further on cost concerns when it is deployed on current systems.
Nov. 4