Toward inter-VM Visibility in a Cloud

Environment Using Packet Inspection

Karim Benzidane, Saâd Khoudali, Fetjah Leila and Abderrahim Sekkaki

Computer sciences Department

University Hassan II Faculty of Sciences Ain Chock

k.benzidane@live.fr, s.khoudali@yahoo.fr, fetjah_leila@yahoo.fr and a.sekkaki@fsac.ac.ma

Abstract—Virtualization is one of the key elements of

Infrastructure as a Service (IaaS), Cloud Computing (CC) offerings and private Clouds, and it is increasingly used in portions of the back-end of Platform as a Service (PaaS) and SaaS (Software as a Service) providers as well. This creates new targets for intrusion due to the complexity of access and difficulty in monitoring all interconnection points between systems, applications, and data sets. This raises many questions about the appropriate infrastructure, processes, and strategy for enacting detection and response to intrusion in a Cloud environment.

This article discusses the security and the visibility issues of inter-VM traffic and solutions for it within a Cloud environment context, by proposing an approach relying on distributed intrusion detection technique and packet inspection.

I. INTRODUCTION

Cloud Computing is an innovative computing model in which resources are provided as a service over the Internet, on an as-needed basis, relieving users from the responsibility of buying and managing a dedicated complex computing infrastructure [1]. CC is a large-scale distributed computing paradigm that is driven by economies of scale, in which a pool of abstracted, virtualized, dynamically-scalable, managed computing power, storage, platforms, and services are delivered on demand to external customers over the Internet. The CC paradigm is usually linked to SaaS or Software as a Service model [2]. This service model works by providing applications for end users on service-based manner. Before this paradigm can be widely accepted, the security, privacy and reliability provided by the services in the cloud must be well established.

The security factor of a CC infrastructure is an important one. In this case, we need to look into the Cloud environment (Network, Systems and applications) in a very deep manner to keep it informant, that will help to prevent security and performance disruptions which can destroy and compromise smooth transactions, and since the main concept of the CC is to allow end users to execute various applications in on-premise or off-premise resources, most of them are shared in a virtual environment creating new security and performance challenges leveraging attacks to be launched from compromised Virtual Machines (VM) that can damage the ability to serve all end users demands.

Right now, the most important problems facing VMs are inter-VM threat and VM hopping. Inter-VM threat occurs when a hacker takes control of a single VM and then gains access to the underlying hypervisor, allowing them access to control of all the

VMs on the system. VM hopping is when a hacker is able to control multiple virtual servers that all run on the same hardware.

The remainder of the article is structured as follows: in the next section, we discuss some technology security issues in CC. The third section presents the core of our approach by explaining its components. In section 4, we present some scenarios by highlighting the use of the frame tag and the agents in a CC environment. The last section contains a summary and conclusions.

II. TECHNOLOGY SECURITY ISSUES IN CC

As widely known, virtualization is the key technological driver for a fair amount of the success of CC idea. Initially driven by the need to consolidate servers to achieve higher hardware utilization rates, boost operational efficiency, and cut costs, enterprises more recently have implemented virtualization to get on-demand access to CC can result in the creation of multiple VMs out of a single physical server. Each VM is itself a virtual server comprising a guest OS, middleware, application and data. Therefore, virtualization comes with new challenges; new attack a surface in the hypervisor, and also another important impact is on network security. VMs communicate over a hardware backplane rather than a network. As a result, the standard network security controls are blind to this traffic and cannot perform monitoring or in-line blocking. In terms of actual threats to a virtualized environment [11] [12], these fall into a number of categories, centered mostly on the hypervisor: Hyperjacking, VM escape, VM hopping, VM migration, VM theft and inter-VM traffic.

Hyperjacking: Subverting the hypervisor or injecting a rogue hypervisor on top of the hardware layer. Since hypervisors run at the most privileged ring level on a processor, it would be hard or even impossible for any OS running on the hypervisor to detect. In theory, a hacker with control of the hypervisor could control any virtual machine running on the physical server.

VM escapes: is a security attack designed to exploit a hypervisor, it allows a hacker to gain access over the hypervisor and attack the rest of the VMs. If the attacker gains access to the host running multiple VMs, the attacker can access the resources shared by the other VMs.

VM Hopping/Guest jumping: is the process of hopping from one VM to another VM using vulnerabilities in either the virtual infrastructure or a hypervisor. These attacks are often accomplished once an attacker has gained access to a low-value, thus less secure, VM on the same host, which is then used as a launch point for

further attacks on the system. Because there are several VMs running on the same machine, there would be several victims of the VM hopping attack. An attacker can falsify the SaaS user's data once he gains access to a targeted VM by VM hopping, endangering the confidentiality and integrity of SaaS. VM hopping is a considerable threat because several VM’s can run on the same host making them all targets for the attacker.

VM mobility/migration: enables the moving or copying of VMs from one host to another over the network or by using portable storage devices without physically stealing or snatching a hard drive. It could lead to security problems such as spread of vulnerable configurations. The severity of the attack ranges from leaking sensitive information to completely compromising the OS. A man-in-the-middle can sniff sensitive data, manipulate services, and possibly even inject a rootkit. As IaaS lets users create computing platforms by importing a customized VM image into the infrastructure service. The impact on confidentiality, integrity, and availability via the VM mobility feature is quite large.

Inter-VM: In a traditional IT environment, network traffic can be monitored, inspected and filtered using a range of server security systems to try to detect malicious activity. But the problem with virtualized environments provides limited visibility to inter-VM traffic flows. This traffic is not visible to traditional network-based security protection devices, such as the network-based intrusion prevention systems (IPSs) located in network, and cannot be monitored in the normal way.

III. THE PROPOSED APPROACH

As mentioned in the introduction, a malicious user has a huge hack domain since the inter-VM communication is blind to the security appliances on the LAN, giving him the possibility to take control of other VMs via a compromised one. Thereby, the focus of our work is about controlling the inter-VM traffic, analyzing it, and then preventing the non-compliant one.

Figure 1. A simple model for a Cloud Service Provider.

The core of our proposed approach is about restricting the access to the critical resources in a virtual environment, thus by securing the inter-VM communication. We are basing our work on a simple model as depicted in Fig1, containing the essential elements that we can find in a Cloud Service Provider: Cloud Manager, Hypervisor, Virtual Machines...

Relating to other works especially in intrusion detection [6] [7], we find that all of the measures that should be taken must to be distributed since it is a Cloud environment [10], but the work done so far is about detecting and preventing a malicious traffic [8]. Our approach aims to control and analyze a particular traffic which is the inter-VM traffic by adding a frame called frame tag via an agent in the payload of the IP packet ensuring a high-level of integrity, so that the receiving VM's agent will detect and analyze the incoming traffic then respond by accepting or rejecting this IP packet according to the compliance of the information on the frame tag. The idea behind this approach is that in a virtual environment the visibility factor is a serious issue for the security appliances. Thus, a compromised VM can be a jumping-off point in order to send requests to other VM for instance a VM hosting a database to retrieve information in a malicious way, while in a legitimate scenario as depicted in Fig1, App1 hosted in a VM in tenant 1 sends a request to the DB1 hosted in another VM in order to get the requested information. Thereby, we are having two distinctive elements whom are the tenant and the application, meaning who sends the request and from where. Hence, what we are trying to achieve with our approach is to authenticate each request/ IP packet communicating between VMs by encapsulating these two identifiers in the frame tag which will be added in the beginning of the payload of the IP packet by the sending VM's agent, then detected and analyzed by the receiving VM's agent acting like a light-weight intrusion prevention system by rejecting the non-compliant packets.

A. The frame tag

Users in a CC environment access their services by providing a digital identity. Commonly, this identity is a set of bytes related to the user. Based on this digital identity, a Cloud system can recognize what right this user has and what is allowed to do. Most of the Cloud platforms include an identity service management service (like keystone in OpenStack). Following the same analogy, our approach is about identifying the application that sends the request (IP packet) to another machine in the same tenant. Hence, we propose a new structure of a frame called frame tag, as shown in the Fig 2. The frame tag is generated between a pair of communicating agents, and it is inserted after the IP header and at the beginning of the payload, it contains three fields: Tenant tag, Application Tag, Flag.

Figure 2. Structure of a frame Tag.

To ensure the privacy and the integrity of the tenant tag and the application tag, tags are generated by a hashing mechanism then stored in a database called database tag. This approach will

ensure a monitored traffic by an agent acting as light-weight intrusion detection and prevention system and responds according to the frame tag field’s values, providing a secure inter-VM communication.

1) The flag field: The flag section of the frame tag represents

an indicator of what action should be taken by an agent

depending on its value. The flag is a set of bits defining the type

of the frame tag and can take several values: Data flag,

Subscription flag and Rule Update flag and Trust level flag that

we will be discussed more explicitly in the agent section.

2) The tenant tag field: When a tenant is created the identity

management service in the Cloud Manager creates an ID for this

tenant, the same thing happens with the tenant tag and it is stored

into the database tag. When a request is sent from a VM to

