- Email: [email protected]
Detecting DRDoS attacks by a simple response packet confirmation mechanism
Computer Communications 31 (2008) 3299–3306
Contents lists available at ScienceDirect
Computer Communications journal homepage: www.elsevier.com/locate/comcom
Detecting DRDoS attacks by a simple response packet confirmation mechanism q Hiroshi Tsunoda a,*, Kohei Ohta b, Atsunori Yamamoto c, Nirwan Ansari d, Yuji Waizumi e, Yoshiaki Nemoto e a
Tohoku Institute of Technology, Yagiyama Kasumicho 35-1, Taihaku-ku, Sendai 982-8577, Japan Cyber Solutions Inc., Minami Yoshinari 6-6-3, Aoba-ku, Sendai 989-3204, Japan NTT DATA Corporation, Toyosu Center Buildings, 3-3, Toyosu 3-chome, Koto-ku, Tokyo 135-6033, Japan d Advanced Networking Laboratory, Department of Electrical and Computer Engineering, New Jersey Institute of Technology, Newark, NJ 07102-1982, USA e Graduate School of Information Sciences, TOHOKU University, Aramaki Aza Aoba 6-6-05, Aoba-ku, Sendai 980-8579, Japan b c
a r t i c l e
i n f o
Article history: Received 31 July 2007 Received in revised form 17 May 2008 Accepted 19 May 2008 Available online 7 June 2008 Keywords: Distributed reflection DoS Detection Response confirmation
a b s t r a c t In this paper, we propose a simple and robust method to detect Distributed Reflective Denial of Service (DRDoS) attacks. In DRDoS attacks, the victim is bombarded by reflected response packets from legitimate hosts, and thus it is difficult to distinguish attack packets from legitimate packets. We focus on the fact that the types of packets used for DRDoS are limited and predictable. Hence, the proposed method monitors only limited pairs of requests and responses, and confirms the validity of the received response packets based on the request–response relationship. Therefore, the proposed method does not need complicated state management such as the stateful inspection method, and thus the detection mechanism becomes simple. We also analyze the complexity of the proposed method, and show that the proposed method requires low processing cost as compared with the conventional method. Through experiments using a real networking environment, we demonstrate that the proposed method can accurately detect DRDoS packets at a low cost. Ó 2008 Elsevier B.V. All rights reserved.
1. Introduction Denial of Service (DoS) and Distributed DoS (DDoS) attacks pose a serious threat to the integrity of the Internet. For instance, the infamous massive DDoS attacks on the 13 DNS root servers almost paralyzed the Internet in October 2002. Recently, a more sophisticated type of attacks called Distributed Reflective DoS (DRDoS) attacks [2–5] have emerged. A DRDoS attack uses legitimate hosts called ‘‘reflectors” to send a large number of packets to a victim by using IP spoofing. Since a DRDoS attacker can exploit a host as a reflector if the attacker knows the host’s IP address, the attacker can easily magnify the impact of the attack by using a large number of reflectors, thus effectively increasing the number of attack paths as compared with traditional DDoS attacks. For instance, a DRDoS attack occurred in January 2002 when Gibson research cooperation network was attacked by DRDoS packets resulting in service interruption for several hours [2]. Hundreds of legitimate hosts were used as reflectors and about 1 billion packets were filtered until the attack was halted.
q The preliminary version of this manuscript was presented at ICACT2006[1]. This manuscript presents the enhanced detection mechanism with mathematical analysis and additional experimental results. * Corresponding author. Tel.: +81 22 305 3411. E-mail address: [email protected] (H. Tsunoda).
0140-3664/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2008.05.033
Most of conventional countermeasures to traditional DDoS attacks are insufficient to mitigate DRDoS attacks. To prohibit attackers from sending spoofed packets, ingress filtering is implemented at edge routers [6] to block packets that have invalid source address prefices. Although ingress filtering is a useful solution, implementation of the filter is strictly an administrative decision of each network, and thus it is difficult to extirpate IP spoofing at this time. The primary objective of IP traceback is to identify true sources of the attack packets [7,8], from which the attack damage may be minimized. Several IP traceback schemes, such as hash-based IP traceback [9], ICMP traceback [10], probabilistic packet marking [11], and deterministic packet marking [12,13], have been proposed. However, DRDoS attack traffic reaches a victim via reflectors, and thus conventional traceback schemes may have difficulties in finding the true sources of DRDoS attacks. In this study, we propose to detect DRDoS attacks at the victim side, not at the reflectors, as the first step of any countermeasures. The principal feature of DRDoS attacks is that a victim is bombarded by attack packets sent by legitimate hosts, and the victim cannot distinguish attack packets from legitimate packets by simply inspecting contents of each received packet. Although the sequence of packets is useful information for distinguishing attack packets, keeping track of the sequence requires a complicated process such as the stateful inspection method [14,15]. Since a DRDoS attacker can easily magnify the attack, we have to simplify the
3300
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
detection mechanism to make it more robust. Since our target is to detect DRDoS attacks which can easily magnify the attack, the robustness of the detection system is a significant requirement. Therefore, we propose a simple method without complicated state management for DRDoS detection in this paper. The proposed method focuses on the fact that the types of the response packets received by a victim are predictable based on the corresponding types of the request packets. The remainder of this paper is organized as follows. Section 2 briefly describes the mechanism and characteristics of DRDoS attacks. Section 3 provides an overview of existing countermeasures against DRDoS attacks. In Section 4, we propose a simple response packet confirmation mechanism to detect DRDoS packets. Section 5 presents the design of the DRDoS detection system by using the proposed mechanism along with the complexity analysis of the proposed method. The performance of the proposed method is evaluated in Section 6. Finally, conclusions are drawn in Section 7.
cited by application protocols which use UDP as the transport protocol. DNS and SNMP are known application protocols that make use of the request–response relationship. In Table 1, we can categorize response packets into two groups. One is a response to a request which has been accepted, and the other is a response to a request which has not been accepted. The former type of response packets includes TCP SYN/ACK, DNS reply, SNMP response, and ICMP reply. The rest belong to the later type of response packets. The attacker launching a DRDoS attack can send any type of packets as a request, but types of response packets are predictable and limited by protocol specifications. For example, even if the attacker sends a protocol-violating request packet, the reflector simply responds with ‘‘the request has not been accepted” according to the protocol specifications. Therefore, a response packet itself is definitely valid assuming that a reflector is not compromised. This implies that the attacker cannot directly control attack packets generated by the reflector to avoid detection.
2. Distributed reflection DoS attacks
2.2. Characteristics
2.1. Mechanism
In this section, we highlight the characteristics of DRDoS attacks as compared with traditional DDoS attacks. Since the victim is assaulted by attack packets sent by legitimate hosts (i.e., reflectors), these innocent reflectors are perceived as attackers. Thus, it will take a longer time to determine the real attacker. Unlike a DDoS attack which needs to enslave hosts by compromising these hosts, the attacker of a DRDoS attack can orchestrate a large number of attack sources easily. Since the attacker needs to know only the IP address of a host to use it as a reflector, most of the hosts (any server, client, router, switch, or device which runs on the TCP/IP protocol stack) in the Internet can potentially be used as reflectors. As a result, it is possible to attack the victim with a small amount of traffic from each reflector. This characteristic poses great difficulties for reflectors to detect such attacks. Besides, the attacker can also easily shift the attack source, i.e., the so-called ‘‘reflector usage phasing” [2]. The packet amplification allows the attacker to effectively reduce the number of request packets and to evade detection; it is made possible by exploiting the TCP retransmission mechanism [18], IP broadcast (e.g., Smurf), or application specific behaviors such as DNS recursive query [19]. For example, in response to TCP SYN issued by the attacker, the reflector sends SYN/ACK to the victim. At this time, if the bandwidth between the reflector and the victim is fully flooded, the SYN/ACK packet will be dropped and retransmitted. Consequently, the number of response packets can be larger than that of request packets.
DRDoS attacks capitalize on the reflector’s ability of generating messages in reply to other messages [4]. In other words, the ‘‘request–response” relationship is a key to DRDoS attacks. Here, the ‘‘response” is the generated message, and the ‘‘request” is the trigger of the ‘‘response”. When a DRDoS attacker sends request packets to a reflector, source addresses of the request packets are spoofed as the victim’s IP address. Thus, the reflector sends response packets to the victim in reply to the spoofed requests. These response packets become real attack packets against the victim. For example, Smurf [16] is a classical and a well-known type of DRDoS attack. The attacker sends ICMP echo request packets as request packets to a subnet-directed broadcast address. In this case, all of the hosts in the subnet become reflectors, which issue a large number of ICMP echo reply packets assaulting the victim. The Fraggle attack [17] is a variant of Smurf. In the Fraggle attack, instead of using ICMP echo request packets, the attacker sends request packets to reflectors for services such as UDP echo, chargen, daytime, or quotd in a similar fashion as that of Smurf. Today, to protect against these types of attacks, hosts in the Internet are recommeded to ignore ICMP echo request to the broadcast address and to stop unused services. However, there are various ways to launch DRDoS attacks other than Smurf and Fraggle, and therefore we need to consider more comprehensive countermeasures. A DRDoS attacker can exploit any protocol that supports automatic message generation to launch attacks. For example, TCP, UDP, various ICMP messages, and application protocol messages can be used to launch DRDoS attacks. Typical types of response packets and their correspondent request types are summarized in Table 1. Note that UDP itself does not posses the automatic message generation ability, and request–response relationships are in-
Table 1 Examples of request and response pair used by DRDoS attacks Request
Response
TCP SYN packets to open TCP ports TCP packets to closed TCP ports DNS query packets SNMP request packets UDP packets to closed UDP ports ICMP requests (e.g., echo request) IP packets
TCP SYN/ACK packets TCP RST packets DNS reply packets SNMP response packets ICMP port unreach. msg. ICMP replies (e.g., echo reply) ICMP time exceeded msg
3. Issues in conventional countermeasures Although various countermeasures have been proposed to mitigate conventional DDoS attacks, they are not effective to combat against DRDoS attacks. Basically, since all of attack packets are sent by a large number of innocent reflectors, source address filtering based on pre-configured black-list will not work. Even if the black-list can be updated dynamically as proposed in [20], the attacker can easily bypass such list by reflector usage phasing [2]. Also note that filtering based on source addresses can refuse normal communication between the victim and the host which is used as a reflector as well. For conventional DDoS attacks, identifying the attacker by IP traceback techniques have received much attention [7,8], and various IP traceback techniques [10,21,9,22,12,23–25] have been proposed. However, it is difficult, if not impossible, for them to trace attack traffic arrived at the victim via reflectors.
3301
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
To detect DRDoS attacks at a reflector, Peng et al. [26] proposed to share information about illegal traffic among potential reflectors. In addition, Jin et al. [27] proposed a detecting and filtering method of spoofed packets at the reflector based on the mapping between the hop-count and the source IP address. A reflector, which can detect and filter the attack packets, can certainly minimize the damage to victims. However, deploying such detection mechanisms on all potential reflectors is not realistic because all hosts in the Internet are potential reflectors. Moreover, since a DRDoS attacker can limit the number of packets sent to each reflector by using a large number of reflectors, it is difficult to detect attacks orchestrated through reflectors. Consequently, it is still necessary to detect DRDoS attacks at the victim side. Peng et al. [28] have proposed a mechanism by using source IP address monitoring for detecting DDoS attacks. Their proposed method uses the number of new source IP addresses monitored at the victim as a detection feature, and it can be applied to the detection of DRDoS attacks. However, if a DRDoS attacker uses popular servers as reflectors, it is difficult to detect an attack by using such detection feature. In DRDoS attacks, response packets themselves are always valid, and thus the detection process must validate a received response packet based on protocol specifications. The most famous technique for performing such validation is the stateful inspection technique developed by Check Point Software Technology [14]. In the stateful inspection process, a state is defined for each connection, and the state is constantly updated with information carried in every sending and receiving packet belonging to the connection. If the protocol-violating state transition is found, the packet triggering such transition is detected as the illegal packet. The stateful inspection technique has been implemented in various IDSs and firewalls [15], but its complexity is rather high because this technique needs to investigate every packet in a connection and keep track of the packet sequence. Therefore, the stateful inspection is too complex to detect DRDoS attacks because a response packet is the target of detection in the case of DRDoS attacks. As mentioned above, types of attack packets used for DRDoS are predictable, and we thus propose a simple mechanism to detect attack packets at the victim side. 4. A simple mechanism for confirming response packets 4.1. Overview of the proposed method The proposed method focuses on only pairs of request and response packets, and does not need to manage the complicated state transition of any protocol such as TCP. For a legal response packet, the corresponding valid request packet should be monitored before. Within the context of DRDoS attacks, it is realistic to assume that the victim is not compromised and any request originated from the victim is valid. Fig. 1 illustrates the concept of the proposed detection method. In the proposed method, the detector will be deployed next to the victim or at the border of the network to which the victim
Correct Response Victim
Confirm
resides. For a valid response, the detector can monitor both request and response packets. In this case, the validity of the response packet is confirmed because there is a bidirectional action of request–response. On the other hand, for the reflected response, the detector monitors only a response packet, and there is no bidirectional action. In this case, the confirmation of the response packet fails. Since only limited and predictable types of packets can be used for such attacks as previously mentioned, it is possible to accurately detect a reflected response by checking only the limited types of request–response pairs. This characteristic significantly simplifies the detection procedure in the proposed method. In the proposed method based on the limited types of request packets that an attacker can stage a DRDoS attack, the detector can compose and store potential response packets in its buffer for each request packet. When a response packet sent to the victim is monitored, the detector compares this response packet with the stored potential response packets. If there is a match, the monitored response packet is considered valid. Otherwise, it is detected as an invalid response. The detailed system design will be described in Section 5. Obviously, this proposed method depends on the certainty of request–response pairs. In the next section, we will discuss the potential ambiguity exhibited in typical cases of actual inspection. 4.2. Request–response relationship Depending on the type of a response packet, two request–response relationships exist, namely, the one-to-one case and the many-to-one case, as shown in Fig. 2. In the proposed method, the detector has to compose response packets for each monitored request packet. Thus, to confirm the validity of a response packet we have to first define the types of request packets that will result in such a response. For the one-to-one case, it is easy to determine the unique request packet for a given response packet. Therefore, the definition of a request packet is clear in this case. Response packets with this type of one-to-one relationship are referred to as clear response packets. On the other hand, for the many-to-one case, several request packets may correspond to a given response packet. Hence, the definition of a request packet is ambiguous. Response packets with this type of many-to-one relationship are referred to as ambiguous response packets. We shall next elaborate on the types of request and response packets within the context of the request–response relationship of a DRDoS attack. 4.2.1. One-to-one relationship For the one-to-one relationship, we can easily predict the response packet for a given request packet. As mentioned in Section 2, an attacker can use any type of packet as a request packet. However, assuming that a protocol violated packet is never sent by the victim, the detector only needs to monitor the following packets as request packets:
Reflected Response Confirm(failed)
Detector Request
Response
Legitimate Host
Request should exist
Reflected Response
Clear Response (one-to-one)
Ambiguous Response (many-to-one)
One Request One Response
Many Requests One Response
Victim Detector
Spoofed Request
Attacker Fig. 1. Concept of the proposed method.
Legitimate Host Fig. 2. Relationship between request and response packets.
3302
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
Packets that initiate communication (e.g., TCP SYN, SCTP INIT) Packets that request some sort of information (e.g., DNS Query, SNMP Request, ICMP Request) For each request packet, the correspondent response packet should satisfy the following minimal conditions: For IP header – Src./Dst. address pair should be the same. – Protocol field should have the same value. For TCP/UDP headers – Src./Dst. port number pair should be the same. For ICMP header – Type field should correspond to that of the request, e.g., echo request (Type:8) and reply (Type:0). – ID and sequence number should be the same.
Additional conditions should be considered for TCP and UDP. As previously mentioned, for UDP, the request–response relationship depends on the application level protocol. Thus, we only consider the cases where such relationship exists in the application level. For TCP – Correspondent flag (SYN/ACK) is set. – Acknowledgment number of the response packet is greater than the sequence number of the request packet by only one. For UDP – There is the request–response relationship in the application protocol level header. For example, the ID values are the same for correspondent DNS request and response.
The detector composes potential response packets based on the above conditions. Clearly, in the case of a valid response, this type of response packets should be monitored at the detector in the RTT time-scale since the correspondent request packet was actually sent. Therefore, in order to correctly confirm the validity of this type of response packets, the detector should have a buffer large enough for keeping potential response packets in the RTT time-scale. The required buffer size will be discussed in Section 5.3. 4.2.2. Many-to-one relationship The previous section considers request and response packets that exhibit the one-to-one relationship. However, several request and response packets do not follow the one-to-one relationship. For example, in the case of a TCP connection interruption, every packet belonging to the interrupted connection can result in an RST packet, i.e., a response packet. Therefore, an RST packet has a many-to-one relationship with all TCP packets. Similarly, an ICMP destination unreachable packet has a many-to-one relationship with all IP packets. These error related packets can be generated anywhere, anytime, and for any type of packets. Thus, it is difficult to strictly establish the request–response relationship. In this case, we choose an alternative request packet instead of the actual request, and approximate the many-to-one relationship by a one-to-one relationship. For connection-oriented protocols, a packet for initiating a connection becomes an alternative request packet. For TCP, the SYN packet of each connection initiated by the victim side is the alternative request packet of an RST packet and an ICMP destination unreachable packet. If a connection is ini-
tiated by the other communicating end (i.e., SYN packet is sent to the victim), SYN/ACK packet sent by the victim is the alternative request packet. Therefore, when a SYN or a SYN/ACK packet is monitored, the detector composes an RST packet and an ICMP destination unreachable packet as potential responses. Note that the sequence number and the acknowledgment number fields in the TCP header should be ignored for request–response matching in this case. For UDP, which is not connection-oriented, each packet sent by the victim becomes a request packet for an ICMP destination unreachable packet. This approximation reduces the accuracy of detection, which will be elaborated further in Section 6. In terms of the buffer size for correctly validating ambiguous response packets, the detector should have a buffer large enough to store the potential response for the connection duration time. This means that the buffer size is larger than that of the previous case (i.e., one-to-one relationship case). The required buffer size will also be discussed in Section 5.3. 5. The detection system using the proposed confirmation mechanism 5.1. Basic architecture Fig. 3 illustrates the basic architecture of the proposed detection system, which comprises a translator, a comparator, and two buffers: the short-term (RTT time scale) buffer and the long-term (connection duration time scale) buffer. The short-term buffer and the long-term buffer are used to store the composed clear response packets and ambiguous response packets, respectively. For the sake of simplicity for describing the detection system, we assume that the buffer is a cyclic buffer with a constant buffer size. The detector monitors packets sent and received by a victim. If a request packet sent by the victim is monitored, the translator translates the monitored request packet into potential response packets that the request packet can possibly cause. If the potential response packet is a clear response packet, the packet is stored in the short-term buffer. On the other hand, if the potential response packet is an ambiguous response packet, the packet is stored in the long-term buffer. When the detector monitors a response packet, the detector selects the targeted buffer according to the type of the monitored response packet. Then, the comparator compares the monitored packet with each potential response packet in the selected buffer. If the potential response packet and the monitored packet have the same information, it implies that the correspondent request packet has been monitored before. In this case, the proposed method determines that the monitored response packet is valid. Otherwise, the monitored response packet is unexpected, and is thus considered invalid.
Request Packet from the Victim
Detector Response Packet to the Victim
Clear Response Packet Translator Short-term Buffer
Comparator Long-term Buffer
Potential Response Packets
Ambigous Response Packet Output Detection Result Fig. 3. Basic architecture of the proposed detection system.
3303
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
The roles of the detector are only to compose potential response packets, and to match observed response packets with stored potential response packets. Thus, unlike stateful inspection, the proposed method can detect unexpected and invalid packets in a stateless manner. 5.2. Complexity of the proposed detection method We formulate the complexity of the proposed method, and compare it with that of the stateful inspection method, currently available state of the art. For both methods, the detector carries out the following three processes in the detection procedure. Creation of an entry to be stored in the buffer. Searching an entry in the buffer. Updating an entry in the buffer. An entry is either a composed potential response packet for the proposed method, or a state defined for a connection for the stateful inspection method. Our formulation is based on the number of occurrences of these events (creation, search, update) in each method. Although the complexity of each search depends on the data structure of the buffer, we just count the number of entry searches for the sake of simplicity. In the following evaluation, N c ðtÞ; N s ðtÞ, and N u ðtÞ stand for the number of entry creation, search, and update processes in the time slot ½t; t þ Dt, where Dt is the maximum time slot supported by the cyclic buffers, respectively. First, we summarize the parameters and their corresponding definitions used in the following evaluation in Table 2. In the proposed method, the number of entries created in Dt equals to the number of composed potential response packets. As mentioned in Section 4.2, there are two types of response packets: clear and ambiguous, and a request packet is defined for each response packet. Denote ai as the number of clear response packets for a type i request packet, and bi as the number of ambiguous response packets for a type i request packet. Note that the maximum value of ai is one because only one clear response packet is defined for a given request packet. When the number of types of requests sent by the victim is V req ; N c ðtÞ becomes
Nc ðtÞ ¼
V req X fsreq i ðtÞ ðai þ bi Þg;
ð1Þ
i
where sreq i ðtÞ denotes the number of type i request packets sent by the victim in the time slot ½t; t þ Dt. For detecting reflected response packets, the detector monitors PV V resp ¼ i req ðai þ bi Þ types of incoming response packets. For each monitored response packet, the detector searches for the correspondent potential response packets within its buffer. Therefore, the number of entry search processes in the time slot ½t; t þ Dt; N s ðtÞ, can be expressed as
Table 2 Parameters and corresponding definitions Parameter
Definition
V req
# of types of requests sent by the victim # of clear response packets for a type i request packet # of ambiguous response packets for a type i request packet # of type i request packets sent by the victim in the time slot ½t; t þ Dt # of type j response packets received by the victim in the time slot ½t; t þ Dt # of connections # of packets in connection c in the time slot ½t; t þ Dt # of entry searches for which a correspondent state is not found
ai bi sreq ðtÞ i rresp ðtÞ j N conn nc ðtÞ d
Ns ðtÞ ¼
V resp X
r resp ðtÞ; j
ð2Þ
i
where r resp ðtÞ denotes the number of type j response packets rej ceived by the victim in the time slot ½t; t þ Dt. Obviously, the proposed method does not update stored entries for detecting reflection attacks. Thus, N u ðtÞ equals zero. On the other hand, in the stateful inspection method, an entry is a state which is defined for each TCP connection, UDP session, or ICMP session. In addition, each created entry is updated packet by packet based on information in packets belonging to the same connection, in order to keep track of the sequence of packets in the connection. Hence, the stateful inspection method requires more entry searches and entry updates. The detector creates a state for each request packet of a connectio, and N c ðtÞ becomes
Nc ðtÞ ¼
V req X req fsreq i ðtÞ þ r i ðtÞg;
ð3Þ
i
where rreq i ðtÞ denotes the number of type i request packets received by the victim in the time slot ½t; t þ Dt. The stateful inspection method needs to keep the state updated for validating a currently monitored packet. Therefore, for each incoming/outgoing packet, the detector searches for and updates the correspondent state within its buffer with the information included in the monitored packet. Consequently, the stateful inspection method needs a large number of entry search and update processes for validating legitimate connections. As a result, N s ðtÞ and N u ðtÞ are defined as
Ns ðtÞ ¼ Nu ðtÞ ¼
XNconn c
nc ðtÞ;
ð4Þ
nc ðtÞ d;
ð5Þ
XNconn c
where N conn and nc ðtÞ denote the total number of connections, and the number of packets in connection c in the time slot ½t; t þ Dt, respectively. Note that d denotes the number of entry searches for which a correspondent state is not found. Table 3 summarizes the complexity of both methods. Since the proposed method focuses only on the limited types of packets (i.e., response packets), the number of search events can be drastically reduced as compared with the stateful inspection method. In addition, no update events are required for the proposed method. Considering the fact that the stateful inspection is widely used to detect and filter illegal packets in a firewall, we believe that the proposed method, which is computationally more efficient and can work on-the-fly, can be readily installed for the next generation firewalls and IDSs. 5.3. Required buffer size Here, we analyze the required buffer size for the proposed method. As shown in Fig. 3, composed clear response packets and ambiguous response packets are stored in the short-term buffer and the long-term buffer, respectively. The short-term buffer should keep each clear response packet in the RTT time scale, T s slots. Thus, the required buffer size is proportional to the number of entries stored in the short-term buffer during T s slots. The number of entries, Bs , can be computed as follows: Table 3 The complexity of the proposed method and the stateful inspection method
Proposed method Stateful inspection
# of state creation PV req req fs ðtÞ ðai þ bi Þg PiV req ireq fsi ðtÞ þ r req ðtÞg i i
# of search PV resp resp r ðtÞ PiNconn i ni ðtÞ i
# of update 0 PNconn i
ni ðtÞ d
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
Bs ¼ T s
V req X fsreq i ðtÞ ai g:
ð6Þ
i
Similarly, the long-term buffer should keep each ambiguous response packet for the connection duration scale, T l slots ðT s T l Þ. Thus, the required buffer size is proportional to the number of entries stored in the long-term buffer during T l slots. The number of entries, Bl , becomes
Bl ¼ T l
V req X fsreq i ðtÞ bi g:
ð7Þ
i
For the stateful inspection method, the detector should also have the buffer large enough to keep states for the connection duration scale. Therefore, the number of entries, B, becomes
B ¼ Tl
V req X req fsreq i ðtÞ þ r i ðtÞg:
ð8Þ
i
T s and T l are determined based on the maximum RTT and connection duration in the normal situation. In the evaluation of the proposed method in the following section, the buffer size is determined based on the above equations. 6. Evaluation of the proposed method We evaluate the processing cost of the proposed method, and compare it with that of the stateful inspection method [15]. 6.1. Evaluation environment The experimental environment is setup by using a real network consisting of 50 hosts, as shown in Fig. 4. The victim is one of the hosts in network A, and the attacker and the reflector are located in another network (network B) in the same campus. The attacker sends 1000 spoofed TCP SYN packets as requests to the reflector within three hours, which reflects TCP SYN/ACK or RST packets as responses to the victim. We trace incoming/outgoing traffic at the gateway of the laboratory’s network. The traffic trace, which contains attack packets, is used for evaluation by off-line simulations. In this evaluation, to detect DRDoS attacks based on TCP, the proposed method and stateful inspection method inspect only TCP packets in the traffic trace. The traffic trace includes a total of about 670,000 incoming/outgoing TCP packets. The focus of the detection is on the response packets included in the incoming traffic. Since DRDoS packets always do not have the correspondent entry in the buffer despite the number of attackers, all DRDoS packets will be detected by both the proposed method and the stateful
6.2. Buffer size configuration The buffer size of the proposed detection system is determined based on the statistics of a traffic trace in this environment. In this environment, a maximum of 50 request packets (SYN and SYN/ACK) per second (i.e., Dt is 1 s) are sent from the inside of the victim network (network A in Fig. 4). Since the correspondent clear response packet is a SYN/ACK packet for a SYN packet, ai is one for a SYN packet. On the other hand, there are no clear response packets for a SYN/ACK packet, and thus ai is zero for a SYN/ ACK packet. Fig. 5 shows the 3-month cumulative distribution of the RTT value calculated by the intervals between correspondent SYN and SYN/ACK packet pairs. As shown in the figure, the RTT value of more than 99.8% connections are less than one second. Therefore, we set T s to 1 s. As a result, we set the short-term buffer size Bs to 1 50 1 ¼ 50 entries. Fig. 6 shows the cumulative distribution of the lifetime of interrupted connections. As shown in the figure, the lifetime of more than 99.8% interrupted connections are less than 600 s. According to this result, we set T l to 600 s. Since a RST packet is an ambiguous response packet to SYN and SYN/ACK packets, bi is one for both SYN and SYN/ACK packets. As a result, we set the long-term buffer size Bl to 600 50 1 ¼ 30; 000 entries.
100
80
60
40
20
0
0
0.1
Spoofed Request Packets
Reflector
0.2
0.3
0.4
0.5
0.7
0.8
Fig. 5. Cumulative distribution of RTT of connections.
Victim
Detector Reflected Response Packets
network B (other network in the same campus)
0.6
RTT[sec]
Gateway / Firewall
Internet
Attacker
inspection method. On the other hand, false positives may be generated depending on the buffer size. Consequently, the accuracy may be degraded mainly due to false positives (not false negatives), and we thus focuses on the number of false positives.
Cumulative distribution[%]
3304
50 clients
network A (Laboratory’s network)
Fig. 4. Experimental environment.
0.9
1
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
Cumulative distribution [%]
100
90
80
70
60
50
0
200
400
600
800
1000
Lifetime of interrupted connections [sec] Fig. 6. Cumulative distribution of the lifetime of interrupted connections.
Since 50 request packets (SYN and SYN/ACK) are sent from the inside of the victim network as previously mentioned, the buffer size for the stateful inspection method, B, is set to 600 50 ¼ 30; 000 entries.
3305
from a host in the external network. In this experimental environment in which the detector is located outside the firewall, a SYN packet for a service prohibited by the firewall is monitored at the detector, and then filtered out at the firewall. The host attempting to initiate the connection finally sends an RST packet, and this RST packet is falsely detected only by the proposed method. In the stateful inspection method, the detector creates a state in its buffer for even this kind of SYN packets. Thus, the RST packet can be confirmed. In the proposed method, the request packet which result in an RST packet can only be SYN or SYN/ACK packets sent by the victim, and both types of request packets are not sent in this case. Therefore, the potential response packets are never composed in the proposed method, and the confirmation of the RST packet fails (i.e., the RST packet is detected as a DRDoS attack packet). This is the cause for 29 extra packets falsely detected by the proposed method. However, if the detector is located inside the firewall, such RST packet will also be filtered out at the firewall, and the detector would not have monitored such RST packets. This means that this type of false positives can be easily eliminated. Consequently, we conclude that the proposed method can detect invalid response packets with an accuracy as the high as that of stateful inspection with much less processing cost.
6.3. Evaluation results
7. Conclusions
The numbers of entry creations, searches, and updates shown in Table 4 are used to evaluate the processing cost. It is clear that the proposed method can detect invalid response packets with fewer events than the stateful inspection. In term of the actual elapsed time for processing and analyzing, the proposed method is more than nine times faster than the stateful method. It takes 1.6 s to process 670,000 TCP packets using Intel Xeon CPU 3.06 GHz. The stateful inspection needs 14.9 s under the same conditions. Table 5 shows the detection results. Both methods can detect all reflected attack packets. Further investigation on the extra 91 packets and 61 packets detected by the two respective methods reveals that most of the other extra packets are unexpected SYN/ACK or RST packets not corresponding to any packets sent before. Since source port numbers of these packets are 22 (ssh), 80 (http), or 7000 (afs3-fileserver), and the source address of the packet which has the same source port number is also the same, these packets are possibly reflected response packets, and are not false positives. For both methods, a long-lived connection can be the cause for false positives. In this evaluation, three or four RST packets are falsely detected for each method. These RST packets arrive 10 min after the last packet is arrived, and the potential response packet for confirming these packets are already deleted from the buffer. Some false positives are generated by the proposed method. The largest difference between the proposed method and the stateful inspection is the treatment of cases when connections are initiated
In this paper, we have proposed a simple response packet confirmation method specialized for DRDoS detection. DRDoS attacks, in which victims of DRDoS are attacked by response packets reflected from legitimate hosts, are emerging threats in the Internet. To detect such packets, received response packets have to be confirmed. Unlike stateful inspection which needs to monitor all packets for state management, the proposed method needs to monitor only limited types of request and response packets. We have analyzed the complexity of the proposed method in terms of the number of entry creation, search, and update events required to detect attack packets. The analysis result shows that the proposed method can drastically reduce the complexity as compared to that of the stateful inspection method. Through experiments using real traffic traces, we have also verified that the numbers of entry creations, searches, and updates required by the proposed method are much smaller than those of the stateful inspection method. Although the proposed method incurs additional false positives as compared with the stateful inspection method, such false positives can be easily eliminated by placing the detector appropriately (such as behind the firewall). In conclusion, the proposed method is simple and robust in detecting DRDoS attacks, and can be incorporated in the next-generation firewalls and IDSs.
Table 4 The numbers of entry creations, searches, and updates
Proposed method Stateful inspection
# of entry creations
# of searches
# of updates
14,274 10,773
8,270 672,406
0 660,583
Table 5 Detection results
Proposed method Stateful inspection
# of attacks
# of detected
1000 1000
1091 1061
References [1] H. Tsunoda, K. Ohta, A. Yamamoto, Y. Nemoto, A simple response packet confirmation method for DRDoS Detection, in: Proceedings of the 8th International Conference on Advanced Communication Technology (ICACT), 2006. [2] S. Gibson, DRDoS: Description and analysis of a potent, increasingly prevalent, and worrisome Internet attack, Available from: (Feb. 2002). [3] C. Douligeris, A. Mitrokotsa, DDoS attacks and defense mechanisms: classification and state-of-the-art, Comupter Networks 44 (2004) 643– 666. [4] R. Chang, Defending against flooding-based distributed denial-of-service attacks: a tutorial, IEEE Communication Magazine 40 (10) (2002) 42–51. [5] V. Paxson, An analysis of using reflectors for distributed denial-of-service attacks, ACM Computer Communication Review 31 (3) (2001) 38–47. [6] P. Ferguson, D. Senie, Network ingress filtering: defeating denial of service attacks which employ ip source address spoofing, RFC2827, Available from: (May 2000). [7] A. Belenky, N. Ansari, On IP Traceback, IEEE Communications Magazine 41 (7) (2003) 142–153.
3306
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
[8] Z. Gao, N. Ansari, Tracing cyber attacks from the practical perspective, IEEE Communications Magazine 43 (5) (2005) 123–131. [9] A. Snoeren, C. Partridge, L. Sanchez, C. Jones, F. Tchakountio, S. Kent, W. Strayer, Hash-based IP traceback, in: Proceedings of the ACM SIGCOMM , 2001, pp. 3–14. [10] S. Bellovin, M. Leech, T. Taylor, ICMP traceback messages, internet draft: draftietf-itrace-04.txt (Feb. 2003). [11] S. Savage, D. Wetherall, A. Karlin, T. Anderson, Network support for IP traceback, ACM/IEEE Transactions on Networking 9 (3) (2001) 226–237. [12] A. Belenky, N. Ansari, IP traceback with deterministic packet marking, IEEE Communications Letter 7 (4) (2003) 162–164. [13] A. Belenky, N. Ansari, On deterministic packet marking (DPM), Computer Networks 51 (10) (2007) 2677–2700. [14] Stateful Inspection Technology (The industry standard for enterprise-class network security solutions), Available from: (Aug. 8. 2005). [15] G. van Rooij, Real Stateful TCP Packet Filtering in IP Filter, in: Proceedings of the 10th USENIX Security Symposium, 2001. [16] CERT Advisory CA-1998-01 Smurf IP Denial of Service Attacks, Available from: (1998). [17] A. Householder, A. Manion, L. Pesante, G.M. Weaver, R. Thomas, Managing the threat of denial-of-service attacks, Available from: (2001). [18] J. Postel, Transmission control protocol, RFC793 (also STD0007) (Sep. 1981). [19] P. Mockapetris, Domain names – concepts and facilities, RFC1034 (also STD0013) (Nov. 1987).
[20] Y. Xu, H.C.J. Lee, A source address filtering firewall to defend against denial of service attacks, in: Proceedings of the 60th IEEE Vehicular Technology Conference, 2004, pp. 3296–3300. [21] S. Savage, D. Wetherall, A. Karlin, T. Anderson, Practical network support for IP traceback, IEEE/ACM Transactions on Networking 9 (3) (2001) 226–237. [22] A. Snoeren, C. Partridge, L. Sanchez, C. Jones, F. Tchakountio, B. Schwartz, S.T. Kent, W.T. Strayer, Single-packet IP traceback, IEEE/ACM Transactions on Networking 10 (6) (2002) 721–734. [23] A. Belenky, N. Ansari, Tracing multiple attakers with deterministic packet marking (DPM), in: Proceedings of the IEEE Pacific Rim Conference on Communications, Computers, and Signal Processing, 2003, pp. 49–52. [24] G. Mansfield, K. Ohta, Y. Takei, N. Kato, Y. Nemoto, Towards trapping wily intruders in the large, Computer Networks 34 (2000) 659–670. [25] K. Ohta, G. Mansfield, Y. Takei, N. Kato, Y. Nemoto, Detection, defense, and tracking of internet-wide illegal access in a distriuted manner, in: Proceedings of the INET2000, Yokohama, Japan, 2000. [26] T. Peng, Detecting reflector attacks by sharing beliefs, in: Proceedings of the 46th IEEE Global Telecommunications Conference (GLOBECOM’03), 2003, pp. 1358–1362. [27] C. Jin, H. Wang, K. Shin, Hop-count filtering: an effective defense against spoofed traffic, in: Proceedings of the 10th ACM International Conference on Computer and Communications Security (CCS), 2003, pp. 30–41. [28] T. Peng, C. Leckie, K. Ramamohanarao, Proactively detecting distributed denial of service attacks using source IP address monitoring, in: Proceedings of the Third International IFIP-TC6 Networking Conference (Networking 2004), 2004, pp. 771–782.
Contents lists available at ScienceDirect
Computer Communications journal homepage: www.elsevier.com/locate/comcom
Detecting DRDoS attacks by a simple response packet confirmation mechanism q Hiroshi Tsunoda a,*, Kohei Ohta b, Atsunori Yamamoto c, Nirwan Ansari d, Yuji Waizumi e, Yoshiaki Nemoto e a
Tohoku Institute of Technology, Yagiyama Kasumicho 35-1, Taihaku-ku, Sendai 982-8577, Japan Cyber Solutions Inc., Minami Yoshinari 6-6-3, Aoba-ku, Sendai 989-3204, Japan NTT DATA Corporation, Toyosu Center Buildings, 3-3, Toyosu 3-chome, Koto-ku, Tokyo 135-6033, Japan d Advanced Networking Laboratory, Department of Electrical and Computer Engineering, New Jersey Institute of Technology, Newark, NJ 07102-1982, USA e Graduate School of Information Sciences, TOHOKU University, Aramaki Aza Aoba 6-6-05, Aoba-ku, Sendai 980-8579, Japan b c
a r t i c l e
i n f o
Article history: Received 31 July 2007 Received in revised form 17 May 2008 Accepted 19 May 2008 Available online 7 June 2008 Keywords: Distributed reflection DoS Detection Response confirmation
a b s t r a c t In this paper, we propose a simple and robust method to detect Distributed Reflective Denial of Service (DRDoS) attacks. In DRDoS attacks, the victim is bombarded by reflected response packets from legitimate hosts, and thus it is difficult to distinguish attack packets from legitimate packets. We focus on the fact that the types of packets used for DRDoS are limited and predictable. Hence, the proposed method monitors only limited pairs of requests and responses, and confirms the validity of the received response packets based on the request–response relationship. Therefore, the proposed method does not need complicated state management such as the stateful inspection method, and thus the detection mechanism becomes simple. We also analyze the complexity of the proposed method, and show that the proposed method requires low processing cost as compared with the conventional method. Through experiments using a real networking environment, we demonstrate that the proposed method can accurately detect DRDoS packets at a low cost. Ó 2008 Elsevier B.V. All rights reserved.
1. Introduction Denial of Service (DoS) and Distributed DoS (DDoS) attacks pose a serious threat to the integrity of the Internet. For instance, the infamous massive DDoS attacks on the 13 DNS root servers almost paralyzed the Internet in October 2002. Recently, a more sophisticated type of attacks called Distributed Reflective DoS (DRDoS) attacks [2–5] have emerged. A DRDoS attack uses legitimate hosts called ‘‘reflectors” to send a large number of packets to a victim by using IP spoofing. Since a DRDoS attacker can exploit a host as a reflector if the attacker knows the host’s IP address, the attacker can easily magnify the impact of the attack by using a large number of reflectors, thus effectively increasing the number of attack paths as compared with traditional DDoS attacks. For instance, a DRDoS attack occurred in January 2002 when Gibson research cooperation network was attacked by DRDoS packets resulting in service interruption for several hours [2]. Hundreds of legitimate hosts were used as reflectors and about 1 billion packets were filtered until the attack was halted.
q The preliminary version of this manuscript was presented at ICACT2006[1]. This manuscript presents the enhanced detection mechanism with mathematical analysis and additional experimental results. * Corresponding author. Tel.: +81 22 305 3411. E-mail address: [email protected] (H. Tsunoda).
0140-3664/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2008.05.033
Most of conventional countermeasures to traditional DDoS attacks are insufficient to mitigate DRDoS attacks. To prohibit attackers from sending spoofed packets, ingress filtering is implemented at edge routers [6] to block packets that have invalid source address prefices. Although ingress filtering is a useful solution, implementation of the filter is strictly an administrative decision of each network, and thus it is difficult to extirpate IP spoofing at this time. The primary objective of IP traceback is to identify true sources of the attack packets [7,8], from which the attack damage may be minimized. Several IP traceback schemes, such as hash-based IP traceback [9], ICMP traceback [10], probabilistic packet marking [11], and deterministic packet marking [12,13], have been proposed. However, DRDoS attack traffic reaches a victim via reflectors, and thus conventional traceback schemes may have difficulties in finding the true sources of DRDoS attacks. In this study, we propose to detect DRDoS attacks at the victim side, not at the reflectors, as the first step of any countermeasures. The principal feature of DRDoS attacks is that a victim is bombarded by attack packets sent by legitimate hosts, and the victim cannot distinguish attack packets from legitimate packets by simply inspecting contents of each received packet. Although the sequence of packets is useful information for distinguishing attack packets, keeping track of the sequence requires a complicated process such as the stateful inspection method [14,15]. Since a DRDoS attacker can easily magnify the attack, we have to simplify the
3300
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
detection mechanism to make it more robust. Since our target is to detect DRDoS attacks which can easily magnify the attack, the robustness of the detection system is a significant requirement. Therefore, we propose a simple method without complicated state management for DRDoS detection in this paper. The proposed method focuses on the fact that the types of the response packets received by a victim are predictable based on the corresponding types of the request packets. The remainder of this paper is organized as follows. Section 2 briefly describes the mechanism and characteristics of DRDoS attacks. Section 3 provides an overview of existing countermeasures against DRDoS attacks. In Section 4, we propose a simple response packet confirmation mechanism to detect DRDoS packets. Section 5 presents the design of the DRDoS detection system by using the proposed mechanism along with the complexity analysis of the proposed method. The performance of the proposed method is evaluated in Section 6. Finally, conclusions are drawn in Section 7.
cited by application protocols which use UDP as the transport protocol. DNS and SNMP are known application protocols that make use of the request–response relationship. In Table 1, we can categorize response packets into two groups. One is a response to a request which has been accepted, and the other is a response to a request which has not been accepted. The former type of response packets includes TCP SYN/ACK, DNS reply, SNMP response, and ICMP reply. The rest belong to the later type of response packets. The attacker launching a DRDoS attack can send any type of packets as a request, but types of response packets are predictable and limited by protocol specifications. For example, even if the attacker sends a protocol-violating request packet, the reflector simply responds with ‘‘the request has not been accepted” according to the protocol specifications. Therefore, a response packet itself is definitely valid assuming that a reflector is not compromised. This implies that the attacker cannot directly control attack packets generated by the reflector to avoid detection.
2. Distributed reflection DoS attacks
2.2. Characteristics
2.1. Mechanism
In this section, we highlight the characteristics of DRDoS attacks as compared with traditional DDoS attacks. Since the victim is assaulted by attack packets sent by legitimate hosts (i.e., reflectors), these innocent reflectors are perceived as attackers. Thus, it will take a longer time to determine the real attacker. Unlike a DDoS attack which needs to enslave hosts by compromising these hosts, the attacker of a DRDoS attack can orchestrate a large number of attack sources easily. Since the attacker needs to know only the IP address of a host to use it as a reflector, most of the hosts (any server, client, router, switch, or device which runs on the TCP/IP protocol stack) in the Internet can potentially be used as reflectors. As a result, it is possible to attack the victim with a small amount of traffic from each reflector. This characteristic poses great difficulties for reflectors to detect such attacks. Besides, the attacker can also easily shift the attack source, i.e., the so-called ‘‘reflector usage phasing” [2]. The packet amplification allows the attacker to effectively reduce the number of request packets and to evade detection; it is made possible by exploiting the TCP retransmission mechanism [18], IP broadcast (e.g., Smurf), or application specific behaviors such as DNS recursive query [19]. For example, in response to TCP SYN issued by the attacker, the reflector sends SYN/ACK to the victim. At this time, if the bandwidth between the reflector and the victim is fully flooded, the SYN/ACK packet will be dropped and retransmitted. Consequently, the number of response packets can be larger than that of request packets.
DRDoS attacks capitalize on the reflector’s ability of generating messages in reply to other messages [4]. In other words, the ‘‘request–response” relationship is a key to DRDoS attacks. Here, the ‘‘response” is the generated message, and the ‘‘request” is the trigger of the ‘‘response”. When a DRDoS attacker sends request packets to a reflector, source addresses of the request packets are spoofed as the victim’s IP address. Thus, the reflector sends response packets to the victim in reply to the spoofed requests. These response packets become real attack packets against the victim. For example, Smurf [16] is a classical and a well-known type of DRDoS attack. The attacker sends ICMP echo request packets as request packets to a subnet-directed broadcast address. In this case, all of the hosts in the subnet become reflectors, which issue a large number of ICMP echo reply packets assaulting the victim. The Fraggle attack [17] is a variant of Smurf. In the Fraggle attack, instead of using ICMP echo request packets, the attacker sends request packets to reflectors for services such as UDP echo, chargen, daytime, or quotd in a similar fashion as that of Smurf. Today, to protect against these types of attacks, hosts in the Internet are recommeded to ignore ICMP echo request to the broadcast address and to stop unused services. However, there are various ways to launch DRDoS attacks other than Smurf and Fraggle, and therefore we need to consider more comprehensive countermeasures. A DRDoS attacker can exploit any protocol that supports automatic message generation to launch attacks. For example, TCP, UDP, various ICMP messages, and application protocol messages can be used to launch DRDoS attacks. Typical types of response packets and their correspondent request types are summarized in Table 1. Note that UDP itself does not posses the automatic message generation ability, and request–response relationships are in-
Table 1 Examples of request and response pair used by DRDoS attacks Request
Response
TCP SYN packets to open TCP ports TCP packets to closed TCP ports DNS query packets SNMP request packets UDP packets to closed UDP ports ICMP requests (e.g., echo request) IP packets
TCP SYN/ACK packets TCP RST packets DNS reply packets SNMP response packets ICMP port unreach. msg. ICMP replies (e.g., echo reply) ICMP time exceeded msg
3. Issues in conventional countermeasures Although various countermeasures have been proposed to mitigate conventional DDoS attacks, they are not effective to combat against DRDoS attacks. Basically, since all of attack packets are sent by a large number of innocent reflectors, source address filtering based on pre-configured black-list will not work. Even if the black-list can be updated dynamically as proposed in [20], the attacker can easily bypass such list by reflector usage phasing [2]. Also note that filtering based on source addresses can refuse normal communication between the victim and the host which is used as a reflector as well. For conventional DDoS attacks, identifying the attacker by IP traceback techniques have received much attention [7,8], and various IP traceback techniques [10,21,9,22,12,23–25] have been proposed. However, it is difficult, if not impossible, for them to trace attack traffic arrived at the victim via reflectors.
3301
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
To detect DRDoS attacks at a reflector, Peng et al. [26] proposed to share information about illegal traffic among potential reflectors. In addition, Jin et al. [27] proposed a detecting and filtering method of spoofed packets at the reflector based on the mapping between the hop-count and the source IP address. A reflector, which can detect and filter the attack packets, can certainly minimize the damage to victims. However, deploying such detection mechanisms on all potential reflectors is not realistic because all hosts in the Internet are potential reflectors. Moreover, since a DRDoS attacker can limit the number of packets sent to each reflector by using a large number of reflectors, it is difficult to detect attacks orchestrated through reflectors. Consequently, it is still necessary to detect DRDoS attacks at the victim side. Peng et al. [28] have proposed a mechanism by using source IP address monitoring for detecting DDoS attacks. Their proposed method uses the number of new source IP addresses monitored at the victim as a detection feature, and it can be applied to the detection of DRDoS attacks. However, if a DRDoS attacker uses popular servers as reflectors, it is difficult to detect an attack by using such detection feature. In DRDoS attacks, response packets themselves are always valid, and thus the detection process must validate a received response packet based on protocol specifications. The most famous technique for performing such validation is the stateful inspection technique developed by Check Point Software Technology [14]. In the stateful inspection process, a state is defined for each connection, and the state is constantly updated with information carried in every sending and receiving packet belonging to the connection. If the protocol-violating state transition is found, the packet triggering such transition is detected as the illegal packet. The stateful inspection technique has been implemented in various IDSs and firewalls [15], but its complexity is rather high because this technique needs to investigate every packet in a connection and keep track of the packet sequence. Therefore, the stateful inspection is too complex to detect DRDoS attacks because a response packet is the target of detection in the case of DRDoS attacks. As mentioned above, types of attack packets used for DRDoS are predictable, and we thus propose a simple mechanism to detect attack packets at the victim side. 4. A simple mechanism for confirming response packets 4.1. Overview of the proposed method The proposed method focuses on only pairs of request and response packets, and does not need to manage the complicated state transition of any protocol such as TCP. For a legal response packet, the corresponding valid request packet should be monitored before. Within the context of DRDoS attacks, it is realistic to assume that the victim is not compromised and any request originated from the victim is valid. Fig. 1 illustrates the concept of the proposed detection method. In the proposed method, the detector will be deployed next to the victim or at the border of the network to which the victim
Correct Response Victim
Confirm
resides. For a valid response, the detector can monitor both request and response packets. In this case, the validity of the response packet is confirmed because there is a bidirectional action of request–response. On the other hand, for the reflected response, the detector monitors only a response packet, and there is no bidirectional action. In this case, the confirmation of the response packet fails. Since only limited and predictable types of packets can be used for such attacks as previously mentioned, it is possible to accurately detect a reflected response by checking only the limited types of request–response pairs. This characteristic significantly simplifies the detection procedure in the proposed method. In the proposed method based on the limited types of request packets that an attacker can stage a DRDoS attack, the detector can compose and store potential response packets in its buffer for each request packet. When a response packet sent to the victim is monitored, the detector compares this response packet with the stored potential response packets. If there is a match, the monitored response packet is considered valid. Otherwise, it is detected as an invalid response. The detailed system design will be described in Section 5. Obviously, this proposed method depends on the certainty of request–response pairs. In the next section, we will discuss the potential ambiguity exhibited in typical cases of actual inspection. 4.2. Request–response relationship Depending on the type of a response packet, two request–response relationships exist, namely, the one-to-one case and the many-to-one case, as shown in Fig. 2. In the proposed method, the detector has to compose response packets for each monitored request packet. Thus, to confirm the validity of a response packet we have to first define the types of request packets that will result in such a response. For the one-to-one case, it is easy to determine the unique request packet for a given response packet. Therefore, the definition of a request packet is clear in this case. Response packets with this type of one-to-one relationship are referred to as clear response packets. On the other hand, for the many-to-one case, several request packets may correspond to a given response packet. Hence, the definition of a request packet is ambiguous. Response packets with this type of many-to-one relationship are referred to as ambiguous response packets. We shall next elaborate on the types of request and response packets within the context of the request–response relationship of a DRDoS attack. 4.2.1. One-to-one relationship For the one-to-one relationship, we can easily predict the response packet for a given request packet. As mentioned in Section 2, an attacker can use any type of packet as a request packet. However, assuming that a protocol violated packet is never sent by the victim, the detector only needs to monitor the following packets as request packets:
Reflected Response Confirm(failed)
Detector Request
Response
Legitimate Host
Request should exist
Reflected Response
Clear Response (one-to-one)
Ambiguous Response (many-to-one)
One Request One Response
Many Requests One Response
Victim Detector
Spoofed Request
Attacker Fig. 1. Concept of the proposed method.
Legitimate Host Fig. 2. Relationship between request and response packets.
3302
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
Packets that initiate communication (e.g., TCP SYN, SCTP INIT) Packets that request some sort of information (e.g., DNS Query, SNMP Request, ICMP Request) For each request packet, the correspondent response packet should satisfy the following minimal conditions: For IP header – Src./Dst. address pair should be the same. – Protocol field should have the same value. For TCP/UDP headers – Src./Dst. port number pair should be the same. For ICMP header – Type field should correspond to that of the request, e.g., echo request (Type:8) and reply (Type:0). – ID and sequence number should be the same.
Additional conditions should be considered for TCP and UDP. As previously mentioned, for UDP, the request–response relationship depends on the application level protocol. Thus, we only consider the cases where such relationship exists in the application level. For TCP – Correspondent flag (SYN/ACK) is set. – Acknowledgment number of the response packet is greater than the sequence number of the request packet by only one. For UDP – There is the request–response relationship in the application protocol level header. For example, the ID values are the same for correspondent DNS request and response.
The detector composes potential response packets based on the above conditions. Clearly, in the case of a valid response, this type of response packets should be monitored at the detector in the RTT time-scale since the correspondent request packet was actually sent. Therefore, in order to correctly confirm the validity of this type of response packets, the detector should have a buffer large enough for keeping potential response packets in the RTT time-scale. The required buffer size will be discussed in Section 5.3. 4.2.2. Many-to-one relationship The previous section considers request and response packets that exhibit the one-to-one relationship. However, several request and response packets do not follow the one-to-one relationship. For example, in the case of a TCP connection interruption, every packet belonging to the interrupted connection can result in an RST packet, i.e., a response packet. Therefore, an RST packet has a many-to-one relationship with all TCP packets. Similarly, an ICMP destination unreachable packet has a many-to-one relationship with all IP packets. These error related packets can be generated anywhere, anytime, and for any type of packets. Thus, it is difficult to strictly establish the request–response relationship. In this case, we choose an alternative request packet instead of the actual request, and approximate the many-to-one relationship by a one-to-one relationship. For connection-oriented protocols, a packet for initiating a connection becomes an alternative request packet. For TCP, the SYN packet of each connection initiated by the victim side is the alternative request packet of an RST packet and an ICMP destination unreachable packet. If a connection is ini-
tiated by the other communicating end (i.e., SYN packet is sent to the victim), SYN/ACK packet sent by the victim is the alternative request packet. Therefore, when a SYN or a SYN/ACK packet is monitored, the detector composes an RST packet and an ICMP destination unreachable packet as potential responses. Note that the sequence number and the acknowledgment number fields in the TCP header should be ignored for request–response matching in this case. For UDP, which is not connection-oriented, each packet sent by the victim becomes a request packet for an ICMP destination unreachable packet. This approximation reduces the accuracy of detection, which will be elaborated further in Section 6. In terms of the buffer size for correctly validating ambiguous response packets, the detector should have a buffer large enough to store the potential response for the connection duration time. This means that the buffer size is larger than that of the previous case (i.e., one-to-one relationship case). The required buffer size will also be discussed in Section 5.3. 5. The detection system using the proposed confirmation mechanism 5.1. Basic architecture Fig. 3 illustrates the basic architecture of the proposed detection system, which comprises a translator, a comparator, and two buffers: the short-term (RTT time scale) buffer and the long-term (connection duration time scale) buffer. The short-term buffer and the long-term buffer are used to store the composed clear response packets and ambiguous response packets, respectively. For the sake of simplicity for describing the detection system, we assume that the buffer is a cyclic buffer with a constant buffer size. The detector monitors packets sent and received by a victim. If a request packet sent by the victim is monitored, the translator translates the monitored request packet into potential response packets that the request packet can possibly cause. If the potential response packet is a clear response packet, the packet is stored in the short-term buffer. On the other hand, if the potential response packet is an ambiguous response packet, the packet is stored in the long-term buffer. When the detector monitors a response packet, the detector selects the targeted buffer according to the type of the monitored response packet. Then, the comparator compares the monitored packet with each potential response packet in the selected buffer. If the potential response packet and the monitored packet have the same information, it implies that the correspondent request packet has been monitored before. In this case, the proposed method determines that the monitored response packet is valid. Otherwise, the monitored response packet is unexpected, and is thus considered invalid.
Request Packet from the Victim
Detector Response Packet to the Victim
Clear Response Packet Translator Short-term Buffer
Comparator Long-term Buffer
Potential Response Packets
Ambigous Response Packet Output Detection Result Fig. 3. Basic architecture of the proposed detection system.
3303
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
The roles of the detector are only to compose potential response packets, and to match observed response packets with stored potential response packets. Thus, unlike stateful inspection, the proposed method can detect unexpected and invalid packets in a stateless manner. 5.2. Complexity of the proposed detection method We formulate the complexity of the proposed method, and compare it with that of the stateful inspection method, currently available state of the art. For both methods, the detector carries out the following three processes in the detection procedure. Creation of an entry to be stored in the buffer. Searching an entry in the buffer. Updating an entry in the buffer. An entry is either a composed potential response packet for the proposed method, or a state defined for a connection for the stateful inspection method. Our formulation is based on the number of occurrences of these events (creation, search, update) in each method. Although the complexity of each search depends on the data structure of the buffer, we just count the number of entry searches for the sake of simplicity. In the following evaluation, N c ðtÞ; N s ðtÞ, and N u ðtÞ stand for the number of entry creation, search, and update processes in the time slot ½t; t þ Dt, where Dt is the maximum time slot supported by the cyclic buffers, respectively. First, we summarize the parameters and their corresponding definitions used in the following evaluation in Table 2. In the proposed method, the number of entries created in Dt equals to the number of composed potential response packets. As mentioned in Section 4.2, there are two types of response packets: clear and ambiguous, and a request packet is defined for each response packet. Denote ai as the number of clear response packets for a type i request packet, and bi as the number of ambiguous response packets for a type i request packet. Note that the maximum value of ai is one because only one clear response packet is defined for a given request packet. When the number of types of requests sent by the victim is V req ; N c ðtÞ becomes
Nc ðtÞ ¼
V req X fsreq i ðtÞ ðai þ bi Þg;
ð1Þ
i
where sreq i ðtÞ denotes the number of type i request packets sent by the victim in the time slot ½t; t þ Dt. For detecting reflected response packets, the detector monitors PV V resp ¼ i req ðai þ bi Þ types of incoming response packets. For each monitored response packet, the detector searches for the correspondent potential response packets within its buffer. Therefore, the number of entry search processes in the time slot ½t; t þ Dt; N s ðtÞ, can be expressed as
Table 2 Parameters and corresponding definitions Parameter
Definition
V req
# of types of requests sent by the victim # of clear response packets for a type i request packet # of ambiguous response packets for a type i request packet # of type i request packets sent by the victim in the time slot ½t; t þ Dt # of type j response packets received by the victim in the time slot ½t; t þ Dt # of connections # of packets in connection c in the time slot ½t; t þ Dt # of entry searches for which a correspondent state is not found
ai bi sreq ðtÞ i rresp ðtÞ j N conn nc ðtÞ d
Ns ðtÞ ¼
V resp X
r resp ðtÞ; j
ð2Þ
i
where r resp ðtÞ denotes the number of type j response packets rej ceived by the victim in the time slot ½t; t þ Dt. Obviously, the proposed method does not update stored entries for detecting reflection attacks. Thus, N u ðtÞ equals zero. On the other hand, in the stateful inspection method, an entry is a state which is defined for each TCP connection, UDP session, or ICMP session. In addition, each created entry is updated packet by packet based on information in packets belonging to the same connection, in order to keep track of the sequence of packets in the connection. Hence, the stateful inspection method requires more entry searches and entry updates. The detector creates a state for each request packet of a connectio, and N c ðtÞ becomes
Nc ðtÞ ¼
V req X req fsreq i ðtÞ þ r i ðtÞg;
ð3Þ
i
where rreq i ðtÞ denotes the number of type i request packets received by the victim in the time slot ½t; t þ Dt. The stateful inspection method needs to keep the state updated for validating a currently monitored packet. Therefore, for each incoming/outgoing packet, the detector searches for and updates the correspondent state within its buffer with the information included in the monitored packet. Consequently, the stateful inspection method needs a large number of entry search and update processes for validating legitimate connections. As a result, N s ðtÞ and N u ðtÞ are defined as
Ns ðtÞ ¼ Nu ðtÞ ¼
XNconn c
nc ðtÞ;
ð4Þ
nc ðtÞ d;
ð5Þ
XNconn c
where N conn and nc ðtÞ denote the total number of connections, and the number of packets in connection c in the time slot ½t; t þ Dt, respectively. Note that d denotes the number of entry searches for which a correspondent state is not found. Table 3 summarizes the complexity of both methods. Since the proposed method focuses only on the limited types of packets (i.e., response packets), the number of search events can be drastically reduced as compared with the stateful inspection method. In addition, no update events are required for the proposed method. Considering the fact that the stateful inspection is widely used to detect and filter illegal packets in a firewall, we believe that the proposed method, which is computationally more efficient and can work on-the-fly, can be readily installed for the next generation firewalls and IDSs. 5.3. Required buffer size Here, we analyze the required buffer size for the proposed method. As shown in Fig. 3, composed clear response packets and ambiguous response packets are stored in the short-term buffer and the long-term buffer, respectively. The short-term buffer should keep each clear response packet in the RTT time scale, T s slots. Thus, the required buffer size is proportional to the number of entries stored in the short-term buffer during T s slots. The number of entries, Bs , can be computed as follows: Table 3 The complexity of the proposed method and the stateful inspection method
Proposed method Stateful inspection
# of state creation PV req req fs ðtÞ ðai þ bi Þg PiV req ireq fsi ðtÞ þ r req ðtÞg i i
# of search PV resp resp r ðtÞ PiNconn i ni ðtÞ i
# of update 0 PNconn i
ni ðtÞ d
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
Bs ¼ T s
V req X fsreq i ðtÞ ai g:
ð6Þ
i
Similarly, the long-term buffer should keep each ambiguous response packet for the connection duration scale, T l slots ðT s T l Þ. Thus, the required buffer size is proportional to the number of entries stored in the long-term buffer during T l slots. The number of entries, Bl , becomes
Bl ¼ T l
V req X fsreq i ðtÞ bi g:
ð7Þ
i
For the stateful inspection method, the detector should also have the buffer large enough to keep states for the connection duration scale. Therefore, the number of entries, B, becomes
B ¼ Tl
V req X req fsreq i ðtÞ þ r i ðtÞg:
ð8Þ
i
T s and T l are determined based on the maximum RTT and connection duration in the normal situation. In the evaluation of the proposed method in the following section, the buffer size is determined based on the above equations. 6. Evaluation of the proposed method We evaluate the processing cost of the proposed method, and compare it with that of the stateful inspection method [15]. 6.1. Evaluation environment The experimental environment is setup by using a real network consisting of 50 hosts, as shown in Fig. 4. The victim is one of the hosts in network A, and the attacker and the reflector are located in another network (network B) in the same campus. The attacker sends 1000 spoofed TCP SYN packets as requests to the reflector within three hours, which reflects TCP SYN/ACK or RST packets as responses to the victim. We trace incoming/outgoing traffic at the gateway of the laboratory’s network. The traffic trace, which contains attack packets, is used for evaluation by off-line simulations. In this evaluation, to detect DRDoS attacks based on TCP, the proposed method and stateful inspection method inspect only TCP packets in the traffic trace. The traffic trace includes a total of about 670,000 incoming/outgoing TCP packets. The focus of the detection is on the response packets included in the incoming traffic. Since DRDoS packets always do not have the correspondent entry in the buffer despite the number of attackers, all DRDoS packets will be detected by both the proposed method and the stateful
6.2. Buffer size configuration The buffer size of the proposed detection system is determined based on the statistics of a traffic trace in this environment. In this environment, a maximum of 50 request packets (SYN and SYN/ACK) per second (i.e., Dt is 1 s) are sent from the inside of the victim network (network A in Fig. 4). Since the correspondent clear response packet is a SYN/ACK packet for a SYN packet, ai is one for a SYN packet. On the other hand, there are no clear response packets for a SYN/ACK packet, and thus ai is zero for a SYN/ ACK packet. Fig. 5 shows the 3-month cumulative distribution of the RTT value calculated by the intervals between correspondent SYN and SYN/ACK packet pairs. As shown in the figure, the RTT value of more than 99.8% connections are less than one second. Therefore, we set T s to 1 s. As a result, we set the short-term buffer size Bs to 1 50 1 ¼ 50 entries. Fig. 6 shows the cumulative distribution of the lifetime of interrupted connections. As shown in the figure, the lifetime of more than 99.8% interrupted connections are less than 600 s. According to this result, we set T l to 600 s. Since a RST packet is an ambiguous response packet to SYN and SYN/ACK packets, bi is one for both SYN and SYN/ACK packets. As a result, we set the long-term buffer size Bl to 600 50 1 ¼ 30; 000 entries.
100
80
60
40
20
0
0
0.1
Spoofed Request Packets
Reflector
0.2
0.3
0.4
0.5
0.7
0.8
Fig. 5. Cumulative distribution of RTT of connections.
Victim
Detector Reflected Response Packets
network B (other network in the same campus)
0.6
RTT[sec]
Gateway / Firewall
Internet
Attacker
inspection method. On the other hand, false positives may be generated depending on the buffer size. Consequently, the accuracy may be degraded mainly due to false positives (not false negatives), and we thus focuses on the number of false positives.
Cumulative distribution[%]
3304
50 clients
network A (Laboratory’s network)
Fig. 4. Experimental environment.
0.9
1
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
Cumulative distribution [%]
100
90
80
70
60
50
0
200
400
600
800
1000
Lifetime of interrupted connections [sec] Fig. 6. Cumulative distribution of the lifetime of interrupted connections.
Since 50 request packets (SYN and SYN/ACK) are sent from the inside of the victim network as previously mentioned, the buffer size for the stateful inspection method, B, is set to 600 50 ¼ 30; 000 entries.
3305
from a host in the external network. In this experimental environment in which the detector is located outside the firewall, a SYN packet for a service prohibited by the firewall is monitored at the detector, and then filtered out at the firewall. The host attempting to initiate the connection finally sends an RST packet, and this RST packet is falsely detected only by the proposed method. In the stateful inspection method, the detector creates a state in its buffer for even this kind of SYN packets. Thus, the RST packet can be confirmed. In the proposed method, the request packet which result in an RST packet can only be SYN or SYN/ACK packets sent by the victim, and both types of request packets are not sent in this case. Therefore, the potential response packets are never composed in the proposed method, and the confirmation of the RST packet fails (i.e., the RST packet is detected as a DRDoS attack packet). This is the cause for 29 extra packets falsely detected by the proposed method. However, if the detector is located inside the firewall, such RST packet will also be filtered out at the firewall, and the detector would not have monitored such RST packets. This means that this type of false positives can be easily eliminated. Consequently, we conclude that the proposed method can detect invalid response packets with an accuracy as the high as that of stateful inspection with much less processing cost.
6.3. Evaluation results
7. Conclusions
The numbers of entry creations, searches, and updates shown in Table 4 are used to evaluate the processing cost. It is clear that the proposed method can detect invalid response packets with fewer events than the stateful inspection. In term of the actual elapsed time for processing and analyzing, the proposed method is more than nine times faster than the stateful method. It takes 1.6 s to process 670,000 TCP packets using Intel Xeon CPU 3.06 GHz. The stateful inspection needs 14.9 s under the same conditions. Table 5 shows the detection results. Both methods can detect all reflected attack packets. Further investigation on the extra 91 packets and 61 packets detected by the two respective methods reveals that most of the other extra packets are unexpected SYN/ACK or RST packets not corresponding to any packets sent before. Since source port numbers of these packets are 22 (ssh), 80 (http), or 7000 (afs3-fileserver), and the source address of the packet which has the same source port number is also the same, these packets are possibly reflected response packets, and are not false positives. For both methods, a long-lived connection can be the cause for false positives. In this evaluation, three or four RST packets are falsely detected for each method. These RST packets arrive 10 min after the last packet is arrived, and the potential response packet for confirming these packets are already deleted from the buffer. Some false positives are generated by the proposed method. The largest difference between the proposed method and the stateful inspection is the treatment of cases when connections are initiated
In this paper, we have proposed a simple response packet confirmation method specialized for DRDoS detection. DRDoS attacks, in which victims of DRDoS are attacked by response packets reflected from legitimate hosts, are emerging threats in the Internet. To detect such packets, received response packets have to be confirmed. Unlike stateful inspection which needs to monitor all packets for state management, the proposed method needs to monitor only limited types of request and response packets. We have analyzed the complexity of the proposed method in terms of the number of entry creation, search, and update events required to detect attack packets. The analysis result shows that the proposed method can drastically reduce the complexity as compared to that of the stateful inspection method. Through experiments using real traffic traces, we have also verified that the numbers of entry creations, searches, and updates required by the proposed method are much smaller than those of the stateful inspection method. Although the proposed method incurs additional false positives as compared with the stateful inspection method, such false positives can be easily eliminated by placing the detector appropriately (such as behind the firewall). In conclusion, the proposed method is simple and robust in detecting DRDoS attacks, and can be incorporated in the next-generation firewalls and IDSs.
Table 4 The numbers of entry creations, searches, and updates
Proposed method Stateful inspection
# of entry creations
# of searches
# of updates
14,274 10,773
8,270 672,406
0 660,583
Table 5 Detection results
Proposed method Stateful inspection
# of attacks
# of detected
1000 1000
1091 1061
References [1] H. Tsunoda, K. Ohta, A. Yamamoto, Y. Nemoto, A simple response packet confirmation method for DRDoS Detection, in: Proceedings of the 8th International Conference on Advanced Communication Technology (ICACT), 2006. [2] S. Gibson, DRDoS: Description and analysis of a potent, increasingly prevalent, and worrisome Internet attack, Available from:
3306
H. Tsunoda et al. / Computer Communications 31 (2008) 3299–3306
[8] Z. Gao, N. Ansari, Tracing cyber attacks from the practical perspective, IEEE Communications Magazine 43 (5) (2005) 123–131. [9] A. Snoeren, C. Partridge, L. Sanchez, C. Jones, F. Tchakountio, S. Kent, W. Strayer, Hash-based IP traceback, in: Proceedings of the ACM SIGCOMM , 2001, pp. 3–14. [10] S. Bellovin, M. Leech, T. Taylor, ICMP traceback messages, internet draft: draftietf-itrace-04.txt (Feb. 2003). [11] S. Savage, D. Wetherall, A. Karlin, T. Anderson, Network support for IP traceback, ACM/IEEE Transactions on Networking 9 (3) (2001) 226–237. [12] A. Belenky, N. Ansari, IP traceback with deterministic packet marking, IEEE Communications Letter 7 (4) (2003) 162–164. [13] A. Belenky, N. Ansari, On deterministic packet marking (DPM), Computer Networks 51 (10) (2007) 2677–2700. [14] Stateful Inspection Technology (The industry standard for enterprise-class network security solutions), Available from:
[20] Y. Xu, H.C.J. Lee, A source address filtering firewall to defend against denial of service attacks, in: Proceedings of the 60th IEEE Vehicular Technology Conference, 2004, pp. 3296–3300. [21] S. Savage, D. Wetherall, A. Karlin, T. Anderson, Practical network support for IP traceback, IEEE/ACM Transactions on Networking 9 (3) (2001) 226–237. [22] A. Snoeren, C. Partridge, L. Sanchez, C. Jones, F. Tchakountio, B. Schwartz, S.T. Kent, W.T. Strayer, Single-packet IP traceback, IEEE/ACM Transactions on Networking 10 (6) (2002) 721–734. [23] A. Belenky, N. Ansari, Tracing multiple attakers with deterministic packet marking (DPM), in: Proceedings of the IEEE Pacific Rim Conference on Communications, Computers, and Signal Processing, 2003, pp. 49–52. [24] G. Mansfield, K. Ohta, Y. Takei, N. Kato, Y. Nemoto, Towards trapping wily intruders in the large, Computer Networks 34 (2000) 659–670. [25] K. Ohta, G. Mansfield, Y. Takei, N. Kato, Y. Nemoto, Detection, defense, and tracking of internet-wide illegal access in a distriuted manner, in: Proceedings of the INET2000, Yokohama, Japan, 2000. [26] T. Peng, Detecting reflector attacks by sharing beliefs, in: Proceedings of the 46th IEEE Global Telecommunications Conference (GLOBECOM’03), 2003, pp. 1358–1362. [27] C. Jin, H. Wang, K. Shin, Hop-count filtering: an effective defense against spoofed traffic, in: Proceedings of the 10th ACM International Conference on Computer and Communications Security (CCS), 2003, pp. 30–41. [28] T. Peng, C. Leckie, K. Ramamohanarao, Proactively detecting distributed denial of service attacks using source IP address monitoring, in: Proceedings of the Third International IFIP-TC6 Networking Conference (Networking 2004), 2004, pp. 771–782.