The DeepDive Obstacles

The following are the technical obstacles that were faced during the CloudStack DeepDive : 1. Management server console:

a) Network Provider OVS was disabled:

i. During the DeepDive , information collection issues on VXLAN were encountered. Despite the cloud running correctly with virtual interfaces added normally to OVS

bridges, we found that the OVS Network Service Provider was disabled. However, there was no sign of VLAN tags or VXLANs in the OVS bridges.

ii. According to [163], theKVM OvS VifDriver does not support VXLAN and a solution was to drop the use of OVS and replace it with Linux bridges, and then configure the KVN with BridgeVifDriver.

iii. As our major aim was to create the CloudStack Testbed as close as possible to the OpenStack Testbed, we decided to solve this issue by keeping the OVS configuration and, alternatively, to change the isolation type from VXLAN to GRE as shown in the example[164].

iv. Another implication was that re-configuring the physical network was not possible unless we deleted the entire Zone and re-created it, and that required us to re-create the tenants and their scenarios.

v. Once the OVS network provider is enabled in CloudStack and the tenant VNs re-created, the interfaces were added to the OVS bridges along with their assigned VLAN specifically in Cloudbr1 bridge as is shown in Table 4.10.

2. Management host: Scripts provided very limited information. Due to the fact that none of the cloud network infrastructure was included in the Management Node, we had to cut down the commands running in the designated scripts.

3. KVM Host: Instance XML files were nowhere to be found in the KVM Host. Unlike OpenStack, which uses the default Libvirt path to store the VM configuration parameters XML file, we had to modify the script files for collecting the content of XML files from the source path and used the commands virsh list –all, Virsh dumpxml <VMName> > vmname.xml[165] to get the instance XML file contents.

4. The DeepDive analysis was similar to the OpenStack analysis. However, due to the infrastructure differences between OpenStack and CloudStack, the manual analysis had to be adjusted to fit the CloudStack information collected.

4.6

Conclusions

This chapter achieved two research objectives by firstly defining the research required resources through outlining the CloudStack setup. The identification of the construction of the cloud

network infrastructure, VN components and Isolation mechanism was performed via the DeepDive methodology on the CloudStack Testbed.

A fully operating CloudStack testbed, functioning similar to the OpenStack testbed, was analysed and multiple tables of data were generated to allow a map of the cloud infrastructure to be created. From this, the outcome was a complete CloudStack Network Infrastructure diagram, which showed virtual network isolation mechanisms (e.g. VLAN) and network components (e.g. vRouters, OVS bridges). Further, connections within the cloud are typed and labelled as shown CloudStack Network Infrastructure DeepDive diagram in Figure 4.7 on page 125.

Comparably, the CloudStack Testbed Infrastructure DeepDive representation is less dense than that with OpenStack diagram represented in Chapter 3. The difference in technology resulted in different Cloud infrastructures, although matching technology options and scenarios were used. As an outcome, the third research objective, the identification of a Cloud Network Infrastructure methodology, provided a cloud infrastructure and isolation knowledge guide for OpenStack (Chapter 3) and CloudStack (Chapter 4) to be used in the remaining research objectives. Consequently, the next chapter focuses on penetration tests on the two experimental testbed clouds to discover if an attacker can determine cloud virtual network isolation information as discovered by DeepDive methodology.

5

CHAPTER

FIVE

PENETRATION

TESTING

FOR

DATA

LEAKAGE

Following on from the setup of the two testbeds and the mapping of their network infrastructures in Chapters 3 and 4, this chapter outlines the security tests for detecting any Cloud Network infrastructure components using Penetration Testing. The fourth research objective, stated in Chapter 1 (§1.6), concerned detecting and determining the characteristics of the leaked data, and this is achieved and described in this chapter. The aim was to collect leaked information from running bi-directional Penetration Tests (Internally and Externally) on the two testbeds and to then analyse this information. If components and configuration details of the tenant VNs within the Cloud Network infrastructure could be determined, then Virtual Network Isolation is weak and insecure.

5.1

Penetration testing and tools

The research problems in §1.6 stated that although VN Isolation is a core element of cloud security, the literature shows that very little experimental work has been conducted to test, discover and evaluate any VN isolation data leakage.

We recall our Null hypothesis that the security of the IaaS Cloud Virtual Network Isolation is robust against Data Leakage caused by current penetration tools. This chapter empirically tests this hypothesis.

As stated in the Problem Statement of §1.6, the aim of this research is to detect or evaluate information leakage from cloud virtually isolated networks. Therefore, questions arise as to how

data leakage can be determined and what the characteristics can be leaked, such as IP addresses, OS type, VM types, open ports etc?

Chapters 3 and 4 answered two of the research objectives questions; 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? The first question was answered by selecting OpenStack and CloudStack as our base testbeds for this study. The second question was answered when the DeepDive Methodology was developed to identify the construction of the cloud network infrastructure, VN components and Isolation mechanisms.

Cloud VN Info.  (2) Identify Vulnerabilities 

Input Process _OutcomesOutput/

Tenant1

Tenant2

TenantN

(1) Penetration Testing Tools: to test the Cloud VN vulnerabilities

for possible info. leakage 

(3) Type of Data Leaked.  (4) Suggest possible

prevention/Mitigation 

Figure 5.1:Research Map

We mapped the research as shown in Figure 5.1 to show the flow of the empirical work performed to answer the research questions. The research was divided into three main stages as follows: 1. Stage one, Setup:

• Build the Advanced VN Cloud Testbeds with multi-tenancy scenarios.

• Select one tenant to be a rogue tenant and use the initial information to perform bi- directional penetration testing attacks (External and Internal)

2. Stage two, Penetration Testing:

• The rogue tenant launches the currently available penetration tools - the Kali Tool kits- to test the Cloud VN Vulnerabilities for possible information leakage.

• Vulnerabilities are identified and their relevance to VN, the impact on identifying the co-existing VN of the other tenants or the breaking the VN Isolation are determined. At this stage the decision was made to accept or reject the null hypothesis.

3. Stage three, Outcome:

• An outcome is to find and categorize leaked data them as well as detect or determine their source and cause.

• Finally, and based on the results above, we suggest possible prevention or mitigation guidelines.

This chapter outlines Stage 2 in the above list and introduces our Penetration Testing procedures. A Penetration Testing methodology is described as “a roadmap with practical ideas and proven practices that can be followed to assess the true security posture of a network, application, system, or any combination thereof “[125].