Blocking of Flooding Attacks: Using Active Internet Traffic Filtering Mechanism

Transcription

1 Blocking of Flooding Attacks: Using Active Internet Traffic Filtering Mechanism Deepthi.S #1, Prashanti.G *2, Sandhya Rani.Kr #3 # Assistant Professor, Department of Computer Science and Engineering Vignan s Lara Institute of Technology and Science Vadlamudi, Guntur, India Abstract Now a day there is a dramatic increase in the frequency of distributed denial-of-service (DDoS) attacks. These attacks are an acute contemporary problem, with few practical solutions available today; one of the Fundamental limitations of the Internet is which allows anonymous people to access the network. Whenever the attacker wants to block the receiver for some amount of time they will send a disruptive flow which halt the receiver and they consume receiver s network link resources. Critical infrastructures and businesses alike are vulnerable to DoS attacks flood of data that can incapacitate their networks with traffic floods. Unfortunately, current mechanisms require per-flow state at routers, ISP collaboration, or the deployment of an overlay infrastructure to defend against these events. In a bandwidth-flooding attack. A large number of compromised sources send high-volume traffic to the target with the purpose of causing congestion in its Receivers circuit and disrupting its legitimate communications. We proposed a mechanism called a enhanced Active Internet Traffic Filtering (AITF), a network layer Defense mechanism against such attacks [3]. AITF preserves a significant fraction of a receiver s bandwidth in the face of bandwidth flooding.aitf can maintain their connectivity between the nodes that are connected in the network in the face of Bandwidth flooding. Hence, the network-layer of the Internet can provide an effective, Scalable and incrementally deployable solution against bandwidth-flooding attacks. Keywords Denial of Services Defences, Network level security and Protection, Traffic Filtering. Flooding I. INTRODUCTION In a bandwidth-flooding attack, compromised sources send high-volume traffic to the target with the purpose of causing congestion in its Receivers circuit and interrupting its legitimate communications. Active Internet Traffic Filtering (AITF), a network-layer defence mechanism against such attacks. AITF enables a receiver to contact misbehaving sources and ask them to stop sending it traffic; each source that has been asked to stop is policed by its own Internet service provider (ISP), which ensures its compliance. An ISP that hosts misbehaving sources both supports AITF (and accepts to police its misbehaving clients), or risks losing all access to the complaining receiver this is a strong incentive to cooperate, especially when the receiver is a popular publicaccess site. Real-life reports complement such analysis: The first well documented incident we are aware of is the 2001 attack against the Gibson Research Corporation (GRC) web site. To block the flood, GRC analysed the undesired traffic, determined its sources, and asked from their Internet service provider (ISP) to manually install filters that blocked traffic from these sources; in the meantime, their site was unreachable for more than 30hours.More recent attacks are less well documented (the victims are increasingly unwilling to reveal the details), but hint that botnet sizes have increased beyond thousands of sources, while undesired traffic is harder to identify. There are two basic steps in stopping a bandwidthflooding attack: 1) Identifying undesired traffic 2) And Blocking it. To prevent undesired traffic from causing legitimate-traffic loss, it must be blocked before entering the target s tail circuit, for example, inside the target s ISP. The first solution that comes to mind is to automate the approach followed by GRC: one can imagine an ISP service, in which a flooding target sends filtering requests to its ISP, and, in response, the ISP installs wire-speed filters (i.e., filters that do not affect packet-forwarding performance) in its routers to satisfy these requests; each filtering request specifies traffic from one undesired-traffic source to the target AITF preserves a significant fraction of a receiver s bandwidth in the face of bandwidth flooding, and does so at a per-client cost that is already affordable for today s ISPs; this per-client cost is not expected to increase, as long as botnetsize growth does not outpace Moore s law. And also show that even the first two networks that deploy AITF can maintain their connectivity to each other in the face of bandwidth flooding. We can say that the network-layer of the Internet can provide an effective, scalable, and incrementally deployable solution against bandwidth-flooding attacks. Figure1. Typical locations for an intrusion detection system ISSN: Page 3031

