It is a fact, corporations are looking towards Software Defined Networks (SDN), but something keeps troubling their peace of mind…their network security. Software defined network attacks are unfortunately a reality nowadays, so let’s see how they try to breach into the network.
Many things have been said about the ability of SDNs to solve security problems. However this technology is still unfamiliar to many network engineers, the history of attacks is unknown and thousands of undiscovered vulnerabilities are out there.
This article focuses on classifying SDN-related attacks. Nine potential security threats and their counter-measurements are analyzed based on the 3 planes of the SDN architecture (Data, Control and Application).
Traditional vs. Software-defined Networks
By abstracting network-related services, a network engineer can have more flexibility and accuracy when configuring a service. SDN use cases from the real world can be found here.
In traditional networking, the control plane and data plane exist on each device. SDN on the other hand, abstracts this concept and separates the two planes. To add flexibility, the control plane is placed directly on a SDN controller which can be a Linux server running SDN software and Data plane is located on a physical or virtual switch. The SDN controller becomes a critical component that tells switches how to forward data packets. Both planes can communicate through a protocol such as OpenFlow.
In addition to allowing a flexible network, SDN also brings programmability and simplicity to the network management. With these benefits, SDN could easily replace traditional networks. But given how this trend is changing, how could an organization implement a secured SDN and protect from unfamiliar vulnerabilities and exploits?
From a security point of view, the mere separation of control and data planes in SDN could improve the network. Instead of the evenly distributed traditional networks, now the entire network is controlled by a single point of control, or from a hacker’s point of view “a high value asset”.
Software Defined Network attacks
Centralized controller: a high-value target
New network technologies can introduce threats that didn’t existed before or it can even make things worse. Besides the existing attack vectors on traditional networks, the controllers and the connections to the control plane bring new security challenges that are unique to the SDN. A single vulnerability could cause a lot of damage, so security should be a basic component built into SDN. By compromising the SDN controller, a hacker could have total control of the network. Hackers go for a high-value target, so leaving the controller as a single point of failure is not such a good idea.
By centralizing the control plane, the SDN can provide excellent control over the entire network but it can also increase the workload of the administrator since the security must be deployed manually.
Programmability: a double-edged sword
To increase automation and flexibility, centralization allows networks to be easily programmed. This network programmability is the nature of SDNs. However when an interconnected system is introduced where its fundamental operations are delegated to programmable software, new vulnerabilities are invariably introduced.
SDN is exposed to more risks when it offers programmatic access to users. Consider the case where users are forced to “trust” and depend on third party applications or standard-based solutions with the keys to the network. Another case is where control information and management of network elements might be exploited if isolation is not properly implemented.
Nine types of attacks in SDN
The evolution of networks is creating new types of attacks, identified and unidentified risks and zero-day exploits. For now, there is no history of past SDN real-case attacks so it is challenging to define existing vulnerabilities and build security from that. Meanwhile a classification of potential attacks can be made in order to be used as a reference and lay the ground for security. Figure 1 shows the SDN architecture along with its possible attacks vectors (in red).
- Network Manipulation: A critical attack that occurs on the control plane. An attacker compromises the SDN controller, produces false network data and initiates other attacks on the entire network.
How to protect: To mitigate this attack, the SDN controller should have a redundant entity and the communication channels should be protected using strong encryption.
- Traffic diversion: This attack occurs to the network elements at the data plane. The attack compromises a network element to redirect traffic flows and allow eavesdropping.
How to protect: Secure network elements and its communication channels with strong encryption.
- Side channel attack: The network elements at the data plane can be the target of this attack. Timing information, such as how long a new network connection takes to establish, can inform an attacker if a flow rule exists or not.
How to protect: Secure network elements with strong an encryption algorithm.
- App manipulation: This attack takes place in the application plane. An exploit of application vulnerability could cause malfunction, disruption of service, or eavesdrop of data. An attacker could gain access with high privilege to an SDN application and perform illegal operations.
How to protect: Keep servers updated with latest patches.
- Denial of Service “DoS”: This is one of the most common attacks and can affect all parts of the SDN. By applying a DoS, an attacker could cause reduction or complete disruption of SDN services.
How to protect: Use rate limiting and packet dropping techniques at the controller plane.
- ARP Spoofing Attack: A Man-in-the-middle attack which is also called ARP cache-poisoning. A hacker can use an ARP spoofing to infiltrate the network, sniff traffic, modify it and even stop it. This type of attack corrupts the network topology information and the topology-aware SDN applications. Poisoning can also happen through other protocols such as LLDP or IGMP.
How to protect: It is recommended to use strong authentication methods.
- API exploitation: The APIs of a software component might contain vulnerabilities that can allow a hacker to perform an unauthorized disclosure of information. API exploitation can also happen at the northbound interface and can lead to the destruction of network flows.
How to protect: Keep servers updated with latest patches.
- Traffic sniffing: A sniffing attacks is a popular method used by hacker to capture and analyze network communication information. With sniffing, a hacker is also able to eavesdrop data from network elements or links and steal important information. Sniffing can happen anywhere where there is constant traffic. In SDN a hacker can take advantage of unencrypted communications to intercept traffic from and to a central controller. The data captured could include critical information on flows or traffic allowed on the network.
How to protect: Use a strong encryption method.
- Password guessing or brute force: This attack can happen on a non-SDN element. With password guessing or brute force, an unauthorized user could gain access to the SDN.
How to protect: Change vendor default passwords, use strong passwords and frequently update them.
Can SDN enhance security?
SDN deployments are still immature and it is difficult to foresee how attackers will target SDN infrastructure. The knowledge on SDN attacks and threats is very limited. What we’ve seen and learned so far in the history of cyber attacks and counter-attacks in traditional networks is that new technologies come along with new vulnerabilities.
To fully commit to SDN, some security challenges need to be taken care of, such as network centralized control and programmability features. But technology is not going to take us backwards in time, SDN is gaining popularity and its improvements are happening extremely fast. With SDNs is probable that we are going to see a lot more security benefits compared to traditional networks.
For now we can learn from the past and prepare a security plan before migrating to SDN. It is not so easy to learn from mistakes when the whole corporate data is at the hands of a new technology.