Securing SDN Network using Distributed Controller and Real time Machine Learning

As explained in Day 59's post , we shall be continuing the project with detecting DoS attacks on the controller by the switch. We can monitor all switches from the controller and keep observing the bandwidth usages and bitrates of OpenFlow communications between switch and controller. The monitoring happens completely from the controller side. Each controller irrespective of whether it is responsible for installing flows in a particular switch can monitor it. A new TCP communication is established from the Ryu controller to the switch. This TCP connection is first used to get all switch statistics including flows. Then, it monitors the packets that flow in and out of a switch. This is the strategy behind monitoring. Once monitoring is done, we would concentrate on DoS attack detection. We shall do this in the next post. I've borrowed the monitoring code from Ryu controller Github page itself. I found this link helpful in understanding how to go about integrating the code....

Hey guys! Finally finished building the basic storm topology for extracting the following features. It took me 2.5 weeks to finish integrating kafka with and to build the topology. The features extracted so far, 1. Total Inflow Packets 2. Average Number of inflow packets (Total/Number of flows) 3. Total Number of flows 4. Total Packet length 5. Average packet length (Total/Number of packets) What next? I want to set up an ML model for analyzing the features in real time.  What are the hiccups along the way? 1. Are the input features enough? What more can be extracted? 2. Outflow features cant be utilized directly since there is a cyclic dependency with the outflow features.  3. Which ML model to build such that it doesn't slowdown the decision process? Should it be supervised or unsupervised? 4. How to improve accuracy once the model is built? I am reading up on existing real time ML models for networks. I shall be updating the solution soon on t...

The features built into the architecture so far: high sustainability of controllers when DoS attack occurs - due to switchover mechanism (high availability) avoiding single point of failures in load balancer and master controller dynamic learning of new flows scalability  synchronized controllers Thus in case any DoS attack happens from switch to controller, the distributed controller architecture can sustain this attack for a very long time. This was the purpose of the architecture from when we conceived the idea of building it. What other features should we be implement? an ML server - detection and decision regarding malicious packets (  watch out for Swati's blogs regarding this) this ML server must receive packets from load balancer using any pub-sub model like kafka and zookeeper architecture What other features can make our already existing architecture better? As a further enhancement to the architectural design, I have intended to add a component to d...

The controller architecture is now almost complete. It is highly available since the switch-over mechanism takes care of longevity of running controller even under a DoS attack. I tried to drop few packets in the load balancer based on the threshold as decided in the Day 45 's post. This would only mean dropping even legitimate packets and would increase the false positives. Thus I have decided not to pursue a thresholding mechanism before contacting the ML server. Suppose I already decide to drop few packets before contacting the ML server, the data sent to ML server would be incomplete and thus incorrect. Also, if a threshold is decided even before sending the data to the ML server, there will be some bias introduced in the dataset which the ML model wouldn't be aware of. Thus, I am dropping the idea of threshold from the implementation of a secure distributed SDN controller architecture. The only important phase left in the project is to check for scalability. If the ...

From the previous posts we can see that we have achieved a huge amount of the architecture we had set out to build! There was one scenario in the last article, which we have not attended to yet. That is - What if the master controller (which connects to all switches at some point or the other) faces a single point of failure? This is completely probable as master controller is connected to all switches and installs flows in all of them, even the ones that cause DoS attack on the controllers. Thus, we need to protect the master controller from single point of failure. We shall use the same approach as used in Day 45 to protect load balancer from single point of failure. Thus, we are going to need an additional computer in our network architecture that can act as a back-up master controller. We are going to use the keepalived tool for the same. My Github page has the code. You could refer to Day 45 's code and experiment yourself regarding what changes to be made to the code t...

The below is the newly implemented code for switch-over and synchronization between controllers: global     log /dev/log    local0     log /dev/log    local1 notice     chroot /var/lib/haproxy     stats socket /var/run/haproxy.stat mode 600 level admin     stats timeout 2m     user haproxy     group haproxy     daemon     # Default SSL material locations     ca-base /etc/ssl/certs     crt-base /etc/ssl/private     # Default ciphers to use on SSL-enabled listening sockets.     # For more information, see ciphers(1SSL). This list is from:     #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/     # An alternative list with additional directives can be obtained from     #  https://mozilla.githu...

In Day 50's article we familiarized ourselves with tcpliveplay and how to use the same to redirect OpenFlow packets to the master controller. Yesterday, I tried to create TCP connections from master controller to the switch from which the duplicated packets reached the master controller. These were few findings that made me rethink my tcpliveplay approach: Zodiac FX switch cannot forward packets to the required port if it is not connected to any controller. This is irrespective of whether the flows are already installed in it or not. Whenever a Zodiac FX switch contacts any controller, it informs the controller of all the flows it already has installed in it. Only new flows get installed from then on. Thus the controller automatically becomes aware of the previously installed flows. This does not take perceivable amount of time. The flows installed in the FX switch keep getting updated and this is the reason the FX switch needs to be connected to a controller at all times. F...