National College of Ireland

Project Submission Sheet – 2014/2015

School of Computing

Student Names: Karan Chhabra and Rajat Dikshit

Student ID: Karan Chhabra (14111322) and Rajat Dikshit (14119200)

Programme: MSc. Cloud Computing Year: 2014-2015

Module: Cloud Security

Lecturer: Mikhail Timofeev

Submission Due Date:

14/12/2014

Project Title: Implementation of security in hybrid cloud

Word Count: 2197

We hereby certify that the information contained in this (my submission) is information pertaining to research we conducted for this project. All information other than our own contribution will be fully referenced and listed in the relevant bibliography section at the rear of the project.

Signature: Karan Chhabra and Rajat Dikshit

Date: 14/12/2014

Office Use OnlySignature:Date:Penalty Applied (if applicable):

IMPLEMENTATION OF SECURITY IN HYBRID CLOUD

TEAM MEMBERS:

RAJAT DIKSHIT (14119200)

KARAN CHHABRA (14111322)

AREAS COVERED:

1. OBJECTIVE2. PROJECT PLAN3. SELECTION OF TOOLS/METHODOLOGIES/FRAMEWORKS4. AUTHENTICATION PROCESS5. SELECTION OF TOOLS AND TECHNICAL TESTS WITH RESULTS6. STEPS TAKEN TO STOP ATTACK THROUGH PORT

BLOCKING 7. CHALLENGES AND LIMITATIONS 8. CONCLUSION 9. BIBLIOGRAPHY

Objective:

The major objective of this project is to secure the whole hybrid cloud paradigm consisting of private cloud (Openstack) and public cloud (Windows Azure). The security is applied in different phases which contains the native machine where the private cloud is implemented and the network which is used for the communication amongst the private cloud (Openstack) and public cloud (Windows Azure). The public cloud environment is not included as that domain is owned by the governing organization and the implementation of security by a third party liaison is not permitted.

Project Plan:

PHASE 1 (Private Cloud) PHASE 2 (network)

Here, Openstack will be secured by implementing various strategies from authorization techniques to management of data. Since Openstack is an open source cloud environment, there will be no consideration of malwares embedded in the native cloud environment as they are not specifically manufactured for open source software and services. All the work is carried out in a controller node which is a single node after the implementation of the private cloud (Openstack) and the compute services along with the network configuration is carried out in the same node.

Implementation of security can be shown according to the following diagram:

Selection of Tools/Methodologies/Frameworks/Benchmarking:

In a Hybrid cloud environment, the areas which are vulnerable to attacks are tabulated underneath:

Operating System used for the native cloud operation Authentication portal Network Virtual Machines

1. OPERATING SYSTEM: The operating system used for the installation of the native environment as for the execution of private cloud is the latest release of mac OS X. Since this is a Linux based operating system, the base users and the NICs are presumably very secure. However, the private cloud environment is setup in a virtual environment using VMWARE where the OS used to interface the installation of Openstack is Ubuntu 14.04 Trusty Tahr Server Edition. Since Ubuntu is a core Linux based operating system and is also an open source environment, there is no need of any anti-virus/anti-malware software or tools as discussed earlier these kind of threats are not manufactured to work on open-source environments.

Although to secure the operating system from within the user-space, various steps are taken so that the current user-space remains isolated. These steps are discussed below:

Firewall is enabled by the main user The privileges of the root user have been abstracted. Therefore access to root user

is only allowed after the password is entered under Super User (SU).

2. AUTHENTICATION PORTAL: Since the private cloud platform used is Openstack, there are certain rules that are already set in the authorization service called KEYSTONE. Keystone works inside the nova API in Openstack and every query for authentication of user/Admin (for this project) goes to the keystone first and gets validated. The rules on which this the administrator predetermines works so any attempt of key-logging is restricted. Whereas, the public cloud side which is Windows Azure for this project is secured by a management key which is embedded in the Azure session directories and can only be accessed by users who have subscribed into Azure to be recognized by that session. This management key is inscribed into an azure understandable file known as <subscription_name.PublishSettings> file. This file is imported into Openstack to make the transition into Azure secure.

3. NETWORK: The network part of the hybrid cloud is secured by applying various constraints to it so that less and less operations can be performed on it except the ones needed in order to maintain the functionality of the environment. We close all the ports which may lead to access of any cloud systems and hence we access the virtual machines spinning on the cloud platforms via SSH/Putty so that only people with the access key get to tunnel into the instances. This kind of connection is much more secured than a passcode type authentication system.

4. VIRTUAL MACHINES: The implementation shown here is carried out on two different levels of virtualization. The first level of virtualization runs on the host operating system while the second level works on the first level and in this level all the virtual machines are spun. This kind of hierarchical approach makes it difficult to penetrate into the resources. Moreover, we have a hypervisor which is the controller machine running beneath the cloud layer on the system. The virtualization is done on the hypervisor hence only root access is allowed. In this project we have used the QEMU hypervisor running on an Ubuntu native system.

Authentication Process:

1. Authentication into Openstack: Once Openstack is successfully configured on the host machine, an access IP along with admin username and password is provided to the user. In this case the secure IP is 172.16.236.197. The Username and password are also provided and are checked upon by keystone. The secure IP returns the login page for the dashboard.

Here, when the entries are put in, the control goes back to keystone and the tenant list is checked.

2. Authentication into Azure: Azure offers the most general account ID and password system for authentication into its portal. This can only be provided to users who are subscribed to Microsoft’s cloud service. The authentication window for Azure can be seen below.

Signing into this portal, a dashboard of all the services is provided by Azure.

AUTHENTICATION FROM OPENSTACK TO AZURE IN THE HYBRID CLOUD SCENARIO

1. Associating Openstack environment with Azure credentials system: To connect Openstack and azure in a secure way, we implement the Azure API into Openstack as it is open source and easy to do so. The CLI for Azure is taken to be a cross platform one and is known as XPLAT_CLI. Since the CLI commands work on NODEJS, we go ahead and install the latest version of Node.js

After Node.js has been installed in the system, we install npm for configuration of Azure CLI.

This will create a framework for the Azure CLI to work.

The installation of Azure CLI into Openstack terminal is done by the following command.

This command installs Azure CLI globally throughout the whole console even outside of the Openstack sphere.

sudo apt-get updatesudo apt-get install nodejs

sudo apt-get install npm

npm install azure-cli -g

2. Downloading Azure credentials securely into Openstack:

After the Azure API has been completely setup in Openstack, we download and include the credentials of Windows Azure in it. The following command connects Openstack to Azure account.

When the file is done being downloaded and saved, we import it into the current session. This is achieved by the following commands.

~$ azure account downloadinfo: Executing command account downloadinfo: Launching browser to https://windows.azure.com/download/publishprofile.aspxhelp: Save the downloaded file, then execute the commandhelp: account import <file>info: account download command OK

~$ azure account import publishsettings.publishsettingsinfo: Importing publish settings file publishsettings.publishsettingsinfo: Found subscription: 3-Month Free Trialinfo: Found subscription: Pay-As-You-Goinfo: Setting default subscription to: 3-Month

Importing an account .publishsettings file automatically connects current session with Azure dashboard securely. This connection is secure because before downloading the .publishsettings file Microsoft asks for the account username and password.

It can be seen in the above screenshot that the authentication fails when the credentials files is missing.

SELECTION OF TOOLS AND TECHNICAL TESTS WITH RESULTS:

As seen in the earlier sections of the report, the public cloud is secured completely and the private cloud is secured as far as authorization is concerned. Our goal now is to find various vulnerabilities in the network. For this, we employ some security tools whose configuration and usage are given in a step-by-step fashion.

Nmap – Nmap stands for Network Mapper and is an open-source mapping tool which scans the current network on which all the user sessions are active and notifies which ports in the whole address space is open. This scan determines ports through which attackers can penetrate into cloud sessions.

Installation command for Nmap:

rajat@controller:-$ sudo apt-get install nmap

Next step is to search the whole network along with the subnet to find out the ports which are open to other hosts.

It can be observed from the above command which returns all the ports that are vulnerable to attacks by other hosts.

Nikto – It is also a scanning tool like Nmap but the difference is that Nikto scans the network attached to the servers and also the files on the servers which cater to the services of networking. This tool returns all the vulnerabilities and dangers along with outdated files on the server which may lead to attacks from the outside.

In order to save the installation package of Nikto we use the following command:

In order to extract all the files and install Nikto we use the following command:

rajat@controller:-$ nmap 172.16.236.0/24

rajat@controller:-$ wget http://www.cirt.net/nikto/nikto-2.1.5.tar.gz

rajat@controller:-$ tar -xvzf nikto-2.1.5.tar.gz

The following command is used bring out all the vulnerabilities related to connection of servers.

The following snapshot we can see that open source vulnerability database ID is

OSVDB-27071 is prune to XSS. This is due to PHP image view 1.0 is allowing remote attacker to execute script. To resolve this vulnerability we have to upgrade PHP image view to 2.0 or above version which has fixed this vulnerability.

rajat@controller:~/ nikto2$ ./nikto.pl -host 172.16.236.197

Nessus – Nessus is a network scanner tool which not only enlists all the shortcomings of the network but also searches for vulnerabilities in a federated cloud system.

STEPS TAKEN TO REDUCE ATTACK THROUGH PORT BLOCKING:

This section deals with securing network channel by blocking unnecessary ports. The main idea behind this approach is to use the concept of IPtables in Linux environment. IPtables is a service which reads, displays, modifies and saves the status of different ports and IP networks to or from a host network.

The status of network ports can be seen through IPtables by the following command.

rajat@controller:-$ sudo iptables –L

After scrutinizing all the ports, we go ahead and block the ports which are not required by the user. The ports mainly taken into consideration are:

SSH -22 HTTP – 80 Iscsi – 3260 MySQL – 3306 HTTP-alt – 8000

We can block all the unwanted ports by applying reject rules to them in IPtables. The commands for achieving this are underlined as follows:

iptables -A INPUT -p tcp --dport ssh -j DROP iptables -A INPUT -p tcp --dport HTTP -j DROP iptables -A INPUT -p tcp --dport iscsi -j DROP iptables -A INPUT -p tcp --dport MySQL -j DROP iptables -A INPUT -p tcp --dport ssh -s 10.10.10.10 -j DROP

CHALLENGES AND LIMITATIONS:

The major challenge of this implementation is the management of IP addresses to and from which connections are supposed to be made by the host virtual machine. Though we were able to virtualize the private cloud environment, any access through the application layer run on these environments is not mentioned and very difficult to test. Also according to the Nikto test we found out that the apache server was prone to cross site attacks. These can be avoid by generating tokens for every session but since the Private cloud is implemented inside a domain therefore token generation is not possible.When we move to the public cloud environment, there is no mode of modification available to the users in the area of security and hence the security part is untouchable. According to Microsoft, any modification if necessary will be carried out by the organization. All will be acted upon the feedback and bug reports sent by the user to the company.Further, the security implementation for the network is carried out only for local machines and the impact of vulnerabilities is unknown in an open world environment. Also the network for hybrid cloud has been embedded inside that of Private cloud and the connection is done through external network. This is a limitation that can be overcome by using a VPN connection between the two clouds. This kind of connection was not possible in our project as we did not have any access to the DNS servers provided to us.

CONCLUSION:

This project thus demonstrates the importance of security and threat management in a federated hybrid cloud system. Since a Hybrid cloud model involves two discreet cloud environments remotely placed, hence, there arises a need to secure both the clouds and the corresponding channel of network between them. There is a huge scope of development in this field and with every step of development, the need to secure public data will also increase. Travelling of data from a private to public environment is a very crucial and sensitive area for cloud administrators and the implementation of security a must for them.

BIBLIOGRAPHY:

CIRT.net 2014. “Nikto”. Available from: https://cirt.net/Nikto2/ [Accessed December 2014]

Microsoft. 2014. “Create a Virtual Machine Running Linux”. Available from: http://azure.microsoft.com/enus/documentation/articles/virtual-machines-linux-tutorial/ [Accessed November 2014].

Microsoft. 2014. “Install and configure the Azure Cross-Platform Command-Line Interface”. Available from: http://azure.microsoft.com/en-us/documentation/articles/xplat-cli/ [Accessed December 2014]

NMAP.ORG 2014. “Nmap”. Available from: http://nmap.org/ [Accessed December]

Openstack.2014. “Openstack git repository browser” .Available from: https://git.openstack.org/cgit [Accessed December 2014]

Tenable network security. “Nessus”. Available from: https://www.tenable.com/products/nessus [Accessed December 2014]