Defending P2ps from Overlay Flooding-Based Ddos
Total Page：16
File Type：pdf, Size：1020Kb
Defending P2Ps from Overlay Flooding-based DDoS Yunhao Liu1, Xiaomei Liu2, Chen Wang2, and Li Xiao2 1Department of Computer Science, Hong Kong University of Science and Technology, Kowloon, Hong Kong 2Department of Computer Science and Engineering, Michigan State University, East Lansing, MI 48824, USA Abstract DDoS. In DD-POLICE, peers monitor the traffic from and to each of their neighbors. If a peer receives a large number of queries from one of its neighbors, it will mark this neighbor as a A flooding-based search mechanism is often used in un- suspicious DDoS peer. This peer will exchange query volume structured P2P systems. Although a flooding-based search information with the suspicious peer‘s neighbors so that it can mechanism is simple and easy to implement, it is vulnerable to figure out the number of queries originally issued by the suspi- overlay distributed denial-of-service (DDoS) attacks. Most pre- cious peer. Based on this number, this peer makes a final deci- vious security techniques protect networks from network-layer sion on whether the suspicious neighbor is a DDoS peer and DDoS attacks, but cannot be applied to overlay DDoS attacks. should be disconnected. Overlay flooding-based DDoS attacks can be more damaging in The remainder of this paper proceeds as follows. Section 2 that a small number of messages are inherently propagated to analyzes the characteristics of overlay DDoS. Section 3 presents consume a large amount of bandwidth and computation re- the design of DD-POLICE. Performance evaluation of sources. We propose a distributed and scalable method, DD-POLICE is presented in Section 5. Section 4 reviews the DD-POLICE, to detect malicious nodes in order to defend P2P related work. We conclude the work in Section 5. systems from overlay flooding-based DDoS attacks. We show the effectiveness of DD-POLICE by comprehensive simulation studies. We believe that deploying DD-POLICE will make P2P 2 Overlay DDoS in unstructured P2Ps systems more scalable and robust. 2.1 Overlay DDoS in P2Ps 1 Introduction Our belief that unstructured P2P systems are vulnerable to There are mainly three different architectures for P2P sys- overlay DDoS attacks, is based on following observations. tems: centralized, decentralized structured, and decentralized First, the flooding based search mechanism makes overlay unstructured [1]. Unstructured P2P systems are most commonly DDoS in P2Ps simple in design and operation without requiring used in today's Internet [2-9]. The most popular search mecha- any special resources. Malicious nodes may attack the system nism in unstructured P2P systems is to “flood" a query to the by walking in and sending out a huge number of useless search network among peers or among super-peers. A query is broad- queries. The message volume will be quickly propagated and cast and rebroadcast until certain criteria are satisfied. The sim- the resources in the P2P system can be exhausted by a small plicity of the flooding based search mechanism makes it vul- number of DDoS attack machines. nerable to overlay DDoS attacks. DDoS attacks have already Second, the anonymity design of P2P helps the malicious become a major threat to the stability of the Internet [10-14]. nodes easily hide behind other peers. The forwarding peers do The basic goal of denial of service (DoS) is to overwhelm the not know the original sender of each query and the query re- processing or link capacity of the target by saturating it with sponse is only delivered to the neighbor along the inverse path bogus packets. Flooding based overlay DDoS attacks are DoS of the search path. Disconnecting all the peers who send out a attacks performed from multiple compromised peers (agents), large number of queries is dangerous in that a large number of who generate as many bogus queries as they can toward the “good” peers could be forwarding queries for “bad” peers. We victims. One character of P2P overlay DDoS is that the attack show a simple example in Figure 1. Instead of flooding the target is not a single site in the Internet, but the whole system. same queries to all its neighbors, a “bad” peer issues different Most previous research on DDoS focused on Network layer queries to its neighboring peers in order to make DDoS attacks attacks. Since a P2P system can have millions of insecure users more damaging to the system. We can see in Figure 1 that the online simultaneously, and the IP address of a query source peer query traffic in some connections between “good” peers is is not included in the query or query hit messages, network much higher than that in the connections between a “bad” peer layer defense approaches often find it difficult to effectively and a “good” peer. protect against overlay DDoS attacks. It is therefore a worth- Finally, the nature of free downloading in P2P systems while endeavor to design an overlay level defending mechanism makes peers easily recruited as DDoS agent (slave) peers. It is inside P2P applications. challenging to handle overlay DDoS in P2P systems because of In this paper, we propose a detection based approach, the difficulty in separating attack query traffic from legitimate DD-POLICE (Defending P2Ps from Overlay Distrib- traffic, while it is relatively easy to perform DDoS in P2P with- uted-Denial-of-Service), to protect P2P systems against overlay out being detected. Note that the victim of P2P overlay DDoS is not a single peer but the P2P system itself. This work is supported in part by the U.S. National Science Foundation CCF-0514078, CNS-0549006, CNS-0551464, and Hong Kong RGC grants HKUST6152/06E. equal to q0 /q. If a peer’s general indicator or single indicator is much larger than 1, we will have confidence to disconnect it as a “bad” peer. The two indicators at peer i for peer j in Figure 2 are show here. g( j,t) = 1 + + + + + + + + − − + + ((q0 q2 q3 ) (q0 q1 q2 ) (q0 q1 q3 ) (3 1)(q1 q2 q3 )) 100 × 3 = Figure 1. q sends 5000 queries/min, but it is a ‘good’ peer q0 /100 1 s( j,t,i) = ((q + q + q ) − (q + q )) = q /100. 2.2 Definition of a “good” peer and a “bad” peer 100 0 2 3 2 3 0 In this example g(j,t)=s(j, t ,i)=q0/100, where q0 is the In our model, the definition of a “good” peer is twofold. number of queries issued by peer j per minute. Note that the First, we assume they have the same processing capacity, and assumption that all of peer j’s incoming queries should be they will forward as many incoming queries as they are capable forwarded is not always true. But at least we are sure that g(j, of. Second, a “good” peer will not issue more than 100 queries t) and s(j, t, i) could reflect q /q. per minute. Actually, some observations in [16] show that one 0 peer issues less than 1 query per minute on average. We also have done some experiments in our lab, and no peer ever cre- 2.3 Implementation of an overlay DDoS agent ated more than 40 queries per minute. The assumption that a “good” peer does not issue more than 100 queries per minute We build a traffic-monitoring node to collect queries flood- makes sense as it is hard for a human user to generate more than ing through the Gnutella network. Using a modified LimeWire one query every second. We further model a “bad” peer’s be- [17] client with logging functionality, all queries passing by the havior pattern as it will do everything else as a “good” peer monitoring node are recorded to a log file. The monitoring except that it generates and issues a large number of queries node, as shown in Figure 3, is configured as a super node con- during every time unit. necting to ten peers in the Gnutella network. Our experiment to We quantitatively define a “good” peer and a “bad” peer collect query trace lasted 24 hours. We collected 13, 705, 339 as follows. We use Q (t) to denote the number of queries queries with the size of 112 MB. ih It is easy to design and implement an overlay DDoS agent. sent out (issued plus forwarded) from peer i to peer h during To better study the characteristics of a DDoS agent, a LimeWire the time period from (t-1)th to tth time unit. We assume client is modified and an experiment is conducted as illustrated that a peer j has k neighbors, m , m …m . 1 2 k in Figure 4. We modified the command line version of Definition 2.1 Peer j’s General Indicator at time t is de- LimeWire 2.0.2 by adding a new querying thread to the original mk mk fined as: = 1 − − , where q source code in peer A. The querying thread reads queries from g( j, t) ( ∑ Qjm (t) (k 1) ∑ Qmj (t)) = = qk m m1 m m1 the log file collected by the monitoring node and issues these is the threshold in distinguishing a “good” peer and a “bad” queries, and forwards queries coming from the Gnutella net- peer. We set q=100 based on the above discussion that a work to its neighbors based on the pre-configured time interval. “good” peer does not issue more than 100 queries per min- Thus, peer A may work like an overlay query flooding based ute. DDoS agent, a “bad” peer. Peer B is a “good” peer who never issues any queries and Definition 2.2 Peer j’s Single Indicator measured by its only attempts to forward the queries coming from A.