3.5.1
OpenStack Testbed Construction
The following points indicate some of the major technical obstacles of building an OpenStack TestBed:
1. It took six trials to build a single-node Demo cloud between Hyper-v and VirtualBox environment for the cloud Nodes. Different Ubuntu versions were examined (Ubuntu 12.02 and 14.04) and different cloud repositories tried (icehouse and Juno), but the cloud builds repeatedly failed.
a) The Demo Cloud failed to install with DevStack, which was not flexible enough to support our planned testbed. The successful demo single-node was built with VirtualBox, Ubuntu Server 14.0 and devstack /OpenStack-Juno. However, the physical infrastructure server (Gorman) was supported with a Hyper-v virtualization environment. This Demo cloud was a good base reference for the intended testbed.
2. The planned testbed was a multi-node (3 node) OpenStack cloud, which was not successful with DevStack and hence the cloud was built manually using OpenStack Installation Guide for Ubuntu 14.04 – Kilo[147] with GRE. Trial 7 was the first successful multi-node OpenStack Cloud.
a) The cloud operation was healthy except that the External Network connection failed and Instances were not connecting with outside the cloud Nodes boundaries.
b) After a long period and countless trials of solutions to resolve the cloud external network issue, we found that Hyper-v External vSwitch connecting the instance to the outside was incompatible with the external OVS switch in the Network Node and the connection was blocked in between. The Hyper-V switch connectivity issue solution was unsolvable, even with expert help.
c) As a solution we decided to change the virtualization environment to VBox as was the original Cloud Demo. However, at that time OpenStack-Mitaka was released and the installation guide set the cloud structure to be built on two nodes rather than three nodes.
i. A 2-node OpenStack-Mitaka cloud on Hyper-V (trial 8) had the same external network connection issue. Hence the Hyper-V virtual environment was disabled and replaced with a VBox in the Gorman Server.
ii. OpenStack–Mitaka (2-Node) cloud with VXLAN was successfully deployed and the External Network connection was successful (trial 9).
iii. Tenant scenarios, the DeepDive methodology and the Penetration Testing method- ology were all repeated from the 3-nodes OpenStack-Kilo Cloud testbed to a 2-node OpenStack-Mitaka cloud testbed.
3.5.2
OpenStack DeepDive Application
The following are the technical obstacles of the DeepDive method:
1. Although the Demo single-node OpenStack cloud was built on one server, the planning of the DeepDive took longer than expected to study the infrastructure as the documentation
was not as clear and available as we had expected. We found the proper commands and identifying the cloud’s significant information was not easy.
2. Moreover, due to our initial limited knowledge in cloud systems, their infrastructure and associated information, coming up with the best way to analyse the collected information manually in the first attempt took significantly longer than expected.
3. A redesign of the DeepDive method to move from a single node cloud to a 3-node cloud was necessary as the infrastructure differed in both clouds, the amount of collected data was even larger and the manual data analysis took longer than for demo cloud.
4. Upon changing the OpenStack Cloud from a 3-node Kilo to a 2-node Mitaka, the cloud infrastructure changed and the DeepDive method had to be adjusted.
5. Chapter 4 contains the last DeepDive method procedure, however, the manual data analysis is still appropriate but the time spent remained significantly long.
3.6
Conclusions
This Chapter started by achieving the second research objective of discovering the required resources to evaluate Cloud Virtual Network Isolation by building the OpenStack testbed. This was followed by achieving the third research objective of discovering the best methodology to acquire infrastructure information and resulted in a contribution of developing the DeepDive methodology. The DeepDive was applied on the testbeds to reveal the components and configuration of the cloud network infrastructure.
Due to the nature of this exploratory research, we only managed to ground the hypothesis after achieving the third objective as it clarified for us what to be tested.
The final outcome of this chapter is a complete OpenStack Network infrastructure diagram (Figure 3.7 on page 87) showing the tenant elements and components such as VMs, Networks, Routers and DHCP servers. The diagram clarifies and identifies the isolation mechanisms after the process of gathering information, analysis and visualisation. The VN isolation mechanisms used by this cloud testbed setup were:
1. VLAN: locally defined by Openflow within the OVS switches to isolate a tenant’s traffic. Each network is assigned to a specific VLAN. Note that Neutron dashboard is not aware of these isolation mechanisms as it is handled directly by OpenFlow controllers.
2. VXLAN: The tenant network type is defined by Neutron. Each VXLAN tunnel is created between two cloud nodes where all the tenants share the VXLAN tunnel and traffic isolated by the VXLAN code is tagged in the tenant traffic packets header. Therefore tagging is used as an isolation mechanism.
3. Namespaces: A Linux isolated container containing the tenant’s network configurations. Our Testbed setup shows two types of namespaces. DHCP namespace, which represents a DHCP server created by Neutron when a tenant creates a network. Router namespace, which represents the local router created by the tenant. This links the inner side of the cloud (tenant private network) with the outside (External network) world to provide the instances external connection. Therefore namespaces are used to isolate tenant network configurations. The DeepDive was the most involved experiment performed in this research. The aim of the experiment was to discover whether the identities of the tenant and user connections in a commercially used open-source system could be derived. Theoretically router and bridge identifications should not be accessible by users. However this DeepDive experiment has demonstrated that with the use of multiple commands throughout the cloud architecture, any user can find private information, which can compromise tenants and users. This experiment provides a methodology for cloud network isolation analysis.
DeepDive did not only provide a graphical representation of the cloud infrastructure but it identified the cloud network infrastructure, VN components and configurations. This information was used as our cloud infrastructure and isolation knowledge guide.
The work described above is followed by experiments discussed in Chapter 5 and 6, wherein a publicly available penetration testing tool is placed inside a Cloud tenant and outwith a cloud to simulate attackers both internally and externally.
These experiments were aimed at determining if an attacker can duplicate the extensive Deep Dive, that is, finding Cloud Virtual Network Isolation information or tenant information from different connection vectors. In other words, the experiments demonstrate whether Virtual Network Isolation mechanisms can be learned by other tenants or external users users as stated in the Research Aim of detecting cloud virtual network isolation information.
4
CHAPTER
FOUR
CLOUDSTACK
IAAS
TESTBED AND
INFRASTRUCTURE
DEEPDIVE
This chapter follows a similar structure to that of Chapter 3 as it aims to answer two of the research questions which are;
What are the required resources to evaluate CVNI? and
What is the best methodology to identify the construction of the cloud network infrastructure, VN components and Isolation mechanism?
To answer the first of these research questions, this chapter illustrates extensively the process of setting up the CloudStack - Advance Network- Testbed, followed by the process of exposing the CloudStack Cloud Network Infrastructure. This is done through the DeepDive Methodology, which answered the second of these research questions. Finally, we listed the components of the Cloud tenants Virtual Network to be targeted via the following Penetration test as described in Chapter 5.