Abstract
In traditional networks, DDoS attacks are often launched in the network layer or the transport layer. Researchers had explored this problem in depth and put forward plenty of solutions. However, these solutions are only suitable for scenarios such as a single link or victim side network and could not analyse traffic distribution from the angle of the global network. Also, the TCP/IP network architecture lacks abilities to quickly conduct resource deployment and traffic scheduling. When DDoS attacks occur, victims usually could not respond in time. With the superiorities of centralized control mode and global topological view, Software-Defined Networking (SDN) provides a new way to get over the above issues. In this paper, we adopt a combination of diverse technologies to design SDNDefender, a SDN-based DDoS detection and defense mechanism, which is composed of two core components aiming to counter the most popular DDoS attacks including IP spoofing attack and TCP SYN flood attack. We carry out quantitative simulation experiments for evaluating SDNDefender from many metrics. The experimental results show that in contrast to other DDoS defense algorithms, SDNDefender not only efficiently validates spoofed packets and withstands well-known attacks but also defends unknown attacks according to the target’s available resources. Besides, SDNDefender could significantly reduce TCP half-open connections and improve detection accuracy, alleviating attack influences that exhaust the server’s resources and network bandwidth.
1. Introduction
With the rapid growth of networking technologies, current network systems and data centers are becoming more and more complex and data excessive. For system designers, ensuring the high availability and security of resources and services is still a crucial and challenging issue. Among different kinds of cyber-threats, DDoS attacks are most harmful, attracting tremendous research efforts from both academia and industry. DDoS is a large-scale and distributed network attack, which launches illegal requests to attack targeted hosts and exhaust their bandwidth and service resources. The fundamental cause of a DDoS attack is that in TCP/IP protocol stack, connection requests of any proxy program could be sent to the targeted server without identity authentication so that attackers could configure proxy servers to attack victims. At present, scholars carry out further research on DDoS attack defense technology. Ref. [1] presents a detection method based on the Pearson correlation coefficient to discriminate anomaly traffic from normal traffic. Ref. [2] builds a traffic self-similar model with chaos theory, which utilizes the Lyapunov equation to detect attack behavior and trains samples to filter anomaly traffic using the BPNN network. Ref. [3] proposes a sliding window-based flow interaction feature algorithm that could lower interruptions of background flows and raise attack detection rates. Ref. [4] designs a Naive Bayes classification method that makes use of datasets from discrete Wavelet transform training and discrete Fourier transform training to identify attacking traffic. Experiment results show that this method has better calculation accuracy than that of those methods using threshold values. Ref. [5] uses a dynamic game defense measure to deal with DDoS attacks in the botnet environment. Ref. [6] builds a cooperation defense mechanism with Network Function Virtualization (NFV). The mechanism sets up a virtual intrusion detection system and a resource allocation model to filter and redirect anomaly traffic.
In summary, current DDoS defense mechanisms mainly choose attack features and congestion patterns as detection evidence and further design models and algorithms by statistics, machine learning, data mining, and so forth. However, under the Internet architecture, building network topology and forwarding packets seriously rely on network protocols and there are no uniform norms between ports of network devices, so these flaws constrain executions of these defense strategies.
SDN paves a new way to tackle the abovementioned problems. First, the controller as the core component separates control function from network devices and takes charge of global topology management, creating flow entries and updating link status, whereas network devices merely realize data forwarding. Second, SDN adopts flow forwarding rather than packet forwarding. When detecting attack behavior, the controller could make decisions and install flow entries on switches to block attacks. According to the analysis above, we present SDNDefender, a SDN-based DDoS detection and defense mechanism. Compared with other DDoS defense strategies for SDN environments, SDNDefender is a comprehensive detection and defense mechanism that can counter different kinds of DDoS attacks such as ARP/IP spoofing and TCP SYN flood. It not only uses dynamic flow entries and an intrusion prevention library to track source address and match well-known cyber-attacks but also defends unknown attacks by monitoring the available host resource. SDNDefender consists of two core components: Anti-IP spoofing and Anti-TCP SYN flood. When receiving incoming packets, the Anti-IP spoofing component validates whether they have forged source IP addresses by calculating their forwarding paths, and if confirmed, it will immediately install flow rules on affected OF switches to directly drop these packets. In addition, this component is also responsible for examining packet’s legitimacy through building an intrusion prevention rules (IPR) library and designing a host-based anomaly detection algorithm for suspicious access. For the Anti-TCP SYN flood component, it firstly verifies SYN packets’ transmission rate with univariate Gaussian distribution. Once suspicious TCP flows are recognized, it calculates entropy based on destination IP address and the network self-similarity index to go on further detecting the onset of the SYN flood attack. As flood traffic is detected, the component starts to install flow rules and deploy priority queues on OF switch ports to block attack packets and allocate the least bandwidth resource for a small quantity of anomaly traffic into the network to ensure that normal flows can be forwarded timely. We implement simulation experiments to evaluate SDNDefender and compare it with other defense algorithms using many metrics. Our results show that under IP spoofing attacks, SDNDefender can reduce the maximum average packets per flow and the server’s CPU load by 30% and 37%, respectively. Also, under TCP SYN flood attacks, SDNDefender not only slows down SYN packets’ transmission rate and decreases the maximum TCP half-open connections by 35% but also observably improves detection accuracy and lowers the false positive rate.
The main contributions of this paper are summarized as follows:(1)We present a dynamic entries match (DEM) algorithm to validate incoming packets’ source addresses. Leveraging SDN’s centralized control, DEM algorithm uses path-based routing rules to match a packet and decides the next action for it.(2)Inspired by misuse detection, we build an IPR library to check intrusion behavior. IPR extracts signatures of well-known cyber-attacks and stores them in a rule tree. Besides, we design a host-based anomaly detection algorithm to counter unknown attack events.(3)On detecting TCP SYN flood attack, we employ univariate Gaussian distribution to examine SYN packets’ transmission rate. For dubious flows, we propose a detection algorithm to determine whether there exists flood traffic using both entropy based on destination IP address and network self-similarity index.(4)We present a SYN flood mitigation method based on DiffServ model. It takes advantage of ingress port blocking and priority queue scheduling to relieve flood traffic’s effects on the network.
The rest of this paper is organized as follows. We first introduce background knowledge of DDoS and SDN, and describe current research progress in Section 2. Next, we expound the design principles of SDNDefender in Section 3. Then, we implement simulation experiments and discuss experimental results in Section 4. Meanwhile, we analyse those factors affecting our experiments in Section 5. Finally, we conclude with a summary of the main points in Section 6.
2. Background and Related Work
2.1. DDoS Attack
Compared to the single attack method of DoS attacks, DDoS is a large-scale and distributed network attack that is more detrimental to Internet services. It utilizes multitudinous controlled nodes to launch DoS attacks on targets and brings victims a breakdown by exhausting their network bandwidth and system resources. Figure 1 illustrates an entire DDoS attack process that is made up of an attacker, masters, zombies, and victims. First of all, the attacker needs to gather system configuration and run state of targets. Second, the attacker makes use of loophole scanners or backdoor programs to intrude as many hosts as possible, and then these affected hosts are divided into masters and zombies. Each master controls a range of zombies and on receiving attack codes from the attacker, the master forwards these commands to its zombies and informs them of attacking targets.
2.2. SDN
Legacy IP networks are complex and difficult to manage because their control and data planes are vertically integrated. What is more, they involve network devices that run distributed control software that is closed and proprietary. SDN is an emerging software-based network architecture that supports centralized network control and programmability and offers rich APIs to lift automatic network management level and meet various business demands. As seen from Figure 2, a basic SDN architecture comprises infrastructure, control, and application layers. The infrastructure layer includes a group of one or more network devices such as OpenFlow (OF) switches, routers, and terminals, each of which contains a set of traffic scheduling and gathering statistics resources that directly tackle end user traffic, along with the necessary supporting resources to ensure proper connectivity, security, and quality. The responsibilities of the control layer are mainly programming and managing the infrastructure layer. The control layer is composed of a set of SDN controllers that translate the upper applications’ requirements and exert low-level control over the network devices through standardized interfaces while providing relevant information up to the SDN applications. The application layer supplies network applications that can bring new network features or services, such as traffic engineering, security and network verification. In addition, the application layer can receive a global view and overall statistics of the network from the controllers and use this information to provide appropriate guidance to the control layer.
As the most commonly used protocol for the southbound interface of SDN, OpenFlow decides basic components, core functions, and protocols. As shown in Figure 3, an OF switch is a forwarding device that deals with incoming packets in terms of its flow tables that consist of a set of flow entries, each of which is made up of match fields, counters, and instructions. The match fields in a flow entry can match various protocols, such as Ethernet, IPv4, ICMP, UDP, or TCP, depending on the OpenFlow specification. The counters are used to track statistics relevant to a flow, such as how many packets and bytes have been forwarded for this flow, as well as the duration of this flow. The instructions prescribe what the switch should do with a packet matching this entry. Common instructions are “forward,” “drop,” “modify field,” etc.
SDN provides users with diverse network functions, yet also faces many cyber-security challenges such as DDoS attacks. In the infrastructure layer of SDN, OF switches and their flow tables are likely to be a major target, because they maintain information related to network management, traffic scheduling, and fine-grained access control. More specifically, the main task of an OpenFlow controller is gathering the run state of underlying devices, making forwarding policies and instructing the actions of network elements. It manages the switch flow table by adding or removing flow entries via the secure channel. To make the forwarding fast and efficient, the flow table usually uses ternary content addressable memory (TCAM). However, TCAM is usually very costly and only supports limited flow entries. When attackers utilize network protocol flaws, such as address spoofing or packet flood technique, to compromise targets and even make them unavailable, there will be a large number of useless flow rules and the flow table might be unable to store normal flow rules. Therefore, the first and foremost security challenge is distinguishing malicious rules from genuine flow rules. The second security challenge is about the number of flow entries a switch can accommodate. In OpenFlow, every switch needs to buffer unsolicited flows until the controller releases new flow rules. Due to the limited memory of the switches, the infrastructure layer is prone to suffer saturation attacks. In the past few years, many researchers have discussed DDoS attacks in the SDN environment and put forward a lot of solutions. Authors in Ref. [7] present a SDN-based security policy enforcement framework for ships’ communication networks. This framework uses Event-Condition-Action (ECA) paradigm for high-level security policies to define flow types and corresponding actions. With network service header (NSH), network traffic can be monitored from end to end. To defend slow-running attacks in SDN, authors in Ref. [8] present a three-phase mitigation framework, which detects potential attackers according to the servers’ state and identifies them with multiple metrics. The framework leverages the SDN controller to send RST packets to release the resources occupied by attackers. Ref. [9] employs both sFlow and adaptive polling sampling to propagate all related traffic statistics to the IDS for classifying different feature extractions. Meanwhile, a deep neural network algorithm-Stacked AutoEncoder is used to determine whether there exists DDoS attacks in the network. In this paper, we specifically focus on those solutions towards defending against IP spoofing attack and TCP SYN flood attack.
2.3. Proposals for IP Spoofing Attack
IP spoofing refers to an IP source address forgery or host files hijacking technique in which attackers can conceal their real identities and launch attacks to gain unauthorized access and sensitive data of the targeted host. This threat derives from the shortcoming that Internet packet forwarding in routers merely depends on each packet’s destination IP address but neglects the validation of the packet’s source IP address to verify sender authenticity. At present, most of the anti-spoofing solutions can be categorized into path-based filtering, end-to-end, and traceback. Path-based filtering proposals verify and filter packets by the paths they flow through, and, to a large extent, ensure that targeted hosts avoid receiving attack packets. Ingress Filtering [10] is a typical and lightweight filtering solution, which is deployed into a router or a firewall between two networks and can restrain attack packets always staying in the subnet to which attackers belong. However, this solution only defends attacks from the intra-domain and is not beneficial for ISPs. End-to-end technique adds a signature into a packet at the sender side and verifies the packet’s genuineness using the signature at the receiver side. IPSec [11] is a host-level identification mechanism that uses a private key to encrypt a packet and decrypt it by a sender’s public key. Although IPSec can examine a packet’s integrity, its high overhead cost cannot efficiently defend against DDoS attacks. APPA [12] employs a single Hash function to create a signature for both sender and receiver, and each signature can only be used once. This not only decreases interactions of both sides but also reduces communication complexity. Compared with the two types of solutions above, traceback is used for tracing attackers’ real addresses through packet mark. Packet mark technique adds router marks into a packet and the receiver gets the packet’s practical path using these marks. But this technique is not suitable for large-scale networks because the more routers a packet traverses, the longer the packet’s length is, and when a new mark is added, the earliest marks will be erased. In summary, these solutions still face some problems to solve, although they achieve good effects for anti-spoofing.
As discussed before, SDN owns the global topological view and the centralized control capacity. This can interpret access control list (ACL) by flow rules in OF switches, and bring a new opportunity to solve the IP spoofing issue and overcome shortcomings in traditional solutions. So far, there are some SDN-based solutions to the IP spoofing problem. SAVSH [13] aims to achieve the best trade-off between packet filtering accuracy and deployment cost. It converts the hybrid network into a sink-tree and locates deployment nodes by computing the minimum OF switches deployment ratio with all legal IP prefix pairs. It also utilizes the SDN controller to generate filtering rules and deal with network dynamics. However, SAVSH needs to adapt to topological change in advance and take a high delay for redistributing new filtering rules. SIPAV-SDN [14] maintains a HostTable, where the switch id, switch port, host IP, and MAC are recorded as an item by extracting details from Packet_In messages. The scheme validates each incoming packet with the table and only installs flow entries for legitimate packets to forward them. Ref. [15] presents DDAH, a host-based dynamic detection method for IP spoofing in SDN. DDAH uses access ports to find anomaly hosts and periodically calculates their weight and activity. If a port’s activity exceeds the threshold, DDAH will select some flow features and employ machine-learning algorithms for further detection and mitigation. BASE [16] takes BGP information to calculate path-based marking values and distributes them into BGP routers. Each BGP router updates its flow rules according to the marking value and filters every incoming packet with an incorrect mark. For BGP protocol, any route change brings a recalculation of the routing table, so multiple recalculations will overload the router. Also, the filtering accuracy of BASE relies on the network scale.
2.4. Proposals for TCP SYN Flood Attack
TCP SYN flood is one of the most widespread DDoS attacks, in which attackers exploit the 3-way handshake mechanism in TCP, and send a mass of spoofed SYN packets to consume resource on the targeted server and degrade its availability. Most of the existing proposals for defending against SYN flood attacks in legacy networks use end host-based methods. SYN cookie, SYN cache [17], and SYN proxy [18] all need a modification in the host’s TCP stack so as to change algorithms and data structures used for connection lookup and establishment, yet the main limitation of these solutions is that they can only detect attacks at the receiver side. In this way, the network will be seriously congested due to fierce attack traffic. Other solutions like firewalls and intrusion detection system (IDS) are usually deployed on the edge of the targeted network and employ static rules or signature-based strategies to tackle anomaly traffic. Although they can detect and block trivial DDoS attacks, they will be compromised as attackers launch attacks using spoofed IP addresses or different TCP source ports.
In summary, none of the solutions above can be directly applied to SDN, because SYN flood attacks can destroy the entire SDN network rather than a single targeted host. Specifically, the controller has global network information, so it is apt to suffer the saturation attack due to receiving a huge number of PACKET_IN messages at a high speed and becomes a single point of failure for the network. In the last few years, many solutions have been proposed in the literature to counter SYN flood attacks in SDN networks. AVANT-GUARD [19] uses each OF switch as a proxy to inform the controller about the connection requests that successfully perform TCP 3-way handshake via an extension message. To mitigate SYN flood attacks in SDN, AVANT-GUARD needs to modify the controller and OF switches together. Moreover, it requires additional resources to establish new connections for legitimate TCP requests. This will cause long delays and introduce a buffer saturation attack. LineSwitch [20] also uses the SYN proxy technique to maintain a minimum number of TCP connections and adopts probabilistic blacklisting of network traffic for mitigating the buffer saturation attack. Like AVANT-GUARD, LineSwitch requires an upgrade of data plane switches. Authors in Ref. [21] propose a SYN flood mitigation algorithm based on machine learning. The algorithm calculates the entropy of ports per each IP address and discerns anomaly traffic using K-Nearest Neighbors (KNN) method and CAIDA dataset. Experiment results show that the algorithm mitigates SYN Flood attack up to more than to 96% while normal traffic is almost not affected. SAFETY [22] is composed of two components: a detection component and a mitigation component. By calculating the entropy of both destination IP and specific TCP flags and comparing it with an adaptive threshold, SAFETY can complete attacker identification and stop ongoing TCP connections until corresponding SYN-ACK packets arrive from the server. However, SAFETY lacks of the ability to deal with plenty of TCP half-open connections existing in the network. Authors in Ref. [23] use TCP timeout mechanism and Packet Round-Trip Time (RTT) against SYN flood attacks. The scheme drops the first SYN packet from a sender and calculates RTT based on the time between the first and the retransmitted SYN packets. If an ACK packet arrives later than the previous RTT, the ACK packet is dropped and this half-open session will be removed. SLICOTS [24] verifies the legitimacy of the connection establishment request using the TCP 3-way handshake process. When receiving a new SYN packet, SLICOTS extracts necessary information including MAC address and TCP ports into a pending list, which records uncompleted TCP connections. Moreover, SLICOTS calculates a path and instructs OF switches to forward the SYN packet. Once SLICOTS receives the ACK packet from the requested host, it recognizes that this is a normal TCP connection, and otherwise if the number of half-open TCP connections for the requested host exceeds a threshold, SLICOTS will install a flow rule for blocking anomaly traffic at the edge switch. However, SLICOTS does not take MAC spoofing into account and this issue will make SLICOTS inactive. SRL [25] is comprises a hash module and a flow aggregator module. For an incoming SYN packet, if its requests exceed the threshold, SRL will calculate the hash value based on IP address and maximum segment size (MSS) and use flow aggregator to install hash priority-based flow rules in edge switches for eliminating those fraudulent rules with lower hash values.
3. Proposed Mechanism: SDNDefender
To address security challenges discussed in Section 2, we propose SDNDefender as a scalable, efficient, and defensive mechanism for countering IP spoofing attack and TCP SYN flood attack in SDN networks. Particularly, SDNDefender is implemented as an extension of the SDN controller to protect from cyber-attacks. As shown in Figure 4, SDNDefender consists of two components: Anti-IP spoofing and Anti-TCP SYN flood. The Anti-IP spoofing component is responsible for validating a packet’s source address authenticity and its legitimacy. Anti-TCP SYN flood component conducts multistep detection on TCP flows to determine whether SYN flood traffic exists. In this section, we describe the design principles of each component in detail.
3.1. Anti-IP Spoofing Component
As shown in Figure 5, when receiving a new PACKET_IN message, the Anti-IP spoofing component validates the packet’s source address and decides how to handle the packet. Besides, the component also checks destination host’s performance for detecting unknown attacks as soon as possible.
3.1.1. Dynamical Entries Match
In SDN, topology discovery is an essential service and consolidates many higher layer services. On startup, the SDN controller requests configuration information from OF switches using OFP_FEATURES_REQUEST messages, and this initial switch-controller handshake tells the controller about the existence of the nodes in the network. Currently, most of the controllers leverage the Link layer discovery protocol (LLDP) [26] to explore the available links between switches in the network. LLDP is a neighbor discovery protocol working on the data link layer, which is composed of a header and a LLDP data unit (LLDPDU). The link discovery process is shown in Figure 6. The controller sends a LLDP packet to each port on switch S1 via PACKET_OUT messages. Each of these LLDP packets includes Chassis ID and Port ID accordingly. Suppose that switch S1 forwards a LLDP packet to port3 of switch S2 via port2, and then S2 puts its metadata and this packet together into a PACKET_IN message and sends it to the controller. The controller parses the PACKET_IN message and infers the existence of a link between (S1, port2) and (S2, port3) from the LLDPDU and the metadata. This process is repeated for each switch in the network, and as a result, the controller gets a global network view. For host discovery, we assume that host1 pings host2 and an ARP packet will be sent to the controller, which learns host1’s IP address, MAC address, and ingress port. Due to the lack of knowledge of host2, the controller installs flow rules on S1 to order it to flood the ARP packet, and this packet reaches S2 via port3 and is received by host2. Similarly, host2 sends an ARP response packet to the controller, and thus the controller records host2’s location and floods the ARP response packet to host1.
As described above, the controller can dynamically acquire the current network topology view and load status. More importantly, the controller can calculate a path between any two hosts in the network using some routing algorithms like open shortest path first (OSPF) and routing information protocol (RIP) [27]. Therefore, we present a DEM algorithm based on calculating the forwarding path. Table 1 lists notations used in this subsection.
To get the forwarding path of a pair of hosts, we select the shortest path algorithm called Floyd [28] to realize this goal. First, we calculate the link weight W. We use OFP_PORTSTATS messages to periodically query transmission bytes of each port on each switch, and calculate bandwidth available of each link, which can denote W. For a link l (l ∈ E), we assume that in a transmission direction, l forwards b bytes in t seconds, so Wl can be depicted by Equation .
Second, we define matrixes D and P as (2) and (3), respectively. In (2), we let dij (1 ≤ i ≤ m, 1 ≤ j ≤ m) be the distance from switch i to switch j. Obviously, when i = j, dij = 0. If there exists a link between switch i and switch j, dij = Wij. Otherwise, dij = ∞. In Equation (3), we let pij (1 ≤ i ≤ m, 1 ≤ j ≤ m) be a node number on the shortest distance from switch i to switch j. If there is a link between switch i and switch j, pij = i, otherwise pij = 0.
Third, we update D by adding an intermediate element from V, and this process will generate D(1), where d(1)ij can be described by Equation (4). By analogy, we can deduce d(k)ij (k = 2, …, m) as Equation 5. If k = m, d(k)ij is the final shortest distance between switch i and switch j. On this basis, we can update p(k)ij according to Equation (6). In Algorithm 1, matrix initialization is a 2-layer loop that is described from line 5 to line 8, and its time complexity is O(m2). The forwarding path calculation is a 3-layer loop that is described from line 10 to line 15, and its time complexity is O(m3). Therefore, the total time complexity of Algorithm 1 is O(m3).
| ||||||||||||||||||||||||||||||||||||||||||
As two hosts begin to communicate with each other, the controller records some necessary information, such as source/destination IP, source/destination MAC, ingress port, etc. Then, the controller calculates a forwarding path and divides the path into several 7-tuple flow entries and each flow entry can be defined as < source IP, source MAC, ingress port, datapath id, egress port, destination MAC, destination IP>. Finally, the controller deploys these entries into switches of the path. Figure 7 demonstrates how DEM algorithm deals with spoofed packets. When host1 attempts to contact host4, the controller will calculate the forwarding path and seriatim install flow entries on s1, s2, and s3. For s1, the flow entry is recorded as <10.0.0.1, 00 : 00 : 00 : 00 : 00 : 01, p1, s1, p3, 00 : 00 : 00 : 00 : 00 : 04, 10.0.0.4>. However, if host2 launches a conversation by disguising its IP address as host1’s, then the flow entry of s1 will be < 10.0.0.1, 00 : 00 : 00 : 00 : 00 : 02, p2, s1, p3, 00 : 00 : 00 : 00 : 00 : 04, 10.0.0.4>, so the controller knows that host2 forges an IP address. Similarly, if host3 pretends itself as host1 and communicates with host4, the route3 is not the same as the route1, and the controller decides that the IP address is also illegal.
3.1.2. Intrusion Prevention Rules Library
On detecting the existence of IP spoofing, the Anti-IP spoofing component immediately sends an OFP_FLOWMOD message to the affected switch and drops forged packets according to the entry. However, even if a packet owns an authentic source address, it still needs to be examined for its legitimacy. For instance, an intra-host was infected by worms and started to send malformed packets. Usually, vicious packets are created by setting mistaken control bits, specific port, or oversize payload. Once these packets are received by targeted hosts, the hosts will have a breakdown immediately. Misuse detection searches for the appearance of specific traffic patterns in a ruleset of attack signatures. It can recognize all well-known cyber-attacks in an accurate and efficient way and the ruleset can be updated by capturing new forms of attacks. According to this analysis, we build an IPR library to validate intrusion behavior. IPR library consists of a big number of rules and each rule is made up of a rule header (RH) and some rule options (RO). The structures of a RH and a RO are shown in Tables 2 and 3, respectively. We can write a rule according to an attack’s specific features. Taking the UDP Chargen attack for example, we define a rule as: “alert udp any any - > any any (msg:‘Chargen attack’; rid:10001; clstype:udp-event; filter: dst_port = 19;)”. This rule allows the Anti-IP spoofing component to check each UDP packet’s destination port, and if there is an alert, the component will drop the packet with an OFP_FLOWMOD entry. Furthermore, we summarize common malformed packet attacks the IPR library can detect, which are listed in Table 4.
With the rapid increase of attack types, we need to periodically update the IPR library to raise the match speed and accuracy. However, considering that the match time of different attribute sequence varies widely, we design a three-layer rule tree to reduce unnecessary match operations. As shown in Figure 8, the rule tree contains protocol layer, port layer, and rule layer.
We classify rule protocols into 4 groups: IP, TCP, UDP, and ICMP. According to the type of rule port, we build three rule port sets by the following steps:(1)If the source port is a specific value and the destination port is “any,” we put the rule into the source port set.(2)If the source port is “any” and the destination port is a specific value, we put the rule into the destination port set.(3)If the source port and the destination port are both of “any,” we put the rule into the general port set.(4)If the source port and the destination port are specific values, we put the rule into both the source port set and the destination port set.
On receiving a packet, the Anti-IP spoofing component decides the port set according to the packet’s protocol and ports. Then, the component matches the packet with each rule in the set in sequence. If there is a full match, the component drops the packet. Otherwise, the component will take further actions to detect attack behavior.
3.1.3. Host-Based Anomaly Detection
For some novel cyber-attacks, IPR library may lack the capacity to detect them because there are no corresponding rules in the library. This not only compromises targeted hosts but also exhausts their resources such as CPU and bandwidth. Usually, a host’s security is closely related to its system resource usage. If the host’s resources have been excessively consumed for some time, the host is subject to serious attacks. So, we propose a host-based anomaly detection algorithm to counter suspicious access or unknown attacks. First of all, we define a host resource availability system X that contains some indicators which reflect a host’s performance from different aspects, such as CPU load, memory usage, system processes, bandwidth, I/O, etc. Second, we use SNMP protocol to collect these indicator values in nonattack scenarios and constitute n evaluation schemes. For each Xi = (a1i, a2i, …, ami)T, where i = 1, 2, …, n, ami denotes the mth indicator value of the ith scheme. Thus, we get an m × n indicator matrix EV. Meanwhile, we define normal value range of the jth indicator as [uj − d ∗ sj, uj + d ∗ sj] (j = 1, 2, …, m), where uj and sj represent the mean and the standard variance of the indicator and d is a constant.
In EV, indicators can be divided into two types: cost and profit. Cost indicators perform well as they have smaller values, which are opposite to the profit indicators’. For , if satisfies Equation (8), X∗ is the best scheme in X. For , if satisfies Equation (9), X∗ is the worst scheme in X.
On this basis, we calculate relative deviation matrixes R∗ = (r∗ij)m×n and R∗ = (r∗ij)m×n. Next, we calculate ci, the included angle cosine of r∗ij and r∗ij. At last, we figure out each indicator’s weight Φi. As shown in Equations (12) and (13), the bigger ci is, the more important the ith indicator is, so it should be endowed with a higher weight.
To detect whether there exists unknown attack behavior, we need to evaluate the targeted host’s current status through periodically collecting its performance indicators and calculating its abnormal degree ad(X). For an indicator x in X, We let ad(x) denote this indicator’s abnormal value. If the observed value of x is in its normal value range, ad(x) = 1, otherwise, ad(x) = 0. Thus, we can get ad(X) by Equation (14) and if ad(X) is bigger than a threshold ϐ, the targeted host is in anomaly status. Furthermore, if the number of anomaly status exceeds a threshold ρ during a given time slot, the targeted host is suffering from attacks. Once potential attacks are detected, the Anti-IP spoofing component will log these events and send an OFP_PortMod message to provisionally block the switch port connected with the targeted host so as to ensure that the host can recover as soon as possible.
3.2. Anti-TCP SYN Flood Component
TCP SYN flood attacks that occurred in the SDN environment are similar to those in the legacy networks except for actions taken by the controller for incoming SYN packets. As illustrated in Figure 9, when the Anti-TCP SYN flood component receives a SYN packet, it tests the packet’s transmission rate and decides whether there is a need for further detection. Once this packet is judged as an abnormal one, the component calculates current entropy based on destination address and network self-similarity index. As the two metrics exceed their thresholds, the component knows that there has been flood traffic in the network, so it will install flow entries to block ingress port and put those attack packets in flight into a low priority queue to limit bandwidth occupation.
3.2.1. Abnormal Detection for SYN Packet’s Transmission Rate
In SDN, the controller uses OFP_FLOWSTATUS messages to obtain a flow’s statistics in real time. The status information includes transmitted packets, transmitted bytes, duration time, etc. On this basis, the controller can calculate the instantaneous transmission rate of the flow. A(t) and F(t) are functions about variable t From t-T/2 to t + T/2, F(T) can be expressed as the following equation.
Upon this condition, we leverage the CIC-DDOS2019 dataset [29] to build a practical flow throughput sample that comprises many elements. CIC-DDOS2019 contains benign and the most up-to-date common DDoS attacks and also includes the results of the network traffic analysis. We let S denote the sample and select n TCP records as sample elements from the SYN subset. When the value of n is big enough, we consider that S nearly coheres with normal distribution. For each record, we can calculate the flow’s goodput via the bytes the flow has transmitted and the duration of the flow. Thus, we define S as S = {s1, s2, …, sn}. If μ and σ2 represent the mean and the variance of S, respectively, the probability density function of S can be expressed as
For a new TCP flow fl, the controller will examine whether fl’s goodput is abnormal in real time. For S, we define θ (0 < θ < 1) as the significance level. Given a parameter ϑ, if P{x1 < ϑ < x2} = 1 − θ, [x1, x2] is the confidence interval of ϑ. Due to S ∼ N(μ, σ2), we can get‾S ∼ N(μ, σ2/n) according to the central-limit theorem. We define a random variable as , and solve Equation (19) to determine the confidence interval of μ, namely . After this, we calculate Ffl(t) and if the value is not in the confidence interval, the value is an outlier. The Anti-TCP SYN flood component will launch further actions to validate the onset of SYN flood traffic.
3.2.2. Measuring Entropy Based on Destination IP Address
The concept of entropy comes from information theory and is used to measure the randomness associated with a random variable. According to the Shannon definition, if a random variable Z owns n values whose happening probability are ψ1, ψ2, …, ψn, respectively, the entropy of Z can be expressed as Equation (20). Among the n values of Z, when only one value’s happening probability equals 1 and all other values’ happening probabilities are equivalent to 0, Z has a minimum of 0. When ψ1 = ψ2 = … = ψn = 1/n, Z has a maximum of log2n.
In the case of nonattack scenarios, hosts communicate with each other, and packets are randomly distributed in the network. However, under TCP SYN flood attacks, there will be plenty of SYN packets that own the same destination IP address in the network, so in such scenarios, the packet randomness is limited due to the nature of the attack. The Anti-TCP SYN flood component employs a sliding window to collect destination IP addresses and calculates the current window entropy. The bigger the entropy value is, the bigger the packet randomness is, and vice versa. Table 5 lists main notations used in this subsection.
We describe the window entropy calculation process according to Figure 10. In Figure 10(a), the window includes 4 packets: p1, p2, p4, and p1. After moving towards right, the window, in Figure 10(b), removes the first packet p1 and adds a new packet p3. Thus, packets going into the current window are p2, p4, p1, and p3. This repeatable process is the workflow of the sliding window.
(a)
(b)
More generally, for a sliding window win, we assume that its capacity is η. If there are n (n ≤ η) different IP addresses in Iwin and their emergence probability is denoted as {ωi|i = 1, 2, …, n}, we can figure out ef, eo and ewin in terms of Equation (20). Next, we move the window to right, and thus If will be cleared and Io is added into the new window I’win. Therefore, we need to recalculate ω′f and ω′o. The calculation for ω′f and ω′o can be expressed as Equations (21) and (22), respectively. After these, we calculate e’win according to Equation (23). Finally, we can get a window entropy series es by implementing the above process repeatedly.
As aforementioned, under nonattack scenarios, there is only a little bit of change among window entropies, so we can take advantage of some software tools like TCPreplay to reimplement the flow throughput sample S and thus obtain a normal window entropy series es. To determine the onset of SYN flood attack, we adopt PauTa criterion to examine each newly generated window entropy. PauTa criterion adopts a given confidence probability of 99.7% to detect outliers according to the triple standard deviation of a group of normal data. As shown in Algorithm 2, when verifying a new window entropy enew, we put it into es and calculate the absolute value of the difference of both enew and a. If the absolute value is bigger than , enew is regarded as an outlier and will be removed from es. Meanwhile, we update the anomaly counter for recording the outlier status. If there are consecutive outliers and the count of outliers reaches the threshold λ, the Anti-TCP SYN flood component will acquire current status of the network self-similarity index. This is because only using entropy to detect flood traffic may lead to a misjudgment. For example, some services in the data centers like Hadoop and MapReduce need multi-client to communicate with a single server simultaneously. Under this many-to-one pattern, the destination IP-based entropy will be similar to that under attack scenarios.
|
3.2.3. Calculating the Network Self-Similarity Index
A lot of research literatures have proved that network traffic owns an attribute of self-similarity. Suppose that X = {Xi |i = 1, 2, …} is a stationary random process, we let μ, σ2 and f(k) (k = 0, 1, …) be the mean, variance, and autocorrelation function of X, respectively. We assume that f(k)∼k−βL(k), k ⟶ ∞, 0 < β < 1 and ∀ x > 0, lim L(tx)/L(t) = 1 (t ⟶ ∞). We let X(m) be the m-order sequence of X where X(m)i = (Xim−m+1 + … + Xim)/m (m = 1, 2, …) and also let the autocorrelation function of X(m) be f(m)(k). If f(m)(k) = f(k), X is a self-similarity process that possesses a unique self-similarity index H, which is also called Hurst index and is equivalent to 1 − β/2. Under nonattack scenarios, network traffic keeps its self-similarity stationary, yet encountering SYN flood attacks, and the Hurst index will obviously descend. Therefore, we can continuously monitor the variation of the Hurst index and detect anomaly traffic. Considering that SYN flood traffic sends a huge number of packets in several seconds, we adopt each packet’s arrival time to calculate the index H. Among different solutions, we select Rescaled Range (R/S) analysis to achieve this goal and describe the calculation process as follows:(1)We set a fixed size time window to collect each SYN packet’s arrival time and thus get a time series.(2)We divide the series into parts {Ii|i = 1, 2, …, }.(3)For each part Ii = {Ia,i| a = 1, 2, …, n}, we let qi and si denote their the mean and standard variance. We create another series of deviations for each part by .(4)We calculate a running total for each part’s deviations from the mean according to .(5)As shown in Equation (24), we pick up both the maximum and minimum values in the updated series of each part to calculate the widest difference. Thus, we can get the rescaled range of each part. That is, yi/si.(6)We get a rescaled range series {yi/si|i = 1, 2, …, }. The mean of this series is . Obviously, as is set as different values, is a function about v. Many researches show that the relationship between and can be expressed as , where is a constant. We take the logarithm on both sides of this formula, and it will be Equation (25). For all , we employ Ordinary Least Squares to fit a straight line and the slope of this line is index H.
We can monitor sequential windows and calculate their Hurst values to detect the variation of network traffic. We set two thresholds £1 and £2. For two adjacent Hurst values h1 and h2, if |h2 − h1| ≥ £1 and h2 < £2, network traffic is under abnormal state. As the entropy and the Hurst value of network traffic all overstep the respective threshold, the Anti-TCP SYN flood component decides the onset of SYN flood attacks and takes safeguards to mitigate attack influences.
3.2.4. DiffServ-Based Mitigation Method for SYN Flood Attack
Under TCP SYN flood attacks, there is a mixture of flows in the network, so how to separate anomaly traffic from normal traffic timely is a major concern. There has been a typical technique called traffic redirection. This technique manages a pool of public IP addresses and selects another IP address in the same subnet for the victim so that normal traffic could be redirected from the attacked address to the new address. However, in large-scale networks, selecting an additional IP address for new route calculation and traffic redirection may bring a long network latency and a very high system cost. Fortunately, SDN provides lots of controller-to-switch messages to enable users deploy QoS strategies on OF switches according to their demands. The Anti-TCP SYN flood component adopts the DiffServ model [30] to deal with anomaly traffic. That is to say that the component carries out traffic classification and management only on edge switches and implements traffic scheduling algorithms on inner switches.
(1) Traffic Classification. As described before, SDNDefender calculates a path for a pair of hosts by extracting the packet header. Therefore, we define a TCP flow as <source IP, ingress port, egress port, destination IP, and status>. Ingress port means the port connected with the source host and egress port means the port linked to the destination host. The parameter “status” decides the flow’s attributes. If its value is 0, the flow is normal. Otherwise, if the value is 1, the flow is considered as an anomaly one. For all normal flows, the Anti-TCP SYN flood component will set the highest priority in flow entries and forward them. On the contrary, for each abnormal flow, the component changes a flow entry’s priority field to the lowest value and rewrites actions as “Drop,” and then this flow entry is installed on the flow’s ingress port. As a consequence, a majority of attack packets of the flow can be directly dropped on the source host side. However, there is still a small quantity of attack packets forwarded to the destination host, because of the workflow of detecting SYN flood attacks; so, the Anti-TCP SYN flood component needs to deal with these packets and keep normal flows unaffected.
3.3. Queue Scheduling
Queue scheduling is a major method for solving competition on shared resources among multiple data flows. To mitigate the effect of the remaining attack traffic in the network, we adopt the priority queue-based scheduling strategy to ensure that normal traffic can be firstly dealt with. Priority queue can lead the classified flows into the queues with different priorities and forward the flows according to the level of their priorities. As illustrated in Figure 11, on the switch’s egress port connected with the destination host, we create two priority queues: QN for normal traffic and QA for attack traffic. SDN provides a SET_QUEUE action to forward a packet to the queue to which the packet belongs, so when installing flow entries on the egress port, the Anti-TCP SYN flood component sets a high priority value for QN as well as a low priority value for QA. Thus, scheduling on QA has to wait for the completion of that on QN.
3.4. Traffic Shaping
To decrease bandwidth waste of the queue QA, there is a need to implement traffic shaping on QN and QA to smooth packet transmission and reduce traffic burst. We assume that there are x anomaly flows arriving at the egress port at a moment t, and each such flow’s throughput is expressed as {εi| i = 1, 2, …, x}. If the egress port’s output bandwidth is B, QN’s available bandwidth rate γt can be expressed as Equation (26). To allocate more bandwidth resources for the queue QN, we have to restrain QA’s bandwidth occupation, so we preset a bandwidth factor ξ (0 < ξ < 1) for QA. We compare 1 − γt with ξ and if the former is less than the latter, we reset ξ as 1 − γt. Thus, the maximum bandwidth QA can take is Bξ. Correspondingly, available bandwidth QN can obtain is B(1 − ξ). At present, SDN offers many application interfaces to realize traffic engineering on OF switches, so we can easily implement traffic shaping towards output traffic.
4. Performance Evaluation
In this section, we carry out a comprehensive simulation study and analyse the results to evaluate the performance of SDNDefender against other defense mechanisms and normal SDN. We will demonstrate how SDNDefender lifts the security of normal SDN.
4.1. Experimental Setup and Simulation Scenarios
We compile SDNDefender as a security module into the RYU controller, an open source SDN controller platform written in Python language. To simulate the data plane of our experimental network, we make use of Mininet, which can be rapidly deployed into hardware environments and emulate complex topologies that include a huge number of hosts and network devices. We choose Ubuntu 14.04 LTS as the system environment because this Linux-based operation system provides lots of third-party plugins for developing SDN applications and complex data processing. As seen from Figure 12, we build a 4-pod Fattree topology with 4 core, 8 aggregation, and 8 Top-of-Rack (ToR) switches and 8 virtual hosts using a testbed that owns a dual-core processor with 3.2 GHz, 4 GB memory, and 250 GB disk space. In this topology, OF switches and virtual hosts are connected via 10 Mbps links and the default latency of each link is set as 2 ms.
Our simulation experiments can be divided into two groups: one for IP spoofing attack and another for TCP SYN flood attack. For each group experiment, we classify experimental data from the angles of accuracy, True positive rate (TPR) and False positive rate (FPR). There are several relevant concepts as follows:(1)True Positive (TP): SDNDefender correctly identifies positive class.(2)True Negative (TN): SDNDefender correctly identifies negative class.(3)False Positive (FP): SDNDefender incorrectly identifies negative class.(4)False Negative (FN): SDNDefender incorrectly identifies positive class.
In the first group experiment, we set the run time of the simulation scenario as 40 s. We compare SDNDefender with normal SDN, SIPAV-SDN, and DDAH, using diverse performance metrics. Specially, we use CIC-DDOS2019 dataset and the random forest algorithm for DDAH to detect anomalies.(i)Scenario 1. We categorize virtual hosts into benign users, attackers, and the server. Next, we let benign users and attackers to concurrently communicate with the server. As shown in Table 6, for benign ones, we use Ping command to generate legal connection requests, and for attackers, we adopt Hping to falsify their IP and implement specific attacks. In the second group experiments, we will simulate TCP SYN flood attack. Considering that flood traffic can quickly exhaust target’s system resources and break it down, we set simulation time as 70 s and only record valid data for the first 40 s. We compare SDNDefender with SRL, SLICOTS, and normal SDN from many aspects.(ii)Scenario 1. Firstly, we let all virtual hosts be benign ones and each host starts a TCP conversation with another one in a random way. This process lasts for the first 10 s. From then on, we let H1, H2, H3, and H4 be attackers and let H5, H6, and H7 be benign ones. We use Scapy to send legitimate TCP SYN packets and employ Hping to launch SYN flood attacks towards the server H8. Table 7 lists simulation parameters for this scenario.(iii)Scenario 2. We choose H1–H6 as potential attackers and gradually increase an attacker in each simulation.
4.2. Results Analysis
4.2.1. Experimental Results for IP Spoofing Simulation
In Figure 13(a), the APPF curves continuously fluctuate with the elapse of simulation time. We can see that SDNDefender keeps its APPF values much lower than that in the other three situations. The main cause of this phenomenon is that normal SDN does not provide any defense measure to counter IP spoofing, so that a massive number of attack packets can be directly forwarded to the server without further validation by the controller. Although SIPAV-SDN can block spoofed packets, it cannot filter ARP spoofing due to its imperfect way of validation. DDAH decides an anomaly host by updating access port’s weight and activity and evaluating a flow’s status with several selected features. Obviously, DDAH will launch the detection process until a port’s activity exceeds the threshold. However during this period, there has to be lots of attack packets in the network. Figure 13(b) shows that each situation’s MFE value gradually increases with the course of experiments. It is clear that the timeliness and detection accuracy of each algorithm decide the number of vicious entries. In normal SDN, there is no countermeasure against attackers, so the anomaly entries increase fast. SIPAV-SDN keeps its flow table much capacious than DDAH, because the former can drop most of the attack packets using a host table, yet the latter needs some time to find suspicious ports and train specific features to detect attacks. On the contrary, SDNDefender strikingly eliminates attack entries, because it implements route-based validation for each flow before forwarding it, and thus, IP spoofing and ARP spoofing can be blocked in advance, so that the controller dedicates itself to matching normal packets. Figure 13(c) displays the variation of the server’s CPU load under different situations. Obviously, the four situations get a maximum CPU load of 1.06, 1.22, 1.33, and 1.27, respectively. In normal SDN, a huge number of attack packets quickly consume the server’s CPU resources and impose a heavy load on it. For SIPAV-SDN, it drops the majority of attack packets with illegal IP addresses while forwarding vicious ARP packets with legitimate IP and MAC addresses. This also increases the server’s CPU usage rate. Compared with such three situations, SDNDefender significantly reduces the server’s work load due to its all-round validation for spoofed packets and quickly blocking attack traffic on ingress ports. IP spoofing also influences the server’s receiving capacity. As shown in Figure 13(d), under normal SDN, SIPAV-SDN, and DDAH, there is a mixture of legitimate packets and attack packets, which surges to the server, so the received byte curve greatly ascends until the attack traffic becomes faint. In contrast, SDNDefender keeps the server’s receiving traffic below 270 bps.
(a)
(b)
(c)
(d)
As shown in Figure 14 and Table 8, SDNDefender performs much better in attack detection than other two algorithms do. SDNDefender not only blocks spoofing attacks but also provides the ability to defend those specific DoS attacks. On the contrary, SIPAV-SDN fails to detect ARP spoofing. This is why its detection accuracy and FPR are poor. For DDAH, its detection effect relies on the delay of recognizing an abnormal port and checking a flow’s status. In another word, the delay imposes a significant influence on the detection accuracy and true positive rate.
4.2.2. Experimental Results for TCP SYN Flood Simulation
Figure 15 shows the variation of the entropy and the Hurst index under normal SDN and SDNDefender, as TCP SYN flood attacks are launched. In Figure 15(a), the entropy value fast descends from 10 s under normal SDN. This suggests that as SYN flood attacks are launched, the window entropy becomes much smaller and IP addresses in the current window are almost the server’s IP address. By comparison, the entropy decreases little by little from 10 s to 20 s with SDNDefender, and then keeps a stationary state, in which the entropy value is much bigger than that in normal SDN. This is because SDNDefender directly drops most of the attack packets on ingress ports and ensures normal traffic is at a predominant level. In Figure 15(b), the SYN flood traffic makes the network self-similarity degree obviously go down from 12 s and network traffic shows inverse persistence. As SDNDefender detects the onset of flood traffic at 14 s, it reduces the proportion of anomaly traffic in the network as much as it could. Therefore, the Hurst curve returns a normal tendency again.
(a)
(b)
As illustrated in Figure 16, SDNDefender shortens the first successful detection time by 15% and by 21%, respectively, compared with SLICOTS and SRL. SLICOTS judges a TCP request’s legitimacy by monitoring the completeness of the TCP three handshakes, and this process influences the timeliness of attack detection. SRL detects flood traffic by measuring both SYN requests and the number of replaced entries. This obviously increases detection time due to entries update inconsistency in switches and simplicity of flow’s hash calculation. On the contrary, SDNDefender not only measures SYN packet transmission rate but also calculates network entropy and self-similarity index in real time, and thus flood traffic can be detected fast.
Figure 17 demonstrates the variation of AFE under different situations. It is clear that SDNDefender sustains its AFE at a much lower level, because SDNDefender can quickly discern SYN flood attack and block anomaly traffic on edge switches on time. This notably decreases flow entry installations. However, SLICOTS and SRL block a source address only when its TCP illegal requests exceed the threshold. During this period, there have been a lot of flow entries in switches.
In Figure 18, SDNDefender brings a stationary variation on SYN packets’ transmission rate due to its port-based packet filtering and priority queue scheduling. Conversely, under normal SDN, the curve values continuously rise until there are a small number of flows left in the network. The main cause is that when SYN flood attacks occur, the proportion of SYN packets and ACK packets becomes seriously unbalanced. SLICOTS examines whether a TCP connection successfully establishes in a given time, and if not, this TCP request is seen as an illegal one; however, this method cannot ensure that all flood traffic is detected because those temporary flow rules expire at a given time, in which some TCP half-open connections have turned into the establishment state. For SRL, it needs to judge whether the replaced flow entries surpass the threshold after updating the SYN counter. Therefore, if SRL cannot detect the onset of SYN flood attacks in time, there will be a huge number of SYN packets in the network in several seconds.
In Figure 19, each situation’s TCP half-open connection curve steeply varies owing to the timeout mechanism of the TCP protocol. SYN flood traffic sends tremendous SYN packets in several seconds and leads the server to be busy in answering with SYN + ACK packets and waiting for ACK packets. At this moment, the server generates many new TCP half-open connections and puts them into its SYN queue. Thus, those old ones will be released from the queue once their survival time is over. It is distinct that SDNDefender enables the number of TCP half-open connections to be in a rational range because of its quick detection and efficient mitigation towards SYN flood attack. On the contrary, SLICOTS and SRL suffer from detection delays, which do not let the server spend time removing the half-open connections, so the server has to wait for the timeout of these connections.
As shown in Figure 20, SDNDefender reduces the server’s response time by 84% and by 68%, respectively, compared with SLICOTS and SRL. This is because SLICOTS and SRL have certain detection delays, and during these periods, flood traffic still largely consumes the server’s resources, so each TCP request’s round time will be much longer.
In Figure 21, SDNDefender and SRL keep their detection accuracy above 85% and 70%, respectively. However, SLICOTS’s detection efficiency descends along with the increase of attackers. The main cause is that SLICOTS judges a TCP request’s legitimacy through monitoring the completeness of TCP handshakes within the threshold time, yet this time is big enough so that more half-open connections turn into establishment state; therefore, there exists a high false positive rate.
Tables 9 and 10 show each algorithm’s TPR and FPR, respectively. We can see that SLICOTS’ FPR is much higher than that in SRL and SDNDefender. Similarly, SDNDefender’s TPR performs much better than the other two algorithms’. This is to say that real-time attack detection and detection method are two critical factors to improve detection accuracy, and the higher the detection delay is, the lower the TPR is, and vice versa.
5. Limitation
There are several factors that affect our experiments. First, we use a single testbed and a DDoS attacks dataset to carry out simulations. This experimental topology is different from practical data center environments. Moreover, real network traffic usually appears more distinct self-similarity and burstiness. These features test the network’s robustness and the SDN controller’s performance. Second, we set some thresholds for proposed algorithms in the literature to trigger detection activities. These threshold values decide detection timeliness and accuracy. Third, to simulate literature [15] we use random forest algorithm for training samples to go anomaly detection. This ML algorithm needs some explicit parameters, such as the number of a decision tree, split criterion, the max depth of a decision tree, etc. Besides these, the training sample size is also an important role in the classification process.
6. Conclusion
Despite the large number of traditional defense solutions that exist now, DDoS attacks still grow in frequency and severity. This requires an innovative network technique to address today’s challenging security threats. With the superiorities of possessing a global view and centralized control mode, SDN offers a new angle to review how this problem is solved with SDN patterns. In this paper, we present SDNDefender, a SDN-based DDoS detection and defense mechanism against IP spoofing attack and TCP SYN flood attack. SDNDefender includes two core components: Anti-IP spoofing and Anti-TCP SYN flood. Anti-IP spoofing component adopts dynamic entries that match to validate a packet’s source address and build an intrusion prevention rules library to defend those well-known attacks. Besides, the component employs a host-based anomaly detection algorithm to counter unknown attacks. Anti-TCP SYN flood component measures SYN packet’s transmission rate and once suspicious flows are detected, the component calculates the current network entropy and self-similarity index. As these metrics exceed their thresholds, the component installs entries on switches to block flood traffic and uses a DiffServ-based mitigation method to reduce attack influences on the network.
To evaluate SDNDefender in the round, we implement two group experiments. Our experimental results prove that SDNDefender outperforms other algorithms from many metrics and poses a desirable performance. In future work, we will pay more attention to the functional extension of SDNDefender and enable it to defend against some new-style attacks. At the same time, we plan to use more complex network topology and realistic traffic for security experiments.
Data Availability
The experimental results (xlsx format) of this study have been deposited in the repository (https://pan.baidu.com/s/1s36uxFEj5evsdA71oTrPrA. fetch code: xc8g).
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
The article was partly funded by National Natural Science Foundation of China under Grant no. 61702048.