Security Issues In Eucalyptus Cloud

Published Date: 02 Nov 2017

Eucalyptus is an open source software framework for Cloud Computing that implements Infrastructure as a service (IaaS). It allows the users to run and control virtual machine instances, store and retrieve data using the WALRUS Data Storage Service and create and manage volumes and snapshots using Block Storage Service.

Cloud entities including cloud users, service providers and business partners share the available resources at different levels of technological operations. Hence, the Cloud Computing framework is inherently susceptible to a great number of security threats due to the amalgamation of different computing technologies that make it a complex architecture. Among all the potential threats, those targeting the users’ data are significantly important and must be handled properly to facilitate effective cloud functionality.

Therefore, the preservation of cloud users’ data privacy is one of the major challenges to be considered in a typical private cloud environment. It is very important that the users’ data and metadata is protected and is available to authorized users only.

The focus of this paper is to identify some of the critical users’ data privacy issues that could exist in a typical Private Cloud Computing environment.

Keywords : Eucalyptus, Walrus, Buckets, Objects.

I. INTRODUCTION

Cloud computing is a computing paradigm that shifts drastically from traditional computing architecture. Although this new computing paradigm brings many advantages like utility computing model but the design is not flawless and hence suffers from not only many known computer vulnerabilities but also introduces unique information confidentiality, integrity and availability risks as well due its inherent design paradigm.

The involvement of various different technologies like databases, networks, virtualization, operating systems etc. in Cloud Computing gives rise to many security concerns. One of the fundamental security concerns in relation to the cloud database is achieving a reasonable balance between the users’ roles and rights. Private Cloud environments are much more complex and different from simple corporate environments in the sense that their services are based on virtualization technology and are susceptible to same attacks that afflict the physical deployments as well as new threats that exploit the weaknesses in virtualized environments.

One important fact about Cloud security is that the owner may not have control over his data or metadata. Private Clouds provide the facility of on-site virtualized data storage in order to maximize resource utilization which in turn raises the issue of users’ data privacy.

II. DATA PRIVACY ISSUES IN EUCALYPTUS

We can classify Eucalyptus cloud users’ data into three major categories.

Cloud users’ personal information such as login names, passwords, and personal identification data requested by the cloud provider for users’ subscription.

Metadata of the cloud users’ data residing in the cloud.

Cloud users’ cloud resident data (including user created VM images called EMIs).

The prospective attacks in a private cloud environment include attacks from internal and external sources. External sources are business competitors, cloud’s legitimate and illegitimate users and external computing systems. The internal sources include administrators and technical staff.

Among all possible attack sources, the cloud’s administrators stand the greatest chance of violating the users’ data privacy. Having physical access to the cloud machines, privileged cloud access rights and most importantly cloud administration expertise, the cloud administrators can deliberately compromise the cloud users’ data privacy to their own advantages.

III EUCALYPTUS DESIGN & ARCHITECTURE

Eucalyptus Components :

Eucalyptus is composed of several components that interact with one another through well-defined interfaces.

Eucalyptus is comprised of five components: Cloud Controller (CLC), Walrus, Cluster Controller (CC), Storage Controller (SC) Node Controller (NC) and an optional component available for eucalyptus subscriber. Each component is a stand-alone web service. This architecture allows Eucalyptus both to expose each web service as a well-defined, language-agnostic API, and to support existing web service standards for secure communication between its components.

A detailed description of each Eucalyptus component follows.

Cloud controller :

The Cloud Controller (CLC) is the entry-point into the cloud for administrators, developers, project managers, and end-users. The CLC queries other components for information about resources, makes high-level scheduling decisions, and makes requests to the Cluster Controllers (CCs). As the interface to the management platform, the CLC is responsible for exposing and managing the underlying virtualized resources (servers, network, and storage). We can access the CLC through command line tools that are compatible with Amazon’s Elastic Compute Cloud (EC2) and through a web-based Dashboard.

Cluster Controller :

CC has three primary functions: schedule incoming instance run requests to specific NCs, control the instance virtual network overlay, and gather/report information about a set of NCs. When a CC receives a set of instances to run, it contacts each NC component through its describeResource operation and sends the runInstances request to the first NC that has enough free resources to host the instance. When a CC receives a describeResources request, it also receives a list of resource characteristics (cores, memory, and disk) describing the resource requirements needed by an instance (termed a VM "type"). With this information, the CC calculates how many simultaneous instances of the specific "type" can execute on its collection of NCs and reports that number back to the CLC.

