[openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project

Sumit Naiksatam sumitnaiksatam at gmail.com
Thu May 8 04:03:35 UTC 2014


Hi Mike,

Thanks for your input and welcome to the OpenStack community! Your
research area is pretty interesting, and you are right, we are kind of
in unchartered territory as far as the definition of Firewall as a
Service (FWaaS) in an IaaS context is concerned. Our FWaaS API has
evolved based on input from vendors, operators, and of course the
reviewers in the OpenStack community. So I am just as thrilled to hear
that the API and resource model abstraction we have chosen resonates
with your research which was performed independently.

Apart from discussing on the mailing list, we have weekly IRC meetings
for FWaaS and you are welcome to join these to contribute your ideas
and discuss with the rest of the team:
https://wiki.openstack.org/wiki/Meetings/FWaaS

You can find us on #openstack-neutron IRC channel as well.

It's also interesting that you bring up the separation of concerns
between the application deployers (VM admin as you call it) and the
tenant (infra) admin. While your body of work addresses the policy
enforcement piece, there is a complementary aspect of policy
definition which needs to be expressed prior to the enforcement. In
that context, I would also like to draw your attention to the Group
Policy work we are doing in Neutron
(https://wiki.openstack.org/wiki/Neutron/GroupPolicy). This provides
the user with a declarative framework to specify policy for
connectivity. The separation between app deployer and infra admin
roles in inherent to this model, and allows elegant handling of use
cases such as the compromised/infected VMs that you mentioned.

Thanks,
~Sumit.


On Wed, May 7, 2014 at 2:51 PM, Michael Grima <mike.r.grima at gmail.com> wrote:
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list