Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

SDN security attack vectors and SDN hardening

Scott Hogg | Nov. 12, 2014
Securing SDN deployments right from the start.

Similarly, depending on the Data Center Interconnect (DCI) protocol being used, there may be configurable options to authenticate tunnel endpoints and secure tunneled traffic.  Again, passwords/shared-secrets might be an option.  However, some DCI protocols may not have any option for security.

Organizations may believe that a private network has certain inherent security.  As organizations extend their virtual networks and SDNs to cloud services and to remote data centers, verifying the physical path may not be so easy.  Preventing unauthorized access is easier when an organization controls the physical access, but as networks virtualize, the actual physical path gets a little murky.  It is difficult to secure what you can't see.

2-2. Securing the Controller Layer
The controller is a key attack target and therefore, it must be hardened.  Hardening the security posture of the controller and the network elements typical comes down to host OS hardening.  All the best practices for hardening public-facing Linux servers are applicable here.  Still, organizations will will want to closely monitor their controllers for any suspicious activity.

Organizations will also want to prevent unauthorized access to SDN control network.  SDN systems should allow for configuration of secure and authenticated administrator access to controller.  Even Role-Based Access Control (RBAC) policies may be required for controller administrators.  Logging and audit trails could be useful for checking for unauthorized changes by administrators or attackers alike.

If there is a DoS attack of the controller, then it is beneficial to have a High-Availability (HA) controller architecture.  SDNs that use redundant controllers could suffer the loss of a controller and continue to function.  This would raise the bar for an attacker trying to DoS all the controllers in the system.  Besides, that attack would not be particularly stealthy and further the attacker's aims of remaining undetected.

2-3. Securing the SDN Layer
Another protection measure is to use an Out-of-Band (OOB) network for control traffic.  It is easier and less costly to construct an OOB network in a data center than across an enterprise WAN.  Using an OOB network for the northbound and southbound communications could help secure the protocols for controller management.

Using TLS or SSH or another method to secure northbound communications and secure controller management would be considered a best practice.  The communications from the applications and services requesting services or data from the controller should be secured using authentication and encryption methods.

Secure coding practices for all northbound applications requesting SDN resources should be a best practice.  Not only are secure coding practices beneficial to the security of public-facing Internet web applications, but they are also applicable to northbound SDN connections.

There are some SDN systems that have the ability to validate flows in network device tables against controller policy.  This type of checking (similar to FlowChecker) of the flows in the network devices against the policy in the policy could help identify discrepancies that are the result of an attack.

 

Previous Page  1  2  3  4  5  Next Page 

Sign up for Computerworld eNewsletters.