A Detailed Inspection of Machine Learning Based Intrusion Detection Systems for Software Defined Networks

Abstract

The growing use of the Internet of Things (IoT) across a vast number of sectors in our daily life noticeably exposes IoT internet-connected devices, which generate, share, and store sensitive data, to a wide range of cyber threats. Software Defined Networks (SDNs) can play a significant role in enhancing the security of IoT networks against any potential attacks. The goal of the SDN approach to network administration is to enhance network performance and monitoring. This is achieved by allowing more dynamic and programmatically efficient network configuration; hence, simplifying networks through centralized management and control. There are many difficulties for manufacturers to manage the risks associated with evolving technology as the technology itself introduces a variety of vulnerabilities and dangers. Therefore, Intrusion Detection Systems (IDSs) are an essential component for keeping tabs on suspicious behaviors. While IDSs can be implemented with more simplicity due to the centralized view of an SDN, the effectiveness of modern detection methods, which are mainly based on machine learning (ML) or deep learning (DL), is dependent on the quality of the data used in their modeling. Anomaly-based detection systems employed in SDNs have a hard time getting started due to the lack of publicly available data, especially on the data layer. The large majority of existing literature relies on data from conventional networks. This study aims to generate multiple types of Distributed Denial of Service (DDoS) and Denial of Service (DoS) attacks over the data plane (Southbound) portion of an SDN implementation. The cutting-edge virtualization technology is used to simulate a real-world environment of Docker Orchestration as a distributed system. The collected dataset contains examples of both benign and suspicious forms of attacks on the data plane of an SDN infrastructure. We also conduct an experimental evaluation of our collected dataset with well-known machine learning-based techniques and statistical measures to prove their usefulness. Both resources we build in this work (the dataset we create and the baseline models we train on it) can be useful for researchers and practitioners working on improving the security of IoT networks by using SDN technologies.

1. Introduction

Nowadays, there is a big need for a gradual development in networking in order to facilitate the rapid advances in technologies. For example, the explosion in mobile device technologies, server virtualization techniques, and cloud services are no longer efficiently supported by the traditional network architectures, which are hierarchical arrangements in a client-server model [1]. In fact, multiple clients and multiple servers are required by today’s applications, which access different databases and services in different domains. In general, there is a need to access applications and other resources on demand. Moving from traditional networking to software-defined networking (SDN) is one advance that overcomes the limitations and challenges of traditional networking approaches.

SDN is the most suitable architecture for the high-bandwidth and dynamic nature of today’s applications. SDN has advantages over other architectures by being cost-effective, adaptable, dynamic, and manageable. The network control in SDN is directly programmable and the underlying infrastructure is abstracted for the network applications and services [2,3]. The control plane and the data plane are decoupled in SDN. The control plane is responsible for where to send the traffic, whereas, the data plane is responsible for executing the decisions of the control plane.

Although SDNs have the advantages of providing fine-grained control of traffic, improving drawbacks and solving security issues in traditional networks, they introduce their own security issues that must be addressed [4].

Internet of Things (IoT) is an emerging technology where billions of devices are connected to the Internet. IoT systems are rapidly spreading in almost all areas of our lives, including finance, government, military, agriculture, and many different industrial sectors [5]. Generally, IoT devices are equipped with human and physical interfaces such as wireless sensors, actuators, and RFID tags [6]. These devices generate and transmit large amounts of data over the Internet, which leads to serious cybersecurity challenges in securing IoT systems against malicious attacks [5]. The IoT architecture comprises a perception layer which includes the physical devices, a network layer for data transmission, and an application layer of the user applications and services [6].

Moreover, IoT systems have a dynamic nature in the sense that they are growing very fast as more and more devices are introduced and join the IoT network every day. This dynamic nature and the exposure of the IoT devices to a wide range of communities highly increase the threats effects and levels such that it may lead to loss of human life, electricity and nuclear power hacking, and even national intelligence hacking [7]. Therefore, there is a big need for proper infrastructure to meet the secure requirements of the IoT. Traditional networks are not the best choice because of their limitations. Hence, integrating SDN with IoT (SDN-IoT) becomes of big interest as SDN provides the best debugging tools to enhance the security of any IoT environment [6]. The main goal of this integration between the SDN and the IoT is to utilize the advantages of SDN, over the traditional networks in controlling and managing IoT devices. In fact, SDN-IoT enables the environment for an automated management and monitoring of IoT devices and provides the flexibility and controllability of the software applications running on those devices [8,9].

One approach to protect networks against attacks is to employ intrusion detection systems (IDS). Based on the strategy followed in attack detection, IDSs are categorized into two types: signature-based and anomaly-based detection. The signature-based detection cannot recognize new attacks due to the fact that it compares new traffic data with pre-recognized intrusions. However, it is the most used commercially. On the other hand, using machine learning, anomaly-based detection is capable of detecting new attacks that have never been seen before. It reports the deviation of new traffic data from normal user behavior as an anomaly [10].

Anomaly-based IDSs are categorized into either statistical-based, knowledge-based, or machine-learning-based. Each category has its own advantages and disadvantages [11]. A statistics-based IDS employs statistical metrics like mean, median, and standard deviation of the packets. It marks the detected low-probability events as potential intrusions based on a distribution model for normal behavior profiles. On the other hand, the knowledge-based IDS, which is also known as the expert IDS system, reflects the legitimate traffic profile such that an intrusion is defined as the action which deviates from this standard profile. Given that the system has knowledge about all the normal behaviors, knowledge-based IDS has the capability of reducing false-positive alarms. Finally, machine learning is the process where knowledge is extracted from huge amounts of data by applying several techniques such as clustering, neural networks, and decision trees. In general, the machine learning techniques are categorized into supervised, semi-supervised, and unsupervised, where the characteristics of the data and the nature of the application play the main role in choosing the proper category [12].

Machine learning shows noticeable success in many fields including pattern recognition, natural language processing, and computer vision. Employing machine learning in IDSs increases the detection accuracy and efficiency as IDSs that are based on machine learning learn from large amounts of data and adapt to the strategies of attacks [5,13,14,15].

A robust and comprehensive dataset presents a key component in IDS exploiting machine learning for network security. The variety of traffic data in the dataset, where both normal and malicious behaviors exist, highly affects the learning efficiency [13]. On the second hand, the features that are extracted and selected from the dataset and the way they are extracted are very important as they specify the relevance of the information that is extracted from the traffic data [13,16]. Many machine learning algorithms already exist, such as support vector machines, random forests, and neural networks, each with their advantages and disadvantages. Choosing the most suitable machine learning algorithm is a non-trivial process that depends on many factors including the size and nature of the available data, the available resources, the complexity and desired performance of the resulting system (including effectiveness and efficiency) [13].

This work aims at building a testbed environment in an SDN topology in order to generate multiple types of Distributed Denial of Service (DDoS) and Denial of Service (DoS) attacks on the data plane hosts. All of the packets and the flows are then gathered in a new dataset that includes illustrations of attacks, both benign and suspicious, that can take place on the data plane of an SDN-IoT architecture. The collected dataset can be utilized in designing IDSs for SDN-IoT systems. To demonstrate the usefulness of our datasets, we carry out an experimental evaluation using different machine learning algorithms, as well as statistical metrics to evaluate their performance.

In summary, the contributions of this work can be listed as follows:

• An extensive benchmark dataset of DoS and DDoS attacks on SDN-IoT networks.
• A set of baseline machine learning models trained and tested on the benchmark dataset.

By making them publicly available, we hope that the resources we build in this work can be useful for both researchers and practitioners. Specifically, the dataset can be used to build or enhance models for detecting DoS and DDoS attacks on SDN-IoT networks. It allows for benchmarking of such models. Finally, the baseline models we have built can be integrated into a development cycle allowing for them to be deployed quickly.

The rest of this paper is organized as follows. Section 2 provides a survey of the related work. Section 3 presents the methodology for collecting and utilizing the dataset in IDSs. Section 4 talks about the collected dataset and the extracted features. The experimental results are provided and discussed in Section 5. Finally, the paper is concluded in Section 6.

2. Related Work

A vast amount of research work that addresses the topic of IDS does exist in the literature. Some of these works are based on ML algorithms and some are not. Some of these works are focused on IoT where SDN is utilized to enhance the management, the security, the flexibility, and the controllability. On the other hand, there exist works that do address the dataset collection to be utilized for building IDS.

2.1. General IDS Works

Intrusion detection and prevention systems integrate intrusion detection and prevention technologies. Intrusion prevention is developed as a goal of research into the flaws in intrusion detection. Intrusion detection arises from a threat model as discussed in [17].

By offering a model for detecting suspicious activity in computer systems, the work in [18] establishes the fundamentals for intrusion detection systems. External penetrations, internal penetrations, and misfeasance are the three types of risks that are identified. The work develops an anomaly-based user behavior monitoring system based on these three kinds of risks. This paradigm is founded on the premise that by studying the audit logs of any system, security breaches can be recognized and monitored. Profiles, metrics, statistical models, and procedures for evaluating logs are all part of the concept.

The work in [19] represents a technique that is still in use today as the fundamental for any general-purpose expert system in intrusion detection.

The collaborative intelligent intrusion detection system (CIIDS) in [20] combines the two basic approaches used in intrusion detection and prevention systems. Current challenges to collaborative intrusion detection systems and the algorithms they use for alert correlation are examined and addressed. The work also provides new techniques to minimize the false positive while optimizing the accuracy of the detection mechanism.

In Valeur et al. [21] and Wu and Banzhaf [22], the target is to synthesize the research conducted in intrusion detection up to this point and provide a jumping-off point for future work. On the other hand, the authors of [23] provide an introduction to intrusion detection systems, from the foundations of how they work to the methods they employ to detect, mitigate, and identify security threats.

An illustration of how an intrusion detection system reacts to violations of the security rules is provided by [24]. Scalability and efficiency issues afflict intrusion detection and prevention systems. These problems are dealt with by high-performance deep packet pre-filtering and memory-efficient approaches. Using a deep packet pre-filter and modifying its management and processing of the memory and the collected data, the work allows intrusion detection and prevention systems to have high accuracy rates and performance metrics.

Anomaly detection approaches suffer from a high percentage of false positives. Hence, a novel detection system for anomaly-based techniques is proposed in [25]. The suggested system achieves both a high accuracy rate and a low false positive rate by balancing generalizations in anomaly detection approaches.

A improved detection system is produced by [26]. It combines the two most often used approaches in intrusion detection and prevention systems: the anomaly-based and signature-based detection strategies.

The work presented in [27] pre-processes data using the anomaly detection engine and then transfers the results to the signature-based engine. As a result, the accuracy rate is quite high, and the number of false positives is very low. The authors have begun by providing the fundamental organization and implementations of the intrusion detection and prevention systems in a new signature-based intrusion detection and prevention system.

2.2. IDS That Are Based on ML/DL

OverWatch is a cross-plane’s DDoS attack defense architecture by [28]. It enables controller-forwarding device intelligence and covers assault detection and reaction. On the data plane, a poorly graded sensor and actuator monitor flow. On the control plane, a fine-grained ML-based classifier detects. To detect and mitigate DDoS attacks, forwarding and control planes partition protection functions. The suggested framework is tested utilizing a customized FPGA-based OpenFlow switch (Altera EP4SGX180) and Ryu controller. The experiment uses eight laptop hosts as DDoS attackers, victims, and typical traffic generators. Experiments demonstrate the protection system’s high detection accuracy and real-time DDoS assault responsiveness. This minimizes SDN southbound interface communication overhead.

The authors of [29] present a deep learning-based DDoS detection system for crossfire attacks. The controller detects DDoS. Capturing network status uses two ways. The SDN controller periodically obtains network traffic, whereas the switch might request traffic monitoring when it has severe packet loss. Network traffic features include flow count, flow size, and timestamp. Next, CNN and LSTM models are built. CNN input data are a 2d array of traffic features at a certain period. CNN has two convolutional phases. The first processes one row while the second processes several rows. A fully connected layer receives the output of these two convolutional processes and generates the binary value to determine DDoS assault. Besides the CNN model, an LSTM model with two sequential LSTM cells and a total layer is provided. LSTM exceeds CNN in detection accuracy.

Besides bagging-based DDoS detection systems, SDN also uses boosting-based mechanisms. The work of [30] uses a DDoS assault detection system using XGBoost, which builds trees by dividing nodes iteratively. It can then recognize DDoS attack features. The network extracts TCP connection essential features, TCP connective content features, time-based and host-based network traffic statistical features, and host-based network traffic statistical characteristics. These features are XGBoost tree training data. The trained XGBoost tree can online test network features to detect DDoS attacks. XGBoost outperforms GBDT, Random Forest, and SVM in detection accuracy and false positive rate.