CCs gather information about a set of NCs and schedules virtual machine (VM) execution on specific NCs. The CC also manages the virtual machine networks. All NCs associated with a single CC must be in the same subnet.

Storage Controller :

The Storage Controller (SC) provides functionality similar to the Amazon Elastic Block Store (Amazon EBS). The SC is capable of interfacing with various storage systems (NFS, iSCSI, SAN devices, etc.). Elastic block storage exports storage volumes that can be attached by a VM and mounted or accessed as a raw block device. EBS volumes persist past VM termination and are commonly used to store persistent data. An EBS volume cannot be shared between VMs and can only be accessed within the same availability zone in which the VM is running. Users can create snapshots from EBS volumes. Snapshots are stored in Walrus and made available across availability zones.

Node Controller :

The Node Controller (NC) executes on any machine that hosts VM instances. The NC controls VM activities, including the execution, inspection, and termination of VM instances. It also fetches and maintains a local cache of instance images, and it queries and controls the system software (host OS and the hypervisor) in response to queries and control requests from the CC. The NC is also responsible for the management of the virtual network endpoint.

Walrus :

Walrus allows users to store persistent data, organized as buckets and objects. We can use Walrus to create, delete, and list buckets, or to put, get, and delete objects, or to set access control policies. Walrus is interface compatible with Amazon’s Simple Storage Service (S3), providing a mechanism for storing and accessing virtual machine images and user data. Walrus can be accessed by end-users, whether the user is running a client from outside the cloud or from a virtual machine instance running inside the cloud. Walrus should be considered as a simple file storage system.

An architectural diagram of WALRUS is given in Figure 1 indicating the various third party tools using which the user can access WALRUS storage via REST/SOAP over HTTP while the cloud controller provides access control to WALRUS objects using ACLs and user credentials.

The WALRUS buckets can be accessed by the users for the following two services :

For storing and managing Eucalyptus VM images (termed as ‘EMIs’-Eucalyptus Machine Images).

For storing and managing cloud users’ data.

The web interface of Eucalyptus installation supports two types of accounts ‘administrator’ account (called ‘admin’ by default) with privileged access rights and ‘user’ accounts (named by the users themselves).

A successful user registration process with a Eucalyptus supported cloud provider supplies the registered users with X509 certificates (a credentials zip file named ‘euca2-username-x509’) and two query interface credentials namely Query ID and Secret Key. On decompression, the credentials zip file provides the users with their RSA public and private keys, X509 certificates of the cloud provider and the certification authority and a file named ‘eucarc’ comprising of all the vital user credentials needed by the users to use the cloud services.

Third party tools like CloudBerry Explorer for Amazon S3, RightScale, Boto, s3curl, s3cmd and s3fs can be used for interacting with WALRUS. Users can use these graphical interface and command line tools for streaming data in and out of WALRUS and accessing the S3 buckets as local directories.

We are using s3curl for interacting with WALRUS; it adds security parameters as curl headers. Using s3curl, users can create/delete/list buckets, put/get/delete objects, set object/bucket access control policies, enable/disable object/bucket access logging and obtain MD5 checksums and last modification date and time for objects and buckets.

WALRUS implements ACLs (access control lists) for limiting users’ access to buckets and objects. A Eucalyptus user has to provide his SECRET KEY and ACCESS KEY while requesting access to buckets and objects. Once the user is authenticated, read and write permissions are granted over standard HTTP. WALRUS uses MD5 hashing technique in order to provide consistency to the stored data.

EUCALYPTUS DATABASE FILES :

There are five file system locations that are critical to ensure the efficiency of a Eucalyptus installation. These include the

Configuration File - /etc/eucalyptus/eucalyptus.conf

Database Files - /var/lib/eucalyptus/db/eucalyptus_*.script/log/properties

Cryptographic Keys - /var/lib/eucalyptus/keys

Walrus Buckets - /var/lib/eucalyptus/bukkits

Storage Controller Volumes - /var/lib/eucalyptus/volumes