2 IDS should be placed in Network Topology: Depending upon our network topology, we may want to position intrusion detection systems at one or more places. It also depends upon what type of intrusion activities we want to detect: internal, external or both. For example, if we want to detect only external intrusion activities, and we have only one router connecting to the Internet, the best place for an intrusion detection system may be just inside the router or a firewall. If we have multiple paths to the Internet, we may want to place one IDS box at every entry point. However if we want to detect internal threats as well, we may want to place a box in every network segment. In many cases we don t need to have intrusion detection activity in all network segments and we may want to limit it only to sensitive network areas. Figure 1 shows typical location where we can place an intrusion detection system. II. LITARATURE SURVEY Distributed denial-of-service attacks (DDoS) creates an immense threat to the Internet, and consequently many defense mechanisms have been proposed to combat them. Attackers constantly modify their tools to bypass these security systems, and researchers in turn modify their approaches to handle new attacks. The DDoS field is evolving quickly, and it is becoming increasingly hard to grasp a global view of the problem. We recently witnessed some attacks In December 2003, an attack kept SCO's web site practically unreachable for more than a day [13]; in June 2004, another attack _flooded Akamai's name servers, disrupting access to its clients for 2 hours, including the Google and Yahoo search engines [14]; a month later, an attack _flooded Double Click's name servers, disabling ad distribution to its 900 clients for 3 hours [8]. Considering that network downtime costs hundreds of thousands of dollars per hour [17], such incidents can translate into millions of dollars of lost revenue for the victim. Yet, the DDoS problem remains unsolved. Flooding attacks, where an attacker attempts to exhaust the downstream bandwidth of a server, are particularly difficult to defend against. Unlike other forms of DDoS such as SYN-flooding, computation attacks or request floods, the downstream bandwidth is not under a web-server s control. And therefore, while there exist server side protection mechanisms to protect server resources, such as syn-cookies [18] and secure admission control schemes, few practical solutions to defend against flooding exist today. Part of the problem is the difficulty in pushing filtering requests into the network where there is sufficient bandwidth to handle the flood. An in-network element cannot distinguish a single packet as being part of a legitimate flow without doing flow tracking, a tricky proposition [1] That traditionally requires per-flow state which may be untenable for a high-bandwidth link. Other solutions are easily fooled by source spoofing [1] or require massive architectural changes. A. Filters In Existing System To prevent undesired traffic from causing legitimate-traffic loss, it must be blocked before entering the target s tail circuit, for example, inside the target s ISP. The first solution that comes to mind is to automate the approach followed by GRC: one can imagine an ISP service, in which a flooding target sends filtering requests to its ISP, and, in response, the ISP installs wire-speed filters (i.e., filters that do not affect packetforwarding performance) in its routers to satisfy these requests; each filtering request specifies traffic from one undesiredtraffic source to the target. The problem with this approach is that it requires more resources than ISPs can afford: Wirespeed filters in routers are a scarce resource, and this is not expected to change in the near future. Modern hardware routers forward packets at high rates that allow only few lookups per forwarded packet; to reduce the number of per-packet lookups, router manufacturers store filters as well as any state that must be looked up per packet, e.g., the router s forwarding table in TCAM (ternary content addressable memory), which allows for parallel accesses. However, because of its special features, TCAM is more expensive and consumes more space and power than conventional memory; as a result, a router line card or supervisor-engine card typically supports a single TCAM chip with tens of thousands of entries. To block the flood, GRC analysed the undesired traffic, determined its sources, and asked from their Internet service provider (ISP) to manually install filters that blocked traffic from these sources. Wire-speed filters in routers are a scarce resource, and this is not expected to change in the near future. Modern hardware routers forward packets at high rates that allow only few lookups per forwarded packet; to reduce the number of perpacket lookups, router manufacturers store filters as well as any state that must be looked up per packet. In the figure2 attacker sends large number of packets to the target through the routers and there is no chance to the other node to send packets or receive the packets from that same node so that path is congested due to the over flow of sending packets from the attacker. Then we overcome this problem by using the filters for stopping the attacks for some amount of time. Even though packets is continuously sending by the attacker then AITF protocol Block that node. Congested Figure2. Blocking path through continuous data ISSN: Page 3032

