draft1

parent 7b36130f
\title{First Draft for ACM SIGCOMM Workshop on Distributed Cloud Computing (DCC 2014)}
\author{
Praveen Kumar Shanmugam\\
School of Computing\\
University of Utah
}
\date{\today}
\documentclass[12pt]{article}
\usepackage{graphicx}
\usepackage{hyperref}
\begin{document}
\maketitle
\begin{abstract}
Title: Elastic network anomaly prevention, detection and
mitigation using SDN and Cloud
\end{abstract}
\section{Introduction}
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.
\section{Motivation}
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
infrastructure.
\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
Network. [Ref:
\url{http://ieeexplore.ieee.org/xpls/abs\_all.jsp?arnumber=6009336}]
\section{Campus Network}
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.\\
\section{CNAC Interface}
We introduce a Cloud and Network Access Controller (CNAC) module which forms
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 just like the
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 or mitigate the attack.
\section{Architecture Diagram 1.0}
\centerline{\includegraphics[width=1.1\textwidth]{ElasticIdsArch.jpg}}
\section{Implementation}
One primary instance to monitor the traffic constantly. And there must be
standby instances ready to monitor rather than instantiating newly. When these
standby's are used then a new instance to be spawned. This is just to make
sure that we react to the situation as soon as possible.
We are looking into BRO IDS as it is easy to add rules to alert when something
goes out of normal. The catch is that these rules are handcrafted.
Another thing to consider is the traffic that is tapped before the firewall
and after the firewall. The traffic after the firewall is always considered to
be safe but it may not be the case in few.
Closed loop has two parts. One the instance creation and the second the
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.
Another thing to look out for is that Security Onion is not meant to scale.
Have to manually test the Server Sensor combination to come up with the
maximum capacity.
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
JSON.\\
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
traffic.
\bibliographystyle{abbrv}
\bibliography{main}
\end{document}
No preview for this file type
......@@ -119,14 +119,14 @@ 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
JSON. [As of now Im doing the testing of the capabilities using REST APIs].\\
JSON. [As of now I'm doing the testing of the capabilities using REST APIs].\\
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 networks service traffic.\\
core network's service traffic.\\
The modified rules and the added rules are to be maintained by the CNAC when
the tapping has to be removed.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment