Security: SDN Exposed Layer by Layer #5
Welcome back my DDoSed Reader,
We hope that you genuinely enjoyed our latest excursus on CDNs and Security hactics when it comes to dealing with highly redundant, impenetrable (so it is claimed) Architectures. Today instead, we’ll walk a little bit away from there and enter another Realm, the one of SDN, or Software Defined Networking, and look what lies beneath its shadows. Or Security Introduction is just about halfway and we hope that you appreciate us bringing you by the hand into different environments and showing you what the threats of the Security declination are, rather than just focusing on one kind of Security aspects alone and leave the whole rest behind. No one ever said a Security Introduction would have been an easy journey, either.
These Introductory Articles will make for more Advanced ones down the road together, our intent is thus to share basic, evergreen notions with you and raise your awareness to this regard.
Back to today: as more and more companies look to adopt Software Defined Networking (SDN), the concerns for Security reach their peak. Companies want to know how SDN products will guarantee them that their Data, Applications as well as Infrastructure will remain safe. With the introduction of SDN, new methods for securing the control plane traffic are needed. In this article we will review the attack vectors of SDN systems and expose SDN Security layer by layer.
What is Sotware-Defined Networking?
Software-Defined Networking is a relatively new Architecture that is dynamic, financially effective, manageable and adaptable, which makes it perfect for the high-bandwidth, dynamic nature of nowadays’ applications. This Architecture decouples the forwarding functions and network control to become directly programmable (via so-called Software “Controllers”) and the hidden infrastructure to be set for applications and network services.
Another important feature of SDN is agility. Abstracting control from forwarding allows Administrators to adjust network traffic flow in order to meet changing needs. SDN is likewise centrally managed in the aforementioned Software-based network Controllers that keep an eye on the Network as whole, and are viewed by applications and policy engines as a single logical switch.
When implemented, SDN simplifies network design and the way packets operate and travel. This is achieved because instructions are distributed by SDN Controllers instead of many Vendor-specific Protocols and Devices.
SDN Attack Vectors
SDN represents a way to deal with networking that separates the control plane from the forwarding plane to support virtualization. SDN is a new “ideal model” for Network Virtualization. Most of SDN structures have 3 Layers – a lower Layer consisting of SDN Network devices, a middle Layer of SDN Controllers and a higher Layer which contains the Services and Applications for configuration of the SDN. Despite the fact that numerous SDN Systems are generally new and SDN is in its age of early adoption, one thing is certain, as this Technology evolves and is more widely used, it will turn into a target for hackers.
We can expect a few Attack Vectors on SDN Systems. The most common SDN Security concerns incorporate Attacks at the different SDN Architecture Layers. Let’s see the anticipated Attacks on each of these Layers.
1. Attacks at Data Plane Layer
Hackers could target the Network components from inside of the System itself. Theoretically, an attacker could gain unauthorized access to the Network or compromise a Host that is connected to the SDN and then conduct Attacks to destabilize System elements. These could be DDoS Attacks or perhaps a type of fuzzing Attack to attempt to hack the Network components.
There are various southbound APIs and Protocols used for communication between the Controller and Network elements (the most famous of which, on the other not the only, is represented by OpenFlow). Each of those Protocols has their own particular techniques of securing the communication between Network elements and the Controller. However, a large number of these Protocols (including OpenFlow) are quite new and they may not have been set up in the safest way possible.
A Hacker could likewise influence these Protocols and try to run new flows into the device’s flow-table. The Attacker would probably try to force new flows to allow particular types of traffic that should be forbidden all over the System. If the flow that permits certain types of traffic is created and used to get traffic through the Firewall, the Attacker would have a decisive advantage. If this type of Attack is conducted successfully, the Attacker could easily perform a Man in the Middle Attack to steer traffic in his direction.
Numerous SDN Frameworks are deployed within Data Centers frequently using Data Center Interconnect (DCI) Protocols for connections. These Protocols often lack Encryption as well as any type of Authentication to secure the Packet contents. Use of these new Protocols could pose vulnerability mainly due to the way the Customer or Vendor has implemented the protocol. DCI connections are very vulnerable to DDoS Attacks.
2. Attacks at Controller Layer
It is quite evident that the SDN Controller is a very good target for the Attack. There are several reasons why someone would try to target the SDN Controller. First off, the Attacker would want to start new flows by “spoofing” southbound messages sent towards the Network devices or “spoofing” northbound API messages. If the Attacker succeeds to “spoof” flows from the Controller then it gets the ability to control traffic flow across the SDN as well as to bypass Policies that may be applied for Security reasons.
A Crook might perform a DDoS on the Controller or use other methods to disable the Controller. Any type of Resource Consumption Attack would cause high damage to the Controller, making it at best extremely slow and almost completely unable to communicate.
Also, quite often SDN Controllers run on some type of Linux Operating System. If the SDN Controller runs on a widely used Operating System, then the vulnerabilities of that Operating System get to be vulnerabilities for the Controller. Very often the Controllers are put to work with default Passwords and without any Security Features configured. The reason behind this lies in the fact that the SDN Engineers barely made it (the Controller) to work so they didn’t want to change anything for fear of breaking it, which lead as a result to a vulnerable configuration.
Also, since it’s relatively new on the market, it is possible for the Attacker to create their own Controller and use it to trick Network components to believe that it is a legit Network Controller. This corrupt Controller wouldn’t be visible to the SDN Engineers, which means that it could easily take control of entire Network.
3. Attacks at SDN Layer
Attack on the Security perimeter of the northbound Protocol would likewise be a likely (and reasonable) Attack Vector. There are numerous northbound APIs that are used by SDN Controllers. If the Attacker could exploit the vulnerabilities of any northbound API, then the Attacker would have complete control over the SDN Network using the Controller. On the off chance that the Controller didn’t have any type of Security for the northbound API, then the Attacker may be able to make his/her own SDN Policies and therefore gain control of the SDN Network.
Very often, there is a default Password used for a REST API which is very easy to guess. If this default Password isn’t changed, then the Attacker could very easily make their own configuration of the SDN Network, replacing the existing one.
Securing a SDN System
As this presentation of SDN Security shows, a new mindset is required for securing the Control Plane traffic. In standard IP Networks the Control Plane Security is applied in the form of routing Protocols which include using certain Security measures such as MD5 for EIGRP, IS-IS, GTSM, Passwords and many others. Some Admins do not even apply these simple methods for securing standard IP Networks. If they approach arrangement of a SDN with the same nonchalance for Security, then there will be a lot of exposure to Attacks. Let’s consider possible ways of securing a SDN System through all three mentioned Layers.
1. Securing the Data Plane Layer
Ordinary SDN Systems use X86 Processors and TLS (former SSL) for securing the Control Plane. These enduring HTTP Sessions are vulnerable to an extensive variety of Attacks that could jeopardize the integrity of the Data Plane. This could cause Cloud-based Services to be compromised. Companies should use TLS to provide Authentication as well as Encryption for the traffic between Network Device and Controller.
2. Securing the Controller Layer
The Controller is a primary target for the Hacker’s Attacks and thus, it must be secured. Strengthening the Security of the Controller and the Network itself usually comes down to Host Operating System Security. All those practices for securing public Linux Servers can – and should – be used here. Anyhow, the Company will want to keep an eye on its Controllers for any suspicious activities.
Companies will likewise want to prevent unapproved access to SDN control System. SDN Frameworks should allow access to configuration panel of the Controller for authenticated Administrators. Indeed, even Role-Based Access Policies may be required for Controller Administrators in order to make it secure. Lastly, login log would be useful for checking for unapproved changes by Admins or Hackers of any kind.
3. Securing the SDN Layer
In order to secure the SDN Layer, a good protection measure might be to use an Out-of-Band Network for control traffic. It is far easier and less expensive to develop an Out-of-Band Network in a Server than over an Enterprise WAN. Use of an Out-of-Band Network for the southbound and northbound communications would be a great help in securing the Protocols related to Controller management.
Another method for securing communications and Controller management is the use of TLS or SSH. The communications should use Authentication as well as Encryption when the Applications and Services are requesting data from the Controller. Some SDN Systems have the ability to validate flows in Network Device tables against Controller policy. This kind of checking of flows could help recognize inconsistencies that are usually consequence of an Attack.
The SDNs are new. The deployments are new, the Controller Software is new, the Protocols are new… But they are the future of virtualized deployments. Securing the SDNs might pose a challenge, sure, but it is important that we don’t wait until the final clean-up phase. Like most things, setting it up right from the beginning will save us numerous problems down the road.
Share your story with us!