3 B. Ternary Content Addressable Memory. TCAM = Ternary Content Addressable Memory. Special type of computer memory used in certain very high speed searching applications. Where Content Addressable Memory describes a chip design that allows for a search of entire memory in a single operation. TCAM can perform a wide search in memory in a very short fixed period of time typically less than 20ns. TCAM memory is expensive to build there manufactures use a little as possible. TCAM chips use a lot of power and high heat dissipation. III. PROPOSED METHODOLOGY In this paper, we present Enhanced Active Internet Traffic Filtering (AITF),[2] a network-layer filtering mechanism that enables a receiver to explicitly deny tailcircuit access to misbehaving sources, while addressing these challenges. We show that AITF enables a receiver to preserve on average more than 80% of its tail circuit in the face of a SYN-flooding attack that exceeds the target s tail-circuit capacity by a factor of 10. A. Goals and Objectives of the proposed system In this paper propose and develop an Active Internet Traffic Filtering. Proposed model should be a network- layer filtering mechanism that would preserve a significant fraction of a receiver s tail circuit in the face of bandwidth flooding, while requiring a reasonable amount of resources from participating ISPs. We should observe the following Considerations on proposed model. The proposed should allow a receiver to preserve on average 80% of its tail circuit in the face of a SYNflooding attack that would have ten times the rate of its capacity. Should reduce the CPU Cost. Logics (AITF) should be modifiable at any instance of time Should be able to detect the attacks that cause server to crash Should be able to detect the flooding and bandwidth. B. Active Internet Traffic Filtering (AITF) A networklayer filtering Mechanism. Figure 3. Source S sends undesired traffic to receiver R Source S sends undesired traffic to receiver R through routers S gw ( in S s domain ) and R gw (in R s domain) SNET and RNET have deployed AITF ( and the underlying pathidentification mechanism). R identifies {S S gw R gw R} as an undesired flow. As shown in Figure 3 Here we divided entire working functionality into following modules. C. Path Identification: The domain-level path of a received packet as the sequence of border routers that forwarded the packet; a border router is a router that interconnects different administrative domains. I assume that there exists a (not necessarily globally deployed) path-identification mechanism that enables participating domains to associate the packets they forward with some form of identity, such that the receiver of a packet can combine these identities and reconstruct part of the packet s domain-level path. E.g., in an early deployment scenario, where only and have deployed path identification, the receiver can identify as part of the domain-level path, to provide path identification via record route, i.e., by enabling routers to mark forwarded packets, such that a packet s path is specified inside its headers: NIRA, WRAP, and the Points of Control approach [8] all provide sufficient path identification for AITF. Whatever the underlying record-route mechanism, i do not assume that it is globally deployed; the only domains that have to deploy it are the ones that also deploy AITF. D. Undesired-Traffic Identification: We define a packet flow as a sequence of packets with a common source IP address, domain- level path specification, and destination IP address; use notation {source domain_level_path destination} to specify a flow. For instance, in Fig. 1, traffic with source IP address, domain-level path specification, and destination IP address constitutes a flow, denoted by. We assume that a receiver can run an undesired-flow identification system, which takes as input incoming traffic and outputs specifications of undesired flows; a flow is classified as undesired once the receiver decides it does not want to receive it for a certain amount of time. From this assumption on the fact that existing technology already identifies undesired flows in terms of their source and destination prefixes (and potentially other header fields in use today); once the domain-level path is specified inside a packet s headers, it should be possible to extend this technology to take it into account. E. Path-Based Wire-Speed Filtering: We assume that a router that runs the AITF protocol (which, as i will see, is necessarily a border router) can install a wire-speed filter that blocks all traffic matching a certain flow specification. we base this assumption on the fact that modern routers already use wire speed filters to block packets based on their IP and transport layer headers; once the domain-level path is specified inside a packet s headers, it ISSN: Page 3033

