An Evaluation of Systems for Detection and Prevention of DoS Attacks in SDN Networks

Software-Defined Networking is a promising architecture for routing in computer networks that divides the control plane from the forwarding functions [1]. An OpenFlow-specific protocol ensures communication across the layers. This technique, while novel, increases the risks that traditional networks often face by introducing additional vulnerabilities and security challenges [2]. Logical centralization and separation from the infrastructure layer are the main benefits of the control plane, while at the same time making it a bottleneck that can be targeted to affect the operation of the entire network. Security in the SDN environment is now a popular research field, still very open today, in particular regarding Denial of Service [2,3,4]. A DoS attack, single or distributed, can be aimed at a server on the network or at the controller itself. As previously explained, the controller interacts with the switches in a proactive or reactive manner, ie it can introduce new flow rules to the device tables, autonomously or following an explicit request. An attacker could, through a flood attack, hit the controller directly, or take advantage of the reactive mode. In fact, if the high-speed packets generate table-misses, it will be induced to send many PacketIn requests to the controller [5]. Therefore:

A switch's OpenFlow Interface (SBI) may become overloaded, as it can handle a limited number of requests to the controller per unit of time (depends on the device's typically low-end CPU).

Packets from other hosts may be dropped or delayed.

The OpenFlow channels dedicated to communication between the switch and the controller are logically separate but can share the same physical connections. A flood of requests could cause massive bandwidth consumption and congestion on the affected link, harming all hosts using it.

The high load of requests received may cause saturation of controller resources (CPU, memory, bandwidth, etc.) used for processing new rules. The interaction of the controller with the entire network would be compromised.

If the controller has handled all requests and sent new flow rules, a switch's table space could rapidly become exhausted until it overflows. Adding each new flow entry would be prevented.

While the aforementioned vulnerabilities are present, there is no doubt that SDN technology opens up new opportunities and strategies in terms of security at the same time. The characteristics of an SDN architecture can be exploited to enable, facilitate, or improve security systems, not only thanks to the possibility of easily monitoring network traffic and obtaining statistics, but also to the ability of the controller to reprogram, at any time, the routing, acting directly on the switching devices. Trivially, the controller could readily break the connection between two hosts involved in an attack (attacker and target), by adding or deleting flow rules in the tables of the involved switches. In this regard, one or more IDSs can be installed to analyze traffic, detect, and report attacks, and then solicit preventive action from the controller. In traditional networks, the traffic that can be inspected typically concerns a host acting as an IDS, or which passes through the switch it is connected to (copied via port mirroring). Because of this, the performance of a detection system depends on where and how many dedicated hosts are located. This represents a problem if the network to be safeguarded is topologically complex, in terms of costs, scalability and efficiency: the choice of the best positioning of the IDSs would in any case be constrained by the availability and, as much as possible, from foreknowledge of the potential path and target of malicious traffic, since visibility into all network traffic is often a difficult advantage to ensure. Another problem related to traffic monitoring concerns the acquisition, non-adjustable and possibly excessive, of the packages [6]. The most intricate situation is that of a network which provides, in addition to a structural complexity, high-speed traffic, which is added to that generated by any flood attacks, even distributed, that take place there. If each packet were captured to be analyzed, the traffic load to be examined could cause network congestion or hinder the reading capacity, still limited (in terms of Mbit/s), of the IDS involved, with the discarding of packages, or in any case, a decrease in performance. In an SDN network, these complications can be circumvented, since the controller it can enable some or all switches to duplicate the traffic flow, to be allocated to a specific host used for monitoring, even if not directly connected. This is possible with direct consultation of the switch tables, via OpenFlow, or with the support of a mechanism that performs traffic sampling.

Fig. 1. Traffic monitoring based on packet sampling in SDN.

By suitably configuring packet sampling, the second solution makes selective capture possible, based on preferences or on the conditions imposed by the characteristics of the network, the expected traffic rate, and the capabilities of the detection system. Ultimately, the features of an SDN network can be exploited to obtain:

• •    Real-time detection and mitigation of attacks, through traffic monitoring by the IDS and thanks to the possibility of the controller to intervene directly on network connections following a signal.

• •    The visibility of all (or partial) network traffic, with a precise or summary capture of the traffic, obtained following the choice of switches delegated to capture packets and certain sampling parameters.

• •    The scalability of the applicable systems, which can be adapted to the needs imposed by the network, the number, and resources of the IDSs used for prevention.

2.    Background

These benefits make the SDN architecture particularly prone to security Data Centers (the structures that host the servers for data processing and the provision of services on behalf of a company) and leads to a wider adoption of Cloud Computing services. They can not only be controlled remotely, but also monitored and protected in short time.

The paper is structured as follows. In Section 2, we introduce relevant aspects of SDN architecture and the main types of DoS attacks. In Section 3, we present a model to detect and prevent attacks based on dedicated protocols and services. The testbed's composition is described in Section 4, and the results of a series of experiments are presented in Section 5. In conclusion, Section 6 provides an overview of the primary outcomes of our present endeavours and highlights indications for a forthcoming study.

Software-Defined Networking is an innovative networking approach introduced to simplify network configuration and administration. In SDN architectures, routing and forwarding functions are decoupled, giving the opportunity to have direct control on network paths.

The operation and logical structure of an SDN network can be divided into three levels, as represented in Fig. 2:

Application Plane : special programs (SDN applications) communicate to the SDN controller, through one or more Northbound Interfaces (NBI), the desired requirements regarding the behavior of the network, with the possibility of obtaining the abstraction of the infrastructure and obtaining information on the devices or on the traffic.

Control Plane : a logically centralized device, the SDN controller, receives, through one or more NBI agents, the requests of the SDN applications to be communicated to the infrastructure, i.e. to the SDN Datapaths, through a Southbound Interface (SBI).

Infrastructure Plane : logical devices, the Datapath SDN, interact, via an SBI agent, with the controller, to which they expose visibility and control over the data forwarding and processing capabilities. They include one or more forwarding devices, with possible forwarding, internal processing, traffic termination functions.

Fig. 2 SDN logical structure.

The main difference between an SDN architecture and a traditional network is due to the introduction of a new element, the controller, delegated to dynamically administer the operation of the network in combination with the switching devices. The control plane should be interpreted as a centralized logical entity, which however does not necessarily involve the presence of a single physically centralized controller. Multiple control units can be installed allowing the distribution of infrastructure management, that is a scalable solution which extends the performance of the Control Plane and increase its resilience. An SDN system supports APIs capable of freely accessing resource and network state information obtained through communication between controllers and forwarding devices, regardless of topology. The applications are provided with an abstract view of the network and are enabled to configure services, routing adaptation, traffic analysis or economic management. Switching devices must lend themselves to total controllability and transparency in the interaction with the controller, and this is guaranteed by enabling the appropriate OpenFlow protocol [7]. Thus, an SDN network is not composed of ordinary routers and switches, but exclusively of special OpenFlow-enabled switches. They can be hybrid or pure, i.e., supporting either other protocols or solely OpenFlow. There are software implementations, such as Open vSwitch, that provide routers and switches with OpenFlow-and other protocols (for example, sFlow for traffic monitoring).

The Open Networking Foundation (ONF) is the organization that manages the OpenFlow protocol, defined as the communication standard between the control layer and that of forwarding. The OpenFlow architecture is presented in Fig. 3. It enables direct access to the infrastructure by allowing the controller to dictate a traffic path to the switches, establishing a dedicated OpenFlow channel with each switch. In an SDN network, traffic is interpreted as flow and each OpenFlow-enabled switch has one or more flow tables which collect the rules for the desired packet routing. Through the OpenFlow protocol, the controller can add, update, or delete a flow entry, proactively or following a request [8].

Fig. 3. OpenFlow switch main structure and processing pipeline.

An individual flow rule is identified by its match field and priority. When a packet reaches an OpenFlow switch, a lookup correspondence occurs with table elements. They are allocated in numerical series starting from 0, forming an OpenFlow pipeline. At the end of the comparison process, if there are one or more matches, all associated instructions will be executed. If no match is found, there is a table-miss, i.e. the association with a special entry that specifies how to handle the packet: it can be discarded or sent to the controller, which will tell the affected switch whether to ignore it or forward it, inserting a new flow entry. In addition to flow tables, a switch has a group table, which makes it possible to execute additional instructions associated with multiple flow entries.

• 2.1    Denial of Service

The term Denial of Service indicates a category of computer attacks, the author of which intends to make the services provided by a system inaccessible to legitimate users, with temporary or permanent effects. Compromised services can be those provided from a server (web, mail, authentication, etc.), from a generic host or from an entire network. The goal (target) is flooded with useless traffic until exhausted of resources and the impossibility of providing for the usual requests of users. In a distributed attack (DDoS), multiple hosts launch a coordinated attack directed at the same target. Interaction with the victim can be direct or indirect. In the second case, the attacker can take control of a group (botnet) of hosts (zombies), infected with specific malware, and use them to trigger distributed attacks, making defense procedures and identification of the culprits complicated. The effects of a Denial of Service are:

• -    The unavailability, in the short or long term, of a resource;

• -    Drop in the transmission capacity of the network involved;

• -    Closing active connections of the attacked host.

The most common DoS attacks in SDN are those of type flood, which leverage the issuance of many ad packages high transmission speed(throughput) putting the target's ability to manage requests into difficulty [6,9,10]. The main flood attacks are described below, and they be directed even towards a SDN.

ICMP Flood

The attacker overwhelms the target with the continuous release of ICMP Echo Request packets (ping, usually used to test connectivity between two hosts), without it being scanned, as it should be, by the receipt of the corresponding Echo Reply packets, inevitably sent by the victim. This type of attack aims to saturate the available bandwidth capacity, as well as to commit the victim to replying to the large number of requests [11].

UDP Flood

It is based on the non-connection-oriented transport protocol UDP and involves sending a large number of UDP datagrams to a port on a remote host. In case no application, which adopts the UDP protocol, is listening to the specified port (for example to port 80, usually reserved for web applications and the TCP protocol), the victim will reply with ICMP Destination Unreachable packets. This type of attack also aims to exhaust the bandwidth, rather than the internal resources of the affected host.

TCP SYN Flood

It is the best-known type of DoS attack. A TCP communication between a client and a server foresees the establishment of a connection through the three-way handshake procedure:

• 1-    The client sends a TCP SYN packet to the server;

• 2-    The server approves the request by sending a SYN-ACK packet;

• 3-    The connection is established following the sending of an ACK packet by the client.

• 2.2    Intrusion Detection Systems.

