Handling DDOS attacks in Cloud Computing based on SDM System

CSEIT17222 | Received: 05 March 2017 | Accepted: 17 March 2017 | March-April-2017 [(2)2: 62-68]

International Journal of Scientific Research in Computer Science, Engineering and Information Technology

© 2017 IJSRCSEIT | Volume 2 | Issue 2 | ISSN : 2456-3307

62

Handling DDOS attacks in Cloud Computing based on SDM System

S. Akhilesh Kumar1, A. Sundersingh2

¹PG Scholar, Department of M.Sc(Software Engineering), PSN College of Engineering & Technology, Tirunelveli, Tamilnadu, India

² Research Supervisor, Department of M.Sc(Software Engineering), PSN College of Engineering & Technology, Tirunelveli, Tamilnadu,

India

ABSTRACT

Distributed Denial Of Service (DDoS) attacks in cloud computing environments are growing due to the essential

characteristics of cloud computing. With recent advances in Software Defined Networking (SDN),SDN-based cloud

brings us new chances to defeat DDoS attacks in cloud computing environments. Nevertheless, there is a

contradictory relationship between SDN and DDoS attacks. On one hand, the capabilities of SDN, including

software-based traffic analysis, centralized control, and global view of the network, dynamic updating of forwarding

rules, make it easier to detect and react to DDoS attacks. On the other hand, the security of SDN itself remains to be

addressed, and potential DDoS vulnerabilities exist across SDN platforms. In this paper, we discuss the new trends

and characteristics of DDoS attacks in cloud computing, and provide a comprehensive survey of defence

mechanisms against DDoS attacks using SDN. In addition, we review the studies about launching DDoS attacks on

SDN, as well as the methods against DDoS attacks in SDN. To the best of our knowledge, the contra dictory

relationship between SDNandDDoS attacks has not been well addressed in previous works. This work can help to

understand how to make full use of SDN‘s advantages to defeat DDoS attacks in cloud computing environments and

how to prevent SDN itself from becoming a victim of DDoS attacks, which are important for the smooth evolution

of SDN-based cloud without the distraction of DDoS attacks.

Keywords : Application Programming Interface, VLAN, IETF, Saas, Paas, Iaas, QoS

I. INTRODUCTION

Cloud computing is an internet-based computing in

which large groups of remote servers are networked to

allow sharing of data-processing tasks, centralized data

storage, and online access to computer services or

resources. Clouds can be classified as public, private or

hybrid.Cloud computing or in simpler shorthand just

"the cloud", also focuses on maximizing the

effectiveness of the shared resources. Cloud resources

are usually not only shared by multiple users but are

also dynamically reallocated per demand. This can

work for allocating resources to users. For example, a

cloud computer facility that serves European users

during European business hours with a specific

application (e.g., email) may reallocate the same

resources to serve North American users during North

America's business hours with a different application

(e.g., a web server). This approach should maximize

the use of computing power thus reducing

environmental damage as well since less power, air

conditioning, rack space, etc. are required for a variety

of functions.

The expression cloud is commonly used in science to

describe a large agglomeration of objects that visually

appear from a distance as a cloud and describes any set

of things whose details are not inspected further in a

given context. In analogy to above usage the word

cloud was used as a metaphor for the Internet and a

standardized cloud-like shape was used to denote a

network on telephony schematics. I.

Wireless Networking becomes the most adaptable

technology for flexibility and mobility in human life.

For the last few years, Software Defined Wireless

Networking (SDWN), a branch of Software Defined

Network (SDN) has been a key research technology to

Volume 2 | Issue 2 | | March-April-2017 | www.ijsrcseit.com

63

analyze and proper management of the densely

populated cellular network [1] [2]. Software Defined

Wireless Networking (SDWN) assures simple and

scalable network architecture and effective mobility

management of the IP networks.

The Software Defined Wireless Networking (SDWN)

programmatically centralizes and separates the control

plane (aka. Network OS) from the data plane (aka.

Forwarding plane). A conventional architecture of SDN

is illustrated in Fig. 1. The southbound interface is a

medium between the control plane and data plane while

northbound is layer between application plane and

control plane. The southbound interface trains the

controllers to collect information about Mobile Nodes

(MNs) and transmits and receives packets to and from

MNs using SDWN elements [3].

To ensure quality of service in SDWN and persistent

network services, operators need to monitor the

network and do proper service measurements from time

to time. Such monitoring will assist in analyzing

network parameters, i. e. throughput, roundtrip

