Analysis of Traceback Techniques

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Analysis of Traceback Techniques"

Transcription

1 Analysis of Traceback Techniques Udaya Kiran Tupakula Vijay Varadharajan Information and Networked Systems Security Research Division of ICS, Macquarie University North Ryde, NSW-2109, Australia {udaya, Abstract Today s Internet is extremely vulnerable to Distributed Denial of service (DDoS) attacks. There is tremendous pressure on the sites performing online business and ISP s to protect their networks from DDoS attacks. Recently, several novel traceback techniques have been proposed to trace the approximate spoofed source of attack. Each proposed traceback technique has some unique advantages and disadvantages over the others. In this paper we will consider some of the novel traceback techniques and focus our discussion i) to raise some of the real time issues that can be addressed in the further research and ii) from the attackers perspective on how to generate DDoS attacks and remain untraced even if any of the traceback technique is deployed in the Internet. We will also demonstrate how attacks can be further amplified if ICMP traceback technique is deployed in the Internet and discuss techniques to minimise the additional attack traffic.. We believe that the networks tend to become complex and more vulnerable to DDoS attacks if some of the proposed traceback techniques are deployed in the Internet. Keywords: Denial of Service, DoS, DDoS, Traceback. 1 Introduction After a series of attacks that occurred in February 2000, there is increased threat of DDoS attacks in today s Internet. Denial of Service (DoS) (CERT 2000, David More, Geoffery M. Voelker, and Stefan Savage 2001), is an attempt by attackers to prevent access to resources by legitimate users for which they have authorization. In the case of DDoS, an attacker compromises several hosts on the Internet. Often, these are weakly secured machines and they are broken into using well-known defects in standard network service programs and common operating systems. These compromised computers are referred to as zombies. The attacker then uses these compromised computers to launch coordinated attacks on victim machines. In figure 1, the attacker has already done a substantial amount of work in creating the Copyright 2006, Australian Computer Society, Inc. This paper appeared at the Fourth Australasian Information Security Workshop (AISW-NetSec 2006), Hobart, Australia. Conferences in Research and Practice in Information Technology (CRPIT), Vol. 54. Rajkumar Buyya, Tianchi Ma, Rei Safavi-Naini, Chris Steketee and Willy Susilo, Eds. Reproduction for academic, not-for profit purposes permitted provided this text is included. zombies. So it is only a matter of few keystrokes for the attacker to launch a severe DDoS attack on the victim. It is clearly evident from the recent attacks (Ivan Arce 2004) that the attacker can create a severe DDoS attack by using innocent systems even without compromising them. The attacker takes to his advantage the known vulnerabilities in an operating system or database. In the case of DDoS attack, the victim can protect his network from the attack traffic at his network boundary, if he has some security tools like firewalls and intrusion detection systems to identify and prevent these attacks. Even if the victim can prevent the attack at his boundary, since all the available bandwidth is consumed by the malicious traffic, the victim cannot have access to other networks (Internet) and other legitimate hosts/networks do not have access to the victim s network. This can have considerable impact on the sites performing online business. Zombie1 Attacker Control Mechanism Zombie2 Victim s Machine / Network Fig 1: Attack Mechanism Zombie3 Recently several schemes have been proposed (P.Ferguson and D.Senie 1998, SANS 2000, Alex C. Snoeren, Craig Partridge, Luis A. Sanchez, Christine E. Jones, Fabrice Tchakountio, Beverly Schwartz, Stephen T. Kent, and W. Timothy Strayer 2002, Allison Mankin, Dan Massey, Chien-Long Wu, S. Felix Wu and Lixia Zhang 2001, D. Song and A.Perrig 2000, Drew Dean, Matt Franklin and Adam Stubblefield 2001, Stefan Savage, David Wetherall, Anna Karlin and Tom Anderson 2000, Steven M. Bellovin 2001) on how to detect and prevent some of these types of attacks. Since traceback techniques have received considerable attention during recent times, in this paper, we will focus our discussion on some of the novel traceback techniques and raise some real time issues that can be considered in the further research.

2 The paper is organised as follows. We will start our discussion with the single packet IP traceback technique in section 2 and issues related to the single packet IP traceback technique in section 3. Section 4 gives an overview of the IP packet marking techniques and section 5 raises some of the real time issues related to IP packet marking techniques. Section 6 gives overview of ICMP traceback technique and in section 7 we discuss how an attacker can generate a DDoS attack and remain untraced even if ICMP traceback technique is deployed in the current Internet. We will also present a simple demonstration to support our arguments and discuss techniques to minimise the additional attack traffic. Section 8 concludes. 2 Single Packet IP Traceback Snoeren et al. (2002) proposed a Source Path Isolation Engine (SPIE) that allows traceback of even a single packet within the single ISP domain. The idea behind this approach is to maintain the database of all the traffic at every router within the domain and to query the database to identify the approximate source of attack if the victim reports a malicious packet. The novelty of this technique is the minimisation of the storage overhead using bloom filters and storing only the digest of non-varying fields in the IP header (J.Postel 1981) and the first 8 bytes of payload, instead of storing the complete packet. The main advantage of this technique is the traceback of a single packet with the capability to deal with the compromised routers within the ISP domain. DGA DGA DGA DGA SCAR SCAR Victim IDS Fig 2: SPIE Architecture STM The SPIE architecture in Figure 2 consists of a Data Generator Agent (DGA), which will be incorporated into the routers (both edge routers and transit routers) within the ISP. While forwarding the packets, the DGA masks the varying fields (TTL, Checksum, ToS and options field) of the IP header and calculates the digest of the remaining fields in the IP header and the first 8 bytes of the payload. The DGA stores the digest in a time-stamped table and periodically pages out the portion of the table to the SPIE Collection and Reduction Agents (SCAR). The SCARs monitor a group of DGAs and generate a periodic graph of the traffic path. The SPIE Traceback Manager (STM) is connected to the victim IDS. When the victim IDS reports the attack by sending the malicious packet and the time of receipt, the STM queries each individual SCAR for the local attack patch. The STM assembles each individual attack path received from the SCARs, calculates the total attack path and updates it to the victim. 3 Issues in Single Packet IP Traceback The authors argue for the single packet IP traceback since a single packet can cause considerable damage to some of the mission critical applications. Let us analyse the technique with regard to single-packet DoS attacks. The computation overhead on the routers is very high, since hashes of the packets have to be calculated at every router. As the current routers carry gigabits of data per second, the storage overhead is equally very high, since the database of all the traffic has to be maintained at every router. The implementation cost of this technique is also very high, since all the routers should be modified or additional devices should be placed at every router to support the single packet traceback. First let us consider the limitations of the single-packet traceback technique by assuming that the technique is deployed within a single ISP domain. The scheme assumes that the attacker is aware of the traceback. In this case, the attacker can co-ordinate the attack in such a way that the attack packet originates from the compromised host that is located in another ISP domain. Considering the number of attacking tools available in the Internet, it is a very simple task for the attacker to compromise and generate the attack packet from a host that is located outside the victim s ISP domain. In this case, the traceback is only effective in determining the ingress router of the ISP through which the attack packet entered the ISP domain. This traceback information will be of no use to the victim. For each attack packet generated by the attacker, multiple queries have to be initiated within the ISP domain to determine the approximate source of attack. If considerable attack packets are generated on one or more customers of the ISP, this can result in an increase in traffic within the ISP domain. Since the packets are stored at every hop and since the current routers carry gigabits of data per second, the proposed technique has severe limitations on the time period for which the database can be maintained. This has a severe time restriction on the victim to identify the malicious packet and request the SPIE Traceback Manager (STM) for traceback within the time period for which the database is maintained. Now let us assume that this technique is universally deployed in all the ISP domains and discuss the issues related to this approach. Let us assume that the attacker and the victim are connected to the ISP 1 domain depicted in Figure 3. Since the attacker is aware of the traceback, she/he would co-ordinate the attack in such a way that the attack packet originates from the ISP domain which is multiple hops away from the ISP 1. Let us consider that the attacker initiates the attack packet from

3 ISP X domain. Now in order to traceback this attack packet, the victim has to quickly detect the attack packet and request its STM to traceback the approximate source of attack packet. The STM can initiate the traceback process only after proper authentication of the victim. The STM in ISP 1 will query all the SPIE Collection and Reduction Agents (SCAR) in its domain and determine the ingress edge router through which the attack packet entered its domain. Now this process should be repeated in all the upstream ISP domains from ISP 1 to ISP X. ISP 1 ISP 2 ISP 3 Fig 3: Multiple ISP Scenario ISP X ISP Y complicated by the potential use of indirection to conceal the true origin of an attack. The proposed schemes mark the 32-bit IP address of the router with their own techniques by overloading the 16-bit Fragment ID field of an IP packet (J.Postel 1981). The proposed techniques make the assumption that there would be a considerable amount of packets generated during an attack. They argue that a victim will be able to reconstruct the route the packets followed by combining a modest number of marked packets, though each marked packet represents only a sample of the path it has traversed. Since packets are probabilistically marked, the victim would need large number of packets to calculate the total path traversed by the attack traffic. Even if we assume that each packet is marked, it could take a considerable amount of time for the victim to calculate the path, as computation is needed to retrieve the 32-bit IP address of the marked router. In general, the time taken to reconstruct the path (RT) is dependent on the number of attacking systems, number of parallel paths and length of the path (D. Song and A.Perrig 2000). Figure 4 shows the characteristics of the traceback approaches. The number of false positives is also dependent on the number of attacking hosts, length of path and number of parallel paths. If the traceback has to be initiated in the upstream ISP 2, the victim or the STM in ISP1 has to request the STM in ISP2 to initiate the traceback. This raises several issues as to who (the victim or the STM in ISP 1) should initiate the request and how authentication should be achieved for the traceback to be initiated in an inter-domain situation. This process can lead to DoS attacks on the STM in each ISP domain. Furthermore, this process has to be recursively repeated across multiple ISPs until the approximate source of attack can be identified with this technique. For this process to be effective in multiple ISP domains, it is a requirement that the database has to be maintained for extended time periods. Note that the single ISP itself has serious limitations on the time period for which the database can be maintained. Furthermore, for each attack packet generated, several queries have to be initiated in multiple ISP domains and this can lead to a greater increase in the Internet traffic. In addition to all these issues, it should also be noted that this technique only enables traceback of the single packet and is not capable of protecting the victim s network from the single-packet attack. Hence we believe that it is efficient to deal with the single- packet attacks at the victim s boundary by configuring specific security tools like firewalls. 4 IP Packet Marking Techniques Several IP packet marking techniques (D. Song and A.Perrig 2000, Drew Dean, Matt Franklin and Adam Stubblefield 2001, Stefan Savage, David Wetherall, Anna Karlin and Tom Anderson 2000) have been proposed in the recent years. One of the major difficulties associated with tracing a packet stream back to the source is that it requires cooperation of all the intervening ISP s. This is RT Number of attacking systems, number of parallel paths, length of path Figure: 4 Advantages of this approach include: The ability to trace route the approximate source of an attack even in the case of heterogeneous networks without the cooperation of ISPs. Retention of evidence for legal proceedings. As path information is encoded within the packet header, no additional traffic is generated with these techniques. Since the marking is done on some probability the overhead on the routers is less. In general the proposed IP Traceback techniques have atleast some of the following disadvantages: Packets are marked with some probability and moreover each marked packet represents only a part of the IP address of the marked router. So it consumes a lot of time to calculate the path traversed by the attack traffic. The reconstruction time and number of false positives is dependent on the number of attacking

4 systems, length of the path and number of parallel paths. Packets are marked even if there is no attack. Victim should have the map of all the upstream routers. Victim should share a key with all the upstream routers. It cannot deal with the fragmented packets. For any packet marking technique to be effective, all ISPs should agree to deploy a similar packet marking technique in their respective domain. 5 Issues in Packet Marking Technique In this section, we will focus our discussion on some of the real time issues that are related to IP packet marking techniques. Unless specified, the section deals with the traceback techniques in general. 5.1 Co-operation of ISPs The authors of the traceback techniques claim that their technique is capable of tracking the approximate source of attack in heterogeneous networks without the cooperation of the ISPs. Even if the proposed technique is capable of tracking the attack source in heterogeneous networks, we believe that a fair amount of co-operation is needed between the ISPs, both for the deployment and for the functioning of traceback technologies. Up to the present day, no traceback technique has been proposed that deals with the interoperability between the traceback techniques. For a traceback technique to be effective, the same traceback technique should be deployed in all the ISP domains. That is, all the ISPs should agree to deploy a common traceback technique. It should be noted that, even if most of the routers are capable of performing ingress filtering (P.Ferguson and D.Senie 1998), ISPs are not willing to perform ingress filtering, since it is an additional overhead on their routers. On the other hand, deployment of the traceback techniques requires modification to the router software since the marking is to be done in the fragment ID field. Upgrading the router software incurs additional costs for the ISPs. Even if the packets are marked on some probability, this can result in at least some additional overhead on the routers, depending on the traceback technique being used. So it is a major issue whether ISPs will be willing to bear the additional cost and overhead on their routers. 5.2 Problems with legal proceedings Some proposals claim that one of the main advantages of the traceback techniques is to retain the evidence of attack so that the victim can initiate legal proceedings against the attacking sources. This is not entirely correct, because the calculated attack path is not accurate. The actual attack path is only a subset of the total calculated path. It should be noted that it was extremely difficult for a real-time DDoS victim (Steve Gibson 2001) to initiate legal proceedings against that attacking sources, even when the attack was generated with the correct source address. With the traceback technologies, due to the high false positive rates, there is no strong evidence for the victim to initiate legal proceedings against the attacking source. If the victim initiates legal proceedings with the evidence captured from traceback techniques, the attacker can argue that it can be false positive or some compromised router could have fraudulently marked the packets. Even a small error that results in legal proceedings against an innocent client can cause additional financial losses for the victim. So the victim should be in a good position to differentiate between packets marked by the attacker and packets marked by benign and malicious routers, if legal proceedings against the attacker are to be successful. 5.3 Issues with fragments In general, the packet marking techniques use the fragment ID field in an IPv4 packet to mark the packets for traceback purpose, since fragments constitute only 0.22 % of the total Internet traffic. Once deployed, traceback is a continuous process and there is more probability for all the hosts in the Internet to receive packets that are marked in the fragment ID field. There is no procedure to differentiate between packets that are fragments and packets that are marked in the fragment ID field for traceback purposes. Added to this complication, some DoS attacks use fraudulently marked fragmented packets. So there should be a procedure for the victim to differentiate packets that are real fragments, packets that are marked for traceback purposes and packets that are malicious fragmented packets. 5.4 Modifications to the existing architecture In addition to the changes required to the routing infrastructure to support IP traceback, there is a need for further changes in the complete architecture. For example, the end hosts and security tools in the Internet should be modified to support IP traceback. If the end hosts are not modified to support IP traceback, they will process the packet as fragments. If security tools are not modified to support IP traceback, they can identify the fragments as malicious fragmented packets and generate false alarms. This can incur huge costs. 5.5 Incremental deployment Let us now consider the situation where a single router in the Internet is modified to support an IP traceback technique with incremental deployment. This router marks the packet with traceback information with some probability. The marked packet can be destined to any host in the Internet. The end host will consider the packet as a fragment, if it is not capable of identifying that the packet is actually marked for traceback purposes. Hence all the hosts in the Internet should be modified to identify the packets that are marked for traceback purposes. To support incremental deployment, we require that the packet marking techniques should differentiate between packets marked for traceback and actual fragmented packets.

5 5.6 Problem with routes Several routing protocols such as BGP, EIGRP, IGRP, OSPF, IS-IS and RIP are used to route the packets in the current Internet architecture. Each routing protocol uses different metrics to calculate the best path to a particular destination. The traceback techniques assume that routes between the attacking source and the victim are fairly stable. This condition may not hold true in all the cases and it is dependent on the routing protocols. For example, the RIP protocol only chooses the route with minimum hop count as the best/shortest route for a particular destination. Even in the case of RIP, we should note that there can be equal paths for a particular destination and the packet may take any of the routes to that particular destination. The advanced routing protocols such as OSPF, EIGRP and IS-IS calculate the shortest path based on several parameters such as hop count, time delay, bandwidth, load-balancing between equal paths and load-balancing between unequal paths. In the case of DDoS there will be a sudden burst of traffic. This burst of data can cause the packets to be routed through different routes. Due to the advanced routing protocols, the packets can take different paths depending on parameters such as time delay and loadbalancing between the routes. It has been observed (S.Deshpande, M.Thottan and B.Sikdar 2004) that BGP instabilities occur during the time of DDoS attack. So we believe that the routes may not be stable within a small time interval of time and the traceback techniques should also consider the routing protocols used in the Internet architecture. 5.7 Increase in the Internet traffic In some cases the packet marking techniques can also result in the generation of additional traffic in the Internet. For example, let us assume that a TCP packet is marked for traceback purposes by a particular router and destined to the actual host. Since there is no procedure for the end host to differentiate whether the packet is a fragment or marked for traceback purposes, the end host can assume the packet to be a fragment and can wait to receive other fragmented packets. This can delay the transmission of the acknowledgement from the end host to the actual source. If the sending source does not receive the acknowledgement within the specified time, this can lead to the retransmission of one or more packets, depending on the size of the window. Several errors can occur and lead to retransmission of a greater number of packets if the packet marking technique overwrites the actual fragmented packets. 5.8 Motivation of the attacker and future DoS/DDoS attacks If we observe the trend of DDoS over a period of time, we see that the attacker is ready to do any amount of additional jobs to generate a more severe DDoS attack. The series of attacks that occurred in the year 2000 shows the motivation of the attacker to exploit the limitations in the current Internet architecture to bring down any of the major sites which have advanced security tools deployed at their end to identify and prevent the attacks. Every day, several automated attack tools that can ease the generation of DDoS are being released. In spite of global research and huge investment from commercial vendors and government, the security tools are unable to keep up with the pace of the attack tools. In addition to the increased gap between security technologies and attack tools, the current security tools have become so complex that the attacker is able to generate DoS attacks by exploiting the limitations or features in the security tools. Even if a proposed technique has several advantages, it is important to recognise that the attacker is only interested in exploiting the disadvantages of the proposed technique to create more severe DDoS attacks. Let us now examine how the attacker can exploit the limitations and generate DDoS attacks if some of the traceback techniques are deployed in the Internet. Some traceback techniques show that for each attack path with distance d, the number of packets required to reconstruct the path can be calculated by ln(d)/q(1-q) d-1. Since the proposed traceback techniques assume that the attacker is aware that she/he are being traced, the attacker just needs to send packets of less than ln(d)/q(1-q) d-1, where d is the distance from the attacking source to the victim. The attacker can perform a traceroute (see Figure 6) to find the distance between the attacking source and the victim and then calculate the number of attack packets that can be generated on the victim s machine and remain untraced. The time required for traceback is exponentially dependent on the number of attacking sources. For example, D. Song and A.Perrig (2000) have shown that with just 30 attacking sources, some of the packet marking techniques requires seconds to reconstruct the path traversed by the attack traffic. The recent attacks involved hundreds and thousands of attacking sources. In this case, the traceback itself requires several days and the computational overhead at the victim is extremely high. The authenticated packet marking scheme (D. Song and A.Perrig 2000) can ensure that even a compromised router cannot mark the IP packet by forging the markings of other legitimate routers. This technique enables the victim to detect if a compromised router tampers the markings of other legitimate routers. Even if this scheme can detect the markings that are forged/ tampered, we should note that these packets are not suitable for traceback purposes. 6 ICMP Traceback Technique Earlier, there was ongoing work in the IETF on ICMP traceback technique (Steven M. Bellovin 2001) as a possible DDoS solution. Though the working group is currently inactive, we believe that a detailed analysis on the proposed technique could be of some importance. In this approach (Steven M. Bellovin 2001), when forwarding packets, routers send an ICMP traceback message to the destination with a low probability (say, 1/20,000). The ICMP traceback packet includes the identity of the router, the contents of the packets, and information about the adjacent routers. During the time of attack, after receiving a considerable number of traceback

6 messages, the victim can identify the approximate source of the attack by tracing the total path traversed by attack traffic with the information received in the ICMP traceback packets. In order to trace the route, the victim should compare and find a match between the received attack traffic/packets with the ICMP traceback messages to determine the routers through which attack traffic has traversed. After receiving a considerable number of ICMP traceback packets, the victim can trace the chain of routers through which the attack traffic has traversed and find the approximate source of attack. The technique also proposed to use some security protocols to authenticate the ICMP traceback messages. Advantages of this technique include: The ability to trace route the approximate source of an attack in heterogeneous networks without the cooperation of ISPs. There will be more number of packets to the victim in the case of DDoS attacks. So there is more probability for the victim to receive a greater number of ICMP traceback messages compared to other destinations. This approach has little overhead at the routers, since ICMP packets are generated on very low probability. It simplifies the process for legal proceedings since the victim has evidence of the attack packet and ICMP traceback messages confirming that the attack packets originated from a particular attacking source/network. Disadvantages of this technique include: ICMP packets are generated even if there is no attack. The same technique should be deployed in all the ISPs. This technique generates additional traffic in the Internet. Some sites do not allow ICMP packets through their networks. So the victim may not receive the ICMP traceback messages. Since ICMP traceback messages are generated on very low probability, the victim should receive a large number of attack packets in order to trace the path traversed by the attack traffic. DDoS floods can be generated with the ICMP traceback messages itself. The authentication scheme for the ICMP traceback messages can be an overhead at the routers and this may lead to some form of DoS attacks. 7 Issues in ICMP Traceback Technique Even if the approach has many advantages, the attacker is only interested in exploiting the vulnerabilities in the technique to create a more severe DDoS attack. It should be noted that the attack traffic originates from the zombies (innocent sources which are actually compromised and remotely controlled by the attacker) but not directly from the attacker s machine. So only the zombies will be liable for legal proceedings. Let us look at how an attacker can use to her/his advantage the limitations present in the ICMP traceback technique to generate DDoS attack without leaving any evidence of the attack and remain untraced. We will start with a brief discussion on some of the related topics. 7.1 Reflection/Smurf attack We will present a brief discussion on the reflection/smurf DDoS (CERT 1998) attack in this section and propose a variant of the attack in Section 7.3 assuming that the ICMP traceback technique is deployed in the Internet. Three different parties are involved in the case of a reflection attack: the attacking source, the intermediary and the victim. There can be a number of attacking hosts in case of a smurf attack. The innocent intermediary could be a single machine or an entire network and the intermediary machine/network itself can be a victim of the attack. The victim can also be a single machine or the entire network. The attacker spoofs her/his source address with that of the victim and sends a flood of ICMP echo requests to an individual machine or a broadcast address (intermediary machine/network). Since the source address of the attack traffic is spoofed with the address of the victim, all the machines that receive this request will send a reply message to the victim s machine. This can result in a severe reply flood at the victim s machine/network. Hence a single attacking/compromised host can cause considerable damage to the victim by making use of the innocent intermediary hosts in the Internet. 7.2 Time to Live When two sources communicate, it is observed that a packet may make up to 32 hops to reach any destination in the present Internet. The TTL (time to live) counter in the IP header is used to limit the lifetime of the packet. TTL is an 8-bit field which is supposed to count time in seconds, allowing a maximum lifetime of 255 seconds for a packet. In practice TTL just counts hops. Whenever a router forwards a packet, the TTL is supposed to be decremented on each hop. If the packet is queued for a long time in the router then the TTL can be decremented multiple times within a single hop. This process is used to eliminate the looping of packets due to corrupted routing tables. If the TTL field value becomes zero, the router has to discard the packet. If the packet cannot reach the destination before the TTL expires, then the router at which the TTL expires will generate an ICMP time exceeded message to the source host. The ICMP time exceeded message is to inform the source that there is severe congestion or that the timer values are being set too low. 7.3 A new DoS/DDoS technique In order to generate a severe DDoS attack on the victim s machine, it was assumed in some of the traceback

7 techniques that the DDoS attacks are possible only if the attacker can generate the attack traffic with a TTL value which is equal to or greater than the number of hops from the attacking source to the destined victim. This is true to some extent, because if the TTL value is less than the required number of hops, the TTL of the attack packet will expire before it reaches the victim and the victim will not even notice the attack. In this case, the router at which the attack traffic TTL expires will generate an ICMP time exceeded message to the attacking source. Zombie R7 R1 R2 R V 1 R6 R5 R4 Figure: 5 Now, let us assume that the ICMP traceback technique is deployed in the Internet and discuss how a DDoS attack can be generated. As discussed earlier, there will be hundreds and thousands of attacking sources (zombies) in the case of DDoS attacks. To keep it simple, let us initially consider a DoS attack with a single zombie, as shown in Figure 5. In Figure 5, Rn are routers, Vn are victims. In this scenario, the main aim of the attacker is to create a DoS/DDoS attack on as many systems as possible and remain untraced without leaving any evidence of the attack traffic. Now let us discuss how many attacks are possible with a single attacking source in this scenario. Let us consider that the attacker wants to primarily create an attack on the victim V1 and on additional systems (V2 and R5/V3) if possible. First the zombie can trace route the path to the victim it wants to attack, say V1. The trace-route command gives the complete path from the zombie to the victim. Let N denote the number of hops from the zombie to the destination. Now the zombie can generate a flood of traffic (ICMP, TCP, UDP etc) in such a way that the TTL of the attack traffic expires before it reaches the destined victim. This can be achieved by setting the TTL value of the attack traffic with a value less than N. Now, since the TTL of the attack packets expire before it reaches the victim, the attack traffic generated by the zombie will not reach the victim V1. In doing so the zombie is successful in consuming the bandwidth available for the victim V1 at the routers and V 2 4 there will be no evidence of the attack packet at the victim s end since the attack packets expire before reaching the victim. If the zombie floods the victim V1 with different types of attack traffic with spoofed source addresses, this can cause congestion at the routers in between the zombie and the victim. Since the flood is generated with different types of attack (TCP, UDP and ICMP) traffic, this can lead to undifferentiated congestion at the routers and the routers will start dropping the packets. This dropping can also result in dropping of the good packets from good sources (not shown in Figure 5) to the victim V1. Maximum effect can be achieved by setting the TTL value of the attack traffic with N-1. Since no attack packet has actually reached the victim, the victim (security tools at the victim s end like firewalls and intrusion detection systems) will not even notice the attack and there is no evidence of attack at the victim s end. This type of attack traffic is represented as step 1 in Figure 5 where the TTL of the attack traffic expires at the router R5. The router where the TTL of the attack traffic expires will generate an ICMP time exceeded packet to the zombie. If the zombie sends the initial attack traffic by spoofing its source address with the innocent source address of V2, then all the ICMP time-exceeded messages will be sent to the victim V2. In Figure 5, if we assume that the TTL value of the attack traffic (generated in step 1) expires at router R5 then the router R5 will generate an ICMP time-exceeded-message to the victim V2. This type of attack traffic is represented as step 2. The number of ICMP time-exceeded packets to the victim V2 from the router R5 will be equal to the number of attack packets generated by the zombie. Since we have assumed that the ICMP traceback technique is deployed in the Internet and since the attack traffic in step 1 is destined to the victim V1, there is more probability for the routers R1, R2, R3, R4 to generate ICMP traceback messages to the victim V1. The number of ICMP traceback messages that can be generated to the victim is proportional to the total attack traffic generated by the zombie and the length of the path from the zombie to the victim. Even if the generation probability of ICMP traceback messages is less at the routers, it should be noted that we have only considered an attack with a single zombie. In the case of DDoS, several hundred zombies may be involved in the generation of this kind of attack traffic. Since a greater number of (attack) packets are generated to the victim, the probability of each router sending an ICMP traceback message to the victim V1 is also high, and this can have a considerable effect on the victim V1 network. So the victim V1 will notice an ICMP traceback message flood from the routers. This type of attack traffic is shown in step 3. Now, because of the ICMP time-exceeded flood messages generated at router R5 in step 2, there is more probability for all the routers in between router R5 and victim V2 to generate ICMP traceback messages to the victim V2. This type of attack traffic is shown in step 4. Note that the attacks in step 3 and in step 4 are represented by dotted line to show that these attacks are due to the deployment of the ICMP traceback technique in the Internet. However, it should be noted that the ICMP traceback messages generated in step 4 are very helpful to the victim V2 to trace back the