This attack involves the flood of TCP SYN packets, without sending the consequent expected ACK packets from the server. The latter maintains a data structure for each incomplete connection (for each SYN request), waiting for the receipt of the ACKs for a certain time [12]. Therefore, the internal resources of the server can be fully occupied, preventing the opening of new connections for requests from legitimate users.

HTTP Flood

Through this application-level attack, numerous connections are established following the continuous sending of more or less complex HTTP requests (GET or POST),to a web server. Like the TCP SYN Flood, the purpose of the attack is to deplete internal resources. The scale of the attack is greater if it is distributed and if the HTTP messages request access to a large amount of data from the server.

Slowris attack

Unlike the previous ones, it can exploit a low bandwidth capacity to make a server unavailable. It is usually triggered through special scripts that open multiple connections with the web server by sending HTTP requests; periodically (e.g. every 15 sec), followed by incomplete HTTP headers, unduly keeping the connections active for as long as possible; if the server closes a connection, another one is created with the same procedure. If the target has a limited concurrent connection pool, further connection attempts will be denied. The attack can be effective even when generated by a single machine.

In a computer network, the operations that allow for the recording and possibly filtering of dangerous traffic take place through firewalls and intrusion detection systems. A firewall is software capable of blocking the flow of malicious packets destined for a host or a network, by referring to predetermined rules, entered by an administrator or added following the occurrence of an event. Often, a firewall is unable to perform a thorough inspection of each packet, making protected systems vulnerable to, for example, application layer attacks. The effectiveness remains linked to rules set since alleged compromise scenarios, which can sometimes be insufficient or, on the contrary, generate false positives by blocking harmless traffic. Furthermore, a firewall can only block attacks from outside a network, it cannot prevent locally triggered attacks. In this sense, the need arises to install a second system (software or hardware) capable of actively and accurately analyzing the packets that pass through it, and of detecting attacks in real time, both internal and external, involving a network. A Network Intrusion Detection System (NIDS) is a system that generates alerts when potentially harmful traffic is observed. A Network Intrusion Prevention System (IPS), on the other hand, is also capable of attack detection, and operate by acting directly or reporting the event, for example, to a firewall which will create new rules. An IDS can be:

• i)    Based on signatures: Consult databases, libraries, signatures related to known attacks;

• ii)    Based on anomalies- Uses machine learning to create a statistically regular traffic profile, to be used for unusual traffic detection.

3.    System to detect and prevent DoS attacks in SDN

• 3.1    Monitoring.

Several defenses have been put forth to protect SDN from attacks, particularly denial-of-service attacks [13,14,15]. We now evaluate a solution for detection and prevention of DoS attacks in SDN. As represented in Fig. 4, the system is composed of one single SDN controller and one host with the Network Intrusion Prevention System installed.

The main components of this system are: i) the monitoring system, capable of traffic sampling by integration of functionalities provided by the sFlow protocol. All the network traffic is monitored both by the controller, for audit purposes, and by the IDS, responsible to identify possible attacks. Therefore, both act as sFlow collectors. ii) The Snort detection system, based on signatures, has a defensive function that is set up by a process that communicates the detected threat to the controller; iii) The SDN Floodlight controller is not only in charge of the control but also can immediately operate on network connections, with the aid of a firewall, to stop attacks from happening at an early stage.

The defensive mechanism is enabled: i) with Unix Domain Sockets, so that the relay process, which is running in conjunction with Snort, can read the alerts produced during traffic inspection from a local file, ii) with Network Sockets, so that the process sends alerts to the controller.

Fig. 4. The proposed system.

As it was explained in earlier chapters, in an SDN network, the controller can interface with switches to manage routing, adjust flow tables, and gather statistics for traffic monitoring. Through the open-source protocol OpenFlow, the controller can periodically request information about the incoming flow from the switches. The data can be requested and interpreted by specific SDN applications. This operation involves the acquisition of all the flow entries owned by the switches and the consultation of the relative counters [16]. They are updated following each forwarding operation when there is a match between a packet received and a specific flow entry. The controller can know the status of a flow table (assuming that each switch has a single flow table) and therefore the data related to the flow by sending a StatsRequest message to a switch. As a result, the switch replies with a StatsResponse message, providing a block of data associated with all elements of the flow tables. A block contains portions of the flow entries with the respective packet counters. The counters indicate the total number of packages received and matched, starting with the presence of the flow entry in the table. However, for the observation of traffic behavior over time, it is advisable to have knowledge of the number of packets acknowledged since the last acquisition. For this purpose, a copy of the previous state of the flow table must be kept evaluating the variation of the counter values, thus obtaining the actual number of packets received in the last time frame. Using the OpenFlow-based statistics collection method, it is possible to detect and analyze the entire network traffic passing through the switches in a detailed way since no selective action is foreseen.

This approach can be convenient for monitoring SDN networks with low to medium traffic volumes, but it can be problematic if network traffic starves a lot of bandwidth capacity, possibly resulting in distributed DoS flood attacks. Such circumstances are not suitable for the exact acquisition of traffic data, as they can compromise the correct functioning of the network (and of the detection of installed system), leading to the consequences introduced in Section 1. In particular, the negative effects can be link congestion, overflow of data structures held by switches, and the IDS inability to handle an excessive amount of packets.

• 3.2    Traffic sampling: the sFlow Protocol.