Two of these file system locations, namely ‘Database Files’ and ‘WALRUS Buckets’, are used by Eucalyptus to store cloud users’ data. The ‘Database Files’ are used to store cloud users’ personal information and metadata of cloud users’ data and ‘WALRUS Buckets’ are used to store cloud users’ data itself and the image files (parts of kernel, ramdisk and root file system images in encrypted form along with the respective manifest files) of users’ custom images as well as the UEC installed images. A Eucalyptus supported cloud consists of seven distinct HSQL based catalogs (databases) solely comprising of ‘memory’ type tables. The schema, table definitions, database objects definitions and the data for these ‘memory’ type tables are stored in ‘*.script’ files, which are used with ‘*.log’ and ‘*.properties’ files to reconstruct the database in memory every time a request to open the database is received by the database engine.

Of the seven database files namely eucalyptus_auth, eucalyptus_config, eucalyptus_dns, eucalyptus_general, eucalyptus_images, eucalyptus_storage, eucalyptus_walrus.log/properties/script,eucalyptus_auth.script, eucalyptus_general.script and eucalyptus_walrus contain the critical cloud users’ personal information and the meta data of cloud users’ data.

BUCKET RELATED ATTACKS :

It involves making use of the credential file ‘eucarc’ along with attribute values as extracted from the catalog eucalyptus_auth.script. Source this new eucarc file and run the s3curl commands to create a new bucket impersonating the user whose credentials are used. Once the attacker is in possession of the list of user owned buckets, by using the credentials he can interact with the Walrus buckets.

3.2.2 OBJECT RELATED ATTACKS :

The attacker needs to know the exact bucket name in which the target object is located. After getting hold of this information, the attacker needs to make a new eucarc file with the query interface credentials of his victim, source this file and run s3curl

commands to put an object into the victim’s bucket, get the MD5 checksum, size and modification time of a victim’s object, read the victim’s object into a file or delete a victim’s object.

3.2.3 ACCESS CONTROL LIST RELATED ATTACKS :

Each WALRUS bucket and object has an Access Control List (ACL) attached to it as a subresource. To launch access control list related attacks on buckets/objects, the attacker first needs to get hold of their respective ACL subresources. Then the attacker modifies the *.acl file or creates a new *.acl file containing his preferred access control rights.

3.2.4 USER PASSWORD RELATED ATTACKS :

Eucalyptus enables the users to generate access log files for the buckets that they own. The access log files are objects of particular interest to the attackers since they provide the attackers with the opportunity to remove their attack traces. Another attack avenue for the attacker can be to read the ‘logging’ subresources of the victim’s buckets into *.logging files, make the desired modifications to the selected subresource in order to forge the real information contained in the log files and finally set the modified file as the ‘logging’ subresource of the target bucket.

4 S3Curl COMMANDS :

We are using s3curl for interacting with WALRUS. It adds security parameters as curl headers. Using s3curl, users can create/delete/list buckets, put/get/delete objects, set object/bucket access control policies, enable/disable object/bucket access logging and obtain MD5 checksums and last modification date and time for objects and buckets.

s3curl command to list the contents of the buckets.

./s3curl.pl --id $EC2_ACCESS_KEY --KEY $EC2_SECRET_KEY --get --

--s –v $S3 URL/bucketName > bucket.list

Experimental Results

The Ubuntu Enterprise Cloud (UEC) is deployed with Cloud Controller, Walrus, Cluster Controller & Storage Controller on one system and the node controller on the other.

The cloud is ready to provide the infrastructure as the service. The services provided include customized Linux operating systems to suit the requirements of the users. These services are provided on-demand basis.

Walrus bucket can be loaded with files/objects similar to the images.

S3Curl command line interface is deployed which communicates with the Walrus.

Different accounts, groups and users are created with their individual credentials.

Network modes are configured to run the cloud on both MANAGED-NOVLAN & SYSTEM MODE as per requirements.

Conclusion

Ubuntu Enterprise Cloud (UEC) offers a promising solution to organizations aspiring to exploit their fullest infrastructural potential. A Eucalyptus based private cloud deployment, however, must be weighed in the light of prospective benefits and imminent risks. Public clouds are normally considered to be incapable of providing reliable guarantees in relation to the preservation of their users’ data privacy owing to the fact that they store users’ data at multiple geographical locations and the users are themselves not aware of the physical location of their data, thus limiting users’ control over their own data.

This project is concerned with the security analysis of cloud, pertinent to data privacy of users’ cloud resident data and metadata. It identifies the potential attack sources and prospective attacks originating from these sources.