Day 3: SDN Controller Security

SDN has two features which are a possible sources challenges for operators who are less
prepared and attractive for malicious users. They are:
  1. ability to control the network through software which could be subject bugs and other security vulnerabilities
  2. centralization of “network intelligence” in controllers
Threat Vectors

The threat vectors that controller is vulnerable to might fall into one of these categories:
  • fake or forged traffic flows - includes any malicious content that is used to attack the controller, examples: DoS attacks, DDoS attacks, Ransomware attacks etc.
  • attacks on vulnerabilities in switches
  • attacks on control plane communications
  • attack on Controller vulnerabilities
  • lack of mechanisms for ensuring security between the management applications and controllers
  • attacks on vulnerabilities in administrative station
How to Secure Controllers?

To secure the controller we need to make sure we secure three aspects of the controller:
  • Securing the controller design - the processes running on the controller and how they can be made secure
  • Securing the controller interfaces - securing the controller communication with the data plane
  • Securing the services provided by controller - services provided like resource monitoring, secure logins, IDS/IPS, authentication and authorization.
To know more about each of the above points refer to this article. The article also suggests ways to increase robustness of the controller by replicating the controller information, having diverse controller environments running the same controller instance, including self-healing mechanisms to revive controller automatically and having a distributed network of controllers to reduce the risk and consequences of a single point failure.

What happens when Controller is Attacked?

When a controller is attacked, the minimum consequence that would happen is that the resources of controller is not all available to the legitimate processes running. Instead, the malicious attack takes up few of the resources thus making the controller less available and extremely slow. Worst case, the contents of the controller is copied and the malicious server poses as the controller and thus all hosts, switches associated with the controller becomes slaves to 'The Dark Lord'. 

There have been many approaches to  detect and stop these attacks. The few approaches taken so far are:
  1. Dropping packets from particular sources when under a DoS attack. The downside to this is that even legitimate packets can be dropped and these false positives could be costly wrt performance of the controller.
  2. Secure SDN architecture based on Byzantine Fault Tolerant (BFT) mechanisms to encounter malicious attacks on the control plane and maintain availability.
  3. Achieve scalability and reliability through proposing a cluster-based distributed OpenFlow controller framework using a master slave architecture
  4. elastic distributed controller architecture to maintain scalability and reliability
This article proposes a distributed controller architecture with a protocol with several components including a mapping algorithm, heart-beat messages, synchronization messages, take-over process, and protective mode. This approach is by far the most complete solution that I found.

But all these above solutions only concentrate on DoS attacks among the various threat vectors. In the further articles we shall see what other threat vectors can be addressed and also if DoS attacks can be addressed in a better way?

Comments

  1. Ram P RustagiJanuary 30, 2019 at 3:46 AM

    It would be helpful if you can further throw some light on how Byzantine Fault Tolerant mechanism works to deal with such attacks.
    Glad to see you studying all related stuff and doing a proper literature survey. On the right track

    ReplyDelete

Post a Comment

Popular posts from this blog

Day 12: Master Slave SDN Controller Architecture

In the previous post, I was struggling to figure out why all controllers can install flows in all switches irrespective of the code. Well, today the mystery is getting resolved. I found this book that explains beautifully the various roles that a controller can play. The three roles are: Equal : this happens by default all the equal controllers in a network that are connected to the switch can add and delete flows from it Slave: it has a read-only limitation to the switch openflow tables Master: very similar to the switch, but only 1 master can be connected to the switch at that point of time, and no other flows can intercept the communication between switch and master. I highly recommend you go through the above link to get a better picture. Since the default role of any controller is "Equal", we couldn't really differentiate between the three controller flows yesterday. But one good news from this is that we don't really need extensive coding to assi...
Read more

Day 1: Understanding Ransomware and how to detect them?

Image
To start this journey, let’s begin at the basics and learn about what ransomwares are, what is the meaning of a ransomware attack, how have other people detected it so far? By learning the above, we will be in a position to analyze any ransomware attack and devise methods to detect, mitigate and prevent them. Definition: Ransomware is a type of malicious software from cryptovirology that threatens to publish the victim's data or perpetually block access to it unless a ransom is paid. To continue understanding and addressing the threats posed by ransomware, let us dig a little deeper. As the definition specifies, ransomware is a type of malicious software. Now, what is a malicious software? Definition: Malware (= Malicious + Software) is a software which is specifically designed to disrupt, damage, or gain authorized access to a computer system. These malwares (or simply dangerous content that can corrupt your system), can enter your system from various s...
Read more

Day 50: Tcpreplay and tcpliveplay approach

Today we shall be exploring how to copy and redirect the OpenFlow packets to more than one controller from the load balancer. The load balancer is anyway sending the OpenFlow packets to one of the slave controllers - c1 or c2. The packets sent to these two controllers needs to be sent to master controller so the master controller can update the new flows added by c1 or c2 on the switches. This ensures synchronization between controllers. There are two implementation methods to achieve the same: Copy all packets generated from the load balancer to the controller side. Only the packets having destination IP address of c1 and c2 can be redirected to the master controller. Thus we can prevent the packets which already are reaching the master controller to be sent as duplicates Copy and redirect packets from the slave controllers - c1 and c2. We need not take care of duplicate packets reaching master controller. This will reduce the time taken to redirect packets. Since the second a...
Read more