another VM within the same tenant, the frame tag is generated

and added by the agent in the payload of the IP packet and

foreseeably the tenant tag, thereby ensuring the integrity of the

inter-VM communication, but more importantly the prevention of

spring boarding to another VM within another tenant, thereby

adding a strong layer of tenant isolation.

3) The application tag field: When an application is added and

installed on a VM, the client has to certify the trustworthiness of

this application by adding it via the console management, so that

via a hashing mechanism an application tag is created and stored

in the database tag. The use of the application tag in our approach,

is that when App1 in Tenant 1 sends a request to DB 1 hosted in

another machine within the same tenant and if the user did certify

this application as a trustworthy one, the sending agent machine

will generate the frame tag in order to send this request by filling

its fields with the right tenant tag and application tag and adding it

to the payload of the IP packet. The frame tag in our proposed approach plays the role of an

authenticator by encapsulating credentials (the tenant and the application) of the whereabouts and the who sends the request to another VM, thereby ensuring a certain level of integrity and security of the inter-VM traffic in a non-intrusive way.

B. The agent

The frame tag in our approach has specific fields that need to

be captured and analyzed. Therefore, we thought about using a

comprehensive agent embedded in every machine of interest [9].

Those agents are the center-piece of this approach in order to

have a complete working cycle, their functionality is similar to an

intrusion detection and prevention system but lighter in terms of

analysis but they are also responsible of generating the frame

tags, depending on whether if they are receiving/analyzing or

sending/generating an IP packet/frame tag. As IP packets flow

into a VM, the agent doesn't perform a whole packet analysis, but

only targets specific fields of the IP packets and responds to the

non-compliant ones by an automated acceptance or rejection.

Every tenant in a Cloud environment has some critical

machines and resources with a restricted access. For this purpose,

the agent has a component called trust level and can take two

distinct values; high and low, and it comes to the client to define

the trust level of his machines/agents (for example a database

with sensitive data can take a high trust level), this value will

affect the behavior of the agent regarding the frame tag in terms

of the inspection and frame tag creation.

1) Rules generation: As any intrusion detection and prevention

system [3], the agent performs it analysis according to a set of

rules, but in our case the agent has a self-generated rules defining

what action should be taken regarding to the inbound IP packets.

Fig 3 illustrates the workflow of the rules creation.

Figure 3. The workflow of the rules creation.

When a tenant is created, a tenant tag is generated and

attributed via a md5 hashing mechanism and stored in the

database tag, and the same thing goes for applications when they

are installed and certified by the client. Besides the trust level

component, the agent has another component called rules engine

which is responsible for the self-generated rules based on the trust

level value. The first task of the rules engine is to fetch the tenant

tag and application tags (1), afterwards the rules engine checks the

value of the trust level in order to generate the proper rules set (2).

When the trust level value is low, the rule which will be generated

is only about analyzing the tenant tag of the frame tag (3). On the

other hand, if the trust level value is high this means that the

generated rule is about analyzing both tenant tag and application

tag of the frame tag (3).

There are two types of agents; master and slave. When a slave

agent is freshly deployed it is assigned to a master agent for a

management purposes but the master will also plays the role of a

gateway to the database tag in order to retrieve the right

information for the slave. At the client side, the master agent plays

the role of a front-end for the tenant in order to manage his

deployed agents in terms of setting the trust level of each agent,

but also to certify the trustworthiness of the applications running

on the machines within the tenant. Assigning the slave agents to

their master agent means also having the right key pair in order to

have an encrypted and secured transaction between them,

therefore preventing rogue requests to the master or having some

VM impersonate the master.

2) The frame tag analysis: At the first run of a slave agent, it

sends a request to its assigned master agent in order to retrieve its

related tenant information. A tenant can contain several machines

and accordingly several agents. Hence, a freshly deployed slave

agent needs to recognize its neighboring agents within the same

tenant, therefore comes the role of the frame tag flag field. As

mentioned before the frame tag flag affects the agent's behavior,

when a slave agent is newly deployed it sends a request to the

master agent in order to subscribe its self and receive its tenant

tag, applications tag and also information about its neighboring

agents (IP address and trust level). After this, the master agent

sends specific frame tag with a particular flag called subscription

flag to all the slave agents within the same tenant in order to have

synchronization between the slave agents (the IP address and the

trust level of the new slave agent). The trust level of a new slave

agent is set by default to low but evidently it can be changed via

the console management on the master agent by the client if

needed. When a change of a trust level occurs, the master agent

sends a trigger to the designated slave agent in order to update its

trust level. The request holds a particular value on the frame tag

