Handling DDOS attacks in Cloud Computing based on SDM System

(1)

Handling DDOS attacks in Cloud Computing based on SDM

System

S. Akhilesh Kumar

1

_{, A. Sundersingh}

2

¹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 Deﬁned 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.

(2)

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.

(3)

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

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-

(4)

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

(5)

(6)

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 deﬁned 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

(7)

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 deﬁned device-to-device (D2D)

communications in virtual wireless networks with imperfect network

[8] Ku, Y. Lu, and M. Gerla, ―Software-deﬁned 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