8 attacking source R5. If the attack in step 1 is generated with a random TTL which is less than or equal to N-1, then the traceback messages generated in step 4 will not be of any use to the victim V2. In addition to all these, the router R5 is also a victim of DoS attack, since it has to generate an ICMP timeexceeded message for each packet where the TTL expires at that point. It can be argued that attacks on victim V2 can be prevented by deploying ingress filtering at router R1 but it should be noted that traceback techniques are proposed to traceback the approximate source of attack in case of spoofed source addresses. If ingress filtering is deployed, we believe that there is no need for traceback technologies. We should note that the attacks generated in step 1 and step 2 can occur even if the ICMP traceback technique is not deployed in the Internet. The additional traffic generated in step 3 and step 4 is due to the deployment of the ICMP traceback technique. However there is one more interesting point, which is to be observed in this scenario. Even in the case of deployment of the ICMP traceback technique, there is no evidence of the attack traffic generated in step 1 at the victim V1, since no attack packet has actually reached the victim V1. So the victim cannot initiate legal proceeding on the zombie and hence the purpose of the ICMP traceback technique is defeated. If these attacks are to be prevented, then the routers should be modified to store the packets so that the traceback can be performed from the router at which the TTL expires. This is not a feasible solution, because even if router R5 is configured to log the expired TTL packets, it will not have any evidence of the attack because i) all the attack traffic has spoofed source address of the victim V2; and ii) since the packets are actually destined to victim V1, all the ICMP traceback messages are actually sent to victim V1 (instead of router R5). Further, configuring the routers to log these packets can lead to different types of DoS attacks on the routers. If any of the other packet marking techniques were deployed this would not cause the attacks shown in steps 3 and 4, but the attacks shown in steps 1 and 2 can still happen and the attacking source can remain untraced. In addition to the attack traffic generated in step 3, victim V1 can also receive traceback messages due to the good traffic sent to it. This is not shown in Figure 5. Further, the attacker/zombies can send faulty traceback messages. Similarly, the victim V2 can also receive the ICMP traceback messages due to the good traffic, attack traffic and the fraudulent ICMP traceback messages from the attacker. Even if the ICMP traceback technique uses some form of authentication for the ICMP traceback message packets, there are several challenges that are to be addressed. Some modifications to the ICMP traceback technique have also been proposed (Allison Mankin, Dan Massey, Chien-Long Wu, S. Felix Wu and Lixia Zhang 2001). Here ICMP messages are generated only when the intrusion detection system (deployed by the victim) intends to receive the traceback messages by setting the intention to receive a bit. This requires modification to the BGP protocol. Even if this technique is deployed, the attacker just needs to send a fraudulent intention to receive ICMP traceback messages and the remaining process is the same. 7.4 A simple demonstration In this section, we will present a simple demonstration to illustrate that DoS floods can be easily generated even without compromising any computers in the Internet. We will consider a real-time scenario to show how vulnerable the sites performing online business are to these DoS/DDoS attacks. A Windows machine has been used to demonstrate this scenario on one of the commercial server. We started with tracing the route from our machine to the commercial server using the tracert command ( tracert xyz 1.com ) in the command prompt. Figure 6 shows the output of this command. From the figure, it can be seen that the commercial server is 15 hops away from our machine (attacking source) and now we also know the complete path from our machine to the commercial server. We have generated a ping flood in such a way that the TTL was configured to expire at the 13 th hop router. This is achieved by typing ping xyz.com i 13 t in the command prompt. Figure 7 shows the output of this command. The option t is enabled in this case so that our machine will continuously ping the victim server until it receives the stop command. From the ping statistics in Figure 7, it is clear that the number of TTL expired packets received is equal to the number of ping packets sent. Now, if we spoof our source address with some other valid 32-bit IP address, all the TTL expired reply packets will be destined to the source address with which we have spoofed our own source address. As shown in Figure 8, we have spoofed our source address with a valid 32-bit IP address ( ) and generated the traffic. Since we have spoofed our machine s source IP address, we cannot get the DNS information from the DNS server. So we had to type ping ipaddress i 3 t instead of typing ping xyz.com i 3 t. In this case, the reply message will be destined to the source with which we have spoofed our IP address. This is a very simple scenario. In this scenario, a ping flood will not be generated using the complete processing power of our machine and the effect of the ping (attack) traffic is negligible on the routers or on the forged source address. Several attacking tools are readily available (CERT 2000) with which an attacker can generate the traffic/packets with the required parameters in the IP header and by completely utilising the processing power of the compromised machine. Since the ICMP traceback technique is not yet deployed, here we have not demonstrated how ICMP traceback messages are generated. 1 For the sake of anonymity, we have specified this as xyz.com although it was carried out on a real site with permission.

9 Darkened for anonymity Figure: 6 Figure: 7 Figure: 8

10 7.5 Minimising the additional traffic Let us discuss some techniques on how to minimize attacks generated in step 1 and step 2 as shown in figure 5. In the first instance, to prevent traffic with spoofed source address, ingress/egress filtering should be deployed at the edge routers of the ISP/customer networks. To route the packets to the destination, each router maintains a routing table, which maintains the known destinations and the number of hops to the particular destinations. In addition to the ingress/egress filtering, during routing, each router should check the packet has a TTL value greater than or equal to the number of hops stored in the routing table. 1. At every router 2. For each Packet P from source S to destination D 3. If TTL >= number of hops for D, route P 4. Else drop P and send an error message to S. This type of filtering should be performed on all the routers between the source S to destination D because it is to be noted that routers may decrease the TTL by a value more than 1 in case of congestion. This type of filtering has very high overhead at routers because all the packets have to be checked for the minimum TTL value at all the routers. Since ingress/egress filtering is also deployed all the error messages generated in step 4 in the above algorithm will be destined to the actual attacking source. An alternative approach to minimize the overhead on the routers is to check the packet for minimum TTL value only when the router picks the packet on some probability to send an ICMP traceback message to the destination. If the selected packet has a TTL value less than the required number of hops to the destination, the router should not send an ICMP traceback message to the destination D. This feature is already supported in the existing routers. In this case only the attack traffic generated in step3 in figure 5 can be prevented. 1. At every router 2. For packet P from source S to destination D picked on probability 1/ If TTL >= number of hops for D, route P and send ICMP traceback message to D. 4. Else drop P and send an error message to S. 8 Conclusion In this paper, we have presented a detailed analysis on some of the recently proposed traceback techniques. We have raised several issues so as to enable further research and analysed the traceback techniques from the attacker point of view. We have discussed how the attacker can generate DoS/DDoS attacks and remain untraced if some of the traceback techniques are deployed in the Internet. We have discussed several examples to support our arguments. We have shown a simple demonstration to show how easily DoS/DDoS attacks can be generated without being traced even if ICMP traceback technique is deployed in the current Internet. We have also discussed a new technique to minimise the attack traffic generated due to the implementation of ICMP traceback technique. We believe that the networks tend to become complex and more vulnerable to DDoS attacks if some of the proposed traceback techniques are deployed in the Internet. 9 References Alex C. Snoeren, Craig Partridge, Luis A. Sanchez,Christine E. Jones, Fabrice Tchakountio, Beverly Schwartz, Stephen T. Kent, and W. Timothy Strayer (2002): Single-packet IP traceback. IEEE/ACM Transactions on Networking (ToN), 10(6). Allison Mankin, Dan Massey, Chien-Long Wu, S. Felix Wu and Lixia Zhang (2001): On Design and Evaluation of Intention-Driven ICMP Traceback. Proc. of 10th IEEE International Conference on Computer Communications and Networks. V.Gill, J.Heasley and D.Meyer (2004): The generalized TTL security mechanism. RFC CERT (1998): CERT advisory CA Smurf IP Denial-of-Service Attacks. CERT (2000): CERT advisory CA denial-ofservice developments. D. Song and A.Perrig (2000): Advanced and Authenticated Marking Schemes for IP Traceback. Technical Report UCB/CSD , University of California, Berkeley. David Moore, Geoffrey M. Voelker and Stefan Savage (2001): Inferring internet denial -of-service activity. Proc. of the 10 th USENIX Security Symposium. Drew Dean, Matt Franklin and Adam Stubblefield (2001): An Algebraic Approach to IP Traceback. Proc. of the NDSS. Stefan Savage, David Wetherall, Anna Karlin and Tom Anderson (2000): Practical network support for IP traceback. Proc. of the ACM SIGCOMM Conference, pages Steven M. Bellovin (2001): ICMP Traceback Message. Internet Draft. Steve Gibson (2001): The Strange Tale of the Denial of Service Attacks on GRC.COM. S.Deshpande, M.Thottan and B.Sikdar (2004): Early detection of BGP Instabilities resulting from Internet Worm Attacks. Proc. of the IEEE Globecom, Dallas, Texas, USA. Ivan Arce (2004): More Bang for the Bug: An Account of 2003 s Attack Trends. IEEE Security & Privacy, Volume 2, Pages J.Postel (1981): Internet Protocol. RFC 791.