transmission time, bandwidth in the wireless link,

mobility frequency and preparing a real-time view of

the network service standard on industry level. For

such analysis, monitoring and measurement, various

open- source and commercial technology and tools are

available for SDWN including sFlow [4], FlowVisor

[5], BigSwitch [6], BigTap [7], SevOne [8] etc. These

tools provide the operator with capabilities to perform

troublesome network activities and even monitor,

detect and indicate security attack in progress on a

certain.

Figure 1. SDN architecture with separated control and

data plane

Previously several research work is performed on

analyzing the security of OpenFlow-based SDN

environment. Analysis on 4D, PCE and SANE-based

SDN architectures is performed in paper [9], security

application of SDN is thoroughly analyzed and

evaluated in [10]. In previous research sFlow has been

represented as an effective and scalable vulnerability

mitigation mechanism for SDN [11]. FlowVisor turned

a better solution for network virtualization [12] and

vulnerability solution for flow isolation is proposed and

evaluated alongside [13]. Among the tools that monitor

and measure the SDN: a comparative study between

sFlow (Open-Source) and BigTap (commercial) is

illustrated in paper [14]. However, a security and threat

defined study in SDWN monitoring and measurement

tools, those focuses on Open-Flow flow entries and

communication among multiple controllers in wireless

platform, is the primary goal of this perspective study.

Hence, sFlow and FlowVisor are chosen for above flow

circumstances.

The structure of this paper is as follows. In Section II,

the STRIDE and Data Flow methodology is described.

In section III and IV, security and threat risk of sFlow

and FlowVisor are analyzed. Section V represents a

comparative study between the two monitoring tools

and thereby concluding the paper in Section VI with

future prospects of this study outcomes.

II. BACKGROUND AND RELATED WORK

According to OpenFlow specification in [15], any

OpenFlow switch holds flow entries that contains

incoming packet header information, packet handling

action for matched packet entries in the list and

statistics of number of bytes, packets in a particular

flow and time since last pass. Packets as arrive at any

OpenFlow switches, it executes the packet header

information and try matching the existing flow entries.

When the information does not match any of the flow

tables, switch then pass the packet to the controller to

take action and update the flow entries accordingly

with required information of the packet. When it‘s a

match switch performs and forwards the packet to its

next destination on the basis of routing flow table

information in it.

As SDN brings more advantage in connecting into the

internet, Software Defined Wireless Network (SDWN)

has got much importance and emerging research field


64

with attention. SDWN is oriented towards the mobile

and wireless network devices and aims at the research

and study of crucial technologies for the future mobile

and wireless network. This SDWN architecture is

composed of both North-South and East-West network

dimension where East- West operates for wireless and

mobile devices using inter- controller protocols such as

Border Gateway Protocol

(BGP) [16]. Hence, security of the underlying network

depends on the secured flow information and control

plane. Tools that monitor and measure and flows

between SDWN entities, therefore, requires security

from external access and service oriented attacks. This

study is concerned about sFlow and FlowVisor as one

of these tools.

Subjective assessments by the threat reporter. Octave

model is best suited for complex and larger system

where STRIDE focuses on network based application

and systems. Trike helps security auditing process with

distinct risk-based implementation than others,

however, is yet in experimentation stage and lacks

proper documentation and support. PASTA includes

risk management steps in the final stage of the process

and is not limited to a specific risk calculation formula

[22]. Thereby, introduced by Microsoft, SRTIDE

model method is used to identify and evaluate the

security threats on OpenFlow- based SDWN network

measurement and monitoring tools: sFlow and

FlowVisor.

STRIDE threat model reveals if a system or software in

concern is vulnerable to Spoofing, Tampering,

Repudiation, Information Disclosure, Denial of Service

(DoS) and Elevation of Privilege threat [20]. Each of

the STRIDE threats can be mapped to one security

property as shown in Table 1. and described in the

following:

a) Spoofing: In spoofing malicious user or program

masquerades gain illegal access in privileged data by

falsifying user information.

b) Tampering: Data tampering involves malicious

modification of information and resources, i.e.

alteration of data as it flows between two computers

over an open network, such as the Internet.

c) Repudiation: Repudiation threats are associated with

malicious users and masquerades who performs ac

action and deny without other parties having any way

to prove otherwise—for example, an attacker controller

performs an illegal operation in a SDN that lacks the

ability to trace the prohibited operations.

d) Information Disclosure: This treat means the

illegitimate availability of resource information of the

system or network or software to malicious and

