OPEN SOURCE PRIVATE CLOUD MANAGEMENT WITH OPENSTACK AND SECURITY EVALUATION

of 124
“OPEN SOURCE PRIVATE CLOUD MANAGEMENT WITH OPENSTACK AND SECURITY
EVALUATION WITH INTRUSION DETECTION/PREVENTION SYSTEMS.
”
By
TRUNGU XHANI
Dissertation Submitted to the University of Greenwich in partial fulfillment of the
requirements for the degree of Bachelor of Science in Internet Engineering and Web
Management.

of 124
AKNOWLEDGMENTS
I would like to thank my parents and sister, who helped me and supported me for all my life,
and i would like to thank from the depths of my heart, that the most important part anymore
is my wife, who supports me for everything i have had to do. She is the Alpha and the Omega
and the most important contributor so far.
Also my sincere regards, and was my pleasure to work with, cooperate, and learn among the
great tutors we had all these years, and who helped us without ever complaining about
anything.
My love to ,
ANTHI, ELENA, STAYROYLA, MICHALIS, my family
And
Mr. PANDITHAS, Mr. DERAZIZIAN, Mr. PAPAMICHAIL

of 124
Abstract
Nowadays, we hear about terms like, cloud computing((Kalagiakos and Karampelas,
2011)), cloud architectures((Amanatullah et al., 2013)), virtualization
technologies((“Virtualization,” 2014)), cloud management systems, clustering and cloud
security systems. By a first glance these terms are a bit vague, and questions arise about
what is a cloud, what is virtualization and finally what is clustering. We are going to
elaborate these terms and conceptualize how we could use them in real life, just like as
many enterprises, corporations, and mid-ranged businesses are doing so.
Figure 1 The OpenStack Cloud Computing and the World of Internet
(cloud-computing-using-openstack-1-638.jpg (JPEG Image, 638 × 479 pixels) - Scaled (0%),
n.d.)

of 124
Table of Contents
ABSTRACT .............................................................................................................................................................................3
INTRODUCTION..................................................................................................................................................................7
LITERATURE REVIEW.....................................................................................................................................................8
OPEN SOURCE CLOUD SYSTEMS........................................................................................................................................8
What is OpenStack.......................................................................................................................................................10
OpenStack Conceptual Architecture of our Interest ..............................................................................................10
Main OpenStack Components.....................................................................................................................................11
NOVA .............................................................................................................................................................................11
SWIFT ............................................................................................................................................................................11
CINDER .........................................................................................................................................................................11
HORIZON......................................................................................................................................................................12
KEYSTONE ...................................................................................................................................................................12
GLANCE ........................................................................................................................................................................12
HEAT..............................................................................................................................................................................12
CEILOMETER..............................................................................................................................................................12
NEUTRON.....................................................................................................................................................................12
3-Node Architecture with OpenStack Networking..................................................................................................13
2-Node Architecture with legacy-networking..........................................................................................................14
DevStack Cloud System Management ......................................................................................................................15
Virtualization Technologies .......................................................................................................................................16
Intrusion Detection Prevention Systems ..................................................................................................................17
OpenStack‘s security issues........................................................................................................................................18
Divisions of security roles and responsibilities...........................................................................................................18
Keystone conceptual Architecture...............................................................................................................................19
Known Security Breaches in Keystone.......................................................................................................................21
Security Policies for Cloud Systems..........................................................................................................................22
ANALYSIS ............................................................................................................................................................................24
PROBLEM DOMAIN UNDERSTANDING.............................................................................................................................24
Our project’s OpenStack Architecture.....................................................................................................................26
PLANNING...........................................................................................................................................................................27
METHODOLOGY APPLIED.................................................................................................................................................35
DESIGN AND IMPLEMENTATION ...........................................................................................................................36
REDESIGN AND REIMPLEMENTATION OF OUR CLOUD..................................................................................................44
Setting up DevStack.....................................................................................................................................................44
SSH Hardening............................................................................................................................................................47
Firewalls ......................................................................................................................................................................50
Apache Hardening.......................................................................................................................................................55
Installing RKHunter ....................................................................................................................................................57
Installing OSSEC Server .............................................................................................................................................60
TESTING..............................................................................................................................................................................64
TESTING SCENARIO 1: (SQLMAP) ..........................................................................................................................64
TESTING SCENARIO 2: (THC-HYDRA)..................................................................................................................65

of 124
CONCLUSION.....................................................................................................................................................................66
FUTURE WORK.................................................................................................................................................................67
APPENDIX............................................................................................................................................................................68
APPENDIX 1 ........................................................................................................................................................................68
APPENDIX 2 ........................................................................................................................................................................70
APPENDIX 3 ........................................................................................................................................................................72
APPENDIX 4 ........................................................................................................................................................................75
APPENDIX 5 ........................................................................................................................................................................76
APPENDIX 6 ........................................................................................................................................................................76
APPENDIX 7 ........................................................................................................................................................................77
APPENDIX 8 ........................................................................................................................................................................83
APPENDIX 9 ........................................................................................................................................................................86
APPENDIX 10......................................................................................................................................................................87
APPENDIX 11....................................................................................................................................................................106
APPENDIX 12....................................................................................................................................................................107
APPENDIX 13....................................................................................................................................................................108
APPENDIX 14 ................................................................................................................................................................112
APPENDIX 15 ................................................................................................................................................................112
APPENDIX 16 ................................................................................................................................................................114
REFERENCES ...................................................................................................................................................................123

of 124
Table of Figures
Figure 1 The OpenStack Cloud Computing and the World of Internet--------------------------------------3
Figure 2 Cloud Computing Service Models--------------------------------------------------------------------9
Figure 3 DevStack Concept------------------------------------------------------------------------------------ 15
Figure 4 DevStack Default Services -------------------------------------------------------------------------- 16
Figure 5 The OSI 7 Layer Model ------------------------------------------------------------------------------- 24
Figure 6 Iterative Methodology ------------------------------------------------------------------------------- 25
Figure 7 Network Layout Of our System---------------------------------------------------------------------- 27
Figure 8 Host Connection with Router------------------------------------------------------------------------ 37
Figure 9 Security of Host and Router Connectio------------------------------------------------------------- 37
Figure 10 Firewall Protection on Router---------------------------------------------------------------------- 38
Figure 11 NAT Enabled On Router ---------------------------------------------------------------------------- 38
Figure 12 DHCP Server Enabled On Router ------------------------------------------------------------------ 38
Figure 13 Images for the Servers and Clone Images of them ---------------------------------------------- 39
Figure 14 Storage Volumesfor the Servers ------------------------------------------------------------------ 39
Figure 15 Network Interfaces on Virtual Machine Manager----------------------------------------------- 40
Figure 16 Virtual Networks for the Virtual Machines (Nodes)--------------------------------------------- 40
Figure 17 Virtual Network Connections ---------------------------------------------------------------------- 41
Figure 18 Compute Node Ready for further configurations------------------------------------------------ 41
Figure 19 The Virtual Network Connecting the Machines to the Internet ------------------------------- 42
Figure 20 Hosts configuration on Controller--------------------------------Error! Bookmark not defined.
Figure 21 NICs on ControllerNode-------------------------------------------Error! Bookmark not defined.
Figure 22 Devstack's Finalized Installation with Login and Management Info--------------------------- 45
Figure 24 Firewall configurations------------------------------------------------------------------------------ 51
Figure 26 Rule added ------------------------------------------------------------------------------------------- 52
Figure 25 Disable unauthorized user creation--------------------------------------------------------------- 52
Figure 27 Removing Rkhunter Warning through configuration ------------------------------------------- 59
Figure 28 OSSEC Architecture --------------------------------------------------------------------------------- 61
Figure 29 Hosts configuration on Controller----------------------------------------------------------------- 68
Figure 30 NICs on ControllerNode---------------------------------------------------------------------------- 69
Figure 31 Hosts of each OpenStack Node defined ---------------------------------------------------------- 71
Figure 32 Host of each OpenStackNode defined ----------------------------------------------------------- 73
Figure 33 Network Interfaces on Compute Node ----------------------------------------------------------- 74
Figure 34 SqlMap attack---------------------------------------------------------------------------------------113
Figure 35 SqlMap attack---------------------------------------------------------------------------------------113
Figure 36 Agent Configurations ------------------------------------------------------------------------------121
Figure 37 Agent configurations-------------------------------------------------------------------------------122

