The pace of digitalization and technological change is increasing exponentially, demanding a high degree of adaptability, reliability and scalability from modern IT infrastructures. Conventional network architectures can be a limiting factor, as they may not be able to adapt quickly enough to changes. Software-Defined Networking (SDN) can help solve some of these challenges by separating network control from the physical infrastructure by decoupling the control plane from the data plane. This enables the centralized management and control of networks and eliminates the need for manual configuration of individual network devices, enabling dynamic network configuration and automation. SDN is therefore often mentioned in the context of zero trust architectures, particularly with regard to micro-segmentation. SDN can help enable granular segmentation, policy enforcement and improved flexibility and transparency. In those applications where SDN is used to support security objectives, own security is of paramount importance.

Introduction to Software-Defined Networking

Organizations are increasingly turning to Software-Defined Networking (SDN) to redefine their networks and provide dynamic control, programmability and flexibility for network management. It’s a shift from traditional static, hardware-bound networks to a centralized, software-driven approach. This shift is not just a matter of convenience, but a strategic imperative in the age of digital transformation. But with great power comes great responsibility. When companies deploy SDN to orchestrate their networks, they simultaneously open the doors to a new range of challenges, particularly in the area of security.

The ongoing transformation of the network infrastructure poses an urgent problem for network security. With the move away from physical separation and unique physical identification of components responsible for different functions such as transportation or security, the traditional approach of configuring multiple separate components is becoming obsolete. However, in our pursuit of the benefits of this shift, we must not overlook the inherent security benefits that come with the physical configuration of multiple components. This shift to centralized control in software-defined networking can be a double-edged sword, offering efficiencies but also vulnerabilities. Therefore, protection against threats, especially Distributed Denial of Service (DDoS) attacks, remains paramount in this evolving landscape.

Security challenges

While SDN offers numerous benefits, it also comes with unique security challenges. The two main security challenges are DDoS attacks, which we will focus on in this article, and controller security.

The centralized controller in SDNs is a prime target for attackers, and if compromised, it can lead to severe network disruption and unauthorized access to critical network resources. Unlike traditional network devices, controllers in SDNs are highly vulnerable as they have a global view of the network topology and its policies.

To overcome this unique challenge, SDN controllers must be secured with strong authentication and authorization mechanisms. Logging and auditing should be configured to provide the necessary information to generate alerts in the event of suspicious access or operations. Communication at the control level must be protected by encryption and regular security audits and updates should be performed. Access control policies must be tuned to ensure that access is limited to the minimum required.

DDoS attacks also pose a significant threat to SDNs due to their size and adaptability. Unlike traditional network architectures, SDNs centralize control in a software-based controller, making them vulnerable to massive traffic floods. This makes SDNs particularly attractive targets for attackers.

To address this challenge in SDNs, specialized DDoS mitigation solutions must be deployed. These solutions often include real-time traffic analysis and anomaly detection mechanisms that can redirect malicious traffic away from the target. In this article, we propose a way to detect and mitigate a DDoS attack using an intrusion detection system.

Mininet

Mininet is an open source network emulator used to create simulated network environments. It allows users to simulate complex network topologies on a single machine, making it an invaluable tool for testing and developing SDN solutions. It enables cost-effective network simulation and provides precise control over network topologies and traffic. It is important to note that while Mininet is excellent for testing, it does have some limitations. The main limitations are that, firstly, the performance of the simulated network does not always match the real hardware. Secondly, Mininet uses simplified switch models that may not fully reflect the complexity of enterprise SDN switches.

Aim of the test

For this article, we simulated a DDoS attack from inside an SDN environment to a web service outside the network. This was done with the intention of replicating a simple but realistic network. The main focus of this article is to describe a method and strategy to effectively detect and mitigate DDoS attacks within an SDN environment and to illustrate the importance of advanced security measures in SDN infrastructures.

Simulation of DDoS attacks on your SDN environment

Simulating DDoS attacks in an SDN environment provides organizations with a proactive approach to improving network security. It helps assess the readiness of the SDN infrastructure for detecting and mitigating DDoS attacks while optimizing response strategies to reduce downtime and customer impact. This approach increases security, saves costs and prepares teams to deal effectively with DDoS.

A virtualized test environment enables cost-effective training for IT and security teams while providing flexibility for quick adjustments. It reduces risks to the live network and enables teams to validate security measures efficiently. It also enables rapid reconstruction with suitable tools and minimizes manual work.

Setup

For the purposes of this demonstration, we assume the following simplified setup:

On the virtual machine VM1 there is an OpendayLight Controller and Snort as IDS solution, on the second VM there is Mininet, which emulates a network with three hosts and an OpenFlow vSwitch, which is software-based and executes the OpenFlow protocol client part. On the third VM, we simulate a web service that acts as a victim. The connections between the different components:

• The bidirectional connection (a) between the OpenFlow switch and the SDN controller, which exchanges control traffic between the data and control planes – the southbound API.
• The unidirectional connection (b) between the OpenFlow switch and IDS, which enables the switch to send all mirrored traffic to the IDS for further analysis.
• The unidirectional connection (c), which allows Snort to inform the SDN controller of an ongoing DDoS attack by sending alert packets via the Unix domain socket.
• Bidirectional connection (d), which connects the local network domain to a remote service.

