From our research into the field of Cloud Virtual Networks, we decided to use penetration testing in testbed cloud network systems to test Isolation mechanisms. We wanted to discover any design flaws or mis-configurations that would compromise both the network isolation and multi-tenancy. A goal was to leak information about cloud network infrastructure and collect evidence about the tenant VN components and configurations. The desired output was a map of the infrastructure and a listing of other tenant resources to demonstrate security weaknesses in Cloud Virtual Network Isolation.
Consequently a methodology was chosen to allow a process of investigation via multiple tools to detect vulnerabilities in Data Leakage in cloud virtual networks and their setup. Given that Data Leakage was noted by several authors and can occur at different points in a network path, it was decided to determine what was visible or leaked internally (Internal Pentest) and externally (External Pentest) using the common tools a hacker or penetration tester would use within the
Kali package.
We used the tools and techniques outlined in this chapter to focus on information leakage from virtual networks, that is, we tested for Virtual Network Isolation. Isolation was described by multiple authors as a major research area and this work is one of the first to perform experimental analysis.
Chapter 3 outlines the first testbed built and tested, the Open Stack test cloud, to determine if our research into Data Leakage information gathering from penetration testing tools was valid.
3
CHAPTER
THREE
OPENSTACK
TESTBED
AND
INFRASTRUCTURE
DEEP
DIVE
Before building the cloud testbeds we revisit the objectives as laid out in §1.6 on page 11. The first research objective, discovering the research cloud platforms has been answered and Chapters 3 and 4 will cover the work on OpenStack and CloudStack. The next two research objectives were:
Q2:What are the required resources to evaluate CVNI?
Q3:what is the best methodology to identify the construction of the cloud network infrastructure, VN components and Isolation mechanism?
This chapter provides a detailed discussion of setting up an OpenStack - Advanced Network- Testbed to answer Q2. To answer Q3, this is followed by exposing the OpenStack Cloud Network Infrastructure through the Deep Dive Methodology. Finally, we listed the components of the Cloud tenants Virtual Network to be targeted via Penetration test in Chapter 5.
3.1
Overview
One of the reasons for the popularity of OpenStack is its simplicity to create, manage and facilitate the tenant requirements with Virtual Machines (VMs), routers, subnets, Firewalls, VPN, etc through a series of GUI options. A Software Defined Network (SDN) is fully supported by Neutron and its special feature is to add plugins from a large range of SDN vendors and
technology. Hence, communication can pass through all components created by Neutron such as "routers, basic/advanced networks and security services"[138] [139].
The comparison in Sefraoui et al.[48] encouraged cloud provider administrators and researchers to deploy OpenStack especially if the intention was to use existing resources or to use the stack system for experimentation. Therefore we used OpenStack as our Testbed because of its community usage.
A cloud Tenant may represent “a customer, account, organization or project” based on the service intended to be provided [85]. Cloud tenant’s 1 “purchase” cloud resources such as compute, storage and network from cloud providers [18]. Tenants then utilize the rented cloud resources to launch VMs configured to provide services to their “clients”[17].
Despite the relative ease of creating VN components, it is important to first plan what tenants need to create and for what purpose. Neutron, the networking module responsible for network coordination, provides for a straightforward setup, build and management through the Horizon Dashboard, by supporting L3 virtual network abilities and logically defining the tenants virtual network [138]. Figures 3.1 and 3.2 show how the research Testbed scenarios for the virtual networks were planned for each tenant.
Despite the relative ease of creating VN components, it is recommended to first define what tenants need to create and for what purpose. Neutron provides straightforward setup, build, and management by OpenStack Dashboard (Horizon).
There are two tenants, Test with two VMs and Tenant1 with two users, each with two VMs. Figure 3.1 shows the Test Tenant scenario plan in the OpenStack Cloud Testbed. Test is a tenant, which has two VMs (my_first_instance and KaliLight) communicating through a network, Network1. The VMs in the network request and receive their IPs from the DHCP server and an outward facing gateway/ router (Router1) at 10.190.0.1.
Figure 3.2 represents the Tenant1 scenario plan in the OpenStack Testbed. Tenant1 consists of two users; User1 and User2. Each user created their own VNs (T1user1net for User1 and T1user2net for User2) and routers (T1u1R for User1 and T1u2R for User2). In addition, each user creates one VM (T1u1Vm for user1 and T1u2VM for User2) where the VMs are connected to the Internet through their network router.
The concept of the scenarios shown in Figures 3.1 and 3.2 are similar to the one described by 1Cloud Tenants, customers and users are alternative names used by documentation and published resources. Tenants are the most common used name by published resources, as we will use in this thesis. OpenStack documentation uses similar terminologies differently and such terminologies will be defined later in tenants and users section of this chapter.
10.190.0.6 10.190.0.7 Router1 10.190.0.1 Network1 DHCP Server 10.190.0.5 External Network/ Internet KaliLight my_first_ instance
Test Tenant Network Logical Topology Test Tenant
Figure 3.1:Infrastructure Plan of the Test Tenant.
Kashin [140] and are designed to:
• Create Virtual Networks (VN): use isolated networks for tenants and users and discover how these networks function within the cloud.
• Launch VMs: connect the VMs to the created network and observe how the communication operates within the cloud and the exit path.
• Request DHCP and Router services: router and DHCP services are controlled by the OpenStack Neutron. Our interest is to find out the role of these services and how they respond to tenant requests and communications.
Both scenarios represented in Figures 3.1 and 3.2 were implemented in the OpenStack cloud Testbed. The Testbed was implemented based on a multi-node architecture with OpenStack Networking (Neutron) using the OpenStack installation guide for Ubuntu 14.04 Mitaka[141] [142]. The Testbed shown in Figure 3.3 consists of two nodes; the Controller Node and the Compute Node. The internal infrastructure of the two Nodes is the focal point in this research as all the VN Isolation components and methods are implemented in both nodes. This will be explained in the following sections.
192.168.10.3 192.168.20.3 T1u1R 192.168.10.1 t1user1net DHCP Server 192.168.10.2 External Network/ Internet T1u2VM T1u1VM
Tenant1 and its two users Network Logical Toplogy T1u2R 192.168.20.1 t1user2net DHCP Server 192.168.20.2 User1 User2 Tenant1
Figure 3.2:Infrastructure Plan of Tenant1 and Its Users.
Figure 3.3 represents the experimental Testbedused to implement the two scenarios. OpenStack was used as the cloud environment with Neutron to provide the VN implementation of Network as a Service. At this point there is no indication of how the cloud system will allocate and configure the provisioned resources of tenants and therefore how Figures 3.1 and 3.2 map into Figure 3.3.