Analysis of Automated Model against DDoS Attacks

Analysis of Automated Model against DDoS Attacks Analysis of Automated Model against DDoS Attacks Udaya Kiran Tupakula Vijay Varadharajan Information and Networked Systems Security Research Division of Information and Communication Sciences Macquarie

More information

A Practical Method to Counteract Denial of Service Attacks

A Practical Method to Counteract Denial of Service Attacks A Practical Method to Counteract Denial of Service Attacks Udaya Kiran Tupakula Vijay Varadharajan Information and Networked System Security Research Division of Information and Communication Sciences

More information

A Survey of IP Traceback Mechanisms to overcome Denial-of-Service Attacks

A Survey of IP Traceback Mechanisms to overcome Denial-of-Service Attacks A Survey of IP Traceback Mechanisms to overcome Denial-of-Service Attacks SHWETA VINCENT, J. IMMANUEL JOHN RAJA Department of Computer Science and Engineering, School of Computer Science and Technology

More information

A Hybrid Approach for Detecting, Preventing, and Traceback DDoS Attacks

A Hybrid Approach for Detecting, Preventing, and Traceback DDoS Attacks A Hybrid Approach for Detecting, Preventing, and Traceback DDoS Attacks ALI E. EL-DESOKY 1, MARWA F. AREAD 2, MAGDY M. FADEL 3 Department of Computer Engineering University of El-Mansoura El-Gomhoria St.,

More information

Packet-Marking Scheme for DDoS Attack Prevention

Packet-Marking Scheme for DDoS Attack Prevention Abstract Packet-Marking Scheme for DDoS Attack Prevention K. Stefanidis and D. N. Serpanos {stefanid, serpanos}@ee.upatras.gr Electrical and Computer Engineering Department University of Patras Patras,

More information

Flexible Deterministic Packet Marking: An IP Traceback Scheme Against DDOS Attacks

Flexible Deterministic Packet Marking: An IP Traceback Scheme Against DDOS Attacks Flexible Deterministic Packet Marking: An IP Traceback Scheme Against DDOS Attacks Prashil S. Waghmare PG student, Sinhgad College of Engineering, Vadgaon, Pune University, Maharashtra, India. prashil.waghmare14@gmail.com

More information

DDoS Attack Traceback and Beyond. Yongjin Kim

DDoS Attack Traceback and Beyond. Yongjin Kim DDoS Attack Traceback and Beyond Yongjin Kim Outline Existing DDoS attack traceback (or commonly called IP traceback) schemes * Probabilistic packet marking Logging-based scheme ICMP-based scheme Tweaking

More information

Comparing Two Models of Distributed Denial of Service (DDoS) Defences

Comparing Two Models of Distributed Denial of Service (DDoS) Defences Comparing Two Models of Distributed Denial of Service (DDoS) Defences Siriwat Karndacharuk Computer Science Department The University of Auckland Email: skar018@ec.auckland.ac.nz Abstract A Controller-Agent

More information

A Novel Packet Marketing Method in DDoS Attack Detection

A Novel Packet Marketing Method in DDoS Attack Detection SCI-PUBLICATIONS Author Manuscript American Journal of Applied Sciences 4 (10): 741-745, 2007 ISSN 1546-9239 2007 Science Publications A Novel Packet Marketing Method in DDoS Attack Detection 1 Changhyun

More information

Firewalls and Intrusion Detection

Firewalls and Intrusion Detection Firewalls and Intrusion Detection What is a Firewall? A computer system between the internal network and the rest of the Internet A single computer or a set of computers that cooperate to perform the firewall

More information

Denial of Service. Tom Chen SMU tchen@engr.smu.edu

Denial of Service. Tom Chen SMU tchen@engr.smu.edu Denial of Service Tom Chen SMU tchen@engr.smu.edu Outline Introduction Basics of DoS Distributed DoS (DDoS) Defenses Tracing Attacks TC/BUPT/8704 SMU Engineering p. 2 Introduction What is DoS? 4 types

More information

Dr. Arjan Durresi Louisiana State University, Baton Rouge, LA 70803 durresi@csc.lsu.edu. DDoS and IP Traceback. Overview

Dr. Arjan Durresi Louisiana State University, Baton Rouge, LA 70803 durresi@csc.lsu.edu. DDoS and IP Traceback. Overview DDoS and IP Traceback Dr. Arjan Durresi Louisiana State University, Baton Rouge, LA 70803 durresi@csc.lsu.edu Louisiana State University DDoS and IP Traceback - 1 Overview Distributed Denial of Service

More information

NEW TECHNIQUES FOR THE DETECTION AND TRACKING OF THE DDOS ATTACKS

NEW TECHNIQUES FOR THE DETECTION AND TRACKING OF THE DDOS ATTACKS NEW TECHNIQUES FOR THE DETECTION AND TRACKING OF THE DDOS ATTACKS Iustin PRIESCU, PhD Titu Maiorescu University, Bucharest Sebastian NICOLAESCU, PhD Verizon Business, New York, USA Rodica NEAGU, MBA Outpost24,

More information

Port Hopping for Resilient Networks

Port Hopping for Resilient Networks Port Hopping for Resilient Networks Henry C.J. Lee, Vrizlynn L.L. Thing Institute for Infocomm Research Singapore Email: {hlee, vriz}@i2r.a-star.edu.sg Abstract With the pervasiveness of the Internet,

More information

Security vulnerabilities in the Internet and possible solutions

Security vulnerabilities in the Internet and possible solutions Security vulnerabilities in the Internet and possible solutions 1. Introduction The foundation of today's Internet is the TCP/IP protocol suite. Since the time when these specifications were finished in

More information

An Efficient Filter for Denial-of-Service Bandwidth Attacks

An Efficient Filter for Denial-of-Service Bandwidth Attacks An Efficient Filter for Denial-of-Service Bandwidth Attacks Samuel Abdelsayed, David Glimsholt, Christopher Leckie, Simon Ryan and Samer Shami Department of Electrical and Electronic Engineering ARC Special

More information

Defenses against Distributed Denial of Service Attacks. Internet Threat: DDoS Attacks

Defenses against Distributed Denial of Service Attacks. Internet Threat: DDoS Attacks Defenses against Distributed Denial of Service Attacks Adrian Perrig, Dawn Song, Avi Yaar CMU Internet Threat: DDoS Attacks Denial of Service (DoS) attack: consumption (exhaustion) of resources to deny

More information

Frequent Denial of Service Attacks

Frequent Denial of Service Attacks Frequent Denial of Service Attacks Aditya Vutukuri Science Department University of Auckland E-mail:avut001@ec.auckland.ac.nz Abstract Denial of Service is a well known term in network security world as

More information

Abstract. Introduction. Section I. What is Denial of Service Attack?

Abstract. Introduction. Section I. What is Denial of Service Attack? Abstract In this report, I am describing the main types of DoS attacks and their effect on computer and network environment. This report will form the basis of my forthcoming report which will discuss

More information

