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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev