System and method for mitigating Cross VM attacks in Cloud ...

System and method for mitigating Cross VM attacks in Cloud Computing by securing the network traffic Bhaskar Kumar

Kumar Abhishek

Abhay Kumar

M.P.Singh

Sonus Network India Pvt. Limited, India [email protected] om,

Dept. of Computer Science and Engg, NIT Patna, India kumar.abhishek@nitp .ac.in

Dept. of Computer Science and Engg, NIT Patna, India [email protected] .in

Dept. of Computer Science and Engg, NIT Patna, India [email protected]

Abstract: Cloud computing involves deploying groups of remote servers and software networks, offering computational resources as a service to clients. The servers are virtualized, which means virtual machines are rapidly provisioned on demand and released without service provider’s interaction. These virtual machines might interact with each other to provide services. Under favorable conditions, it is possible for an intruder to identify the target server and launch a malicious virtual machine on the target to perform side channel attacks against other colocated VMs [5]. This paper discusses about hiding the servers location using a broadcast domain such that opponent is not able to trace the target server after a certain point. In this paper, a cloud computing environment is implemented using Openstack platform. It is shown that this approach is secure against all the possible attacks that an intruder can use to trace the target. Some more steps to further enhance the security is also suggested. The size of the broadcast domain varies according to available bandwidth. This design can be easily implemented in cloud computing platforms, where virtual resources are dynamically created and destroyed.

INTRODUCTION

Research works [5], [6], [11] have revealed that cross VM Side Channel attacks are possible. Microsoft’s Azure and Amazon’s EC2 cloud services allow users to create VMs on demand. An intruder can breach the security walls to place his own malicious VM in the environment, and then access shared hardware and cache locations to perform side channel attacks against co-located VMs [5], [6], [11]. Many recent works have been done on cross-VM attack mitigation, but all these approaches are limited to cache based attacks [8], [9]. However, other than secure cache management, there can be several other ways to mitigate cross-VM attack risk. One of the ways is to maintain the location privacy. This paper concentrates on preventing location privacy based attacks. Location privacy routing algorithms have been developed to forward packets in directions not always towards the receiver, so as to confuse intruder. However, protection using these

978-1-4799-8969-0/15/$31.00 ©2015 IEEE

The proposed approach, assumes that an opponent can identify the target server using any of the techniques and create a VM on the target server and is capable of attacking the co-located VMs. As a solution to this problem, grouping of the servers in a special way is performed, such that opponent is not able to trace the target. All the requests that travel from source to destination have to travel through a broadcast domain, which misleads the opponent’s path and the opponent is unable to detect the target beyond this point. The cloud can be prepared using Openstack APIs, discussed in detail in the results section. Results have been shown that this approach causes little bit of performance issue, which is still acceptable. A) Need for this Design

Keywords: VM(Virtual Machine); Cloud Computing; Broadcast

I.

algorithms will not be full protection because overall network traffic still points towards the receiver, and the intruder can still trace it.

Cross VM attacks in cloud computing can be possible under favorable conditions. If not checked, this can lead to problems like denial of services, shared cache attacks, shared hardware attacks, shutdown of services, etc. Even though good amount of work have been done on cache based attacks, nothing much have been done to hide network location and prevent attack. Thus, this paper targets to eliminate an inevitable threat to cloud computing network. B) Existing Methodology In 2012, Ristenpart showed that it is possible to locate the target server and create malicious VMs to perform side channel attacks like extracting keystroke patterns [5]. Shortly later, Zhang demonstrated an access driven side channel attacks to extract decryption key information from co-located VMs using cache timing attack [6]. Then after, Weiss demonstrated extraction of cache timing attack to extract AES inside a VM [11].

221

Many recent works have been done on mitigating cross-VM attacks, but all these approaches are limited to cache based attacks [8], [9]. In this paper, a secure network infrastructure is implemented with broadcast domain, such that an intruder is not able to locate the target server. The cloud is implemented using Openstack platform. It is shown that this design is secure against all the possible techniques that an intruder can perform to locate target server.

sections: implementation of cloud, implementation of Broadcast Domain, implementation of an intruder. Each of the sections are discussed in brief. Fig.2 gives a brief overview of Openstack cloud environment along with its basic functionalities

