enhanced sdn security using firewall in distributed ...

ENHANCED SDN SECURITY USING FIREWALL IN DISTRIBUTED SCENARIO

By DHAVAL P SATASIYA [141060751024]

Under guidance of MR. HIRESH KUMAR Software Engineer, AurionPro

A Thesis Submitted to GUJARAT TECHNOLOGICAL UNIVERSITY, AHMEDABAD In the Partial Fulfillment of the Requirement For the Degree of Master of Engineering In Computer Engineering (Network Security) MAY, 2016

Gujarat Technological University PG SCHOOL AHMEDABAD

CERTIFICATE

This is to certify that research work embodied in this thesis entitled “Enhanced SDN security using firewall in distributed scenario” was carried out by Mr. Satasiya Dhavalkumar P. (141060751024) studying at GTU PG School, Ahmedabad (Institute code: 106) for partial fulfillment of Master of Engineering in Computer Engineering (Network Security, branch code: 51) be awarded by Gujarat Technological University during the academic year 2015-16. This research work has been carried out under my guidance and supervision and it is up to my satisfaction.

Date: Place:

GUIDE

PRINCIPAL

Name: Mr. Hiresh Kumar

Name:

Signature:

Signature:

Seal of Institute

COMPLIANCE CERTIFICATE

This is to certify that research work embodied in this thesis entitled “Enhanced SDN security using firewall in distributed scenario” was carried out by Mr. Satasiya Dhavalkumar P. (141060751024) studying at GTU PG School, Ahmedabad (Institute code: 106) for partial fulfillment of Master of Engineering in Computer Engineering (Network Security, branch code: 51) be awarded by Gujarat Technological University during the academic year 2015-16. He has complied with the comments given by the Dissertation phase – I as well as Mid-Semester Thesis Reviewer to my satisfaction.

Date: Place:

STUDENT

GUIDE

Name: Dhaval Satasiya


Signature:

Signature:

PAPER PUBLICATION CERTIFICATE

This is to certify that research work embodied in this thesis entitled “Enhanced SDN security using firewall in distributed scenario” was carried out by Mr. Satasiya Dhavalkumar P. (141060751024) studying at GTU PG School, Ahmedabad (Institute code: 106) for partial fulfillment of Master of Engineering in Computer Engineering (Network Security, branch code: 51) be awarded by Gujarat Technological University during the academic year 2015-16, has published article entitled Analysis of Software Defined Network Firewall (SDF) for publication by the IEEE conference on Wireless, Signal Processing and Network at Chennai during 23-25 March 2016.

Date: Place:

STUDENT

GUIDE



Signature:

Signature:

Signature of Principal

Seal of Institute

PAPER PUBLICATION CERTIFICATE

This is to certify that research work embodied in this thesis entitled “Enhanced SDN security using firewall in distributed scenario” was carried out by Mr. Satasiya Dhavalkumar P. (141060751024) studying at GTU PG School, Ahmedabad (Institute code: 106) for partial fulfillment of Master of Engineering in Computer Engineering (Network Security, branch code: 51) be awarded by Gujarat Technological University during the academic year 2015-16, has published article entitled Enhanced SDN security using firewall in distributed scenario for publication by the IEEE International conference on Advance Communication, Control and Computing technology at Syed Ammal Engineering Collage, Ramanathapuram during 25 -27 May 2016. Date: Place:

STUDENT

GUIDE



Signature:

Signature:

Signature of Principal

Seal of Institute

THESIS APPROVEL CERTIFICATE

This is to certify that research work embodied in this thesis entitled “Enhanced SDN security using firewall in distributed scenario” was carried out by Mr. Satasiya Dhavalkumar P. (141060751024) studying at GTU PG School, Ahmedabad (Institute code: 106) for partial fulfillment of Master of Engineering in Computer Engineering (Network Security, branch code: 51) be awarded by Gujarat Technological University during the academic year 2015-16.

Date: Place:

EXAMINERS

Name:

Name:

Signature:

Signature:

STATEMENT OF ORIGINALITY

We hereby certify that we are the sole authors of this thesis and that neither any part of this thesis nor the whole of the thesis has been submitted for a degree to any other University or Institution. We certify that, to the best of our knowledge, the current thesis does not infringe upon anyone’s copyright nor violate any proprietary rights and that any ideas, techniques, quotations or any other material from the work of other people included in our thesis, published or otherwise, are fully acknowledged in accordance with the standard referencing practices. Furthermore, to the extent that we have included copyrighted material that surpasses the boundary of fair dealing within the meaning of the Indian Copyright (Amendment) Act 2012, we certify that we have obtained a written permission from the copyright owner(s) to include such material(s) in the current thesis and have included copies of such copyright clearances to our appendix. We declare that this is a true copy of thesis, including any final revisions, as approved by thesis review committee. We have checked write up of the present thesis using anti-plagiarism database and it is in allowable limit. Even though later on in case of any complaint pertaining of plagiarism, we are sole responsible for the same and we understand that as per UGC norms, University can even revoke Master of Engineering degree conferred to the student submitting this thesis.

Date: Place:

Signature of Student:

Signature of Guide:

Name of Student: Dhaval Satasiya

Name of Guide: Mr. Hiresh Kumar

Enrollment No: 141060751024

Institute Code: 106

ACKNOWLEDGEMENT

This thesis done as requirement in the 4th semester of our M.E. Computer Engineering (Network Security) as a course contain, I feel greatly obliged to certain specials. I am sincerely gratitude to Mr. Hiresh Kumar, who providing me this opportunity and necessary support during the analysis. I am also grateful of his for providing all the assistance and helping during Dissertation work. I have no other words to express my sincere thanks to my coordinators for their kind cooperation and able guidance. Especially to Mr. Naresh Gurdas (Course Coordinator, CDAC) and Ms. Vinita Tiwari (Senior Technical Officer, C-DAC), they also guides me during this research work. I am also thankful to the C-DAC ACTS for providing me such a good resource. From help of this I am only able to done my work nicely.

-

i

Dhaval P. Satasiya

POWER OF RESPECT

-

Mr SMERT

ACKNOWLEDGEMENT

This thesis done as requirement of our M.E. Computer Engineering (Network Security) as a course contain, I feel greatly obliged to certain specials. I am sincerely gratitude to Mr. Hiresh Kumar, who providing me this opportunity and necessary support during the analysis. I am also grateful of his for providing all the assistance and helping during Dissertation work. I have no other words to express my sincere thanks to my coordinators for their kind cooperation and able guidance. Especially to Mr. Naresh Gardas (Course Coordinator, CDAC) and Ms. Vinita Tiwari (Senior Technical Officer, C-DAC), they also guides me during this research work. I am also thankful to the C-DAC ACTS, Pune for providing me such a good resource. From help of this I am only able to done my work nicely.

-

i

Dhaval Satasiya

LIST OF FIGURES

Figure No.

Figure Description

Page No.

Figure 2.1

Firewall Architecture

5

Figure 2.2

SDN Architecture

9

Figure 2.3

SDN Plan

10

Figure 2.4

OpenFlow

13

Figure 2.5

SDN without OpenFlow

15

Figure 2.6

SDN Packet direction by OpenFlow

15

Figure 3.1

Experiment System paper1

18

Figure 3.2

Experiment System paper 2

19

Figure 3.3

Experiment System paper 3

20

Figure 4.1

Existing Firewall Mechanism

26

Figure 6.1

33

Figure 6.3

Prototype Model OpenFlow Switch with intermediate firewall Individual Firewall Object with a host

Figure 6.4

Flow Diagram of algorithm

38

Figure 6.5

Traffic Flow diagram

39

Figure 7.1

Virtual Network Topology

43

Figure 7.2

MiniEdit GUI window

44

Figure 8.1

Rule file

54

Figure 8.2

Create a firewall with POX controller

54

Figure 8.3

ARP entry in host1

55

Figure 8.4

ARP entry in host2

55

Figure 8.5

ARP entry in host3

55

Figure 8.6

Host2 ping host3

56

Figure 8.7

Host2 ping host1

56

Figure 8.8

host3 ping host2

56

Figure 8.9

Firewall performance chart

57

Figure 9.1

Time-Line Chart

59

Figure 6.2

ii

34 35

LIST OF TABLES Table No.

Table Description

Page No.

Table 1

Synopsis

3

Table 2

Summary of literature survey

23

Table 3

Firewall Policy

49

Table 4

August: Milestones & Deliverables

60

Table 5

September: Milestones & Deliverables

60

Table 6

October: Milestones & Deliverables

60

Table 7

November: Milestones & Deliverables

60

Table 8

December: Milestones & Deliverables

61

Table 9

January: Milestones & Deliverables

61

Table 10

February: Milestones & Deliverables

61

Table 11

March: Milestones & Deliverables

61

Table 12

April: Milestones & Deliverables

61

Table 13

May: Milestones & Deliverables

61

iii

TABLE OF CONTENTS

Chapter: 1

Chapter: 2

Chapter: 3

Chapter: 4 Chapter: 5

Chapter: 6

Chapter: 7

Chapter: 8

Chapter: 9

