ACHIEVING HIGHER NETWORK SECURITY BY PREVENTING DDOS ATTACK USING HONEYPOT

ACHIEVING HIGHER NETWORK SECURITY BY PREVENTING DDOS ATTACK USING HONEYPOT 1 Sivaprakasam.V, 2 Nirmal sam.s 1 M.Tech, 2 Assistant Professor Department of Computer Science & Engineering, SRM University, Chennai -603 203 Email : 1 sivaprakasam98.6@gmail.com Abstract: Distributed denial of service is major security threat that has been increasing today. If network size increases, the security threats problems becomes more severe. Therefore intrusion prevention/detection becomes mandatory. The system differentiates the traffic coming from the authorized user and an intruder. The introduction of IPS aims at preventing the attack as far away from destination server. Denial of service can be of any form either pings of death, teardrop attack, smurf attack, clone attack. In existing system, these attacks can be overcome by using filter (Firecol) technique. Filtering malicious traffic occur in three ways, they are filtering at source level, service level, destination level. The FireCol system has virtual rings or shields of protection around registered customers. It has set of intrusion prevention system (ISP) to analyze the attacks and has some set of rules. Firecol have metric manager to compute the frequencies and entropies of each rule following that the selection manager measures the deviation of the current traffic profile and send to score manager. A score manager assigns a score to each selected rule based on the frequencies, the entropies, and the scores received. Finally the attacks are classified whether the attack is potential attack or not. Though the existing system avoids the DDoS effectively, the original server is affected because it is supposed to answer the unnecessary queries of malicious user. Thus proposed system introduces honeypot server to prevent the original server from the malicious customer. Therefore, the hybrid technique of using honeypot in collaboration with Firecol is proposed to mitigate the DDoS attack. Key Terms X Distributed Denial of Service Attacks, Honey pot, FireCol, Intrusion Detection System. I. INTRODUCTION In the recent years, Internet has become a very popular method to connect computers all over the world. While the availability of continuous communication has created many new opportunities, it has also brought new possibilities for malicious users. The Importance of network Security is therefore growing; one of the ways of malicious activity detection on a network is by using Intrusion Detection System. Most modern Intrusion Detection System relies on a set of rules that are applied to each input packet in order to define suspicious activities. The simplest rules are described by packet header field content and pattern of data in the packet payload. Detecting such patterns is the core operation of an Intrusion Detection System. There are four different ways to defend against DoS attacks: Attack prevention Attack detection Attack source identification and Attack reaction. Attack prevention aims to new security holes, such as insecure protocols, weak authentication schemes and vulnerable computer systems, which can be used as 54