4 should be possible to use the same technology to filter the packet based on its domain-level path. F. Provider-Client Message Authentication A provider can verify the authenticity of messages sent from its own clients, and a client can verify the authenticity of messages sent from its own provider. This can be achieved with message authentication codes or three-way handshakes. G. Non-Compromised Path: Here for a source-receiver pair to be able to communicate, the network elements (typically routers) that are on the path between them must not be compromised. Our rationale is that, once a router gets compromised, all the communications served by it are at its mercy: the router can drop their traffic or hijack their TCP connections. Of course, if a source-receiver pair can communicate over multiple paths, and at least one of them is not compromised, they should be able to maintain their communication akin to how multipath communication between access points and clients increases attack resilience in the Stateless Multipath Overlays approach. Combining multi-path with AITF is part of our future work. H. The Basic AITF Protocol H.1 Players AITF involves four players per undesired flow, illustrated in the above figure 3 The receiver R is the target of the undesired flow. The source S is the node generating the undesired flow. The receiver s gateway Rgw is a border router located in R s ISP, on the path from S to R, before R s tail circuit. Note that R gw is not significantly affected by the attack; if it were (i.e., if its own tail circuit were congested), R gw itself would be the receiver, while the role of the receiver s gateway would be played by another router upstream. The source gateway S gw is a border router located in S s ISP, on the path from S to R.. These four players communicate through AITF messages, which include one or more filtering requests. Each filtering request includes the specification of an undesired flow and the amount of time (called the filtering window) for which the Requester does not want to receive F. For simplicity, we make three temporary assumptions they are The source gateway S gw cooperates with the receiver s gateway Rgw to help the Receiver. Filtering requests are not malicious, i.e., they indeed originate from the specified undesired-traffic receiver R and correspond to traffic indeed sent from the specified source. The receiver can trust the path specified inside each received packet, i.e., it knows the true source S and the true source gateway S gw for each undesired flow. Once a receiver R identifies an undesired flow F, it contacts the corresponding source S and asks it to stop sending F for an amount of time W f. R s request is propagated through R gw and S gw, which temporarily block F to immediately protect R until S complies. R Filtering request To block F For W f R gw Installs temporary filters And block F for time T dr << W f Forward request S gw Figure4. Algorithm overview Forward request Installs temporary filters And block F for time T ds << W f More specifically, R sends a filtering request to its gateway R gw to block F for W f. In response, R gw installs a temporary filter that blocks F for time T dr <<W f and forwards the request to the source gateway S gw ; once Sgw satisfies the request, Rgw removes its temporary filter. Similarly, S gw installs a temporary filter that blocks F for time T ds <<W f, logs the request for W f, and forwards the request to S ; once S satisfies the request, S gw removes its temporary filter. If S does not cooperate (i.e., continues to send F), classifies S as non -cooperating and blocks all S -originated traffic. If S pretends to cooperate. R sends a second filtering request against S; upon receiving this second Request, S gw checks its log, detects that has already been told to stop sending F, classifies S as noncooperating, and blocks all S -originated traffic. as shown in figure 4 IV. SIMULATION RESULTS In this section, we use simulation to analyse the effect of undesired traffic on AITF-enabled receivers and illustrate the effectiveness of AITF against bandwidth flooding. We developed site and we followed below steps When users Login into the popular website he can view or download the books stored in that website. Any Number of users can download the books at the same time While any user downloading the books initially the request being serve by all the nodes. At one particular instance attacker attack one node i.e connected in the network and send more number of packets continouly from the same IP address. At that time AITF Filter in that attacked node block that node from the network and provides other path for sending the requests. S ISSN: Page 3034

5 Even though the node is blocked user impact wont be there. As there should be no user impact the other nodes serving the requests. 5sec 10sec 15sec 20sec 25sec 30sec 35sec 40sec 45sec Figure 5 Graph shows Flow of traffic at all nodes and attack at one node. In the Figure 5 we are showing ten nodes that are connected in the network. In the above graph all requests are serving through all the nodes while at IN3 node at the time of 22 sec the attacker send more packets from that particular node then AITF. Immediately block that node even though the node is blocked requests are serving through the other nodes. Here user impact won t be there though the floe is continuous then AITF blocks that particular node sec 6sec 10sec 14sec Figure 6: Graph shows the Flow of traffic at single node. IN1 IN2 IN3 IN4 IN5 IN6 IN7 IN8 IN9 IN10 Good Traffic Bad Traffic See figure 6 represents only single node At 2sec time good traffic is going on smoothly at 7 sec attacker spoof this node and send more traffic from same IP address then bad traffic is more then the good traffic. Then ISP of that particular node installs filters to stop the flow even though the floe is continuous then AITF blocks that particular node. V. CONCLUSION AND FUTURE ENHANCEMENTS Enhanced Active Internet Traffic Filtering (AITF), a mechanism for filtering highly distributed denial-of-service attacks. We showed that AITF can block a million undesired flows, while requiring only tens of thousands of wire-speed filters from each participating router -- an amount easily accommodated by today's routers. It also prevents abuse by malicious nodes seeking to disrupt other nodes' communications. More specifically, we showed the following: 1. AITF offers filtering response time equal to the one-way delay the victim to the victim's gateway. I.e., a victim can have an undesired flow blocked within milliseconds. 2. AITF offers filtering gain on the order of hundreds of blocked flows per used filter. I.e., a router can block two orders of magnitude more flows than it has wire-speed filters. For example, suppose ebay is receiving a million undesired flows; with 10,000 filters, ebay's gateway can have all flows blocked within 100 seconds. In the worst-case scenario, ebay's gateway blocks all traffic from each domain that hosts attack sources and refuses to filter their traffic, which (in today's Internet) requires a few tens of thousands of filters. 3. A set of malicious nodes can practically not abuse AITF to disrupt communication from node A to node B, as long as they are not located on the path from A to B. This holds even during initial deployment, where most Internet domains are AITF-unaware. The idea behind AITF is that the Internet does have enough filtering capacity to block large amounts of undesired flows -- it is just that this capacity is concentrated close to the attack sources. AITF enables service providers to "gain access" to this filtering capacity and couple it with a reasonable amount of their own filtering resources, in order to protect their customers in the face of increasingly distributed denial-of-service attacks. The feasibility of AITF shows that the network-layer of the Internet can provide an effective, scalable, and incrementally deployable solution to bandwidth-flooding attacks. But still some flow based attacks may not be detected effectively by the AITF. So, there should be some enhancements made to AITF so that it can defend all flow based attacks. ACKNOWLEDGMENT We take this opportunity to acknowledge those who have been great support and inspiration through the research work. Our sincere thanks to Mrs.B.RenukaDevi Head of the department of CSE to her diligence and motivation. Special thanks to Vignan s Lara Institute of Science and Technology, for giving us such a nice opportunity to work in the great environment and for providing the necessary facilities during the research and encouragement from time to time. Thanks to our colleagues who have been a source of inspiration and motivation that helped to us. And to all other people who directly or indirectly supported and help us to fulfill our task. Finally, we heartily appreciate our family members for their motivation, love and support in our goal. REFERENCES [1] Flow-Cookies: Using Bandwidth Amplification to Defend Against DDoS Flooding Attacks Martin Casado, Pei Cao Stanford University {casado,cao}@cs.stanford.edu. [2] Active Internet Traffic Filtering: Real-Time Response to Denial-of- Service Attacks,Katerina Argyraki David R. Cheriton, Distributed Systems Group, Stanford University.Fargyraki, cheritong@dsg.stanford.edu ISSN: Page 3035