Strategies to Protect Against Distributed Denial of Service (DD

Strategies to Protect Against Distributed Denial of Service (DD Strategies to Protect Against Distributed Denial of Service (DD Table of Contents Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks...1 Introduction...1 Understanding the Basics

More information

CS 356 Lecture 16 Denial of Service. Spring 2013

CS 356 Lecture 16 Denial of Service. Spring 2013 CS 356 Lecture 16 Denial of Service Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control Lists Chapter

More information

SECURITY FLAWS IN INTERNET VOTING SYSTEM

SECURITY FLAWS IN INTERNET VOTING SYSTEM SECURITY FLAWS IN INTERNET VOTING SYSTEM Sandeep Mudana Computer Science Department University of Auckland Email: smud022@ec.auckland.ac.nz Abstract With the rapid growth in computer networks and internet,

More information

Proving Distributed Denial of Service Attacks in the Internet

Proving Distributed Denial of Service Attacks in the Internet Proving Distributed Denial of Service Attacks in the Internet Prashanth Radhakrishnan, Manu Awasthi, Chitra Aravamudhan {shanth, manua, caravamu}@cs.utah.edu Abstract In this course report, we present

More information

Tackling Congestion to Address Distributed Denial of Service: A Push-Forward Mechanism

Tackling Congestion to Address Distributed Denial of Service: A Push-Forward Mechanism Tackling Congestion to Address Distributed Denial of Service: A Push-Forward Mechanism Srinivasan Krishnamoorthy and Partha Dasgupta Computer Science and Engineering Department Arizona State University

More information

Federal Computer Incident Response Center (FedCIRC) Defense Tactics for Distributed Denial of Service Attacks

Federal Computer Incident Response Center (FedCIRC) Defense Tactics for Distributed Denial of Service Attacks Threat Paper Federal Computer Incident Response Center (FedCIRC) Defense Tactics for Distributed Denial of Service Attacks Federal Computer Incident Response Center 7 th and D Streets S.W. Room 5060 Washington,

More information

Provider-Based Deterministic Packet Marking against Distributed DoS Attacks

Provider-Based Deterministic Packet Marking against Distributed DoS Attacks Provider-Based Deterministic Packet Marking against Distributed DoS Attacks Vasilios A. Siris and Ilias Stavrakis Institute of Computer Science, Foundation for Research and Technology - Hellas (FORTH)

More information

An IP Trace back System to Find the Real Source of Attacks

An IP Trace back System to Find the Real Source of Attacks An IP Trace back System to Find the Real Source of Attacks A.Parvathi and G.L.N.JayaPradha M.Tech Student,Narasaraopeta Engg College, Narasaraopeta,Guntur(Dt),A.P. Asso.Prof & HOD,Dept of I.T,,Narasaraopeta

More information

Announcements. No question session this week

Announcements. No question session this week Announcements No question session this week Stretch break DoS attacks In Feb. 2000, Yahoo s router kept crashing - Engineers had problems with it before, but this was worse - Turned out they were being

More information

International Journal of Emerging Technologies in Computational and Applied Sciences (IJETCAS) www.iasir.net

International Journal of Emerging Technologies in Computational and Applied Sciences (IJETCAS) www.iasir.net International Association of Scientific Innovation and Research (IASIR) (An Association Unifying the Sciences, Engineering, and Applied Research) International Journal of Emerging Technologies in Computational

More information

Depth-in-Defense Approach against DDoS

Depth-in-Defense Approach against DDoS 6th WSEAS International Conference on Information Security and Privacy, Tenerife, Spain, December 14-16, 2007 102 Depth-in-Defense Approach against DDoS Rabia Sirhindi, Asma Basharat and Ahmad Raza Cheema

More information

Defending against Flooding-Based Distributed Denial-of-Service Attacks: A Tutorial

Defending against Flooding-Based Distributed Denial-of-Service Attacks: A Tutorial Defending against Flooding-Based Distributed Denial-of-Service Attacks: A Tutorial Rocky K. C. Chang The Hong Kong Polytechnic University Presented by Scott McLaren 1 Overview DDoS overview Types of attacks

More information

Towards Improving an Algebraic Marking Scheme for Tracing DDoS Attacks

Towards Improving an Algebraic Marking Scheme for Tracing DDoS Attacks International Journal of Network Security, Vol.9, No.3, PP.204 213, Nov. 2009 204 Towards Improving an Algebraic Marking Scheme for Tracing DDoS Attacks Moon-Chuen Lee, Yi-Jun He, and Zhaole Chen (Corresponding

More information

Classification and State of Art of IP Traceback Techniques for DDoS Defense

Classification and State of Art of IP Traceback Techniques for DDoS Defense Classification and State of Art of IP Traceback Techniques for DDoS Defense Karanpreet Singh a, Krishan Kumar b, Abhinav Bhandari c,* a Computer Science & Engg.,Punjab Institute of Technology,Kapurthala,

More information

ForNet: A Distributed Forensic Network

ForNet: A Distributed Forensic Network ForNet: A Distributed Forensic Network Kulesh Shanmugasundaram Polytechnic University 1 Problem and Motivation Security fails. Thousands of reported security breaches, worms, and viruses attest to this

More information

Distributed Denial of Service(DDoS) Attack Techniques and Prevention on Cloud Environment

Distributed Denial of Service(DDoS) Attack Techniques and Prevention on Cloud Environment Distributed Denial of Service(DDoS) Attack Techniques and Prevention on Cloud Environment Keyur Chauhan 1,Vivek Prasad 2 1 Student, Institute of Technology, Nirma University (India) 2 Assistant Professor,

More information

Survey on DDoS Attack Detection and Prevention in Cloud

Survey on DDoS Attack Detection and Prevention in Cloud Survey on DDoS Detection and Prevention in Cloud Patel Ankita Fenil Khatiwala Computer Department, Uka Tarsadia University, Bardoli, Surat, Gujrat Abstract: Cloud is becoming a dominant computing platform

More information

Distributed Denial of Service (DDoS)

Distributed Denial of Service (DDoS) Distributed Denial of Service (DDoS) Defending against Flooding-Based DDoS Attacks: A Tutorial Rocky K. C. Chang Presented by Adwait Belsare (adwait@wpi.edu) Suvesh Pratapa (suveshp@wpi.edu) Modified by

More information

SECURING APACHE : DOS & DDOS ATTACKS - I

SECURING APACHE : DOS & DDOS ATTACKS - I SECURING APACHE : DOS & DDOS ATTACKS - I In this part of the series, we focus on DoS/DDoS attacks, which have been among the major threats to Web servers since the beginning of the Web 2.0 era. Denial

More information

DDoS Attack and Defense: Review of Some Traditional and Current Techniques

DDoS Attack and Defense: Review of Some Traditional and Current Techniques 1 DDoS Attack and Defense: Review of Some Traditional and Current Techniques Muhammad Aamir and Mustafa Ali Zaidi SZABIST, Karachi, Pakistan Abstract Distributed Denial of Service (DDoS) attacks exhaust

More information

ICMP Protocol and Its Security

ICMP Protocol and Its Security Lecture Notes (Syracuse University) ICMP Protocol and Its Security: 1 ICMP Protocol and Its Security 1 ICMP Protocol (Internet Control Message Protocol Motivation Purpose IP may fail to deliver datagrams

More information

Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks

Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks Document ID: 13634 Contents Introduction Understanding the Basics of DDoS Attacks Characteristics of Common Programs Used to Facilitate

More information

DDOS WALL: AN INTERNET SERVICE PROVIDER PROTECTOR

DDOS WALL: AN INTERNET SERVICE PROVIDER PROTECTOR Journal homepage: www.mjret.in DDOS WALL: AN INTERNET SERVICE PROVIDER PROTECTOR Maharudra V. Phalke, Atul D. Khude,Ganesh T. Bodkhe, Sudam A. Chole Information Technology, PVPIT Bhavdhan Pune,India maharudra90@gmail.com,

More information

co Characterizing and Tracing Packet Floods Using Cisco R

co Characterizing and Tracing Packet Floods Using Cisco R co Characterizing and Tracing Packet Floods Using Cisco R Table of Contents Characterizing and Tracing Packet Floods Using Cisco Routers...1 Introduction...1 Before You Begin...1 Conventions...1 Prerequisites...1

More information

Tracing Network Attacks to Their Sources

Tracing Network Attacks to Their Sources Tracing Network s to Their Sources Security An IP traceback architecture in which routers log data about packets and adjacent forwarding nodes lets us trace s to their sources, even when the source IP

More information

Dual Mechanism to Detect DDOS Attack Priyanka Dembla, Chander Diwaker 2 1 Research Scholar, 2 Assistant Professor

Dual Mechanism to Detect DDOS Attack Priyanka Dembla, Chander Diwaker 2 1 Research Scholar, 2 Assistant Professor International Association of Scientific Innovation and Research (IASIR) (An Association Unifying the Sciences, Engineering, and Applied Research) International Journal of Engineering, Business and Enterprise

More information

A Flow-based Method for Abnormal Network Traffic Detection

A Flow-based Method for Abnormal Network Traffic Detection A Flow-based Method for Abnormal Network Traffic Detection Myung-Sup Kim, Hun-Jeong Kang, Seong-Cheol Hong, Seung-Hwa Chung, and James W. Hong Dept. of Computer Science and Engineering POSTECH {mount,

More information

Tracing the Origins of Distributed Denial of Service Attacks

Tracing the Origins of Distributed Denial of Service Attacks Tracing the Origins of Distributed Denial of Service Attacks A.Peart Senior Lecturer amanda.peart@port.ac.uk University of Portsmouth, UK R.Raynsford. Student robert.raynsford@myport.ac.uk University of

More information

Distributed Denial of Service

Distributed Denial of Service Distributed Denial of Service Dr. Arjan Durresi Louisiana State University Baton Rouge, LA 70810 Durresi@Csc.LSU.Edu These slides are available at: http://www.csc.lsu.edu/~durresi/csc7502_04/ Louisiana

More information

TECHNICAL NOTE 06/02 RESPONSE TO DISTRIBUTED DENIAL OF SERVICE (DDOS) ATTACKS

TECHNICAL NOTE 06/02 RESPONSE TO DISTRIBUTED DENIAL OF SERVICE (DDOS) ATTACKS TECHNICAL NOTE 06/02 RESPONSE TO DISTRIBUTED DENIAL OF SERVICE (DDOS) ATTACKS 2002 This paper was previously published by the National Infrastructure Security Co-ordination Centre (NISCC) a predecessor

More information

Denial of Service (DoS) Technical Primer

Denial of Service (DoS) Technical Primer Denial of Service (DoS) Technical Primer Chris McNab Principal Consultant, Matta Security Limited chris.mcnab@trustmatta.com Topics Covered What is Denial of Service? Categories and types of Denial of

More information

A Stateless Traceback Technique for Identifying the Origin of Attacks from a Single Packet

A Stateless Traceback Technique for Identifying the Origin of Attacks from a Single Packet A Stateless Traceback Technique for Identifying the Origin of Attacks from a Single Packet Marcelo D. D. Moreira, Rafael P. Laufer, Natalia C. Fernandes, and Otto Carlos M. B. Duarte Universidade Federal

More information

Guide to DDoS Attacks December 2014 Authored by: Lee Myers, SOC Analyst

Guide to DDoS Attacks December 2014 Authored by: Lee Myers, SOC Analyst INTEGRATED INTELLIGENCE CENTER Technical White Paper William F. Pelgrin, CIS President and CEO Guide to DDoS Attacks December 2014 Authored by: Lee Myers, SOC Analyst This Center for Internet Security

More information

Client Server Registration Protocol

Client Server Registration Protocol Client Server Registration Protocol The Client-Server protocol involves these following steps: 1. Login 2. Discovery phase User (Alice or Bob) has K s Server (S) has hash[pw A ].The passwords hashes are

More information

You Can Run, But You Can t Hide: An Effective Methodology to Traceback DDoS Attackers

You Can Run, But You Can t Hide: An Effective Methodology to Traceback DDoS Attackers You Can Run, But You Can t Hide: An Effective Methodology to Traceback DDoS Attackers K.T. Law Department of Computer Science & Engineering The Chinese University of Hong Kong ktlaw@cse.cuhk.edu.hk John

More information

The Internet provides a wealth of information,

The Internet provides a wealth of information, IP Traceback: A New Denial-of-Service Deterrent? The increasing frequency of malicious computer attacks on government agencies and Internet businesses has caused severe economic waste and unique social

More information

Outline. CSc 466/566. Computer Security. 18 : Network Security Introduction. Network Topology. Network Topology. Christian Collberg

Outline. CSc 466/566. Computer Security. 18 : Network Security Introduction. Network Topology. Network Topology. Christian Collberg Outline Network Topology CSc 466/566 Computer Security 18 : Network Security Introduction Version: 2012/05/03 13:59:29 Department of Computer Science University of Arizona collberg@gmail.com Copyright

More information

Internet Firewall CSIS 4222. Packet Filtering. Internet Firewall. Examples. Spring 2011 CSIS 4222. net15 1. Routers can implement packet filtering

Internet Firewall CSIS 4222. Packet Filtering. Internet Firewall. Examples. Spring 2011 CSIS 4222. net15 1. Routers can implement packet filtering Internet Firewall CSIS 4222 A combination of hardware and software that isolates an organization s internal network from the Internet at large Ch 27: Internet Routing Ch 30: Packet filtering & firewalls

More information

DDPM: Dynamic Deterministic Packet Marking for IP Traceback

DDPM: Dynamic Deterministic Packet Marking for IP Traceback DDPM: Dynamic Deterministic Packet Marking for IP Traceback Reza Shokri, Ali Varshovi, Hossein Mohammadi, Nasser Yazdani, Babak Sadeghian Router Laboratory, ECE Department, University of Tehran, Tehran,

More information

Internet Control Message Protocol (ICMP)

Internet Control Message Protocol (ICMP) Internet Control Message Protocol (ICMP) Relates to Lab 2: A short module on the Internet Control Message Protocol (ICMP). 1 Overview The IP (Internet Protocol) relies on several other protocols to perform

More information

Filtering Based Techniques for DDOS Mitigation

Filtering Based Techniques for DDOS Mitigation Filtering Based Techniques for DDOS Mitigation Comp290: Network Intrusion Detection Manoj Ampalam DDOS Attacks: Target CPU / Bandwidth Attacker signals slaves to launch an attack on a specific target address

More information

Design and Experiments of small DDoS Defense System using Traffic Deflecting in Autonomous System

Design and Experiments of small DDoS Defense System using Traffic Deflecting in Autonomous System Design and Experiments of small DDoS Defense System using Traffic Deflecting in Autonomous System Ho-Seok Kang and Sung-Ryul Kim Konkuk University Seoul, Republic of Korea hsriver@gmail.com and kimsr@konkuk.ac.kr

More information

2. Design. 2.1 Secure Overlay Services (SOS) IJCSNS International Journal of Computer Science and Network Security, VOL.7 No.

2. Design. 2.1 Secure Overlay Services (SOS) IJCSNS International Journal of Computer Science and Network Security, VOL.7 No. IJCSNS International Journal of Computer Science and Network Security, VOL.7 No.7, July 2007 167 Design and Development of Proactive Models for Mitigating Denial-of-Service and Distributed Denial-of-Service

More information

Internet Protocol: IP packet headers. vendredi 18 octobre 13

Internet Protocol: IP packet headers. vendredi 18 octobre 13 Internet Protocol: IP packet headers 1 IPv4 header V L TOS Total Length Identification F Frag TTL Proto Checksum Options Source address Destination address Data (payload) Padding V: Version (IPv4 ; IPv6)

More information

A TWO LEVEL ARCHITECTURE USING CONSENSUS METHOD FOR GLOBAL DECISION MAKING AGAINST DDoS ATTACKS

A TWO LEVEL ARCHITECTURE USING CONSENSUS METHOD FOR GLOBAL DECISION MAKING AGAINST DDoS ATTACKS ICTACT JOURNAL ON COMMUNICATION TECHNOLOGY, JUNE 2010, ISSUE: 02 A TWO LEVEL ARCHITECTURE USING CONSENSUS METHOD FOR GLOBAL DECISION MAKING AGAINST DDoS ATTACKS S.Seetha 1 and P.Raviraj 2 Department of

More information

Internet Infrastructure Measurement: Challenges and Tools

Internet Infrastructure Measurement: Challenges and Tools Internet Infrastructure Measurement: Challenges and Tools Internet Infrastructure Measurement: Challenges and Tools Outline Motivation Challenges Tools Conclusion Why Measure? Why Measure? Internet, with

More information

Survey on DDoS Attacks and its Detection & Defence Approaches

Survey on DDoS Attacks and its Detection & Defence Approaches International Journal of Science and Modern Engineering (IJISME) Survey on DDoS Attacks and its Detection & Defence Approaches Nisha H. Bhandari Abstract In Cloud environment, cloud servers providing requested

More information

Safeguards Against Denial of Service Attacks for IP Phones

Safeguards Against Denial of Service Attacks for IP Phones W H I T E P A P E R Denial of Service (DoS) attacks on computers and infrastructure communications systems have been reported for a number of years, but the accelerated deployment of Voice over IP (VoIP)

More information

Internet Protocol trace back System for Tracing Sources of DDoS Attacks and DDoS Detection in Neural Network Packet Marking

Internet Protocol trace back System for Tracing Sources of DDoS Attacks and DDoS Detection in Neural Network Packet Marking Internet Protocol trace back System for Tracing Sources of DDoS Attacks and DDoS Detection in Neural Network Packet Marking 1 T. Ravi Kumar, 2 T Padmaja, 3 P. Samba Siva Raju 1,3 Sri Venkateswara Institute

More information

IP addressing and forwarding Network layer

IP addressing and forwarding Network layer The Internet Network layer Host, router network layer functions: IP addressing and forwarding Network layer Routing protocols path selection RIP, OSPF, BGP Transport layer: TCP, UDP forwarding table IP

More information

On Evaluating IP Traceback Schemes: A Practical Perspective

On Evaluating IP Traceback Schemes: A Practical Perspective 2013 IEEE Security and Privacy Workshops On Evaluating IP Traceback Schemes: A Practical Perspective Vahid Aghaei-Foroushani Faculty of Computer Science Dalhousie University Halifax, NS, Canada vahid@cs.dal.ca

More information

Firewalls and intrusion detection systems

Firewalls and intrusion detection systems Firewalls and intrusion detection systems Markus Peuhkuri 2005-03-22 Lecture topics Firewalls Security model with firewalls Intrusion detection systems Intrusion prevention systems How to prevent and detect

More information

Yahoo Attack. Is DDoS a Real Problem?

Yahoo Attack. Is DDoS a Real Problem? Is DDoS a Real Problem? Yes, attacks happen every day One study reported ~4,000 per week 1 On a wide variety of targets Tend to be highly successful There are few good existing mechanisms to stop them

More information

Survey on DDoS Attack in Cloud Environment

Survey on DDoS Attack in Cloud Environment Available online at www.ijiere.com International Journal of Innovative and Emerging Research in Engineering e-issn: 2394-3343 p-issn: 2394-5494 Survey on DDoS in Cloud Environment Kirtesh Agrawal and Nikita

More information

Denial of Service Attacks, What They are and How to Combat Them

Denial of Service Attacks, What They are and How to Combat Them Denial of Service Attacks, What They are and How to Combat Them John P. Pironti, CISSP Genuity, Inc. Principal Enterprise Solutions Architect Principal Security Consultant Version 1.0 November 12, 2001

More information

DDoS-blocker: Detection and Blocking of Distributed Denial of Service Attack

DDoS-blocker: Detection and Blocking of Distributed Denial of Service Attack DDoS-blocker: Detection and Blocking of Distributed Denial of Service Attack Sugih Jamin EECS Department University of Michigan jamin@eecs.umich.edu Internet Design Goals Key design goals of Internet protocols:

More information

OSI Network Layer OSI Layer 3

OSI Network Layer OSI Layer 3 OSI Network Layer OSI Layer 3 Network Fundamentals Chapter 5 ١ Objectives Identify the role of the Network Layer, as it describes communication from one end device to another end device Examine the most

More information

DDoS Protection Technology White Paper

DDoS Protection Technology White Paper DDoS Protection Technology White Paper Keywords: DDoS attack, DDoS protection, traffic learning, threshold adjustment, detection and protection Abstract: This white paper describes the classification of

More information

An IP Traceback Technique against Denial-of-Service Attacks

An IP Traceback Technique against Denial-of-Service Attacks An IP Traceback Technique against Denial-of-Service Attacks Zhaole Chen, Moon-Chuen Lee Computer Science & Engineering Department, the Chinese University of Hong Kong {zlchen, mclee@cse.cuhk.edu.hk Abstract

More information

Vulnerability Analysis of Hash Tables to Sophisticated DDoS Attacks

Vulnerability Analysis of Hash Tables to Sophisticated DDoS Attacks International Journal of Information & Computation Technology. ISSN 0974-2239 Volume 4, Number 12 (2014), pp. 1167-1173 International Research Publications House http://www. irphouse.com Vulnerability

More information

CS5008: Internet Computing

CS5008: Internet Computing CS5008: Internet Computing Lecture 22: Internet Security A. O Riordan, 2009, latest revision 2015 Internet Security When a computer connects to the Internet and begins communicating with others, it is

More information

Protocol Rollback and Network Security

Protocol Rollback and Network Security CSE 484 / CSE M 584 (Spring 2012) Protocol Rollback and Network Security Tadayoshi Kohno Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin, John Manferdelli, John Mitchell, Vitaly Shmatikov, Bennet Yee,

More information

Assignment 6: Internetworking Due October 17/18, 2012

Assignment 6: Internetworking Due October 17/18, 2012 Assignment 6: Internetworking Due October 17/18, 2012 Our topic this week will be the notion of internetworking in general and IP, the Internet Protocol, in particular. IP is the foundation of the Internet

More information

Inter-provider Coordination for Real-Time Tracebacks

Inter-provider Coordination for Real-Time Tracebacks Inter-provider Coordination for Real-Time Tracebacks Kathleen M. Moriarty 2 June 2003 This work was sponsored by the Air Force Contract number F19628-00-C-002. Opinions, interpretations, conclusions, and

More information

TTL based Packet Marking for IP Traceback

TTL based Packet Marking for IP Traceback TTL based Packet Marking for IP Traceback Vamsi Paruchuri, Aran Durresi and Sriram Chellappan* Abstract Distributed Denial of Service Attacks continue to pose maor threats to the Internet. In order to

More information

ATTACK PATTERNS FOR DETECTING AND PREVENTING DDOS AND REPLAY ATTACKS

ATTACK PATTERNS FOR DETECTING AND PREVENTING DDOS AND REPLAY ATTACKS ATTACK PATTERNS FOR DETECTING AND PREVENTING DDOS AND REPLAY ATTACKS A.MADHURI Department of Computer Science Engineering, PVP Siddhartha Institute of Technology, Vijayawada, Andhra Pradesh, India. A.RAMANA

More information

Tracking and Tracing Spoofed IP Packets to Their Sources

Tracking and Tracing Spoofed IP Packets to Their Sources Tracking and Tracing Spoofed IP Packets to Their Sources Alaaeldin A. Aly, College of IT, aly@uaeu.ac.ae Ezedin Barka, College of IT, ebarka@uaeu.ac.ae U.A.E. University, Al-Ain, P.O. Box: 17555, U.A.E.

More information

Dos & DDoS Attack Signatures (note supplied by Steve Tonkovich of CAPTUS NETWORKS)

Dos & DDoS Attack Signatures (note supplied by Steve Tonkovich of CAPTUS NETWORKS) Dos & DDoS Attack Signatures (note supplied by Steve Tonkovich of CAPTUS NETWORKS) Signature based IDS systems use these fingerprints to verify that an attack is taking place. The problem with this method

More information

Towards Stateless Single-Packet IP Traceback

Towards Stateless Single-Packet IP Traceback Towards Stateless Single-Packet IP Traceback Rafael P. Laufer, Pedro B. Velloso, Daniel de O. Cunha, Igor M. Moraes, Marco D. D. Bicudo, Marcelo D. D. Moreira, and Otto Carlos M. B. Duarte University of

More information

Application of Netflow logs in Analysis and Detection of DDoS Attacks

Application of Netflow logs in Analysis and Detection of DDoS Attacks International Journal of Computer and Internet Security. ISSN 0974-2247 Volume 8, Number 1 (2016), pp. 1-8 International Research Publication House http://www.irphouse.com Application of Netflow logs in

More information

Proceedings of the UGC Sponsored National Conference on Advanced Networking and Applications, 27 th March 2015

Proceedings of the UGC Sponsored National Conference on Advanced Networking and Applications, 27 th March 2015 A New Approach to Detect, Filter And Trace the DDoS Attack S.Gomathi, M.Phil Research scholar, Department of Computer Science, Government Arts College, Udumalpet-642126. E-mail id: gomathipriya1988@gmail.com

More information

#42 D A N T E I N P R I N T. Tackling Network DoS on Transit Networks. David Harmelin

#42 D A N T E I N P R I N T. Tackling Network DoS on Transit Networks. David Harmelin D A T E I P R I T #42 Tackling etwork DoS on Transit etworks David Harmelin DATE I PRIT is a track record of papers and articles published by, or on behalf of DATE. HTML and Postscript versions are available

More information

2-7 The Mathematics Models and an Actual Proof Experiment for IP Traceback System

2-7 The Mathematics Models and an Actual Proof Experiment for IP Traceback System 2-7 The Mathematics Models and an Actual Proof Experiment for IP Traceback System SUZUKI Ayako, OHMORI Keisuke, MATSUSHIMA Ryu, KAWABATA Mariko, OHMURO Manabu, KAI Toshifumi, and NISHIYAMA Shigeru IP traceback

More information

9025- TCP/IP Networking. History and Standards. Review of Numbering Systems. Local Signaling. IP Addressing

9025- TCP/IP Networking. History and Standards. Review of Numbering Systems. Local Signaling. IP Addressing 9025- TCP/IP Networking History and Standards ARPA NCP TCP, IP, ARPANET PARC Collaborative Network Requirements One Protocol? Peer-to-Peer Protocols Documentation and RFCs RFC Categories Where to Find

More information

A Novel Distributed Denial of Service (DDoS) Attacks Discriminating Detection in Flash Crowds

A Novel Distributed Denial of Service (DDoS) Attacks Discriminating Detection in Flash Crowds International Journal of Research Studies in Science, Engineering and Technology Volume 1, Issue 9, December 2014, PP 139-143 ISSN 2349-4751 (Print) & ISSN 2349-476X (Online) A Novel Distributed Denial

More information

Gaurav Gupta CMSC 681

Gaurav Gupta CMSC 681 Gaurav Gupta CMSC 681 Abstract A distributed denial-of-service (DDoS) attack is one in which a multitude of compromised systems attack a single target, thereby causing Denial of Service for users of the

More information

Denial of Service in Sensor Networks

Denial of Service in Sensor Networks Denial of Service in Sensor Networks Authors : From: Anthony D. Wood John A. Stankovic University of Virginia Presented by: Luba Sakharuk Agenda for the DOS in Sensor Networks Abstract Theory and Application

More information

EFFICIENT AND SECURE AUTONOMOUS SYSTEM BASED TRACEBACK

EFFICIENT AND SECURE AUTONOMOUS SYSTEM BASED TRACEBACK Journal of Interconnection Networks c World Scientific Publishing Company EFFICIENT AND SECURE AUTONOMOUS SYSTEM BASED TRACEBACK ARJAN DURRESI 1,VAMSI PARUCHURI 1, LEONARD BAROLLI 2, RAJGOPAL KANNAN 1,

More information

Analysis of IP Spoofed DDoS Attack by Cryptography

Analysis of IP Spoofed DDoS Attack by Cryptography www..org 13 Analysis of IP Spoofed DDoS Attack by Cryptography Dalip Kumar Research Scholar, Deptt. of Computer Science Engineering, Institute of Engineering and Technology, Alwar, India. Abstract Today,

More information

An Anomaly-Based Method for DDoS Attacks Detection using RBF Neural Networks

An Anomaly-Based Method for DDoS Attacks Detection using RBF Neural Networks 2011 International Conference on Network and Electronics Engineering IPCSIT vol.11 (2011) (2011) IACSIT Press, Singapore An Anomaly-Based Method for DDoS Attacks Detection using RBF Neural Networks Reyhaneh

More information

DDoS Overview and Incident Response Guide. July 2014

DDoS Overview and Incident Response Guide. July 2014 DDoS Overview and Incident Response Guide July 2014 Contents 1. Target Audience... 2 2. Introduction... 2 3. The Growing DDoS Problem... 2 4. DDoS Attack Categories... 4 5. DDoS Mitigation... 5 1 1. Target

More information