stepping stones to launch a DoS attack. This approach aims to improve the global security level and is the best solution to DoS attacks in theory. However, the disadvantage is that it needs global cooperation to ensure its effectiveness, which is extremely difficult in reality. Hence, the challenge is how to develop a scalable mechanism with low implementation cost. Attack detection aims to detect DoS attacks in the process of an attack. Attack detection is an important procedure to direct any further action. The challenge is how to detect every attack quickly without misclassifying any legitimate traffic. Attack source identification aims to locate the attack sources regardless of the spoofed source IP addresses. It is a crucial step to minimize the attack damage and provide deterrence to potential attackers. The challenge for attack source identification is how to locate attack sources quickly and accurately without changing current Internet infrastructure. Attack reaction aims to eliminate or curtail the effects of an attack. It is the final step in defending against DoS attacks, and therefore determines the overall performance of the defense mechanism. The challenge for attack reaction is how to filter the attack traffic without disturbing legitimate traffic. This paper is framed as follows: Related works are explored in section II. Proposed works are discussed in section III. Result and Discussion are discussed in section IV and the section V discuss about the conclusion and further research. II. RELATED WORK REVIEW DISTRIBUTED denial-of-service (DDoS) attacks still constitute a major concern [1] even though many works have tried to address this issue in the past (ref. survey in [2]). As they evolved from relatively humble megabit beginnings in 2000, the largest DDoS attacks have now grown a hundredfold to break the 100 Gb/s, for which the majority of ISPs today lack an appropriate infrastructure to mitigate them [1]. Most recent works aim at countering DDoS attacks by fighting the underlying vector, which is usually the use of botnets [3]. A botnet is a large network of compromised machines (bots) controlled by one entity (the master). The master can launch synchronized attacks, such as DDoS, by sending orders to the bots via a Command & Control channel. Unfortunately, detecting a botnet is also hard, and efficient solutions may require to participate actively to the botnet itself [4], which raises important ethical issues, or to first detect botnet-related malicious activities (attacks, infections, etc.), which may delay the mitigation. To avoid these issues, this paper focuses on the detection of DDoS attacks and per se not their underlying vectors. Although non-distributed denial-of-service attacks usually exploit vulnerability by sending few carefully forged packets to disrupt a service, DDoS attacks are mainly used for flooding a particular victim with massive traffic as highlighted in [1]. In fact, the popularity of these attacks is due to their high effectiveness against any kind of service since there is no need to identify and exploit any particular service-specific flaw in the victim. Hence, this paper focuses exclusively on flooding DDoS attacks. An intrusion detection system (IDS) inspects all inbound and outbound network activity and identifies suspicious patterns that may indicate a network or system attack from someone attempting to break into or compromise a system. There are several ways to categorize IDS. A. Misuse detection vs. anomaly detection In misuse detection, the IDS analyze the information it gathers and compares it to large databases of attack signatures. Essentially, the IDS look for a specific attack that has already been documented. Like a virus detection system, misuse detection software is only as good as the database of attack signatures that it uses to compare packets against. In anomaly detection, the system administrator defines the baseline, or normal, state of the network s traffic load, breakdown, protocol, and typical packet size. The anomaly detector monitors network segments to compare their state to the normal baseline and look for anomalies. B. Network-based vs. host-based systems In a network-based system, or NIDS, the individual packets flowing through a network are analyzed. The NIDS can detect malicious packets that are designed to be overlooked by a firewall s simplistic filtering rules. In a host-based system, the IDS examines at the activity on each individual computer or host. C. Passive system vs. reactive system In a passive system, the IDS detect a potential security breach, log the information and signal an alert. In a reactive system, the IDS respond to the suspicious activity by logging off a user or by reprogramming the firewall to block network traffic from the suspected malicious source. Though they both relate to network security, an IDS differs from a firewall in that a firewall looks out for intrusions in order to stop them from happening. The firewall limits the access between networks in order to prevent intrusion and does not signal an attack from inside the network. An IDS evaluates a suspected intrusion once it has taken place and signals an alarm. An IDS also watches for attacks that originate from within a system. 55

III. PROPOSED DESIGN Proposed System design is shown in Figure 3.1 Figure 1. Proposed System Design A. Proposed System Design The FireCol system maintains virtual rings or shields of protection around registered customers. A ring is composed of a set of IPSs that are at the same distance (number of hops) from the customer each FireCol IPS instance analyzes aggregated traffic within a configurable detection window. The metrics manager computes the frequencies and the entropies of each rule A rule describes a specific traffic instance to monitor and is essentially a traffic filter, which can be based on IP addresses or ports. Following each detection window, the selection manager measures the deviation of the current traffic profile from the stored ones, selects out of profile rules, and then forwards them to the score manager. Using a decision table, the score manager assigns a score to each selected rule based on the frequencies, the entropies, and the scores received from upstream IPSs (vertical collaboration/communication). Using a threshold, a quite low score is marked as a low potential attack and is communicated to the downstream IPS that will use to compute its own score. A quite high score on the other hand is marked as high potential attack and triggers ring-level (horizontal) communication in order to confirm or dismiss the attack based on the computation of the actual packet rate crossing the ring surpasses the known, or evaluated, customer capacity. As can be noticed, this detection mechanism inherently generates no false positives since each potential attack is checked. However, since the entire traffic cannot be possibly monitored, we promote the usage of multiple levels and collaborative filtering described previously for an efficient selection of rules, and so traffic, along the process. In brief, to save resources, the collaboration manager is only invoked for the few selected candidate rules based on resource-friendly metrics. Once the FireCol routers found the metrics value exceeds threshold value, the threshold value 1 will set to normal packet and the threshold value 0 is set to the abnormal packet. Then firecol routes the packet to the load balancer. Load balancer decides to send the packet to the server or honey pot server based on the threshold value. Every system in the organization might be a honeypot. For example, if the attacker s compromise packets to the web server of the corporation are detected, the packets go to the honeypot for processing. The reply the attacker gets should be indistinguishable from a real reply of the web server. i) Subscription Protocol: FireCol protects subscribers (i.e., potential victims) based on defined rules. A FireCol rule matches a pattern of IP packets. Generally, this corresponds to an IP subnetwork or a single IP address. However, the rule definition can include any other monitorable information that can be monitored, such as the protocols or the ports used. FireCol is an added value service to which customers subscribe using the protocol. The protocol uses a trusted server of the ISP that issues tokens. When a customer subscribes for the FireCol protection service, the trusted server adds an entry with the subscribing rule along with its subscription period (TTL) and the supported capacity. The server then issues periodically a corresponding token to the customer with a TTL and a unique ID signed using its private key. All communications between subscribers and the server are secured a using private/public key encryption scheme. The ring level of a FireColenabled router (IPS) is regularly updated based on the degree of stability of IP routing. This is done using a two phase process. First, the router sends a message RMsg to the protected customer containing a counter initialized to 0. The counter is incremented each time it passes through a FireCol-enabled router. The customer (or firstlevel FireCol router) then replies to the initiating router with the value of its ring level. This procedure is optimized through aggregation when several routers are requesting a ring-level update. In practice, the ring level value is network-dependent. However, routing stability has been well investigated and enhanced [6], [7]. The study done in [8] shows that most routes are usually stable within the order of several days, while flooding 56