The work in Nikoloudakis et al. [31] introduces a machine learning-based situational awareness framework. The framework monitors the network in real-time to identify both existing and recently added network-enabled entities, evaluates them in light of known vulnerabilities, and places them in a network slice with the appropriate level of connectivity. An IDS based on machine learning is constantly watching over the evaluated entities. To address some aspects of the situational awareness paradigm, the researchers seek to show that a neural network trained with heterogeneous data originating from the operational context (common vulnerability enumeration IDS that correlates attacks with existing vulnerabilities) can achieve higher accuracy in prediction rates than a conventional one. The overall prediction accuracy is increased by almost 4% when the proposed framework is tested in a real-world setting.

Examining the efficacy of DL-based models for detecting and stopping DDoS attacks in SDN is addressed in [32]. UDP, TCP, and ICMP flood attacks are the core focus of the proposed work. The superiority of DL-based models over traditional ML-based models has been demonstrated with the help of LSTM and CNN. The hping3 application is used to train and evaluate these models on simulated traffic. According to the outcomes of the conducted experiments, LSTM is the most effective model, with an accuracy of 89.63%. However, SVM outperforms all other linear-based models in terms of accuracy (86.85%). A comparison of the longest and shortest times needed to discover anomalies with varying split ratios is provided.

2.3. SDN-IoT IDS

The work in [33] proposes and SDN-based IDS for IoT where the IoT devices are not burden with security profiles. The proposed IDS utilizes DL classification to identify whether traffic is normal or malicious.

An intelligent SDN-enabled IDS for detecting threats in IoT networks is developed in [34]. The Cuda Long Short Term Memory Gated Recurrent Unit (cuLSTMGRU) has been utilized in building the proposed intrusion detection framework. The proposed model is evaluated and tested against similar models. In order to ensure unbiased results, 10-fold cross-validation is employed.

The authors of [8] have conducted a study related to the concept of wireless network intrusion detection systems. The goal is to achieve an adaptive solution to detect threats in SDN-IoT networks with high accuracy. Two different datasets have been adopted in a DL model know as Bi-directional Long Short-Term Memory. Both binary and multi-class classifications are investigated.

In [35], an intelligent SDN-IoT-enabled IDS, for securing healthcare ecosystems, is proposed. Both ML and DL techniques are employed to classify and detect threats in sensor-based healthcare data. Mininet-Wifi emulation is used to design the testbed required for the evaluation of the proposed framework. Contrary to the existing research, the work addresses the multi-dimensional data in healthcare systems.

2.4. Dataset for IDS

KDD’99 is one of the most widely used datasets for evaluating intrusion detection systems [11,36]. The DARPA packet traces are used as the basis for KDD’99. There are 41 elements in the dataset, and they are divided into three categories: basic elements, traffic elements, and content elements. Besides the usual data, four attack categories are included. DoS, R2L, U2R and probe attacks are all types of malicious traffic that can be classified as malicious. The KDD’99 dataset has a problem with redundancy records, with 78% of the training set and 75% of the testing set having the same records. For low-attack categories like R2L and U2R, the detection techniques are unable to provide high accuracy because of the high degree of data duplication. As a result, the detection systems favor high-volume events like Denial-Of-Service (DoS) attacks.

NSL-KDD is a modified version of the original KDD’99 dataset [37]. It is created to address issues with the KDD’99 dataset, namely the presence of duplicate records. The attack distribution in the testing set is higher than in the training set because there are an additional 17 attacks in the testing set that are not found in the training set. Despite the fact that KDD’99 and NSL-KDD have been extensively studied in the field of intrusion detection, the datasets used in these studies were created over two decades ago, and therefore, do not accurately represent current network traffic or attack trends. In addition, an old version of the TCP protocol is used to create the original DARPA dataset. IPv4 Type of Service (ToS) is invalid if you use the old TCP version, according to modern standards [38].

Apart from the previous restrictions on IDS evaluation of KDD’99 and NSL-KDD datasets, they have a large number of features that are not relevant to SDN networks. A few previous studies like [10,39] deploy the NSL-KDD dataset in an SDN context and utilize six out of the 41 features available in the dataset. SDN OpenFlow protocols are used in both studies to select features that can be directly derived from the SDN OpenFlow protocol. However, the classifier model’s performance shows a low detection rate and a high false alarm rate because the features used are not able to find the suspicious behavior of malicious traffic. For this reason, packet content features such as U2R and R2L must be included in the packet’s data to identify other types of attacks like U2R and R2L. OpenFlow’s content features, on the other hand, cannot be accessed directly.

The Kyoto dataset 2006+ has been gathered from honeypot servers at Kyoto University [40] between November 2006 and August 2009. It contains all of the actual traffic on the network. Fourteen of the 24 statistical features in the Kyoto dataset are identical to those in the KDD dataset. In order to build a more realistic dataset, an additional server is deployed in the same honeypot network as the malicious traffic. Because the traffic data are gathered via honeypot servers, where the majority of the traffic is malicious, Kyoto 2006+’s dataset has an uneven class distribution. As a result, the dataset’s assault kinds are unknown. When evaluating intrusion detection performance, this dataset has a limited ability to distinguish attack types. In addition, Kyoto’s regular traffic in 2006+ covers only the mailing and DSN traces, not the total volume of traffic. Because the dataset’s regular traffic is just 3% to 4% of the total, it does not represent overall Internet traffic. In addition, the dataset is unrealistic and uncorrelated because it is developed in two independent environments [41]. However, even though the Kyoto 2006+ dataset is based on real traffic data, it does not take into account any information on the dataset’s attack kinds. These assaults can have a negative impact on SDN network services.

Another dataset that is called ISCX2012 is presented in [42]. The authors have employed two profiles to create a network simulation based on data traffic. In the Alpha profiles, offensive traffic and beta profiles are created for the regular creation of traffic. Two main network attachments are included in this dataset. These are DoS and brute force attacks with 20 packet features. The variety of DoS attacks on the data is nonetheless significantly small and does not cover vulnerabilities occurring in various OSI layers. In addition, the dataset covers just HTTP traffic, wherein the majority of the tracks currently in the Internet are based on HTTPS traffic [43] not reflecting modern traffic. Again, the amount of features that can be recovered from the OpenFlow Protocol, comparable to KDD’99 [11,36] and NSL-KDD [36] datasets, is not sufficient for evaluating machine learning.

