story.tex 9.91 KB
Newer Older
1 2
\title{Elastic network anomaly prevention, detection and
    mitigation using SDN and Cloud}
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
3 4 5 6 7 8 9 10 11 12 13
    Praveen Kumar Shanmugam\\
    School of Computing\\
    University of Utah


Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
15 16 17 18 19


    First Draft for ACM SIGCOMM Workshop on Distributed Cloud Computing (DCC 2014)
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

The main goal of the system is to make the IDS management simple and automated
in a core network. Our approach uses the capability of Software Defined Network
(SDN) to manage the network from a single point and leverage the elasticity of 
the cloud computing resource and build a generic framework for the IDS management.

The current campus and enterprise networks have a huge network for the
internal and external users. When these kind of network are created the
security of the network is the main factor which comes along with the
designing and maintenance. The cost incurred for providing the security is
higher than the core network installation cost. The network is always
constantly monitored and the anomalies are detected by Network Intrusion 
Detection Systems either using signature based detection or rule based approach. 
When these rules are hit the IDS send out an alert for the network security
administrator and they choose to take further actions.

When ever they want to tap on a single port, then the mirror has to be
installed manually along with new IDS system. Usually there are few key points
that are monitored constantly. But when there are multiple points that needs
to be monitored on the fly, it is very hard to achieve that with the current

\section{Proposed Solution}
With the Software Defined Network and Cloud Computing Network it is possible
to achieve the monitoring capability in an automated way. The IDS can be
instantiated whenever necessary in the cloud leveraging the elasticity
property of the cloud. The SDN makes it possible to install flows to mirror
the traffic at any point and deliver it to the IDS instance. With these two
possibilities the mirroring can happen at specific alerts from the IDS hence
making it a scale able approach.
With multiple core network sites being maintained at multiple points, the
cloud at each site can be used to make it scale more than the current site's
capability assuming that these sites are connected using Software Defined
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
58 59

\section{Campus Network}
The campus network is shown in the Architecture Diagram 1.0.
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
61 62 63 64 65 66 67 68 69 70 71 72 73
The Campus Gateway (CG) serves as the entry point of the core network in which all
the inbound and outbound traffic passes through. The Campus Cloud Gateway
(CClG) forms the boundary between the campus core network and the Campus Cloud
Network. Cloud Compute Gateway (ClCG) acts as the entry for point for the
cloud traffic.\\

The Cloud consists of Cloud Controller which manages instances in it and it
also has a SDN controller inside the cloud which spans through out the cloud
network devices within it.\\

The Campus Core network also has an SDN controller which spans across the core
network devices.\\

74 75

Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
\section{CNAC Interface}
The framework consists of a Cloud and Network Access Controller (CNAC) module which forms
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
78 79 80
the brain of the framework. CNAC interfaces with the Cloud Controller and
the Cloud SDN Controller for controlling the IDS instances and network path
for that instance. Without the access to the network in the Cloud for the IDS
instance it is very difficult to deliver the traffic of interest exactly like the
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
82 83 84
packet which reaches the destination without manual setup.
CNAC Interface also controls the Campus SDN Controller to enable the tap
points and install/delete flows based upon the CNAC commands to help monitor
the traffic of interest or mitigate the attack.
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
86 87 88

One primary instance to monitor the traffic constantly. And there will be a
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
standby instances ready to monitor rather than instantiating newly. When these
standby's are used then a new instance will be spawned. This is just to make
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
92 93
sure that we react to the situation as soon as possible.

94 95 96 97 98 99 100
The IDS monitoring is to be done using Security Onion. It is a Linux distro which forms a generic framework to plug different IDS (Intrusion Detection System) and NSM (Network Security Monitoring) tool. This also supports ELSA (Enterprise Log Search and Archive) which is a query tool
for looking at all of the supported IDS and NSM logs through the single
interface. It works in server client model where multiple clients can be
spawned and made to push the logs to the centralized server. This architecture
makes it less tedious to get the alerts from the IDS for the decision making.

Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed

102 103 104 105
The overall architecture diagram doesn't show the firewall as the placement of
firewall can be before or after the campus gateway. Though the expectation of
the firewall is to filter out all the malicious traffic but there is no
guarantee that a legit traffic can cause malicious behavior.
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed

107 108
The proposed framework consists of a closed loop mechanism which has two parts. 
One the instance creation and the second the
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142
network changes for reacting to the alert. As of now there is no defined way
to have specific actions for some alerts and it is well beyond the scope of
this project. Requires extensive machine learning and extensive parsing rules
and an important thing will be the false positive actions.
We'll be concentrating on the cloud instance creation for the taps rather than
taking network level actions.

Few cases for new instance creation are heavy load to one IDS, drastic alert
from single source like a flood of TCP connection. Should come up with various
such cases. This will be good enough to start off with.

\subsection{Networking Part}
Flowvisor cannot used as it doesn't€™t allow flows to be created when there is a
conflict arrives. This is exactly what we want to accomplish but without
changing the behavior or the existing network.\\

The main controller which controls the core network will not be touched. RYU
controller which is to be used by our CNAC interface will do the job of
pushing and pulling flows. The communication as of now is done by REST APIs or

The system knows all the ports in each switch which are dedicated for the IDS
traffic route. Given the tap point the CNAC will form a graph in which
switches the flows are to be installed, then it compares it with the existing
flows in each of the switch and tries to come up with the equivalent rules
which makes the tapping to happen but preserving the existing behavior of the
core network's€™s service traffic.\\

The modified rules and the added rules are to be maintained by the CNAC when
the tapping has to be removed.

\subsection{Cloud Part}
Flowvisor can be used in the cloud part which we want the traffic to be
isolated and delivered to the specific VM without affecting the others
143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204
traffic. The cloud is to be given the capability to accept the type of traffic
that needs to be delivered to the VM based on the 5 tuple data format given to
it. The API that are to be implemented are as follows.
    \item \textbf{incomingTrafficSet(traffic, VM)} : Delivers the specified traffic
        type to the VM. This is a user level API.
    \item \textbf{fanoutTrafficSet(networkNode, traffic, outPorts)} : Forward
        the traffic at the given network node to all the output ports. This is
        a system level API.
\section{Cloud Networking}
For creating virtual networks between cloud tenants in the cloud. This is
achieved using SDN which are used in two places.
    \item For the TOR control to connect physical machines using internal network.
    \item Physical Machine runs openvswitch to connect to different VMs.

The current API's provided by OpenStack uses SDN to achieve the network,
subnet and port abstraction. These also provide firewall rules to handpick the
traffic type to the VMs.\\

This allows tenants to create private network inside the cloud. These are achieved
using OpenFlow rules using VLANS and GRE tunneling.\\

Though it uses SDN controllers we can't get our hands directly on the controller.
These are controlled by REST APIs from OpenStack Quatum Server based upon
the requests. Openstack had to be tailed to make these SDN controller accept rules based on our
The cases that are to be considered that other VM traffic are not matched
against these rules. To enable such behavior flowVisor can be used inside the

\subsection{OpenStack Neutron - SDN}
This is followed by openstack which uses SDN in its underlying network.

\subsection{Amazon Virtual Private Cloud}
These also try to provide the user with the same functionality but the
underlying architecture is a closed one. This again the network is with the cloud
between the same administrative tenants.

\section{Related Work}
\textbf{SDN in Cloud}\\
The paper talks about using OpenFlow to create a virtual network
abstraction for the tenants. This is what OpenStack Neutron does.
  \item An OpenFlow based Network Virtualization Framework for the
  \item Cloud orchestration with SDN/OpenFlow in carrier transport
  \item Cloud computing networking: challenges and opportunities for

\textbf{Multi-Site Work}
    \item Cloud Service Delivery Across Multiple Cloud
        Platforms~\cite{6009336} is a work in progress infrastructure to connect multi site tenants. This
        is achieved by OpenFlow switches connecting the site and installing flows based on
        the connectivity requirements of the services.
Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
205 206

207 208

Praveen Kumar Shanmugam's avatar
Praveen Kumar Shanmugam committed
209 210 211