Acknowledgement……………………………………. List of Figures………………………………………… List of Tables…………………………………………. Table of Contents…………………………………….. Abstract………………………………………………. Introduction………………………………………….. 1.1 Project Summary …………………………………. 1.2 Purpose …………………………………………… 1.3 Synopsis ………………………………………….. Background Information.....………………………… 2.1 Firewall…… ……..……………………………….. 2.2 SDN ………………………………………………. Literature Survey..………………..…………………. 3.1 Paper 1…….………………………………………. 3.2 Paper 2..………………………………………..….. 3.3 Paper 3.……………………………………………. 3.4 Paper 4……………………..……………………… Existing System.……………………………………… 4.1 Existing SDN Firewall…..……..………………….. Problem Statement...…………………………………. 5.1 Challenges in SDN.……...……..…………………. 5.2 Problem Identification.……..…………..…………. 5.3 Problem Definition……………………….……….. Proposed Solution..…………………………………... 6.1 Design Methodology …...…..…………..………… 6.2 Detailed Algorithm Description ………………….. Implementing System..…………………………..…... 7.1 Create SDN……………………………………….. 7.2 Maintain flow-table and Handle new host………... 7.3 Firewall Prototype……………………………….... 7.4 Tools and Technology Used…………………….... System Evaluation……..……………………………. 8.1 Functionality Testing …………………………….. 8.2 Performance Testing…………………….………... Research Management………………………………. Conclusion……………………………………………. References………………………………………….… iv

i ii iii iv vi 01 02 02 03 04 05 06 17 18 19 20 21 24 25 27 28 30 31 32 33 36 41 42 46 48 51 53 54 57 58 62 63

Appendix-1 Appendix-2 Appendix-3 Appendix-4 Appendix-5

List of Abbreviations…………………………….….. Review card & Compliance Report …………….….. Publication Details……………………………….….. Consolidation Report…………………………….….. Plagiarism Report…….………………………….…..

v

65 66 73 85 88

ENHANCED SDN SECURITY USING FIREWALL IN DISTIBUTED SCHENARIO

Submitted by

Supervision by

DHAVAL P SATASIYA

Mr. HIRESH KUMAR

[141060751024]

AurionPro, Pune

Abstract Software defined networking (SDN) allows for easy programmable networks without having to manually configure every network device individually. Needs in the network industry today is; the need to develop new devices quickly but maintain product quality and the need to allow a greater level of end-user flexibility when creating network devices. SDN is among the latest developments in the field of computer networking that tries to answer these needs. And SDN is wildly adopted in data-center architecture. However, not many studies are done on security applications for SDN based infrastructure. But, SDN have too much vulnerability like Packet-loss, Throughput and absent of defense mechanism; DoS, MITM and Controller High-jacking is the popular attack done on SDN. Analyzing current security issue and the existing Security mechanism helps to identify new of mechanism for firewall. The goal of this work is to explore security possibilities by focusing on the development of a firewall prototype that maximizes the advantages of SDN.

vi

Chapter 1

INTRODUCTION  Project Summary  Purpose  Synopsis

Introduction

1.1 PROJECT SUMMARY Firewalls indispensable security device that protects the host and network traffic filtering to provide momentary almost every network-connected devices that are placed in. Firewall performance, which is a critical component for network performance, many are willing to take advantage of its filtering algorithms can be degraded by traffic. Software defined networking (SDN) presents different network architecture than physical infrastructure. Introduce separates control logic of a network rather than traditional network design, Allows for easy programmable networks with no having to manually configure each network device separately. However, there is not much study done on security applications for SDN based networks. SDN is a technology innovation and flexibility in the design and management of the network enables, but may introduce new security issues. In this thesis, we present the details of implementation, as well as present the results of the use of a firewall application. This study is on firewall application; firewall functionalities to show that most of that without the assistance of a dedicated hardware, software, but built on OpenFlow-based SDN controllers are able to be focused on the development of runs.

1.2 PURPOSE The aim of proposed system is to develop a system with improved facilities. The proposed system will overcome all the limitations of the existing system. Proper security will be provided by the system and manual work will be reduced. The existing system has several disadvantages and many more difficulties to work smoothly. In proposed system efforts will be made to eliminate or reduce these difficulties up to some extent. The proposed system will help the user to reduce the workload and mental conflict and also it will help the user to work user friendly and they can easily do his jobs without time lagging.

141060751024

Page 2

Introduction

1.3 SYNOPSIS

Title

Enhanced SDN security using firewall in distributed scenario

Project Description

A research on SDF is going in C-DAC environment for collecting review of existing techniques and finds faceable solution.

Objective

To make easy flexible and good UI for user and provide better security and patch holes than existing techniques.

Purpose

To collect review of software defined network firewall and identify problems in current system and proposed better solution and implementing prototype model

Anticipated Outcome

Outcome of this research is modeled for firewall user to provide easy configuration of firewall object based on users need and requirement and we also tries to provide flexible UI.

Time Frame

10:00 a.m. to 6 p.m., 5 Days in a week

Time Duration

Approximately 12 Months Table 1 Synopsis

141060751024

Page 3

Chapter 2

BACKGROUND TECHNOLOGY  Firewall  SDN

Background Technology

2.1FIREWALL TECHNOLOGY Firewall Technologies is usually a safe and efficient manner at a lower security level to a higher security level for the environment from the environment the user and / or most common way to access the system is safe. Firewall security level too high for the environment but at a more granular level of security, you can use the grant [15]. In information technology, hardware and / or software that functions in a network environment by the firewall security policy, called refused to stop communication in one piece. The basic function of a firewall between the various sectors of the trust is to control traffic. Specific areas of trust include public and private computer networks. The ultimate goal of a security policy and connectivity model based on the principle of least privilege enforcement through the different levels of trust is to provide connectivity between areas controlled.

2.1.1 Firewall Architecture Firewall is basically placed between Internet (public network) and internal network (Private network). There is several existing firewall type based on them work:

Fig. 2.1 Firewall Architecture Here classify firewalls categories as: packet filtering, circuit gateways, and proxy based.

141060751024

Page 5


2.1.1.1 Packet-filtering Firewall Also known as filtering router or network –layer firewall, it works at the network layer and transport layer. It is based on a single data packet network control, according to IP source address of the packet received, IP destination addresses, TCP/UDP source port number and destination port number, ICMP message type, packet access interface, protocol type, and data packet a variety of signs, etc. as parameters, and user access control list scheduled to be compared to decide whether the data in line with preestablished security policy, decided to forward or discard packets that the implementation of the filter [12]. 2.1.1.2 Proxy server-based Firewall Proxy-based firewall stunning on the host through the proxy server program, reporting directly to a particular application layer service, it is also known as application-oriented firewall. The core is running on a firewall, proxy server on the host computer process that instead of Internet users to complete a specific TCP/IP functions [12]. A proxy server is actually a specific network application to connect two networks gateway. 2.1.1.3 Circuit-Gateway Firewall Circuit gateways relay TCP connections. At the entrance to caller in a TCP port, which connects to the entrance on the other side connects to some destination. The circuit level gateway firewalls work at the session layer of the OSI model. They monitor TCP to determine if a requested session is legitimate. And the information passed through a circuit level gateway, to the internet, appears to have come from the circuit level gateway. The logic is simple: a firewall must be positioned to control all incoming and outgoing traffic. If some other program has that control, there is no firewall. We define a firewall as a collection of network components that collectively have the following properties: 1. All the network traffic must pass through the firewall.

141060751024

Page 6


2. Only authorized traffic, based on Security policy will be allowed to pass. 3. The firewall itself is immune to penetration, maintain logs. Firewalls are desirable follows directly from our earlier statements. Many more are expected to host, the hosts cannot protect themselves against a determined attack.

2.1.2 What Firewall Can’t Do!! Firewalls are a powerful tool for network security. However, they are many things they cannot do. It is important to understand their limitations as well as their benefits. Consider the usual network protocol layer. By its nature, a firewall is a very strong defense against attacks at a lower level of the protocol stack. In contrast, firewalls provide almost no protection against problems with higher level protocols. The most interesting question is what degree of protection a firewall can provide against threat sat its own level. The answer turns entirely on how carefully the gateway code-the permissive part is written. The problems, however, do not stop there. Any information that passes inside can trigger problems, when transfer do communications link, effectively brought down that link, because of bit pattern sensitivity in some network elements. Furthermore, even if we had implemented defenses against the known flaws , we would still be vulnerable to next year’s.

141060751024

Page 7


2.2 SOFTWARE DEFINED NETWORK High ability skills requires for configuration and installation of many network elements. Where the network nodes (dialogue between the switch, router, etc.) are complex, there is a need to include the elements of a system-based approach and the simulation of more. Also, operational provisioning and multi-vendor network covering many technologies involved in the management costs have been increasing in recent years, while in the major trend for operating revenue is reduced. The term software defined networking (SDN) has been identified in recent years. The concept behind SDN has been developed since 1996, in 2005 the implementation of SDN brought closer to reality [3]. Open Networking Foundation (ONF) is described SDN as [9]: “In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications.” Four key characteristics that SDN focus is [8]: 

Separation of the control plane from the data plane



A centralized controller and view of the network



Open interfaces between the devices in the control plane and those in the data plane



Programmability of the network by external applications