To optimize the monitoring process, the packets passing through the switches (all or a group of them) can be captured at a certain sampling rate. In this regard, different approaches can be undertaken, but for the proposed detection system, the choice fell on the integration of the sFlow protocol. It is a standard, maintained by sFlow.org, that can be used for monitoring fast packet-switched networks. Using sFlow, all or part of the network switches can be designated as 'samplers', or rather, sFlow agents. They capture packets at a defined sampling rate and at a certain polling rate. When a packet arrives at a device, following the process of matching flow table elements, a forwarding decision is made, and the packet is assigned to a certain output port. At this point, it is decided whether to capture the packet. This procedure involves a counter, which is decreased for each parquet received. When the counter reaches zero, the packet is collected. The counter value is then reset to a random integer. The sequence of random values from which the count begins depends on the sampling frequency. Sampling Rate = Total_Packets / Total_Samples, being Total_Packets all the packets received, and Total_Samples the number of those sampled, for each interface. These values are taken whenever the time specified for polling has elapsed. For this, sFlow sampling has two approaches: one is random for packet capture, the other is periodic for meter reading. The sampled data is converted to sFlowdatagrams, or UDP packets, destined for one or more hosts chosen for monitoring, called sFlow Collectors, and sent to the appropriate port 6343.

A collector can have either the role of an IDS, dedicated to traffic inspection to report any threats, or a generic monitor capable of processing the data received at the application level so that the trend of network traffic can be observed in real time.

sFlow is widely supported by many switches that can be OpenFlow-enabled. The two protocols operate by offering complementary functions without interference, as depicted in Fig. 5. Therefore, the traffic capture procedure and the forwarding procedure are untied. This way, OpenFlow is not used for the collection of the statistics, and access to the counters present in the flow tables is thus avoided.

Fig. 5. Separation of OpenFlow and sFlow functions.

sFIbuu

With sFlow, the impact of monitoring is undoubtedly less, as the traffic is sampled according to adaptable parameters. In particular, the sampling rate can be suitably fixed. Given the number of packets, N, they are randomly sampled with a probability of 1 out of N packets. Thus, the sampling rate increases as N decreases. By increasing the value of the sampling rate, more precise traffic capture is ensured. However, by choosing an excessive value, some problems can arise, as indicated above, due to: i) Network overhead: the sampled traffic, forwarded to one or more sFlow Collectors, including the IDS, could cause congestion and interfere with regular flow circulation. Therefore, the 'additional' traffic load must be weighted; ii) limited IDS reading capability: The detection system may not be able to analyze too many incoming packets without discarding some.

Especially for large-scale networks, some criteria can be adopted to select the optimal sampling rate [7]. They require knowledge of parameters such as the number of switches, the capacity of the IDS, the expected traffic rate for the network. Another deciding factor may be the number and location of hosts with Intrusion Detection functionality that are required [17].

Fig. 6. Flow information matrix example.

For example, let the capacity of the IDS be known, in bits/s. Suppose, furthermore, that we know which traffic flows cross the network switches and the exploited bandwidth. A flow information matrix M = [m ,j ] can be built, where each elemenm ,j t is a binary number: it is set to 1 if the i-th flow crosses the j-th switch, otherwise is set to 0. An example is presented in Fig. 6. Let r = [r , ] be the flow-rate vector and A = [dy] be the matrix associating the elements of M and r, where a^ = r , • т^:

Finally, let x = [X j ] be the sampling rate vector to be assigned to the switches (sFlow Agents). Then, if X j = i c c

• • #—Tcft, the switches do not have the same sampling rate but produce the same sampled traffic load. If X j = —, all switches have the same sampling rate, but the sampled traffic load is proportional to the total throughput of the flows they are affected by. These are possible choices of sampling probability, but even more careful approaches can be followed.

• 3.3    Controller.

Based on these needs, the configuration of each switch can be further diversified, for example when it is possible to differentiate the potential entities of the traffic flows (malicious or normal) [17]. If you want to avoid using all the switches, you can resort to algorithms for choosing how many and which devices to use as sFlow Agents (sampling points). In this way, the risks of saturation of network resources and of the detection system are further reduced. The decision-making techniques are varied, but insights in this regard are beyond the objectives of the study. For the experimentation of the proposed system, a virtual network with modest topological complexity has been created for demonstration purposes. In this case, as will be seen, all the switches were used with a sampling probability of 1 out of 50. The choice of the parameter has practical reasons which will be clarified in the dedicated paragraph.

The proposed system relies on two sFlow collectors for monitoring purpose. The first is the SDN controller, in which an application is installed and allows the visualization of traffic trend (in graph form) in real time, to support the network status verification at user level. For example, an administrator can check the traffic flows exchanged between hosts and see the onset of anomalous situations. The second collector is the IDS: it receives the sampled traffic to inspect it, in order to detect attacks in progress. InMon Corporation, recognized as the originator of sFlow, provides special tools that implement the above features. Respectively:

sFlow-RTis an open source platform that provides real-time visibility into SDN network status. The sFlow-RT analysis engine receives the traffic captured by the sFlow Agents and converts them into measurements or graphs, accessible via REST API and a Web GUI. The sFlow-RT applications, available on GitHub, are easily installed via command line.

sFlow Toolkitconsists of a command-line utility that interfaces with programs such as tcpdump , ntop and Snort for detailed analysis of captured packets. In the case of the proposed system, it is of primary importance, as it converts the collected data (sFlow Datagrams) into a format compatible with the reading process of the IDS Snort

