National College of Ireland

Project Submission Sheet – 2013/2014

School of Computing

Student Name: GAURAV LAKHANI and JITENDRA KUMAR SHARMA

………………………………………………………………………………………………………………

Student ID: X14111284 and x01315057………………………………………………………………………………………………………………

Programme: M.sc Cloud Computing………………………………………………………………

Year: 2014………………………

Module: Cloud Security ……………………………………………………………………………………………………………

Lecturer: Mikhail Timofeev………………………………………………………………………………………………………………

Submission Due Date:

14-Dec-2014………………………………………………………………………………………………………………

Project Title: CLOUD SECURITY REPORT ………………………………………………………………………………………………………………

Word Count: 2,411 WORDS………………………………………………………………………………………………………………

I hereby certify that the information contained in this (my submission) is information pertaining to research I conducted for this project. All information other than my own contribution will be fully referenced and listed in the relevant bibliography section at the rear of the project.ALL internet material must be referenced in the bibliography section. Students are encouraged to use the Harvard Referencing Standard supplied by the Library. To use other author's written or electronic work is illegal (plagiarism) and may result in disciplinary action. Students may be required to undergo a viva (oral examination) if there is suspicion about the validity of their submitted work.

Signature: GAURAV LAKHANI………………………………………………………………………………………………………………

Date: 14-DEC-2014………………………………………………………………………………………………………………

PLEASE READ THE FOLLOWING INSTRUCTIONS:

1. Please attach a completed copy of this sheet to each project (including multiple copies).

2. You must ensure that you retain a HARD COPY of ALL projects, both for your own reference and in case a project is lost or mislaid. It is not sufficient to keep a copy on computer. Please do not bind projects or place in covers unless specifically requested.

3 Assignments that are submitted to the Programme Coordinator office must be placed into the assignment box located outside the office.

Office Use Only

Signature:Date:Penalty Applied (if applicable):

Cloud Security Report (Jitendra Kumar Sharma, Gaurav Lakhani)

by Gaurav Lakhani

Cloud Security Project Report

1) Approach and Project Planning

Securing a Hybrid Cloud

The implementation of Hybrid cloud between VMware and Amazon web services includes a great deal of hardware and software resources. The VMware private cloud is made of one or more hypervisors (referred as host) on which virtual machines (referred here as guest) are created. The vCenter server is used to manage this hypervisor and a management tool called vSphere client is used to access this management server. And talking about the Amazon Web Services, it serves as the public cloud for our project. We use a Amazon's AWS connector to connect our VMware private cloud to AWS. A general layout of our infrastructure and constituent resources are as depicted below.

Strong importance has been given from the beginning for securing this infrastructure that strictly follows OWASP recommendations. In the private cloud it deals with securing at three levels- security at the hypervisor level, security at the guest OS level and security at the network level.

Task and Dependencies

This section outlines the tasks and dependencies to attain a detailed level of security in the project. Some of the details are as listed below.

Task: Identifying the constituent resources which need to be secured.Dependencies: We have to segregate our infrastructure in logical segments based on their functionality and accessibility to target audience which needs to be secured for identity and access management, network traffic, permissions, data integrity etc. Some of these have been achieved by integrating the cloud infrastructure with a domain controller.

Task: Identification and implementation of appropriate security threat model.Dependencies: As there is no one distinct threat model defined specifically for cloud security,We need to identify one that suits best as per our infrastructure and use other best practices and recommendations for cloud security.

Task: Testing the infrastructure to validate the application of security features and identify loopholes if any.Dependencies: After hardening the infrastructure, it needs to be tested to validate the implementations. This can be tested using different test cases manually or by using third party tools that can suggest robustness of our cloud environment.

2) Selection of Tools / Methodologies / Frameworks / Benchmarking

The security threat model followed is The Australian/New Zealand Standard AS/NZS 4360 along with the security best practices and recommendations from ENISA. The AS/NZS 4360 model gives the freedom to identify your own risk domains based on the structure of your infrastructure and manage them in a traditional way. It uses likelihood and consequences to determine overall risk.

The five steps of the AS/NZS 4360 process are:

1. Establish Context: Establish the risk domain, i.e., which assets/systems are important? In this step we identified and divided our risk domain in four groups that needs to be secured.

Hypervisor(Host) Virtual Machines(Guest) Network Public cloud(AWS)

2. Identify the Risks: Within the risk domain, what specific risks are apparent? - We evaluated all the risk domains listed above and identified few common risks like unauthorized access, Identity Management, Spoofing, Data Tampering and DOS.

3. Analyze the Risks: Look at the risks and determine if there are any supporting controls in place. - This step helped us to identify the contributing factors for breach and remedial controls.

4. Evaluate the Risks: Determine the residual risk. -Here we calculate the impact of the risk

5. Treat the Risks: Describe the method to treat the risks so that risks selected by the business will be mitigated. -This involves the detail of all the steps we performed to secure our hybrid cloud.

We used few of the ENISA recommendations and best practices to secure our risk domains.

The detailed steps to secure our hybrid cloud are as follows:-

2.1) Hypervisor (Host) Security

1. Enable Lock down: Once lockdown mode is enabled, the host can be accessed only through a management server vCenter server. No SSH, putty or Telnet allowed.

2. Integration with Active Directory: As lockdown mode is enabled on hypervisor, It will be accessed only through its management server vCenter server. We integrated vCenter server with our Domain controller so that no local system user can log in to it. Only authorized domain users will have access to vCenter server and the hypervisors registered in it.

3. Role based Access to Hypervisors (Hosts): Although vCenter server is integrated with Domain controller, not all users will be able to login to it. The users who will have login rights will be assigned a role and can perform task specific to that role instead of having full rights. This helps to manage the workload better among different users with a track of who is doing what. For example, domain administrator will have full rights and can manage hosts as well as VM’s though other user 'Gaurav' has virtual machine power users right and can manage VM's but not hosts.

4. ESXi Firewall: ESXi firewall gives us features to allow or restrict all the access to our host. We have enabled firewall and have allowed access to our host only from a network 192.168.0.0/24 and any attempt to connect from other network is blocked.

5. Securing the Log Files- Log files have been directed to a shared NFS store instead of local ESXi hard disk so that they can be accessed even in case of ESXi Failure.

6. Failover Cluster: ESXi hosts have been configured in a HA cluster to protect them against Failures.

2.2) Guest OS Security

Once the Hypervisor is hardened, we need to secure the Guest OS running on it. In our hybrid cloud, we have a Red hat Linux Guest OS running. We performed the below mentioned steps to secure it.

1. Security Patch: The guest OS centOS6.6 has been patched to download all the critical security updates. This has been achieved and verified by running below commands on the console-

#yum --security check-update- To check available security updates #yum --security update: To download and install available security updates

2. Grub-Crypt: The Boot loader of the guest OS has been password protected so as to restrict unauthorized access to the operating system. Also the boot loader password has been encrypted using md5 instead of using a plain text password. The command used to encrypt the password is:

#grub-md5-crypt: Enter the password to encrypt it to MD5 hash.

The Password has been encrypted and entry for same has been made in /etc/grub.conf so that the password command in boot loader configuration file knows where it has to look for the password.

#vim /etc/grub.conf password --encrypted <encrypted password>

3. Key based SSH Authentication: Key Based SSH Authentication- Every time a user wants to secure SSH connection, he needs to enter the password. This may put it in risk if the channel between the host and server is compromised and can result in leak of the password. In our infrastructure we have replaced password based SSH authentication with Key based authentication. Once SSH established, the SSH server will keep a record of the client machine and will not recognize it next time if it tries to connect.

In the screenshot below, we have shown SSH session for two users, 'jeet' and 'admin'. For user 'jeet' it asks for a password every time however for user 'admin' it does not as the SSH key for 'admin' has already been copied to the SSH server as shown in the picture above.

4. Disable root login for SSH

This is a good feature to secure SSH server as no user will be able to access it with root credential and will need to use their own user credential.

5. Enable Firewall

Run #setup to enable the Firewall which will filter out unnecessary network traffic.

6. Port blocking Using IPtable: IPtable rules has been used to block all the ports accept for SSH.

7. Password expiration policy: A 30 day password expiration policy has been set for all the users on the machine so as to enforce a compulsory password change

8. User account Lockout: Guest OS has been configured to lock the user in case of 3 failed login attempts. Administrator access would be required to unlock the account again.

To enable user lockout on failed login, below entries has been made on the guest OS file.

/etc/pam.d/system.auth

Same entry needs to be made in /etc/pam.d/password.auth.

9. Data Encryption (LUKS): The hard drive has been encrypted with LUKS (LINUX unified key setup) so as to restrict unauthorized access to the data on the hard drive

10. Advanced Intrusion Detection Environment- AIDE has been setup on the guest OS to monitor changes in the file and permission metadeta of the file.

Below given files have been set to be monitored by making entry in the file-

/etc/aide.conf

2.3) Network Security

1. VLAN id: A VLAN has been created to isolate tenants from each other. The guest OS has been placed in VLAN separated from management network which is completely isolated on a different port group.

2. Network Policy: The ESXi host has been configured to reject the promiscuous mode, MAC address change and Forged Transmits.

2.4) Public Cloud Security (AWS)

We have used Amazon web Services as our public cloud where in most of the security challenges are dealt by AWS. They provide well secured infrastructure by extensive network and security monitoring system. Some of the security features provided by AWS are as mentioned below:

These systems provide basic but important security measures such as distributed denial of service (DDos) protection and password brute-force detection on AWS Accounts. Additional security measures include:

Secure access – Customer access points, also called API endpoints, allow secure HTTP access (HTTPS) so that you can establish secure communication sessions with your AWS services using SSL/TLS.

Built-in firewalls – You can control how accessible your instances are by configuring built-in firewall rules – from totally public to completely private, or somewhere in between. And when your instances reside within a Virtual Private Cloud (VPC) subnet, you can control egress as well as ingress.

Unique users – The AWS Identity and Access Management (IAM) tool allows you to control the level of access your own users have to your AWS infrastructure services. With AWS IAM, each user can have unique security credentials, eliminating the need for shared passwords or keys and allowing the security best practices of role separation and least privilege.

Multi-factor authentication (MFA) – AWS provides built-in support for multi-factor authentication (MFA) for use with your root AWS Account as well as individual IAM user accounts under it.

Private Subnets – The AWS Virtual Private Cloud (VPC) service allows you to add another layer of network security to your instances by creating private subnets and even adding an IPsec VPN tunnel between your home network and your AWS VPC.

Encrypted data storage – Customers can have the data and objects they store in Amazon EBS, Amazon S3, Glacier, Redshift, and Oracle and SQL Server RDS encrypted automatically using Advanced Encryption Standard (AES) 256, a secure symmetric-key encryption standard using 256-bit encryption keys.

Selection of Tools

We have used few open source tools like NMAP, putty ,NIKTO,OPENVAS and NESSUS etc to run a pen test on our infrastructure to validate the security implementations and check loopholes if any.

3) Testing Approach

We carried out several manual and automated tests on our infrastructure to identify the security vulnerability ranging from finding OS version to open ports, pings and SSH to apache issues.

Some of the test scenarios are:

1. Check if ESXi can be SSHed: We used putty to establish a SSH connection on ESXi. As we have enabled lockdown mode so it should not allow SSH. Given below is the test result.

2. Check if guest OS can be SSHed with root account: We have disabled the root SSH on guest OS for better security so it should not allow root SSH. Given below is the test result.

3. Check if guest OS can be SSHed with non-root account: As we have not disabled non root SSH to guest OS, we should be able to connect. We tried to putty our centos guest operating system with user 'admin' and it connected well. Given below is the finding.

4. Check the open ports on ESXi: We used open source tool nmap to scan our ESXi server to find the open ports. It found that only those ports are open which are required for communication with the management server and client are open and rest are blocked. Here is the result of nmap scan.

#nmap 192.168.0.20

5. Check the open ports on guest OS: We have used IPtable to block all the ports except SSH on guest OS. Here is the scan result from nmap.

4. Findings and Risk Ratings, Challenges and limitations

1. Running scan with Nikto on vCenter server shows that there are web component installed but may not be secure as no measures has been taken to secure the web server on vCenter server

2. Running nmap scan on guest OS reveals the OS version running on it which may make it prone to targeted attacks.

5) Outcome

While doing the security project we have come across following results. We have been successful in securing our hybrid cloud infrastructure which consists of security at four levels namely hypervisor, guest OS, network and public cloud. We have acquired knowledge about the risks and threats associated with the infrastructure and accordingly selected tools and methodologies to alleviate the security risks.

While doing that, we learned about different kinds of threat models and different risks and threats associated to it. We have followed AS/NZS 4360 and ENISA threat model under OWASP recommendations and learned about various aspects of security in our hybrid cloud infrastructure. Using some of the features while implementing AS/NZS 4360 we came to know how we can identify, analyze and treat the risks and affect user experience.

6) Conclusion

With all our security implementation and testing approach we have come to a conclusion that inbuilt security features of the cloud software/platform can be combined together with third party software to achieve better level of security. We cannot rely just on the inbuilt security features of the platform for a full proof infrastructure.

In our implementation, we secured our guest OS with all the inbuilt server hardening features and functions though there still were few vulnerabilities exposed which could be controlled using some third party software. We have identified that more work needs to be done in our future implementations.

7) References

Amazon Web Services, Inc., (2014). AWS Security Center. [online] Available at:

http://aws.amazon.com/security/ [Accessed 11 Dec. 2014].

Cyberciti.biz, (2014). Top 30 Nmap Command Examples For Sys/Network Admins. [online] Available at:

http://www.cyberciti.biz/networking/nmap-command-examples-tutorials/ [Accessed 11 Dec.

2014].

Kali.org, (2014). [online] Available at: https://www.kali.org/official-documentation/ [Accessed 11 Dec.

2014].

Owasp.org, (2014). Threat Risk Modeling - OWASP. [online] Available at:

https://www.owasp.org/index.php/Threat_Risk_Modeling [Accessed 5 Dec. 2014].

Putty.org, (2014). Download PuTTY - a free SSH and telnet client for Windows. [online] Available at:

http://www.putty.org/ [Accessed 12 Dec. 2014].

vSphere Security. (2014). 1st ed. [ebook] Available at:

https://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-

server-50-security-guide.pdf [Accessed 8 Dec. 2014].