of 124
Introduction
Nowadays, we hear about terms like, cloud computing(Kalagiakos and Karampelas,
2011), cloud architectures(Amanatullah et al., 2013), virtualization
technologies(“Virtualization,” 2014) cloud management systems, clustering and cloud
security systems. By a first glance these terms are a bit vague, and questions arise about
what is a cloud, what is virtualization and finally what is clustering. We are going to
elaborate these terms and conceptualize how we could use them in real life, just like as
many enterprises, corporations, and mid-ranged businesses are doing so.
Later in this project we are going to discuss about all these terms, so that we can have
an exact picture of their meaning and where and how do we use them.
Everything in this project is going to be designed and deployed in accordance to the
internal test network topology created for the purposes that follow. The test network
will include several nodes (servers) fully virtualized and managed by the OpenStack
cloud management system(“OpenStack,” 2014). This cluster will be the backbone of
our Private Cloud system, where all the critical data will be held and secured from
attacks outside or even inside of our network. An external unknown client will be used
for breaching inside our Private Cloud’s backbone, demonstrating the effectiveness of
the security policies to be deployed in our internal test network.
In the first part of this project we are going to discuss about Open Source Private Cloud
system architecture and the philosophy of the Open Source cloud management system,
called OpenStack. The second part consists of the applicability and deployment of
clustering. The third part includes the deployment of virtualization technology among
our internal test network servers (nodes) and hosts. We are going to use for this task the
Linux KVM (Kernel-based Virtual Machine)(“Main Page - KVM,” n.d.).Open Source
virtualization software. The fourth part of the project includes the design and
implementation of Network Intrusion Detection/ Prevention System (NIDS/ NIPS) such
as Snort(Khamphakdee et al., 2014);(“Snort (software),” 2014), which is an Open
Source software, and OSSEC(“OSSEC | Home | Open Source SECurity,” n.d.) (IDS),
Open Source software as well, Host-based Intrusion Detection System. Except from the
IDS Software that we are going to use in first line of defense a couple more Software
and Network security tools will be implemented. In the fourth part of the project we are
also going to elaborate the security policies deployed via the NIPS and NIDS, and test
the solidity of our network security by creating some attack scenarios (e.g. buffer
overflows, stealth port scanning from outside the network, CGI attacks, OS

of 124
fingerprinting attempts and etc.).
Literature Review
Open Source Cloud Systems
The concepts of Cloud systems will be researched via on line documentation, manual
guides, articles, projects in order to be able to examine the feasibility to implement a
Cloud System. And finally to conceptualize the Cloud's infrastructure on physical
network level and on virtual network level.
When we are talking about cloud systems we think of cloud computing or on-demand
computing , infrastructure as a service, software as a service we really mean the shift in
geographic transition of computation. For example when we create a word document
with the Google docs and we save it online on an external, somewhere in the world,
database. A couple years ago, we would store the same word document locally in our
PC or a hard drive or disc . But, in the times we live in we are able to create this file or
anything else on the Internet in a cloud system. Metaphorically speaking, computation
has made a transition from the earth to a cloud in the sky.(“CACM_V51.7.indb - news-
cloud-computing.pdf,” n.d.) Today all industry players offer cloud solutions, especially
Amazon ec2, Microsoft azure, Google apps, and etc. Cloud computing consists of three
levels of offerings: (Armbrust et al., 2010)
1) Infrastructure as a service where the equipment is provided in the form of virtual
machines. The client maintains the applications, runtimes and integration databases,
while the supplier maintains the cloud virtualization hardware server storage networks,
for example Amazon ec2.
2) Platform as a service, where you can develop applications using the services
provided. The client maintains only the applications while the supplier maintains
virtualization, server hardware, storage networks, databases, SOA integration, runtimes
cloud, for example Google apps.
3) Software as a service, where the entire applications are available remotely, for
example Facebook.(see Figure 2 Cloud Computing Service Models)

of 124
Figure 2 Cloud Computing Service Models
(https://toyinogunmefun.files.wordpress.com/2011/06/image.png)
(image.png (PNG Image, 747 × 557 pixels) - Scaled (0%), n.d.)
According to existing studies there has been a focus on the two sides of infrastructure
as a service. The first side is about the study of middleware platforms, and the second
side, is about the comparative studies of the different solutions.
As reported officially by the Eucalyptus (“HP Helion Eucalyptus,” n.d.)
OpenNebula(Moreno-Vozmediano et al., 2012), Nimbus(“Publications - Nimbus,” n.d.)
and Openstack(“OpenStack,” 2014) websites, the respective cloud systems have been
largely studied in the literature. The architecture and various components of these
systems have been presented meticulously and adopted by well known corporations,
such as rackspace and NASA, both of which thrusted Open Stack cloud management
system in association with the Open Stack community and partners.

of 124
What is OpenStack
Open Stack is still under active development and has great potential due to its
architecture and community and the support of its partners. All the code is licensed
under apache 2. The initial platform has been developed by NASA and was dedicated to
massive infrastructures. This cloud system has three characteristics:
1) Scalable- deployment by companies with data volumes measured in petabytes in
distributed architectures and scalable up to one million physical machines, up to sixty
million virtual machines and billions of objects stored.
2) Compatible and flexible:Open Stack supports most virtualization technologies such
as ESX, HYPER V, KVM,LXC, UML,XEN, and XEN server and QEMU .
3) Open Stack is open source and as a result the entire code can be modified and
adapted as needed.
Open Stack is a cloud operating system which controls amounts of pool resources such
as compute, storage, end networking .All the management is defined and executed
throughout its data center which can be, in turn, managed through a dashboard. So
administrative control is provided and we can utilize in full and provision resources
through a web interface.
OpenStack Conceptual Architecture ofour Interest
In a more elaborate way of analysis, Open Stack is a set of tools to built and manage
cloud computing platforms for public and private clouds.
When we mentioned that we can utilize the resources of the cloud, we meant that it
allows users to deploy virtual machines and other instances, and handle tasks for
managing the cloud environment.
This kind of architecture serves to achieve horizontal scaling easily, which means that,
tasks which benefit from running concurrently may serve more or less users on the fly
by starting up more instances of any kind we want for our system to serve. A very
clarifying example is stated in(“What is OpenStack? | Opensource.com,” n.d.) which
explains that a mobile application that needs to communicate with a remote server
might be able to divide the work of communicating with each user across many

of 124
instances of the server .
This procedure results in having all of the instances and the users communicating and
scaling up quickly and easily as the application gains more users.
Open Stack is in the category of infrastructure as a service (IaaS). Provided
infrastructure, means that it is easy for users to start a new instance or shut down one,
upon which cloud components can run. Typically the infrastructure runs on a
“platform” on which developers can create software application and deliver to the end
users.
Main OpenStack Components
Open Stack consists of many moving independent parts. This cloud management
operating system is open source which means that anyone can add additional
components to Open Stack in order to meet their expectations and needs.
It is important to state that Open Stack is a community of many large corporations
independent developers all of whom have contributed in the overall progress end
continues development of Open Stack. All these have identified nine key components,
as depicted in Figure 3 above, that are the backbone and the core of Open Stack and
they are supported / maintained by the Open Stack community. (“What is OpenStack? |
Opensource.com,” n.d.)
NOVA
It could be the chief executive of a company. It is the main computing engine behind
Open Stack. It is responsible for managing virtual machines or deploying them in order
to handle computing tasks.
SWIFT
Swift is a storage system for objects and files. Developers can use a type of identifier
which refers to a file or object which inter have been stored in some place through
Open Stack's decision where it should be stored. By this we mean that the system
handles by the best way possible where to store the information in case of a failure of a
machine or network connection.
CINDER
Cinder is the general philosophy of storing information on specific locations on a disk
drive as it is implemented by operating systems. This way of storing files is important

of 124
because access, read/write speeds are also sometimes important for the cloud
environment.
HORIZON
Horizon is the service which deploys a web interface for users to manage some
components of the Open Stack system and start or terminate instances. There is also the
access point for developers though an application programming interface (API).
KEYSTONE
Keystone is the corner stone in terms of security of Open Stack. It provides
identification mechanisms for the users to enter and use the services. This is achieved
by creating a list of all the users of the Open Stack cloud in accordance to all of the
services provided by the cloud when they have permission to use. Also Keystone
provides to developers and other ways of manipulating access methods for the users.
GLANCE
Glance is the service that provides virtual copies of disks. These are called images and
Glance uses them as templates during the deployment of new virtual machine instances.
HEAT
Heat is called the orchestration component of Open Stack which allows developers to
configure a file with all the necessary requirements for a cloud application to run. In
this file all the resources needed are defined for the application.
CEILOMETER
Ceilometer provides telemetry services to the end users regarding billing services such
as the quantity of resources used of the Open Stack components. In general, it reports
on the dashboard of Horizon metering and resource usage.
NEUTRON
Neutron is a networking service, which manages all the networking configurations for
the Open Stack services to communicate one with another.
According to (“Chapter 1. Architecture - OpenStack Installation Guide for Ubuntu
14.04 - juno,” n.d.) OpenStack is highly configurable to meet different needs with
various compute, networking, and storage options. This guide enables you to choose
your own OpenStack adventure using a combination of core and optional services. The

of 124
guide uses the following example architectures:
3-Node Architecture with OpenStack Networking
• Three-node architecture with OpenStack Networking (neutron) and optional nodes
for Block Storage and Object Storage services.
• The controller node runs the Identity service, Image Service, management portions of
Compute and Networking, Networking plug-in, and the dashboard. It also includes
supporting services such as a SQL database, message queue, and Network Time
Protocol (NTP).
Optionally, the controller node runs portions of Block Storage, Object Storage,
Orchestration, Telemetry, Database, and Data Processing services. These components
provide additional features for your environment.
• The network node runs the Networking plug-in and several agents that provision
tenant networks and provide switching, routing, NAT, and DHCP services. This node
also handles external (Internet) connectivity for tenant virtual machine instances.
• The compute node runs the hypervisor portion of Compute that operates tenant virtual
machines or instances. By default, Compute uses KVM as the hypervisor. The compute
node also runs the Networking plug-in and an agent that connect tenant networks to
instances and provide firewalling (security groups) services. You can run more than one
compute node.
Optionally, the compute node runs a Telemetry agent to collect metrics. Also, it can
contain a third network interface on a separate storage network to improve performance
of storage services.
• The optional Block Storage node contains the disks that the Block Storage service
provisions for tenant virtual machine instances. You can run more than one of these
nodes. Optionally, the Block Storage node runs a Telemetry agent to collect metrics.
Also, it can contain a second network interface on a separate storage network to
improve performance of storage services.
• The optional Object Storage nodes contain the disks that the Object Storage service
uses for storing accounts, containers, and objects. You can run more than two of these
nodes. However, the minimal architecture example requires two nodes.