SDN is a means for the implementation of new innovation and opens up new applications. Global network of dynamic topology control is feasible. The networkwide access control, power management, and home networking and network view which scope for beneficial but absolutely necessary [3].

141060751024

Page 8


2.2.1 SDN Architecture

Fig. 2.2 SDN Architecture This architecture encompasses the complete network platform of SDN based on our vision is described in Fig. 2.1.1.1 Infrastructure Layer In the bottom tier of fig 2.2, Ethernet switch and physical network devices including routers included. This forms the data plane. 2.1.1.2 Control Layer Centeral tier consists of the level controllers to establish and tear down of network flows and paths are convenience. Capacity and demand controllers networking equipment through which the use of information

obtained

from

the

traffic

flow.

An

application

programming interface (API) level down through the southbound API referred to as links with the central tier. Connections between the east and westbound controllers work with the API. 2.1.1.3 Application Layer An application in this article refers to the service provided by the network operator is. Detailed information on each element in the image of architecture. Fig 2.2 is beyond the scope of this article. Instead,

141060751024

Page 9


today SCN network transition from traditional to state of the art is presented. By separating the control plane from the data plane Software Defined Networking, development of new applications that try to simplify. Control plane is also called controller. That provides centralized control and view into the network architecture. Some things makes the switches very simple and inexpensive, like most intelligence is now transferred to the controller, and the switch only perform the actions that the controller requests. But the traditional network device has their own vendor-specified operating system to control the data plane, and 3rd party applications can be run over this operating system.

Fig. 2.3 SDN Plan

2.2.2 KEY CHALLENGES However, many challenges remain to be addressed. This section of the challenges arising from SDN focuses on four specific questions. 2.2.2.1 PERFORMANCE VS. FLEXIBILITY SDN is a fundamental challenge of how high-touch, high security and high performance in an efficient way to handle packet processing flow.

141060751024

Page 10


The elements to consider: performance and programmability/ flexibility. There are a number of initiatives underway to allow programmability of existing network technologies in a manner conformant with the goals of SDN. Furthermore, a programming and performance problem of SDN beyond 100 GB / s bandwidth to the node remains a challenge. 

Highest flexibility can be archived through general-purpose processors (CPUs/GPPs)..



Optimized processor architectures for network processing using network flow processors (NPUs/NFPs).



Programmable logic devices (PLDs) or field programmable gate arrays (FPGAs) in telecommunications and networks have developed a technology for processing.

2.2.2.2 SCALABILITY Loosely the issue can be divided into, the control scalability and network node scalability. The focus here controller scalability is on three specific challenges are identified. 

In the first, multiple nodes and the exchange of information between a single controller latency introduced by the network.



And second is how to SDN controller uses the east and westbound APIs for communicating with other controllers.



The size of the controller back-end database and their operation cost is third challenge.

2.2.2.3 SECURITY SDN is going to be acceptable to the wider deployment of security is therefore required more attention. Indeed, a security working group open networking Foundation (ONF) has been established within this in mind. A number of issues are highlighted here that further study and underlined the need for the development of security solutions.

141060751024

Page 11


On the plus side, SDN architecture is a highly reactive security monitoring, analysis and response system supports. Security approach can support the SDN: 

Network forensics



Security policy alteration



Security service insertion

2.2.2.4 INTEROPERABILITY It is based on a completely new technology infrastructure to deploy SDN will be simple. For this, all the elements will be able to SDN and network devices. However, today's critical systems and business support network is a huge installed base. Simply "swap out" the new infrastructure for these networks is going to be not possible, and only such as data centers and campus networks is well suited for closed environments. The transition to SDN; therefore requires simultaneous support of legacy equipment. IETF path computation element (PCE) gradual or partial migration to SDN can help. Also in development is a hybrid SDN infrastructure, which enables traditional SDN, and hybrid network nodes can work in harmony to achieve is necessary. Where the introduction of a new protocol standardization and standardization will be of most benefit to consider is required. European Telecommunications Standards Institute (ETSI)

and

Network Function Virtualization (NFV) Industry Specification Group that is efficient core network for scalability and to provide those services can be virtualized is intended to standardize the components within.

141060751024

Page 12


2.2.3 OpenFlow OpenFlow, most popular protocol of protocol standards exist on the use of SDN in real applications. Enabling the implementation of the SDN concept in both hardware and software can be using OpenFlow [4]. Stanford proposed SDN as a standard protocol. Many models have been proposed for the OpenFlow protocol about their test beds which use open source code to control the universal SDN controllers and switches. OpenFlow is flow-oriented protocol which has switches and ports abstraction that controls the flow. In SDN, there is a controller that is software based which manages the traffic control in collection of switches [3]. The OpenFlow protocol used by controller to communicates with the OpenFlow switch and manages the switch. An OpenFlow switch can have multiple flow tables, a group table, and an OpenFlow channel. Each flow table contains flow entries and communicates with the controller, and the group table can configure the flow entries. OpenFlow switches connect to each other via the OpenFlow ports.

Controller

Channel s Flow table

Flow table

Flow table

Ta Ta

Channel Fig. 2.4 OpenFlow

141060751024

Page 13


The OpenFlow architecture considers main3 important components. 1. Switches: OpenFlow Monitor / Change switches and routers to change the flow table. An OpenFlow switch has at least three components: a) Flow table(s), an action associated with each entry area, each with flow, b) A communication channel for the transmission of packet switches and the command and provides a link between a controllers, c) OpenFlow protocol, any router / switch to be able to communicate with an OpenFlow controller enables. 2. Controllers: A controller from the user's experiments with flow table (add modification, or deletion) flow can update entries. Static (vs. dynamic) Controller software on a computer running a simple statically (vs. dynamic) during a scientific experiment, a group of test packets between computers path to be set up. 3. Flow-entries: Each flow stream for the item of entry at least one simple action (Network Operations), including. Following three actions support by the most OpenFlow switches: a) Send this flow’s packets to a port, b) Encapsulate this flow’s packets and send them to a controller, c) Drop this flow’s packets.

SDN and OpenFlow when used interchangeably, leads to much confusion. SDN is an abstract concept, with clear characteristics and behavior of IP and TCP protocol whereas OpenFlow is like string. In fact, OpenFlow SDN is one of the rapid growing techniques.

141060751024

Page 14


Fig. 2.5 SDN without OpenFlow The OpenFlow specification details, the structure of flow tables and the communication over wire is discussed here. At lower level, OpenFlow controller in an OpenFlow switch forwarding table entries can be set arbitrarily. The match featured a number of traffic flow, an access list filtering can be based on similar. As a simple example, a domain controller over a layer two nodes installed on the forwarding information to make a specific flow from host X Y across the network to host a specific path that can be followed.

Fig. 2.6 SDN Packet direction by OpenFlow 141060751024

Page 15


2.2.4 POX POX is an open source controller for developing SDN applications. POX controller provides an efficient way to implement the OpenFlow protocol which is the de facto communication protocol between the controllers and the switches. Using POX controller you can run different applications like hub, switch, load balancer, and firewall. TCP-dump packet capture tool can be used to capture and see the packets flowing between POX controller and OpenFlow devices [5].

141060751024

Page 16

Chapter 3

LITERATURE SURVEY    

Paper - 1 Paper - 2 Paper - 3 Paper - 4

Literature Survey

3.1 PAPER 1 Title

Programmable Firewall Using Software Defined Networking

Authors

Karamjeet Kaur, Japinder Singh, Krishan Kumar and Navtej Singh Ghumman

Published at

2nd International Conference on Computing for Sustainable Global Development (INDIACom), IEEE, 2015.

On this paper; explain the basis for the development of design and OpenFlow application firewall. Most of these firewall capabilities, without the need of dedicated hardware, using open source software that can be created using POX controller. Here he is behaving like a firewall dumb OpenFlow switches. That switch is connected with the controller POX. POX controller, a MAC address table that maps ports and mac address of other application. A firewall has a characteristic of allowing and rejecting a specific type of information. In this method, the firewall allows source MAC address, destination MAC address (Layer 2), source IP address, destination IP address (Layer 3), network protocol, and destination port (Layer 4) based on restricted traffic.

Fig 3.1 Experiment System paper 1 At the time the packet enters the switch, firewall rules match against the packet headers. Action which then forwards the packet header firewall rules or to drop the packet is to be with the same matches. Insert the firewall rule with firewall. insertRule, firewall. showRule and firewall. deleteRule command.

141060751024

Page 18

Literature Survey

3.2 PAPER 2 Title

Building Firewall over the Software-Defined Network Controller

Authors

Michelle Suh, Sae Hyong Park, Byungjoon Lee and Sunhee Yang

Published at

ICAICT, February 2014

Authors design a firewall runs over OpenFlow controller that already exists. There are two approaches were considered by the authors to apply the firewall; Prior to installing the flow switch on the table and packet handling rules as they come in because of the flexibility in the management directly. This is the logic of the firewall; each packet header highest firewall rules are checked against the highest priority, and are found in areas specifies a matching rule action. Any unmatched packets are dropped.

