Software-Defined Networking - Thoughts on Security

Software-Defined Networking

Thoughts on Security

Tom Looser (HSLU)
Tom Looser (HSLU)
Tomaso Vasella
Tomaso Vasella
Rocco Gagliardi
Rocco Gagliardi
Hanno Wiese (HSLU)
Hanno Wiese (HSLU)
on November 16, 2023
time to read: 18 minutes

Keypoints

How Software-Defined Networking works

  • Modern networking techniques are transforming to a software-driven approach that enables centralized control
  • With centralized control also comes new, unprecedented security challenges and the old challenges remain
  • DDoS attacks are still a threat and must be handled appropriately in terms of detection and response
  • One of the ways to combat DDoS attacks is an IDS

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:

illustration 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:

Attack simulation

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

In this case, we will consider the following scenarios:

No. Description Metrics hping3 Argument
1 A DDoS attack from two malicious hosts while a clean host has normal access to the web service Packet loss, average round-trip time and DDoS disconnection time -1
--flood
2 A DDoS attack with a spoofed IP address from a malicious host while two hosts have normal access to the web service packet loss, average round-trip time and DDoS connection time -a
-1
--flood

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:

Attempt Host 1 Host 2 Host 3
RTT Packet loss (in %) RTT Packet loss (in %) RTT Packet loss (in %)
1 0.605 0 0.696 0 0.774 0
2 0.865 0 1.108 0 0.960 0
3 1.076 0 0.826 0 0.816 0
4 1.361 0 0.669 0 1.077 0
5 0.858 0 1.184 0 1.169 0
average 0.953 0 0.897 0 0.959 0

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

Traffic volume with deactivated defense system

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:

Flow rate during attack

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:

description of 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:

Packets over time

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:

Number of tests Time to damage limitation (s) Average RTT (ms) Packet loss (%)
1 4 0.594 0
2 4 0.998 0
3 5 0.795 0
4 6 1.008 0
5 4 1.374 0
average 4.6 0.954 0

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:

Check flow rules

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

Number of tests Time to disarm (s) Average RTT (ms) Packet loss (%)
1 5 0.429 0
2 6 1.139 0
3 3 0.938 0
4 4 0.904 0
5 4 0.889 0
average 4.4 0.860 0

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:

Scenario Time to disarm (s) Average RTT (ms) Packet loss (%)
Normal usage 0.959 0
Scenario 1 4.6 0.954 0
Scenario 2 4.4 0.860 0

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

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

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

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

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

You want to test the security of your firewall?

Our experts will get in contact with you!

×
Transition to OpenSearch

Transition to OpenSearch

Rocco Gagliardi

Flipper Zero WiFi Devboard

Flipper Zero WiFi Devboard

Tomaso Vasella

Graylog v5

Graylog v5

Rocco Gagliardi

Denial of Service Attacks

Denial of Service Attacks

Tomaso Vasella

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here