of 124
Optionally, these nodes can contain a second network interface on a separate storage
network to improve performance of storage services.
2-Node Architecture with legacy-networking
• Two-node architecture with legacy networking (nova-network) and optional nodes for
Block Storage and Object Storage services.
• The controller node runs the Identity service, Image Service, management portion of
Compute, and the dashboard. It also includes supporting services such as a SQL
database, message queue, and Network Time Protocol (NTP).
Optionally, the controller node runs portions of Block Storage, Object Storage,
Orchestration, Telemetry, Database, and Data Processing services. These components
provide additional features for your environment.
• The compute node runs the hypervisor portion of Compute that operates tenant virtual
machines or instances. By default, Compute uses KVM as the hypervisor. Compute
also provisions tenant networks and provides firewalling (security groups) services.
You can run more than one compute node.
Optionally, the compute node runs a Telemetry agent to collect metrics. Also, it can
contain a third network interface on a separate storage network to improve performance
of storage services.
• The optional Block Storage node contains the disks that the Block Storage service
provisions for tenant virtual machine instances. You can run more than one of these
nodes.
Optionally, the Block Storage node runs a Telemetry agent to collect metrics. Also, it
can contain a second network interface on a separate storage network to improve
performance of storage services.
• The optional Object Storage nodes contain the disks that the Object Storage service
uses for storing accounts, containers, and objects. You can run more than two of these
nodes. However, the minimal architecture example requires two nodes.
Optionally, these nodes can contain a second network interface on a separate storage
network to improve performance of storage services.