Fig 3.2 Experiment System paper 2 Here Authors uses the Virtual-box, Mininet for create virtual network topology and POX as a central Controller. Hosts connected with the OpenFlow switch. Simple Packet forwarding algorithm uses the port, MAC, and IP addresses to updates the OpenFlow Switch as they come in. This firewall offers six options to choose from in the management of the firewall: Add, Delete, Show – add, delete and show the rules ShowComplete - Shows complete entry of rules SwitchPri - command takes name and new priority as input, and switches list order SetTimeout - command sets general timeout to drop similar packets in the future

141060751024

Page 19

Literature Survey

3.3 PAPER 3 Title

A Layer2 Firewall for Software Defined Network

Authors

Tariq Javid, Tehseen Riaz and Asad Rasheed

Published at

Conference on Information Assurance and Cyber Security (CIACS), IEEE, 2014

This paper presents a layer2 firewall, Implementation uses POX controller at control plane of the architecture. The modified code successfully controlled flow of packets between hosts according to firewall rules. POX controller who Here are three network devices, hub, layer 2 learning switch, and Layer 3 switch comes with learning. They used PUTTY SSH client and Xming X Server for Windows to establish remote connections. This open source application, POX controller functionality to amend the code to learn, and to perform experiments have provided sufficient flexibility. POX hub controller is used; it receives every incoming packet to all ports except the port flooding. For each packet from the switch: I. II. III.

Address / port source MAC address table to update and use the switch port, Install flow table entry in the switch, and Send the packet out the appropriate port. Layer 3 switches in learning, source IP address, MAC address is used instead.

Fig 3.3 Experiment System paper 3 141060751024

Page 20

Literature Survey

3.4 PAPER 4 Title

Stochastic Pre - Classification for Software Defined Firewalls

Authors

Pritha Ghoshal, C. Jasson Casey, Paul V Gratz, and Alex Sprintson

Published at

IEEE, 2013

This letter stateless firewall, or is focused on simple packet filtering ACL. More advanced stateful firewall filtering stateless packet filtering on the creation of a rich set of features to offer. Stateless firewall performance and stateful firewall features to address both stateless influences. The main idea is that we are likely to take advantage of its architecture authorized and unauthorized speculative flow of traffic in the division. When a packet received, it’s extracted and processed by a Bloom filter. If a hit indicates a corresponding packet flow is likely to be authorized, while a miss indicates that it certainly is not part of an existing authorized flow. Cache quickly authorized paths intersect and high volume of false positives are used to filter unauthorized flow. Bloom filter and both authorized and unauthorized path at the end of the cache entries are maintained at the ACL stage. The key ideas expressed in this design are: Partition traffic - likely authorized and unauthorized False positive pruning - filter false positives early Attack pruning - filter high bandwidth flows early New flow learning - false positives, authorized, and unauthorized flows Author gives an approach to verify the performance of firewall in a vanilla Linux kernel v2.6.2. Implement GEM5 simulator running on multi-core processors. This tool simulates a complete system including network interface and IO connections. They develop a system GEM5 with two network interface card. NIC is a trusted interface, pointing to the private network and the other is un-trusted interface as is used.

141060751024

Page 21

Literature Survey Speculative Partitioning Packet processing architecture in the first phase expected to authorize and unauthorized flow of packets sent speculative Division provides. This process is a Bloom filter, the smaller the chance of false positives, false negative analytical calculations but is accomplished with no incident. False Positive and Attack Pruning Both authorized and unauthorized handling of packets in the way of false positives and the next stage is known sorting unauthorized traffic. The speculative nature of architecture in the way authorized Bloom filter unauthorized packets, due to the potential for false positive leads. New Flow Learning Both authorized and unauthorized flow architecture learns. Any unauthorized flow path is always the first packet will reach ACL. If the flow is authorized for Bloom filter will be updated if you deny unauthorized cash flow will be updated. Keep in mind that the packet can make a decision in the case is delayed until the ACL is important.

141060751024

Page 22

Literature Survey Title of Paper Programmable Firewall Using Software-Defined Networking. Year: 2015

Author Name Karamjeet Kaur, Japinder Singh, Krishan Kumar, Navtej Singh Ghumman

Building Firewall over the SoftwareDefined Network Controller. Year: 2014

Michelle Suh, Sae Hyong Park, Byungjoon Lee, Sunhee Yang

A Layer2 Firewall for Software Defined Network.

Tariq Javid,

Year: 2014

Asad Rasheed

Stochastic PreClassification for Software Defined Firewalls.

Pritha Ghoshal,

Year: 2013

Tehseen Riaz,

C. Jasson Casey, Paul V Gratz, Alex Sprintson

Mechanism

Remark

Used a dumb OpenFlow Limitation of this switch, that behaves similar to implementation is a firewall and connected the stateless. switch with POX controller. Uses OpenFlow POX controllers are v1.0 which responsible for building a doesn’t keep Mac address table and record of the firewall application that packet state and restricts or allows the traffic. supports few header fields. Implemented firewall runs over an OpenFlow-based SDN controller that works by pre-installing the rules onto the switch’s flow table and handling the packets directly as they come in.

This design only views at the packet header fields to determine the action.

Implemented Layer 2 firewall with tree topology that uses POX controller at the control plane of the architecture.

Limitation of these implementations is that they block only layer2 traffic and For every packet coming looks at few from the switch, use source header fields. MAC address and incoming switch port to update address and port table, then install the flow table entry in the switch, and send the packet out at appropriate port. This idea is of speculative partitioning the traffic into authorized and unauthorized flows.

The Bloom filter and cache used to filter traffic and those entries are maintained by the When packet is received, ACL. being processed by a Bloom filter that indicates the packet and caches are used to quickly prune false-positives from the authorized path and filter unauthorized flows.

Table 2 Summary of literature survey

141060751024

Page 23

Chapter 4

EXISTING SYSTEM  Existing SDN Firewall

Existing System

4.1 EXISTING SDN FIREWALL TECHNOLOGY The OpenFlow Controller presents two behaviors, reactive and proactive. 

In the Reactive approach, in each of the first packet flow received by the network switch, runs from the controller to enter the flow OpenFlow switch entries. This approach utilises the existing flow table memory most efficiently, but with each new flow there is some extra setup time. Due Dependence on the controller, if the connection is lost between the controller and the switch, the switch cannot forward packets.



In the Proactive approach, each switch in the flow table entries constantly flow controller installs. These approach gives zero flow setup time as the rules are previously defined. Even if the connection between the switch and the controller is lost, it does not block the traffic, instead uses (wildcard) rule necessary to cover all of the flow.

The firewall uses a hybrid approach in which the firewall rules are put in active mode and the switching rules into reactive mode, thus giving the advantage of both methods. The logic behind this firewall mechanism is something like: 

Every packet header from lowest to highest priority are checked against the firewall rule; and



Performs well once used matching rules are found in the specified action.

Mininet emulator used for the current setup. Mininet can run on the limited resources of an ordinary computer or VM to develop a system for large networks. Mininet emulator virtual hosts, controllers, switches, and links to network topology allows consist of. The topology in Mininet is as shown in the following figure Topology includes: 

A controller, Controller as labeled ‘c’



OpenFlow switches, switches as labeled ‘s’



Hosts, and hosts as labeled ‘h’

141060751024

Page 25

Existing System

Controller ‘c’

OpenFLow Switch ‘s’

Switch

Switch

Switch

Host ‘'

Host

Host

Fig 4.1 Existing Firewall Mechanism All these devices are connected via virtual links. Existing topology, making dumb OpenFlow switch ‘s’ behaves like a firewall. For this we connected ‘s’ switch with the POX controller. This two applications running on POX controller: 

The first is learning application, switch to maps addresses to ports; for that maintain a MAC address table.



OpenFlow switches S0, and the second firewall application rules that allow or deny traffic based on a rule.

When packet enters the switch, firewall rules match against the packet headers. Firewall rules, which coincides with the action corresponding to pass or deny the packet is to be. The packet was forward to learning switch algorithms if the packet header cannot match with the firewall rules.

141060751024

Page 26

Chapter 5

PROBLEM IDENTIFICATION  Challenges in SDN  Problem Identification  Problem Definition

Problem Identification

5.1 CHALLENGES AND SECURITY ISSUE IN SDN CIA of Resources; network security solutions to this three problems usually are treated as а consistent. "Resources" is could be interpreted as a physical resource, logical resources and may be information resources. Based on SDN approach, the network can dynamically configure using software, allowed to adapt change according to its need. Several tasks can be accomplished by an SDN-based solution [8]: 

Runing virtual networks on top of the physical network.



Controlling the network traffic flow within the network.



Creating integrated policies that span the physical and virtual networks.

List of security challenges in the development of SDN is expected to grow. To take maximum benefits of SDN, the challenges should be listed so that appropriate security mechanism can adopt continuously. Therefore, security challenges and threats are discussed in this section. From a fundamental point of view, SDN security vulnerabilities are centered on their three plans.

5.1.1 Application Plane Security The SDN applications as network functions can be applied; malicious apps if not stopped soon enough, can spread havoc across a network. Diversity and different programming models and using criteria limits interoperability and security policy can take on different developing vendor-independent development environment and the multitude of third party applications. SDN applications, some of the challenges posed by security threats are described below. 1. Authentication and Authorization 2. Access Control and Accountability 3. Fraudulent flow rules insertion

141060751024

Page 28


