This chapter covers Software-Defined Networking (SDN) security, a critical topic for the Security+ SY0-701 exam under Objective 3.1 (Security Architecture). SDN decouples the control plane from the data plane, introducing new attack surfaces and defense strategies. You will learn how SDN works, its security implications, and how to protect SDN deployments. Understanding SDN security is essential for modern network defense, as many enterprises adopt SDN for flexibility and automation.
Jump to a section
Imagine a major airport. In a traditional network (like a non-SDN airport), each airplane (data packet) must communicate directly with every other plane and ground crew to navigate the runways. Pilots (switches) make their own routing decisions based on local signs (MAC tables) and broadcast messages. This is chaotic, inefficient, and prone to collisions or misrouting. Now consider an SDN airport: there is a central control tower (the SDN controller) that has a complete view of all aircraft, runways, gates, and weather conditions. Pilots no longer make independent decisions; they simply request a path from the tower, which calculates the optimal route and instructs each plane exactly when and where to taxi, take off, or land. The tower communicates with pilots via a standardized radio frequency (the southbound API, e.g., OpenFlow). The tower itself can be updated by airline operations (northbound API) to adjust schedules or security protocols. In this analogy, an attacker might try to spoof the tower's radio signal (controller hijacking) to send false instructions, causing planes to collide (network disruption) or land at the wrong gate (data exfiltration). Alternatively, an attacker could compromise a single pilot (switch) to ignore tower commands (flow rule tampering). The security mechanisms include authenticating all tower-pilot communications (TLS, certificate-based), monitoring for anomalous flight paths (flow analysis), and having a backup tower (controller redundancy) to take over if the primary is compromised. Just as an airport must secure its control tower, an SDN must harden its controller, APIs, and the software that defines network behavior.
What is Software-Defined Networking (SDN)?
Software-Defined Networking (SDN) is a network architecture that separates the control plane (decision-making) from the data plane (packet forwarding). In traditional networking, each switch or router makes forwarding decisions independently using distributed protocols (e.g., OSPF, STP). SDN centralizes the control logic in a software-based controller that programs the data plane devices via standardized interfaces. This centralization enables dynamic, programmable network management.
SDN Architecture Components
SDN architecture consists of three layers: - Application Layer: Contains network applications (e.g., firewall, load balancer, monitoring) that communicate with the controller via northbound APIs. - Control Layer: The SDN controller (e.g., OpenDaylight, ONOS, Ryu) that maintains a global network view and makes forwarding decisions. - Infrastructure Layer: Physical or virtual switches (data plane devices) that forward packets based on flow rules installed by the controller.
Communication between layers uses two key interfaces: - Northbound API: Between applications and controller (often RESTful). - Southbound API: Between controller and switches (commonly OpenFlow, but also NETCONF, OVSDB).
How SDN Works Mechanically
A packet arrives at an SDN switch.
The switch checks its flow table for a matching rule. If no match, it sends a Packet-In message to the controller via the southbound API.
The controller computes the appropriate path (using its global view) and installs flow rules on the switch via Flow-Mod messages.
Subsequent packets matching the same flow are forwarded directly by the switch without controller involvement.
This process is defined in the OpenFlow specification (e.g., OpenFlow 1.3, RFC 7047). The controller can proactively install rules or reactively respond to traffic.
Security Threats in SDN
SDN introduces unique attack vectors: - Controller Hijacking: Attacker gains control of the SDN controller, allowing them to manipulate the entire network. This could be via exploiting software vulnerabilities (e.g., CVE-2018-1000158 in OpenDaylight) or weak authentication. - Flow Rule Tampering: Attacker modifies or injects malicious flow rules on switches, bypassing security policies or redirecting traffic. - Southbound API Attacks: Eavesdropping or spoofing OpenFlow messages if TLS is not enforced. - Northbound API Attacks: Exploiting insecure REST APIs to reconfigure the network. - Switch Compromise: An attacker with access to a switch can ignore controller commands or report false statistics. - Denial of Service (DoS): Flooding the controller with Packet-In messages (e.g., using new flows) to overwhelm the control plane.
Defense Mechanisms
Controller Hardening: Use secure coding practices, regular patching, and role-based access control (RBAC). Deploy redundant controllers (e.g., using RAFT consensus) to ensure high availability.
Encrypted Southbound API: Always use TLS for OpenFlow (port 6633 or 6653). Verify certificates.
Flow Rule Integrity: Use signed flow rules or integrity checks. Monitor flow table changes via audit logs.
Northbound API Security: Authenticate API requests (OAuth 2.0, API keys), use HTTPS, and implement rate limiting.
Switch Authentication: Each switch must authenticate to the controller using certificates or shared secrets.
DoS Mitigation: Rate-limit Packet-In messages, use flow aggregation, and deploy controller load balancers.
Tools and Commands
- Open vSwitch (OVS): Common virtual switch supporting OpenFlow. Commands:
- ovs-vsctl show – view switch configuration.
- ovs-ofctl dump-flows br0 – list flow rules.
- ovs-ofctl add-flow br0 "in_port=1,actions=output:2" – add a flow rule.
- Wireshark: Capture OpenFlow packets (port 6653) to analyze controller-switch communication.
- FlowVisor: Network virtualization layer that slices the network, isolating tenants.
Standards and References
OpenFlow 1.3 (ONF TS-007)
RFC 7047 (OVSDB Management Protocol)
NIST SP 800-207 (Zero Trust Architecture) – SDN as an enabler.
Real-World Example: CVE-2018-1000158
A vulnerability in OpenDaylight's AAA (Authentication, Authorization, Accounting) service allowed remote attackers to bypass authentication and gain admin access. This could lead to full network compromise. Mitigation: upgrade to patched version (Carbon SR3).
1. Reconnaissance – Identify SDN Components
The attacker scans the target network for signs of SDN, such as OpenFlow-enabled switches or known controller ports (e.g., 6633, 6653). Tools like Nmap with service detection (`nmap -sV -p 6633,6653 <target>`) can reveal the controller. The attacker may also probe for northbound API endpoints (e.g., REST API on port 8080). Logs: network scans may appear in firewall logs; controller logs may show connection attempts from unknown IPs.
2. Attack Vector – Exploit Weak Southbound API
If the southbound API is not using TLS (plain TCP), the attacker can intercept OpenFlow messages (e.g., Packet-In, Flow-Mod). Using Wireshark or mitmproxy, the attacker captures or modifies messages. For example, they can inject a Flow-Mod to redirect traffic to a malicious server. Alternatively, they can spoof a switch identity and connect to the controller. Logs: abnormal flow rule changes; controller logs may show multiple new switch connections from unknown IPs.
3. Exploit – Install Malicious Flow Rules
The attacker sends crafted Flow-Mod messages to the switch, adding rules that forward sensitive traffic (e.g., SSH, HTTPS) to an attacker-controlled host. For example: `ovs-ofctl add-flow br0 "tcp,tp_src=22,actions=output:3"` would redirect SSH traffic. The switch may accept the rule if the attacker has control of the controller or if the southbound channel is unauthenticated. Logs: flow table audit logs show new rules from unexpected sources; network traffic analysis shows data leaving the network to unknown destinations.
4. Exfiltration – Extract Data
With traffic redirected, the attacker captures data (e.g., credentials, files). They may also use the compromised switch to send copies of packets to an external server. The attacker can remain stealthy by deleting the malicious flow rule after exfiltration. Logs: outbound connections to unknown IPs; IDS/IPS may detect data exfiltration patterns (e.g., large file transfers).
5. Cover Tracks – Remove Evidence
The attacker sends a Flow-Removed message or overwrites the malicious flow with a benign rule. They may also reset the switch's connection to the controller to clear logs. If the controller logs are not centrally stored, the attack may go unnoticed. Logs: missing flow rules in audit trail; sudden disconnection of switch from controller.
Scenario 1: SDN Controller Compromise at a Data Center
A large cloud provider uses OpenDaylight to manage thousands of virtual switches. An attacker exploits a vulnerability in the northbound API (CVE-2019-12105) to gain admin access. The analyst sees unusual API calls in the controller logs (e.g., creating many virtual networks). The correct response: immediately isolate the controller, revoke API keys, and revert to a known good backup. Common mistake: assuming it's a misconfigured application and not investigating further, allowing the attacker to install backdoor flow rules.
Scenario 2: Southbound API Sniffing in a Campus Network
A university's SDN deployment uses plain TCP for OpenFlow. A student on the same network uses Wireshark to capture OpenFlow messages and learns the controller's IP. They then send a spoofed Packet-In message that causes the controller to install a rule redirecting all DNS queries to a rogue DNS server. The network administrator notices slow internet and DNS errors. Using tcpdump -i eth0 port 6653, they see unencrypted OpenFlow traffic. The fix: enable TLS on the southbound channel and deploy certificate-based authentication. Common mistake: blaming the DNS server without checking the SDN control plane.
Scenario 3: Flow Rule Tampering via Switch Access
An attacker gains physical access to a switch in a retail store's SDN network. They connect a laptop to the management port and use ovs-ofctl add-flow to insert a rule that copies all credit card traffic to an external IP. The security team notices an increase in outbound traffic to an unknown IP. They use ovs-ofctl dump-flows br0 on a known good switch to compare flow tables and spot the rogue rule. The correct response: remotely wipe the switch's flow table and revoke its controller authentication. Common mistake: only blocking the IP address without removing the root cause (the compromised switch).
Exactly What SY0-701 Tests
For Objective 3.1 (Security Architecture), the exam expects you to:
Explain the separation of control plane and data plane in SDN.
Identify security risks: controller as single point of failure, southbound API attacks, flow rule tampering.
Recognize mitigation techniques: encrypted southbound API, controller redundancy, RBAC, flow integrity checks.
Understand the role of SDN in network segmentation and microsegmentation.
Common Wrong Answers
"SDN eliminates all network security issues" – Candidates choose this because SDN centralizes control, but it introduces new attack surfaces. Wrong: SDN still requires security controls.
"The data plane makes all forwarding decisions" – Confusing SDN with traditional networking. In SDN, the control plane (controller) makes decisions.
"OpenFlow is a northbound API" – OpenFlow is the most common southbound API. Northbound APIs are for applications.
"SDN switches cannot be compromised" – Switches are still vulnerable to physical attacks or software exploits.
Specific Terms to Know
Control Plane: Makes decisions (where traffic goes).
Data Plane: Forwards traffic based on decisions.
Southbound API: Between controller and switches (e.g., OpenFlow).
Northbound API: Between applications and controller.
Flow Table: Contains rules for packet handling.
Packet-In: Message from switch to controller when no flow match exists.
Flow-Mod: Message from controller to switch to add/modify flow rules.
Trick Questions
Question: "Which plane is responsible for forwarding packets?" – Answer: Data plane. But candidates may say control plane.
Scenario: "An attacker sends many new flows to the controller. What attack is this?" – Answer: DoS on the control plane. Candidates might say data plane attack.
Comparison: "SDN vs. traditional networking" – SDN centralizes control; traditional distributes it.
Decision Rule for Scenario Questions
If a question describes a network where a central system controls switches, it's SDN. If the attack involves the controller being overwhelmed, it's a control plane attack. If the attack involves modifying switch rules, it's flow rule tampering. Look for keywords: "controller," "OpenFlow," "flow table." Eliminate answers that mention distributed routing protocols (OSPF, BGP) as those are traditional networking.
SDN separates the control plane (decision-making) from the data plane (forwarding).
The southbound API (e.g., OpenFlow) connects the controller to switches; should use TLS on port 6653.
The northbound API connects applications to the controller; should use HTTPS and authentication.
Key threats: controller hijacking, flow rule tampering, southbound API eavesdropping, DoS on controller.
Mitigations: controller redundancy, encrypted southbound API, RBAC, flow integrity monitoring.
OpenFlow 1.3 is a common southbound protocol; Packet-In and Flow-Mod are key message types.
SDN enables microsegmentation and dynamic network policies.
Always authenticate switches to the controller (e.g., certificates).
Monitor flow table changes regularly using audit logs.
SDN is not inherently secure; proper hardening is essential.
These come up on the exam all the time. Here's how to tell them apart.
Traditional Networking
Control and data planes are coupled in each device.
Routing decisions are distributed (e.g., OSPF, BGP).
Configuration is device-by-device (CLI).
Scaling requires manual changes on each switch.
Security relies on per-device ACLs and firewall rules.
Software-Defined Networking (SDN)
Control plane is centralized; data plane is separate.
Routing decisions are made by the controller.
Configuration is centralized via software (northbound API).
Scaling is easier: update controller to affect all switches.
Security policies can be enforced globally via flow rules.
Mistake
SDN is only for data centers and cloud providers.
Correct
SDN is used in enterprise campus networks, WANs (SD-WAN), and even home networks. Security+ covers SDN as a general architecture concept, not limited to one environment.
Mistake
OpenFlow is the only southbound protocol for SDN.
Correct
While OpenFlow is the most common, other protocols like NETCONF, OVSDB, and P4 are also used. The exam focuses on OpenFlow as the primary example.
Mistake
SDN controllers are always secure by default.
Correct
Many controllers have default credentials or unencrypted channels. Hardening is required. The exam emphasizes that southbound APIs should use TLS.
Mistake
SDN eliminates the need for firewalls.
Correct
SDN can implement firewall functionality via flow rules, but dedicated firewalls are still used. SDN does not make other security controls obsolete.
Mistake
The control plane and data plane are physically separate devices in SDN.
Correct
They are logically separated. The controller can be software running on a server; switches are separate devices. The separation is architectural, not necessarily physical.
The control plane makes decisions about where traffic should go (e.g., routing). The data plane forwards packets based on those decisions. In SDN, the control plane is centralized in the controller, while the data plane remains in the switches. This separation allows dynamic, programmable network management.
OpenFlow uses TCP port 6653 (officially assigned by IANA). Earlier versions used 6633. The exam expects you to know port 6653 for southbound API communication.
If the southbound API is not encrypted (plain TCP), an attacker can eavesdrop on OpenFlow messages to learn network topology, or inject malicious Flow-Mod messages to redirect traffic. Mitigation: always use TLS and authenticate both controller and switches.
A Packet-In message is sent from an SDN switch to the controller when a packet arrives that does not match any existing flow rule. The controller then decides how to handle the packet and may install a new flow rule. An attacker can flood the controller with Packet-In messages to cause a DoS.
Yes. SDN enables microsegmentation by allowing fine-grained flow rules that isolate traffic between workloads. The controller can enforce policies such as 'only allow HTTP traffic between web server and database.' This is more flexible than traditional VLAN-based segmentation.
The northbound API allows applications (e.g., security monitoring tools) to interact with the controller. If insecure, an attacker could exploit it to reconfigure the network. Security measures include API authentication (OAuth, API keys), HTTPS, and rate limiting.
No. SDN centralizes control, which can improve visibility and policy enforcement, but it also introduces a single point of failure and new attack surfaces. Proper security controls (encryption, authentication, redundancy) are essential.
You've just covered Software-Defined Networking Security — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?