Open Stack

Mohammad,

There are presently no published papers at this point that I can point
to. The primary "problem" with my thesis at this point is that I am
almost done, but still have about one or two more sections to go
before completing it. The major issue is more in line with the
citations (I didn't fully and properly complete them yet), and thus,
for legality reasons, I can't publish it out in the open just yet.

However, I can certainly provide more background info. What I am
primarily researching is how to make Infrastructure as a Service
(IaaS) cloud platforms more secure by creating an adaptive firewall
that resides on the KVM host. (For my thesis, I examine KVM
specifically, but the same principles in my research can equally be
applied to XEN virtual machines as well. This is shown in video #5 in
the first message)

This relies upon the concept that the guest domain is administered by
people on the outside of the hosting organization. For example, say I
lease/rent/own (or whatever terminology is applicable) a VM from a
cloud provider. I am the administrator of the VM, and I can install
and configure the VM as I see fit. The cloud operator is responsible
for maintaining the infrastructure. Because I am the administrator, I
could make and perform poor choices regarding the security of my VM.
For example, I could disable the firewall, not install patches, or
have an incredibly weak password, to name a few. How can the cloud
provider adequately protect the network resources of the adjacent
virtual machines (VM's operating on the same host), and the greater
network infrastructure? It's hard to administer a system that is
controlled by people you do not know, nor have any control over. Thus,
my research aims to provide the ability to improve the network
security of these architectures by examining the firewall that exists
on the KVM host, and making it adaptable.

To make the host firewall adaptive, the netfilter/iptables firewall on
the KVM host performs high-level firewalling for the guest domains.
The advantage of this approach is that the KVM administrator can
create and enforce policies for what is, or is not, acceptable on the
network. Furthermore, this happens outside of the actual guest domain
itself. This means that the KVM administrator need not worry about
which OS a guest domain is running, or how a guest OS is even
configured. Because these rules are processed on the host, __it does
not matter__ what the guest domain does. Additionally, the guest
domain has no knowledge that this happens, since it happens outside of
the guest's scope; it happens on the host. This is also helpful in the
event that a bad rootkit is installed on a guest VM. Because no change
is made to the guest OS itself, rootkits won't detect changes in
system configuration (the network behavior would obviously change, as
traffic is firewalled, but the OS itself remains the same).
Therefore, the rootkit will act normally, which can make it easier to
detect. This is important, since some malicious applications can
detect configuration changes, and will alter behavior to evade
detection. By relying upon the host, the guest is completely
untouched. Effectively, you can "jail" a guest VM's network
capabilities with the host's firewall.

However, netfilter by itself runs local to the system. Thus, to make
it powerful such that future appliances can dynamically and
automatically create an enforce firewall rules, I created a web
service to expose the iptables functionality to outside systems via a
RESTful API. This is effectively a "Firewall as a Service". This
allows, for example, vulnerability scanners to probe the network for
vulnerabilities in the infrastructure, and dynamically create firewall
rules to close them on the VM's host. This happens without making a
single modification to the guest OS itself, thus, you are preserving
the integrity of the guest OS. Therefore, by exposing the firewall's
capability, the network infrastructure can be better secured, with
organizational network policies actually enforceable on the guest
domains.

I began the research in November/December of 2012, and had a rough
working prototype by the end of January, 2013. I noticed that the
OpenStack community started examining the FWaaS concept in Feb 2013,
and it is refreshing to see that a lot of the decisions I made with
regards to the organization of my API (which is in NO WAY a production
quality defined API) were actually correct and organized similarly in
the OpenStack FWaaS API. So far, during my research, I have seen no
other FWaaS type of components out there. The OpenStack project is the
only one that I have seen that is actually attempting to expose the
firewall capabilities of the host system with an extensible RESTful
API. However, it appears from the documentation, that OpenStack is
looking from the perspective of administering large sets of VM's,
whereas I am looking from the perspective of policy enforcement and
closing network vulnerabilities. I think there is significant value to
both perspectives, and only makes the FWaaS effort more worthwhile.

I apologize for the long email... However, please feel free to ask
more questions if that is still too vague. I expect to be done with
the write-up by hopefully the end of June.

Thank You

>Hi Mike, Thanks for your interest in OpenStack and Neutron. Are there any
>published papers you can point us to? It may be easier to understand your
>work by reading/reviewing your papers.

>Best,
>
>Mohammad


-- 
Mike Grima, RHCE