AU2021102049A4 - Method and system for defense against Distributed Denial-of-Service attack - Google Patents

Abstract

The present disclosure relates to a method for defense mechanisms against DDoS attack based on entropy in software defined network cloud. The present disclosure also relates to a defensive mechanism for DDoS attacks that is based on variations in entropy between DDoS attack and a normal traffic with a low computational overhead and a mitigation technique to reduce the severity of the attack. On comparing with the existing DDoS mechanisms, there are three advantages of the proposed method and those advantages are, detection rate is high, false positive rate is low, and the mitigation ability. Simulations are carried out in mininet emulator with POX controller and open flow switches at different attack strength. 22 CN C ( C Cr ii I, q L L

Description

CN C ( C Cr

ii I, q

L L

Method and system for defense against Distributed Denial-of-Service attack

FIELD OF THE INVENTION

The present disclosure relates to a method for defense mechanisms against DDoS attack based on entropy in software defined network cloud.

BACKGROUND OF THE INVENTION

The Cloud technology is a dynamic platform and it provides a collection of configurable and sharable resources to the consumers and suppliers. As per the requirement of the user, resources can be scaled up and scale down, and accordingly, the users have to pay for the used resources. In 2011, National Institute of Standards and Technology (NIST) has provided a formal definition which includes deployments of cloud model (Public, Private, Hybrid and community), services of clouds (IaaS, Paas and SaaS) and its essential characteristics(On demand self-services, Broad Network Access, resources Pooling, Rapid Elasticity and Measured Services). Due to its essential characteristics, the consumers and providers of cloud computing are increasing like anything. However, there ISA significant increment also in the number of issues over cloud such as breach of data, the vulnerability in a shared technology, outdated versions and patching, abuse and nefarious use of cloud and distributed Denial of service (DDoS) attack. From the statistics of, we can see that DDoS is making itself more energetic day by day with the help of advanced tools and technology in cloud computing. Over the years DDoS has increased its volume to stop the legal services. DDoS which works at network layer and the conventional network architecture is itself a problem to invite many of the threats including DDoS.

SDN beautifully manages the three planes. The lower plane which is also known as data or infrastructure plane used to carry the switches, virtual switches, routers and access points and maintains information in related tables such as routing table, miss table and forwarding table. The data plane interacts with the control plane, where it may have one or multiple controllers. The main work of the controller is to manage the network. The control plane interacts with the application plane, which contains security related mechanisms to make the system secure and provide authenticated access to the users. It simplifies complexity exists in a traditional network. It attempts to segregate network activities in the following way: Prioritization, filtering and forwarding: Forwarding responsibilities, implemented in hardware tables, remain on the device.

Besides, features such as traffic prioritization and filtering based on ACLs are enforced locally on the required devices in the same way. Control: Complicated control software is evacuated from their devices and inserted into a centralized controller. It has a complete view and control of the network along with the ability to make routing decisions and optimal forwarding. It shows a shift to a programming standard for a control plane. On the controller, the underlying forwarding hardware on the networking device is available to be programmed by external software. The control plane is not any more closed, embedded, tightly coupled with the hardware, or optimized for specific embedded environments. Applications: Above the controller is where the network applications run, implementing higher-level functions and, additionally, participating in decisions about how best to manage and control packet forwarding and distribution within the network.

There are some factors related to balancing the load and enforcement of security when the virtual migration takes place. Such as a shared link on many different virtual networks and one of them can be compromised due to the DDoS attack which in turn affect the services. In such kind of cases, the other non-compromised networks should be migrated to different servers till the problem is solved. In SDN the logically centralized controller knows the entire system. This worldwide information on the system is valuable in the construction of proper defense approaches for network system that further aides to detect and mitigate the attacks. SDN has great ability of the technical programming over conventional network systems, which empowers the administrators of network in using different existing defense frameworks relying upon the kind of DDoS attacks. In a SDN domain, we can utilize various kinds of programming tools and intelligent algorithms to analyze traffic of a network. Consequently, SDN can detect the attack and mitigation the system more successfully by implementing programming based traffic examination.

In SDN, there is an essential and basic component as an OpenFlow switch. According to the OpenFlow determination, an OpenFlow empowered switch keeps up a flow table to perform forwarding of packets. In the switches, a flow table consists of number of flow entries, which contains match fields, priorities, counters, Action, Timeout, Cookies, and flag to be applied on the coordinating flows. After receiving a packet, matching begins from the absolute first flow table and proceeds to next flow tables in the succession. On matching of an entry with the match field, the packet is handled as per the action specified in the flow entry. However, if there is no match, the action is executed as per the action stored in the table-miss flow entry. In which it includes the probable set of actions, forward the packet, keep on searching, decline the entry, and many more. In the important components of a flow entry, each flow entry contains fields. Match Field: To compare it against approaching packets. Priority: It characterizes priority of a flow entry. We can utilize it with the match fields to distinguish novel flow entry in a specific flow table. Counter: It is refreshed and incremented on a match. Action: It includes a lot of moves to be made when a match field occurs as true. Timeout: It talks about a session maintained by a flow entry in the flow table. Cookies: The controller selects hazy information. It may be utilized to separate out flow entries influenced by statistics, alterations and deletion demands of a flow. During the processing of the packets, we cannot use it. Flags: To modify and keep track of the modified flow entries.

In DoS attack, a single machine or connection generates large amount of traffic to make the victim machine unavailable to process other legitimate requests. DoS attack can be categorized in three modes, first one focuses on consumption of limited resources of the victim machine which could be the network connectivity, bandwidth, processing power or memory. Second, changing or destructing the configuration information of the machine and lastly physically altering or destructing the network components.

In DDoS attack, network is saturated to an extent that no other request can be entertained by the victim. The attacker uses the hierarchical architecture to perform the attack. First, the attacker creates some zombie machines also known as bots. These machines are created by installing some malicious code on the victim machines. In this hierarchical structure there exists a Bot master or the main attacker which issues the command to handlers who further sends it to the zombie machines to perform the attack. All the zombie machines after receiving the command generates huge amount of traffic on the victim machine or network to overwhelm it so that it cannot process any other legitimate requests. The intensity of the attacks mainly depends on the number of zombie machines used. In one of the existing solution, the attention was paid on the approach to the detection of the DDoS attack. 25 window size is used for the simulation with a POX controller, where a faster mode was tried to detect an attack. It works well in the suggested scenario, but it may not be suitable for the larger volume of the attack. Also, they a timestamp was used for recording the number of packets in the attack period, but further, it was not recommended it. In one of the existing solution a model of selective cloud egress filter (SCEF) was proposed for detection of DDoS attack. Once the attack is detected, the proposed model relays information regarding participation VM in attack to the virtual machine monitors for taking the right action. The benefit is the scope of the system extends to a diverse variety of network attacks. In one of the existing solution an idea was presented to defend from the DDoS attack by using the probability distribution and somehow succeeded to gain optimized Flow Table space but did not reduce the false positive rate as per the requirement.

In one of the existing solution an automatic framework ArOMA was proposed that utilizes the important features of SDN such as programmability and centralized manageability to mitigate DDoS. The thought process is to efficiently incorporate different mitigation frameworks that are dispersed among its clients. In one of the existing solution the attack was identified by using the SDN controller and to ensure its architecture. The fundamental destinations of this methodology are to use the controller's expansive of system features to distinguish the attack and to make the detection framework compelling and lightweight as far as resources uses. In one of the existing solution a system was proposed to trigger the detection method for DDoS attack with the aim to diminish the reaction time to detect the attack framework. In the event that the reaction time is longer, it enforces the SDN controller to process countless attacking packets. It might even crash or degrade the controller. In one of the existing solution the effect of SDN on detection of attack in the cloud computing was researched. The SDN was considered as a help with regards to attack if the barrier framework is sufficiently structured. Researchers constructed an attack defense architecture called "DaMask". An adaptable control structure which is used to perform for faster response of attack was discussed.

However, DDoS which works at network layer and the conventional network architecture is itself a problem to invite many of the threats including DDoS. The existing mechanism does not focus on the many of the features of attacks and works for majorly for passive defensive mechanisms, that is also a problem and therefore they are not sufficient to trackback the attack. In spite of, so many developments in tools and technology, it is still hard to detect the DDoS attack. Therefore, in order to avoid aforementioned drawbacks there is a need of a method for defense mechanisms against DDoS attack based on entropy in software defined network cloud.

SUMMARY OF THE INVENTION

The present disclosure relates to a method for defense mechanisms against DDoS attack based on entropy in software defined network cloud. A defensive mechanism is proposed for DDoS attack that is based on variations in entropy between DDoS attack and a normal traffic with a low computational overhead and also a mitigation technique to reduce the severity of the attack. The three advantages of the present disclosed method are detection rate is high, false positive rate is low, and the mitigation ability. Simulations are carried out in mininet emulator with POX controller and open flow switches at different attack strength.

The present disclosure seeks to provide a method for defense mechanisms against DDoS attack based on entropy in software defined network cloud. The method comprises: receiving incoming flow rate of packets and verifying whether said flow rate of packets exceeds beyond a specified threshold or not in order to identify an unusual traffic; collecting all statistics of switch's flow by a controller plane upon receiving said unusual traffic; parsing incoming packets by offering many primitives using a POX controller; extracting packets information and thereby creating match for flow rules; sending messages to program a switch using said controller; identifying a distributed denial-of-service (DDoS)attack by comparing current entropy with specified entropy threshold using statistics; incrementing a counter upon obtaining an attack period or going into a non-attack period and asking said controller to modify packet to forward it to a next address through said switches; and diminishing effect of said DDoS attack by said plane and mitigating DDoS attack upon identifying of an attack in a software defined network cloud (SDN-Cloud).

An objective of the present disclosure is to provide a method for defense mechanisms against DDoS attack based on entropy in software defined network cloud.

Another object of the present disclosure is to achieve high detection rate and low false positive rate.

Another object of the present disclosure is to develop a mitigation technique to reduce the severity of the attack.

Another object of the present disclosure is to carry out simulations in mininet emulator with POX controller and open flow switches at different attack strength.

Yet, another object of the present disclosure is to use the attributes of flow table along with the entropy variations in SDN to recognize and alleviate DDoS attack.

To further clarify advantages and features of the present disclosure, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings.

BREIF DESCRIPTION OF FIGURES

These and other features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

Figure 1 illustrates a flow chart of a method for defense mechanisms against DDoS attack based on entropy in software defined network cloud in accordance with an embodiment of the present disclosure;

Figure 2 illustrates the DDoS size development trend from 2003 to 2019 in accordance with an embodiment of the present disclosure;

Figure 3 illustrates the architecture of software defined networks in accordance with an embodiment of the present disclosure;

Figure 4 illustrates the flow table component in accordance with an embodiment of the present disclosure;

Figure 5 illustrates the DDOS attack Scenario in accordance with an embodiment of the present disclosure;

Figure 6 illustrates the Categories of DDoS Attack in accordance with an embodiment of the present disclosure;

Figure 7 illustrates the table for analysis of the existing mechanisms in accordance with an embodiment of the present disclosure;

Figure 8 illustrates Architecture of proposed approach in accordance with an embodiment of the present disclosure;

Figure 9 illustrates DDoS detection algorithm in accordance with an embodiment of the present disclosure;

Figure 10 illustrates DDoS mitigation algorithm in accordance with an embodiment of the present disclosure;

Figure 11 illustrates the defense mode in accordance with an embodiment of the present disclosure;

Figure 12 illustrates the SDN topology in accordance with an embodiment of the present disclosure;

Figure 13 illustrates a table for simulation parameter in accordance with an embodiment of the present disclosure;

Figure 14 illustrates the entropy variations under attack in accordance with an embodiment of the present disclosure;

Figure 15 illustrates the Throughput Observation in accordance with an embodiment of the present disclosure;

Figure 16 illustrates the Entropies distribution of individual flow in accordance with an embodiment of the present disclosure;

Figure 17 illustrates the table of simulation parameter in accordance with an embodiment of the present disclosure;

Figure 18 illustrates the Flow Statistics observation in accordance with an embodiment of the present disclosure;

Figure 19 illustrates a table of the design parameter () in accordance with an embodiment of the present disclosure;

Figure 20 illustrates ROC curve in accordance with an embodiment of the present disclosure;

Figure 21 illustrates Holding time of Network during attack period in accordance with an embodiment of the present disclosure;

Figure 22 illustrates the Holding time of SDN by changing the attack rate in accordance with an embodiment of the present disclosure;

Figure 23 illustrates DDoS Mitigation Algorithm in accordance with an embodiment of the present disclosure;

Figure 24 illustrates a table for Comparisons of the proposed approach with other existing approaches to defend DDoS Attack in SDN-Cloud in accordance with an embodiment of the present disclosure;

Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have been necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present disclosure. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.

DETAILED DESCRIPTION

For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.

It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the invention and are not intended to be restrictive thereof.

Reference throughout this specification to "an aspect", "another aspect" or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by "comprises...a" does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.

Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings.

Figure 1 illustrates a flow chart of a method for defense mechanisms against DDoS attack based on entropy in software defined network cloud in accordance with an embodiment of the present disclosure. At step 102 the method 100 includes, receiving incoming flow rate of packets and verifying whether said flow rate of packets exceeds beyond a specified threshold or not in order to identify an unusual traffic. After receiving the incoming flow rate of packets, it is checked whether it exceeds beyond the specified threshold t, or not, as this is the first check to identify the unusual traffic.

At step 104 the method 100 includes, collecting all statistics of switch's flow by a controller plane upon receiving said unusual traffic. On receiving the unusual traffic, the controller plane then collects all the statistics of switch's flow.

At step 106 the method 100 includes, parsing incoming packets by offering many primitives using a POX controller. A POX controller is used. It offers many primitives to parse the incoming packets.

At step 108 the method 100 includes, extracting packets information and thereby creating match for flow rules. The packets information can be extracted through a packet in command and then by thefrompacket function, the match for the flow rules can be created.

At step 110 the method 100 includes, sending messages to program a switch using said controller. The controller sends packetout, flowmod and other OpenFlow messages to program the switch. Controller's job is quite important as it is a middle layer and has to interact with the switch and application both at the same time.

At step 112 the method 100 includes, identifying a distributed denial-of-service (DDoS) attack by comparing current entropy with specified entropy threshold using statistics. Controller helps to compute the probability and entropy by using the specified Shannon equation in the application plane. These statistics helps to identify the attack by comparing the current entropy with the specified entropy threshold.

At step 114 the method 100 includes, incrementing a counter upon obtaining an attack period or going into a non-attack period and asking said controller to modify packet to forward it to a next address through said switches. Based on the current entropy value, if it does not exceed the second thresholds, and then it is assumed and declared as an attack period and increment a counter. Otherwise, it goes into the non-attack period and asks to controller to modify the packet and forward it to the next address through the switches.

At step 116 the method 100 includes, diminishing effect of said DDoS attack by said plane and mitigating DDoS attack upon identifying of an attack in a software defined network cloud (SDN-Cloud). Once the attack is identified, it is the responsibility of the application plane to diminish the effect of the DDoS attack. Therefore, it is equally important to mitigate the DDoS attack. In the mitigation part, the malicious flow whose hit count value is more than the third threshold, are dropped out from the link by using the rules and blocked that id, also the subsequent request from that id will be blocked.

Figure 2 illustrates the DDoS size development trend from 2003 to 2019 in accordance with an embodiment of the present disclosure. The figure depicts that over the years DDoS has increased its volume to stop the legal services. DDoS which works at network layer and the conventional network architecture is itself a problem to invite many of the threats including DDoS. Therefore, we already have the new technology Software Defined Network (SDN) with many advantages like centralized monitoring, data plane, control plane and application planes are separated. This technology works better with the cloud as we know SDN-Cloud.

Figure 3 illustrates the architecture of software defined networks in accordance with an embodiment of the present disclosure. SDN beautifully manages the three planes. The lower plane which is also known as data or infrastructure plane used to carry the switches, virtual switches, routers and access points and maintains information in related tables such as routing table, miss table and forwarding table. The data plane interacts with the control plane, where it may have one or multiple controllers. The main work of the controller is to manage the network. The control plane interacts with the application plane, which contains security related mechanisms to make the system secure and provide authenticated access to the users. It simplifies complexity exists in a traditional network. It attempts to segregate network activities in three ways. Prioritization, filtering and forwarding: Forwarding responsibilities, implemented in hardware tables, remain on the device. Besides, features such as traffic prioritization and filtering based on ACLs are enforced locally on the required devices in the same way. Control: Complicated control software is evacuated from their devices and inserted into a centralized controller. It has a complete view and control of the network along with the ability to make routing decisions and optimal forwarding. It shows a shift to a programming standard for a control plane. On the controller, the underlying forwarding hardware on the networking device is available to be programmed by external software. The control plane is not any more closed, embedded, tightly coupled with the hardware, or optimized for specific embedded environments. Applications: Above the controller is where the network applications run, implementing higher level functions and, additionally, participating in decisions about how best to manage and control packet forwarding and distribution within the network.

Figure 4 illustrates the flow table component in accordance with an embodiment of the present disclosure. In SDN, there is an essential and basic component as an OpenFlow switch. According to the OpenFlow determination, an OpenFlow empowered switch keeps up a flow table to perform forwarding of packets. In the switches, a flow table consists of number of flow entries, which contains match fields, priorities, counters, Action, Timeout, Cookies, and flag to be applied on the coordinating flows. After receiving a packet, matching begins from the absolute first flow table and proceeds to next flow tables in the succession. On matching of an entry with the match field, the packet is handled as per the action specified in the flow entry. However, if there is no match, the action is executed as per the action stored in the table-miss flow entry. In which it includes the probable set of actions, forward the packet, keep on searching, decline the entry, and many more. Each flow entry contains fields. Match Field: To compare it against approaching packets. Priority: It characterizes priority of a flow entry. We can utilize it with the match fields to distinguish novel flow entry in a specific flow table. Counter: It is refreshed and incremented on a match. Action: It includes a lot of moves to be made when a match field occurs as true. Timeout: It talks about a session maintained by a flow entry in the flow table. Cookies: The controller selects hazy information. It may be utilized to separate out flow entries influenced by statistics, alterations and deletion demands of a flow. During the processing of the packets, we cannot use it. Flags: To modify and keep track of the modified flow entries.

Figure 5 illustrates the DDOS attack Scenario in accordance with an embodiment of the present disclosure. In DDoS attack, network is saturated to an extent that no other request can be entertained by the victim. The attacker uses the hierarchical architecture to perform the attack. First, the attacker creates some zombie machines also known as bots. These machines are created by installing some malicious code on the victim machines. In this hierarchical structure there exists a Bot master or the main attacker which issues the command to handlers who further sends it to the zombie machines to perform the attack. All the zombie machines after receiving the command generates huge amount of traffic on the victim machine or network to overwhelm it so that it cannot process any other legitimate requests. The intensity of the attacks mainly depends on the number of zombie machines used.

Figure 6 illustrates the Categories of DDoS Attack in accordance with an embodiment of the present disclosure. The DDoS attacks are categorized into two types: Depletion of bandwidth attack and Depletion of resources attack. Depletion of bandwidth attack targets the victim's machine by flooding the network with unusual traffic and deny the authorized request. Again it is of two types: Flood attacks: In this attack, victim's machine is flooded with unusual traffic generated by zombies. These huge volumes of packets are used to degrade the victim machine by saturating the bandwidth of network. Amplification attack: This type of attack includes either master (attacker) or slave (zombies) to a broadcast IP address, by which all the available machines in subnet starts broadcasting the, messages and it amplifies malicious traffic to reduces the bandwidth of victim's system. Depletion of resources attack intended to consume all the resources of a server or process so that it could not fulfill the service of authorized request. Again it is executed by two ways. Protocol exploitation attacks: Protocol like TCP, attacker use the TCP SYN attacks which is a three-way handshake communication protocol between server and client. We use the following scenario to establish a new connection. At first, the client sends a SYN packet as SYN 1 to the server so the connection process can be started. After that, the server replies with an ACK 1 and SYN 2 to acknowledge that the server receives the request and it is ready for synchronizing. Then after the client sends an acknowledgement packet as ACK 2 to the server, which indicate that it has also received the replied package from the server and also ready for synchronized communications. The resources like memory, processors, and ports etc. are being allocated by the server for making connection as soon as it sent out the ACK 1/SYN 2 packet. And the resources are kept safe for a longer period in case of acknowledgement ACK 2 is not received from client till time out. A malformed packet attack: In malformed packet attack, the attacker instructs the zombies to send maliciously formed IP packets to the victim system so the victim's machine could be crashed. It uses an IP address for launching the attack, where the packet has the same source IP address and destination addresses which confuses the victim machine and lead the machine to crash.

Figure 7 illustrates the table for analysis of the existing mechanisms in accordance with an embodiment of the present disclosure. The existing mechanism does not focus on the many of the features of attacks and works for majorly for passive defensive mechanisms, that is also a problem and therefore they are not sufficient to trackback the attack.

Figure 8 illustrates Architecture of proposed approach in accordance with an embodiment of the present disclosure. Window size and a threshold are independent variable, but the value of the entropy depends on these two independent variables. The detection of an attack function figures entropy for the entire new incoming packets. A window size is the quantity of packets in that window. As new incoming packets, comes and the entropy value is determined. In the event that different packets are received at a similar port of same host/switch in the predefined window, and it crosses over the limit of threshold value, then a DDoS attack occurs. In the architecture, the controller keeps up a log record of figured entropy for all the packets. In the attack situation, the entropy falls than the threshold persistently. Subsequent to recognizing attack in the predetermined window, the focused on port of the predefined switch is blocked. Started from the data plane through switches, we receive the incoming flow rate of packets, and check whether it exceeds beyond the specified threshold ti or not, as this is the first check to identify the unusual traffic. On receiving the unusual traffic, the controller plane then collects all the statistics of switch's flow. Here, in experiments we have used a POX controller. It offers many primitives to parse the incoming packets. The packets information can be extracted through a packetin command and then by thefrompacket function, the match for the flow rules can be created. Also the controller sends packetout, flowmod and other OpenFlow messages to program the switch. Controller's job is quite important as it is a middle layer and has to interact with the switch and application both at the same time. To further proceed, it helps to compute the probability and entropy by using the specified Shannon equation in the application plane. These statistics helps to identify the attack by comparing the current entropy with the specified entropy threshold. Based on the current entropy value, if it does not exceed the second thresholdsand then it is assumed and declared as an attack period and increment a counter. Otherwise, it goes into the non-attack period and asks to controller to modify the packet and forward it to the next address through the switches. Once the attack is identified, it is the responsibility of the application plane to diminish the effect of the DDoS attack. Therefore, it is equally important to mitigate the DDoS attack. In the mitigation part, the malicious flow whose hit count value is more than the third threshold, are dropped out from the link by using the rules and blocked that id, also the subsequent request from that id will be blocked. Algorithm 1 and Algorithm 2 represent the detection method of DDoS and mitigation method respectively in SDN-Cloud.

Figure 9 illustrates DDoS detection algorithm in accordance with an embodiment of the present disclosure. In which the flooding based DDoS attack is identified. Here, first three thresholds have been initialized ti, t2 and t3 for incoming packet flow, entropy and count threshold respectively. Then first catch the unusual traffic by comparing the flow rate with first threshold. If it exceeds the ti value, then with the help of the controller we collect the statistical information for the purpose of entropy calculation. Once it is calculated again compared by the second threshold t 2 . If the current calculated entropy does not exceed the value of t2 then we enter into the period of attack. After the attack happens, there is an increment of the counter value and also mark those packets. Now, for those specific packets that have the higher count value in comparison with third threshold value t3 , alert messages of attack is generated.

Figure 10 illustrates DDoS mitigation algorithm in accordance with an embodiment of the present disclosure. After the generation of alert messages of attack in algorithm 1 the mitigation function defines in algorithm2 is invoked. it collects the port, DPID and IP information from the switch's flow rule and block that port, drop all the subsequent request from that IP and also remove all such flow rules from the flow table.

Figure 11 illustrates the defense mode in accordance with an embodiment of the present disclosure. The figure shows 3 modes of operation in the best mode; the bandwidth of the entropy is selected to be small as it characterizes flow as genuine and valid. This option is to reduce the false alarm. The figure also presents immature mode which has lowest power to detect the attack, where as the medium detection rate is presented by normal mode of operation. If the genuine traffic is too high, then the system switches to the immature mode to reduce the undesirable effects on genuine traffic by keeping false positive low.

Now due to the mitigation function, the attack flows that exist in acceptable entropy range but try to utilize the vulnerabilities are intended to be dropped out by blocking the port id, which improves the result. On the other side the systems are switched into the best mode, when the attack traffic is launched.

Figure 12 illustrates the SDN topology in accordance with an embodiment of the present disclosure. The figure shows the used topology with 9 OpenFlow virtual switches, 64 hosts and 1 controller for the simulation. The experiment is performed for the specified time period and collected the data from the trace file. The selected window size is 0.2 seconds and the packets are divided into the specified time for each. For every window size, the entropy of every individual flow is calculated and sum up all to get the result. For monitoring, the values of various entropies are over every flows, the analysis has taken place over a number of successive same window size and splits curves plotted for every window. The simulation for longer period is also performed such as 1.0 seconds and found deviations are still but average is almost same. Next after the implementation of present approach, the uncalibrated system is calibrated by determining entropic thresholds values.

Figure 13 illustrates a table for simulation parameter in accordance with an embodiment of the present disclosure. The figure shows the parameters used in SDN topology. For physically set up, an Openflow controller is connected to a network. The entropy of the traffic related to the controller under normal and attack conditions is observed. The POX controller, which is accustomed to actualizing attack recognizable proof strategy and runs on python is used. The tool, scapy is used for generation of packets, sniffing, scanning, forging of packet and attacking.

Figure 14 illustrates the entropy variations under attack in accordance with an embodiment of the present disclosure. The degradation in entropy values under the attack period. In this figure, the top most line shows the entropy variations when 7 attacker attack with the 3 Mbps attack load, the middle line has attack load as 4 Mbps with same number of attackers while the down most line shows variations in entropy with 5 Mbps attack load. It can be seen from the figure that when the attack is launched, the packet flowing distribution gradually converted into concentrated form in a small number of flows. Consequently the entropy of every window decreases.

Figure 15 illustrates the Throughput Observation in accordance with an embodiment of the present disclosure. The figure shows the throughput observation of the link for the simulation time of 16 seconds. The figure has two conditions, throughput under non attack condition and throughput under attack condition. The second condition depicts that under the attack period, the throughput decreases drastically. This shows a disruptive effect on the utilization of bandwidth during attack time.

Figure 16 illustrates the Entropies distribution of individual flow in accordance with an embodiment of the present disclosure. For the calculation of every entropy flow, the function used is fun(p) = (-1)plog(p), 0 < p < 1 . The highest point of the curve occurs at the 0.5 probability.

Figure 17 illustrates the table of simulation parameter in accordance with an embodiment of the present disclosure. The figure shows two types of function, one is an growing function which is used for the values of 'p' lies between 0 and 0.5 and another is shrinking function used for the values of 'p' lies between 0.5 and 1.

Figure 18 illustrates the Flow Statistics observation in accordance with an embodiment of the present disclosure. The figure examines the flow statistics of our approach over disruption of bandwidth during the simulation of DDoS attack. The curve moves, change in highest values and skewness reveal the existence of DDoS attacks.

Figure 19 illustrates a table of the design parameter (f) in accordance with an embodiment of the present disclosure. The varying values of tf to calculate the entropic thresholds are used. These values are used to decide the operation modes such as immature, normal and best. The set of tf values as{8,9,10} for immature, {6,7} for normal and {2,3,4,5} for best mode are recommended.

Figure 20 illustrates ROC curve in accordance with an embodiment of the present disclosure. When the value of tfis set to a high value, the range of entropy value is broader, and then the false alarm and the detection rate will be low. And vice versa, if the value of tf is set to too low, it may highly detect the attacks but also has to suffer with a high rate of false alarm. As soon as the attack is detected by variations in entropy, the value of tf is determined, thus optimizing the thresholds. To show the relationship between detection and false positive ratio, we plot the ROC curve over different tolerance factor tfis plotted. It evaluates the performance of the proposed mechanism. It can be seen that at tf--4, it gives the largest area for best result and also isolate all the malicious traffic. While the attack is mild, the immature mode works better. Although the experiments are carried out under different conditions, the technique provides relatively very high detection rates when the false positive rates are low. For example, the detection rate is 98.2%, when tfis 4 when the false positive rate is .04%. When the false positive rate is reduced to .02%, the detection rate is still 91.2%.

Figure 21 illustrates Holding time of Network during attack period in accordance with an embodiment of the present disclosure. Figure shows the holding time of SDN during attack with and without proposed approach. It can be seen from the figure that the present approach has significantly improved the holding time. During simulation, done switch at a time to launch the attack is targeted, where 7 attackers are selected randomly for performing the attack and found that SDN hold better time period under attack with the present approach.

Figure 22 illustrates the Holding time of SDN by changing the attack rate in accordance with an embodiment of the present disclosure. The figure shows that when the attack rate increases the holding time of SDN decreases. However, increase in the holding time by applying the proposed approach provides some extra time to the underlying DDoS defense system to take effect and start .mitigating the attack flow.

Figure 23 illustrates DDoS Mitigation Algorithm in accordance with an embodiment of the present disclosure. At the time of mitigating the system, the dropping out rules at switches helps to reduce the number of OpenFlow messages exchanged between controller and switch. The figure shows that the numbers of OpenFlow messages exchanged during attack are reduced significantly when the proposed approach is applied. It makes the switches capable to handle a large number of new flows during attack period without involving the controller.

Figure 24 illustrates a table for Comparisons of the proposed approach with other existing approaches to defend DDoS Attack in SDN-Cloud in accordance with an embodiment of the present disclosure. The figure shows the comparisons of the proposed approach with other approaches in the form of literature in defending DDoS by utilizing the features of SDN. it can be seen that most of the existing approaches are not able to reduce the overhead as they exchange lots of messages to communicate with the servers.

The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

Claims (10)

WE CLAIM

1. A method for defense mechanisms against DDoS attack based on entropy in software defined network cloud, the method comprises:

receiving incoming flow rate of packets and verifying whether said flow rate of packets exceeds beyond a specified threshold or not in order to identify an unusual traffic;

collecting all statistics of switch's flow by a controller plane upon receiving said unusual traffic;

parsing incoming packets by offering many primitives using a POX controller;

extracting packets information and thereby creating match for flow rules;

sending messages to program a switch using said controller;

identifying a distributed denial-of-service (DDoS) attack by comparing current entropy with specified entropy threshold using statistics;

incrementing a counter upon obtaining an attack period or going into a non-attack period and asking said controller to modify packet to forward it to a next address through said switches; and

diminishing effect of said DDoS attack by said plane and mitigating DDoS attack upon identifying of an attack in a software defined network cloud (SDN-Cloud).

2. The method as claimed in claim 1, wherein first three thresholds have been initialized for incoming packet flow, entropy and count threshold.

3. The method as claimed in claim 1, wherein said packets information is extracted through a packetin command and then match for said flow rules are created by a frompacket function.

4. The method as claimed in claim 1, wherein said controller is a middle layer that interacts with said switch and application both at a same time, wherein said controller helps to compute the probability and entropy by using a specified Shannon equation in an application plane.

5. The method as claimed in claim 1, wherein said attack period is obtained if said current entropy value exceeds second thresholds whereas said non-attack period is obtained when said current entropy value does not exceeds second thresholds.

6. The method as claimed in claim 1, wherein a malicious flow whose hit count value is more than a third threshold are dropped out from a link by using a rule and blocking an ID in said mitigation part, wherein a subsequent request from said ID is blocked.

7. The method as claimed in claim 1, wherein an alert message of attack is generated for specific packets having higher count value in comparison with third threshold value.

8. The method as claimed in claim 1, wherein said DDoS mitigation technique collects said port including DPID and IP information from said switch's flow rule and thereby block said port.

9. The method as claimed in claim 8, wherein after blocking said port all subsequent request from said IP is dropped and all such flow rules from said flow table is removed.

10. The method as claimed in claim 1, wherein small entropy is selected to characterize flow as genuine and valid to reduce a false alarm and if genuine traffic is too high, then system switches to an immature mode to reduce undesirable effects on genuine traffic by keeping false positive low.

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 8

Figure 9

Figure 10

Figure 11

S.No Parameters Values

1 Client traffic load .1-.6 Mbps

2 Attack traffic load 1-6 Mbps 3 Simulation time 0-16s 4 Attack time 2-8s Legitimate traffic type TCP 6 Attack traffic type UDP 7 OpenFlow switches 9 8 Hosts 64 9 Targeted node 1 10 Generated traffic in attack UDP mode 11 Size of the window 50 12 Controller POX

Figure 13

Figure 14

Figure 15

Figure 16

Function Range of Probability Type of function 0 ≤ p ≤ 0.5 Growing Function fun(p) = (−1)plog(p), 0.5 ≤ p ≤ 1 Shrinking Function

Figure 17

Figure 18

Parameter Higher Lower Range (tf) Range 2 5.183491 4.955864 3 5.193491 4.921864 4 5.231491 4.905864 5 5.260491 4.896864 6 5.282491 4.853864 7 5.293491 4.815864 8 5.313491 4.794864 9 5.333491 4.755864

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Overhead on Attack False Computation Approaches SDN Detection Positive al Overhead Controller Rate Rate Rochak et al. Moderate Low Moderate Low

Shidaganti, Ganeshayya Moderate M oderate High Low Ishwarayya, et al.

Bhushan et al. Low Low High Moderate

Sahay et al. High Moderate High Low

Mousavi et al. Moderate Low Moderate Moderate

Cui. et al. High High High Moderate

Wanget et al. Moderate Low High Moderate

Proposed approach Low Low High Low

Figure 24