Securing SDN Network using Distributed Controller and Real time Machine Learning

In previous article, we discussed how to tackle DoS attacks on the controller initiated by the switch. We also saw the HAProxy configuration for the same. It is time for implementation now!!! In today's article, I have also given a video on how the network will be working by the end of the setup. To ensure that the Zodiac FX switch is contacting multiple controllers in case one of them fail, we can just configure the controller IP address on the Zodiac FX switch as the load balancer IP address. When I was going through few articles yesterday, I realized that there are many sorts of load balancing mechanisms. I was trying to do the DNS load balancing mechanism thus far. But after understanding the article, I realized that a server-side load balancer would be better for my scenario. And the only change I made to the setup already built to convert it into a server-side load balancer was changing the controller IP address on switch to 10.0.0.5. Although the architecture is working...

In the previous post, we have built the basic network. Let's remember the problem statement we are working on: Securing the SDN distributed controller architecture against DoS attacks specifically - Syn-Flood and Smurf attacks. Now, we have the basic SDN conroller architecture ready. We need to now concentrate on securing this network. Have a look at the architecture we have built so far(an implementation oriented diagram): Let's start with detecting Syn-Flood attacks on the load balancer. Why the load balancer? The reason is that all packets have to go through it and if any controller is under a DoS attack, we can come to know about the same from observing packets that the load balancer has to forward to the controller pool. I have already implemented Syn-Flood attacks on the controllers and stored the tcpdump data in 2 of my files. ping.txt consists of packets generated in a normal scenario when the switch has not installed any flow tables and contacts the controller...

As discussed in previous article, we shall be achieving what we wanted to on Day 36 , by manually assigning VIPs to our load balancers. Once I figure out how to use keepalived, I shall automate the process of switching between master and slave load balancer. Please refer to the video to refer to the architecture we shall be building. The configuration details are as given below: The configuration of switches, controller and hosts remain as given in previous posts. Only load balancer cum router configuration has changed from the last few posts: > sudo ip addr add 10.0.0.10/24 dev enp2s0 > sudo ip addr add 20.0.0.10/24 dev eth2 > sudo ifconfig enp2s0 10.0.0.5 netmask 255.255.255.0 > sudo ifconfig eth2 20.0.0.5 netmask 255.255.255.0 > sudo sysctl -w net.ipv4.ip_forward=1 > sudo sysctl -w net.ipv4.conf.all.send_redirects=0 On active load balancer: > arping -q -U -c 3 -I enp2s0 10.0.0.5 > arping -q -U -c 3 -I eth2 20.0.0.5 My previous post explains ...

More often than not, I realize that I need to refresh my basic networking knowledge when faced by problems in building my current architecture. This post is meant for only that reason and also to share a few enlightening insights I got to know today. Did you know that ARP was a layer 3 protocol and not a layer 2 protocol? If no, you have been learning the wrong thing so far. ARP is indeed a layer 3 protocol. ARP protocol serves the purpose of mapping the IP address to the device’s MAC address. Hence, it needs to know IP mapping of the systems as well. How would a layer 2 protocol possibly know about IP address and device mapping? Thus ARP protocol which resolves the mapping between IP and MAC is a layer 3 protocol. How to build a basic network with routers, switches and hosts? We have worked on this subject over the last few posts. If you have been following the blog, you would know that we have established the network and ran specific commands to achieve a similar network. We...

In the previous posts we had discussed the implementation architecture and also built it to a fairly good extent. Now, it is time to consider what would happen if the load balancer faces a single point of failure. We need to have a standby load balancer that can become active once the master load balancer is down. As explained yesterday, we shall be looking into Keepalived for the same. Today, I started to implement a new version of the architecture keeping in mind the introduction of a new system to the architecture which would act as the standby load balancer. So, the new architecture I started implementing today is something like this: These were the diffculties I faced with the above architecture: The controller needs to be configured with one static route to go to the Router subnet. This is possible only by giving a the next hop as the load balancer that is active at that instant. Since it is a static route, the configuration was not possible As a consequence to the...

In the previous post we had discussed few problems we were facing with the working of the architecture. To be precise, it was regarding why the switch was not accepting packets from the backup controller even after traffic redirection from the load balancer. Well, since we have configured the controller IP address on the switch already, the switch expects to receive no packets from controllers bearing any other IP address. So, how do we deal with this problem? We can introduce a NAT functionality on the load balancer that changes the IP address when the packets go from the switch subnet to the controller pool subnet. This way, even though the request may not be answered by a controller of a specific IP address, it can pose like it has that IP address. We shall be taking this up for implementation next week. Now, we shall first have to concentrate on securing our load balancer with a standby system that can act as backup when the load balancer goes down. There is something called ...

Today, we shall get into the implementation details of the architecture that was explained in the last article. The load balancer code is as follows: frontend ft_web     bind 10.0.1.2:6633      default_backend bk_web backend bk_web     balance source#for IP Affinity     server c1 10.0.0.7:6633 check     server c2 10.0.0.8:6633 check     server c3 10.0.0.9:6633 check     server c0 10.0.0.6:6633 check backup In the above code, we are asking the load balancer to listen to the interface 10.0.0.2 which belongs to the same machine as that of the load balancer. We are also specifying on which port listening should happen. Since OpenFlow protocol standard is to communicate over port 6633, we have mentioned the same. We have mentioned the default backend servers that the switches can access - c1, c2 and c3. c0 is also a backend server that acts as a backup controller in case one or many of them fail. The bac...