6 [3] A. Kuzmanovic and E. Knightly, Low-rate targeted TCP denial-ofservice attacks (The shrew vs. the mice and elephants), in Proc. ACM SIGCOMM, Karlsruhe, Germany, Aug [4] A. Stavrou and A. Keromytis, Countering DoS attacks with stateless multipath overlays, in Proc. ACM Conf. Computer and Communications Security (CCS), Alexandria, VA, Nov [5] ] Z. Chen, C. Ji, and P. Barford, Spatial-temporal characteristics of internet malicious sources, in Proc. IEEE INFOCOM Mini- Conference, Phoenix, AZ, Apr [6] B. Agrawal and T. Sherwood, Modeling TCAM power for next generation network devices, in Proc. IEEE Int. Symp. Performance Analysis of Systems and Software (ISPASS), Austin, TX, Mar [7] X. Yang, NIRA: A new internet routing architecture, in Proc. ACM SIGCOMM Workshop on Future Directions in Network Architecture (FDNA), Karlsruhe, Germany, Aug [8] K. Argyraki and D. R. Cheriton, Loose source routing as a mechanism for traffic policies, in Proc. ACM SIGCOMMWorkshop on Future Directions in Network Architecture (FDNA), Portland, OR, Aug [9] A. Greenhalgh, M. Handley, and F. Huici, Using routing and tunneling to combat DDoS attacks, in Proc. USENIX Workshop on Steps Towards Reducing Unwanted Traffic in the Internet (SRUTI), Cambridge, MA, Jul [10] A. Markopoulou, F. Tobagi, and M. Karam, Loss and delay measurements of internet backbones, Elsevier Computer Commun., Special Issue on Measurements and Monitoring of IP Networks, vol. 29, pp , Jun [11] Scalable Network-layer Defense Against Internet Bandwidth-Flooding Attacks by Katerina Argyraki and David R. Cheriton [12] ]D. G. Andersen. Mayday: Distributed Filtering for Internet Services. In USITS, March [13] Attack downs Yahoo, Google. June [14] DDoS Attack Knocks Out DoubleClick Ads. July [15] Ihoneycol: A Collaborative Technique For Mitigation Of Ddos Attack [16] FireCol: A Collaborative Protection Networkfor the Detection of Flooding DDoS Attacks.Jéerôme François, Issam Aib, Member, IEEE, and Raouf Boutaba, Fellow, IEEE. [17] D. A. Patterson. A simple way to estimate the cost of downtime. In USENIX Systems Administration Conference,November [18] D. Bernstein. Syn cookies ISSN: Page 3036