The CICIDS 2017 dataset of [43] is the closest to the dataset collected in this work because it provides an extensive array of attack scenarios that are not included in the earlier datasets. It also includes the same number of flow-based characteristics collected in this work. The CICIDS 2017 has been published on the basis of the ISCX 2012 foundation. The difference between the two datasets is the total number of functions that have been extracted. More than 80 flow-based features are contained in CICIDS 2017 compared to 20 ISCX 2012 packet features. In addition, to ensure website acceptance of HTTPS expansion, the HTTPS Beta profile has been introduced to the CICIDS 2017 dataset. Normal traffic behavior based on profile scripts has been generated in the CICIDS 2017 dataset. However, because of their natural complexity, the application of the profiling idea might be problematic [44]. Unfortunately, certain difficulties and weaknesses do exist in the CICIDS 2017 dataset [45]. The dataset consists of 288,602 class labels missing and 203 information instances missing. Furthermore, the size of CICIDS2017 is large and it includes multiple redundant records that appear disrespectful when it comes to IDS training.

The CSE-CIC-IDS 2018 dataset is a result of a collaborative study between the CSE and the Canadian Cybersecurity Institute (CIC) [46]. It is implemented using the cloud computing platform Amazon Web Services (AWS), in a similar way to CICIDS 2017. The profile notion is utilized to systematically construct the dataset. This dataset has two generic profile classes: B-profiles that are utilized for normally generated traffic and M-profiles that are used for scenarios of attack. The data package covers the same CICIDS2017 attack scenario. The dataset nonetheless suffers from CICIDS 2017’s similar fundamental flaws as well as the usage of fake traffic.

3. Methodology

Despite having historical roots dating back to the 1950s, the past two decades have seen virtualization taking an important place in the world of parallelization and programming in general. It is defined as a collection of software technologies that allow software applications to run on virtual hardware. In this work, virtualization is associated with another technology called containers. A container is a virtual run-time environment that runs on top of the OS kernel. When virtualization is used with containers, it is called containerization [47].

In this work, the Docker is used, which is a set of platform-as-a-service products that use OS-level virtualization to deliver software in packages called containers [48]. Many projects are built on Dockers and many research papers define, analyze and leverage the concept of Dockers. Over the past decade, the use of Dockers exploded and became a very promising area in research [49].

The Docker containers are used to improve and facilitate the application life cycle (development, testing and production) [50]. In recent research articles, the authors took the security issues in Docker containers as a study field and devised methods to secure them. Since Dockers use complex technologies, it is not simple to make them secure. In fact, many APIs are needed to secure the Docker containers [51]. Deploying Docker containers in Linux-powered IoT devices simplifies software management, maintenance, and updates. In fact, this can highly enhance IoT environments as they are naturally dynamic with limited resources. Throughout this work, a Docker represents an IoT device.

Within the framework of the proposed network design, an attacker has the ability to take advantage of weak points in the SDN-IoT network and carry out a variety of attacks, including scanning, spoofing, denial of service, and others. It is necessary to implement a wide variety of application services inside the testbed environment in order to build a substantial dataset. The created dataset has to accurately represent the many Internet exploits that may be carried out in the various SDN-IoT networks that are in use nowadays. In addition, the attack scenarios need to accommodate the existing network attacks present in the various SDN components. In addition, a number of potential attack scenarios from a variety of sources, arriving from outside of the SDN-IoT network, are taken into consideration. The usual traffic in the created data includes a variety of well-known application services such as HTTP, FTP, and SSH. As shown in Figure 1, a Virtual Box running on Ubuntu Linux 18.04 LTS is used to create three virtual machines (VMs) to serve as a representation of proposed topology.

The first virtual computer runs Kali Linux and acts as a representation of the attacker server. Ubuntu 18.04 LTS is installed on the second VM, which serves as the POX controller as well as a component for running the OVS switch over the Mininet Simulator. The third VM is a Ubuntu 18.04 LTS that acts as a victim machine to gather Pcap File and manipulate the data. Its purpose is to demonstrate common vulnerabilities by providing susceptible services. Figure 2 depicts the design of the testbed network for the proposed solution.

The attacker machine and the POX controller machine both have Intel core i7 HQ 10th Gen CPU with 32GiB 3200MHZ RAM and Nvidia Geforce RTX 2070 super GPU. The Victim machine has an Intel core i7 U 7th Gen CPU with 16GiB RAM and Nvidia Geforce 930MX GPU.

The proposed architecture suggests a solution that is made up of four OVS switches and two OVS bridges connected to the switches. The Attacker Machine that performs the attack is linked to the first OVS Bridge (brg1) (Kali Linux). The victim Machine is linked to the second OVS Bridge (brg2). The Mininet virtual hosts are joined to the POX controller based on a pre-implement configured internal bridge (by default). In addition, the Mininet network emulator [52,53] is used to simulate both valid and malicious network traffic by creating many other virtual hosts that are distributed to various switches. Mininet is often used by academics in order to implement a realistic virtual network that runs on a single Linux kernel practically and consists of hosts, virtual switches and connections. The HTTPSimpleServer webserver is used to guarantee that Web Protocol Attacks exceeded successfully in order to provide a more detailed explanation of the many attacks that occurred within the SDN-IoT network. Combining the OVS software with the routing provided by the Linux kernel allows the OVS switch to be set up to perform the duties of a Level 3 switch depending on IP. This allows a virtual host to connect with another via several subnets. The setup of the proposed testbed network is shown in Figure 3.

Using the OVS switch, to transfer from Level 2 to Level 3 switching, the following steps are carried out:

• On the same virtual machine (VM), install both the Open vSwitch (OVS) 2.14.2 and the Mininet software 2.3.0.
• In the OVS-VM, create two adapters to represent the three distinct network subnets. Both of the newly formed interfaces in the configuration in the proposed work are given the names esp33 and esp34.
• On the same OpenFlow switch, create two OVS bridges and give them the names br1 and br2.
• Assign each data plane interface to the bridge that is most appropriate for it. In this work, esp34 was assigned to the br1 bridge, while esp33 was assigned to the br2 bridge.
• Remove the IP address from each data plane interface, or set it to zero. At a later stage, the IP address that was previously withdrawn will be allocated to the bridges that have been built. For instance, we delete the IP address that has been set on the esp34 interface and assign it to the bridge that is linked to it (br1). The setup is carried out in the same manner for br2.
• Connect the virtual machine running Kali Linux to the same network adapter as br1, then connect the target server to the same network adapter as br2.
• On the Linux machine running OVS, enable IP forwarding.
• Construct a topology for a Mininet that consists of four virtual hosts (h1 to h4). By default, the primary Bridge of the controller VM is the node to which Mininet’s virtual hosts are associated.
• Pair up the POX controller to each of the newly built bridges (br1, br2).
• As of right now, ping can be used to communicate with hosts located in various subnets.

In the experiment, we use Docker Orchestration as a real environment to perform DDOS Attack and collect both suspicious and normal traffic to our study. We find attacks that exploited miss-configured open Docker daemons, where attackers were actively utilizing this attack vector to hijack environments in order to launch targeted DDoS attacks. In addition, we find attacks that collected both suspicious and normal traffic to our study. Each of the assaults is carried out by a botnet of containers, and each of the containers is based on a pre-configured specialized Docker image that the attackers have generated specifically for the purpose of carrying out the attacks.

Following this, we utilize Docker images to request a certain attack be carried out on a particular computer. This is conducted by identifying a number of pre-configured, lightweight container images that have as little script as is humanly feasible.

In this work, we make use of a variety of approaches for the attacks in both TCP flood and UDP flood. Each node (container) starts launching a Docker image to carry out a denial of service attack against a specific Destination IP and Ports as shown in Figure 4.

The targeted host constantly checks if the destination is listening to the requested ports. The destination returns a “Destination Unreachable” message when it is not in listening state or incomplete HTTP requests. This means that a denial of service occurs because these are both cyclical processes that tie up system resources and overload the server; the server is rendered inaccessible.

In order for the attackers to successfully carry out each attack script, they require specific Docker images. Each image has an entry point, and all images are given command parameters before launching attacks where each attack targets unprotected Docker daemons. In order for the attackers to carry out their assaults on many nodes (containers), they needed to collect the information listed below and shown in Figure 5:

• Found open Docker daemons.
• Identified open Docker daemons.
• Obtained Docker images with the needed capabilities.
• A Docker client to deploy the images onto the remote daemons (local Registry).

During this effort, the Docker Orchestration is able to collect 300 nodes (containers) during phase 1, another 300 nodes during phase 2 for a total of 600 nodes, and 800 nodes during phase 3, which represents an increase of 200 nodes over phase 2.

On the other hand, we use a single configure attacker node with the approach used in the DDoS attack to simulate the DoS attack environment and gather the data in the victim machine for the modeling phases as shown in Figure 6.

4. Datasets and Features Extraction

We separate the dataset into several categories according to the different kinds of traffic and the devices that are being targeted. The only kind of traffic included in the first group is the typical or normal one. The second category consists of the attack traffic that is directed toward the server. The Wireshark program is utilized in order to record the traffic traces for each class on the target computer as well as the interface for the SDN controller. In addition, the CICFlowMeter tool [54] is used in order to extract the flow characteristics. Because it is the only instrument that takes into consideration time-based aspects, we have opted to conduct our work with the CICFlowMeter. This is a deliberate choice on our part. One reason for this is that the amount of available time varies greatly depending on the program. As a direct consequence of this, it is of utmost significance to compute the statistical characteristics that are time-related for flow traffics.

The CICFlowMeter generates the features, which are listed in

Table 1. Features from CICFlowMeter [54].

#	Feature Name	Description
1	Destination Port	Port number at the victim side
2	Flow Duration	Duration of the flow in Microsecond
3	Total Fwd Packets	Total packets in the forward direction
4	Total Backward Packets	Total packets in the backward direction
5	Total Length of Fwd Packets	Total size of packet in forward direction
6	Total Length of Bwd Packets	Total size of packet in backward direction
7	Fwd Packet Length Max	Maximum size of packet in forward direction
8	Fwd Packet Length Min	Minimum size of packet in forward direction
9	Fwd Packet Length Mean	Mean size of packet in forward direction
10	Fwd Packet Length Std	Standard deviation size of packet in forward direction
11	Bwd Packet Length Max	Maximum size of packet in backward direction
12	Bwd Packet Length Min	Minimum size of packet in backward direction
13	Bwd Packet Length Mean	Mean size of packet in backward direction
14	Bwd Packet Length Std	Standard deviation size of packet in backward direction
15	Flow Bytes/s	Number of flow packets per second
16	Flow Packets/s	Number of flow bytes per second
17	Flow IAT Mean	Mean time between two packets sent in the flow
18	Flow IAT Std	Standard deviation time between two packets sent in the flow
19	Flow IAT Max	Maximum time between two packets sent in the flow
20	Flow IAT Min	Minimum time between two packets sent in the flow
21	Fwd IAT Total	Total time between two packets sent in the forward direction
22	Fwd IAT Mean	Mean time between two packets sent in the forward direction
23	Fwd IAT Std	Standard deviation time between two packets sent in the forward direction
24	Fwd IAT Max	Maximum time between two packets sent in the forward direction
25	Fwd IAT Min	Minimum time between two packets sent in the forward direction
26	Bwd IAT Total	Total time between two packets sent in the backward direction
27	Bwd IAT Mean	Mean time between two packets sent in the backward direction
28	Bwd IAT Std	Standard deviation time between two packets sent in the backward direction
29	Bwd IAT Max	Maximum time between two packets sent in the backward direction
30	Bwd IAT Min	Minimum time between two packets sent in the backward direction
31	Fwd PSH Flags	Number of times the PSH flag was set in packets travelling in the forward direction (0 for UDP)
32	Bwd PSH Flags	Number of times the PSH flag was set in packets travelling in the backward direction (0 for UDP)
33	Fwd URG Flags	Number of times the URG flag was set in packets travelling in the forward direction (0 for UDP)
34	Bwd URG Flags	Number of times the URG flag was set in packets travelling in the backward direction (0 for UDP)
35	Fwd Header Length	Total bytes used for headers in the forward direction
36	Bwd Header Length	Total bytes used for headers in the backward direction
37	Fwd Packets/s	Number of forward packets per second
38	Bwd Packets/s	Number of backward packets per second
39	Min Packet Length	Minimum length of a packet
40	Max Packet Length	Maximum length of a packet
41	Packet Length Mean	Mean length of a packet
42	Packet Length Std	Standard deviation length of a packet
43	Packet Length Variance	Variance length of a packet
44	FIN Flag Count	Number of packets with FIN
45	SYN Flag Count	Number of packets with SYN
46	RST Flag Count	Number of packets with RST
47	PSH Flag Count	Number of packets with PSH
48	ACK Flag Count	Number of packets with ACK
49	URG Flag Count	Number of packets with URG
50	CWR Flag Count	Number of packets with CWR
51	ECE Flag Count	Number of packets with ECE
52	Down/Up Ratio	Download and upload ratio
53	Average Packet Size	Average size of packet
54	Avg Fwd Segment Size	Average size observed in the forward direction
55	Avg Bwd Segment Size	Average number of bytes bulk rate in the backward direction
56	Fwd Header Length	Length of the forward packet header
57	Fwd Avg Bytes/Bulk	Average number of bytes bulk rate in the forward direction
58	Fwd Avg Packets/Bulk	Average number of packets bulk rate in the forward direction
59	Fwd Avg Bulk Rate	Average number of bulk rate in the forward direction
60	Bwd Avg Bytes/Bulk	Average number of bytes bulk rate in the backward direction
61	Bwd Avg Packets/Bulk	Average number of packets bulk rate in the backward direction
62	Bwd Avg Bulk Rate	Average number of bulk rate in the backward direction
63	Subflow Fwd Packets	The average number of packets in a sub flow in the forward direction
64	Subflow Fwd Bytes	The average number of bytes in a sub flow in the forward direction
65	Subflow Bwd Packets	The average number of packets in a sub flow in the backward direction
66	Subflow Bwd Bytes	The average number of bytes in a sub flow in the backward direction
67	Init_Win_bytes_forward	The total number of bytes sent in initial window in the forward direction
68	Init_Win_bytes_backward	The total number of bytes sent in initial window in the backward direction
69	act_data_pkt_fwd	Count of packets with at least 1 byte of TCP data payload in the forward direction
70	min_seg_size_forward	Minimum segment size observed in the forward direction
71	Active Mean	Mean time a flow was active before becoming idle
72	Active Std	Standard deviation time a flow was active before becoming idle
73	Active Max	Maximum time a flow was active before becoming idle
74	Active Min	Minimum time a flow was active before becoming idle
75	Idle Mean	Mean time a flow was idle before becoming active
76	Idle Std	Standard deviation time a flow was idle before becoming active
77	Idle Max	Maximum time a flow was idle before becoming active
78	Idle Min	Minimum time a flow was idle before becoming active