attacks generally operate within the order of minutes in order to have a high impact. For further analysis, the impact of routers not assigned to the right level. It shows that updating the ring topology at regular intervals is sufficient even if some IPSs are not well configured with respect to the ring to which they belong. A more sophisticated mechanism could monitor route changes to force ring updates. In FireCol, a capacity is associated to each rule. Rule capacities can be provided either by customers or the ISP (for overall capacity rules). For sensitive services, customers can specify the capacity. IT services of large companies should be able to provide such information regarding their infrastructure. For smaller customers, statistical or learning algorithms, running at customer premises or first hop IPS, might be leveraged to profile traffic throughput [9]. Similar to [10], the threshold can be tuned to keep a small proportion (i.e., 5%) for analysis. Finally, for very small customers, such as a household, a single rule related to the capacity of the connection can be used. The maximum capacity, or throughput quota, is generally readily available to the ISP based on the customer service level agreement (SLA) [11], [12]. ii)proposed Attack Detection Algorithms: For each selected, the collaboration manager computes the corresponding packet rate using rule frequencies and the overall bandwidth consumed during the last detection window. If the rate is higher than the rule capacity, an alert is raised. Otherwise, the computed rate is sent to the next IPS on the ring (Algorithm 1). When an IPS receives a request to calculate the aggregate packet rate for a given rule, it first checks if it was the initiator. In this case, it deduces that the request has already made the round of the ring, and hence there is no potential attack. Otherwise, it calculates the new rate by adding in its own rate and checking if the maximum capacity is reached, in which case an alert is raised. Otherwise, the investigation is delegated to the next horizontal IPS on the ring. Algorithm 1 shows the details of this procedure. Algorithm1:Check Rule It is initially called with an empty. The first IPS fills it and sets the boolean to true (line 16). is reset after the computation finishes, i.e., when the request has made the round of the ring or when the alert is triggered. With simple adjustments, ring traversal overhead can further be reduced if several suspect rules are investigated in one pass. Rate computation can be performed based on the number of packets per second (pps) or bytes per second (bps). The first method is more suitable for detecting flooding DDoS attacks having a small packet pattern, such as SYN floods. Bytes-based method is better for detecting flooding attacks with large packet payloads. FireCol customers can subscribe to either or both protection types. B. MITIGATION When an attack is detected, FireCol rings form protection shields around the victim. In order to block the attack as close as possible to its source(s), the IPS that detects the attack informs its upper-ring IPSs (upstream IPSs), which in turn apply the vertical communication process and enforce the protection at their ring level (Algorithm 2). To extend the mitigation, the IPS that detects the attack informs also its peer IPSs on the same ring to block traffic related to the corresponding rule. This is done by forwarding the information in the same manner as done by the collaboration manager (Algorithm 1). Only traffic from suspected sources (i.e., triggered some rule) is blocked. This is performed by the block_ips function in Algorithm 2, line 5. Algorithm2: Mitigation This process entails the potential blocking of benign addresses. However, this is a temporary cost that is difficult to avoid if a flooding attack is to be stopped. Potential alternatives are described in the next section. It may be impossible to determine all attack sources during a single detection window due to inherent network delays and/or resource limitations. The attacker can also invoke an attack scenario from different machines at different 57