5.1.1 Control Plane Security Control plane is a centralized decision-making unit. Therefore, the network controller in highly compromising its role or malicious network activity can be targeted to carry. The main security challenges and threats present in the control plane, control plane are described below is a centralized decisionmaking unit. Therefore, the network controller in highly compromising its role or malicious network activity can be targeted to carry. The main security challenges and threats existing in the control plane are described below. 1. Threats from Applications 2. Threats due to Scalability 3. DoS Attacks

5.1.2 Data Plane Security In the SDN the control plane, data plane described as safety has a direct impact on. This means that if a controller is compromised, the data plane includes a variety of network nodes will be compromised. Hence, the switchlink can be a favorable choice for attacking the network. 1.

Flooding attacks

2.

Controller hijacking or compromise

3.

TCP-Level attacks

4.

Man-in-the middle attack

141060751024

Page 29


5.2 PROBLEM IDENTIFICATION After studying existing systems of anonymous network, there are few points to consider: 

Such sleep is to keep down the transit encryption, firewalling and filtering and access control system will help spread calculated as adding power during peak load.



In both networking and storage functions sensitive to latency (data plane) or side-band (control plane) can be labelled.



With real-time operation, the standard example of a core slices are periodic heavy traffic can introduce latencies. Suppose that the routing is an example of a core 10% were running. How Hypervisor slices and dices, depending on the time of use of the core, the latency, which in financial systems such as switch configuration for low-latency operation for general work is very slow and completely unacceptable, must submit to add milliseconds.



Existing Firewall become a single point of failure (SPOF); a central OpenFlow switch is work as a firewall, the whole networks traffic was passed through firewall (OpenFlow switch), if too much traffic is passed than firewall is down and whole network is not accessible.



Firewall overload is a common cause of failure.

141060751024

Page 30


5.3 PROBLEM DEFINITION Keeping in mind the limitations of existing systems and models SDN Firewall, I am proposing which will contain following characteristics: 

Stage focus on control plane to manage the entire network is more extensive, and will bring a bunch of new features to the table. These changes streamline and networking operations must accelerate.



An important consideration is to balance the load across the number of firewalls.



And also tries to reduce overhead on SDN firewall and



Provide good UI for flexible and easy configuration of firewall object on users need and demand.

141060751024

Page 31

Chapter 6

PROPOSED SOLUTION  Design Methodology  Detailed Algorithm Description

Proposed Solution

6.1 DESIGN METHODOLOGY Because of the design direction for distributed firewalls; firewalls overload is a common cause of failure and thus an important consideration is to balance the load across a number of firewalls. And also increase the safety and efficiency of the whole network flow by looking at the initial stage by blocking network attacks, improve the argument for SDN capabilities. Here we would create a simulated network for building the distributed flow-based firewall prototype. Prototype tries for latency without causing any delay in the case of a distributed configuration via ping tests, tries to show the full functionality. And also this prototype model tries to reduce overhead on SDN firewall and provide good UI for flexible and easy configuration of firewall object on users need and demand.

Fig. 6.1 Prototype Model

141060751024

Page 33

Proposed Solution Every time when a network device connects to the controller; one event is triggered, and the other event launch function for the firewall listens for First events and creates firewall object linked with the specific network host that triggered the connection. These firewall objects are in turn stored in a list whose index identifies the firewall.

6.1.1 Working of Proposed System According to Existing Firewall system OpenFlow Switch is work as a Firewall for SDN network; here we use same things but in some different way, the OpenFlow switch is implement an intermediate firewall. Figure 6.2 shows the OpenFlow Switches have an Intermediate firewall.

Fig. 6.2 OpenFlow Switch with intermediate firewall When the new host is attached to OpenFlow Switch; where two events is occurs I. II.

First event is creating a trigger. And the second event is listening a trigger and creates a firewall object that link with the individual host.

141060751024

Page 34

Proposed Solution

Fig. 6.3 Individual Firewall Object with a host Figure 6.3 Show the every host in network have individual firewall object. Firewall object on host can also done using OpenFlow mechanism for light weight and flexible implement. For define a drawbacks of existing firewall system we distribute firewall into number of object and tries to reduce load from firewall for prevent failure and low latency problem. The intermediate firewall is define general rules for overall network; like block broadcast packet or disable ping test into network. And individual firewall object is responsible for counter enforcement mechanism for individual host or network; like block incoming traffic from individual IP address or allow only some type of traffic http/https, ftp etc.

141060751024

Page 35

Proposed Solution

6.2 DETAILED ALGORITHM DESCRIPTION Proposed System for SDN Firewall mechanism is work on a distributed scenario, the number of firewall is work to secure a network from malicious activity and provide good mechanism to defend network with the high flexibility and define such old problem discussed in chapter 5. But for the valuable implement of a proposed idea we decide to make an algorithm for workflow in proper manner. Algorithm is responsible for the… 

Proper traffic flow across the number of firewall in SDN



Handel the trigger when new host is adding to the network



Assign firewall object to all individual host; and



Link-up all firewall objects into intermediate firewall and work as a soul system



Also manage the network traffic through intermediate firewall and individual firewall object.

6.2.1 Proposed Algorithm The design of the firewall can be summarized as follows. The controller proactively loads a set of rules onto the switch to act as a primary filter on incoming packets. Only packets matching rules on the switch are then forwarded to the controller which installs bidirectional flows on the switch to enable that traffic. This design requires the switch to handle the majority of traffic as it should and only send data to the controller as necessary. This should allow the controller to scale to control a larger number of switches and the corresponding increase in new flows.

141060751024

Page 36

Proposed Solution

1. Connect host to network or network indicated a. Call first event and trigger generated for new host b. Process listening for the trigger If (trigger generated) Create new firewall object Else Continue to listen for the trigger 2. Assign firewall object to new host Enter entry of object in flow table 3. Startup: Controller reads configuration rules from command line to memory And listens for switch to connect on port 6633 (default port) 4. Switch connected: Controller loads rules onto switch to pass through unrestricted And Switch forwards packets to controller 5. Proactive rule sent to switch If (Incoming connections matches rule set) Then Forward matching packets to controller 6. Controller receives encapsulated packets from switch If (encapsulated packets match the rule set) Packets allowed to flow Bidirectional pair of flows installed that allows the traffic (packets) between the originating source host and its intended destination host Packet returned to switch for forwarding to its intended destination Else (encapsulated packets do not match the rule set) Packets dropped

6.2.2 Work-Flow of Proposed Algorithm Diagram shows the work of proposed algorithm in software defined network. Main object of the work is manage the distributed firewall and handle the traffic across the network because software define network have same

141060751024

Page 37

Proposed Solution fundamentals

as

traditional

network

mechanism

but

manage

and

implementation of the software defined network is a complex task. Handle the traffic and implement firewall into the software defined network is much complex things. Proposed algorithm and proper workflow is reducing the overhead and complexity to implement and manage many firewall into a single network infrastructure and make proper way to distribute and manage traffic across whole network.

Fig. 6.4 Flow Diagram of algorithm Flow Diagram of assign a firewall objects to new add host in network. When the new host is connected to network the first event is called. In the first event a trigger is generated for new host; one process is listening for the trigger, if the trigger is generated then it’s create a new firewall object, if not than continue to listen for a trigger. 141060751024

Page 38

Proposed Solution After the create a new object; 

First it’s make a entry in Flow Table of OpenFlow switch, and



Assign a individual object to host

After that the new host is connected to network with firewall object and OpenFlow switch is transfer controls to host and allow passing traffic.

Fig. 6.5 Traffic Flow diagram

141060751024

Page 39

Proposed Solution Above diagram is describe flow pattern of traffic into Software Defined Network, First things is all incoming traffic is handle by the controller and transfer to the OpenFlow switch to distribute in network. OpenFlow switch is also work as a intermediate firewall in a network; 

Its Match the incoming packet to Flow Table for where pass the packet, and



Match with the firewall enforcement rule to filter the traffic.

The unwanted traffic is dropped by intermediate firewall and finds the path and passed traffic to the network. Firewall at the individual host is handle the incoming traffic from OpenFlow switch and match the packet with firewall rules in flow table to filter traffic, its drop the unwanted packet and pass the legitimate traffic to the host. Both Firewall is dropped traffic according to enforcement rules in flow table and generate a log entry for administrative purpose.

141060751024

Page 40

Chapter 7

IMPLEMENTING SYSTEM    

Create SDN Maintain flow-table Firewall Prototype Tools and Technology used

Implementing System

7.1 CREAT SDN First task to do in implementing proposed idea is to create a software defined network infrastructure as a platform for next task. Here we use LINUX DESTRO for the create software defined network infrastructure. Steps to create a SDN are; 

Install the Mininet network simulator



Configure MiniEdit GUI



Install POX SDN controller

A first thing to do is create a machine with two interface card (NIC).

7.1.1 Install and configure Mininet Network Simulator 1. Download the Mininet 2.2.0 from:github.com/mininet/mininet A folder named mininet created in the home directory that contains the project file structure. 2. Run the installation script from the util directory. This will install Mininet 2.2 $ ~/mininet/util/install.sh –a 3. One time the script was completely install mininet, now we test that the installation was successful or not. That could be done by executing following command. It should run a short Mininet scenario successfully. $ sudo mn --test pingall 4. Now, use command ‘mn’ to access Mininet in terminal 5. Create a Virtual network topology using Mininet $ sudo mn –topo=single,3 –mac –switch ovsk –controller remote That creates virtual network topology (Fig. 7.1) with,

