DDoS Detection and Mitigation in SDN Environment

What is DDoS?
The definition and meaning of DDoS:

DDoS stands for Distributed Denial of Service. DDoS is a kind of cyberattack that make a website or a network resource unreachable. An attacker obliges thousands of devices across the internet to send an amazing amount of unwanted packets to the target> This target could be a company’s data centre or network or website. Almost any type of internet-facing connected device could be a potential DDoS resource: Internet of Things (IoT) devices, smartphones, personal computers, and powerful servers.

DDoS attacks are still a growing threat to all businesses dependent on the connectivity. There are several approaches to protect against DDoS attacks, where the most cost-efficient one is the out-of-path strategy to detect and mitigate the attacks. But how it fits SDN environments?

Out-of-path DDoS solution consists of Flowmon DDoS Defender for flow-based attack detection and traffic rerouting for a mitigation in on-premise devices or cloud scrubbing. This works well for the physical environment. However, we are witnessing of a transition to SDN / NFV virtual environments and such environments do not usually provide with out of the box DDoS detection and mitigation capabilities. So let’s have a look at DDoS attack protection in SDN environment using Open vSwitch and Floodlight SDN controller.

Open vSwitch (OVS) is known as one of the most interesting and important open source projects. In order to abstract from the physical network infrastructure, OVS is widely used in data centres to steer traffic among virtualized appliances running as virtual machines (VMs), apply access and security policies, and realize overlay networks by means of protocol tunnelling. We will show in this article, how to use OVS for protection against volumetric DDoS attacks.

We will need the following components:

  • Flowmon Collector VA or hardware appliance
  • Flowmon DDoS Defender
  • Floodlight SDN controller
  • Open vSwitch
  • We have prepared integration package which performs adding an interface to configure Open vSwitch (OVS) via Floodlight SDN controller with needed information for DDoS attack mitigation.
    Let’s dive into the details:

Firstly you need to export flows from the OVS to Flowmon collector. The figure shows a case when using a virtual collector so you can choose between flow export from the OVS or port mirroring that will drive the traffic to monitoring ports of the Flowmon collector.Principle of the Flowmon DDoS Defender + Floodlight controller + Open vSwitch (OVS) integration

Figure 1: The figure shows the principle of the Flowmon DDoS Defender + Floodlight controller + Open vSwitch (OVS) integration.

The Flowmon DDoS Defender module computes multiple adaptive baselines so when a DDoS attack comes, it is detected by exceeding the baselines. After that, the Flowmon DDoS Defender generates an attack signature which is passed to the SDN mitigation script. Upon receiving and parsing the signature by the script the DDoS Defender logs to the Floodlight controller and sends an ACL configuration via REST API in order to set up an ACL to start the mitigation. The ACL configuration is then issued by the controller to the OVS itself via OpenFlow protocol. As soon as the DDoS attack ends, all the ACL configuration caused by the DDoS Defender is again automatically removed from the OVS.

 

References:

https://selinc.com/mktg/122222/?gclid=Cj0KCQiAnL7yBRD3ARIsAJp_oLb_jXZWFw4F_cj6I8f05ougk5lB2oogBL2pCUST8WqhUAZOPwXbej4aAtbWEALw_wcB

https://link.springer.com/article/10.1007/s13369-017-2414-5

What is Software-Defined Security for SDN?

The security and protection of information in networks are essential in SDN. It should be safe everywhere and be included in the structure, to presented as a buffer to protect the provision and integrity of privacy for all resources and related information.

While everyone knows security is essential, there is still minimal solutions and technology improvements. The Open Networking Foundation (ONF) started research to discover how to make SDN more secure, and industry players are beginning to include security functionality into their solutions. However, it is immature and will likely hinder the adoption of SDN until addressed sturdily.

 

Inside the software-defined security for SDN structure, you demand to:

Secure the Controller: as the centralised choice point, access to the controller needs to tightly controlled.
Protect the Controller: if the controller works down (for example, because of a DDoS attack), so goes the network, that means the availability of the controller requires to be maintained.
Establish Trust: protecting the communications entirely the network is essential. That means securing the controller, the applications loaded on it, and the devices it runs are all trusted realities that are operating as they should.
Create a Robust Policy Framework: what’s needed is a system of checks and stability to make sure the controllers are doing what you want them to do.
Conduct Forensics and Remediation: when an incident occurs, you must be able to determine what it was, recover, probably report on it, and then protect opposite it in the future.

Behind the structure, itself, how protection should be expanded, managed, and controlled in an SDN environment is still very much up for grabs. There are competing approaches – some belief security best embedded within the network; others feel it best embedded in servers, storage and other computing devices. Regardless, the solutions need to be designed to create an environment that is more scalable, efficient and secure. They must be:

Simple – to deploy, manage and maintain in the highly dynamic SDN environment.
Cost-effective – to assure security can be stationed everywhere.
Secure – to protect against the latest advanced, targeted threats facing your company.

 

Source: https://www.sdxcentral.com/research/