. These features include Protocol, Duration, Number of bytes, and Number of packets, amongst others. The features are classified under the following eight different categories:

• Characteristics based on network detailed information including specific origin and destination flow, IP, Port and protocol used.
• Attributes based on packets: these characteristics store data within the packets, including the total number of packets in both directions.
• Characteristics based on the number of bytes transmitted or received are considered byte-based attributes.
• Attributes for displaying interval time information in both directions.
• Attributes of flow timers: these characteristics save data about the active and idle times of each flow.
• Attributes pertaining to flags, such as SYN Flag, RST Flag, etc.
• Attributes of flows: these characteristics specify traffic flow data such as number of packets and bytes in both directions.
• The properties of sub-flow descriptors provide data about sub-flows, such as the total amount of packets and bytes flowing in both directions.

After that, for pre-proccessing, we perform labeling technique manually on the collected suspicious and normal traffic and combine them as an input to the next step.

Two algorithms are adopted for feature selection: The Maximum Relevance Minimum Redundancy (MRMR), and the Random Forest (RF).

The MRMR algorithm searches for an ideal collection of features that may effectively describe the response variable. These characteristics are found to be mutually and maximally distinct from one another. The technique reduces the number of redundant features in a feature set while simultaneously increasing the number of features’ relevance to the response variable. The redundancy and relevance are both quantified by the method utilizing the mutual information of features, the pairwise mutual information of features, the mutual information of a feature, and the response [55].

It is possible to employ the RF algorithm for feature selection by calculating the error that occurs after randomly permuting a single feature and comparing that result to the error percentage that occurs after constructing the RF model once more. As a consequence of this, the feature relevance of each variable is determined by the increase in prediction error that occurs when the values of that variable are permuted over all of the observations made outside of the bag. This metric is calculated for each individual tree, then averaged throughout the whole ensemble, and finally, the ensemble-wide standard deviation is applied to the ensemble-wide average [56].

We utilize Pearson’s linear correlation approach to determine whether or not there is a connection between the characteristics of the dataset and the labels that belong to the features. The linear correlation value is considered to be positive (increasing) if it is more than 0, and it is considered to be negative (decreasing) if it is less than 0. The correlation value is bounded between −1 and 1. Peason’s correlation formula is a method that may be utilized to analyze the relationship between two variables x and y as in Equation (1).

$$r={\displaystyle \frac{\sum (x_i-\overline{x})(y_i-\overline{y})}{\sqrt{\sum {(x_i-\overline{x})}^2\sum {(y_i-\overline{y})}^2}}}$$

(1)

The strength and direction of the monotonic relationship between two variables can be determined using Spearman’s correlation method, whereas the strength and direction of the linear relationship between two variables can be determined using Pearson’s correlation method. Both methods are used to analyze the correlation between two datasets using Equation (2).

$$r=1-{\displaystyle \frac{6\sum \left(d^2\right)}{n(n^2-1)}}$$

(2)

where d is the difference between the ranks of the two variables and n is the number of observations.

When conducting hypothesis testing, p-values are often used as a means of determining whether or not the null hypothesis should be rejected. In this particular scenario, the null hypothesis is that $H_0:r=0$ versus $H_1:r\ne 0$. A low p-value is suggestive of the falsity of the null hypothesis, which is the default assumption. It can be concluded that the correlation coefficient is not equal to zero and that there is a link between the two variables. If the p-value is less than 0.05, it is customary practice to reject the null hypothesis as being incorrect.

The p-value for Pearson’s correlation coefficient uses the t-distribution given by Equation (3).

$$t={\displaystyle \frac{r\sqrt{n-1}}{\sqrt{1-r^2}}}$$

(3)

The p-value is $2P(T>t)$ where T follows a t distribution with $n-2$ degrees of freedom.

5. Results

The performance evaluation metrics on the confusion matrix are TP, TN, FP, FN, and RC which represent the true-positive, true-negative, false-positive, false-negative, and Recall values, respectively. The TP rate and the FP rate are calculated using Equations (4) and (5), respectively.

$$T{P}_{Rate}={\displaystyle \frac{TP}{TP+FN}}$$

(4)

$$F{P}_{Rate}={\displaystyle \frac{FP}{TN+FP}}$$

(5)

Accuracy, as given by Equation (6), is the percentage of correct predictions. This metric is appropriate for balanced datasets. This statistic may misrepresent model performance in datasets with a majority class.

$$Accuracy={\displaystyle \frac{TP+TN}{TP+TN+FP+FN}}$$

(6)

On the other hand, recall measures the Machine Learning Model’s accuracy in identifying positives from total positives. In Fraud Detection Models, False Negatives are costly. Recall is given by Equation (7).

$$Recall={\displaystyle \frac{TP}{TP+FN}}$$

(7)