II. SUMMARY OF THE DESIGN In short, the design proposed in this paper works as follows: the opponent tries to identify the target server using any of the techniques (Brute-Force, small packet round trip time, hop-byhop packet tracing, etc). However, the opponent is not able to trace the packets inside the broadcast domain because of rebroadcasting, thus fail to identify the target.

III. IMPLEMENTING THE DESIGN Fig. 1 shows the network design architecture. All the packets from source to destination travel via a broadcast domain.

Fig.2 Open Stack Cloud Design [1]

A) Cloud Implementation using OpenStack OpenStack is a set of software tools for building and managing cloud computing platforms for public and private clouds. First of all, a new Openstack software needs to be installed on UNIX system. Openstack APIs provide wide range of services like Identity Service, Compute Service, Network Service, Storage Service, Orchestrator Service, etc. as shown in Fig.2. Network Service is used to Create a network, querying for network, add/delete a network, etc as below: OSClient os = OSFactory.builderV3(); Network network = os.networking().network() .create(Builders.network().name("ext_network").tenantId (tenant.getId()).build());

Fig.1 Proposed Model

List networks = os.networking().network().list(); Openstack is used to implement the cloud computing software platform. Openstack provides APIs to control pools of processing, storage, and networking resources throughout a data center—which users manage through a web-based dashboard, command-line tools, or a RESTful API [1]. The rest of this implementation section is categorized into 3

// Get network by ID Network network= os.networking(). network().get ("networkId"); //Delete a Network by ID

222

os.networking().network().delete("networkId"); The Compute service provides APIs to manage virtual machines on a servers. A virtual hardware template can be created as below: Flavor flavor = Builders.flavor().name("Sample Resources Template").ram(512) .vcpus(6).disk(60).rxtxFavor(1.2f)

Broadcast domain traffic must be scalable, so as to adjust with network overload. C) Implementation to show how an intruder can attack Some of the common techniques that an attacker can use to locate the target server are as follows: • • •

.build(); flavor = os.compute().flavors(). create(flavor);

•

All the available APIs are listed at [7]. Any client can customize his cloud using the above APIs. B) Implementation of Broadcast Domain A broadcast domain is a small part of network, with boundaries defined by routers and other networking devices. Within a broadcast domain, each node can communicate directly with each other. A switch acts as a buffer and checks for the network packets flowing between the nodes. The switch forwards the data packets to the receiver only when all the nodes have received the packets.

•

Hop by hop packet tracing. Small packet roundtrip time. Perform a TCP SYN traceroute to an open port on the target. Matching the eth0 IP of numerically close internal IP addresses. Brute-Force trial and error method.

Once the target is located, the opponent can bypass the firewall to create his own VM on the target and perform sidechannel attacks against the co-located VMs [5]. All of the above attacking techniques can be avoided using this suggested design. The attacker is able to trace the packets till the entry point of the Broadcast Domain. Once the packet enters the Broadcast domain, the attacker will not be able to follow the packet. IV. RESULT AND DISCUSSION

A Broadcast Domain suffers from 2 main problems: •

Excessive broadcast traffic can seriously degrade network performance by decreasing the available network bandwidth. Therefore, network bandwidth must be considered and the broadcast domain should be implemented accordingly.

•

Processing power of network nodes can be decreased by Broadcasting. Normally a Broadcast packet is relevant to the receiver and broadcast packet is irrelevant for every other nodes. This is an unnecessary overhead.

The above design can be implemented using Openstack software platform, which provides APIs for cloud implementation. A user has to login to the cloud and he gets access to the UI, which has provision to create his own network and monitor and manage his nodes. The dashboard section provides the statistics of network details in the form of graphs. The above design was evaluated to measure the performance of the Broadcast Domain against the number of nodes. It was found that the network overload increased. However, for a certain number of nodes, the network overload was acceptable.

However, there are several ways to implement the Broadcast domain in an efficient way. One way is to implement a dynamic Broadcast domain, which adds/removes nodes depending upon the network bandwidth. By this way, the network bandwidth overhead can be controlled. Other way is to measure the maximum traffic overhead in the network and then decide the size of Broadcast Domain. Other way is to implement a Pairwise Broadcast Synchronization. Node pairs could be carefully chosen so as to reduce the number of message exchanges [4]. If some more bandwidth is available, introduction of fake packets into the network can further confuse the opponent.