flag field called trust level update flag, so that the receiving agent

will update its trust level and triggers an update of its rules set

meaning a re-execution of the rules engine workflow, but also the

master will resend a subscription flag to the other neighboring

agents of the designated agent for a resynchronization. As for the

rule update flag is triggered when the client at the console

management in the master agent adds an application as a trusted

one, the master agent updates its database and sends a frame with

a rule update flag to all the agents within the same tenant in order

to add the new application in their rules set and create a rule for it.

Figure 4. The workflow of the packet inspection.

When an inbound traffic comes towards a machine, the agent captures the IP packet then checks the source IP address if it is an external or an inter-VM incoming traffic in order to be processed. In case of an inter-VM traffic, Fig 4 depicts the workflow of the IP packet inspection, (1) the agent will capture the IP packet and targets the first payload's bytes whom are the frame tag trying to know its flag value, (2) if the field's value is either update (rules or trust level) or subscription the agent knows that the IP packet is coming from the master, otherwise the other flag value left is data, meaning that the frame tag of the IP packet has to pass to a packet inspection (3) in order to decode and analyze the content of the next two fields of the frame tag against the self-generated rules. When the trust level of an agent is low, its rules set will only be about inspecting the value of the tenant tag, the agent will

respond by an automated blocking (4) if the incoming value of the tenant tag is not compliant. As for a high trust level, the agent will have to inspect according to its rules set the tenant tag and also the application tag and responds automatically (4).

The implementation of distributed agents comes to relieve the hypervisor from a bottleneck filtering ..., hence an improved resource management, and also not to affect the scalability and the performance factors directly, since that the agents are embedded in the virtual machines, and it comes to the Cloud manager to provision VMs on the fly with the needed resources. The role of the agents is to elevate the level of security in a Cloud environment adding another layer of authentication via the frame tags (generating and analyzing them). Therefore, the integrity of those agent is primal, hence implementation wise, they are executed in Ring 0 domain so that no agent would be under the control of a particular VM's user and also in order to avoid any kind of impersonation. The proposed system can be considered as a light-weight stack-based intrusion detection system, where the packets are examined as they go through the TCP/IP stack and, therefore, it is not necessary for them to work with the network interface in promiscuous mode. This fact makes its implementation to be dependent on the Operating System that is being used, but also could be combined with other detection methodologies (signature-based, behavior-based, stateful-based...) but of course as a third party.

IV. OUR APPROACH IN A WORKING ENVIRONMENT

Relating to the model depicted in Fig 1 that we are basing our work on, and after laying out the components of our approach, this section will be about presenting scenarios on how the traffic is seen by the agents and how it is handled.

Most of the Cloud service providers have OS images and templates ready to use, according to our approach the agents need to be already embedded in order to have a working scenario. When a client chooses an image or a template to run, the agent is in a start-up mode meaning that it has to do specific tasks in order to be up and running. At its first run, the agent knows only four things, its IP address, the IP address of its master agent, its trust level which is set to low and a default rule to accept incoming frame tags from its master. Thereby, the first thing that the agent does (Fig 1 ,1) is sending a request to its master agent in order to subscribe its self as a new slave agent in order to receive its tenant tag, the applications tags within the tenant, but also the IP addresses of its neighboring agents with their trust levels. Then, the new slave agent will start self-generating its rules set and change to listen mode. After this phase, comes the subscription phase alongside the neighboring agents of the new slave agent, this task is done by the master agent by sending a frame tag with a subscription flag having as data the IP address of the new slave agent and its trust level. The receiving agents will have to begin at first, the analysis process by making sure that the incoming traffic is either from the master agent or another VM/agent within the same tenant (since that any slave agent knows its master and neighboring agents) in order to begin the packet inspection process by capturing the IP Packet and going directly to the first bits of the payload to check the frame tag flag in order to know the nature of the request, which is for subscription purposes in this case.

As aforementioned, the trust level at the first run of a slave agent is set by default to low, but when a change of this value

occurs (Fig 1, 2) on the console management, the master agent sends a trust level update flag to the designated agent in order to change its trust level and accordingly its whole rules set, but also a subscription frame tag flag with the IP address and the new trust level of the selected slave agent to all its neighboring agents in order to update trust level value.

The same thing happens when an application is added as a trusted one within the tenant (Fig 1, 3); the master agent sends rules update flag to all the slave agents in order to update their rules set by generating a rule for this application according to their trust level.

For a daily usage in a Cloud environment, a user can for example consult an application called App1 in tenant 2 (Fig 1, A), the incoming traffic from the user is considered an external traffic therefor the agent will not process it, but when the user tries for example to sign in by entering his login and password, evidently the App 1 will send a request to a database DB 1 in order to check the credentials.