Attack simulation

The DDoS attack is carried out with the hping3 utility. The following parameters can be particularly useful for such a test:

• -flood Sends packets as quickly as possible without taking into account the incoming responses.
• -i Specifies the interface to be used
• -1 Uses ICMP mode
• -a Sets a spoofed IP address
• -d Specifies the size of the individual packets

In this case, we will consider the following scenarios:

Before testing, we should first get an overview of how the system behaves under normal circumstances. Mininet offers the same command; the pingall program can be used to simulate a simple interaction between all systems connected to the Mininet instance. In this case, quality of service metrics such as packet loss percentage and average round trip time (RTT) in milliseconds (ms) are evaluated. A typical system performance under normal usage could look like this:

The traffic volume generated by a DDoS attack when the proposed defense system is disabled is as follows:

This shows that after 50 seconds there was a significant increase in data traffic triggered by the DDoS attack. At its maximum, the attack reached around 43,000 packets per second. Once the baseline has been established, the corresponding scenarios for containing the attacks now follow.

Scenario 1

The first scenario simulates a DDoS attack originating from both H1 and H2, while H3 maintains its “good” access to the remote server. In this scenario, hping3 was used in ICMP mode, flooding packets to the victim (192.168.1.100) as fast as possible. The flow rate of H3 during the attack is as follows:

It can be seen that the flow rate fluctuates over time. This is the result of network congestion and lack of resources on the victim computer, both of which are caused by the DDoS attack. In this setup, the detection of the attack is done by the IDS, in this case Snort. Fortunately, Snort already provides some ready-made detection rules, such as those for DDoS attacks:

alert icmp 10.0.0.0/8 any → 192.168.1.100 any (msg: "odl block"; detection_filter:track by_src, count 10, seconds 1, sid:1000001)

According to this rule, an alert is generated if Snort captures more than 10 packets within a second from any source IP within the 10.0.0.0/8 network, destined for 192.168.1.100 (i.e. the victim machine) and using any transport ports. When this alert is sent to the OpenDaylight controller, it can automatically transmit flow rules to the local switch, which in turn blocks the sources from which the attack is intended to originate. One can check the flow table of the vSwitch in Mininet (using the built-in ovs-ofctl dump-flows utility) to verify the flow rules:

The top entries should now indicate that ICMP packets from the malicious hosts are automatically discarded by the switch. The diagram for packets over time now looks as follows:

According to the scenario, host 1 starts the attack after 59 seconds and reaches a peak value of around 3700 packets per second. Next, Host 2 launches the attack and simulates the attack. The attack was almost defused after 68 seconds. From then on, the network stabilizes to its normal operating status. This data can be taken from the Wireshark I/O diagram. If the victim computer is continuously pinged from host 3, conclusions can also be drawn about the performance of the network in terms of RTT and packet loss:

This solution takes around five seconds on average to detect and fend off the attack. The performance of the network, at least from Host 3’s point of view, was not affected.

Scenario 2

In the second scenario, the DoS attack is now carried out with a spoofed IP address. This also used the hping3 utility in ICMP mode, still flooding packets as fast as possible, but this time with a spoofed IP address (i.e. 10.0.0.100). Without changing anything in the configurations of scenario 1, a quick check of the flow rules shows:

Exactly the same configuration also works for this scenario! The performance results this time:

Conclusions

In this article, we have given a brief introduction to Software-Defined Networking (SDN) and its security challenges and finally presented a security system for an SDN environment based on an IDS to ensure “normal operation” during a DDoS attack. This approach mitigates the negative consequences of the far-reaching impact on potential victims. The system was able to detect and mitigate both types of DDoS attacks, the attack originating from H1 and H2 and the attack originating from a spoofed IP address in 4.4s and 4.6s respectively, ensuring a normal round trip time and no packet loss:

Despite the simplified set-up, the potential of how DDoS attacks can be efficiently detected and mitigated automatically in an SDN environment was demonstrated.

This article was written as a joint project of the Lucerne University of Applied Sciences and Arts and scip AG.

About the Authors

Tom Looser is a trained computer scientist and cyber security enthusiast. At the time of publication of this article, he is studying for a Bachelor’s degree in Information & Cyber Security at the Hochschule Luzern.

Tomaso Vasella has a Master in Organic Chemistry at ETH Zürich. He is working in the cybersecurity field since 1999 and worked as a consultant, engineer, auditor and business developer. (ORCID 0000-0002-0216-1268)

Rocco Gagliardi has been working in IT since the 1980s and specialized in IT security in the 1990s. His main focus lies in security frameworks, network routing, firewalling and log management.

Hanno Wiese is a part-time lecturer of Information & Cyber Security at the Hochschule Luzern and managing director of InfraStrat GmbH with a focus on plant cyber security. Hanno has a background in civil engineering and system integration of critical infrastructures.

Links

• https://www.hslu.ch
• https://www.opendaylight.org/
• https://www.scip.ch/?labs.20230720
• https://www.snort.org/
• https://www.snort.org/downloads#rules