141060751024

Page 42

Implementing System 3 Hosts (Named h1, h2, h3), 1 OpenFlow Switch (s0), And, Controller (port 6633)(c0)

Fig 7.1 Virtual Network Topology 6. Test the created network using (into the Mininet terminal) h2 ping h1

7.1.2 Configure MiniEdit GUI To run the mininet in a GUI version run the script is located in Mininet’s examples directory. For that go to example directory and execute the command: $ sudo python miniedit.py GUI windows after the running previous command (that shows network diagram of previously created virtual topology in mininet)

141060751024

Page 43

Implementing System

Fig. 7.2 MiniEdit GUI window

7.1.3 Installing POX POX provides a framework for communicating with SDN switches using either the OpenFlow or OVSDB protocol. Developers using the Python programming language can create an SDN controller POX. It's about teaching and research on software defined networks and network application programming is a popular tool. 1. Download the POX complete code: http://github.com/pox-carp/pox 2. Invoking POX $

sudo

python

~/pox-carp/pox.py

forwarding.l2_learning

info.packet_dump samples.pretty_log log.level –DEBUG web.webcore Where, Forwarding.l2_learning This component makes OpenFlow switches act as a type of L2 learning switch.

141060751024

Page 44

Implementing System samples.pretty_log This module uses log.color and a custom log format to provide nice. Run the script from the samples directory. log.level Use the pythons logging infrastructure. That display log massage into the pox terminal. web.webcore Run a web server within the pox process from web directory. info.packet_dump A component that dumps packet_in info to the log.

141060751024

Page 45

Implementing System

7.2 HANDAL NEW HOST AND MAINTAIN FLOW-TABLE Implement firewall into the SDN architecture, must know how traffic flow into the software based network. And also OpenFlow switch is maintain a flow table to handle the network traffic within the SDN. So, indentify packet flow and how flow table should maintain we gone through this experiment. 1. We use network topology that creates in section 7.1 into the mininet, and invoke controller using same as in 7.1.That’s creating 3 host, 1 switch and controller. IP and MAC address of the host are h1  10.0.0.1, 00:00:00:00:00:01 h2  10.0.0.2, 00:00:00:00:00:02 h3  10.0.0.3, 00:00:00:00:00:03 2. Test ping for connection between host h1 and h2 use following command into the mininet terminal, can also check connection with other link. mininet> h1 ping h2 3. Now into the pox terminal debug log should be displayed. In which you found DEBUG: forwarding.l2_learning:Connection [00:00:00:00:00:01] That means entry for host1 is installed into the flow table when first packet was send by the host1 (in ping h2), and DEBUG: forwarding.l2_learning:installing flow for 00:00:00:00:00:02.2  00:00:00:00:00:01.1 DEBUG: forwarding.l2_learning:installing flow for 00:00:00:00:00:01.1 00:00:00:00:00:02.2 That defines the flow rule into the flow table from host2 to host1 and 2 nd is for host1 to host2. Where .1 and .2 indicates switch port for respective hosts. 4. Now open the terminal (with root privileges) for hosts using Xterm command, For Host,

141060751024

Page 46

Implementing System xterm h1 xterm h2 xterm h3 For Switch xterm s1 For Controller xterm c0 5. Now use following command to dump all network packet tcpdump -a That display all network traffic packet, from which you can found arp, dhcp and icmp packet sent by the hosts. 6. To explore more we create a http server in host1, for that use command in h1 xterm python –m SimpleHTTPserver HTTP server was running on 10.0.0.1 port 80 Now, access server from host2 and we can show the new flow entry in pox terminal same as in task3 and also found http packet in tcpdump. 7. Apply following command into the base host (your OS) to view of complete flow table $ sudo ovs-ofctl dump-flows s1

141060751024

Page 47

Implementing System

7.3 FIREWALL PROTOTYPE This firewall module implements firewall-like functionality for POX. The code uses python as a platform to develop firewall prototype. When a switch connects to the controller, the component initializes the connection to the switch as well as adding low-priority flow entries to allow certain types of packets to pass through (i.e. ICMP, IP, ARP), but block all packets that are not specified by a rule in the firewall configuration file. It pushes medium priority flow entries for rules from the configuration file. When it receives a packet, it checks the configuration rules to ensure that there is a match, then pushes symmetric flow entries from the packet specifics. If there is not a match, it pushes a flow entry with null action, so the switch will drop packets from that flow. Our firewall module has contains two files; fw.py : firewall source code rule.conf : configuration file that contain enforcement rule for firewall. To run this firewall module, must require running firewall code file (fw.py) with the controller.

7.3.1 Write Configuration File Proposed firewall module contain a firewall enforcement rule into the rule.conf configuration files, this file store the firewall rules in a tabular format. User have to manually write rule.conf file. There first column is for the write entity for firewall type that decide to in which firewall that rule can apply like intermediate firewall or individual firewall; use ‘0’ for the intermediate firewall and ‘host ip’ for individual firewall object. In this configuration file put # for write comments in anywhere in file.

141060751024

Page 48

Implementing System Firewall Source Desti Source MAC Type IP IP 0 10.0.0.1 10.0.0.3 00:00:00:00:00:01 10.0.0.2 10.0.0.3

Desti MAC 00:00:00:00:00:02

Proto col icmp

00:00:00:00:00:02

https ftp

10.0.0.2 10.0.0.1 00:00:00:00:00:03 Table 3 Firewall Policy

Table 3 is shows the sample firewall rule policy. Here first rule is for block icmp ping between host 10.0.0.1 and 10.0.0.2 that apply on intermediate firewall (because firewall type is 0). And second and third rules are apply on individual firewall of host 10.0.0.3, for allow https traffic with host 10.0.0.1 and ftp traffic with host 10.0.0.2.

7.3.2 Useful POX API’s 1. connection.send( ... ) function sends an OpenFlow message to a switch. When a connection to a switch starts, a ConnectionUp event is fired. 2. ofp_action_output class This is an action for use with ofp_packet_out and ofp_flow_mod. It specifies a switch port that you wish to send the packet out of. It can also take various "special" port numbers. 3. ofp_match class Objects of this class describe packet header fields and an input port to match on.Some notable fields of ofp_match objects are: dl_src - The data link layer (MAC) source address dl_dst - The data link layer (MAC) destination address in_port - The packet input switch port 4. ofp_packet_out OpenFlow message (not used in the code above but useful in the future work)

141060751024

Page 49

Implementing System The ofp_packet_out message instructs a switch to send a packet. Notable fields are: ? buffer_id - The buffer_id of a buffer you wish to send. Do not set if you are sending a constructed packet. data - Raw bytes you wish the switch to send. Do not set if you are sending a buffered packet. actions - A list of actions to apply. in_port - The port number this packet initially arrived on if you are sending by buffer_id, otherwise OFPP_NONE. 5. ofp_flow_mod OpenFlow message This instructs a switch to install a flow table entry. Notable fields are: idle_timeout - Number of idle seconds before the flow entry is removed. hard_timeout - Number of seconds before the flow entry is removed. actions - A list of actions to perform on matching packets priority - When using non-exact matches, this specifies the priority for overlapping matches. buffer_id - The buffer_id of a buffer to apply the actions to immediately. in_port - If using a buffer_id, this is the associated input port. match - An ofp_match object. By default, this matches everything, so you should probably set some of its fields!

141060751024

Page 50

Implementing System

7.4 TOOLS AND TECHNOLOGY USED 7.4.1 Operating System UBUNTU 14.04LS – Linux based Open Source operating system 7.4.2 Mininet Network Simulator 2.2 Mininet is a network emulator which creates a network of virtual hosts, switches, controllers, and links. Mininet hosts run standard Linux network software, and its switches support OpenFlow for highly flexible custom routing and Software-Defined Networking [16]. Mininet: 

A simple and inexpensive network test for the development of applications that provides OpenFlow.



Work independently on the same topology to enable multiple concurrent developers.



Repeatable and easily packaged supports system-level regression tests.



Enables testing of complex topology, without requiring a physical network to wire.



OpenFlow is conscious and aware of the topology of a CLI, debugging and running, including network-wide test.



Supports arbitrary custom topologies with including a basic setoff parameterized topologies.



Is usable out of the box without programming, but



The network construction and use Python API provides a simple and extensible.

141060751024

Page 51

Implementing System 7.4.3

MiniEdit The Mininet network simulator includes MiniEdit, a simple GUI editor for Mininet. MiniEdit is an experimental tool created to demonstrate how Mininet can be extended. MiniEdit has a simple user interface that presents a canvas with a row of tool icons on the left side of the window, and a menu bar along the top of the window [17].

7.4.4

POX It’s a platform for the rapid development and prototyping of network control software using Python. Meaning, at a very basic level, it’s one of a growing number of frameworks for helping you write an OpenFlow controller. As well as being a framework for interacting with OpenFlow switches, we’re using it as the basis for some of our ongoing work to help build the emerging discipline of Software Defined Networking [18]. Some quick POX features: 