The Intrusion Detection System used into the proposed system relies on Snort based on signatures. Snort is an open source software, released by Cisco Systems, capable of performing real-time traffic analysis on IP networks[18]. In this regard, Snort uses legacy packet capture library to log traffic. These logs can be used to replay captured traffic and test the performance of the detection system. The main components of Snort are: a detection engine that uses a modular architecture (Snort Engine) and a series of rules (signatures, Snort Rules) for traffic interpretation. The rules are used to recognize, and therefore signal, a specific anomalous situation. The main advantage of Snort is the vast community of users that keeps the set of signatures (Community Rules) updated, free and accessible by every consumer. When an attack occurs, and therefore the detection of a condition indicated by a As a rule, Snort can act as an IDS reporting the event, in the form of an alert, on the console or in a log file. Alternatively, Snort can act as an IPS by signaling the event externally. In the case of the proposed system, the functionality was exploited which provides for the writing of alerts on a local file, shared with another process via Unix domain socket. A local socket, similarly to what happens for a network connection, allows the exchange of data between processes running on the same host. Therefore, a second process (called relay), simultaneously running, it will read the alerts reported by Snort and signal them, via network socket, to the controller. The implementation of the relay process will be described in the next paragraph, while the methods of using Snort will be illustrated in the chapter on experimentation.

The prevention mechanism is implemented with the support of a process, executed together with Snort, which acts as an intermediary for signaling alerts between the IDS and the SDN controller. The relay process is started by executing a script written in Python.

The controller is based on the SDN Floodlight controller, which is part of an open source project involving a large community of developers [20]. It is entirely programmed in Java and supports all versions of OpenFlow. Floodlight has an architecture structured in modules, which implement not only the typical SDN control functions, but also user-level applications that provide network management services. The latter include REST APIs, i.e. interfaces through which they can communicate between them or outbound through the exchange of HTTP messages. Floodlight has the advantage of being easily adaptable or improved by adding new modules. This feature has been exploited for the creation of a defense mechanism. In Floodlight there is a module that implements the firewall function. It is based on the insertion of ACL (Access Control List) rules to set conditions that can allow or deny the flow of traffic destined for a switch.

4.    Testbed

We developed a simulation environment to evaluate the performance of the proposed system, reproducing a real-world scenario. A virtual SDN network is created with the integration of the components described above, and both normal and malicious traffic is generated on this network.

The entire simulation was carried out on a single computer, in an operational environment of Ubuntu Desktop 18.04 , on which were installed and configured the Floodlight controller, sFlow-RT package, and a software for graphical and real-time traffic analysis. Thanks to the installation of the Mininet emulator, it was possible to create a virtual SDN network consisting of 12 hosts and 7 managed switches, via a remote connection and the OpenFlow protocol, from the Floodlight controller. Virtual hosts are used to generate simple web traffic, or a distributed attack directed to the server.

The other three special hosts have been added through the installation of as many virtual machines with different operating systems and well-defined roles:

VM 1: Snort NIDS : The Snort-based detection system is installed and configured on a virtual machine with Ubuntu Desktop 18.04, with the aim of monitoring all network traffic, detecting attacks, and reporting them to the controller.

VM 2: External Attacker : The Parrot Security OS is installed on the second virtual machine, which offers various pentesting tools with the aim of generating single attacks directed at the server.

VM 3: Vulnerable Web Server : the third virtual machine plays the role of target [21]. It is configured with Metaspoitable2, an OS whose server services are intentionally vulnerable for pentesting purposes. Also, the popular Apache2 web server based on Ubuntu Linux is installed.

We now present the topology and the tools used for the creation of the experimental network, including the description of the virtual machines and the sFlow configuration for traffic sampling.

Mininet is an open-source emulator that makes it possible to virtualize a network of hosts, switches, and links on a single Linux kernel-based OS [19]. Scripts in Python allow the creation and configuration of networks with customized and flexible topologies. Mininet has a GUI (MiniEdit) that allows you to view a topology, create a new one, and run or export the associated script. The topology designated for the testbed is showed in Fig. 7:

Fig.7. Network Topology designed with MiniEdit.

In accordance with the needs of SDN, each virtual switch is OpenFlow-enabled and connected to the controller through a dedicated channel. Each switch is configured as an Open vSwitch in kernel mode.

Open vSwitch is an open source software implementation that provides support for the protocols OpenFlow 1.3, for control, and sFlow, for traffic sampling. The controller is set as remote, indicating the address 192.168.56.1 and port 6653.

All links have bandwidth fixed at 100 Mbit/s. Bandwidth limitations are convenient since Open vSwitches share CPU and memory resources and typically have lower performance than dedicated switches. To complete the configuration, it is necessary to use, in addition to Mininet, the VirtualBox software and the utility ovs-vsctl for adding virtual machines and managing Open vSwitches.

To connect the 3 virtual machines to the SDN network simulated with Mininet, it is necessary to add as many virtual interfaces as will be used by switches s1, s2, and s7:

VM 1 is connected to the eth1 interface of switch s1;

VM 2 is connected to the eth2 interface of switch s2;

VM 3 is connected to the s7 switch's eth3 interface.