As given by Equation (8), precision is a metric used to evaluate how well a Machine Learning Model can distinguish between true positives and false positives. When the cost of a false positive is large for the Model,

$$Precision={\displaystyle \frac{TP}{FP+TP}}$$

(8)

Finally, the Harmonic Mean of precision and recall measures, as given by Equation (9), is used to evaluate model performance. Precision and Recall are equally important in a biased dataset.

$$F{1}_{score}={\displaystyle \frac{2}{{recall}^{-1}+{Precision}^{-1}}}$$

(9)

The MRMR and the RF features selection algorithms are used and the importance score for each selected feature is reported. For both algorithms, the importance scores for the selected features are sorted and 10 features are adopted in this work. These 10 features are chosen to be the 10 features with the highest importance scores based on the feature selection algorithm.

Figure 7 shows the features that are selected using the MRMR Algorithm with their importance score for the DDoS Dataset. In Figure 7, a high score suggests that the related predictor has a significant impact. A decrease in the feature priority score also indicates an increase in confidence in the feature selection process. For instance, if the program is confident that it will choose a feature denoted by the letter x, then the score value of the next most important feature, denoted by the letter y, is much lower than the score value of x. Figure 8 provides an ordering of the features according to their importance that is shown in Figure 7.

Unfortunately, we can see there is not much confidence in the features selection. Therefore, another feature selection is investigated. For example, most values in feature number 46 are zeros. However, it is ranked fourth among all features. This demonstrates that we have to use another feature selection algorithm. Nevertheless, next, we list the top 10 features in Figure 8.

• Feature 5—Total length of packet in forward direction.
• Feature 1—Destination port.
• Feature 70—Minimum segment size observed in forward direction.
• Feature 46—Number of packets with RST flag.
• Feature 49—Number of packets with URG flag.
• Feature 14—Standard deviation of the length of packets in backward direction.
• Feature 12—Minimum length of packets in backward direction.
• Feature 67—Total number of bytes sent in initial window in forward direction.
• Feature 72—Standard deviation of the time in which the flow was active before becoming idle.
• Feature 68—Total number of bytes sent in initial window in the backward direction.

The features that are selected using the RF Algorithm with their importance score for the DDoS Dataset are shown in Figure 9.

The top 10 features in Figure 9 are as follows:

• Feature 1—Destination Port.
• Feature 67—Total number of bytes sent in the initial window in the forward direction.
• Feature 7—Maximum size of the packet in the forward direction.
• Feature 64—The average number of bytes in a subflow in the forward direction.
• Feature 54—Average size observed in the forward direction (i.e., averaged by segment number).
• Feature 5—Total length of the packet in the forward direction.
• Feature 69—Count of packets with at least 1 byte of TCP data payload in the forward direction.
• Feature 9—Average size of packets in the forward direction (i.e., averaged by packet number).
• Feature 68—Total number of bytes sent in the initial window in the backward direction.
• Feature 37—Number of forward packets per second

The features that are selected by the RF algorithm are important and considered significant indicators in the DDoS attack as illustrated next.

• Feature 1: Destinations port in the dataset vary and it is considered important because strange ports that are not used in common protocols like (HTTP 80, FTP 21, HTTPS 443) will be most likely malicious connections.
• Features 67, 7, 64, 54, 5, 69 and 9: These features are all statistics on the forward packet length. The forward packet length is a very important indicator because the attacker will intentionally increase it in order to waste the target processing power which will result in a denial of service attack.
• Feature 68: The backward packet length size is also important because the attacker will generate packets that consume the target resources in preparing and sending more data from its system in order to consume as much as possible from its processing power and network throughput.
• Feature 37: The number of forward packets per second is a significant indicator because a normal connection will generally send a small number of packets in order to request the server content. However, an attacker will send a huge number of packets to request as much as possible data from the server side in order to exhaust server resources.

The correlation values between the top 10 features that are selected by the RF algorithm and their labels are presented in

Table 2. Correlation values between the top 10 selected features, by the RF algorithm, and their labels—Part 1.

Correlation Type	F1	F2	F3	F4	F5
Pearson (Rho)	−0.5098	−0.0509	−0.3215	−0.3197	−0.356
Pearson (Pval)	0	0	0	0	0
Spearman (Rho)	−0.2372	0.4457	−0.4415	−0.3237	−0.4306
Spearman (Pval)	0	0	0	0	0

and

Table 3. Correlation values between the top 10 selected features, by the RF algorithm, and their labels—Part 2.

Correlation Type	F6	F7	F8	F9	F10
Pearson (Rho)	−0.3197	−0.0020	−0.3569	−0.1207	−0.1294
Pearson (Pval)	0	0.3337	0	0	0
Spearman (Rho)	−0.3237	0.4241	−0.4306	0.04220	−0.2189
Spearman (Pval)	0	0	0	0	0

. These correlation values are calculated using Equations (1)–(3); where x represents a feature and y represents its label.

Surprisingly, all of the p-values are almost zeros (rounded to the fourth digit), which indicates a strong correlation between the labels and the features.

For the DoS dataset, only the RF algorithm is used to select the features, which are shown by Figure 10. The MRMR algorithm is not used since it fails with the DDoS dataset. The top 10 features that are selected by the RF algorithm based on the DoS dataset are as follows:

• Feature 67—Total number of bytes sent in the initial window in the forward direction.
• Feature 01—Destination Port.
• Feature 25—Minimum time between two packets sent in the forward direction.
• Feature 49—Number of packets with URG.
• Feature 20—Minimum time between two packets sent in the flow.
• Feature 22—Mean time between two packets sent in the forward direction.
• Feature 41—Mean length of a packet.
• Feature 14—Standard deviation size of the packet in the backward direction.
• Feature 17—Mean time between two packets sent in the flow.
• Feature 44—Number of packets with FIN.

The selected features by the RF algorithm based on the DoS dataset are also important and considered as a significant indicator as illustrated next.

• Features 25, 20, 22 and 17: All of these features define the intervals between packets, which are important for identifying a DoS attack. Feature 22 is the maximum duration between two packets transmitted in the forward direction, and while this value will be extremely large for a regular user, it will be very small for suspicious activity in order to soak up the target’s resources. However, in contrast to DDoS, the chosen features do not depend on time, as DDoS attacks are typically harmless (from the standpoint of a single device) due to the attackers’ efforts to distribute the attack in a natural way so that it is difficult to block or detect their devices. This, in turn, necessitates a normal time between packets to avoid being detected.
• Feature 1: Destination ports in the dataset vary and are considered important because strange ports that are not used in common protocols like (HTTP 80, FTP 21, HTTPS 443) will be most likely a malicious connections.
• Features 67, 41 and 14: Each of these features is a measurement of the packet’s total length. If an attacker is trying to launch a denial of service attack on a target, they will purposefully increase the forward packet length to do so. In addition, feature 14 is the standard deviation of packet sizes in the reverse direction, and an increase in the STD indicates improper behavior that results in abnormally large answers (i.e., responses).
• Feature 49 and 44: One FIN packet and a negligible or nonexistent number of urgent (URG) packets are typical for a healthy connection. Numerous FIN packets indicate a high volume of connections established and subsequently dissolved. And because of the urgency of the URG packets, the TCP/IP stack will forward them to the application even when the window (or buffer) is not filled up yet.