“Pythonic” OpenFlow interface



Reusable sample components for path selection, topology discovery, etc.



“Runs anywhere” – Can bundle with install-free Py runtime for easy deployment



Specifically targets Linux, Mac OS, and Windows



Supports the same GUI and visualization tools as NOX



Performs well compared to NOX applications written in Python

141060751024

Page 52

Chapter 8

SYSTEM EVALUATION  Functionality  Performance

System Evaluation

8.1 FUNCTIONAL EVALUATION Here we scribe the functional testing of our firewall module. We block the all network traffic and allow only icmp flow into the network between particular hosts. Open rule.conf file and put the firewall rule for allow traffic for;  icmp packet for host1 (10.0.0.1) and host2 (10.0.0.2)  And arp packet for host1 (00:00:00:00:00:01) and host3 (00:00:00:00:00:03).

Fig 8.1 Write firewall rules Image 8.1 shows screenshot of firewall rules (rule.conf), this file store rules in a tabular format and apply when firewall module is interact with controller. Here we set arp rule at an intermediate firewall that apply in whole network and a block icmp at an individual host. After that, create a firewall with POX controller. For that in another terminal run the POX controller with upper firewall configuration, use following command… $ ./pox.py py log.level pox.forwarding.l2_learning fw

Fig 8.2 create a firewall with POX controller

141060751024

Page 54

System Evaluation Here we include firewall module “fw” that run over the controller. Show the firewall module is running in below screenshot and inserted firewall rule also. Now in the mininet console we check for the firewall work, so that we test ping configuration in virtual topology. For that we use xterm to interact with host. First, we check for the arp entries in each host to check firewall rules is properly installed or not. For that use arp –a command to check arp entry for every host.

Fig. 8.3 ARP entry in host1

Fig. 8.4 ARP entry in host2

Fig. 8.5 ARP entry in host3 Upper screenshot proof that as per firewall rule here we found arp entries into host1 and host3 but host2 doesn’t have any arp entries. Now, check for the ping test configuration, here the firewall rules for icmp is applied on individual firewall host. According to firewall rules host2 is enable to ping host3 and vise-versa.

141060751024

Page 55

System Evaluation

Fig. 8.6 host2 ping host3

Fig. 8.7 host2 ping host1 Screenshot 8.6 proof that host2 enable to ping host3 but can’t ping host1 (Image 8.7) that denied in firewall policy. Same that in image 8.8 there host3 is enable to ping host2.

Fig. 8.8 host3 ping host2

141060751024

Page 56

System Evaluation

8.2 PERFORMANCE EVALUATION Testing of proposed architecture into distributed scenario used network topology with central switch connected with the multiple hosts and controller also connected with central switch. Two different condition takes to test ping into network with 500+ times. First time use network without firewall. After that use firewall module into network and test performance of both individual firewall and intermediate firewall. Figure 8.9 shows the results of this testing output of multiple condition in Minimum, Maximum and Average time to pass traffic into network in graph format.

Fig. 8.9 firewall performance chart Deployment of the distributed firewall does not affect the overall efficiency of the network traffic filtering process. The results are shown on figure 8 there are not much different between average times; 0that means whatever the firewall used as a distributed scenario or only as single source of firewall has no negative effects in terms of latency.

141060751024

Page 57

Chapter 9

RESEARCH MANAGEMENT  Time-Line

Research Management

9.1 TIME-LINE These are the milestones planning to achieve my dissertation with relative duration of the months.

Fig. 9.1 Time-Line Chart

Phase 1

Phase 2

Phase 3

Task Details

Start in (Approx.)

Task 1.1

Background Information

August

Task 1.2

Problem Formulation

August

Task 1.3

Literature Survey

September

Task 1.4

Survey Paper

September

Task 2.1

Research Direction & Requirement

October

Task 2.2

Setup SDN Architecture

October

Task 2.3

Analyze Existing Firewall Mechanism

November

Task 3.1

Analyze algorithm and SDN protocols

December

Task 3.2

Implement Proposed System

December

141060751024

Page 59

Research Management

Phase 4

Task 4.1

Experiments and Testing

March

Task 4.2

Result and Conclusion

April

Task 4.3

Thesis and Final Research Paper

May

August: Milestones

Deliverables

Background information

Analysis Report

Problem Formulation

Problem Statement Table 4 August: Milestones & Deliverables

September: Milestones

Deliverables

Literature Survey

LR Report

Survey Paper

-Table 5 September: Milestones & Deliverables

October: Milestones

Deliverables

Survey Paper

Survey Paper

Research Direction & Requirement

--


--

Table 6 October: Milestones & Deliverables November: Milestones

Deliverables


SDN Infrastructure

Analyze Existing Mechanism

--

Table 7 November: Milestones & Deliverables

141060751024

Page 60

Research Management December: Milestones

Deliverables

Analyze Existing Mechanism

--

Analyze algorithm and SDN protocols

SDN Infrastructure

Table 8 December: Milestones & Deliverables January: Milestones

Deliverables


Prototype Model

Table 9 January: Milestones & Deliverables February: Milestones

Deliverables


Prototype Model

Table 10 February: Milestones & Deliverables March: Milestones

Deliverables


Prototype Model

Experiments and Testing

Results

Table 11 March: Milestones & Deliverables April: Milestones

Deliverables

Result and Conclusion

Further Evaluation


Thesis

Table 12 April: Milestones & Deliverables May: Milestones

Deliverables


Thesis

Table 13 May: Milestones & Deliverables

141060751024

Page 61

CONLUSION AND FUTURE WORK Easy and flexible configuration and robust control on application placed SDN to a popular network technology in today’s era. Existing firewall technology is designed based on OpenFlow prototype, where firewall controller controls the traffic flow based on rule set define in flow table and switch that makes enforce on controller regulating traffic flow according to their flow table rules. But the existing firewall cannot able to cover all explained security region. SDN model proposed in the firewall is to develop a system of improved facilities. In the proposed system, we try to overcome the limitations of existing firewall system. That appropriate protection and reduces manual work. Many disadvantages of the current system to works well and have many more difficulties. The proposed system to eliminate or minimize these difficulties to some extent tries and will help users to reduce the workload and mental conflicts. In future, we will like carried out work: 

Create more stateless firewall module

141060751024

Page 62

REFERENCES PAPERS 1.

Karamjeet Kaur, Krishan Kumar, Japinder Singh, Navtej Singh Ghumman “Programmable Firewall Using Software Defined Networking” 2015 2nd International Conference on Computing for Sustainable Global Development (INDIACom) (978- 9- 3805-4416-8/15) IEEE pp. 21252129.

2.

Jake Collings Jun Liu “An OpenFlow-based Prototype of SDN-Oriented Stateful Hardware Firewalls” 2014 IEEE 22nd International Conference on Network Protocols (978-1-4799-6204-4/14) IEEE pp. 525-528.

3.

Fei Hu, Qi Hao, and Ke Bao “A Survey on Software-Defined Network and OpenFlow: From Concept to Implementation” 2014 Communication Surveys & Tutorials , VOL. 16, NO . 4, IEEE pp. 2181-2206.

4.

Kazuya Suzuki, Nobuyaki Tomizawa, Yutaka Yakuwa, Terutaka Uchida, Yuta Higuchi, Toshio Tonouchi, Hideyuki Shimonishi, “A Survey on OpenFlow Technology”, 2014 IEICE pp. 375-386.

5.

Sukhveer Kaur, Japinder Singh and Navtej Singh Ghumman, “Network Programmability Using POX Controller”, 2014 ICCCS pp. 134-138.

6.

Michelle Suh, Sae Hyong Park, Byungjoon Lee, Sunhee Yang “Building Firewall over the Software-Defined Network Controller” 2014 Conference on Information Assurance and Cyber Security (CIACS) (ISBN 978-89968650-3-2) (978-1-4799-5852-8/14) IEEE pp 39-42.

7.

Tariq Javid, Tehseen Riaz, Asad Rasheed “A Layer2 Firewall for Software Defined Network (Short Paper)”, pages 165- 178{.ACM,2009}.

8.

Ijaz Ahmad, Suneth Namal, Mika Ylianttila and Andrei Gurtov, “Security in Software Defined Networks: A Survey”, 2015 IEEE.

9.

Sakir Sezer, Pushpinder Kaur Chouhan, Barbara Fraser, David Lake, Jim Finnegan, Niel Viljoen, Netronome Marc Miller and Navneet Rao, “Are We Ready for SDN? Implementation Challenges for Software-Defined Networks”, 2013 (0163-6804/13/$25.00) IEEE.

10.

Jaehoon (Paul) Jeong, Jihyeok Seo, Geumhwan Cho, Hyoungshick Kim, and Jung-Soo Park, “A Framework for Security Services based on Software-Defined Networking”, 2015 29th International Conference on Advanced Information Networking and Applications Workshops, (978-14799-1775-4/15) IEEE pp. 150-153.

63

11.

Xin Vue, Wei Chen, Yantao Wang, “The Research of Firewall Technology in Computer Network Security”, 2009 Second Asia-Pacific Conference on Computational Intelligence and Industrial Applications, (978-1-42444607-0/09), IEEE, pp. 421-424.