223

V. CONCLUSION Based on the results and design, it can be concluded that this design misleads the opponent from identifying the target server and thus mitigates the possibility of cross-VM side channel attacks. Results have been shown to prove that this design is implementable with acceptable performance overhead. This design can be easily implemented in cloud computing platforms, where virtual resources are dynamically created and destroyed. Depending upon the bandwidth availability, the Broadcast domain size may vary so as to avoid any kind of performance overhead. VI. SCOPE AND LIMITATION The proposed design is subject to all kinds of network limitations. Deployment requires formatting the platform in a generic way so that it works for all different types of devices. Also, the design is subject to all the disadvantages and shortcomings of cloud software platform (Open stack, in this case).

Fig.3 Graph for percentage overload increase against number of nodes

As the number of servers in broadcast domain increases, network may suffer from overloading problems, as the bandwidth is unavailable. Therefore an effective broadcast domain is required. VII. FUTURE PROSPECT

Fig. 4 Graph for percentage delay against number of nodes

Once the sender sends a request to the receiver, the packet has to traverse through the Broadcast Domain. The opponent is easily able to track the packet upto the entry point of the Broadcast Domain using any of his tracking method. However, once the packet enters into the Broadcast domain, the opponent is unable to figure out the exact path. Rebroadcasting takes place, which misleads the opponent.

The proposed design can be enhanced to further secure the network from cross VM attacks. Steps must be taken to lock down the OS application instances as much as possible. It must be made sure that all the unused ports and interfaces are closed, firewall is enabled and no unwanted processes are running. Applications should be installed to dedicate time to tuning and collect local process monitoring data logs so as to detect any malware activity. Also, applications should be implemented in such a way that they access shared resources like memory cache in a consistent, predictable way. In order to further confuse the opponent, some fake packets can be added to the network, if more bandwidth is available. Checksum can be used to verify the authenticity of data packets.

224

REFERENCE [1] [2]

OpenStack Docs: Current http://docs.openstack.org/ OpenStack API Documentation: http://developer.openstack.org/apiref.html [3] Get Started with OpenStack : http://docs.openstack.org/adminguide-cloud/content/ch_getting-started-with-openstack.html [4] Li, Xiaoji, Xiuying Qin, Lin Zheng, and Hongbing Qiu. "Simultaneous clock synchronization in double broadcast domain of WSN." In Millimeter Waves (GSMM), 2012 5th Global Symposium on, pp. 367-371. IEEE, 2012. [5] Ristenpart, Thomas, Eran Tromer, Hovav Shacham, and Stefan Savage. "Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds." In Proceedings of the 16th ACM conference on Computer and communications security, pp. 199-212. ACM, 2009. [6] Zhang, Yinqian, Ari Juels, Michael K. Reiter, and Thomas Ristenpart. "Cross-VM side channels and their use to extract private keys." In Proceedings of the 2012 ACM conference on Computer and communications security, pp. 305-316. ACM, 2012. [7] JavaDoc - Overview (OpenStack4j Core 2.0.1 API): http://www.openstack4j.com/javadoc/ [8] Wang, Zhenghong, and Ruby B. Lee. "New cache designs for thwarting software cache-based side channel attacks." In ACM SIGARCH Computer Architecture News, vol. 35, no. 2, pp. 494-505. ACM, 2007. [9] Wang, Zhenghong, and Ruby B. Lee. "A novel cache architecture with enhanced performance and security." In Microarchitecture, 2008. MICRO-41. 2008 41st IEEE/ACM International Symposium on, pp. 83-93. IEEE, 2008. [10] Azar, Yossi, Seny Kamara, Ishai Menache, Mariana Raykova, and Bruce Shepard. "Co-Location-Resistant Clouds." In Proceedings of the 6th edition of the ACM Workshop on Cloud Computing Security, pp. 9-20. ACM, 2014. [11] Weiss, Michael, Benedikt Heinz, and Frederic Stumpf. "A cache timing attack on AES in virtualization environments." In Financial Cryptography and Data Security, pp. 314-328. Springer Berlin Heidelberg, 2012.

225