times to reduce the risk of detection. For this, after the detection and mitigation of an attack against some host, FireCol continues the detection process looking for some additional attack sources. Furthermore, in order to limit the effect of potentially additional attack sources, after the blocking period elapses, the IPS may activate a cautious mode phase wherein a rate limitation of packets corresponding to the triggered rule is applied. The actual duration of the blocking and caution period depends on the aggressiveness of the attack, i.e., on the difference between the observed packet rate and the host paci, capacity capi. C. HONEYPOT Honeypots are designed to mimic systems that an intruder would like to break into but limit the intruder from having access to an entire network. If a honeypot is successful, the intruder will have no idea that s/he is being tricked and monitored. Most honeypots are installed inside firewalls so that they can better be controlled, though it is possible to install them outside of firewalls. A firewall in a honeypot works in the opposite way that a normal firewall works: instead of restricting what comes into a system from the Internet, the honeypot firewall allows all traffic to come in from the Internet and restricts what the system sends back out. By luring a hacker into a system, a honeypot serves several purposes: The administrator can watch the hacker exploit the vulnerabilities of the system, thereby learning where the system has weaknesses that need to be redesigned. The hacker can be caught and stopped while trying to obtain root access to the system. By studying the activities of hackers, designers can better create more secure systems that are potentially invulnerable to future hackers. IV. RESULT AND DISCUSSION We have evaluated proposed technique by testing its performance on a set of simulated distributed denial of service attacks, and comparing its performance to a existing techniques, the performance of these two approaches in terms of the average packet delivery ratio on a set of simulated DDoS attacks is shown in figure 4.1. V. CONCLUSION AND FUTURE WORK In this paper, proposed a collaborative system to eliminate the DDoS attack. Also showed how such a system can be used in a defense in depth real-world network environment. The system is identified with different problems with current realization and provided first solutions to cope with the scalability of the honeypot. Although our honeypot is still in its infancy, we achieved first promising results with the presented initial setup. Future work will consist of the development of a honeynet scalable to a middle sized organisation and the investigation of other solution to the re-direction of packets. VI. REFERENCES [1] H. Liu, A new form of DOS attack in a cloud and its avoidance mechanism, in Proc. ACM Workshop Cloud Comput. Security, 2010, pp. 65 76. [2] D. Das, U. Sharma, and D. K. Bhattacharyya, Detection of HTTP flooding attacks in multiple scenarios, in Proc. ACM Int. Conf. Commun., Comput. Security, 2011, pp. 517 522. [3] A. El-Atawy, E. Al-Shaer, T. Tran, and R. Boutaba, Adaptive early packet filtering for defending firewalls against DoS attacks, in Proc. IEEE INFOCOM, Apr. 2009, pp. 2437 2445. [4] I. B.Mopari, S. G. Pukale, and M. L. Dhore, Detection of DDoS attack and defense against IP spoofing, in Proc. ACM ICAC3, 2009, pp. 489 493. [5] S. H. Khor and A. Nakao, Overfort: Combating DDoS with peer-to-peer DDoS puzzle, in Proc. IEEE IPDPS, Apr. 2008, pp. 1 8. [6] Hwang, K. and Gangadharan, K., Dynamic Network Security with Distributed Intrusion Detection, Proc. of the IEEE Int l Symp. on Network Computing and Applications, Cambridge, MA. Oct. 18, 2001. [7] Hwang, K., Dave, P., and Tanachaiwiwat, S, NetShield: Protocol Anomaly Detection with Datamining against DDoS Attacks, Sixth Int l Symp. on Recent Advances in Intrusion Detection (RAID-2003), Pittsburgh, PA. Sept. 8-10, 2003 (submitted under review) Figure 2 Comparision of Average Packet Delivery Ratio [8] Ioannidis, J. and Bellovin, S. Pushback: Router-Based Defense Against DDoS Attacks, 58

Proc. of Network and Distributed System Security Symposium, San Diego, CA., Feb. 6-8, 2002 [9] Kruegl, C., Valeuer, F., Vigna, G. and Kemmer, R., Stateful intrusion detection for high-speed Networks, Proc. of IEEE Symp. on Security and Privacy, Berkeley, CA., May 12, 2002, pp.162-172. [10] Lee W., Stolfo S. J. and Mok K., A Data Mining Framework for Adaptive Intrusion Detection, in Artificial Intelligence Review, Kluwer Academic Publishers, 1999. [11] Lemonnier, E. Protocol Anomay Detection in Network-based IDSs, June 2001 http://erwan.lemonnier.free.fr/exjobb/report/proto col_anomaly_detection.pdf [12] Mikovic, J. and Reiher, P. A Taxonomy of DDoS Attacks and DDoS Defense Mechanisms Technical Report No. # 020018, Computer Science Dept., Univ. of California, Los Angeles, 2002. [13] Moore, D. Voelker, G. and Savage, S. Inferring Internet Denial of Service Activity, Proc. Of the 2001 USENIX Security Symposium, Washington D.C., August 2001 [14] Noel, S., Wijesekera, D. and Youman, C. Modern Intrusion Detection, Datamining, and Degree of Attack Guilt in Application of Datamining in Computer Security, Kluwer Publishers. 2002 59