unauthorized users or programs.

e) Denial of Service: This treat causes service

unavailability to the authorized legitimate users or

programs. f) Elevation of Privilege: In this type of

threat, an unprivileged user gains privileged access and

thereby has sufficient access to compromise or destroy

the entire system. This treat can cause penetration of all

system or network

Elements of sFlow system consists sFlow agents and

sFlow collector, illustrated in Fig. 2. Agent is the

software process that is remotely configured using a

Management Information Base (MIB) within the

device. Combining the interface counters and flow

samples into sFlow datagrams, these datagrams are sent

to the sFlow collector installed in the monitoring host

through the SDWN environment using Simple Network

Management Protocol (SNMP) [23].Including sFlow‘s

own collector sets: sFlow-RT, sFlow- Trend, sflowtool,

this sampling tool also support the third party collectors:

VitalSuit, Peakflow, Kentik Detect, FlowTraq etc.,

those handle more details of sFlow datagrams [4].

Illustration in Fig. 2 represents the Data Flow Diagram

(DFD) of sFlow that uncovers the crucial security risk.

sFlow doesn‘t provide any security mechanism for data

flow rather depends on secure third party management

environment for sFlow agents.Data flows are

vulnerable to Tampering, Information Disclosure and

DoS attack in absence of proper security mechanism. A

physical interface of switch, routers are pote-

As collectors can be vendor provided, security of the

received datagrams depends on vendor‘s will of

deployment and how they process the data. Hence,

sFlow doesn‘t provide any security mechanism. For

security reasons SNMPv3 should be used to configure

and control the sFlow agents to encrypt and

authenticate the datagrams before transmitting to the

collector.According to Table 1 data store are prone to


65

Tampering, Information Disclosure and DoS attack

vulnerabilities alike data flows. MIB contains

information about sFlow agents, collector ports and

even IP addresses. Using SNMP, sFlow agents can be

configured through a local Command Line Interface

(CLI) or SNMP commands.

In order to decline any anonymous actions, switches

and routers in the network should have some Access

Control (AC) mechanisms, i.e. Discretionary Access

Control (DAC), Role-Based Access Control (RBAC) to

ensure the interface‘s security [14]. In opposite case, if

CLI is accessible from unauthorized user, MIB in

sFlow is vulnerable to data Tampering, traffic

Information Disclosure and even DoS attack, holds the

MIB flow entries and collector details open for

unauthorized access and even attacker can modify the

information. In case of SNMPv1, SNMPv2

communication with collector is at similar risks.

FlowVisor partitions the minimum transmission

bandwidth for each slice assigning specific data rate to

a set of flows from that slice. FlowVisor keeps track of

every flow-entry for each guest controller and

partitions the flow table among the switches. Switches

are configured according to the resource allocation and

routing policies slices of the FlowVisor controller.

Slices are isolated and have their own ‗flowspace‘ or

set of region of data flows. This isolated slices can be

broken allowing different attacks.

A. Data Flows

FlowVisor adopts slicing policies for each guest

controller. Traffic sent from the production network

and guest controllers if matches the forwarding entries

in the FlowVisor is sliced for corresponding switches

according to ‗flowspace‘. Different slices having

flexible and different flow policies are strongly isolated.

Any traffic that does not match the existing forwarding

entries are sent to the production controller for

insertion. Production controller hence rewrites the

policies of corresponding slice. Attack on slice policy

rewrites from attacking entity can cause vulnerabilities

to such network with FlowVisor. If, therefore, data is

sent from an attacker, the controller cannot detect

because of policy rewrite and causes tampering of flow

rules and the network data and even DoS threats.

The switch configuration is stored in the flow entries of

the slices by the corresponding guest controllers. This

allows data traffic authentication to flow between the

controllers and switches inside the wireless OpenFlow

network even under mobility situations. This

mechanism ensures that data is secured against

Tampering, Information Disclosure and Spoofing

threats.

FlowVisor‘s Command Line Interface (CLI) provides

control access to users for data and slice configuration.

CLI uses user-authentication in terms of username, host

name and port number on accessing the interface and

slices and therefore secure from Spoofing, Tampering,

Repudiation and Elevation of Privilege threats.

Adapting Transport Layer Security can defend the

policy rewrite in production controller for unmatched

packets where virtual controller cannot modify the

MAC and IP address for the packets freely.

III. IMPLEMENTATION RESULTS

The implementation results can be shown as figure

below


66


67

IV. COMPARISON