Virtual machines are created with Virtualbox, the controller is connected to switch s1 through vboxnet0. The vboxnet0 interface address, which identifies the controller within the network, is 192.168.56.1. The role of the controller DHCP server is also associated with assigning addresses to hosts on the network. While for virtual machines the assignment is automatic, each Mininet host will be able to request an IP address via the DHCP protocol by executing the dhclient command via the terminal. This procedure guarantees connectivity between each element of the network.

As described in previous chapters, the sFlow protocol allows sampling of packets forwarded by switches, making it possible to monitor all network traffic by a host, called the sFlow Collector . The sampled packs are collected in sFlow datagrams , i.e., UDP packets that are transmitted to port 6343 of the collector.

All switches in the network are used as sFlow agents , or samplers.

ovs-vsctl -- --id=@sflow create sFlow tarqet=\ "192.168.56.1:6343\" .V 192.168.56.101:6343\ f samplinq=50 pollinq=10 header=128 -- set Bridge s6 sftow=@sflow -- set Bridge s4

sflow=@sflow -- set Bridge s5 sflow=@sflow -- set Bridge s3 sflow=@sflow -- set Bridge s7

sflow=@sflow -- set Bridge si sflow=@sflow -- set Bridge s2 sftow=@sflow

Fig.8. sFlow Integration.

The packets sorted by the switches are set to sampled = 50 and polling = 10.

This means that the packets are sampled with a probability of 1 in 50, and every 10 seconds, the counters associated with the devices are detected. As explained earlier, the choice of the sampling rate depends on factors such as network complexity, the expected traffic load (in terms of transfer rate), the ability of the IDS to read packets, or the type of attack expected. A high sampling rate value would ensure good performance by the IDS, especially in detecting flood attacks, but would avoid reading a large number of packets, possibly necessary to detect low-bandwidth attacks.

Fig. 9. Network Topology shown on Floodlight Web GUI

A lower value of the sampling rate would guarantee good visibility of the traffic with the collection of a greater number of packets, but could put the reading capacity of the IDS under strain, compromising its performance. In the case study, the value 50 for the sampling rate was adopted following several tests carried out on Snort's reading and detection abilities and represents a good compromise for observing the attacks tested in the experiment, i.e., flood attacks and the low-bandwidth Slowloris attack. This was possible thanks to the simplicity of the network devised, whereby values even 10 times greater than the one adopted determine insignificant performance differences. For more complex networks, it is possible to use special algorithms for choosing the sampling rate, as suggested in previous section, the application of which goes beyond the scope of the discussion. As collectors are indicated on the controller, where sFlow-RT is installed for the graphical analysis of the traffic, values even 10 times greater than those adopted determine neglected performance differences.

Following the steps described, it is possible to start the Floodlight controller and sFlow-RT. Through the dedicated Web GUI, the correct functioning of the network is verified.

Fig.10. Network Traffic, generated by using httperf, shown on sFlow-RT GUI

5.    Experimental Results

For attack detection, Snort can leverage the set of rules made available by the community. However, to get specific attack detections and alerts we added custom rules. A Snort (signature) rule is for instance:

alert tcp any any -> $HOME_NET 80 (msg:'Possible TCP SYN Flood Attack'; flags: S; flow: stateless; detection_filter: track by_dst, count 100, seconds 10; sid: 1000001)

This rule generates alerts in the event of a TCP SYN Flood attack.

The attack is detected if 100 TCP SYN packets are intercepted in 10 seconds. The count is for each different destination IP address. Although the number to count may seem small, it must be considered that the packets processed by the IDS are those obtained through sampling. The stateless option for the flow keyword indicates that the rule will be applied regardless of the state of the TCP session. The choice depends on the type of attack; for example, in a Slowloris attack, the periodic sending of incomplete HTTP requests requires that TCP connections to the server be regularly established. A new specific Snort rule has been added for each attack type evaluated for experimentation with a structure more or less like that of the example, except for the HTTP Flood. The large number of HTTP requests sent at high bandwidth in fact requires the opening of numerous connections by sending TCP SYN packets. For this reason, although the dynamics of the attack are more complex, they are also detected thanks to the generation of the alert associated with the rule described above, introduced for the TCP SYN Flood. After writing, the rule is inserted in the Snort configuration file. The other file to edit is the one related to the threshold :

event_filter gen_id 0, sig_id 0, type limit, track by_dst, count 1, seconds 5

When the relay process is active, alerts generated by Snort are communicated to the controller. In the event of a new attack, the controller may still be busy reading alert messages or creating firewall rules for an already thwarted or terminated attack. Through this setting, you decide to provide only one alert in output, every 5 seconds, for each different type of alert. This setting is important because it allows enough alerts to be sent to the controller in the event of an attack, but not too many to overload reading.

• 5.1    Traffic generation.

A traffic generation mechanism is needed to evaluate the effects of the proposed attacks. The Metaspoitable2 server provides various web services. In this case study, the effects of attacks based on login attempts, coming from multiple hosts on a web page, were examined. Six hosts were used for the generation of regular web traffic.

VM 2 (Parrot Security) was used to trigger single attacks on the server, while the use of three Mininet hosts served to recreate scenarios of distributed attacks.

Web Traffic

The generation of synthetic web traffic relies on the popular httperf. On each client, the traffic is set with the following parameters:

The --server option indicates the target of HTTP GET requests (HTTP/1.1) to access a given resource. The --client option specifies the sequential number of the client out of a total of six clients accessing server resources via httperf, thus avoiding the generation of an identical traffic pattern.