The collected data (both the DDoS and DoS) have been evaluated using different classification algorithms. These are Naive Bayes (Normal Distribution) and K-Nearest Neighbors using two different distance metrics. The machine used for training and testing has an Intel core i7 HQ 10th Gen CPU with 32GiB 3200MHZ RAM and a Nvidia Geforce RTX 2070 super GPU. The main parameters of each machine learning model are set according to

Table 4. Main parameters of each machine learning model.

Naive Bayes	KNN—Euclidean	KNN—Correlation
Distribution: Gaussian Prior: empirical Kernel: normal Cross-validation: false	Distance: ‘euclidean’ NumNeighbors: 5	Distance: ‘Correlation’ NumNeighbors: 5

. The prediction accuracy and the training time versus the count of the features are illustrated for the DDoS data in Figure 11 and Figure 12, respectively, and for the DoS data in Figure 13 and Figure 14, respectively. It is clear from Figure 11 that, when investigating with the DDoS data, both the KNN—Euclidean and KNN—correlations achieve the highest accuracy once the count of the features is four. On the other hand, the Naive Bayes achieves the highest accuracy once the count of the features is five.

The performance evaluation metrics for the DDoS data are listed in

Table 5. Performance evaluation metrics for the DDoS data.

ML Type	Accuracy	Classes	TP Rate	FP Rate	Precision	F1 Score
Naive Bayes	98.52%	Benign	0.9663	0.0004	0.9995	0.9826
		DDoS Attack	0.9996	0.0337	0.9749	0.9871
KNN—Euclidean	99.99%	Benign	0.9998	0.0001	0.9999	0.9999
		DDoS Attack	0.9999	0.0002	0.9999	0.9999
KNN—Correlation	99.99%	Benign	0.9999	0	1	0.9999
		DDoS Attack	1	0.0001	0.9999	0.9999

. The performance evaluation metrics for the DoS data are listed in

Table 6. Performance evaluation metrics for the DoS data.

ML Type	Accuracy	Classes	TP Rate	FP Rate	Precision	F1 Score
Naive Bayes *	95.95%	Benign	0.9987	0.0977	0.9375	0.9671
		DoS Slowloris	0.4194	0.0001	0.9771	0.5868
		DoS Hulk	0.9444	0.001	0.9982	0.9706
		DoS GoldenEye	0.2488	0.0002	0.9646	0.3955
KNN—Euclidean	99.94%	Benign	0.9994	0.0005	0.9997	0.9995
		DoS Slowloris	0.9943	0.0001	0.9933	0.9938
		DoS Hulk	0.9996	0.0004	0.9994	0.9995
		DoS GoldenEye	0.9954	0.0001	0.9926	0.994
KNN—Correlation	99.92%	Benign	0.9991	0.0006	0.9996	0.9994
		DoS Slowloris	0.9947	0.0001	0.9922	0.9934
		DoS Hulk	0.9995	0.0005	0.9991	0.9993
		DoS GoldenEye	0.9954	0.0002	0.9903	0.9929

* 8 Features.

.

Table 7. Comparing the collected dataset against other datasets from the literature.

DataSet	# of Feature	SDN Controller	Testbed Env.	IDS Domain	Labeled	Balanced
KDD’99 [11,36]	41	None	TCP/IP suite	packet-base	Yes	No
NSL-KDD [37]	41	None	TCP/IP suite	packet-base	Yes	No
CICIDS 2017 [45]	83	None	TCP/IP suite	packet-base	Yes	No
CIC-DDoS 2019 [46]	83	None	TCP/IP suite	packet-base	Yes	No
This Work	83	POX	Mininet	Flow, packet-base	Yes	No

provides a tabular summary and comparison of several datasets from the literature with the collected dataset in this work. Similarly, these works generate datasets for developing an IDS solution. The comparison is made based on the number of features, the SDN controller that is used, the testbed environment, the IDS domain, and the labeling/balancing of the data. The collected dataset is the only dataset that is based on SDN topology. Also, the latest cluster technology is used to perform several forms of DDoS attacks. Moreover, the collected dataset is not only based on the packet base capturing but also it is based on the flow base capturing.

To finalize our discussion and analysis of this work, it is worth mentioning that it suffers from certain limitations. First, the dataset, while being an important contribution to this work, was collected from a network of a smaller scale compared to what is expected in a typical SDN-IoT network. Moreover, our network topology used to create the dataset does not reflect the diverse topologies often found in real-life SDN-IoT networks. Finally, the models we develop could not be deployed and tested in real-world settings due to technical and logistic difficulties beyond our control. In the future, we hope to overcome these issues by expanding the dataset’s scale and diversity of the underlying network topologies. We also hope to deploy our models in real-life settings and test their effectiveness.

6. Conclusions

Intrusion detection systems (IDSs) can be set up more easily in a software-defined networking (SDN) environment. Their accuracy depends on the data used in their modeling. Therefore, this work develops a testbed environment on an SDN network. A Mininet emulator, which creates and implements a realistic virtual network by providing an extensible Python API for SDN networks, has been adopted. After equipping and connecting all parts of the SDN topology, the experiment generates multiple common types of DDoS and Denial of Service (DoS) attacks. Docker Orchestration distributed systems to simulate real environments for DoS and DDoS attack scenarios are used. A dataset is created consisting of examples of both benign and suspicious forms of attacks on the data plane of an SDN infrastructure. Moreover, we extract tens of features for each example and employ feature selection techniques to select the best features. We validated the outcomes of the feature selection process by performing appropriate statistical tests in addition to manually inspecting the selected features and validating their importance/relevance to detecting DoS/DDoS attacks. Finally, an experimental evaluation of our collected dataset with well-known machine learning algorithms was conducted and the effects of iteratively reducing the set of features were investigated. The experimental results showed that the KNN classifiers achieved the highest accuracy in all of our settings with a very small set of features.