Flow and FlowVisor both provide different network

monitoring and measurement functionalities. The

comparative threat model analysis of them is illustrated

in Table 6. Above analysis holds sFlow providing no

security in data flow and data store in DFD wherein

FlowVisor inherits security threat vulnerabilities in

isolated slices. This makes FlowVisor vulnerable to

Spoofing, Tampering and Information disclosure, even

delay and Denial of Service threats in data flow.

However, FlowVisor ensures security of switch

information stored in its own controller where sFlow

depends on external secure deployment environment to

ensure security in MIB data storage and flow entry

information. This makes sFlow vulnerable to spoofing,

DoS and information disclosure threat as switching

agents send unencrypted datagrams to the

collector.Using Transport Layer Security (TLS) in

forwarding the datagrams to the collectors can

eliminate information disclosure threats wherein

tampering can be tackled using access control

mechanism in CLI, agent configuring SNMPv3

protocols.

V. CONCLUSIONS

In this paper, discussed the reasons why DDoS attacks

are growing in cloud computing environments. Then

we summarized the difficulty in defeating DDoS

attacks in cloud computing environments. In addition,

we presented some good features of SDN-based cloud

in defeating DDoS attacks and discussed some

challenges of SDN-based cloud. Since SDN-based

cloud is still in its concept phase, we provided a

comprehensive survey on some of the works that have

already been done to defend DDoS attacks using

SDN.SDN brings a fascinating dilemma: a promising

tool to defeat DDoS attacks in cloud computing

environments, versus a vulnerable target to DDoS

attacks. It is in favor of the community to study how to

make full use of SDN‘s advantages to defeat DDoS

attacks and how to prevent SDN itself becoming a

victim of DDoS attacks in cloud computing

environments. This paper attempts to briefly explore

the current technologies related to SDN and DDoS

attacks, and we discuss future research that may be

beneficial in these issues.

In future, this work can help to understand how to

make full use of SDN‘s advantages to defeat DDoS

attacks in cloud computing environments and how to

prevent SDN itself from becoming a victim of DDoS

attacks, which are important for the smooth evolution

of SDN-based cloud without the distraction of DDoS

attacks.

VI.REFERENCES

[1] G. Pallis, ―Cloud computing: The new frontier of

Internet computing,‖ IEEE

[2] T. Taleb, ―Toward carrier cloud: Potential, challenges,

and solutions,‖ IEEE Wireless Commun., vol. 21, no.

3, pp. 80–91, Jun. 2014.

[3] F. R. Yu and V. C. M. Leung, Advances in Mobile

Cloud Computing Systems. New York, NY, USA:

CRC Press, 2015.

[4] Y.-D. Lin, D. Pitt, D. Hausheer, E. Johnson, and Y.-B.

Lin, ―Software defined networking: Standardization

for cloud computing‘s second wave,‖ Computer, vol.

47, no. 11, pp. 19–21, Nov. 2014.

[5] Z. Yin, F. R. Yu, S. Bu, and Z. Han, ―Joint cloud and

wireless networks operations in mobile cloud


68

computing environments with telecom operator

cloud,‖ IEEE Trans. Wireless Commun., vol. 14, no.

7, pp. 4020–4033, Jul. 2015.

[6] Y. Cai, F. R. Yu, and S. Bu, ―Dynamic operations of

cloud radio access networks (C-RAN) for mobile

cloud computing systems,‖ IEEE Trans. Veh. Tech.,

accepted for publication, DOI:

10.1109/TVT.2015.2411739.

[7] Y. Cai, F. R. Yu, C. Liang, B. Sun, and Q. Yan,

―Software defined device-to-device (D2D)

communications in virtual wireless networks with

imperfect network

[8] Ku, Y. Lu, and M. Gerla, ―Software-defined mobile

cloud: Architecture, services and use cases,‖ in Proc.

IEEE IWCMC, Aug. 2014, pp. 1–6.

[9] P. Klemperer, Y. Liang, M. Mazurek, M. Sleeper, B.

Ur, L. Bauer,

[10] L. F. Cranor, N. Gupta, and M. Reiter, ―Tag, you can

see it!: Using tags for access control in photo

sharing,‖ in Proc. ACM Annu. Conf. Human Factors

Comput. Syst., 2012, pp. 377–386

[11] Multi-authority attribute-based encryption,‖ in Proc.

16th ACM Conf. Comput. Commun. Security, 2011,

pp. 121-130

Documents

Handling DDOS attacks in Cloud Computing based on SDM System