The --wsess option specifies the number of TCP sessions, the number of requests, and the interval in seconds between each request. Specifically, each host initiates a unique TCP session (persistent), through which it sends 5 HTTP requests to the server (1 req/s), receives response messages from the server, and closes the connection.

Since the generation must take place continuously and from multiple hosts, this choice reduces the number of connections with the web server. The --timeout option allows you to specify the amount of time to wait for a response from the server. If within this time the server is not responding, the connection attempt is considered failed, the connection is closed, and a specific error is shown in the final statistics. This option is important, as it allows you to capture the change in the server's responsiveness when under attack. The --uri option indicates the path to the specific server resource. Other options can be used to indicate, for example, other HTTP methods or accessing multiple different URIs. At the end of each httperf execution, statistics are shown.

The most relevant information is denoted by Net I/O. It shows, in KB/s, the actual input and output throughput. This value is calculated based on the number of bytes sent and received in the TCP connection with the server and tends to decrease in the event that the server is under attack. When the web server does not respond promptly to requests within the 10s timeout, the client-timo error is set to 1. The Linux watch command has been used to ensure that traffic, i.e., connections to the server by host, is generated continuously. Each of the six hosts initiates a connection every 30s. In this way, on the terminal of each host, it is possible to verify, from time to time, the change in throughput.

The 'continuity' of the traffic is necessary for the times of progressive data collection, operations to simulate an attack or start of the IDS, and appreciation of the throughput variations and of the traffic load itself. Despite this, the result can be considered effective 'normal' web traffic, which does not compromise server availability in a harmful way and is solicited with short connections and not excessive requests, for example, web pages of just over 200 KB. To simplify data collection, the output can be transferred to a text file (one for each host). In a regular context (where the server is not under attack), there are no connection failures due to timeouts, and the observed throughput maintains an average of 63.8 KB/s.

• 5.2    Attacks.

For the generation of the main flood attacks (ICMP, UDP, and TCP SYN), the tool hping3 is employed , while special Python scripts are used for the HTTP Flood and the Slowloris attack. The effects of the attacks on server performance, measured by the change in I/O throughput over time, are shown below.

The results are collected in tables and graphs and presented in the following subsections. The symbol * indicates a connection failed and closed due to timeout. In this case, the client-timeout error is set to 1, whereas the throughput shown by httperf is 0.0 KB/s.

ICMP Flood (Distributed)

The command that triggers an ICMP flood is:

hping3 -1 --flood 192.168.56.102

It allows the generation of ICMP Echo Request packets at full bandwidth. A single attack does not prove to be particularly effective; rather, a distributed attack can compromise the response capacity of the server in a short time. For this reason, we have chosen to show only the data related to the case of a distributed attack.

CO

Start     30s      60s      90s     120s

	I/O Throughput (KB/s) Test time: 2 mins after begin of attack
Hosts	start	30s	60s	90s	120s
h1	63.8	9.3	*	*	*
h2	63.8	*	*	10.2	*
h3	63.8	20.5	*	*	*
h4	63.9	*	14.7	*	*
h5	63.9	15.4	*	*	*
h6	63.7	*	*	*	*

Fig.11. Distributed ICMP Flood effects on web traffic.

UDP Flood (Distributed)

The command used for the UDP flood is:

hping3 -d 50 -i u1000 --udp -p 80 192.168.56.102

It causes a millisecond UDP packet to be sent with a 50-byte payload.

Also, in this case, the results shown refer to the distributed attack only.

	I/O Throughput (KB/s) Test time: 2 mins after attack starts
Ho sts	star t	30s	60s	90s	120 s
h1	63. 8	62. 7	36. 4	*	*
h2	63. 8	58. 4	36. 5	*	*
h3	63. 6	60. 1	*	*	*
h4	63. 9	62. 8	37	*	*
h5	63. 5	44. 9	40. 4	*	*
h6	63. 7	62. 6	55	*	*

Fig.12. Distributed UDP Flood effects on web traffic

TCP SYN Flood

To simulate a TCP SYN Flood we typed the command:

hping3 -S -d 30 -i u2000 -p 80 192.168.56.102

It triggers the sending of TCP SYN packets with 30 byte payloads, one every 2 ms. In this case, both the effects of a single attack and those of a distributed attack are proposed.

SINGLE ATTACK

Fig.13. TCP SYN Flood effects on web traffic

	I/O Throughput (KB/s) Test time: 2 mins after attack starts
Hosts	start	30s	60s	90s	120s
h1	63.9	22.9	*	22.4	*
h2	63.9	50.3	*	50.6	*
h3	63.7	50.3	*	50.3	43.4
h4	63.8	*	46.7	22.9	*
h5	64	21.6	22.9	36.3	39.9
h6	63.9	50.9	*	45.2	*

DISTRIBUTED ATTACK

	I/O Throughput (KB/s) Test time: 2 mins after attack starts
Hosts	start	30s	60s	90s	120s
h1	63.9	21.1	*	*	*
h2	63.8	51.2	*	*	*
h3	63.7	53.6	51.1	*	*
h4	63.9	31.3	16.6	*	*
h5	64	63	*	*	*
h6	63.8	31.1	*	*	*

Fig.14. Distributed TCP SYN Flood effects on web traffic

HTTP Flood

SINGLE ATTACK

ш

* 30

