1. Anomaly Analysis of OpenStack
Firewall Policies
Ciaran McDonald
112353056
Final Year Project - BSc in Computer Science
Supervisors: Dr Simon Foley & Mr Ultan Neville
Department of Computer Science
University College Cork
April 2016
2. Abstract
OpenStack is an open-source cloud operating system. It provides Infrastructure-as-
a-Service through a collection of interrelated projects/services. These services are
used to manage pools of compute, storage, and networking resources throughout
a data-centre. Network Access Control is provided by a combination of security
group policies and perimeter firewall policies. Anomalies can arise in the definition
of these policies whereby the objective of one policy rule may conflict with another.
These anomalies are comparable to shadowing and redundancy anomalies in firewall
policies. The outcome of this project is a testbed and set of tools that are used to
help an OpenStack administrator identify such anomalies and manage the policies.
3. Declaration of Originality
In signing this declaration, you are conforming, in writing, that the submitted work
is entirely your own original work, except where clearly attributed otherwise, and
that it has not been submitted partly or wholly for any other educational award.
I hereby declare that:
• this is all my own work, unless clearly indicated otherwise, with full and proper
accreditation;
• with respect to my own work: none of it has been submitted at any educational
institution contributing in any way to an educational award;
• with respect to another’s work: all text, diagrams, code, or ideas, whether
verbatim, paraphrased or otherwise modified or adapted,have been duly at-
tributed to the source in a scholarly manner, whether from books, papers,
lecture notes or any other student’s work, whether published or unpublished,
electronically or in print.
Signed:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Date: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Acknowledgements
A special thank you to my supervisors, Dr Simon Foley and Mr Ultan Neville.
They provided amazing guidance and support throughout the project. The weekly
meetings I attended with both of them, gave me clear direction on how the project
was progressing and how to achieve the end objectives. Mr Neville also answered
any questions I had between meetings through email which was pivotal on keeping
the project on course.
13. 1.1 Introduction
1.1.1 Introduction
In recent years networks have became larger and more complex with many new ser-
vices being accessible online. This is the result of the transition to cloud computing
and Infrastructure as a Service. Security policies that allow or deny access to these
services have to be implemented correctly to protect these services against malicious
users. In this report we will present the different problems that can occur, if these
policies are not implemented correctly. We also designed and implement tools to
identify these problems.
1.1.2 Network Access Control
Network Access Control aims to do exactly what the name implies, control access to
a network by implementing a policy that either allows or denies access to a network
[25]. In this report we research how a Perimeter Firewall implements Network Access
Control. The Perimeter Firewall implements a policy which contains a set of rules.
When a piece of Internet traffic enters the Perimeter Firewall it’s compared against
each rule within the policy in sequence. If the traffic matches a rule within the
policy, the traffic is either allowed to pass through the Perimeter Firewall into the
network or it’s dropped. If a piece of Internet traffic doesn’t match any rule its
best practice to automatically drop the packet. In this report we investigate how
anomalies occur within a Perimeter Firewall Policy when it’s misconfigured. We also
investigate how anomalies occur between a Perimeter Firewall Policy and Security
Group Policies, when they are misconfigured.
1.1.3 Host Based Access Control
Host Based Access Control aims to control access to a host by implementing policies
that either allow or deny access to the host. In this report we research how Security
Groups implement Host Based Access Control. Each Security Group implements
a policy which contains a set of rules. When a piece of Internet traffic enters a
Security Group it’s compared against each rule within the policy in sequence. If the
traffic matches a rule within the policy, the traffic is either allowed to pass through
the Security Group and access the host or it is dropped. If a piece of Internet
traffic doesn’t match any rule its automatically drops the packet. In this report
we investigate how anomalies occur within Security Group policies when they are
misconfigured. We also investigate how anomalies occur between Security Group
Policies and between a Perimeter Firewall Policy, when they are misconfigured.
3
14. 1.1.4 Anomalies
Anomalies can occur within a network, if a firewall or multiple firewall policies have
been misconfigured by an administrator. This misconfiguration can lead to traffic
been dropped and not reaching its intended destination. Also unintended traffic
might be allowed to reach a destination. Rules within a policy might be redundant,
shadowed or generalised by another rule within that policy because a previous rule
within the policy might have already matched the traffic and performed an allowed
or denied action on the traffic. In this report we investigate the different types of
anomalies that can occur within these policies or between policies. We will then
develop tools to identify these anomalies so that an administrator can remove them.
1.1.5 OpenStack
OpenStack is a free and open-source software platform for cloud computing, mostly
deployed as an Infrastructure as a Service (IaaS). OpenStack software controls large
pools of compute, storage and networking resources throughout a datacenter, man-
aged through a dashboard or via the OpenStack API[26]. OpenStack provides Net-
work Access Control on its networks by implementing a Perimeter Firewall and
provides Host Based Access Control by implementing Security Group Policies. In
this report we will define the different anomalies that can occur within these policies
and across these policies if they are misconfigured.
1.1.6 Project Aims
A Testbed Network will be designed and implemented to demonstrate a sample
network. Different services will be deployed within this network and these include
a Web, Chat, Mail and File Server. Each services will have its own Security Group
Policy which is a set of IP filter rules, which determines if an IP packet will be either
allowed or denied access to the service. The Testbed Network will have a Perimeter
Firewall which will contain a set IP tables rules and will sit on the edge of the
network. The Perimeter Firewall will either allow or deny IP traffic from accessing
the network.
The aim for this project is to investigate anomalies that occur within or between
Perimeter Firewall and Security Group Policies. Tools will be developed that will
perform Anomaly Analysis on these policies and look for inconsistencies within an
OpenStack Testbed Network. The tools will interact with the OpenStack Neutron
Service which is the Networking Service within OpenStack. The aim is to build a set
of tools which will help an OpenStack Administrator identify such anomalies and
manage the policies.
4
16. 2.1 Firewalls
2.1.1 Firewall Definition
One of the earliest definitions of a firewall[2] is that it is a collection of components
placed between two networks that collectively have the following properties:
1. All traffic from inside to outside and vice-versa, must pass through the firewall.
2. Only authorised traffic as defined by the local security policy, will be allowed
to pass.
3. The firewall itself is immune to penetration[5].
2.1.2 Firewall Rule
A firewall rule takes the form of a series of conditions on packet fields that must be
met in order for that rule to be applicable along with a consequent action for the
matching packet[5].
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.024 60:80 10.0.0.424 24:26 allow
Table 2.1: Example Firewall Rule
2.1.3 Firewall Policy
A firewall policy is a collection of firewall rules, given in sequence[5].
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.024 60:80 10.0.0.424 24:26 allow
2 TCP 0.0.0.024 60:80 10.0.0.424 24:26 allow
3 TCP 0.0.0.032 60:80 10.0.0.424 24:26 allow
Table 2.2: Example Firewall Policy
2.1.4 Default Firewall Configuration Policy
Rules are tested in the order in which they appear in the firewall policy (table).
Once a packet has been successfully matched against a rule, no further rule tests
are carried out for that packet.
If the packet fails to be matched against any of the rules then the firewall imposes
a default policy/rule which can be either:
1. Default Deny: everything is denied except that which is explicitly permitted.
2. Default Allow: everything is permitted except that which is explicitly denied[5].
6
17. 2.1.5 Management of a Firewall Configuration
Management is complex and error prone:
• Large number of rules (often) across multiple subnets implemented by hetero-
geneous firewall mechanisms.
Misconfiguration may result in:
• a firewall configuration that does not uphold the network security require-
ments.
Proper configuration is largely dependent on the expert knowledge of the security
administrator drawing upon best practice and standards[4].
2.1.6 Firewall Rule Semantics
Cannot consider the semantics (meaning) of a rule in isolation.
• Must consider a rule in the context of previous rules.
• Rules are order dependent.
• The order/sequence of rules governs the overall semantics of the firewall configuration[4].
2.1.7 Structural Analysis
Structural Analysis examines the relationship that rules have with one another
within a firewall configuration or accross multiple firewall configurations.
• A conflict occurs when two or more rules that are seemingly different match
the same packet.
• While the individual rules themselves may be consistent with a network se-
curity policy, a rule placed out of sequence may unintentionally change the
intended meaning of the firewall configuration and thus, be inconsistent with
the network security policy.
These firewall structural conflicts are also known as firewall anomalies[4].
2.1.8 Firewall Anomalies
Conflicts will occur within in a network when either one or both of the following
scenarios happen:
1. Intra-Conflicts: occur between rules on a single firewall
2. Inter-Conflicts: occur between rules across different firewalls[5].
There are specific anomalies that can occur within each scenario that has been
defined in ”Taxonomy of Conflicts in Network Security Policies”[1]. We will use the
definitions in ”Taxonomy of Conflicts in Network Security Policies”[1] paper as the
backbone of our anomaly analysis. In Chapter 4 we will define these anomalies and
how they occur within the network.
7
18. 2.2 OpenStack
OpenStack is a free and open-source software platform for cloud computing, mostly
deployed as an infrastructure-as-a-service (IaaS)[26]. OpenStack software controls
large pools of compute, storage, and networking resources throughout a datacenter.
This is managed through a dashboard or via the OpenStack API. The OpenStack
Mission is to produce the ubiquitous Open Source Cloud Computing platform that
will meet the needs of public and private clouds regardless of size, by being simple to
implement and massively scalable. OpenStack is open source, it is openly designed
and developed by an open community[14]. This project will focus on the OpenStack
Networking Service Neutron.
Figure 2.1: OpenStack [14]
2.2.1 Neutron
OpenStack Networking is a system for managing networks and IP addresses. Open-
Stack Networking ensures the network is not a bottleneck or a limiting factor in a
cloud deployment and gives users self-service ability, even over network configurations[26].
OpenStack Networking provides networking models for different applications or
user groups. Standard models include flat networks or VLANs that separate servers
and traffic. OpenStack Networking manages IP addresses, allowing for dedicated
static IP addresses or DHCP. Floating IP addresses allow traffic be dynamically
rerouted to any resource in the IT infrastructure. This allows users to redirect
traffic during maintenance or in case of a failure[26].
Users can create their own networks, control traffic, along with connecting servers
and devices to one or more networks. Administrators can use software defined net-
working (SDN) technologies like OpenFlow to support high levels of multi-tenancy
and massive scale. OpenStack Networking provides an extension framework that can
deploy and manage additional network services such as intrusion detection systems
(IDS), load balancing, firewalls (FWaaS), and virtual private networks (VPN)[26].
8
19. 2.2.2 OpenStack Firewall as a Service
Perimeter Firewall
The OpenStack Neutron Service provides Network Access Control by implementing
FWaaS (FireWall-as-a-Service) which is a Neutron Service extension that introduces
a firewall feature set[10].
The Firewall-as-a-Service (FWaaS) plug-in adds Perimeter Firewall management
to OpenStack Networking (Neutron Service). FWaaS uses iptables to apply a firewall
policy to all virtual routers within a project, supports one firewall policy and logical
firewall instance per project. FWaaS operates at the perimeter by filtering traffic
at the OpenStack Networking (Neutron Service) router. This distinguishes it from
security groups, which operate at the instance level[18].
Perimeter Firewall Structure
The Perimeter Firewall is a key component when achieving Network Access Control.
The rules defined within the Perimeter Firewall Policy will allow or deny traffic
from entering the network. To define a Perimeter Firewall Rule an OpenStack
administrator has to set six key attributes, these attributes are:
1. IP Protocol: Specifies the Type of traffic this rule applies to.
2. Source IP: Specifies the Source IP Range of traffic this rule applies to.
3. Source Port: Specifies the Source Port Range of traffic this rule applies to.
4. Destination IP: Specifies the Destination IP Range of traffic this rule applies
to.
5. Destination Port: Specifies the Destination Port Range of traffic this rule
applies to.
6. Action: Specifies what action should be taken if traffic matches this specific
rule. The action is either denied or allowed.
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.024 60:80 10.0.0.424 24:26 allow
2 TCP 0.0.0.024 60:80 10.0.0.424 24:26 allow
3 TCP 0.0.0.032 60:80 10.0.0.424 24:26 allow
4 TCP 0.0.0.028 60:80 10.0.0.424 24:26 allow
5 TCP 0.0.0.024 100:140 10.0.0.524 5260:5280 deny
5 TCP 0.0.0.032 120:140 10.0.0.532 5260:5280 allow
Table 2.3: Sample Perimeter Firewall Policy
When a packet enters the Perimeter Firewall above it’s compared to each rule
in the Perimeter Firewall Policy in sequence. If the packet matches a rule in the
Perimeter Firewall an action is performed on the packet that is specified by the
matching Perimeter Firewall Rule.
9
20. 2.2.3 Nova
OpenStack Compute (Nova) is a cloud computing fabric controller, this is the main
part of an IaaS system. It is designed to manage and automate pools of computer
resources and can work with widely available virtualisation technologies, as well as
bare metal and high performance computing (HPC) configurations[26].
Instances
Instances are the individual virtual machines that run on physical compute nodes
inside the cloud. Users can launch any number of instances from the same image.
Virtual machine images contain a virtual disk that holds a bootable operating system
on it. Disk images provide templates for virtual machine file systems. The image
service controls image storage and management.
Each launched instance runs from a copy of the base image. Any changes made
to the instance do not affect the base image. Snapshots capture the state of an
instances running disk. Users can create a snapshot, and build a new image based
on these snapshots. The Compute service controls instance, image, snapshot storage
and management.
When you launch an instance you must choose a flavor, which represents a set of
virtual resources. Flavors define virtual CPU number, RAM amount available and
ephemeral disks size. Users must select from the set of available flavors defined on
their cloud. OpenStack provides a number of predefined flavors that you can edit
or add to[11].
2.2.4 OpenStack Security Groups
Security Groups
The OpenStack Neutron Service provides Host Based Access Control by implement-
ing Security Groups. A Security Group is a policy that contains a set of IP filter
rules that are applied to a project instance, this defines networking access to the
instance.
Security Group rules are project specific; An OpenStack administrator can edit
the default rules for their group and add new rule sets. All projects have a default
Security Group which is applied to any instance that has no other defined Security
Group. Unless you change the default, this Security Group denies all incoming
traffic and allows only outgoing traffic to your instance[13].
An OpenStack administrator can define a set of IP filter rules to allow traffic
to enter (Ingress) and leave (Egress) the Security Group. The Security Group IP
filtering rules have a different structure in contrast to the IP filtering rules contained
within the FWaaS.
10
21. Security Group Structure
Security Groups are critical when achieving Host Based Access Control. The rules
defined within Security Group Policy which will allow or deny traffic from entering
or leaving a instance. To define a Security Group Rule an OpenStack administrator
has to set five key attributes, these attributes are:
1. Direction: Specifies the direction of the traffic that this rule applies to.
2. Ethernet Type: Specifies whether the rule applies to IPv4 or IPv6 traffic.
3. IP Protocol: Specifies the Type of traffic this rule applies to.
4. Port Range: Specifies the Destination Port Range if the traffic is entering
the Security Group. In contrast it specifies the Source Port Range if the traffic
is leaving Security Group.
5. Remote IP Prefix: Specifies the Source IP Range if the traffic is entering
the Security Group. In contrast it specifies the Destination IP Range if the
traffic is leaving the Security Group.
Rule Direction Ethernet Type IP Protocol Port Range Remote IP Prefix
1 Ingress IPv4 TCP 15:22 0.0.0.0/24
2 Ingress IPv4 TCP 20:22 0.0.0.0/32
3 Ingress IPv4 TCP 21:21 0.0.0.0/24
4 Ingress IPv4 TCP 22:22 0.0.0.0/24
5 Ingress IPv4 TCP 143:143 0.0.0.0/24
4 Egress IPv4 TCP 10:150 0.0.0.0/24
Table 2.4: Sample Security Group Policy
When a packet enters the File Server Security Group above it’s compared to each
rule in the File Server Security Group Policy in sequence. If the packet matches a
rule in the File Server Security Group and the rule has a direction ingress, then the
packet is allowed to access the instance. If the packet doesn’t match a rule in the
Security Group it is dropped. The same process is applied if a packet is leaving the
instance through the Security Group and the packet matches a egress rule, then the
packet is allow to leave the instance, otherwise the packet is dropped.
2.2.5 OpenStack Python SDK
The OpenStack Python Software Development Kit (SDK) is used to write Python
automation scripts that create and manage resources in your OpenStack cloud.
The SDK implements Python bindings to the OpenStack API, which enables you
to perform automation tasks in Python by making calls on Python objects. All
OpenStack command-line tools are implemented using the Python SDK[15].
11
22. 2.2.6 OpenStack Command Line Interface
Each OpenStack project provides a command-line client, which enables you to access
the project API through easy-to-use commands. For example, the Compute service
provides a nova command-line client. You can run the commands from the command
line or include the commands within scripts to automate tasks. If you provide
OpenStack credentials such as your user name and password, you can run these
commands on any computer. As a cloud end user, we can use the OpenStack
Dashboard to provision resources within the limits set by administrators[8].
2.2.7 Devstack
DevStack is an opinionated script which quickly creates an OpenStack development
environment. DevStack is ideal for potential users who want to see what the Dash-
board looks like from an admin or user perspective along with OpenStack contrib-
utors wanting to test against a complete local environment[14]. With the hardware
available for this project, the normal distribution of OpenStack does not suit the
needs of the project. In contrast DevStack allows a user to install OpenStack on
their local machine in a all in one configuration which is perfect for a project such
as this[9].
2.3 Programming Language
When selecting the Programming Language we looked at different programming
languages such as Java and Python. We decided that Python would be the correct
choice because the OpenStack Python SDK already existed. This meant that there
were pre-existing Python functions in the OpenStack Python SDK to interact with
the OpenStack Services. Python was the clear choice for implementing the project
over Java which did not have these benefits. Python had to be studied so that we
could implemented the project.
2.3.1 Python
Python is a widely used high-level, general-purpose, interpreted, dynamic program-
ming language. Its design philosophy emphasizes code readability and its syntax
allows programmers to express concepts in fewer lines of code than would be possi-
ble in languages such as C++ or Java. The language provides constructs intended
to enable clear programs on both a small and large scale[27].
12
23. 2.4 Virtual Machine
It is recommended not to create an OpenStack development environment within your
local OS, but within a virtual machine. This is because the installation and also in
the event that the environment crashes which could cause unintended side effects
within you local OS. We researched the different virtualisation software available and
decided that VirtualBox was the best free virtualisation software on the market.
2.4.1 VirtualBox
VirtualBox is a free and open-source hypervisor for x86 computers from Oracle
Corporation. VirtualBox may be installed on a number of host operating systems,
including: Linux, OS X, Windows, Solaris and OpenSolaris. It supports the cre-
ation and management of guest virtual machines running versions and derivations
of Windows, Linux, BSD, OS/2, Solaris, Haiku, OSx86 and others, and limited
virtualisation of OS X guests on Apple hardware[29].
2.5 Virtual Operating System
We require a operating system for the virtual machine. It is recommended DevStack
should run in any virtual machine running a supported Linux release[9]. There is
multiple different Linux distributions available, Ubuntu was selected as the operating
system of choice because it’s widely used for OpenStack development[20].
2.5.1 Ubuntu
Ubuntu is a Debian-based Linux operating system and is distribution for personal
computers, smartphones and network servers. It uses Unity as its default user
interface. Ubuntu releases updated versions of the OS every six months and each
release receives free support for nine months. This support includes security fixes,
high-impact bug fixes and conservative, substantially beneficial low-risk bug fixes.
The first release was in October 2004[28].
13
24. 2.6 Project Objectives
Using the tools detailed in this chapter, the objectives of the project are as follows:
• Design and implement a Testbed that will be used as the project test case.
• Design and implement Discovery Agents to access the Perimeter Firewall Pol-
icy and Security Group Policies from the Neutron Service and store them in a
database.
• Design and implement Anomaly Analysis Tools that will perform analysis on
the Perimeter Firewall Policy and Security Group Policies within the database.
It will determine if there are Intra or Inter Anomalies within the network. If
Anomalies are identified, store these within a database.
• Design and implement a tool which will output these anomalies to an Open-
Stack Administrator so that it can help them manage the policies.
14
26. 3.1 Testbed Creation Overview
A Testbed is required to be implemented so that the Anomaly Analysis Tools can
perform analysis. We will see, that there is several steps to create a Testbed within
OpenStack.
3.2 Virtual Machine Installation
As discussed in Section 2.4 it is recommend that if you are installing OpenStack on
your personal machine, that you install OpenStack within a virtual machine so that
the installation doesn’t unintentionally change settings within your local machine.
3.2.1 Installation of VirtualBox
The installation process for VirtualBox is quite simple. You navigate to Virtual-
Boxes website and download the current version of VirtualBox for your system.
Once the download and the installer is completed. Open VirtualBox and you’re
presented with the GUI in Figure 3.1[21].
Figure 3.1: VirtualBox
16
27. 3.3 Ubuntu Installation
As discussed in Section 2.5 OpenStack recommends Ubuntu to be used as the OS
that OpenStack is installed on. VirtualBox supports Ubuntu as a virtual machine
within it’s software and was chosen as the Linux Distribution[9].
3.3.1 Ubuntu Virtual Machine
The setup of the Ubuntu virtual machine is also a simple process. You navigate
to Ubuntu’s website and download the latest version of the distribution[28]. We
create a new virtual machine using the downloaded distribution. We assign the
virtual machine a name, ram and hard disk space. We can also change the amount
of processors we assign to the machine and once that’s complete, one can setup an
virtual machine within VirtualBox as displayed in Figure 3.1.
Then power on the virtual machine and let the Ubuntu installer execute. Once
the installer is complete we have a running Ubuntu Distribution within a virtual
machine as shown in Figure 3.2.
Figure 3.2: Ubuntu Virtual Machine
17
28. 3.4 DevStack Installation
3.4.1 DevStack
As discussed within Section 2.2.7 we install DevStack instead of the normal distri-
bution of OpenStack. OpenStack provide a installation guide to install DevStack in
Ubuntu. By following this step by step guide you can install DevStack, but to meet
the objective of the project we are required to change the configuration file which is
discussed in Section 3.4.2 [9].
3.4.2 Configuration
We are required to create a configuration script to match the needs of the project.
Getting this configuration script correct is a difficult process because there isn’t a
guide to create the file that we required for this project. After trial and error a
configuration file was created as shown in Figure 3.3. It configures DevStack to
install the required modules including the Firewall as a Service module.
Figure 3.3: Configuration Script
18
29. 3.4.3 Installation Process
The installation process is a simple process once you have completed the configura-
tion file. You execute ”./stack.sh” command within the terminal and the installer
process runs. The installer can take up to thirty minutes to complete. The installer
sets up all the OpenStack services within the DevStack environment. Once the in-
staller is complete it returns passwords and IP addresses for the different services
along with OpenStack Dashboard which lets you control the OpenStack Services
using a GUI. When we navigate to the Dashboard address we are presented with a
login screen in Figure 3.4.
Figure 3.4: OpenStack Login Screen
19
30. 3.4.4 DevStack Issues
We are required to take a snapshot of the system when we are shutting down the
virtual machine because DevStack destroys the OpenStack environment. The so-
lution to this problem is to take a snapshot of the live system and then shut the
virtual machine down. When working on the system again you revert back to this
snapshot. As seen in Figure 3.5, there will be lots of snapshots taken during the
project.
Figure 3.5: Snapshots of Virtual Machine
20
31. 3.5 OpenStack Python SDK Installation
The Anomaly Analysis Tool will be implemented with the programming language
Python as discussed in Section 2.3 this requires for the OpenStack Python SDK[15]
to be installed within the virtual machine.
3.5.1 SDK Installation
OpenStack provides a user guide on how to install the different python clients[15].
We are required to install the Python Neutron, Nova, Glance and Keystone clients.
These clients provide the ability to configure OpenStack executing Python programs.
3.5.2 Python SDK Authentication
Before we can execute a Python program we must authenticate the Python clients
with the OpenStack Service endpoints. This requires us to individually authenticate
each Python client. The authentication process requires execution of authentication
code for each service. The Listing 3.1 is an example of the authenticate code that
authenticates the Python clients. Listing 3.1 authenticates the Python Neutron
client.
1 from os import environ as env
2 from n e u t r o n c l i e n t . v2 0 import c l i e n t as n e u t r o n c l i e n t
3 neutron = n e u t r o n c l i e n t . Client ( auth url=env [ ’OS AUTH URL ’ ] ,
4 username=env [ ’OS USERNAME’ ] ,
5 password=env [ ’OS PASSWORD’ ] ,
6 tenant name=env [ ’OS TENANT NAME’ ] ,
7 region name=env [ ’OS REGION NAME ’ ] )
Listing 3.1: Python Neutron Client Authentication
3.5.3 Python SDK Credentials
A credential Python Script had to be implemented that contains functions that you
place in all Python scripts that allow the authentication of the services. Listing
3.2 displays the Neutron credentials function. There is a function for the different
services and you import these credentials into the Python scripts. You also import
the Python clients into the Python scripts so we can interact with the OpenStack
Services as seen in Listing 3.3.
1 def g e t n e u t r o n c r e d e n t i a l s () :
2 d = {}
3 d [ ’ username ’ ] = os . environ [ ’OS USERNAME’ ]
4 d [ ’ password ’ ] = os . environ [ ’OS PASSWORD’ ]
5 d [ ’ auth url ’ ] = os . environ [ ’OS AUTH URL ’ ]
6 d [ ’ tenant name ’ ] = os . environ [ ’OS TENANT NAME’ ]
7 d [ ’ region name ’ ] = os . environ [ ’OS REGION NAME ’ ]
8 return d
Listing 3.2: Python Neutron Client Credentials
1 from n e u t r o n c l i e n t . v2 0 import c l i e n t
2 from c r e d e n t i a l s import g e t n e u t r o n c r e d e n t i a l s
3
4 n e u t r o n c r e d e n t i a l s = g e t n e u t r o n c r e d e n t i a l s ()
5 neutron = c l i e n t . Client (∗∗ n e u t r o n c r e d e n t i a l s )
Listing 3.3: Importing Credentials and Clients into Python Scripts
21
32. 3.6 Test Bed Creation
We require a test network to perform our Anomaly Analysis and this section details
the creation of the Testbed, which will include the creation of a Perimeter Firewall
and instances which will have Security Groups attached to them.
3.6.1 Perimeter Firewall
As discussed in Section 2.2.2 the Perimeter Firewall provide Network Access Control
and sits on the edge of the network attached to the Perimeter Router. By default
the Perimeter Firewall isn’t set up and attached to the Perimeter Router, so an
OpenStack Administrator has to do perform this action.
Perimeter Firewall Creation
We first have to create a Perimeter Firewall Policy and add Perimeter Firewall Rules
to the policy. The creation of this policy and the rules can be achieved through the
Dashboard or through Python Scripts. Both options were used in the creation of the
Testbed. The Dashboard was used to create the Perimeter Firewall Policy and the
creation of the Firewall, a Python Script was used to insert rules into the Perimeter
Firewall Policy.
The creation of the Perimeter Firewall Policy can be seen in Figure 3.6.
Figure 3.6: Creation of the Perimeter Firewall Policy
22
33. We can use either the Dashboard or a Python Script to add rules to the Perimeter
Firewall Policy. But we must first create a Perimeter Firewall Rule as seen in Figure
3.7 then insert that rule into the Perimeter Firewall Policy.
Figure 3.7: Creation of Perimeter Firewall Rule
The creation of the Perimeter Firewall can be seen in Figure 3.8. We add the
Perimeter Firewall Policy during the creation. Once the Perimeter Firewall is created
we attach it the Perimeter Router.
23
34. Figure 3.8: Creation of Perimeter Firewall
Adding Firewall Rules through Python Script
Python functions were designed and implemented so that they can remove or add
Perimeter Firewall Rules to the Perimeter Firewall Policy as alternative to the Dash-
board. These functions were created for two reasons, the first reason is incase the
OpenStack Services crashes and a fresh install had to be performed. These func-
tions would save time because adding and removing Perimeter Firewall Rules is time
consuming. The second reason is during the Anomaly Analysis we can easily deploy
different scenarios within the Testbed network.
There are multiple steps required to create and add Perimeter Firewalls Rules
to the Perimeter Firewall Policy. A database of rules has been created. Listing 3.8
displays how the ”add rules to firewall(database)” function takes a database and
adds each rule to the Perimeter Firewall Policy.
24
35. Listing 3.4 displays a function that will take in rule details and interacts with
the Neutron Service using the ”firewall-rule-create” command to create an Perimeter
Firewall Rule. It returns back to the calling function, the rule ID that is returned
when the rule has been created is done so it can be used to add the rule to the
Perimeter Firewall Policy.
1 def c r e a t e f i r e w a l l r u l e ( rule name , dest ip , dest port , protocol , s r c i p , src port ,
action , tenant id ) :
2 # Create a f i r e w a l l r u l e .
3 c r e a t e f i r e w a l l r u l e r e s u l t = subprocess . Popen ( [ ” neutron ” , ” f i r e w a l l −rule −create ”
4 , ”−−name” , rule name , ”−−destination −ip−address ” , dest ip ,
5 ”−−destination −port ” , dest port , ”−−protocol ” , protocol ,
6 ”−−source−ip−address ” , s r c i p , ”−−source−port ” , src port ,
7 ”−−action ” , action , ”−−tenant id ” , tenant id , ”−f ” , ” json ” ] ,
8 stdout=subprocess . PIPE) . communicate () [ 0 ]
9 c r e a t e f i r e w a l l r u l e = json . loads ( c r e a t e f i r e w a l l r u l e r e s u l t [ 2 9 : ] )
10
11 #f o r loop the json object , and obtain r u l e i d
12 f o r f i r e w a l l r u l e in c r e a t e f i r e w a l l r u l e :
13 i f f i r e w a l l r u l e [ ” Field ” ] == ” id ” :
14 r u l e i d = f i r e w a l l r u l e [ ”Value” ]
15 return r u l e i d
Listing 3.4: Perimeter Firewall Rule Python Creation
Listing 3.5 displays a function that will take in rule id and the Perimeter Firewall
Policy id. The function uses these details to add the rule to the Perimeter Firewall
Policy using the ”firewall-policy-insert-rule” command.
1 def i n s e r t r u l e i n t o f i r e w a l l p o l i c y ( f i r e w a l l p o l i c y i d , r u l e i d ) :
2 #I n s e r t a r u l e into a given f i r e w a l l p o l i c y
3 i n s e r t f i r e w a l l r u l e r e s u l t = subprocess . Popen ( [ ” neutron ” ,
4 ” f i r e w a l l −policy −i n s e r t −r u l e ” , f i r e w a l l p o l i c y i d , r u l e i d , ”−f ” , ” json ” ] ,
stdout=subprocess . PIPE) . communicate () [ 0 ]
Listing 3.5: Inserting Rule into Perimeter Firewall Policy
To create a rule we require the tenant id, Listing 3.6 obtains the tenant ID using
the ”list security groups()” command.
1 def g e t t e n a n t i d () :
2 try :
3 s e c u r i t y g r o u p r u l e s l i s t = c o n f l i c t s e t u p . neutron . l i s t s e c u r i t y g r o u p s ()
4 f o r s e c u r i t y in s e c u r i t y g r o u p r u l e s l i s t [ ’ s e c u r i t y g r o u p s ’ ] :
5 tenant id =s e c u r i t y [ ’ tenant id ’ ]
6
7 return tenant id
8
9 except AttributeError :
10 print ( ” Error ” )
Listing 3.6: Get Tenant ID
To create a rule we also require the Perimeter Firewall Policy ID so that the rules
can be inserted in to the policy, Listing 3.7 obtains the Perimeter Firewall Policy
ID using the ”firewall-policy-list” command.
1 def g e t f i r e w a l l p o l i c y i d () :
2 try :
3 f i r e w a l l p o l i c y l i s t r e s u l t = subprocess . Popen ( [ ” neutron ” ,
4 ” f i r e w a l l −policy −l i s t ” , ”−f ” , ” json ” ] ,
5 stdout=subprocess . PIPE) . communicate () [ 0 ]
6 f i r e w a l l p o l i c y l i s t = json . loads ( f i r e w a l l p o l i c y l i s t r e s u l t )
7
8 f o r p o l i c y l i s t in f i r e w a l l p o l i c y l i s t :
9 f i r e w a l l p o l i c y i d = p o l i c y l i s t [ ” id ” ]
10 return f i r e w a l l p o l i c y i d
11 except AttributeError :
12 print ( ” Error ”
Listing 3.7: Get Perimeter Firewall Policy ID
25
36. Listing 3.8 displays the complete function that takes rules from a database and
uses the functions displayed in Listing 3.4,5,6 and 7 to create and add the rules to
the Perimeter Firewall Policy.
1 def a d d r u l e s t o f i r e w a l l ( database ) :
2 # Use a f o r loop to create a s e t of r u l e s
3
4 f o r c o n f l i c t d a t a b a s e in database :
5 rule name = c o n f l i c t d a t a b a s e [ ” rule name ” ]
6 d e s t i p = c o n f l i c t d a t a b a s e [ ” d e s t i p ” ]
7 d e s t p o r t = c o n f l i c t d a t a b a s e [ ” d e s t p o r t ” ]
8 protocol = c o n f l i c t d a t a b a s e [ ” protocol ” ]
9 s r c i p = c o n f l i c t d a t a b a s e [ ” s r c i p ” ]
10 s r c p o r t = c o n f l i c t d a t a b a s e [ ” s r c p o r t ” ]
11 action = c o n f l i c t d a t a b a s e [ ” action ” ]
12 tenant id = c o n f l i c t s e t u p . g e t t e n a n t i d ()
13 f i r e w a l l p o l i c y i d = ConflictSetup . g e t f i r e w a l l p o l i c y i d ()
14 # c r e a t e s a r u l e and returns the r u l e id
15 r u l e i d = ConflictSetup . c r e a t e f i r e w a l l r u l e ( rule name , dest ip , dest port ,
protocol , s r c i p , src port , action , tenant id )
16
17 # I n s e r t r u l e s into f i r e w a l l p o l i c y
18 ConflictSetup . i n s e r t r u l e i n t o f i r e w a l l p o l i c y ( f i r e w a l l p o l i c y i d , r u l e i d )
Listing 3.8: Complete Add Rules to Perimeter Firewall Function
Removing Firewall Rules through Python Script
To remove a rule from the Neutron Service we are required to first remove the rule
from the Perimeter Firewall Policy. This is accomplished in Listing 3.9 using the
”firewall-policy-remove-rule” command that uses the Perimeter Firewall Policy ID
and rule ID which has been passed into the function.
1 def r e m o v e f i r e w a l l p o l i c y r u l e ( f i r e w a l l p o l i c y i d , r u l e i d ) :
2 # Remove a r u l e from a given f i r e w a l l p o l i c y .
3 r e m o v e f i r e w a l l p o l i c y r u l e r e s u l t = subprocess . Popen ( [ ” neutron ” ,
4 ” f i r e w a l l −policy −remove−r u l e ” , f i r e w a l l p o l i c y i d , r u l e i d ,
5 ”−f ” , ” json ” ] , stdout=subprocess . PIPE) . communicate () [ 0 ]
Listing 3.9: Remove Perimeter Firewall Rule from Perimeter Firewall Policy
After the rule has been removed from the Neutron Service; this is achieved in
Listing 3.10 using the ”firewall-rule-delete” command that uses the rule ID that has
been passed into the function.
1 def d e l e t e f i r e w a l l r u l e ( r u l e i d ) :
2 # Delete a given f i r e w a l l r u l e .
3 d e l e t e f i r e w a l l r u l e r e s u l t = subprocess . Popen ( [ ” neutron ” , ” f i r e w a l l −rule −d e l e t e ”
, r u l e i d ,
4 ”−f ” , ” json ” ] , stdout=subprocess . PIPE) . communicate () [ 0 ]
Listing 3.10: Remove Perimeter Firewall Rule from Neutron Service
Listing 3.11 displays the complete function that uses the functions displayed in
Listing 3.9 and 10 to remove and delete all rules from the Perimeter Firewall.
1 def r e m o v e a l l f i r e w a l l r u l e s () :
2 f i r e w a l l d a t a b a s e = ConflictSetup . databaseObject . g e t f i r e w a l l d a t a b a s e ()
3 f o r f i r e w a l l p o l i c y in f i r e w a l l d a t a b a s e :
4 p o l i c y i d = f i r e w a l l p o l i c y [ ” p o l i c y i d ” ]
5 f o r r u l e i in f i r e w a l l p o l i c y [ ” r u l e s ” ] :
6 r u l e i d = r u l e i [ ” r u l e i d ” ]
7 ConflictSetup . r e m o v e f i r e w a l l p o l i c y r u l e ( p o l i c y i d , r u l e i d )
8 ConflictSetup . d e l e t e f i r e w a l l r u l e ( r u l e i d )
Listing 3.11: Complete remove Rules from Perimeter Firewall Function
26
37. Perimeter Firewall Policy
The completed Testbed Perimeter Firewall Policy is displayed in Table 3.1. The
Perimeter Firewall Policy has been designed to contain rules that will create intra
and inter anomalies within in the Testbed as defined in ”Taxonomy of Conflicts in
Network Security Policies”[1]. We will define these anomalies in Chapter 4.
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.024 60:80 10.0.0.424 24:26 allow
2 TCP 0.0.0.024 60:80 10.0.0.424 24:26 allow
3 TCP 0.0.0.032 60:80 10.0.0.424 24:26 allow
4 TCP 0.0.0.028 60:80 10.0.0.424 24:26 allow
5 TCP 0.0.0.024 100:140 10.0.0.524 5260:5280 deny
6 TCP 0.0.0.032 120:130 10.0.0.532 5260:5280 allow
7 TCP 0.0.0.030 30:40 10.0.0.332 80:100 deny
8 TCP 0.0.0.024 20:45 10.0.0.332 80:100 allow
9 TCP 0.0.0.024 50:150 10.0.0.424 24:26 deny
10 TCP 0.0.0.028 800:900 10.0.0.624 18:24 deny
Table 3.1: Testbed Perimeter Firewall Policy
27
38. 3.6.2 Instances
As we have discussed in Section 2.2.3 instances are virtual machines. For the purpose
of this project we will set up servers within these instances. We will set up four
instances within the Testbed. They are:
1. Web Server Instance
2. Chat Server Instance
3. File Server Instance
4. Mail Server Instance
These instances will act as dummy servers, that when accessed will return a text
output. For the objectives of this project what occurs within the instance is not
important. What is important is the Security Groups that are attached to these
instances because they provide Host Based Access Control.
Instance Setup
To set up an instance there is several steps required and this can be achieved through
the Dashboard or through the Python SDK. We would not be changing the instances
once setup, therefore we decided to use the Dashboard to implement the instances
instead of writing a script to complete the process.
To launch a instance through the Dashboard there is a user guide[12]. This user
guide describes the following steps, we first open the Compute tab and launch an
instance as seen in Figure 3.9. You give the instance a name and you select a flavor
for the instance. The flavor is the size of the instance you wish to launch.
Figure 3.9: Launch a Instance
28
39. We can launch multiple instances using the specification see in Figure 3.9 by
setting the instance count to a value greater than one. We then select the instance
boot source, we select our boot source as an image, there are also other options to
choose from. We finally select the image for our Testbed, we are using the CirrOS
image because it is lightweight and will allow us to create a dummy server within
the instance using Netcat. You launch the instance and it becomes live within the
Testbed network[24].
Dummy Server Setup
Once we have launch all four instances we have to implement four dummy servers
within these instances. This is achieved using Netcat. Netcat is a computer net-
working utility for reading and writing to network connections using TCP or UDP.
The command in Listing 3.12 will create a dummy server within the instance. The
dummy servers will always be listed to the port specified within the command.
When the Dummy Server is called as seen in Listing 3.13 using a curl command, it
will return for example ”This is a Web Server located on Port 80”[24].
1 while true ; do echo −e ’ This i s a Web Server located on Port 80 ’ | sudo nc −l −p
80 ; done &
Listing 3.12: Dummy Web Server Setup
1 c u r l 1 0 . 0 . 0 . 3 : 8 0
Listing 3.13: Calling Dummy Servers
The dummy servers within the instances are simple servers, but for the objectives
of this project they meet the requirement. We must add Host Based Access Control
to these instances and this is achieved by connecting a Security Group to each
instance.
29
40. 3.6.3 Security Groups
As discussed in section 2.2.4 Security Groups are required to be created and con-
nected to the instances within the Testbed network to implement Host Based Access
Control. For the Testbed network we will be required to create four Security Groups
and their rules. These Security Groups will be then connected to the instances within
the network.
Security Groups Creation
We first have to create a Security Group Policy and add Security Group Rules to the
policy. The creation of the policy and rules can be achieved through the Dashboard
or through Python Scripts. Due to time constraints the Dashboard was used to
create the Security Group Policies and the creation of their rules.
The creation of a Security Group Policy can be seen in Figure 3.10.
Figure 3.10: Creation of the Security Group Policy
30
41. This creation process is repeated so that all four required Security Group Policies
have been created. Once a Security Group Policy has been created we add rules to
these policies as seen in Figure 3.11. We repeat this rule creation process within each
policy until the required Host Based Access Control has been achieved. Once the
Security Groups have been implemented correctly they are attached to the different
instances within the Testbed network.
Figure 3.11: Creation of Security Group Rule
File Server Security Group
Table 3.2 shows the completed File Server Security Group Policy that is attached
to the File Server instance to provide Host Based Access Control to the instance.
Rule Direction Ethernet Type IP Protocol Port Range Remote IP Prefix
1 Ingress IPv4 TCP 15:22 0.0.0.0/24
2 Ingress IPv4 TCP 20:22 0.0.0.0/32
3 Ingress IPv4 TCP 21:21 0.0.0.0/24
4 Ingress IPv4 TCP 22:22 0.0.0.0/24
5 Ingress IPv4 TCP 143:143 0.0.0.0/24
6 Egress IPv4 TCP 10:150 0.0.0.0/24
Table 3.2: File Server Security Group Policy
31
42. Web Server Security Group
Table 3.3 shows the completed Web Server Security Group Policy that is attached
to the Web Server instance to provide Host Based Access Control to the instance.
Rule Direction Ethernet Type IP Protocol Port Range Remote IP Prefix
1 Ingress IPv4 TCP 22:22 0.0.0.0/24
2 Ingress IPv4 TCP 60:100 0.0.0.0/24
3 Ingress IPv4 TCP 80:80 0.0.0.0/24
4 Ingress IPv4 TCP 85:95 0.0.0.0/32
5 Ingress IPv4 TCP 143:143 0.0.0.0/24
6 Egress IPv4 TCP 10:150 0.0.0.0/24
Table 3.3: Web Server Security Group Policy
Chat Server Security Group
Table 3.4 shows the completed Chat Server Security Group Policy that is attached
to the Chat Server instance to provide Host Based Access Control to the instance.
Rule Direction Ethernet Type IP Protocol Port Range Remote IP Prefix
1 Ingress IPv4 TCP 5000:5500 0.0.0.0/24
2 Ingress IPv4 TCP 5265:5275 0.0.0.0/32
3 Ingress IPv4 TCP 5269:5269 0.0.0.0/24
4 Ingress IPv4 TCP 22:22 0.0.0.0/24
5 Ingress IPv4 TCP 143:143 0.0.0.0/24
6 Egress IPv4 TCP 10:150 0.0.0.0/24
Table 3.4: Chat Server Security Group Policy
Mail Server Security Group
Table 3.5 shows the completed Mail Server Security Group Policy that is attached
to the Mail Server instance to provide Host Based Access Control to the instance.
Rule Direction Ethernet Type IP Protocol Port Range Remote IP Prefix
1 Ingress IPv4 TCP 20:30 0.0.0.0/24
2 Ingress IPv4 TCP 22:22 0.0.0.0/24
3 Ingress IPv4 TCP 25:25 0.0.0.0/32
4 Ingress IPv4 TCP 143:143 0.0.0.0/24
5 Egress IPv4 TCP 10:150 0.0.0.0/24
Table 3.5: Mail Server Security Group Policy
The Security Group Polices have been designed to contain rules that will create
intra and inter anomalies within in the Testbed as defined in ”Taxonomy of Conflicts
in Network Security Policies”[1]. We will define these anomalies in Chapter 4.
32
43. 3.7 Testbed Network Typology
Figure 3.12 displays the Testbed Network Typology. The typology displays the
different instances and the Perimeter Router which has the Perimeter Firewall at-
tached. This completed Testbed will be analysed using Anomaly Analysis Tools to
identify and report on anomalies within the network.
Figure 3.12: Network Typology
33
45. 4.1 Anomalies
4.1.1 Anomalies and why are they important?
Anomalies within a Perimeter Firewall or Security Groups are conflicts that occur
when two or more rules that are seemingly different match the same packet. While
the individual rules themselves may be consistent with a network security policy, a
rule placed out of sequence may unintentionally change the intended meaning of the
firewall configuration, and thus, be inconsistent with the network security policy.[4]
It is important to identify and remove these anomalies by either reordering the
rules or by deleting the rules. Policy anomalies occur due to rule misconfiguration
within a single policy (intra-policy anomalies) or between policies in different devices
(inter-policy anomalies).
4.1.2 Intra Anomalies within OpenStack
Intra Anomalies are conflicts that occur between rules in a single policy. In relation
to OpenStack this means that there is a conflict within either the Perimeter Firewall
or a Security Group. This conflict can unintentionally change the intended meaning
of the firewall configuration.
There are three types of Anomalies that can occur within a single policy due to
policy misconfiguration that are relevant to this project:
1. Intra Redundancy Anomalies
2. Intra Shadowing Anomalies
3. Intra Generalisation Anomalies
4.1.3 Inter Anomalies within OpenStack
Inter Anomalies are conflicts that occur between rules across different policies. In
relation to OpenStack this means that there is a conflict between a rule in the
Perimeter Firewall and a rule in a Security Group. This conflict can unintentionally
change the intended meaning of the firewall configuration between the Perimeter
Firewall and a Security Group.
There is one type of Anomaly that can occur between policies in different devices
due to policy misconfiguration that is relevant to this project:
1. Inter Shadowing Anomalies
35
46. 4.2 Performing Intra Anomaly Analysis
4.2.1 Intra Redundancy Anomalies
Intra Redundancy Anomalies definition
A rule is redundant when every packet that could match this rule is matched by
some preceding rule that has a similar action. In other words, if the redundant rule
is removed, the behaviour of the security policy remains unchanged. Rule Ry is
redundant to Rule Rx if Rx precedes Ry and Ry is either equivalent too, subset of
or a superset of Rx and the two rules have similar actions[1].
Intra Redundancy Anomalies within Security Groups
An Intra Redundancy Anomaly occurs between two Security Group Policy Rules
that can filter the same packets and those rules have the same target actions over
those packets. The removal of the redundant rule does not affect the semantics of
the firewall configuration[4]. Rule Ry is redundant to Rule Rx in a single Security
Group if Rx precedes Ry and Ry is subset of, or a superset of Rule Rx [1]. OpenStack
doesn’t allow an OpenStack Administrator to define a pair of equivalent rules within
in a Security Group, so it’s not possible to create Intra Redundancy Anomalies
through equivalence.
Rule Direction Ethernet Type IP Protocol Port Range Remote IP Prefix
1 Ingress IPv4 TCP 20:30 0.0.0.0/24
2 Ingress IPv4 TCP 22:22 0.0.0.0/24
3 Ingress IPv4 TCP 15:40 0.0.0.0/24
Table 4.1: Security Group Intra Redundancy Anomaly Example
Table 4.1 is a section of the Testbed Mail Server Security Group and it defines
the two types of Intra Redundancy Anomalies that can occur within a Security
Group. Rule 2 is a subset of Rule 1 because of the port ranges. Rule 3 is a superset
of Rule 1 and Rule 2 also because of the specified port ranges within the rules.
Intra Redundancy Anomalies within the Perimeter Firewall
It is possible for an OpenStack Administrator to define a pair of rules within the
Perimeter Firewall where Rule Ry is redundant to Rule Rx, if Rx precedes Ry and
Ry is either equivalent too, subset of or a superset of Rule Rx and the two rules
have similar actions.
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.024 60:80 10.0.0.424 24:26 allow
2 TCP 0.0.0.024 60:80 10.0.0.424 24:26 allow
3 TCP 0.0.0.032 60:80 10.0.0.424 24:26 allow
4 TCP 0.0.0.028 60:80 10.0.0.424 24:26 allow
Table 4.2: Perimeter Firewall Intra Redundancy Anomaly Example
Table 4.2 is a section of the testbed Perimeter Firewall and it defines the three
types of Intra Redundancy Anomalies. Rule 2 is equivalent to Rule 1; Rule 3 is a
36
47. subset of Rule 1 as well as Rule 2 due to the source IP and Rule 4 is a superset of
Rule 3 due to the source IP.
The need to identify Intra Redundant Anomalies
We can see it is possible for an OpenStack Administrator to misconfigure the Perime-
ter Firewall and or the Security Groups establishing Intra Redundancy Anomalies
within these policies. Therefore it is relevant to identify these anomalies through
analysis and then the OpenStack Administrator can use this analysis to either re-
move or reorder the redundant rules.
37
48. 4.2.2 Intra Shadowing Anomalies
Intra Shadowing Anomalies definition
A rule is shadowed when every packet that could match this rule is matched by
some preceding rule with a different action. Consequently, the shadowed rule will
never have an effect in the policy. Typically, Rule Ry is shadowed by Rule Rx if Rx
precedes Ry and Ry is is either equivalent too or a subset of Rx and the two rules
have different actions[1].
Intra Shadowing Anomalies within Security Groups
OpenStack doesn’t allow an OpenStack Administrator to define rules within in a
Security Group that will result in Shadowing Anomalies within that single policy.
Rules defined within a Security Group have the default action accept and it is not
possible to define rules with the action deny. Therefore we can see that it’s not
possible to define rules that will result in Shadowing Anomalies within a single
Security Group.
Intra Shadowing Anomalies within the Perimeter Firewall
An Intra Shadowing Anomaly occurs when two Perimeter Firewall Rules can filter
the same packets and those rules have different target actions over those packets.
Consequently, the shadowed rule will never have an effect on the packet. It is possible
for an OpenStack Administrator to define rules within the Perimeter Firewall where
Rule Ry is shadowed by Rule Rx. If Rx precedes Ry and Ry is either equivalent too
or a subset of Rx and the two rules have different actions.
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.024 100:140 10.0.0.524 5260:5280 deny
2 TCP 0.0.0.032 120:140 10.0.0.532 5260:5280 allow
Table 4.3: Perimeter Firewall Intra Shadowing Anomaly Example
The need to identify Intra Shadowing Anomalies
We can see in Table 4.3 its possible for an OpenStack Administrator to miscon-
figure the Perimeter Firewall but not the Security Groups to establish Intra Shad-
owing Anomalies. Therefore it’s relevant to identify shadowing anomalies within
the Perimeter Firewall through analysis. An OpenStack Administrator can use this
analysis to either remove or reorder the shadowed rules, such that the more specific
rule is placed before its more general counterpart.
38
49. 4.2.3 Intra Generalisation Anomalies
Intra Generalisation Anomalies definition
Generalisation Anomalies are very common in a network security policies. Typically,
Rule Ry is generalised by Rule Rx if Rx precedes Ry and Ry is a superset of Rx
and the two rules have different actions[1]. Intra Generalisation Anomalies can be
viewed as an warning due to the fact that the proceeding more specific rule makes
an exception of the generalised rule[4].
Intra Generalisation Anomalies in Security Group policies
OpenStack doesn’t allow an OpenStack Administrator to define rules within in a
Security Group that will result in Generalisation Anomalies within that single policy.
Rules defined within a Security Group have the action default accept and its not
possible to define rules with the action deny. Therefore we can see that it’s not
possible to define rules that will result in Generalisation Anomalies within a single
Security Group policy.
Intra Generalisation Anomalies within the Perimeter Firewall
It is possible for an OpenStack Administrator to define rules within the Perimeter
Firewall where Rule Ry is generalised by Rule Rx, if Rx precedes Ry and Ry is a
superset of Rx and the two rules have different actions[1]. These rules will result in
a Intra Generalisation Anomaly.
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.030 30:40 10.0.0.332 80:81 deny
2 TCP 0.0.0.024 20:45 10.0.0.332 80:81 allow
Table 4.4: Perimeter Firewall Intra Generalisation Anomaly Example
The need to identify Intra Generalisation Anomalies
We can see in Table 4.4 its possible for an OpenStack Administrator to misconfigure
the Perimeter Firewall but not the Security Groups to establish Intra Generalisation
Anomalies. Therefore it’s relevant to identify generalisation anomalies within the
Perimeter Firewall through analysis. An OpenStack Administrator can use this
analysis to either remove or reorder the generalised rules.
39
50. 4.2.4 Intra Anomaly Analysis tool
A tool was built to test for the above Intra Anomalies that can occur within a
Perimeter Firewall and within a Security Group Policy. Algorithm 1 shows how
the Intra Anomaly Analysis is achieved. The database is first obtained and the
algorithm shows that we loop through each policy within the database. For each
policy we loop through each rule within the policy in sequence. We assign the rule
attributes in the database to rule i and we perform a inner loop to obtain rule j
which is rule i + 1. This process provides us with rule 1 and 2 the first time around
and then rule 2 and rule 3, etc. As you can see there is conditional tests to see if the
rule j is either redundant, shadowed or generalised by rule i. If a there is a conflict,
the conflict pair are added to a conflict database.
Algorithm 1 Intra Anomaly Analysis
1: Database = get Database()
2: for policies in Database do
3: for rule i in policies do
4: set rule i attributes.
5: for rule j in a policies do
6: set rule j attributes
7: Test Rule i against Rule j.
8: if Redundancy Conflict then
9: Add Redundant pair of Rules to Conflict Database.
10: else if Shadowing Conflict then
11: Add Shadowing pair of Rules to Conflict Database.
12: else if Generalisation Conflict then
13: Add Generalisation pair of Rules to Conflict Database.
14: remove(rule i)
40
51. 4.3 Performing Inter Anomaly Analysis
4.3.1 Downstream Firewalls & Upstream Firewalls
When performing Inter Anomaly Analysis you analyse the relationship between a
Upstream Firewall and Downstream Firewall, and identify Inter Anomalies between
them. In Figure 4.1 we can see the Network Typology, the Perimeter Firewall is
attached to the Perimeter Router and the Security Groups are attached to the dif-
ferent instances in the network such as the Web and File Server. The Typology
demonstrates there are two scenarios that can happen within the OpenStack Net-
work:
1. The traffic is going from the Perimeter Firewall to the Security Group. Then
the Downstream Firewall is the Security Group and the the Upstream Firewall
is the Perimeter Firewall.
2. The traffic is leaving the Security Group and going to the Perimeter Firewall.
Then the Downstream Firewall is the Perimeter Firewall and the Upstream
Firewall is the Security Group.
Figure 4.1: Network Typology
41
52. 4.3.2 Inter Shadowing Anomalies
Inter Shadowing Anomalies definition
The conflict is similar to the one discussed in the Intra Shadowing Anomalies except
that it occurs between rules in two different policies/devices. Thus, Inter policy
shadowing occurs if the upstream policy blocks some traffic that is permitted by the
downstream policy[1].
Inter Shadowing Anomalies in OpenStack
An Inter Shadowing Anomaly occurs when a downstream Security Group Policy is
filtering an equivalent or a subset of packets that the upstream Perimeter Firewall is
currently filtering, but the upstream Perimeter Firewall is denying what the down-
stream Security Group Policy is permitting.[4] Shadowing can only occur in scenario
one of the upstream and downstream scenarios in Section 4.3.1. This is because as
we clearly identified before, that all Security Group Rules are default accepts and it
is not possible to create rules with deny actions, ruling out scenario two in Section
4.3.1.
Example of an Inter Shadowing Anomaly
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.024 100:140 10.0.0.524 5260:5280 deny
Table 4.5: Perimeter Firewall Rule
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.032 0:65535 10.0.0.524 5265:5275 allow
Table 4.6: Security Group Policy Rule
The need to identify Inter Shadowing Anomalies
We can see from Tables 4.5 and 4.6 it’s possible for an OpenStack Administrator
to misconfigure the Perimeter Firewall and the Security Groups to establish Inter
Shadowing Anomalies. Therefore it’s relevant to identify Shadowing Anomalies be-
tween the Perimeter Firewall and Security Groups through analysis. An OpenStack
Administrator can use this analysis to either remove or reorder the shadowed rules,
such that the more specific rule is placed before it’s more general counterpart.
42
53. 4.3.3 Inter Anomaly Analysis tool
A tool was built to test for the above Inter Anomaly that can occur between a
Perimeter Firewall and a Security Group Policy. Algorithm 2 shows how the In-
ter Anomaly Analysis is achieved. The Perimeter Firewall and Security Group
databases are obtained and the algorithm shows that we loop through each Perime-
ter Firewall Policy within the database. For each policy inside the Perimeter Firewall
Database we loop through each rule within the policy in sequence. We assign the
rule attributes in the Perimeter Firewall Database to rule i. As displayed in the
algorithm we have to loop through each Security Group Policy within the Security
Group Database. For each policy inside the Security Group we loop through each
rule within the policy in sequence and assign the rule details to rule j. As you can
see there is conditional tests to see if the rule j is shadowed by rule i. If a there is
a conflict, the conflict pair are added to a conflict database. This algorithm lets us
compare the Perimeter Firewall to each Security Group within the network to see if
there is any inter anomalies.
Algorithm 2 Inter Anomaly Analysis
1: perimeter firewall database = get perimeter firewall database()
2: security group database = get security group database()
3: for policies pf in perimeter firewall database do
4: for rule i in policies pf do
5: set rule i attributes.
6: for policies sg in security group database do
7: for rule j in policies sg do
8: set Rule j attributes
9: Test Rule i against Rule j.
10: if Shadowing Conflict then
11: Add Shadowing pair of Rules to Conflict Database.
12: remove(rule i)
43
54. 4.3.4 Inter Redundancy Anomalies
Inter Redundancy Anomalies were studied but a test for these anomalies were not
implemented within the analysis tool, due to factors described below.
Inter Redundancy Anomalies definition
An Inter Redundancy Anomaly occurs when a downstream firewall is filtering an
equivalent, a subset of or a superset of packets that an upstream firewall is currently
filtering, where both the firewalls apply the same action to those filtered packets[4].
Inter Redundancy Anomalies in OpenStack
An Inter Redundancy Anomaly occurs when a downstream Security Group Policy
is filtering a subset of or a superset packets that the upstream Perimeter Firewall
is currently filtering. Both the Perimeter Firewall and Security Group Policy apply
the same action to those filtered packets[4].
We do not try and identify equivalent rules, we require at least a set of equivalent
rules between the Perimeter Firewall and Security Groups for the instance to receive
traffic. Both rules must have the action allow because it’s futile to have both rules
as action deny. This is due to the fact that the Security Groups are action default
allow as stated above. We focus on identifying Redundant Anomalies relating to
rules in a downstream Security Group being a superset or subset of the rule in the
upstream Perimeter Firewall.
Example of an Inter Redundancy Anomaly
Rule Protocol Source IP Source Port Destination IP Destination Port Action
1 TCP 0.0.0.024 100:140 10.0.0.524 5260:5280 allow
Table 4.7: Perimeter Firewall Rule
Rule Protocol Source IP Source Port Destination IP Destination Port Action
2 TCP 0.0.0.032 0:65535 10.0.0.524 5265:5275 allow
Table 4.8: Security Group Policy Rule
In this example Rule 2 in the downstream Security Group is redundant to Rule
1 in the upstream Perimeter Firewall because Rule 2 is a subset of Rule 1.
The need to identify Inter Redundancy Anomalies
We can see with Tables 4.7 and 4.8 it’s possible for an OpenStack Administrator
to misconfigure the Perimeter Firewall and the Security Groups to establish Inter
Redundancy Anomalies. Even though there is an anomaly between the Perimeter
Firewall and the Security Group in the above example, we take the view that it’s
not relevant to identify these anomalies because you might have multiple instances
within your network. There could be the case that you have one Perimeter Firewall
Rule which is allowing a large range of traffic to four instances.
44
55. In this instance each security group is only allowing a subset of that traffic to
there instances. In this configuration the polices are providing both Network Access
Control and Host Based Access Control that the OpenStack Administrator intended
even though there is Redundancy Anomalies between the Perimeter Firewall and
the Security Groups.
There is a possibility where the Security Group is upstream and the Perimeter
Firewall is Downstream and a rule in the Perimeter Firewall is a superset of the
Security Group Policy Rule. Using the view we declared, it wouldn’t be relevant
to identify superset Redundancy Anomalies. Further work must be carried out to
determine clearly if Inter Redundancy Anomalies are relevant in OpenStack, but it
was outside the scope of this project.
45
57. 5.1 System Architecture Design
Figure 5.1 displays the System Architecture Design, it shows that we first generate
a test bed on the Neutron Service. We then proceed to use a Discovery Agent
to access the policies and their associated rules from the Neutron Service. The
Discovery Agent normalises the policy rules and stores the policies within a database
so that the conflict analysis tool can perform Intra and Inter Anomaly Analysis. If
the analysis tool finds anomalies within a policy or between a polices, it will store
the conflicting rules and the type of anomaly within a database that can allow an
OpenStack administrator to help manage the policies.
Figure 5.1: System Architecture Design
47
58. 5.2 Reasoning about Ranges
5.2.1 Classless Inter Domain Routing
As we have seen in the previous examples the IP addresses are in CIDR notation.
Classless Inter Domain Routing is a method for allocating IP addresses and routing
Internet Protocol packets. CIDR notation is a syntax for specifying IP addresses
and their associated routing prefix. It appends a slash character to the address and
the decimal number of the leading bits of the routing prefix[23].
CIDR notation gives a range of IP addresses. For example XX.XX.XX.0/24
means take 32 bits, subtract 24 (leaving 8) and use that as the two’s power. Answer:
256. Therefore the IP range is XX.XX.XX.0 through XX.XX.XX.255. We will assign
the lower value in the range into a minimum value attribute and assign the higher
value in the range into a maximum value attribute[22].
CIDR IPs into Integer values
For analysis it would be suitable to convert these CIDR IP addresses into integer
range. To achieve this Listing 5.1 displays a function that was designed and con-
structed to take an CIDR IP address and returns the minimum IP within the range
and maximum IP within the range as integer values. These integer values which will
make testing for the different types of anomalies substantially easier. The function
uses a standard library called netaddr which makes the process of converting the
CIDR IP address into ranges a simplified process[17].
1 #Converts CIDR IP into a minmum and maximum i n t values
2 def c i d r t o r a n g e ( c i d r a d d r e s s ) :
3 #Converts the c i d r address into a IPNetwork Object .
4 ip = IPNetwork ( c i d r a d d r e s s )
5 #Obtains l i s t of ip addresses that the CidR IP address r e p r e s e n t s .
6 i p l i s t = l i s t ( ip )
7 #Stores the f i r s t ip and the l a s t ip in the l i s t .
8 ip address min = i n t ( i p l i s t [ 0 ] )
9 ip address max = i n t ( i p l i s t [ −1])
10 #Returns the minimum and maximum ip addresses as i n t values .
11 return ( ip address min , ip address max )
Listing 5.1: CIDR IP to Int Range Function
48
59. 5.2.2 Port Ranges
As we have also seen in the previous examples ports also have the range structure.
For example in a Perimeter Firewall Rule you have a source port range that is 80:85,
this means that a packet which matches all the other attributes within that rule can
have a source port of between 80 to 85 and match the rule correctly. We will assign
the lower value in the range into a minimum value attribute and assign the higher
value in the range into a maximum value attribute. In Listing 5.2 we can see a port
range test, that checks if Rule j is a Subset of Rule i. The Port Ranges provide clear
way to check if a rule is either a subset, superset or equivalent to another rule.
1 #Uses the Port Ranges to t e s t i f Rule j i s a subset of Rule i .
2 i f (#Checks i f Rule J Source Port i s a Subset of Rule J Port
3 r u l e i s r c p o r t r a n g e m i n <= r u l e j s r c p o r t r a n g e m i n and
4 r u l e i s r c p o r t r a n g e m a x >= r u l e j s r c p o r t r a n g e m a x and
5 #Checks i f Rule J Destination Port i s a Destination of Rule J Port
6 r u l e i d e s t p o r t r a n g e m i n <= r u l e j d e s t p o r t r a n g e m i n and
7 r u l e i d e s t p o r t r a n g e m a x >= r u l e j d e s t p o r t r a n g e m a x ) :
Listing 5.2: Subset Port Range Test
5.2.3 Range Analysis
When performing analysis, we will be identifying rules that are equivalent to a subset
of or a superset of a previous rule. The approach that we decided to take for this
project was to identify if a rule was equivalent, a subset of or a superset of a previous
rule using the IP Address maximum and minimum values and the Port maximum
and minimum values.
49
60. 5.3 Data Structure Design
5.3.1 Data Structure choices
We will require some type of data structure to store the Perimeter Firewall Policy
and the Security Group Polices. The data structure must let the analysis tool
efficiently access the different policies and the rules contained within the individual
policies. There are different options that could be implemented to store the policies
and their rules. Different options were looked at but below are the two options that
matched the objectives of the project.
1. Python IP-Tables
2. Self Designed Data Structure
5.3.2 Python IP-Tables
Iptables is the tool that is used to manage netfilter, the standard packet filtering and
manipulation framework under Linux. As the Iptables is used to set up, maintain,
and inspect the tables of IPv4 packet filter rules in the Linux kernel. Several different
tables may be defined. Each table contains a number of built-in chains and may also
contain user- defined chains. Each chain is a list of rules which can match a set of
packets. Each rule specifies what action to take with a packet that matches a rule
within a table. This is called a target action, which may be a jump to a user-defined
chain in the same table[19].
Benefits of Python IP Tables
The benefits of the Python IP Tables is that it’s a previously built library which
is heavily documented and tested. It will save time because a new data structure
doesn’t have to be designed and tested, also no accessor and mutator functions have
to be built and tested.
Negatives of Python IP Tables
The negatives of Python IP tables is that it doesn’t perfectly fit the needs of the
project. The Python IP Tables library doesn’t allow the discovery agent for the
Perimeter Firewall and Security Groups store the required information. It would be
difficult and time consuming to achieve whats required with the Python IP Tables
package.
5.3.3 Self Designed Data Structure
Benefits of Self Designed Data Structure
The benefits of a self designed data structure is that the data structure would only
hold the information that was required by the project and could be easily changed
to fit changing requirements of the project.
50
61. Negatives of Self Designed Data Structure
The self design data structure would be inefficient to access if poorly designed. Also
if poorly designed the structure would not scale correctly. Using a self designed data
structure involves more testing compared to existing data structures and accessor
and mutator functions have to be built and tested.
5.3.4 Data Structure Choice
Both the Python IP Tables and the Self Designed Data Structure have both negatives
and positives; For the objectives of the project and with the timescale given, it was
decided that a self designed data structure would be the best course of action. The
alternative of trying to get the Python IP Tables to do what was required would have
been to time consuming. The self designed structure would hold all the required
attributes and be implemented within the time frame given.
5.4 Data Structure Implementation
5.4.1 Normalised Data Structure
The data structure will contain a list of policies, each policy will contain the Policy
ID, Policy Name and all the rules associated with that policy. Each rule will have
contain the normalised rule attributes which are:
1. Rule ID
2. Protocol
3. Source IP Minimum Value
4. Source IP Maximum Value
5. Source Port Minimum Value
6. Source Port Maximum Value
7. Destination IP Minimum Value
8. Destination IP Maximum Value
9. Destination Port Minimum Value
10. Destination Port Maximum Value
11. Action
51
62. Normalised Data Structure Design
Figure 5.2 displays the Normalised Data Structure Design as a UML representation.
Figure 5.2: Normalised Database Design
As we can see in Listing 5.3 the Data Structure is constructed by implementing
a series of lists with inner dictionaries to hold the policy and rule details. We
implement a list were in each index there is a dictionary which contains each policy.
Within the policy dictionary you have following keys policy id, policy name and
rules.The value for the rules key is a list were in each index is a dictionary to
represent the individual rules associated with the policy. The dictionary will have a
set of keys and values to store the rule attributes. These attributes have be defined
above.
1 database = [{ ” p o l i c y i d ” : ”” , ” policy name ” : ”” , ” r u l e s ” : [{ ” r u l e i d ” : ”” ,
2 ” protocol ” : ”” ,
3 ” src ip range min ” : 0 ,
4 ” src ip range max ” : 0 ,
5 ” src port range min ” : 0 ,
6 ” src port range max ” : 0 ,
7 ” dest ip range min ” : 0 ,
8 ” dest ip range max ” : 0 ,
9 ” dest port range min ” : 0 ,
10 ” dest port range max ” : 0 ,
11 ” action ” : ”” } ] } ]
12
13
Listing 5.3: Normalised Data Structure
52
63. 5.4.2 Conflict Data Structure
The Conflict Data Structure is similar to the Normalised Data Structure with some
key differences such as the Data Structure is holding a pair of conflicting rules. It
doesn’t contain policy information, it contains the conflict ID, the type of conflict
and the two conflicting rules.
Conflict Data Structure Design
Figure 5.3 displays the Conflict Data Structure Design as a UML representation.
Figure 5.3: Conflict Database Design
As we can see in Listing 5.4 the implementation of the data structure is similar
to the normalised database but with the changes detailed above.
1 database = [{ ” c o n f l i c t i d ” : 0 , ” c o n f l i c t ” : c o n f l i c t , ” r u l e s ” : [{ ” r u l e i d ” : ”” ,
2 ” protocol ” : ”” ,
3 ” src ip range min ” : 0 ,
4 ” src ip range max ” : 0 ,
5 ” src port range min ” : 0 ,
6 ” src port range max ” : 0 ,
7 ” dest ip range min ” : 0 ,
8 ” dest ip range max ” : 0 ,
9 ” dest port range min ” : 0 ,
10 ” dest port range max ” : 0 ,
11 ” action ” : ”” } ] } ]
12
13
Listing 5.4: Conflict Data Structure
53
64. 5.5 Security Groups Discovery Agent
5.5.1 Security Groups Discovery Agent Introduction
As we will see there are various steps when constructing the discovery agent for the
Security Groups which reside in the neutron service. To obtain the Security Group
policies from the neutron service, there are two options:
1. Command Line Client
2. OpenStack Python SDK
Research was done to decided which option was best, in relation to the project
goals. The tools were going to be created in Python and the Python API provided
the correct command to access the policies. A decision was made to move forward
with the Python SDK rather then the Command Line Client.
5.5.2 OpenStack Python SDK
The OpenStack Python SDK provides a range of python commands that let an
OpenStack Administrator to manipulate the neutron service. It provides facilities
to create networks and list attributes of the network.
5.5.3 Discovering the Security Group Policies
Listing 5.5 demonstrates how the Security Group Discovery Agent accesses the Secu-
rity Group Polices from the Neutron service. Once the Discovery Agent has obtained
the Security Group Policies, its steps through each policy as shown in Listing 5.5.
As we can also see the Discovery Agent steps through each rule within the policy in
sequence. The code in Listing 5.5 allows the Discovery Agent access to each policy
with the OpenStack Network and rules within each policy. This will allow for a
normalisation process to take place on the rules and allow them to be added to a
data structure, this will be detailed later on in this chapter.
1 #This function a c c e s s e s the Security Group P o l i c i e s from the Neutron Service .
2 def a d d s e c u r i t y g r o u p p o l i c e s t o d a t a b a s e () :
3 try :
4 #Accesses the Neutron Service and s t o r e s the l i s t of p o l i c i e s
5 #within a v a r i a b l e .
6 s e c u r i t y g r o u p r u l e s l i s t = Database . neutron . l i s t s e c u r i t y g r o u p s ()
7 #Loops through each p o l i c y .
8 f o r s e c u r i t y in s e c u r i t y g r o u p r u l e s l i s t [ ’ s e c u r i t y g r o u p s ’ ] :
9 #Loops through each r u l e with the Security Group Policy .
10 f o r r u l e s in s e c u r i t y [ ’ s e c u r i t y g r o u p r u l e s ’ ] :
11 except AttributeError :
12 print ( ” Error a d d s e c u r i t y g r o u p p o l i c e s t o d a t a b a s e ” )
Listing 5.5: Discovering the Security Group Policies
54
65. 5.5.4 Discovering the Instance IPs
We also required the IP address of the instance that the Security Group is at-
tached to. This is so that we can perform Inter Anomaly Analysis. Unfortunately
the Python command that returns the Security Group Policies within Listing 5.5
doesn’t return the IP address of the instance that the Security Group is attached to.
Unfortunately there isn’t any Python command which will provide this information.
So Listing 5.6 displays a purpose built function that will return the IP address in
an instance when you pass in the Security Group Policy ID.
The Function in Listing 5.6 uses two command line commands to obtain the
instance IP. The first command will obtain a list of the instance IP addresses and
port IDs associated with the addresses. We use the port IDs within the second
command which returns a Security Group ID which we have to access within the
returned product. As seen in Listing 5.6 a conditional test is completed to check
if the Security Group Policy ID passed into the function matches the the Security
Group Policy ID obtained from the second command. If they match we can deduce
that the instance IP is associated with the instance that the Security Group Policy
is attached to. The function will return the correct instance IP to the discovery
agent.
1 #Using a Policy id , the function obtains the instance id
2 #that the s e c u r i t y group i s attached to .
3 def g e t i n s t a n c e i p ( p a s s e d i n s e c u r i t y g r o u p i d ) :
4 try :
5 #Obtains the l i s t of instance i p s .
6 f l o a t i n g i p l i s t r e s u l t = subprocess . Popen ( [ ” neutron ” , ” f l o a t i n g i p −l i s t ” ,
7 ”−f ” , ” json ” ] , stdout=subprocess . PIPE) . communicate () [ 0 ]
8 f l o a t i n g i p l i s t = json . loads ( f l o a t i n g i p l i s t r e s u l t )
9 #Loops through each instance ip .
10 f o r d e t a i l in f l o a t i n g i p l i s t :
11 #Assigns values into v a r i a b l e s
12 f i x e d i p a d d r e s s = d e t a i l [ ’ f i x e d i p a d d r e s s ’ ]
13 p o r t i d = d e t a i l [ ” p o r t i d ” ]
14 #Uses the port id obtained to get the s e c u r i t y group assocated
15 #with the instance ip .
16 p o r t s h o w r e s u l t = subprocess . Popen ( [ ” neutron ” , ” port−show” , port id ,
17 ”−f ” , ” json ” ] , stdout=subprocess . PIPE) . communicate () [ 0 ]
18 port show = json . loads ( p o r t s h o w r e s u l t )
19 #Loops through and obtains s e c u r i t y group id and compares the id to the
20 #s e c u r i t y group id that was passed into the function .
21 #I f the id ’ s are the same , return the id .
22 f o r d e t a i l in port show :
23 i f d e t a i l [ ” Field ” ] == ” s e c u r i t y g r o u p s ” :
24 s e c u r i t y g r o u p i d = d e t a i l [ ”Value” ]
25 i f s e c u r i t y g r o u p i d == p a s s e d i n s e c u r i t y g r o u p i d :
26 f i x e d i p a d d r e s s +=”/32”
27 return f i x e d i p a d d r e s s
28 except AttributeError :
29 print ( ” Error ” )
Listing 5.6: Discovering the Instance IP Function
55