Figure 5. IP packet capture with a generated frame tag.

When the application tries to send this request/IP packet, the agent will try at first to check the destination IP address. If it is an external address, the agent will not generate the frame tag, otherwise if it is an IP address of a known neighboring agent, then the sending agent will check the trust level of the receiving agent and sign the IP packet as depicted in Fig 5 [5], with a frame tag carrying the right credentials whom are the tenant tag of the tenant 2 which is a mandatory field, the application tag of App 1 (App 1 is a trusted application in tenant 2) but only if the receiving agent has a high trust level, and of course the data flag. The agent of the machine who is hosting DB 1 will begin the analysis process by checking the source of the incoming IP packet if it is its master or a neighboring agent which is the case in this example, hence begins the packet inspection by going to the first bits of the frame tag/payload and check its flag, in this case it is a data flag, thereby the inspection will run what is left of the frame tag against its rules set and check its compliance in order to accept or reject the incoming IP packet.

V. CONCLUSION

Cloud Computing comes with many advantages, but security issues always comes along since there will be always malicious users over the Internet [13]. In this paper, the focus of our work is about the visibility of the inter-VM traffic in a Cloud environment. Hence, we propose a new approach that gives an

identity to this particular traffic, this identity is about the where and the who sends the request. Our approach relies on proposing a frame called frame tag that holds the proper credentials whom are the tenant and the application that sends the IP packet, providing data origin authentication, and integrity, but also proposing an agent which is able to generate, capture and analyze this particular frame and respond to it by an automated acceptance or rejection.

The agent is the center-piece of our ongoing work. Therefore in our future work, we are trying to incorporate the autonomic computing characteristics on the agent's functionality, in order to have not only a self-generating rule engine but also a self-optimized agent and have an analysis at wire speed to meet security and performance since that those are the two key elements for a good Cloud service, and also study the integration of Deep Packet Inspection and Deep Content Inspection [4] to see which one is the best fit for an efficient inter-VM traffic inspection, but more importantly in order to keep the system informant is to log every suspicious move in a centralized server for a correlation purposes or even for a Security Information Event Management.

REFERENCES

[1] I. Foster, Yong Zhao, I. Raicu, and S. Lu, "Cloud Computing and Grid Computing 360-Degree Compared," in Grid Computing Environments Workshop, Austin, Texas, 2008, pp. 1 – 10.

[2] F. Liu, W. Guo, Z. Q. Zhao, and W. Chou, "SaaS Integration for Software Cloud," in IEEE 3rd International Conference on Cloud Computing, Miami, FL, 2010, p. 402.

[3] Scarfone, Karen; Mell, Peter. "Guide to Intrusion Detection and Prevention Systems (IDPS)".Computer Security Resource Center (National Institute of Standards and Technology), 2007

[4] Deep Content Inspection vs. Deep Packet Inspection",Wedge Networks Inc., August 2, 2011. http://www.wedgenetworks.com/resources/technology/deep-content-inspection-with-wedgeos.html

[5] RFC 791, Internet Protocol

[6] A. Schulter et al., ―Intrusion Detection for Computational Grids,‖ Proc. 2nd Int’l Conf. New Technologies, Mobility, and Security, IEEE Press, 2008

[7] Kleber, schulter, ―Intrusion Detection for Grid and Cloud Computing‖, IEEE Journal: IT Professional, 19 July 2010.

[8] Claudio Mazzariello, Roberto Bifulco and Roberto Canonico, ―Integrating a Network IDS into an Open Source Cloud Computing Environment‖, IEEE sixth international conference on Information Assurance and Security, 2010.

[9] E.H, Spafford and D. Zamboni, ―Intrusion Detection Using Autonomous Agent,‖ Computer Networks, vol.34, issue 4, 2000

[10] Irfan Gul, M. Hussain , ―Distributed Cloud Intrusion Detection Model ‖, International Journal of Advanced Science and Technology , Vol. 34, September, 2011

[11] 3 Ways to Secure Your Virtualized Data Center, Jull 29, 2010, http://www.serverwatch.com/trends/article.php/3895846/3-Ways-to-Secure-Your-Virtualized-Data-Center.htm

[12] A comprehensive framework for securing virtualized data centers, HP, Aug 2010

[13] Michael Hogan , Fang Liu , Annie Sokol , Jin Tong. ―Cloud Computing Standards Roadmap ‖, Computer Security Resource Center (National Institute of Standards and Technology), 2011