Start     30s      60s      90s     120s

	I/O Throughput (KB/s) Test time: 2 mins after attack starts
Hosts	start	30s	60s	90s	120s
h1	63.8	56.6	50.9	43.5	22.1
h2	63.8	58.9	39.3	21.9	14.5
h3	63.9	50.5	34.9	28.5	22.7
h4	64	49.9	31.9	24.8	9.4
h5	63.9	49.8	38.9	24.8	*
h6	63.9	56.5	48.3	44.7	*

Fig.15. HTTP Flood effects on web traffic

DISTRIBUTED ATTACK

Start     30s      60s      90s     120s

	I/O Throughput (KB/s) Test time: 2 mins after attack starts
Hosts	start	30s	60s	90s	120s
h1	63.7	31.1	*	20.5	*
h2	63.8	29.4	40	27.1	13.8
h3	63.9	28.5	*	20.4	19.7
h4	63.8	28.8	37	25.9	18.4
h5	64	37.5	17.6	24.9	*
h6	63.8	38.8	20.5	28.9	*

Fig.16. Distributed HTTP Flood effects on web traffic

Slowloris

A dedicated script was employed to generate the Slowloris low-bandwidth attack. It opens many connections with the server, kept alive periodically by sending incomplete HTTP headers (every 15s). It is possible to set the maximum number of TCP sockets to open (e.g., 500). In this case, a single host can cause rapid and dramatic effects on server availability.

ш

* 30

Fig.17. Slowloris effects on web traffic

	I/O Throughput (KB/s) Test time: 2 mins after attack starts
Hosts	start	30s	60s	90s	120s
h1	63.6	23.9	*	*	*
h2	63.7	*	*	*	*
h3	63.9	*	*	*	*
h4	63.9	*	*	*	*
h5	63.8	12.1	*	*	*
h6	63.9	*	*	*	*

• 5.3    Detection

• 5.4    Mitigation

A first step towards the creation of a defensive strategy, is the attack detection [20]. A solution can rely again on Snort, that is provided with the sFlow tool for translating sample packets:

Using the -A console option, the alerts are listed on the console, as reported in Fig. 18. They can also be reported progressively in a log file. For each alert, the type of attack or anomaly can be read, as well as the date and time of detection, and the source and destination IP addresses of the attack. Alerts are generated according to the frequency set in the threshold file.

A further step to create a defensive strategy is to cope detection tools with a system to prevent and mitigate the effect of DoS attacks [21,22,23]. We here tested a mitigation solution based on a python script that starts a process concurrently with Snort. Using the -A unsock option on the Snort start command, the generated alerts are recorded to a local file (snort_alert), which will be read by the relay process via Unix Domain Sockets. Every read alert is converted

Fig.18. Mitigation of a distributed TCP SYN Flood attack.

into a specific alert message for the controller, which is subsequently included in the corresponding Floodlight firewall rule. An example of this rule is showed in Fig. 19. In Fig.20 we present the response of the tested system with respect to different attacks, both from single or distributed sources. On the left-hand side of the graphs, the effect of mitigation is shown with respect to a single-source attack, while the right-hand side of the graphs reports the results in the case of distributed attacks. In both cases, the graphs indicate the time of detection activation as well as the time required for mitigation.

Fig.19. Examples of rules added to firewall.

Single attack

Distributed attack

ICMP Flood

a)

b)

UDP Flood

c)

d)

TCP SYN Flood

e)

f)

HTTP Flood

5s               45s

g)

h)

Slowloris

i)

Fig.20. Prevention and mitigation to different attacks.

6.    Conclusion

The study carried out is focused on Software-Defined Networking, an emerging routing architecture that separates the control plane and the forwarding plane. To exploit the full potential of this technology as a solution for the management of Data Center and other Cloud centered applications, it is important to verify the SDN vulnerabilities. Here we examine some possible SDN weaknesses and survey the solutions for detecting and preventing DoS attacks. For this purpose, an environment was implemented for simulation in which it was possible to generate regular traffic (requests to a web server) and recreate DoS attack scenarios, single or distributed. First, the effects of different types of attacks on network connections were observed. After that, the effectiveness of the proposed system was evaluated, monitoring the progressive mitigation of the attacks, and measuring the timing of the defensive action. The main components on which the studied solution is based are the monitoring system, which relies on the sFlow protocol; the signature-based IDS Snort; and the Floodlight controller, which can rely on an internal firewall to directly intervene on the connections. While the obtained results are compelling, they represent a preliminary experiment that can undoubtedly be expanded upon. Alternative attack techniques, not only based on DoS-type, can be considered (e.g. MITM, port scanning, ARP poisoning, password attacks). In this regard, using Parrot Security for pen testing may be advised, and the Snort rule set utilized may be increased correspondingly. Moreover, an anomaly-based intrusion detection system (IDS) that leverages machine learning could be included for a more meticulous detection approach that can identify and intercept even unclear unusual circumstances. In certain situations, the suggested remedy might not be effective. An obvious example would be if IP spoofing is employed, as the controller needs to know the attacker's real address to terminate connections (Snort detects and reports this address). In conclusion, this experience focuses on some vulnerabilities of the SDN network and evaluates possible solutions to prevent attacks, thus increasing the system's robustness and exploiting its full potential.

Acknowledgements

This work has been completed with the relevant support of ing. Salvatore Criscuolo, who managed the creation of testbed and the execution of the experiments.