Abstract
Currently 5G communication networks are envisioned to offer in a near future a wide range of high-quality services and unfaltering user experiences. In order to achieve this, several issues including security, privacy, and trust aspects need to be solved so that the 5G networks can be widely welcomed and accepted. Considering above, in this paper, we take a step towards these requirements by proposing a dedicated SDN-based integrated security framework for the Internet of Radio Light (IoRL) system that is following 5G architecture design. In particular, we present how TCP SYN-based scanning activities and DHCP-related network threats like Denial of Service (DoS), traffic eavesdropping, etc. can be detected and mitigated using such an approach. Enclosed experimental results prove that the proposed security framework is effective and efficient and thus can be considered as a promising defensive solution.
1. Introduction
With the great success and development of 4G mobile networks, it is expected that the 5th generation wireless systems (in short 5G) will be a continued effort toward rich ubiquitous communication infrastructure, promising wide range of high-quality services. It is envisioned that 5G communication will offer significantly greater data bandwidth and huge capability of networking resulting in unfaltering user experiences for (among others) virtual/augmented reality, massive content streaming, telepresence, user-centric computing, crowded area services, smart personal networks, Internet of Things (IoT), smart buildings, smart cities, to name just a few.
The 5G communication is currently in the center of attention of industry, academia, and governments worldwide. 5G drives many new requirements for different network capabilities. As 5G aims at utilizing many promising network technologies, such as Software Defined Networking (SDN), Network Functions Virtualization (NFV), Information Centric Network (ICN), Network Slicing, Cloud Computing, Multi-Access Edge Computing (MEC), etc. and supporting a huge number of connected devices integrating above-mentioned advanced technologies and innovating new techniques will surely bring tremendous challenges for security, privacy, and trust. Therefore, secure network architectures, mechanisms, and protocols are required as the basis for 5G to address this problem and follow security-by-design but also security by operations rules. Finally, as in 5G networks even more user data and network traffic will be transferred, the big data security solutions assisted by AI techniques should be sought in order to address the magnitude of the data volume and to ensure security concerns at stake (e.g., data security, privacy, etc.).
Internet of Radio Light is a Horizon 2020 project which aims at developing an architecture for smart buildings [1], supermarkets, museums, or even train stations [2], using a 5G Radio Light multicomponent carrier, Frequency Division Duplex (FDD) broadband system consisting of a VLC (Visible Light Communication) downlink channel in the unlicensed THz spectrum and mmWave up/downlink channels in unlicensed 30-300 GHz spectrum. It allows wireless communication networks to be deployed in buildings that can provide bitrates greater than 10 Gbit/s, latencies of less than 1 ms, and location accuracy of less than 10 cm, whilst reducing EMF levels and interference, lowering energy consumption at transmitter/receiver, and increasing User Equipment (UE) energy battery lifetime.
The IoRL system part responsible for all network layers as well as upper layers processing utilizes SDN in Intelligent Home IP Gateway (IHIPG), which is shown in Figure 1. This element allows network service providers to develop functionality like security monitoring, energy saving, location sensing, network slicing, lights configuration, video and network transport configuration, and network security applications. Moreover, it provides the means to locate network operations and management functions between the Intelligent Home IP Gateway (HIPG) and the Cloud Home Data Centre (CHDC) server in a configurable way to meet the different OPEX and CAPEX needs of different Mobile Network Operators (MNOs). Furthermore, it does not require MNO approval for deployment. This step change in performance and flexibility is a very attractive solution for retailers since it will increase their ability to promote their brand and products thereby improving their profitability, which will incentivize them to raise capital to finance the upgrade of their building network infrastructure.
However, apart from obvious benefits that such a system can offer to the users some challenges and issues must be addressed first. As IoRL integrates various networking technologies, i.e., VLC, mmWave, SDN, WLAN, and eNB/HeNB, and each of them is characterized with a specific set of characteristic features, potential security threats and vulnerabilities still are often not completely resolved and still need addressing.
In this paper, we want to take a step towards dedicated SDN-based integrated security solution for the IoRL system which will be able to monitor network traffic and is capable of detecting and mitigating various types of network threats by means of reconfiguration of the SDN switches flow tables. Thus, the hostile traffic will be simply removed as soon as possible from the network and in an ideal case it never reaches the victims. We initially demonstrated the potential of the proposed concept in [3] where the simulation results were presented for thwarting TCP SYN scanning attacks. However, it must be noted that in this paper we present experimental results using proof-of-concept implementation for two types of threats. Apart from detection and mitigation of the scanning activities, we evaluate also DHCP-related threats like DHCP pool exhaustion attack which is a type of the Denial of Service (DoS) threat, traffic eavesdropping, or rogue DHCP server placement.
Thus, the contribution of this paper can be summarized as follows: we propose an integrated security framework for the IoRL system which is based on SDN technology as well as based on the examples of the chosen attacks; we show that such a solution has potential and it is effective and efficient.
The rest of the paper is organized as follows. Section 2 presents the general overview of the IoRL system architecture and its main threats are characterized. Next, in Section 3 the related work is presented. In Section 4, the network threats including scanning, DoS, and traffic eavesdropping are described and their impact on the communication networks security is emphasized. Then in Section 5, we define the architecture of the SDN-based integrated security framework and describe the inner workings of the designed and implemented detection and mitigation modules. Next in Section 6, we detail how the experiments have been conducted and in what test-bed, while in Section 7 we evaluate the proposed security modules and present their optimal configuration parameters. Finally, Section 8 concludes our paper and outlines potential directions for future work.
2. IoRL System Description
2.1. Overall System Architecture
The IoRL system consists of the three main parts: user equipment (UE), radio access network (RAN), and NFV/SDN part. The developed system will be connected to the outside world using Internet or directly to the mobile operator using native 4G/5G protocols. As mentioned the overall architecture is presented in Figure 1. During the test scenarios as UE we will use currently available electronic devices, for example, SMART TV sets, tablets, or mobile phones, with custom device connected by USB used for receiving VLC and receiving and transmitting mmWave signals. The RAN part is responsible for providing wireless communication for both VLC and mmWave technologies. These functions are provided by the so-called RRLH (Remote Radio Light Head) which are built in lights roses. The last element of the IoRL subsystem is responsible for all layer 3 functions. Due to usage of NFV paradigm all new functions of the IoRL system can be added as additional Virtualized Network Functions (VNFs). In the remainder of this paper we focus on presenting details and results on the proposed security monitoring functions implemented as SDN application.
2.2. IoRL Threats
As already mentioned, IoRL system integrates various concepts and networking technologies, i.e., VLC, mmWave, SDN, WLAN, and eNB/HeNB, and each of them has a specific set of characteristic features and potential security threats and vulnerabilities that still are often not completely resolved and still need addressing. For such a heterogeneous system, a careful threat analysis is needed in order to identify the most important security hazards. In more detail, the potential IoRL system threats can be assigned to one of the following groups:(i)IoRL end user devices-related threats (user-specific): these threats include, e.g., Man-in-the-Middle (MitM) attacks performed by the malicious users in order to influence legitimate IoRL users or their devices in order to capture their sensitive data (like credentials), to tamper with the legitimate users’ communication (in order to impersonate them), or to disrupt it via Distributed Denial of Service (DDoS) attacks. Finally, some privacy-related attacks can be envisioned where the attacker tries to gain, e.g., targeted users location information, their movements, and/or habits patterns.(ii)IoRL infrastructure-related threats (component-specific): these include, e.g., attacks on crucial points of the IoRL architecture in order to overload or impersonate them, e.g., by performing DDoS attacks on the SDN or RRLH controllers or eavesdropping and then spoofing their communication. It is also worth noting that these types of attacks can be launched by malicious IoRL users (insider threat) or by remote attackers (remote threat) residing somewhere in the Internet or in the vicinity of the IoRL system components, for example, mmWave or VLC receivers and/or transmitters.(iii)IoRL-related threats (architecture-specific): such attacks can be possible or could be amplified because of the heterogeneous nature of the proposed system involving coexistence and integration of various networking technologies. Due to this fact, some unexpected interactions or vulnerabilities can be discovered. For example, due to integration of diverse types of technologies, some simplifications may be needed to ensure their cooperation which may lead to the situation that no security is provided or there are security mechanisms; however they are not compatible.
To address above-mentioned threats, we design and implement the security monitoring and management system, i.e., Integrated Security Framework (ISF) that is tailored specifically to the requirements of the IoRL system. Based on the SDN controller, a centralized system for security monitoring and manageability providing near real-time awareness of network incidents status and effective enforcement of security policy is developed. The details of the initial prototype of the SDN-based security solution are presented in Section 5. It must be also noted that in this paper we focus on the detection and mitigation of the scanning and DHCP-related threats which we treat as examples to prove that the proposed solution is effective and efficient.
3. Related Work
Software-defined networking (SDN) is recently one of the most important and promising networking paradigms [4]. The main advantage of SDN is the opportunity to decouple the control and data planes, which means that the underlying network infrastructure is abstracted from the applications. In result, the network can be managed in a logically centralized way. Apart from many potential applications of SDN [4], lately it has become an interesting option to provide security in a more flexible and effective manner in the current communication networks [5].
Moreover, the majority of network device manufactures are nowadays already supporting SDN with their physical and virtual equipment using the OpenFlow protocol. SDN is standardizing the management of heterogeneous networks. Applications written for the SDN controller will work without additional adjustments on various devices supporting SDN in both physical and virtual environments. Based on the above-mentioned facts, we decided to use SDN as a base for our detection solution presented in this paper.
When it comes to the SDN-based solutions tailored to security purposes, the first work that proposed a general SDN-based anomaly detection system was put forward by Mehdi et al. in 2011 [5]. The authors showed how four traffic anomaly detection algorithms could be implemented in an SDN context using OpenFlow compliant switches and NOX controller. The obtained experimental results proved that these algorithms are significantly more accurate in identifying malicious activities in home networks when compared to the ISP. Further, other researchers utilized SDN to detect network attacks [6] or to monitor dynamic cloud networks [7]. Recently Zhang et al. published an interesting survey on the security-aware measurement in SDN [8].
Several papers deal with SDN-based malware detection. Jin and Wang [9] analyzed malware behavior on mobile devices. Based on the acquired knowledge, they proposed several detection algorithms for mobile malicious software and implemented them using SDN. Their system was able to perform real-time traffic analysis and to detect malicious activities based only on the packets used for connection establishment. In [10], the authors designed and developed an SDN-based architecture specialized in malware analysis aimed at dynamically modifying the network environment based on malicious software actions. They demonstrated that this approach is able to trigger more malware events than traditional solutions.
Few papers focused on utilizing SDN in order to create a dedicated security solution against ransomware [11, 12]. The authors of [11] introduced two approaches that took advantage of the fact that without successful communication to the Command & Control (C&C) server the infected host is not able to retrieve the public key and, as a result, it cannot start the encryption process. Both methods rely on dynamic blacklisting of the proxy servers used to relay communication between an infected machine and the C&C server. On the other hand in [12], it is shown that SDN-based detection approach which uses the characteristics of the ransomware communication can be effective against two crypto ransomware families, namely, CryptoWall and Locky. Based on the results presented in this paper, it has been concluded that an analysis of the HTTP message sequences and their respective content sizes is enough to identify such threats with high accuracy.
Recently, research is focused more on mitigating DoS attacks directed against both infrastructure of SDN itself and devices behind it [13–18]. However, below we review the papers that are most related to our contribution, i.e., [19–22].
In [19], Shin et al. proposed AVANT-GUARD solution which helps to avoid saturation of the control plane. This is achieved by adding intelligence to the data plane and installing actuating triggers for responsiveness. This results in the reduced data and control planes’ interactions thus introducing minimal overhead. In [20], authors, in the protocol independent solution named FLOODGUARD, utilize proactive flow rule analyzer which is based on the dynamic application tracking and packets’ migration. In case of attack detection, it will temporary cache the table miss packets. Proof of concept and its evaluation showed the effectiveness and only minor overhead. Scalable and protocol independent framework FloodDefender proposed in [21] implements three novel modules: the table-miss engineering to prevent the communication bandwidth from being exhausted by offloading traffic to the neighbor switches; packet filter to identify attack by using B+ tree traffic; and flow rule management to search and purge unneeded entries in the flow table. A prototype was implemented in both software and hardware. More recently in [22] a solution named StateSec is proposed which offloads some of the controller’s functions to the switch, resulting in the so-called stateful SDN. By utilizing entropy-based algorithms, different types of DDoS attacks can be detected. Authors also claim that such a technique can detect port scanning activities; however no experimental results have been provided.
3.1. SDN-Based Detection and Mitigation of the Scanning Attacks
Finally, there are several papers related to the SDN-based detection and mitigation of scanning attacks. In [23], Yuwen et al. proposed a probability-based delay scheme to mitigate possibility of the SDN network scan using packets response time difference. IP Hopping (IPH) in [24] utilizes transparent changing of the IP addresses in the active communication of two hosts in SDN. In addition of adopting application layer gateway, this can protect against network scanning with support for multichannel protocol. Shirali-Shahreza and Ganjali in order to identify horizontal scanning in [25] decouple protecting and decision-making element of the firewall and offload the intelligence to the cloud for inspections. FleXight was used for selecting parts of the traffic needed for decision-making. This solution is scalable but requires managing third party, i.e., cloud infrastructure. In [26], the authors used combined algorithm based on fuzzy logic for the detection of port scanning, which gives better results than security algorithms used alone. This also results in the reduced number of lines of code.
Last but not least in [27], the authors proposed solution named SLICOTS, which counts TCP SYN connections per host. If their number exceeds fixed threshold further traffic is denied. As this solution is the closest to the one proposed in this paper, we present the main differences between SLICOTS and our scanning protection module below.
In contrast to the existing research, our module uses IPv4 addresses instead of MAC addresses (used by SLICOTS), utilizes a sliding time window, and does not introduce delays in packet forwarding. Moreover, it introduces a possibility to detect and block malicious traffic originating from both inside and outside the monitored network. This is not possible with SLICOTS, as MAC addresses are utilized in point to point Layer 2 connections and packets passing, e.g., through the router network interface do not preserve the original MAC addressing. As such, all packets originating from the Internet would be incorrectly marked as originating from the router gateway and a single port scan would erroneously trigger SLICOTS which will result in shutting down the Internet connectivity for the entire LAN. Furthermore, our module improves upon SLICOTS by introducing a sliding time window for the observed “pending connections” as our experimental results show that over time failed connections tend to accumulate even for the benign traffic and absolute counter of the failed connections would erroneously trigger detection event. Instead of keeping an absolute amount of failed connections, we keep a rate of failed connections over a given time. Finally, our module has the possibility of having superior performance of both packet forwarding times and CPU usage, as we operate on a copy of packets without interfering with normal packet forwarding and the most CPU intensive operations are optimized by utilizing an index and are performed periodically instead of on per packet basis.
3.2. SDN-Based Detection and Mitigation of the DHCP Starvation Attacks
To the best of our knowledge, there are only few papers related to DHCP security and SDN. In [28], it has been proposed that specialized, internal DHCP server is no longer needed. All DHCP requests and offers are handled by the controller and any other DHCP traffic is ignored. Unfortunately, this solution does not scale well as the controller has to maintain IP leases and perform DHCP transactions, which require additional memory and CPU resources. This could affect the whole network performance and security. Network Flow Guard (NFG) was proposed by the authors in [29] which aims to protect against rogue DHCP servers as well. This solution is more scalable as it uses existing DHCP server in the infrastructure instead of implementing its functionality in the controller. Whitelisting of the valid DHCP offers is implemented in the NFG. Every time, any server (rogue or legitimate) sends the DHCP offer, it will be examined and only whitelisted offers will be allowed and forwarded to the client. Unfortunately, examining every offer causes scalability issues as well. Moreover changing DHCP server configuration will require additional steps to be taken to reconfigure NFG, which can lead to the unexpected behavior. Last but not least in [30], authors propose solution against rogue DHCP server, starvation, and lease attack (which is another form of starvation attack). It is based on performing inspection of every DHCP packet and comparing it with hardcoded whitelist. Unfortunately no proper research methodology or experimental results were provided. All proposed solutions are not suitable for scalable and dynamic virtualized or cloud environments. If any change to the network infrastructure is made (like additional hosts, DHCP reconfiguration change, etc.), without updating applications above, network will behave unpredictably. This can lead to further issues including unstable work, unusability, or exposure to security threats.
When compared with existing works, our DHCP starvation protection solution is based on characteristics of the DHCP traffic for more than 97% of the currently most popular operating systems. DHCP requests that are not coherent with known patterns are dropped. What is important in terms of previous applications, any change to infrastructure, will not need further reconfiguration, which will improve scalability of virtualized or cloud environments. Moreover previous solutions do not cover scenario where the access point can be connected to the SDN-controlled switch and many DHCP requests can come from the same source. In our case, we focus on DHCP transaction ID rather than infrastructure layout or configuration. For the rogue DHCP server protection, our solution is very simple and does not require examining every DHCP offer message. It is based on the fact that DHCP infrastructure (not the configuration) is rather static, so all DHCP offers will be allowed only from the fixed server/port. All other offers (coming from other server or port) will be denied. This does not protect DHCP server from being compromised, but still scales well, as no additional overhead is needed on the SDN controller.
4. Network Threats and Their Influence on Security
In the literature, there exist many potential ways to classify network attacks. One of the most well-known classification is related to how the attacker can affect the passing network traffic or system resources. If the attack attempts to learn or make use of information from the passing network traffic or system but does not affect the transferred data or system resources, then it is called a passive attack. Alternatively, an active attack relies on altering the traffic flows/system resources or affect their operation.
In this paper, we address both types of threats which are exemplified by the scanning activities, Denial of Service (DoS) attacks, and traffic eavesdropping. In the following subsections, we describe in detail the network threats for which we will then propose detection and mitigation solutions. Obviously the proposed system can be easily extended by adding another modules responsible for thwarting other types of network threats which is out of the scope of this paper.
4.1. TCP SYN Scanning
The scanning activity, sometimes called recon, is one of the oldest and well-known network threats. The main aim of this activity is to find potentially vulnerable machine and enumerate all its services. In most cases, this process precedes actual attacks. Due to this fact, early detection of scanning activity is beneficial, and it gives valuable time to prepare network for further attacks. Moreover, if the security system introduced in the network can early detect and prevent network from full scanning activity, further attacks can be limited. If the attacker cannot find vulnerable machine, it is unable to compromise it.
Network services use listening TCP or UDP sockets on the specified ports in order to accept incoming network connections from the clients. For example, an HTTP server utilizes TCP listening socket on port 80 to accept connections and serve web pages to the clients. This functionality can be exploited by a rogue client who can scan the entire network in search for an open listening sockets in order to enumerate available services. The results of this scan can be used for further exploitation (for example, to find an outdated insecure web server or misconfigured FTP server with a default password).
It must be noted that currently there are many different types of scanning; however, the most popular is TCP SYN scanning which is described in detail below.
In summary, an attacker is attempting to determine the state of every TCP port of the target IP address (65536 ports in total) without establishing a full connection. This is achieved by sending a SYN segment addressed to every port on the server. If the server responds with SYN/ACK, it means the port is open. If the server responds with an RST segment, then this indicates that the port is closed but reachable. If there is no response after a specified amount of time, then typically it means that the packet has been filtered out by the firewall and the target port is unreachable.
One of the currently most popular scanning tools is nmap (https://nmap.org). It is a network reconnaissance tool commonly used in performing network service enumeration and vulnerability scans. The tool offers many parameters which allow controlling its scanning behavior, e.g., delay between sent packets, response timeouts, parallelism of the scan, etc. Although the user can tune settings individually, the author of the tool provides six built-in templates, i.e., T0-T5 modes. These templates allow the user to specify how aggressive the scanning should be, while leaving nmap to pick the exact timing values. The main information about each nmap mode is included in Table 1.
In this paper, we will utilize nmap to generate the real-life scanning activity using its various modes (T1-T5). It must be noted that we have omitted T0 mode in our research. The detection of such scanning activity for which the delay between two consecutive scan packets is 5 minutes is practically impossible, as scanning process of 65536 ports, for only one IP address, would take almost 228 days.
4.2. DHCP-Related Threats
DHCP (Dynamic Host Configuration Protocol), which dynamically allocates IP addresses to machines, is described in RFC 2131 [31]. Successful obtaining of IP address from the DHCP server from the pool of available IP addresses is based on exchange of four DHCP messages (Discover, Offer, Request, and ACK) during so-called transaction (Figure 2).
The first DHCP message (Figure 2(1)) is sent to the broadcast address of the Link layer (i.e., MAC address FF:FF:FF:FF:FF:FF) and the broadcast address of the Internet layer (i.e., IP address 255.255.255.255). This way, if the DHCP server is available on the network, it will always receive such a packet. The DHCP client and server typically use ports 68 and 67 to communicate. Most of the bytes of the DHCP Discover message are set to zero, but among others there is a 4-byte long transaction ID which identifies the flow of packets for this particular transaction. If the DHCP server has an available IP address in the pool, it replies with the DHCP Offer message (Figure 2(2)) with the same transaction ID. It is sent directly to the MAC address and IP address of the client and contains the proposed IP address with a netmask and a lease time as minimum, but can also provide networking details such as gateway address, DNS server addresses, domain name, TFTP server, and a filename used during boot, etc. The client, based on the offer from the DHCP server, requests such data using DHCP Request message (Figure 2(3)), but again using broadcast addresses and the same transaction ID. Finally the server sends acknowledgement message ACK (Figure 2(4)). At this point, the client can use offered IP address and the server removes it from the pool of available IP addresses.
Because the DHCP protocol has been designed only to ease maintenance of hosts in the network, no effort was done to secure it properly. There are several issues related to the mechanism described above:(i)There is practically no possibility of implementing authentication, authorization, encryption, or use of the trusted third party.(ii)The server has no possibility of finding out if the DHCP Discover and Request messages are sent from the legitimate user or an attacker.(iii)It is quite easy to fabricate DHCP messages.(iv)The pool of available addresses has limited size; thus when exhausted, no new clients are able to obtain new IP addresses. In such situation, new DHCP Discover messages will be ignored by the server resulting in a successful DoS attack.
RFC 2131 also states that DHCP clients are responsible for all messages retransmission (for example, in the case of packet losses occurrence). The client must adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions. During one DHCP transaction, the first retransmission (for example, DHCP Discover message) should take place after 4s (±1s) timeout since sending the first DHCP packet. The next retransmissions will occur after 8s (±1s) and 16s (±1s) since the previous packet (the second and the third packet). The last timeout of 32s (±1s) will finish overall transaction timeout (containing 4 DHCP Discover packets). If the transaction was unsuccessful during this time (no IP address has been successfully obtained), new transaction will be started after some administrative timeout. Unfortunately, different operating system families implement this mechanism nonidentically. This will be explained in Section 6.3.
4.2.1. DHCP Pool Exhaustion Attack
The time required for exchanging four DHCP messages (i.e., Discover, Offer, Request, and Ack) in order to successfully obtain IP address depends on the speed, load, and delays of the network but can be considered as short (ca. 1-3 ms). An attacker can use this mechanism to perform a DoS attack which is called DHCP pool exhaustion or DHCP starvation attack. It must be noted that, for example, the DHCP pool containing subnetwork with /24 prefix (with 254 usable IP addresses) can be exhausted by the attacker in less than 1 second which results in a rapid and efficient DoS attack. As a result, the communication of the entities that depends on DHCP IP addresses allocation will be completely paralyzed. This is especially the case for the dynamic and scalable environments (like clouds or public networks with open access).
4.2.2. Rogue DHCP Server
Rogue DHCP server is an entity on a Local Area Network that is providing IP addresses for other hosts but is not under administrative control of the network or infrastructure legitimate owner. Starting or connecting additional DHCP server often can be just a mistake leading to misbehaviour of network operation and network connectivity problems (like connecting to other hosts on the same LAN). Alternatively, if the rogue DHCP server is under attacker’s control, this can lead to very serious security issues. Rogue DHCP offer can contain default gateway and DNS server settings pointing to the rogue server itself. This will lead to “man in the middle attack” or eavesdropping as all traffic will be routed through malicious host. Other solutions for protecting network like IDS/IPS can be useless as affected DHCP client traffic will not be reaching these security devices at all.
4.2.3. MAC Address Spoofing and Traffic Eavesdropping
Currently one of the fairly frequent cases of network attack involves spoofing of packets/frames source address, where attacker conceals his identity within the network in order to attack either other hosts or the network infrastructure itself. In the LAN, a learning network switch in order to perform its function must keep track of which device (identified by its MAC address) is connected to a physical interface port. This information is usually kept in memory in a forwarding/switching table of a fixed size and updated whenever a frame with a new MAC address is encountered. Because MAC address can be spoofed, it is possible to fill the forwarding table completely by intentionally sending bogus frames to the switch. This in turn forces the switch to broadcast all frames to all ports (except the one on which they were received) which in result effectively transforms switch into a simple network hub. In such a case, the attacker is able to sniff all network traffic that is reaching this intermediate device.
5. SDN-Based Integrated Security Framework
The concept of the SDN-based integrated security framework utilizes a programmable network switch supporting OpenFlow protocol and a controller software running on a dedicated machine. The programmable switch handles packets switching using a rule table which is managed by the controller. The rules stored in the table define the behavior of the switch, i.e., whether to drop or to forward the packet to the specified physical port. If an incoming packet does not match any of the already installed rules, it is temporarily saved in the switch buffer and the controller is notified to conduct its inspection. The notification consists of a unique packet identification number, the switch network interface (from which the packet originated), and the initial bytes of the packet containing both network and transport protocols’ details. On demand, the packet summary can be extended to contain the whole packet payload. Then the controller software can decide whether to drop, let the packet through, change header fields, or add/remove VLAN tags, etc., optionally installing a new flow rule on the switch so the action is repeated automatically on similar packets without the controller’s involvement.
Unlike standard networking solutions, this approach allows for separation of the data and control planes; all management data (known routes, destinations) is collected, kept, and processed by only one device (the controller). This design allows the controller to pose as a central network monitoring device, capable of, e.g., correlating various events and providing additional security features.
Usually the very first couple of packets from the particular communication reveal its intent. Traditional firewall software or hardware uses this feature to block simple attacks, but often lacks the ability to use a contextual detection. Having a benefit of the centralized packets inspection we are able to detect also more complex attacks performed across the entire network which usually would be left intact by a traditional firewall. These patterns are frequently present in the reconnaissance phase of the attack.
For example, an SDN controller can monitor the initiated TCP connections per network client. This is performed in order to detect possible TCP port scanning activity using nmap tool; benign TCP connections are usually initiated with a high rate of success and a relatively stable number of connections per hour. However, a TCP port scan can be potentially distinguished from the regular traffic as it typically manifests itself in large bursts of initiated TCP connections.
In our study, we use POX SDN controller which supports a modular architecture. Our security service is implemented as a set of POX modules running alongside a built-in switch/router module, which handles normal packet forwarding. Each module implements a set of event handling routines, in particular an incoming packet event, which is triggered when a packet is sent to the controller. The event handler receives a copy of the packet, as illustrated in Figure 3. This way our modules act as a set of packet filters that are executed when a new network connection is initiated. Each specialized module keeps track of every network connection, packet contents, and host activity, i.e., in line with its functionality.
In the following subsection, we will describe in detail the security modules that were designed and developed especially for the purpose of this paper and they are focused on detection and mitigation of scanning activities, DoS attacks, and traffic eavesdropping.
5.1. Scanning Detection and Protection Module
Scan protection module works by tracking the state of each TCP connection in the traffic handled by the switch.
When a client attempts to initiate a TCP connection (a SYN packet is sent), the controller creates a description object (IPv4 addresses, ports) and sets its state to “pending”. This state will not change until a full TCP handshake is completed, in which case the status of this connection changes to “connected”. When the connection is closed (either via RST or FIN flag) the description object is removed.
By counting the number of “pending” connections per client IP address, we should be able to distinguish a scanning machine from a benign one. Because even legitimate TCP connections sometimes fail, we focus not on a raw number of “pending” connections, but on the rate of their appearance—we count the connection attempts occurring within a predefined time window (characterized with the parameter “window size” denoted with ). If this number exceeds a certain value (i.e., “threshold”, ), that particular host (client IP address) is probably trying to scan the network—the controller instructs the switch to drop packets from this IP address for a configurable amount of time (i.e., “ban time”, ).
The module works as follows (Figure 4):
(1) Install an OpenFlow rule on the switch that sends a copy of all TCP traffic to the controller (this is done due to performance reasons and the original traffic is forwarded in an uninterrupted manner).
(2) Create two hash maps in memory:(i) all_tcp_connections<FlowDescription, TCPState> contains a summary of all tracked TCP connections (IPv4 addresses, ports, and connection states).(ii) per_ip_tcp_connections<IPv4Address, <FlowDescription, TCPState organizes all_tcp_connections map per IPv4 address in order to optimize lookup performance. FlowDescription is an order-invariant hash structure containing source and destination IPv4 addresses and TCP ports. TCPState is a structure containing a description of a TCP connection with the connection state, the connection creation timestamp, and the last matching packet timestamp.
(3) When a TCP segment is sent to the controller:(a)Determine IPv4 addresses (source and destination) and TCP ports (source and destination).(b)Look up the TCP connection in all_tcp_connections. If it does not exist, create a new entry and store it in all_tcp_connections and per_ip_tcp_connections (marking the source IPv4 address as the connection origin). Mark the connection state as Unknown. Set a connection creation timestamp. Determine which IPv4 address initiated the connection to deduce whether a packet is incoming or outgoing.(c)Analyze TCP flags in the packet and the connection state. If the TCP state is:(i)Unknown:(A)On outgoing SYN flag: mark connection as SynSent(ii)SynSent:(A)On incoming SYN/ACK flag: mark connection as SynAckReceived(B)On incoming RST flag: mark connection as RstReceived(iii)SynAckReceived:(A)On outgoing ACK flag: mark connection as Connected(iv)Connected:(A)On RST or FIN flag: mark connection as Closed(v)Closed:(A)No action(vi)RstReceived:(A)No action(d)Update the timestamp of the last received packet in the TCP connection.
(4) Periodically iterate over per_ip_tcp_connections. For each IPv4 address origin,(a)Count the number of “pending connections”. The connection is considered as “pending” when it is in SynSent, SynAckReceived, RstReceived states and the connection has been created within the last seconds. If the “pending connections” number exceeds T, mark the IPv4 address as banned and install a rule on the Open vSwitch that drops all packets containing that IPv4 address for seconds but still send a copy of the packet to the controller.
As already mentioned in Section 3, the main advantages of our approach when compared with the other state-of-the-art SDN-based TCP SYN attack detection methods (especially SLICOTS [27]) include(i)utilization of IPv4 addressing instead of MAC addressing which gives more flexibility and is not prone to simple DoS attacks which can result in losing connectivity of the whole LAN,(ii)usage of the sliding time window to keep a rate of failed connections over a given time instead of keeping an absolute amount of failed connections,(iii)superior performance in terms of limited delays in packet forwarding.
5.2. Detection Module for the DHCP Pool Exhaustion Attacks
The second module limits the number of IP addresses that can be leased from the DHCP server. Exhausting the pool of available IP addresses will lead to successful DoS attack on the DHCP server; thus no new DHCP clients will be able to obtain IP address and thus they will be unable to perform any type of IP-based communication.
The most trivial solution to this problem would be to block this type of attack by counting the number of active leases per interface and provide an active response in a form of blocking of further DHCP traffic on that interface when a certain threshold is reached. Different interfaces can have a varied number of expected clients, so the threshold can be also set per interface. It must be noted that such a solution significantly increases the time needed to perform a complete DHCP exhaustion attack thus making it unfeasible (especially when the attacker has access only to a single interface). Usage of the DHCP protocol by legitimate devices with IP address already assigned is very rare (only for lease renewal or freeing the address), so typically they will be not affected. However, it should be emphasized that while blocking DHCP traffic no new device connected to the affected port will be able to obtain an IP address. Paradoxically, if the wireless access point (AP) is connected to a port which has such a security solution active, the result can be exactly opposite. In this case, the attacker does not need to make an attempt to completely exhaust DHCP pool as he can only request few IP addresses, and after reaching the assumed threshold, all DHCP-related traffic will be denied even for the legitimate clients. Thus this will appear as a DoS attack for other legitimate users within the AP range, but the DHCP server will be up, fully operational, and not affected by the attacker. Therefore, a more sophisticated solution is required and has been proposed in this paper, which is based on three observations:(i)DHCP server is not able to find out if the DHCP Discover and Request messages are sent from the legitimate user or an attacker.(ii)In case when the DHCP message is lost/blocked, the DHCP clients are responsible for all messages retransmissions.(iii)Retransmission strategy of the DHCP clients can be measured and used as a security benchmark.
Considering above the designed module requires the following steps to complete:(1)Create a structure in the memory with information related to the DHCP transaction ID, number of packets sent during particular DHCP transaction, delays between packets retransmission, and MAC address of the device requesting IP.(2)Install an OpenFlow rule that sends all DHCP Discovery traffic to the controller for the inspection. DHCP traffic volume is only a small fraction of overall traffic; therefore no performance issues nor noticeable resource utilization are expected.(3)Drop the very first DHCP Discovery packet for every new DHCP transaction, forcing the client to retransmit it after certain timeout.(4)When the retransmitted DHCP Discover message with the same transaction ID is identified, update the structure in memory, measure the delay between the original DHCP message and the retransmitted one, and check whether this value is in the range of accepted values and make a decision whether DHCP traffic should be(i)accepted (legitimate user identified),(ii)dropped again in order to wait for the next retransmission (cannot make a decision yet),(iii)banned for administrative amount of time (attacker discovered).
It is worth noting that dropping DHCP Discovery messages will introduce additional delay in the process of obtaining IP address for the legitimate clients. This can be considered as a “cost” of implementing such a solution. But on the other hand, without providing effective security solution to alleviate such threats, the attacker can easily and quickly exhaust pool of available IP addresses making the network unusable for legitimate users.
5.3. Rogue DHCP Server Protection Module
The third module is based on the fact that the infrastructure of DHCP server is rather static, i.e., the MAC or IP address and port on the switch, that it is connected to, will not change often. In fact such a change can never happen as it might not be needed. This module, when enabled, will allow only DHCP offers being sent from the legitimate server MAC/IP/switch port and all other offers (possibly coming from the rogue DHCP server but also possibly from the accidentally started, misconfigured DHCP servers) will be dropped and will not reach DHCP clients. On the other hand, reconfiguration of the DHCP service itself can be made quite frequently (e.g., modification to the pool size, adding static reservation, DHCP parameters changes, which in result would change the DHCP offers). Our module does not examine the content of every DHCP offer; thus it does not introduce any additional overhead for the SDN controller. Additionally, it does not require reconfiguration on the DHCP service configuration update which means it is scalable.
Because the algorithm used for this module is quite simple, we decided not to perform its experimental evaluation. However, we have verified that this module works well and is effective.
5.4. MAC Address Spoofing Detection Module
The fourth module allows only a fixed number of devices (i.e., MAC addresses) that can communicate through a particular interface on the switch. This is done by keeping a limited (configurable capacity) list of “known” MACs, built in first come, first served fashion as the network traffic is routed by the switch. If a packet from an unknown host is encountered and the list is full, the packet is dropped and the filtering rule is installed to prevent further communication.
The total number of addresses across all interfaces should be lower than the maximum capacity of the switch forwarding table. This way the switch will never enter the broadcast mode, making it impossible to sniff passing traffic by the attacker.
In the future, this module can be further extended to support removing hosts from the “known” list if no communication occurs for a given amount of time.
Due to the fact that the algorithm used in this case is quite straightforward, it is pointless to perform experimental evaluation for this module. That is why we have only verified that the module functions correctly and deemed further experiments unnecessary.
6. Experimental Test-Bed and Methodology
As mentioned in the previous sections, for the purpose of this paper, we have developed the dedicated security-related detection and mitigation modules which are a part of the integrated SDN-based security framework. In the remaining of this section, we first introduce the details of our experimental test-bed and outline the methodology of the conducted experiments. Then we focus on presenting obtained results for all designed and developed protection modules.
6.1. Experimental Test-Bed
In our experimental evaluation, the following test-bed has been utilized (see Figure 5). All virtual machines run Ubuntu 16.04 LTS on a machine with Intel Xeon CPU E5-2630 v2 @ 2.60GHz on which Xen v. 4.4 VM Hypervisor is operating. Physical PC sdn_03 is running Windows 10 operating system. Mobile devices sdn_04 and sdn_05 are Samsung S8 with Android 7.0 Nougat and Apple iPhone with iOS 11.4.1. On the sdn_sw0 an Open vSwitch v. 2.5.2 SDN software switch is installed. Machine sdn_controller runs POX, a Python implementation of a controller (github devel, “carp” branch). Although the switch is implemented in software, its host virtual machine is unreachable from inside the created network. This design is applied in order to separate the client and the administrative networks for increased security, i.e., sdn_sw0 and sdn_controller are connected with each other through a dedicated line.
Sdn_01 and sdn_02 hosts act as client devices emulating the behavior of benign and rogue users depending on the test scenario. Sdn_0n and sdn_nat form a subnet and sdn_nat serves as both a gateway, providing Internet access to the “client” machines and a DHCP server which assigns IP addresses in this network. Sdn_01 has a static, fixed IP address reserved in DHCP network range, while sdn_02-5 gets a dynamic IP address assigned by the DHCP server.
Windows, Android, and iOS (or more generally Mac OS X) cover more than 97% of the mobile operating systems market [32] and that is why they have been chosen for the DHCP exhaustion attack analysis. Moreover Android 7.x, Windows 10, and iOS 11.4 are the most popular versions of these operating systems families [33–35]. It is worth nothing that it is possible to emulate Android on x86 architecture (therefore on virtual machine) but during experiments the behavior of the DHCP implementation was different than when tested on a real device. That is why physical devices were used instead. Additionally, the proposed testbed falls into convergent, hybrid (physical and virtual) assumptions of IoRL architecture.
In our experimental test-bed, the following toolset has been used:(i)nmap v.7.01: as already mentioned, one of the most popular network reconnaissance tools typically utilized in performing network service enumeration and vulnerability scans,(ii)Open vSwitch v.2.5.2: software network switch conforming to OpenFlow protocol acting as the main switch in our test-bed,(iii)POX (Carp): OpenFlow SDN controller written in Python 2.7 expanded with our security-related modules,(iv)PhantomJS v2.1.1: a headless browser used in the experiment to simulate benign network traffic,(v)Dhcpstarv (http://dhcpstarv.sourceforge.net): an open source tool that implements DHCP starvation attack.
6.2. Experimental Methodology for the Scanning Attacks Detection
The novelty of our TCP SYN scan detection solution is the excellent routing performance in comparison to other solutions [27]. We achieve this by passing network traffic into two parallel streams: the first one is routed directly through the network switch without any interference caused by the switch (except of packet-drop rules), while a secondary stream of data is being copied to the controller for analysis. By utilizing such an approach, our detection solution should not introduce any additional delays in packet forwarding; however it has the disadvantage of being reliant on the reaction time—the controller receives packet summary in parallel to it being routed and usually the decision is made after the original packet already left the switch interfaces.
In order to validate the simulation results obtained in our previous paper [3], we have enabled our detection module on the controller machine and performed extensive experiments that measured both attack prevention effectiveness and performance impact on the network infrastructure and routing capabilities. Similarly to the previous experiments, we have conducted two types of experiments—the first one measured the True Positive detection rate by tracking an attack performed using nmap tool on a client machine, while the second one measured the False Positive detection by tracking a benign user browsing the Internet on a client machine.
Our experiments measured the following factors:(i)True Positive rate: the ratio between the number of blocked nmap packets to all packets sent by the tool.(ii)False Positive rate: the ratio between the number of erroneously blocked packets to all packets sent by PhantomJS.(iii)Reaction time: the time needed by the infrastructure to detect and block malicious traffic.(iv)Missed packet rate: the ratio between the number of packets that are a part of the scanning activity and should be blocked by the controller’s algorithm, but failed to do so due to implementation factors (i.e., due to slow reaction time).(v)Resource usage: the consumption of the CPU and RAM resources.(vi)Forwarding performance: the impact on the forwarding performance introduced by our solution.
Our detection algorithm (see Figure 4) consists of two independent parts: the packet logging, executed every time the controller receives a packet, and the actual detection logic, executed periodically.
Simulations performed for the previous paper [3] were done under the assumption that the detection logic, parametrized by the threshold, windowsize, and ban time (see Section 5.1), can be executed for every packet. However, due to the performance constraints, the detection routine cannot be performed each time we receive a new packet; thus we need to introduce a separate parameter, check interval which denotes how often the failed connections limit is enforced. This parameter bears the compromise between controller’s CPU usage and reaction time: the more frequent the connection check is, the more the CPU time is required and the faster the reaction time is. However, extreme values of the check interval parameter can cause the controller to overload and disconnect from the switch, disabling the scan protection completely.
In order to optimize the performance of the scanning detection, the old TCP connections are removed from the memory. If the TCP connection is marked as Closed (a proper sequence of RST/FIN flags was exchanged) or the connection has timed out after 180 seconds, then it is removed. However, we make sure that the memory cleanup actions do not interfere with the detection algorithm—for example, if the windowsize parameter exceeds 180 seconds, we extend the timeout time to match the windowsize parameter. This allows us to use a smaller check interval parameter in most cases.
In our experiments, we evaluated the optimal values for threshold, windowsize, and bantime parameters obtained in our previous research, with a set of different check interval settings. As before, we assessed our solution across nmap’s T1-T5 scans and PhantomJS web browsing. The given threshold, windowsize, and bantime parameters are presented in Table 2 and the check interval parameter equals 0.01, 0.02, 0.05, 0.10, 0.20, 0.50, 1.00, or 2.00 seconds.
In order to create a reliable and repeatable experimental environment, we have utilized Fabric (http://www.fabfile.org/), a high level Python library designed to execute shell commands remotely over SSH. This library provides easy means to orchestrate shell commands across multiple hosts within the control of a single Python script running on a single machine.
The data recording phase of our experiment scenario has the following steps:(1)Start POX software with our TCP SYN scan detection module on the SDN_Controller.(2)Start vmstat on the SDN_Controller to monitor CPU nad RAM usage on the machine.(3)Start tcpdump on the Input and Output network interfaces of the SDN_Switch machine to monitor the incoming and outgoing traffic on the machine.(4)Wait 30 seconds for POX to initialize and record machine’s idle CPU and RAM usage (i.e., with no traffic).(5)Generate the network traffic via either (A): TCP scan attack or (B): PhantomJS web browsing by running(A) nmap scan on the SDN_01 machine that scans all ports of the SDN_Nat01 machine,(B)PhantomJS headless web browser on the SDN_01 machine that visits the popular websites on the Internet every 5 seconds.(6)Wait for 660 seconds (amount chosen to be slightly longer than the widest considered windowsize parameter—see Table 2).(7)Terminate the traffic generating tool.(8)Wait 300 seconds for the POX controller to perform necessary memory cleanups and return to the idle state.(9)End tcpdump on the SDN_Switch.(10)Generate simple summary files and synchronize tcpdump, vmstat, and POX log data to the SDN_Nat machine.
The data obtained from the tcpdump tool contains on one hand the input packets (generated by the client machine performing the attack) and on the other hand the output packets (filtered by the rules installed on the switch).
We can measure the algorithm’s efficiency by comparing these two files, looking for packets that were not forwarded through (i.e., filtered out) by the switch and their overall percentage contribution. On the packets that were not filtered out a delta between arrival and departure timestamp (which are provided by the network adapter) can be calculated which, compared to the delta acquired in the control run (i.e., with the security module disabled), can be used as an estimation of the overhead that our system introduces to the network.
We were also interested in the reaction time (between algorithm’s decision and it actually making an effect on the switch); however it happened to be difficult to measure using POX and Open vSwitch event logs, as they are subject to many delay factors and could contain major discrepancies between timing reported and the actual packet blocking on the switch. Instead we used a delta between arrival timestamp of a packet that should trigger the detection and arrival timestamp of a first packet that was, in fact, filtered out. This method has an unfortunate effect of providing only an upper bound to the reaction time, as it can only be measured with accuracy up to the incoming packet interval. The most accurate results are acquired with measurements done on nmap T5 scan, which sends packets in sub-millisecond intervals. On the other hand, T1 scan has the worst accuracy of up to 15 seconds. The results are acquired by a separate Python script in the postprocessing phase of the experiment.
We assumed that the experimental results should not vary highly in comparison to the simulation results; however we identified the following factors that could skew the results:(i)nmap’s timing algorithm: the tool’s behaviour (i.e., scan speed) changes if some of its packets are filtered out. During data gathering for simulation, we did not interfere and allowed the tool to run at full speed. In the actual experiment, some of the traffic will be blocked. If the tool reduces scan speed significantly, it might fall below the detection threshold after some time which does not happen in the simulation data.(ii)CPython’s Global Interpreter Lock: due to the limitations of CPython, the POX controller runs as a one-core process with two interleaved threads (one for handling communication with Open vSwitch and one for calculating connection statistics). In some cases, the threads might not meet the time constraints, resulting in detection misses or disconnection, which renders the system defenseless.(iii)Open vSwitch rule installation delay: every time the controller decides to block specified network stream, there is a significant delay between the moment the decision is made and the moment the rule becomes active.(iv)Implementation differences between the simulation software and actual implementation on POX controller: although our final implementation closely resembles the initial code used in the simulation, some differences were introduced, especially in regards to the way we install the ban rule on the switch. In our final code, we keep track of rules installed on the switch and do not install a ban rule if there is already a similar rule in place.
6.3. Experimental Methodology for the DHCP Starvation Attacks Detection
In order to measure characteristics of the DHCP message retransmissions experimental evaluation has been conducted for Windows 10, Android OS, and iOS as well as for Dhcpstarv tool. The traffic related to the DHCP was captured on the sdn_nat host, with intentionally disabled DHCP service as in this case DHCP clients were unable to successfully obtain IP address and they infinitely retransmitted DHCP discovery messages forming transactions. The set of 100 DHCP transactions for Windows, 100 for Android, 100 for iOS, and 300 for Dhcpstarv were captured and they were used in the learning phase of the proposed security system. During this phase, DHCP discovery messages retransmissions timeouts were examined and the resulting characteristics (the minimal, the maximal, the average, and the standard deviation values) are presented in Section 7.2.
During the testing phase, both our security system and the DHCP server were enabled. Unfortunately legitimate DHCP client, after successfully obtaining an IP address, stops retransmitting DHCP discovery messages (which is how DHCP protocol was designed and should operate). Forcing such OS to reobtain IP address would require flushing current IP address by, for example, restarting network interface. This is not an easy task to automate for Windows and especially for Android and iOS operating systems. On the other hand, Dhcpstarv tool still tries to obtain as many IP addresses as possible; therefore it never stops this activity. Due to the facts above, our security system was tested only for Dhcpstarv tool (with 100% accuracy). On the other hand for legitimate devices (with Windows, Android, and iOS), another set of 100 DHCP transactions was captured for each OS and used in simulation to find out how many DHCP Discovery messages would be blocked by the proposed solution. The obtained results are presented in Section 7.2 as well.
7. Experimental Results
In this section, first we present experimental results obtained for the evaluation of the scanning detection module and then the results for the DHCP-related threats detection are introduced and analyzed.
7.1. Scanning Attacks Detection
Figure 3 presents the results of an exemplary nmap T5 scan mode. It is visible that the implementation of our solution behaves generally in line with our expectations. As nmap starts its scanning activity, it sends a large number of packets in a short burst. In this case, the controller is unable to precisely react and it initially passes through a number of packets (potentially large as it depends on the chosen nmap scanning mode). This is indicated in Figure 6 by a large red line near the beginning of the experiment. However, shortly after the initial burst, the controller installs a rule on the switch which successfully drops packets incoming from the rogue client. The nmap tool monitors the packet retransmission rate and once a significant packet loss occurs, it scales down the packet sending rate as it assumes that the scan exceeded network throughput. Therefore, after the initial burst of packets has been suppressed, the controller has the ability to reliably detect and block further attacks from this machine, as long as they occur within the ban time parameter time window.
Figure 7 presents exemplary CPU consumption (in [%]) and RAM utilization (in kilobytes (KiB)) during the experiment. It can be seen that after 30 seconds from the beginning of the experiment nmap the scanning activity is clearly visible as a spike in RAM and CPU utilization. As the initial burst of packets is handled by the controller, the algorithm quickly completes its database of connections which requires more RAM and CPU utilization with each incoming packet. The usage of both resources rises until ca. 210 seconds of the experiment when old TCP connections are removed from the database (as exactly at 180 seconds the TCP connection timeout has passed) and then the CPU usage decreases significantly.
The freed RAM memory is not returned to the system immediately, due to the optimization used by the Python interpreter to reduce the number of memory allocations. This phenomenon makes it difficult to estimate the real RAM consumption by our algorithm. However, because the algorithm periodically iterates over its connection database in a linear fashion, the memory occupancy can be correlated with the CPU usage.
At this point in time (i.e., after 210 seconds) the nmap scan rate is constant. On the other hand, because the experiment has been running for more than 180 seconds, with each cleanup cycle some of the connections are removed due to exceeded timeout. These two mechanisms keep the database size roughly constant, as the same amount of new connections is added to the database as the number of connections is removed. This is reflected in a constant CPU utilization during the nmap scan phase of the experiment.
In the case of nmap T1 scan mode, there is no initial burst of packets and the packet rate is significantly lower than in the case of T5 mode. However, our evaluation still marks some packets as missed—this is caused by two separate issues.
The first issue is the same as in case of nmap T5 scan mode during the initial burst—the controller’s algorithm works in parallel to packet forwarding on the switch and due to that it has a small delay between the packet forwarding and packet inspection or rule installation. Due to this factor, in the real-world implementations at least one packet will always be missed when compared to the previously obtained simulation results.
The second issue is caused by the differences between our simulation software and the actual implementation of the algorithm on the controller. The simulation software did not account for the way we prevent installation of multiple duplicate rules on the switch.
The optimal results proposed by our simulation software were slightly too optimistic and balanced on the edge of detection when used on real hardware. For example, the experiment that utilized parameters found as Threshold=7, Window Size=100 missed some packets, as illustrated in Figure 8. This is because nmap T1 mode sends a packet every 15 seconds with some random minor timing delays between the packets. When we divide the proposed 100 seconds time window by 15 seconds between each packet, we see that nmap will be able to send around 6.66 packets in the proposed time window, which is slightly less than proposed threshold value equal 7. There is a slight chance that at some point the time window will contain 6 incomplete connections instead of expected 7, allowing one scan packet to pass through. In order to solve this issue a slight increase in the time window size is necessary, e.g., to 105 seconds in to accommodate 7 packets sent by nmap (see Figure 9).
The results presented in Table 3 are oriented towards determining the optimal value for the check interval parameter in order to minimize the reaction delay of attack mitigation. The reaction delay depends on the frequency of inspection of TCP connection statistics gathered in memory and the time needed by the Open vSwitch to install a banning rule. Since the latter factor is outside of our control, we try to optimize the former factor, i.e., check interval parameter to achieve the best compromise between the CPU usage and the reaction time. The results—the average CPU utilization by the POX controller and the reaction time—are influenced by the following:(i)Nmap scan mode determines the frequency of scanning packets generation and time constraints.(ii)Window size parameter influences the memory cleanup feature and CPU utilization if the value exceeds 180 seconds—we delete timed out TCP connections that are older than 180 seconds and windowsize.(iii)Check interval parameter is the frequency of how often we scan the memory map for the IP addresses that exceed given threshold value.
In case the POX controller gets overloaded and fails to respond to Open vSwitch on time, the Open vSwitch disconnects itself from the controller and enters fallback mode, where it passes all network traffic without filtering, effectively disabling all security features. Such cases were marked in Table 3 with bold font. As observed, the check interval parameters shorter than 0.1 seconds tend to overload the controller during the most intensive nmap scans. We selected the 0.1 seconds value as optimal because it offers the shortest reaction time while still being able to withstand most nmap scans. It should be noted however that check interval parameter equal to 0.2 seconds provides only slightly worse accuracy while the CPU utilization is nearly halved, which might be more useful in a nonexperimental environment.
Additionally, we have noticed that the Threshold values 4 and 7 tend to distort the results, as they trigger detection much earlier than in the rest of experiments. In case of T5, T4, and T3 scans, there is an initial, small burst of packets being sent by the tool, followed by a 1 s pause, as visible in Figure 10. In this case, the initial packets sent by nmap trigger detection; however no packets are filtered out, because there is no traffic for the next 1 s. As previously described, reaction time is determined by the interval between the ban installation timestamp and the first packet that has been filtered out. In this particular case this includes 1 s when nmap remains silent. Thus, for these experiments, the reaction times can not be reliably compared with other results presented in Table 3.
Based on the gathered experimental data, we estimated that the rule installation time in our experimental test-bed should be within 0.025–0.075 second range. Therefore decreasing check interval parameter beyond this range brings little to none benefit in terms of the reaction time. Future works could include exploring the aspect of utilizing a faster runtime environment (such as using C++ or C language instead of Python on the controller machine) and further code optimization to achieve higher CPU performance.
After determining the optimal check interval parameter value, i.e., 0.1 seconds, we compared the simulation results of nmap mitigation and false positive rate with the measured experimental results. This is presented in Table 4. It must be noted that the obtained experimental results are similar to those acquired through simulations and this proves that our system (when the proper parameters are configured) is effective in detecting and mitigating nmap scans, while being nonintrusive to the benign traffic.
The measured packet forwarding time was seconds for the unprotected and seconds for the protected system, which is a negligible difference in comparison to the other state-of-the-art solutions.
To summarize it can be concluded that the best parameters for our scanning detection module are windowsize: 550 seconds, threshold: 34 connections, bantime: 16 seconds, and check interval: 0.1 seconds.
7.2. DHCP Starvation Attacks Detection
First we have performed measurements of the DHCP transaction retransmissions for different operating systems and the obtained results for the legitimate DHCP traffic have been used to determine the normal behavior. Then we preformed the same operation for the DHCPstarv tool to determine the characteristics of the malicious activities. In the end all the results have been used to feed the detection system. The details of the measurements are presented below.
Table 5 contains results of the DHCP transaction retransmissions for Windows 10. It should be noted that in this case during a single DHCP transaction four packets are broadcasted and the second, the third, and the fourth packets are sent after ca. 4, 12, and 28 seconds since the initial DHCP message. This gives 4, 8, and 16 seconds timeouts, respectively. After sending the fourth packet, administrative timeout of ca. 32 seconds is counted and if no reply is received, the transaction is considered as failed (ca. 60s). What is more analyzing collected dataset of DHCP transactions for Windows OS showed that the timeout between consecutive transactions (thus the time between sending the first DHCP message for two consecutive transactions) can be described with the series ca. 60s, 360s, 60s, 360s, etc. This means that every new transaction is started immediately after previous transaction (60s) or after five minutes (360s).
Table 6 contains similar results, but for the DHCP transactions collected for Android OS. In this case, during a single transaction five packets are broadcasted and the second, the third, the fourth, and the fifth packets are typically sent after ca. 2, 6, 14, and 30 seconds. This is caused by the timeouts used which are 2, 4, 8, and 16 seconds, respectively. After sending the fifth packet, timeout of ca. 8 s is counted and if no reply is received, transaction is considered as failed (ca. 38 s.) Analyzing collected dataset also showed that the timeout between consecutive transactions (thus the time between sending the first DHCP message for two consecutive transactions) can be described with the series 38, 300-1200, 38, 300-1200 seconds, etc. This means that a new transaction is not started immediately after the previous one but after the random time of about 300-1200s of the administrative timeout. The timeouts between retransmitted DHCP messages within the transaction are smaller than in the Windows dataset, most probably because mobile users typically want to get their online content quickly. Decreasing the timeout between DHCP messages helps to achieve this aim.
DHCP retransmissions for iOS are somewhat more complex than two previous cases. There are two types of transactions which occur in turn. The first transaction type contains nine packets, and the second to the ninth packet are sent after ca. 1.6, 4.3, 9.1, 17.6, 26.1, 34.6, 43.1, and 51.6 seconds. This corresponds to 1.6, 2.7, 4.8, 8.5, 8.5, 8.5, and 8.5 seconds timeout, respectively. Table 7 contains characteristics of those retransmissions. The next transaction will start after ca. 10s timeout. Second transaction type contains only two packets, and the second one is also sent after ca. 1,6 second timeout. The initial transaction started by iOS is the one with 9 packets, and the second is with 2 packets. We are excluding shorter transaction as(i)our solution is based on transactions with at least three packets,(ii)the first initiated transaction by iOS is always the one with nine packets.
Finally, Table 8 contains DHCP transaction characteristics for the Dhcpstarv attack tool. In this case, during one transaction three packets are broadcasted and the second and the third packets are sent after ca. 2 and 4 seconds. After sending the third packet timeout of ca. 2 s is set and if no reply is received during this period, the transaction is considered as failed after 6s timeout. The analysis of this dataset also showed that the timeout between consecutive transactions can be described with the series 6 s, 6 s etc. This means that another transaction is started immediately after the previous one. It should be noted that results from Table 8 contain values with high precision in order to show differences between minimal, maximal, and average values. With typical precision as used in the previous tables, these differences would not be visible.
During the learning phase of the experiment, the minimum and the maximum retransmission timeout values for Dhcpstarv tool were examined. The result was used to create the pattern to describe malicious activity. Therefore if the first retransmission of any DHCP discovery transaction would occur between 2.000274 and 2.002858 seconds, such traffic should be blocked as a possible threat. Likewise the second retransmission will be blocked if the retransmission timeout would take place between 2.000428 and 2.002922 seconds.
Using the values above, experiments for the test dataset were performed. As a result, only once legitimate device (iOS) was identified as malicious; thus the second DHCP packet (therefore the first retransmission) was also dropped. This caused additional delay (2.950614) in obtaining IP address for these devices, which as already mentioned can be considered as a kind of “cost” for the proposed system. The average delays introduced for Android, Windows, iOS, and overall for all OSes are shown in Table 9. It should be noted that, in the proposed solution, for Windows and Android OS devices only one retransmission has to take place (as this is how the proposed mitigation method works). For the iOS, it can be one or two retransmissions, but in this case retransmissions are faster than for Windows and Android OSes (see Tables 5 and 6). The time needed to successfully obtain IP address (fixed value of 1-3ms) is negligible.
It can be assumed that if a legitimate device is booting, about 2.5 seconds for obtaining IP address can be negligible as well (in terms of overall booting time). But on the other hand, if the device is up and running, and only the access to network is enabled, then this can result in a bad user experience. Nevertheless, without providing such a mitigation system that will block DHCP exhaustion, the access to the network can be completely blocked by an attacker.
Another type of the trivial DHCP starvation attack can be based on flooding network with the DHCP messages (in order to speed up the process of the DHCP address pool exhausting):(i)not utilizing retransmissions (i.e., only one message in one transaction) sent with the high rate,(ii)utilizing retransmissions but still sending them with the high rate (vary timeout delay between retransmissions within a single transaction).
Such an attack would be easily blocked by the proposed system as timeouts between DHCP messages would be too small, and not comparable to known patterns of most popular operating systems.
Implementing the proposed solution will result in increased delay in obtaining IP address from the DHCP server for the legitimate users but also will make DHCP pool starvation impossible using trivial tools or Dhcpstarv tool.
For the scenarios described in Table 10, implementation of proposed solution is summed up:(1)only legitimate devices on the network with the mitigation system disabled,(2)legitimate and attacker devices on the network with the mitigation system disabled,(3)legitimate devices with the enabled mitigation system,(4)legitimate and attacker devices with an active mitigation system.
8. Conclusions and Future Work
In this paper, we introduced a novel, dedicated, SDN-based integrated security framework for the IoRL system which is created using the 5G networks architecture guidelines. We also presented how the proposed defensive solution can be used to detect and mitigate various network threats. To demonstrate its usefulness, we tested it with exemplary network threats which included TCP SYN scanning and DHCP-related attacks (DHCP pool exhaustion, traffic eavesdropping, and DHCP rogue server placement).
Obtained experimental results performed using proof-of-concept implementation of the proposed system proved that it is efficient and effective. Another important advantage of the developed framework is that it is easily extendable; i.e., countering a new threat is possible by simply adding a new specialized security module. It must be also noted that the developed modules are quite straightforward yet they defend against serious and important threats.
Future work will be devoted to the extension of the capabilities of the integrated security framework so it is able to mitigate a wider number of threats. We will also consider applying more sophisticated detection algorithms for the existing security modules.
Data Availability
The network traffic data used to support the findings of this study are available from the corresponding author upon request.
Disclosure
The parts of the research presented in this paper were accepted for presentation and presented at 13th International Conference on Availability, Reliability and Security (ARES 2018).
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The authors gratefully acknowledge the financial support of the EU Horizon 2020 program towards the Internet of Radio Light project H2020-ICT 761992.