12.

Pritha Ghoshal , C. Jasson Casey , Paul V Gratz, and Alex Sprintson, “Stochastic Pre - Classification for Software Defined Firewalls”, 2013 (978-1-4673-5775-3/13/$31.00) IEEE.

13.

Steven M. Bellovin and William R. Cheswick, “Network Firewalls”, IEEE Communications Magazine September, 1994.

WEBSITES 14.

Scott Hogg, “SDN Security Attack Vectors and SDN Hardening”, Oct 28, 2014, http://www.networkworld.com/article/2840273/sdn/sdn-securityattack-vectors-and-sdn-hardening.html.

15.

“Mininet Overview”, http://mininet.org/overview/

16.

“MiniEdit: mininet’s graphical user interface”, http://www.brianlinkletter.com/how-to-use-miniedit-mininets-graphicaluser-interface/

17.

“About POX”, www.noxrepo.org/pox/about-pox/

BOOKS 18.

Smeliansky R.L., “SDN for network security”, 2014 (978-1-4799-75952/14) IEEE.

19.

Gary Croft, “Firewall Technologies Good Practice Guideline”, 2007

20.

Saeed Al-Haj and Ehab Al-Shaer, “Measuring Firewall Security”.

64

Appendix - 1

LIST OF ABBREVIATION

SDN

Software Defined Network

POX

Python-based OpenFlow Controller

IP

Internet Protocol

TCP

Transmission Control Protocol

UDP

User Datagram Protocol

ICMP

Internet Control Message protocol

MAC

Media Access Control

OSI

Open System Interface

ACL

Access Control List

NIC

Network Interface Card

ONF

Open Networking Foundation

API

Application Program Interface

DoS

Denial of Service

TLS

Transport Layer Security

UI

User Interface

65

Appendix - 2

REVIEW CARD AND COMPLIANCE REPORT 1. Review Card

66

Appendix - 2

Literature Survey:

67

Appendix - 2

Dissertation Phase I:

68

Appendix - 2

69

Appendix - 2

Mid-Semester Review:

70

Appendix - 2

2. Compliance Report No. 1

2

Event Literature Survey

Dissertation Phase I

Comments Given 1) Develop Algorithm for prototype model.

- We will be delivered algorithm.

2) Modify Title as per algorithm.

- Changed title from ‘Implementation and analysis of Software Defined Network Firewall’ to ‘Enhanced SDN security using firewall in distributed scenario’.

3) Detail Technical information should be required in PPT.

- We improve our DP1 documents.

1) Not clear about distribution scenario.

- Understood and have clear idea of distributed firewall and started implementation accordingly.

2) Justification is require for distribution logic of security.

3

Mid-Semester Review

Work Done

3) Methodology need to specify for proposed work.

- Algorithm has been successfully design for this. Work and sample code from this algorithm has been successfully executed and running.

1) Limitation of existing work were discussed but in proposed work not discussion on those limitations. Those point should be clearly discussed in the dissertation.

- We will analyze our proposed firewall module that’s result describe points that we listed before.

2) Strength and weakness of proposed system should be mentioned.

71

Appendix - 2

3) Make a comparison of four algorithms with existing algorithm that have been cited in literature survey.

72

- We refer many research paper related to SDN firewall and discussed with the author’s but we doesn’t found any proper algorithm for existing mechanism and in literature survey we will discuss about existing firewall technologies for SDN.

Appendix - 3

PUBLICATIONS 1) Paper - 1: Review Paper Title:

Analysis of Software Defined Network Firewall (SDF)

Journal:

IEEE Xplore

Published at:

International conference on Wireless Communications Signal Processing and Networking (2016)

Conference Date:

23 – 25, March (Chennai)

List of Author:

Dhaval Satasiya (CDAC, Pune) Rupal Raviya (CDAC, Pune)

Computing Classification System:

Software Define Network, Firewall, Security, POX, OpenFlow

Conference Certificate:

73

Appendix - 3

Published Paper:

74

Appendix - 3

75

Appendix - 3

76

Appendix - 3

77

Appendix - 3

2) Paper 2: Final Paper Title:

Enhanced SDN security using firewall in a distributed scenario

Journal:

IEEE Xplore

Published at:

International conference on Advance Communication, Control and Computing technology (ICACCT)

Conference Date:

25 – 27 May, 2016 (Ramanathapuram)

List of Author:

Dhaval Satasiya (CDAC, Pune) Hiresh Kumar (AurionPro, Pune) Rupal Raviya (CDAC, Pune)

Computing Classification System:

Software Define Network, Distributed Firewall, Security, POX, OpenFlow

78

Appendix - 3

Published Paper:

79

Appendix - 3

80

Appendix - 3

81

Appendix - 3

82

Appendix - 3

83

Appendix - 3

84

Appendix - 4

CONSOLIDATED REPORT

Date: Name of Students:

Satasiya Dhavalkumar P

Enrollment No:

141060751024

Branch Name:

Network Security

Title of Thesis:

Enhanced SDN Security using Firewall in a Distributed Scenario

Theme:

Cloud Computing (Security)

Name of Supervisor:

Mr. Hiresh Kumar

Signature Mr. Hiresh Kumar AurionPro, Pune

85

Appendix - 4

Objective: Software Defined Network (SDN) attract much attendance from research and industrial area; reason behind is the open interface, user controlled management and lower operating cost for data/flow handling rules that implements on software module rather than embedding in hardware with greatly improve performance. Network with the high security demanding higher in this generation. New service and products provide advanced technology and flexible architecture but changing in network landscape can introduce new security issues. SDN simplifies hardware, software and management of network device but faces many forms of attack. SDN or TNA (Traditional Network Architecture) has same uses firewall to manage legacy network traffic. This report introduce firewall for SDN infrastructure to secure network attached device from suspicious and malicious traffic regarding to attack and access control to enhancing SDN security by distributing system.

Issues in Current System: SDN security; the challenges should be listed so that appropriate security mechanism can adopt continuously. From a security perspective, vulnerabilities are centered on SDN’s three plans. After studying existing systems of anonymous network, there are few points to consider: 

Encryption, firewalling and filtering and access control system can slow down the network.



With real-time operation also storage functions, the standard example of a core slices are periodic heavy traffic can introduce latencies.



Existing Firewall become a single point of failure (SPOF); a central OpenFlow switch is work as a firewall, the whole networks traffic was passed through firewall (OpenFlow switch), if too much traffic is passed than firewall is down and whole network is not accessible.



Firewall overload is a common cause of failure. 86

Appendix - 4

Proposed System: According to Existing Firewall system OpenFlow Switch is work as a Firewall for SDN network; here we use same things but in some different way, the OpenFlow switch is implement an intermediate firewall. Also every host in network have individual firewall object. Firewall object on host can also done using OpenFlow mechanism for light weight and flexible implement. The intermediate firewall is define general rules for overall network; such as block broadcast packet or disable ping test into network. And individual firewall object is responsible for counter enforcement mechanism for individual host or network; like block incoming traffic from individual IP address or allow only some type of traffic http/https, ftp etc.

Result: Open rule.conf file and put the firewall rule for allow icmp packet in host1 (10.0.0.1) and host2 (10.0.0.2). Here we write in configuration file… 0, 10.0.0.1, 10.0.0.2, , , icmp Here 0 for Intermediate Firewall and we put mac address blank. And include firewall module “fw” that run over the controller.

In the upper image; as per firewall rule here only host1 and host2 can enable to ping each other successfully. The pingall command used to send a single ping between every possible host pairs to test the connectivity of the entire network.

87

Appendix - 5

PLAGIARISM REPORT

88

Appendix - 5

89

Appendix - 5

Signature Mr Hiresh Kumar 90

enhanced sdn security using firewall in distributed ...

enhanced sdn security using firewall in distributed ...

Suggest Documents

enhanced sdn security using firewall in distributed

data security in lan using distributed firewall - IRJET

IRJET- SDN Simulation in Mininet to Provide Security Via Firewall

Implementation of Virtual Firewall Function in SDN

Security Policy Checking in Distributed SDN based Clouds - IEEE Xplore

Towards a Reliable SDN Firewall - Clemson University

Towards a Reliable SDN Firewall - Clemson University

Security Enhanced Distributed Knowledge Management ... - CiteSeerX

vPROM: vSwitch Enhanced Programmable Measurement in SDN

vPROM: vSwitch Enhanced Programmable Measurement in SDN

Safeguard Intranet Using Embedded and Distributed Firewall System

Enhanced Information Security in Distributed Mobile ... - Science Direct

Cisco Identity-Based Firewall Security

CCNP Security FIREWALL Notes (PDF)

Cisco's PIX Firewall Series and Stateful Firewall Security

security enhanced key predistribution scheme using transversal ...

An Enhanced ATM Security System using Second

Implementing a Distributed Firewall - Semantic Scholar

Enhanced Information Security using DNA ...

ENHANCED ATM SECURITY SYSTEM USING BIOMETRICS - IJCSI

Waterwall: a cooperative, distributed firewall for

A Collaborative Trust Enhanced Security Model for Distributed System ...

Enhanced Internet security by a distributed traffic control service based ...

Renaissance: Self-Stabilizing Distributed SDN Control Plane