of 124
DevStack Cloud System Management
Except from the above mentioned architectures of OpenStack, DevStack is another
OpenStack community production. The main characteristic and the first goal mentioned
in (“DevStack - an OpenStack Community Production — DevStack 0.0.1.dev6069
documentation,” n.d.) is to create your own private cloud system on a single virtual
machine for development and testing purposes via an automated method of installing
the OpenStack cloud management system. (Figure 3 DevStack Concept)
Figure 3 DevStack Concept
(http://1.bp.blogspot.com/-WfuXmzMqk4o/Uu45R8Kg1BI/AAAAAAAADjM/AbtX9cK_Yok/s1600/Devstack_why.PNG
(Devstack_why.PNG (PNG Image, 591 × 300 pixels) - Scaled (0%), n.d.)
DevStack has evolved to support a large number of configuration options and
alternative platforms and support services. That evolution has grown well beyond what
was originally intended and the majority of configuration combinations are rarely if
ever tested. DevStack is not a general OpenStack installer and was never meant to be
everything to everyone as stated in (“Overview — DevStack 0.0.1.dev6069
documentation,” n.d.). The base OS to be used for the DevStack and in general
OpenStack is a list of unix systems such as:
UBUNTU
FEDORA
RHEL
Other OS platforms may continue to be included
DevStack uses the same components as OpenStack and relies on the same databases
(MSQL, POSTGRESQL) queues (RABBITMQ, QPID) web server (APACHE)
OpenStack network (NOVA Network : Flat DHCP) NEUTRON, services ( by default
configured by DevStack are Identity, Object storage, Image service, Block storage,

of 124
Compute, Networking, Dashboard, Orchestration). (See Figure 4 DevStack Default
Services)
Figure 4 DevStack Default Services
(http://image.slidesharecdn.com/devstack-140825084850-phpapp02/95/openstack-in-10-minutes-with-devstack-
14-638.jpg?cb=1408956595)
(openstack-in-10-minutes-with-devstack-14-638.jpg (JPEG Image, 638 × 359 pixels) - Scaled
(0%), n.d.)
Another advantage for developing and testing purposes with DevStack is that it can also
be set up on a single node or even a multi node cloud system.
Virtualization Technologies
There is a statement according to (Folgar et al., 2014) that cloud technologies are
arousing great interest because of the current increase on the demand by users of
virtualization services and Virtual Machines (VMs). As a result, there is an increasing
number of open-source solutions for building private, and even hybrid Clouds that can
make use of different hypervisors, including KVM.

of 124
Among a list of virtualization softwares, ESX, HYPER V, LXC, UML, XEN, XEN
server and QEMU we have chosen to use KVM. This virtualization software provides
high availability, customization, it is Open Source and can be programmed if needed in
any case, and it is best supported with ongoing development, by OpenStack.
In regard to (Folgar et al., 2014), KVM allows to configure the instructions set of the
VM processors and allowing finally the replacement of the host processor or the VM
migration easier, guaranteeing the guest compatibility with the new host. In addition, it
does not require large amounts of resources and computing power, in order to achieve
the creation of a small private cloud testing environment.
Intrusion Detection Prevention Systems
After setting up the security policies for the Cloud, we shall research and deploy two
IDS/IPS systems, which would be complimentary to the already implemented Cloud
security, and would provide further levels of security.
As stated in the article by (Beal, n.d.)an intrusion detection system is designed to
monitor all inbound and outbound network activity and identify any suspicious patterns
that may indicate a network or system attack from someone attempting to break into or
compromise a system.
IDS is considered to be a passive -monitoring system since the main function of an IDS
is to warn you of suspicious activity taking place. An IDS essentially filters your
network traffic and data and identifies probes, attacks, exploits, and other
vulnerabilities. The most common reaction of an IDS is to send to the administrator via
log or via e-mail alert messages.
There are passive and reactive intrusion detection systems.
They have in common one operation; detect security breaches and then the same tactic
is applied to log the events and trigger alerts. The reactive IDS /IPS has an extra ability
to respond to the breach and execute any kind of policy that it was programmed apply
in such case.
There are, also, network based and host based IDSs. In our project's scope we need to
install an IDS which configured properly would have the ability to analyze the traffic to
and from a computer as well as taking action through active response after an alert. By

of 124
this we mean that after logging and sending alert to an administrator the IDS can
respond to the threat by reconfiguring the firewall of the system to be protected.
(Beal, n.d.) states clearly that a server and agents which can be installed on individual
machines of a network. The agents monitor the hosts in which they are installed log the
network traffic and send the logs to the server where analysis takes place in order the
IDS to take action.
There are two intrusion detection and prevention systems that we can implement in our
project's testing network to complement our private cloud's security. These two open
source systems are OSSEC, which is going to be implemented, and SNORT, about
which, a presentation of capabilities and functions is going to take place further down.
A better security policy except the one of using an IDS would be to install and deploy
another tool called Linux Malware Detect. This is a Malware scanner for Linux
released under the GNU GPLv2 License that is designed around the threats in shared
hosted environment. It uses threat data from network edge intrusion detection systems
to extract Malware that is actively being used in attacks and generates signatures for
detection. In addition threat data is also derived from user submissions with the LMD
checkout feature and from Malware community resources. The signatures that LMD
uses are MD5 file hashes and HEX pattern matches they are also easily exported to any
number of detection tools such as clam AV. The threats primarily OS lever Trojans
rootkits and traditional file-infecting viruses. (“Linux Malware Detect | R-fx
Networks,” n.d.)
OpenStack‘s security issues
Divisions of security roles and responsibilities
With respect to security incidents, concerning Cloud Systems, we would have to state
the division of the security-relevant roles and responsibilities in terms of Infrastructure
as a service. Infrastructure as a service provides a set of servers, storage, network,
bandwidth to the final user-customer, while always bearing in mind and provisioning
for physical support of the infrastructure, physical infrastructure security, and
availability of the Hosts Systems. The user-customer of the IaaS enjoys the services

of 124
while having to provision, on one hand, for the security integrity of the systems
provided, and on the other hand, having to maintain the Identity Management System
and authentication platforms. The division of security roles and responsibilities can be
seen below in the table.
Table 1 Diversions of Roles and Responsibilities
User-Customer IaaS Provider
Maintenance of identity management
system
(Identity Service – Keystone) in our case
Physical support infrastructure (facilities,
rack space, power, cooling, cabling, etc.)
Management of authentication platform
(including enforcing password policy)
Physical infrastructure security and
availability (servers, storage, network,
bandwidth, etc.)
Management of guest OS patch and
hardening procedures
Configuration of guest security platform
(firewall rules, IDS/IPS tuning etc.)
Guest systems monitoring
Security platform maintenance
Log collection and security monitoring
Keystone conceptual Architecture
As stated above Open Stack has nine key components, and one of these the identity
component (keystone), manages the authentication methods, in order to have secure
cloud environment. Keystone provides unified authentication and integrates with
existing systems (“OpenStack Security,” 16:14:46 UTC).It offers identity, token
,service catalog, and policy service designed for integration with existing systems. The
two main functions of the identity service are:
o User management: it contains a list of users and their respective permissions on

of 124
the system.
o Service catalog: The availability of services is provided as well as their API
endpoints locations.
Keystone's philosophy is to have the cloud's internal services organized as a group
which finally are exposed on endpoints (urls provided by Open Stack in order to
manage a service). These internal services are the following:
o Identity: The identity service provides authentication credential validation
and data about users tenants and roles as well as metadata
o Token: The token service validates and manages tokens used for
authenticating requests once a user / tenant's credentials have already been verified.
o Catalog: The catalog service provides an endpoint registry used for
endpoint discovery.
o Policy: The policy service provides a rule based authorization
engine.
One of the main characteristics of keystone is that each of the services can be
configured to use a backend to allow keystone to fit a variety of environments and
needs. The backend for each service is defined in the keystone.conf file. A list of
backends is stated below
-KVS Backend
-SQLBackend: SQL based backend using SQLAlchemy to store data persistently.
-PAM Backend: It uses a system's PAM service to authenticate providing a one to one
relationship between users and tenants.
-LDAP Backend: stores users and tenants in separate subtrees.
-Templated Backend
Keystone user management concept has three main parts:
-Users: represents humans with information associated such as user name password
email.
-Tenants: can be a project a group or organization. And it is compulsory to be specified
in requests to Open Stack services.
-Roles: describe what operations a user is permitted to perform in a given tenant.

of 124
Known Security Breaches in Keystone
It is sensible to refer to a list of security breaches, in terms of Security issues in Clouds,
known in Keystone, as studied before and stated in (“Security Issues in OpenStack,”
16:01:05 UTC).
o Authentication systems: Devauth in which user data are stored in SQLite
database.
o Authentication systems: SWAuth in which user data are stored in object storage.
o Authentication systems: Security Token Generation.
Security tokens in open stack play the same role as session identifiers for web
applications.
o UUID version 4 was found to be used to generate tokens , which used
/dev/urandom on Ubuntu as a source of randomness.
o Authentication: Portability of stored data in which administrators have the
possibility to retrieve authentication data of users belonging to the accounts that
they manage.
Depending on these security holes in Keystone's data management system and storage,
we would need to focus on the most important parts of these security issues. They all
have in common one thing. That would be the database entries for every piece of data
and information handled by Keystone Identity Manager. However, this kind of
approach would be out of our project's scope of research and intentions. Nevertheless, it
would be a theoretical asset to be aware of the Identity Service Security Architecture
for future needs, upon this project or some other case.
This is the cornerstone of OpenStack, in terms of security, and we need to proceed with
penetration testing scenarios in order to conclude how much valuable data could be
manipulated and/or even stolen, from our Cloud System and even from the Host, in
which our OpenStack server resides. Generally, the security issues that could arouse in
our Cloud System are the main project's scope of study.
So the project's field of interest is the Security evaluation of the OpenStack servers and
the Security of the Infrastructure in total, as a unit.
Penetration testing scenarios are going to be conducted via another virtual machine
with Kali Linux OS running from the Virtual Machine Manager in our Host, where all
the other virtual machines – servers reside.

of 124
Security Policies for Cloud Systems
In this section, we will identify, organize, classify and qualify all the levels of security
strategies, so that we could create a stable, efficient and secure distributed system. Main
security frameworks currently available will be discussed in further detail, such as
firewalls, security configurations, and transfer security.
The security polices for our cloud system are mainly extended on the host itself which
has the virtualized Open stack server running, as well as, security polices on the latter
one. The policies will be deployed on five (5) OSI layers, the Application Layer, the
Transport Layer and the Network Layer, Data Link Layer, and Physical Layer.
The host which contains the virtual machine of OpenStack server has to be
configured with certain security steps, which will comprise later the security policies of
our server.
The very first security step would be to create a firewall, with a set of rules, and then
put the network,on which the servers will run, behind it. The recommended software
for this task would be ufw. (“Firewall,” n.d.)
The second security step to be taken is SSH hardening. SSH is going to be used in order
to login from terminal to the OpenStack Server from our host machine and manage it
securely.
It is generally a very sensible idea to disable any kind of root login over SSH, and
especially change the standard port, such as port 22 of SSH, to a non-standard one. By
this way incoming SSH hacking attempts will be avoided, and as a result our servers
will stay untouched.
Another step would be to limit “su” access to administrators only. Generally speaking,
we are going to make sure that only users in the sudo group are able to run the “su”
command in order to act as(or become) root and put our servers at risk state.
Furthermore, the IP security improvement steps shall be taken into consideration, such
as, ignoring ICMP broadcast requests, so that the server's load would be kept at low

of 124
levels, blocking SYN attacks using Log Martians, and ignore Directed pings, and high-
level IPtables configurations in order to prevent at the most a variety of attacks, such as
Smurf attacks, or even Stealth Port Scanning.
In order to complement the security hardening of Apache web server we are going to
install ModSecurity, which is a web application firewall (WAF).
WAFs in general are deployed to establish an increased external security level to detect
and/or prevent attacks even before happening. ModSecurity provides protection from
range of attacks against web applications and allows for HTTP traffic monitoring
and real-time analysis with little or no changes to existing infrastructure.(“Reference
Manual · SpiderLabs/ModSecurity Wiki · GitHub,” n.d.)
Also, another security policy for our servers is the installation of a Unix-based tool that
scans for rootkits,backdoors, and possible local exploits. It is a software with high risk
responsibilities because it is a tool right in the heart of the Project's network, searching
for default directories(of rootkits),wrong permissions, hidden files, suspicious strings in
the kernel modules, and special tests for Linux and FreeBSD. (“rkhunter - Wikipedia,
the free encyclopedia,” n.d.)
Another tool in the section of security policies for our cloud system would be the
Logwatch, which provides regular reports nicely summarizing what's been going on in
the servers' logs. And last but not least option in security policies would be to enable
the Linux process accounting, which keeps track of all sorts of details about which
commands have been run on the servers, who ran them, when, etc. It's a very sensible
thing to enable on a server where security is a priority. (“Security hardening on Ubuntu
Server 14.04,” n.d.)
And last, but not least, the fortification of PHP, MYSQL would be the other most
important step, so that we would possess very secure servers in our network by a series
of commands as stated in (“Ways To Secure Your Ubuntu 14.04 Server Running LAMP
| Unixmen,” n.d.)

of 124
(http://www.escotal.com/Images/Network%20parts/osi.gif)
(osi.gif (GIF Image, 800 × 618 pixels) - Scaled (0%), n.d.)
ANALYSIS
Problem Domain understanding
As stated in the Introduction, we are going to deal mostly with the design of a Private
Cloud System with distributed servers and services. Our goal, in this research paper, is
to create this Cloud System in terms of integrity, security, and as closest as possible to
real world production environments, where the servers in the Clouds are distributed and
managed remotely.
Under these circumstances, we had to conceptualize and design our Cloud System,
having in mind the parameters of Servers Security and the Cloud's overall security
architecture.
Figure 5 The OSI7 Layer Model

of 124
A very serious problem to be found in our conceptualization of the Cloud System, and
the gathering of Hardware, was the final unavailability of one of the routers proposed in
the initial Project proposal due to technical failure, and the inability to gain a new one,
and use it for our purposes of security in our network.
The second problem in row we had to deal with is the second Laptop, which would host
the OSSEC IPS, which proved to be also inaccessible due to external reasons,
stemming from the human environment.
So there shall be described, in the Requirements and Work packages table further down,
that there was a lack of hardware resources, which would have been used in order to
increase the complexity of our Cloud System, and be more close-to product
environments as far as concerning the field of Security.
As a first step, we have to focus on the PLANNING part of our research, in conjunction
with our methodology's lifecycle. (See in Figure 6 Iterative Methodology)
Figure 6 Iterative Methodology
(“Manual Testing -,” n.d.)
As a second step, we will concentrate to list as more detailed as possible the

of 124
REQUIREMENTS of and the WORK PACKAGES of our project.
As a third step, we will ANALYZE THE DESIGN of our Cloud System's Architecture.
As a fourth step, we will proceed with the IMPLEMENTATION of our Architecture,
such as the implementation of the Hosts containing the servers and the Intrusion
Detection Systems.
As a fifth step, we will DEPLOY and EVALUATE with TESTING the system's overall
efficiency and Security fortifications.
As a sixth step, in case of problems and issues arousing during any of the above
processes we will step back to the Initial PLANNING of step one.
Our project’s OpenStack Architecture
For our project's purposes we have decided to implement the OpenStack Networking
architecture based on 3 nodes (Controller Node, Networking Node, Compute Node),
which will serve to run the OpenStack Cloud System, and serve us every service it has
to offer, manage the infrastructure through web-based Interface of Horizon's service
Dashboard.(Figure 7 Network Layout Of our System) We have chosen to deploy this
kind of architecture, despite of its complexity in Analysis, Design and Implementation,
due to the fact that it is a minimalistic architecture that may be found in a real
production environment, with the only difference that there would be deployed many
more servers, with greater computational power.
Alongside with the OpenStack cloud system we will have the OSSEC Intrusion
Detection / Prevention System and Snort IDS to fortify our Cloud system and Private
Network.
OSSEC system provides monitoring, logging, scanning, threat detection and prevention
methods, in many levels of security in conjunction with thousands of rules contained in
the software by default.
Snort Network Intrusion Detection System and Prevention System provide the same
services to a system administrator and it is on the top, alongside with OSSEC, of the list
among other Intrusion Detection /Prevention Systems on the market.

of 124
Figure 7 Network Layout Of our System
PLANNING
Our project's network is divided in three sections. According to Figure 20, which
represents our Network topology, there is a physical distinction between the sections
that divide our network.
We will start describing the sections from inside out, and are the ones below:
The first section is the OpenStack's servers, which operate in a fully virtualized
environment.
The second section is the Host which contains all the three nodes of OpenStack, and the
IDS/IPS system, which after the inaccessibility of the second Laptop computer, in terms
of design, the IPS/IDS will be deployed on the physical Host.

of 124
The third section is the network between the Host and the external router.
The implementation of these procedures will be carried out by the reverse order of the
above description.
1. Beginning with the network between the Hosts and the external router means the
external network connnections between the router and the Physical Host.
2. The Table 2 Requirements and Work PackagesError! Reference source not
found. shows the necessary information regarding the network's Requirements and
Work Packages analyzed and put in a logical sequence of Implementation in order to
achieve the completion and full functionality our Project's Cloud System.
3. After the external network connections, we will be dealing with the installation of
the Host Operating System and the system's preparation for hosting and virtualizing our
Cloud's Servers, as well as the hosting on the physical machine of the OSSEC server.
4. The next step in the second section of our network will be the deployment of the
Virtual Servers, and their configurations to operate and manage the OpenStack Cloud
Management System.
5. Another step after deployment of our Cloud would be the fortification by means
and terms of security policies and methods between the Host and the Cloud's Servers.
6. The first section would include the security policies carried out and implemented
inside the OpenStack Servers as a third level of stronghold in our network topology.
Table 2 RequirementsandWorkPackages
Requirements Description
R1 Installing Ubuntu 14.04 LTS on
the Host of our Project.
Linux System installation due to reason
of vast variety of configurations

of 124
available, due to security enforcements it
has, and last due to compatibility with the
OpenStack Cloud Management System.
R2 Connecting the Host with the
external Router via fast ethernet
cable
R3 Managing the security of the
physical connection to the router
Enabling MAC filtering option in the
router, so that nobody else can have
network connectivity.
R4 Managing the security regarding
Layer 2 security Options
provided by the router.
Enabling NAT, disabling DHCP,
enabling firewall protection provided by
the ISP.
R5 Preparing the Host Operating
System for virtualization
capability
Installing virtualization technology
software and installing one by one the
Servers,
R6 Deploy infrastructure as a Service Deploy the infrastructure of the Virtual
OpenStack server as a service through
Web-based dashboard, command-line
tools, or RESTful API
R7 Manage Pools of Processing
resources
Deployment of OpenStack as IaaS in
order to manage pools of processing
resources through nova service, such as
deploying 2 Virtual CPUs (VCPUs)
R8 Manage Pools of Storage
resources
Managing pools of storage space,
through cinder service, that is block
storage, for any kind of data.
R9 Manage Pools of Networking
resources
Managing the Networking capabilities
provided by Neutron service, for example
flat DHCP , or VLANs creation
R1
0
Managing the Intrusion
Detection/Prevention Systems
Deployment and management, such as of
OSSEC server and agents on the

of 124
OpenStack Nodes
R1
1
Monitoring the networks required
for a 3 Node OpenStack as well
as the OSSEC's network in which
the IDS belongs to/
Monitoring all the inbound and outbound
traffic in which the servers belong to.
R1
2
Logging any unusual patterns by
data sent from the agents
And making them available through log
files
R8 Alerting administrator via e-mail
about any kind of threat of a
certain level
R9 OSSEC automated active
response in case of a threat
detection
Active threat prevention by OSSEC
R1
0
Enabling SSH protocol for secure
remote connections of the users
R1
1
Enabling Iptables
R1
2
Enabling OS firewalls on both
servers
Restricting inbound and outbound traffic
to and from the OpenStack servers and
OSSEC server
R1
3
Enabling Linux Malware detect A tool for detecting and eliminating
Malwares like Trojan ,worms etc.
R1
4
Each OpenStack server will have
firewalls enabled
The firewalls will allow all the necessary
traffic for the services
R1
5
Each OpenStack server will have
rkhunter installed
Its a rootkit detection tool
R1
6
Every server will have an OSSEC
agent installed
R1
7
Every server will have strongly
secured MYSQL service
This is because there are security issues
widely known in the Identity service of

of 124
OpenStack
R1
8
Penetration testing against the
servers using three scenarios
Sqlmap tool to detect and exploit SQL
injection flaws and database takeover
THC-HYDRA tool to crack login
credentials with support in HTTP
,MYSQL,SQLITE,SSH,TELNET, etc.
R1
9
Goal 1: users can manage
OpenStack resources securely
R2
0
Goal 2: the fortification of the
servers will endure many kinds of
attacks and threats
WORK
PACKAGES
DESCRIPTION OF REQUIREMENTS' SPECIFICATIONS
WPK 1 Installing UBUNTU 14.04LTS* (the host of our Cloud)
WPK 2 Installing KVM ( Kernel – Based Virtual Machine )*
WPK 3 Installing Virtual Machine Manager to deploy the virtual machines
*
WPK 4 Creation of storage pools in the virtual machine manager to store
the virtual machines disks *
WKP 5 Create a virtual bridge from the virtual machine manager to the
host's NIC *
WPK 6 Create 4 different virtual networks to be used by the virtual
machines *
WPK 7 Create a management network 10.0.0.0/24*
WPK 8 Create a VM traffic network 10.0.1.0/24*
WPK 9 Create a public network 192.168.100.0/24 routed to ethernet 0
behind NAT*
WPK 10 Create 50 GB of storage volume named CONTROLLER NODE*
WPK 11 Create the virtual machine of the controller node and choose the

of 124
storage volume created before named controller node *
WPK 12 Set CPU and RAM for the controller node *
WPK 13 Configure the network interface card with internet access and
choose it for the primary NIC of controller node- public network*
WPK 14 Add the network interface card for the management network *
WPK 15 Begin installation of UBUNTU SERVER 14.04.LTS controller
node *
WPK 16 Create 50 GB of storage volume named NETWORK NODE *
WPK 17 Create the virtual machine of the network node and choose the
storage volume named network node *
WPK 18 Set CPU and RAM for the network node*
choose it for the primary NIC of network node- public network*
WPK 20 Add the network interface card for the management network*
WPK 21 Add the network interface card for the VM traffic network*
WPK 22 Begin installation of UBUNTU SERVER 14.04. LTS network
node *
WPK 23 Create 50 GB of storage volume named COMPUTE NODE*
WPK 24 Create the virtual machine of the compute node and choose the
storage volume created before named controller node *
WPK 25 Set CPU and RAM for the compute node *
choose it for the primary NIC of compute node- public network*
WPK 27 Add the network interface card for the management network *
WPK 28 Begin installation of UBUNTU SERVER 14.04.LTS controller
node * (This is going to be cloned for the other two Nodes, in
order to create the cluster for the cloud)
WPK 29 CONTROLLER NODE installing SQL database service *

of 124
WPK 30 CONTROLLER NODE installing Message Queue *
WPK 31 CONTROLLER NODE installing Network Time Service*
WPK 32 CONTROLLER NODE installing Identity*
WPK 33 CONTROLLER NODE installing Image Service*
WPK 34 CONTROLLER NODE installing Compute Management *
WPK 35 CONTROLLER NODE installing Networking Management*
WPK 36 CONTROLLER NODE installing Networking ML2 Plug -in*
WPK 37 Enabling Firewall with configurations denying inbound and
outbound traffic, with exception of protocols, ports, and traffic
between the Nodes.
WPK 38 NETWORK NODE installing Open vSwitch*
WPK 39 NETWORK NODE installing Networking ML2 Plug -in*
WPK 40 NETWORK NODE installing Networking Open vSwitch Agent *
WPK 41 NETWORK NODE installing Networking L3 Agent *
WPK 42 NETWORK NODE installing Networking DHCP Agent *
WPK 43 NETWORK NODE installing Networking Metadata Agent*
between the Nodes.
WPK 45 COMPUTE NODE installing KVM Hypervisor *
WPK 46 COMPUTE NODE installing Open vSwitch*
WPK 47 COMPUTE NODE installing Compute *
WPK 48 COMPUTE NODE installing NetworkingML2 Plug -in*
WPK 49 COMPUTE NODE installing Networking Open vSwitch Agent *
WPK 50 COMPUTE NODE installing Horizon service *

of 124
between the Nodes.
WPK 52 Installing UBUNTU 14.04LTS on the second laptop **
between the Nodes.
WPK 54 Installing OSSEC IDS/IPS
WPK 55 Installing the OSSEC server on the local machine
WPK 56 Installing the OSSEC Agent on the controller node *
WPK 57 Installing the OSSEC Agent on the compute node *
WPK 58 Installing the OSSEC Agent on the network node*
WPK 59 Installing LINUX MALWARE DETECT tool on every Open
Stack node (Controller Compute Network ) *
WPK 60 Installing RKHUNTER tool on every Open Stack node (Controller
Compute Network ) *
WPK 61 Installing KALI LINUX on another virtual machine for
penetration testing scenarios
WPK 62 Installing SQL map tool in KALI LINUX to detect and exploit
SQL injection flaws and database takeover
WPK 63 Installing THC-HYDRA tool -login cracker with support in HTTP,
MSQL, SQLITE, SSH, TELNET for accounts of Open Stack
users and services and local user accounts on the server
WPK 65 Installing NMAP tool in order to perform stealth port scans and
obtain as many as possible information about the structure of the
target network, and its’ hosts.
WPK 66 Test scenario 1: Attacking the Open Stack servers with SQL map
WPK 66 Test scenario 2: Attacking the Open stack servers with THC-
HYDRA
WPK 67 Test scenario 3: Attacking with N-MAP tool.

of 124
WPK 68 Presenting the penetration testing results
Methodology Applied
The problem of our project is the level of security fortification of the private cloud
system that we are going to design and implement later on this paper.
The first issue to be discussed and analyzed is the security nature of Open stack cloud
management system. The scope of this issue is to focus on the identity service and any
vulnerabilities that it may have regarding the authentication system, and its direct
relation to MSQL database service.
The second issue to be analyzed is the fortification of the cloud's environment with the
aid of intrusion Detection Systems / Prevention Systems. The scope of this issue varies
from securing the operating system of the servers hosting Open Stack up to securing the
network traffic in the cloud system's network layout according to the architecture
selected for implementation in our case. This is the understanding of the problem's
domain. After understanding the problem of this project we gathered the requirements
for a potential solution, translated these requirements into a design, and tried to build
the solution and test it.
All the testing is going to be conducted in a strictly linear fashion. Regarding the two
issues stated above, after careful study of the keystone service manager authentication
system (“Security Issues in OpenStack,” 16:01:05 UTC), we have addressed some
assertions about the database – keystone relationships that need to be evaluated and
tested. There are also assertions about our cloud system's server side security scope.
The reason about choosing Open Stack Networking (Neutron ) architecture consisted of
three nodes (Controller Node , Compute Node , Network Node ) is because all three of
them depend their inter connection and communication on the Identity Service
(Keystone) which stores all the vital data about the users and the services' endpoints in
MSQL database as also in SQLAlchemy. This kind of architecture is approximately the
same to a production environment based on distributed systems and this is why we
chose to evaluate our assertions.
Up to this point we have understood the problem domain , gathered the requirements,
planned the system implementation, made a stakeholder analysis, further down follows

of 124
up the design and implementation, the deployment of the OpenStack cloud and finally
the penetration testing againsti the servers hosting the OpenStack cloud system services.
According to the design of the cloud system operation and availability, and the testing
results, if any of our assertions prove to be wrong then, we will have to reevaluate the
initial plan, make a new plan scheme re-adjust the requirements and finally redesign the
system, network topology and the implementation.
This is a scientific methodology used mostly in the Software development field. This is
the iterative development methodology, which we define as:
A style of development where the assertions inherent in the plan are repeatedly
challenged and reevaluated by redesigning and redeveloping the system, so that we
refine the understanding of the problem, the situation's definition, and the solution's
implementation, rebuilding the system's core activities. By the iterative development
cycle we grow the understanding of the problem and the capability provided by the
solution in Figure 6 Iterative Methodology. (“What is iterative development?,” 2005)
DESIGN AND IMPLEMENTATION
The procedures following are in conjunction with the Requirements Table and the Work
Packages.
WPK 1.
The Host's Operating System Information

of 124
R2.
Host Connection with Router
R3.
Managing the security of Physical Connection to router
R4.
Figure 9 Security of Host and Router Connectio
Figure 8 Host Connection with Router

of 124
NAT, DHCP, Firewall protection
Figure 10 Firewall Protection on Router
Figure 11 NAT Enabled On Router
Figure 12 DHCP Server Enabled On Router
R5.
Virtualization Capability of Host-based from command line output
xhani@xhani:~$ kvm --version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.10), Copyright (c) 2003-
2008 Fabrice Bellard
xhani@xhani:~$

of 124
WPK 1
Figure 13 Images for the Servers and Clone Images of them
ALL THE IMAGES ARE UBUNTU 14.04 LTS
WPK 4
Figure 14 Storage Volumes for the Servers
WPK 5

of 124
Figure 15 Network Interfaces on Virtual Machine Manager
WPK 6
Figure 16 Virtual Networks for the Virtual Machines (Nodes)
WPK 7

of 124
Figure 17 Virtual Network Connections
WPK 8
Figure 18 Compute Node Ready for further configurations
WPK 10

of 124
Figure 19 The Virtual Network Connecting the Machines to the Internet
The Same Configuration is for all the Three (3) Nodes of OpenStack.
Basic Architecture and Network Configuration
More detail further down, about the procedures of the OpenStack deployment.
In this part of the Design and Implementation section we are going to describe the first
basic Configuration of the OpenStack Nodes we want to deploy. The procedures will
follow in the Appendix in separate sections. Titles will be provided, referencing on the
Appendix section, so that the follow up of the rest of the procedure would be easy.
For the configurations of Computer Node refer back to APPENDIX 1.
For the configurations of Network Node refer back to APPENDIX 2.
For the configuration of Compute Node refer back to APPENDIX 3
Up to this point of network interfaces configurations on all three virtual machines
we have successful communication between them and access to the internet according

of 124
to the results in APPENDIX 3.
The procedure of Installing the MySQL service on the Controller Node is the next step,
as seen in APPENDIX 4.
The procedure next is installing the RabbitMQ service on the Controller Node, as seen in
APPENDIX 5.
The next procedure is about installing NTP service on the Controller Node to
orchestrate the time sync between the servers, as seen in APPENDIX 6.
The next procedure is installing the Identity Service, as seen in APPENDIX 7.
At this point the Identity Service is installed, and we have already configured the
/etc/keystone/keystone.conf file which determines the way Keystone will function, how
it is connected to the database services and trough which endpoints, how does it
manage the admin tokens.
The Database service MariaDB has been configure with a user, and a password
protected root account, through which we created the Keystone tables and granted
privileges on the service.
Now we are going to define the users, tenants, and roles in the Identty Service.
The next step is to install the Image Service (Glance) as seen in APPENDIX 8
The last step is to install the Compute Service (Nova) as seen in the procedures in
APPENDIX 9.
The rest of the steps where to be implemented if there was no issues with the setup and
parameters of the nova.conf file of the Compute Service as seen in APPENDIX 10.

of 124
Redesign and Reimplementationof our cloud
At this point, in conjunction with the iterative methodology adopted in this project, we
are going to Re-plan the Architectural Design approach suggested as initial goal.
During the deployment of the OpenStack Nodes we faced a bug in the installation of an
OpenStack core component (Nova). This reason led us to set new goals, and new
options regarding the Architectural Design, and as a result to adopt the DevStack
Architecture Concept of OpenStack
Setting up DevStack
First of all, it is important to mention that DevStack is a shell script user to deploy a
complete OpenStack development environment. The DevStack script install all the
dependencies required to run OpenStack so there is no need for installing anything
separately.
We opened the console and cloned the devstack repo which contains a script that will
install OpenStack.
We cloned devstack at /home/opstack/devstack.
This command fetched the devstack repo to our local machine.
1. $ git clone https://github.com/openstack-dev/devstack.git
2. Now we found a devstack directory where we cloned the repo
$ cd devstack
3. We run the script to install OpenStack
$ ./stack.sh
The script asked us to enter passwords for the default services enabled in the script.
After it was done it returned a URL for horizon.

of 124
The URL for Horizon is :
http://192.168.100.50/
The Keystone is serving at http://192.168.100.50:5000/v2.0
Default Users are: Admin and Demo
The password is : ubuntu
This is our Host's IP: 192.168.100.50/24
Figure 21 OpenStack Dashboard
Figure 20 Devstack's FinalizedInstallation with Login and Management Info

of 124
We opened that link in our browser and we could acess the OpenStack Dashboard!
By default we got two usernames admin and demo as seen in Figure 23 OpenStack
Dashboard.
The password is the same password set for keystone(which is the identity service
provided by OpenStack) which we can see in the local.config file in the devstack
directory.
#cd /home/opstack/devstack/samples
#vim local.conf
[[local|localrc]]
# Minimal Contents
# ----------------
# While ``stack.sh`` is happy to run without ``localrc``, devlife is better when
# there are a few minimal variables set:
# If the ``SERVICE_TOKEN`` and ``*_PASSWORD`` variables are not set
# here you will be prompted to enter values for them by ``stack.sh``
# and they will be added to ``local.conf``.
SERVICE_TOKEN=azertytoken
ADMIN_PASSWORD=nomoresecrete
MYSQL_PASSWORD=stackdb
RABBIT_PASSWORD=stackqueue
SERVICE_PASSWORD=$ADMIN_PASSWORD
In terms of security we need to turn on Logging in DevStack for maintenance, and
monitoring. The steps are disposed in APPENDIX 11.

of 124
Securing the DevStack Server
SSH Hardening
Once we have installed OpenSSH Server on Devstack by using the command:
#sudo apt-get -y install openssh-server
we will need to configure it by editing the sshd_config file in the /etc/ssh directory.
First of all, we have to make a backup of the original sshd_config file by copying it to
our home directory.
#sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.factory-defaults
and by making it a read-only copy in /etc/ssh by doing:
#sudo chmod a-w /etc/ssh/sshd_config.factory-defaults
Creating a read-only backup in /etc/ssh means that we will always be able to find a
known-good configuration when we need it.
Once we have backed up our sshd_config file, we can make changes with any text
editor, for instance :
#sudo vim /etc/ssh/sshd_config
Configuring OpenSSh means striking a balance between security and ease-of-use.
Ubuntu's default configuration tries to be as secure as possible without making it
impossible to use in common cases.

of 124
Disable Password Authentication
Many people use passwords to secure something, like in our case, SSH. But the
problem stands for that they are weak. That is why many attackers will look for an
SSH server, then start guessing password or even use software tools, with which they
try thousands of passwords in some time. The recommended solution is to user SSH
keys instead of passwords.
These keys are hard to crack, because these keys contain 643 random letters and
numbers.
Because we will always be loging in to this server with an SSH key, we shall disable
password authentication altogether.
To disable password authentication we shall search for the line in /etc/ssh/sshd_config
file :
#PasswordAuthentication yes
and we shall replace it with:
#PasswordAuthentication no
In order to be able to log in to the server with SSH Key, for instance RSA
authentication, we will have first of all to connect to the server from the client just with
#PasswordAuthentication set to yes
#RSAAuthentication set to no
we run the following command on the server :
#ssh-keygen
and as prompted we shall save the key in the file destination:
/root/.ssh/id_rsa
Now we open an unsafe SSH connection from the client to the server, we move to the
/root/.ssh/id_rsa directory and copy the KEY that has been generated.
Then we restart from the already open SSH connection the SSH server.
On our client terminal now, we go to the destination /root/.ssh/ and run the command:
#ls

of 124
#vim known_hosts
Then in the file we add the KEY as generated from the server.
Then we shall restart the service.
#service ssh restart
Test from the Host of the virtual machines to connect to Devstack server:
xhani@xhani:~$ ssh opstack@192.168.100.50
ssh: connect to host 192.168.100.50 port 22: Connection refused
xhani@xhani:~$
Also test from the Host to the Host itself shows up this message:
root@xhani:/home/xhani# ssh -v localhost
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: connect to address 127.0.0.1 port 22: Connection refused
ssh: connect to host localhost port 22: Connection refused
root@xhani:/home/xhani#
So until far, the configurations had a result on both servers.
We can specify which Accounts can use SSH:
We can explicitly allow or deny access to SSH for certain groups or users.
Allowing or denying SSH access for specific users can dramatically increase our
server's security.
To allow only user devstack for example in our server, we shall add the following line
at the bottom of the sshd_config file:
#AllowUsers devstack
or to deny user devstack
#DenyUsers devstack

of 124
Logging is one of the most important things and parts of System Administration.
It is one of the most important tools of a Sys Admin to log everything that is going in or
out and happening inside the system, and even outside of it with certain tools.
Monitoring is one of the best tools, to troubleshoot, to maintain clean systems, or even
to find problems and issues, and figure out where they do stem from.
By default SSH server logs to the AUTH facility of syslog, at the INFO level.
We can read more information if we want to, such as failed log in attempts.
The only thing to do is to change the logging level to VERBOSE.
In the sshd_config file we shall make the following change:
#LogLevel INFO
changes to
#Log Level VERBOSE
Now all of ssh login attempts will be saved in our /var/log/auth.log file.
Firewalls
Most security issue on servers are the ports and this creates a pathway between the
outside world and the server its self, why making all these ports available for access
when they aren’t necessary? We will be using the ufw tools to configure IpTables.
Install the UFW
#sudo apt-get -y install ufw
on installation this package is disabled , we have to enable it:
#sudo ufw enable

of 124
Adding our SSH port quickly will prevent us from the situation of being locked out
from our server and not being able to connect to it if it is a remote connection.
#sudo ufw allow 22
#sudo ufw allow 80
Figure 22 Firewall configurations
We can view list of ports that we have added with :
#sudo ufw remove 1
We can remove or block a port by the following statement:
#sudo ufw remove {port_#}
To make all ports publicly available we can run the command:
#sudo ufw disabled
Disable User Creation:
As a root, disable unauthorized user creation. This will help us as sysadmin to know
users in our system, disable creation of groups and users using:
#chattr +i /etc/passwd && sudo chattr +i /etc/group
if we want to re-enable it we run the command:
#chattr -i /etc/passwd && chattr -i /etc/group
On our two servers the command is passed:
Host server:

of 124
Figure 24 Rule added
Another step would be improving IP Security through the sysctl.d
And through IPtables
We can add lines to /etc/sysctl.d/10-network-security.conf as presented in
APPENDIX 12.
For the configuration of IPtables we have created a specific script file under :
/root/iptablescript.sh as presented in APPENDIX 13.
Then we can check our configurations with the command below:
xhani@xhani:~$ iptable -nL
No command 'iptable' found, did you mean:
Command 'iptables' from package 'iptables' (main)
Command 'ptable' from package 'xcrysden' (universe)
iptable: command not found
xhani@xhani:~$ iptables -nL
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.
xhani@xhani:~$ su
Password:
root@xhani:/home/xhani# iptables -nL
Figure 23 Disable unauthorized user creation

of 124
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
DROP all -- 10.0.0.0/8 0.0.0.0/0
DROP all -- 169.254.0.0/16 0.0.0.0/0
DROP all -- 172.16.0.0/12 0.0.0.0/0
DROP all -- 127.0.0.0/8 0.0.0.0/0
DROP all -- 192.168.0.0/24 0.0.0.0/0
DROP all -- 224.0.0.0/4 0.0.0.0/0
DROP all -- 0.0.0.0/0 224.0.0.0/4
DROP all -- 240.0.0.0/5 0.0.0.0/0
DROP all -- 0.0.0.0/0 240.0.0.0/5
DROP all -- 0.0.0.0/8 0.0.0.0/0
DROP all -- 0.0.0.0/0 0.0.0.0/8
DROP all -- 0.0.0.0/0 239.255.255.0/24
DROP all -- 0.0.0.0/0 255.255.255.255
DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x04/0x04 limit: avg 2/sec
burst 2
DROP all -- 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 86400 name:
portscan side: source mask: 255.255.255.255
all -- 0.0.0.0/0 0.0.0.0/0 recent: REMOVE name: portscan side: source
mask: 255.255.255.255
LOG tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:139 recent: SET name: portscan
side: source mask: 255.255.255.255 LOG flags 0 level 4 prefix "portscan:"
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:139 recent: SET name: portscan
side: source mask: 255.255.255.255
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

of 124
Chain FORWARD (policy ACCEPT)
DROP all -- 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 86400 name:
portscan side: source mask: 255.255.255.255
all -- 0.0.0.0/0 0.0.0.0/0 recent: REMOVE name: portscan side: source
mask: 255.255.255.255
LOG tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:139 recent: SET name: portscan
side: source mask: 255.255.255.255 LOG flags 0 level 4 prefix "portscan:"
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:139 recent: SET name: portscan
side: source mask: 255.255.255.255
Chain OUTPUT (policy ACCEPT)
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8
root@xhani:/home/xhani#

of 124
Apache Hardening
Apache hardening
The following parameters set in /etc/apache2/conf-enabled/security.conf make can reassure
and guarantee the smooth and efficient web server functionality.
ServerTokens Prod
ServerSignature Off
TraceEnable Off
Header unset ETag
FileETag None
For these to take effect we enabled mod_headers:
ln -s /etc/apache2/mods-available/headers.load /etc/apache2/mods-enabled/headers.load
Then restarted Apache:
service apache2 restart
We Installed and configured ModSecurity
If you're using Apache, the web application firewall ModSecurity is a great way to harden
your web server so that it's much less vulnerable to probes and attacks. Firstly,we installed
the necessary packages:
apt-get install libapache2-mod-security2
We enabled the recommended configuration:
Mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
Then we edited /etc/modsecurity/modsecurity.conf:
1. Set SecRuleEngine to On to activate the rules.
2. Change SecRequestBodyLimit and SecRequestBodyInMemoryLimit to 16384000 (or
higher as needed) to increase the file upload size limit to 16 MB.

of 124
Next,we installed the Open Web Application Security Project Core Rule Set:
cd /tmp
wget https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/master.zip
apt-get install zip
unzip master.zip
cp -r owasp-modsecurity-crs-master/* /etc/modsecurity/
mv /etc/modsecurity/modsecurity_crs_10_setup.conf.example
/etc/modsecurity/modsecurity_crs_10_setup.conf
ls /etc/modsecurity/base_rules | xargs -I {} ln -s /etc/modsecurity/base_rules/{}
/etc/modsecurity/activated_rules/{}
ls /etc/modsecurity/optional_rules | xargs -I {} ln -s /etc/modsecurity/optional_rules/{}
/etc/modsecurity/activated_rules/{}
To add the rules to Apache, we edited /etc/apache2/mods-available/security2.conf and added
the following line near the end, just before </IfModule>:
Include "/etc/modsecurity/activated_rules/*.conf"
Then finally we restarted the Apache2 service so that the changes would take into effect.
Installing and configuring mod_evasive
Mod_evasive is a great tool in order to avoid, to protect a web server from DoS attacks.
Firstly we installed the package:
#apt-get install libapache2-mod-evasive
Next, we set up the log directory:
mkdir /var/log/mod_evasive
chown www-data:www-data /var/log/mod_evasive
We Configured it by editing /etc/apache2/mods-available/evasive.conf:

of 124
1. Uncomment all the lines except DOSSystemCommand.
2. Change DOSEmailNotify to your email address.
We Linked the configuration to make it active in Apache:
ln -s /etc/apache2/mods-available/evasive.conf /etc/apache2/mods-enabled/evasive.conf
Then we activated it by restarting Apache:
Installing RKHunter
To install Rkhunter we run the command:
#sudo apt-get install rkhunter
Before running Rkhunter we needed to fill the file properties database by running the
following command: rkhunter –propupd.
If this command is not run then every time a software is installed or a software
update takes place on the server, then the Rkhunter will provide “false positive”
alerts.
#sudo rkhunter - - propupd
we shall run rkhunter - - propupd, automatic after software updates. This can be
achieved by adding the line :
#APT_AUTOGEN=”yes”
In the /etc/default/rkhunter file.
On the Host machine we run the

of 124
#sudo rkhunter - -checkall
and the results were all complete
a small portion of the results is shown below:
System checks summary
=====================
File properties checks...
Files checked: 140
Suspect files: 1
Rootkit checks...
Rootkits checked : 307
Possible rootkits: 0
Applications checks...
All checks skipped
The system checks took: 4 minutes and 34 seconds
All results have been written to the log file (/var/log/rkhunter.log)
Performing system configuration file checks
Checking for SSH configuration file [ Found ]
Checking if SSH root access is allowed [ Warning ]
Checking if SSH protocol v1 is allowed [ Not allowed ]
Checking for running syslog daemon [ Found ]
Checking for syslog configuration file [ Found ]
Checking if syslog remote logging is allowed [ Not allowed ]
Performing filesystem checks

of 124
Checking /dev for suspicious file types [ Warning ]
Checking for hidden files and directories [ Warning ]
In order to remove these warnings we shall edit the rkhunter config file by
whitelisting them:
we edited the file : /etc/rkhunter.conf and remove the # symbol before the lines:
#ALLOWHIDDENDIR=/dev/.
udev
static
initramfs
ALLOWHIDDENDIR=/dev/.
udev
static
initramfs
We have allowed some directories to be allowed:
Figure 25 Removing Rkhunter Warning through configuration

of 124
Installing OSSEC Server
Installing OSSEC IDS/IPS
OSSEC Architecture see at Figure 107.
(“ossec-arch2.jpg (JPEG Image, 1100 × 630 pixels) - Scaled (52%),” n.d.)
OSSEC is composed of multiple pieces. It has a central manager for monitoring and receiving
information from agents, syslog, databases, and from agentless devices.
Manager(Server)
The manager is the central piece of the OSSEC deployment. It stores the file integrity
checking databases, the logs, events, and system auditing entries. All the rules, decoders, and
major configuration options are stored centrally in the manager; making it easy to administer
even a large number of agents.
Agents
The agent is a small program, or collection of programs, installed on the systems to be
monitored. The agent will collect information and forward it to the manager for analysis and
correlation. Some information is collected in real time, others periodically. It has a very small
memory and CPU footprint by default, not affecting the system’s usage.
Agent security: It runs with a low privilege user (generally created during the installation) and
inside a chroot jail isolated from the system. Most of the agent configuration can be pushed
from the manager.
Agentless
For systems that an agent cannot be installed on, the agentless support may allow integrity
checks to be performed. Agentless scans can be used to monitor firewalls, routers, and even

of 124
Unix systems.
The OSSEC server part will be installed on the Host Machine.
In order to compile and install OSSEC we need to install some packages for Ubuntu
first in order to be sure about the completion of the procedures.
We run :
#apt-get install build-essential
#apt-get install mysql-devel postgre-devel
Then we can go and download the files running the command:
#wget -U ossec http://www.ossec.net/files/ossec-hids-2.8.1.tar.gz
Figure 26 OSSECArchitecture

of 124
# tar -zxvf ossec-hids-latest.tar.gz
Entering the source directory of the downloaded package.
# cd ossec-hids-*
# ./install.sh
Then we can start OSSEC by running :
# /var/ossec/bin/ossec-control start
Adding the OSSEC Agent on the Server
Installing OSSEC Agent
****************************************
* OSSEC HIDS v2.8 Agent manager. *
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q: A
- Adding a new agent (use 'q' to return to the main menu).
Please provide the following:
* A name for the new agent: 010
* The IPAddress of the new agent: 192.168.100.50
* An ID for the new agent[002]: 010
Agent information:

of 124
ID:010
Name:010
IPAddress:192.168.100.50
Confirm adding it?(y/n): y
Agent added.
Extracting the Key for the New Agent
* OSSEC HIDS v2.8 Agent manager. *
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q: E
Creating key for Agent
Available agents:
ID: 010, Name: 010, IP: 192.168.100.50
Provide the ID of the agent to extract the key (or 'q' to quit): 010
Agent key information for '010' is:
MDEwIDAxMCAxOTIuMTY4LjEwMC41MCBhYjJhMTFkZWZjZDBmOWJjOTcxY
jI3ZGMxYjI2ZWEyNjFiY2M4NGYwYTJjYmZmMjk0ZGNhNTA1NTFhOWRiNzkz
** Press ENTER to return to the main menu.
The same procedure is on the DevStack server too.

of 124
After installation of OSSEC on both sides, Server andAgent , we start the IDS
by running :
#/var/ossec/bin/ossec-control start
The Configurations on both sides respectively are shown in APPENDIX 15
Additional / Extra features of OSSEC
GeoIP Location
According to the release notes of OSSEC 2.7 (http://www.ossec.net/files/ossec-hids-2.7-
release-note.txt) there is the support for for GeoIP lookup using Maxmind database and API
(xavier), GeoIP database lookup for src/dst IP addresses, converting non-private IP addresses
to city names.
For a future expansion of the security of our Cloud, the GeoIP location would be the very
first candidate to be studied and deployed.
Testing
Testing Scenario 1: (SQLmap)
The first scenario of attack against our cloud is to be conducted by sqlmap tool.
According to (“Sqlmap tutorial for beginners – hacking with sql injection,” n.d.)
Sqlmap is one of the most popular and powerful sql injection automation tool out there.
Given a vulnerable http request url, sqlmap can exploit the remote database and do a lot of
hacking like extracting database names, tables, columns, all the data in the tables etc. It can
even read and write files on the remote file system under certain conditions. Written in
python it is one of the most powerful hacking tools out there. Sqlmap is the metasploit of sql

of 124
injections.
Sqlmap is included in pen testing linux distros like kali linux, backtrack, backbox etc.
The first attempt to attack our Dashboard's website, was conducted with the following
command from the Kali Linux Virtual Machine, through command line.
#sqlmap -u “http://192.168.100.50”
This command checks the input parameters to find if they are vulnerable to sql injection or
not.
Another testing command prompt was added in the evaluation of the security of DevStack's
database system if under the web interface of Horizon there would be a breach in the database
service.
This command would provide us with database tables, if there was a breach in the dashboard
service.
This is the command:
#sqlmap -u "http://www.sitemap.com/section.php?id=51" --dbs
#sqlmap –u http://192.168.100.50 - -dbs
The results, after the security enhancements we have done on our servers is crucial for the
availability and trustworthy functionality of our cloud.
RESULTS in APPENDIX 15
Testing Scenario 2: (THC-HYDRA)
Another testing command prompt was added in the evaluation of the security of DevStack's
database system if under the web interface of Horizon there would be a breach in the database
service.
This command would provide us with database tables, if there was a breach in the dashboard

of 124
service.
This is the command:
#sqlmap -u "http://www.sitemap.com/section.php?id=51" --dbs
RESULTS in APPENDIX 15
Conclusion
The concept of this dissertation is to present the Cloud Computing that is gaining ground
rapidly, and the technologies supporting it which are becoming more and more powerful,
complex, secure and scalable. The Cloud concept and Cloud Security is all about the
unification of hundreds, thousands, and even more components, that work altogether and
provide the services that are meant to be provided. Securing a Cloud is not flat in architecture
like one of a server, but it is more complex, needing more study and research in order to
achieve security over a cloud. Among millions of security products being used around the
world, as well as Cloud Management Systems, no one is capable of stating exactly and
presenting the best security strategy to be deployed within a Cloud. There does not exist a
best strategy, but only best tactics including the collaboration of many security systems with
each other. This is because the laws of nature, can also be applied in the fields of Information
Technology. By this we mean that, when we want to bend a single wooden stick, then it is
possible to bend it and even break it. But when we want to bend twenty wooden sticks at
once then it is impossible to break them or even bend them in the best scenario.
So in other words, securing a cloud, requires open-minded security engineers, system
administrators, etc, and eager to study, contradict or agree, and implement other security
mechanisms, technologies, and products, in order to create a fortified Cloud environment,
with sustainability, high availability, and upon most, high security to its clients.
But this is the beauty of Cloud Computing. Cloud System, in terms of security, has to be
fortified by additional security systems, in order to protect the aims for what it was built, for
example, to service data services, storage services, computational power, and even clusters of
data centers and simultaneously security enhancement for the clients.
Each and every component of a Cloud system, has to be studied separately, due to the
differentiation among the nature, and the purpose of each of them. And after extracting the
conclusions of what shall be the security design for each component, regarding its purpose
then next is the step of implementing bearing in mind each purpose aforementioned, and the
overall Cloud’s purpose.
Cloud computing is the edge of technology nowadays, and it will be for many decades to
come, as it is a lead player in the world market regarding analytics (“Hybrid Cloud Market by

of 124
Solution, by Service Model, by Region – Global Forecast to 2019,” n.d.). Simultaneously,
security moves forward leaping, side by side with Cloud advancements. Nevertheless, side by
side with security advancements unethical hacking, also, flourishes, which means that new
security threats emerge day by day, requiring immediate action.
This means that, except of studying, researching about new security threats, information
security engineers, system administrators, IT managers, etc, also need to test their computing
environments, by legal means and ethical hacking, attacking their systems, on every security
system and strategy deployed. This is a procedure of Designing, Deploying, Testing,
Evaluating the results of the attacks on the own systems.
Every node deployed to provide services of a Cloud System, has to be meticulously designed
and fortified, in terms, of security policies on the server itself, as well as in terms of security
policies implemented on the Cloud Components.
In conclusion, this is what we meant above, stating the non-flat architecture of a Cloud
systems’ security, that a two way security philosophy shall be taken into consideration. A two
way philosophy, by building a strong foundation between the Cloud Components and the
physical server, such as in our thesis, which relies on the security enhancements of the server
hosting the Cloud System. This is the scope of this thesis, although, there are many more,
topics to be studied and researched, such as regarding group-based policies (“Group-Based
Policy for OpenStack - white-paper-c11-733126.pdf,” n.d.) for OpenStack, or access control
and identity management concepts (“OpenStack Docs: Security Guide,” n.d.).
Future work
The topic of this thesis, has a broad range of study fields, regarding security countermeasures,
and security evaluations. The scope of this thesis was to implement a Private Cloud System,
and secure the Nodes hosting the OpenStack services. Nevertheless, there is another field of
extensive research that shall be done in future, regarding the security concepts and
architectures of OpenStack system itself as well as their deployment.
The Cloud System that could be deployed, in accordance to this thesis, and the future
research mentioned above, could also be deployed not only on a test environment, but also on
a real productive environment, such as in our University facilities. This would be a private
Cloud System exclusively dedicated to students of our University here in Athens, which
would give them personal space on the Cloud to save their works, share documents with each
other, and even experiment on the new emerging technologies of Cloud Computing. Yes,
cloud computing is evolving rapidly, and becoming a part of our life, making our tasks easier,
communicating and getting in contact with people easily, learning, working, and many other
great things.

of 124
APPENDIX
APPENDIX 1
Configure Controller Node
The controller node has two Network Interfaces : eth0 (is external, routed to Virtual
Machine Host to eth0- 192.168.100.0/24) and eth1 (used for management network).
After logging in the system:
Change to Super use mode:
# sudo su
Set the hostname of our server:
# vim /etc/hostname
Controller
Edit the /etc/hosts file by adding the following lines, so that controller node can resolve
hostnames with their IP addresses
First of all Remove or Comment the line beginning with 127.0.0.1.
#controller
10.0.0.11 controller
#network
10.0.0.21 network
#10.0.0.31 compute
And it looks fine on the controller node:
Edit network settings to configure the interfaces eth0 and eth1:
Figure 27 Hosts configuration on Controller

OPEN SOURCE PRIVATE CLOUD MANAGEMENT WITH OPENSTACK AND SECURITY EVALUATION

OPEN SOURCE PRIVATE CLOUD MANAGEMENT WITH OPENSTACK AND SECURITY EVALUATION

Recommended

Recommended

More Related Content

Similar to OPEN SOURCE PRIVATE CLOUD MANAGEMENT WITH OPENSTACK AND SECURITY EVALUATION

Similar to OPEN SOURCE PRIVATE CLOUD MANAGEMENT WITH OPENSTACK AND SECURITY EVALUATION (16)

Recently uploaded

Recently uploaded (20)

OPEN SOURCE PRIVATE CLOUD MANAGEMENT WITH OPENSTACK AND SECURITY EVALUATION