Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis and OpenStack Applicability - UPDATED
For whatever reason, this wasn’t linked appropriately to the older post in the list. That post is here: http://lists.openstack.org/pipermail/openstack-dev/2014-August/042981.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project
Mohammad, My responses are inline: Let's start from the question about Deny. There are no Deny actions. By default there is no connectivity. If you want to establish that you do it with Allow or other actions; otherwise no connectivity. Hence no need to have Deny. This makes sense. The policies generally apply to the whole group. The idea is to simplify the use of contract and policy rules by applying them to a group of like minded :) endpoints. So you may reconsider how you group your endpoints into groups so you can apply policies to groups of endpoints with similar characteristics/roles. This makes sense. Group-level policies should be applied to the entire group. So, am I correct in saying that policies can _only_ be applied to entire groups, and not individual VM’s within a group? This makes the assumption that each VM _does not_ have a unique group akin to users on most Linux systems. For example, you have a VM named VM1. VM1 is a member of one group, web servers. There is no unique group named: VM1 The last post seemed to indicate that you can apply policies to specific VM’s within a group. Lastly, what is the relationship between group policies and FWaaS? Thank You, Mike Grima, RHCE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project
Hello, Just to make sure I understand: 1.) I’m assuming that you can dilettante which policies apply to specific VM’s within a group (Is this correct?). With regards to DENY permissions, they are handled specially. In such a case, all other VM’s are provided with ALLOW permissions for that rule, while the destined VM for the DENY policy is provided with a DENY. — Would you necessarily want to automatically provide all other VM’s with an ALLOW privilege? Not all VM’s in that group may need access to that port... 2.) Group Policy does support a Hierarchy. (Is this correct?) 3.) On a separate note: Is the Group Policy feature exposed via a RESTful API akin to FWaaS? Thank you, Mike Grima, RHCE On May 22, 2014, at 2:08 AM, A, Keshava keshav...@hp.com wrote: Hi, 1. When the group policy is applied ( across to all the VMs ) say deny for specific TCP port = 80, however because some special reason one of that VM needs to 'ALLOW TCP port' how to handle this ? When deny is applied to any one of VM in that group , this framework takes care of individually breaking that and apply ALLOW for other VM automatically ? and apply Deny for that specific VM ? 2. Can there be 'Hierarchy of Group Policy ? Thanks regards, Keshava.A -Original Message- From: Michael Grima [mailto:mike.r.gr...@gmail.com] Sent: Wednesday, May 21, 2014 5:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project Sumit, Unfortunately, I missed the IRC meeting on FWaaS (got the timezones screwed up...). However, in the meantime, please review this section of my thesis on the OpenStack project: https://docs.google.com/document/d/1DGhgtTY4FxYxOqhKvMSV20cIw5WWR-gXbaBoMMMA-f0/edit?usp=sharing Please let me know if it is missing anything, or contains any wrong information. Also, if you have some time, please review the questions I have asked in the previous messages. Thank you, -- Mike Grima, RHCE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project
Sumit, Thank you for the kind words. I will try to attend the next IRC meeting on Wednesday. I’ll also take a look at the Neutron Group Policy, and see if my research applies. Thank You, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project
Sumit, I have very briefly looked at the Neutron Group Policy documentation. I have a few questions and points: 1.) My Firewall Web Server component shares some similar functionality with regards to Firewall rules. In my system, the policies are composed of several firewall commands (actual iptables commands), and they can be applied to any VM on the system (KVM host). 2.) From the brief overview of the documentation, it was not clear if you guys have a priority-based list. For such a list, you would want rules made by the customer at the lowest priority, and rules by the “infra admin” to be the highest priority, with the ability to over-write the rules of the customer (in this system, the customer is _not_ always right). 2a.) I have a system of command ordering/priority implemented in that commands within each policy are ordered. Policies themselves are not ordered, and policies in my system should be atomic to avoid collisions. Policies have an implicit order such that the commands of the policy can pick their location in the iptables chain. It’s a quick and possibly simple way to implement policy priority. As an example, policies and rules created by a vulnerability scanner after detecting a vulnerability would take precedence over other “colliding” policies, since those rules would make use of iptables commands with the '-I 1’ flags. This places those iptables rules at the top of the chain. Other, non-priority policies make use of ‘-A’ switches to simply append the firewall rules to the end of the appropriate chain. This is actually demonstrated in vulnerability scanning videos I posted earlier. 3.) How are the Group Policy rules exposed? Do you presently have web services available for other systems to alter policies? For example, in my thesis, I have the video (referenced in my first post) where I have OpenVAS detect the Heartbleed vulnerability, and then use the exposed web services to automatically generate a rule to close off the port on the vulnerable VM via the host. 3a.) Going along with the previous question, what is the relationship between the Neutron Group Policy and FWaaS? Does FWaaS expose the Group Policy capabilities, or does FWaaS simply provide firewall capabilities outside the purview of group policies? Does the GP module depend on FWaaS? 4.) From the brief documentation I read for FWaaS, my research appears to be a mixture of both components. This includes the exposure of firewall capabilities, and the arrangement of firewall rules classified as policies designed to control certain behaviors, albeit at the firewall level only. My research does not address the overall networking of the infrastructure, such as the establishment of routes, virtual bridges, etc. 5.) Slide 16 in the Neutron Group Policy presentation is definitely one of the main advantages to both of our approaches, and one of the main focal points of my thesis. Thank You, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project
Hi Everyone, I am an Information Security grad student, and I am wrapping up a thesis on exposing host firewall capabilities via web services for KVM virtual machines. The purpose of which is to: A. Make the firewall management of KVM virtual machines easier to perform on the host (from the KVM administrator’s perspective) B. Provide the ability to enforce network security policies on hosted virtual machines via the host’s firewall. C. Provide the ability for future security appliances and vulnerability scanners to leverage the exposed web services to close network security vulnerabilities on hosted virtual machines (via modification of the host’s firewall rules). This can allow security appliances to automatically respond to security incidents as they occur. I just recently stumbled upon the OpenStack project, and noticed the Firewall as a Service (FWaaS) plugin and documentation that has been developed this past year. There are a lot of similarities to my thesis, and I would like to know if some of the research I have performed could be of value to the OpenStack project. Perhaps they could be useful in the development of use cases, or maybe inspire future ideas for enhancements and features? I am still in the process of wrapping up the thesis, so I would like to avoid posting it for the time being. However, once I have completed the write-up, I would be more than happy to share it with the OpenStack community. I have recorded screen videos showcasing the above three points in action. Perhaps the most relevant to recent events is the 4th video, which showcases how FWaaS (in general, not the OpenStack plugin) could be used by OpenVAS (in this case) to detect virtual machines that are vulnerable to Heartbleed, and immediately issue a command to the web service to close access to the HTTPS port. The web-services are being exposed via a Java Jetty web server running on the KVM host itself. I made a Java client app for interfacing with the web services. Below are the videos: 1.) Demo 1: Adding new rules/policies and manipulating traffic https://docs.google.com/file/d/0B7WyzOL96X9QU0dQa0xEekFxVlk/edit 2.) Demo 2: Same as Demo 1, but showcasing platform independence by applying rules to a Windows Server 2008 R2 VM https://docs.google.com/file/d/0B7WyzOL96X9QMnRaZXBhU1FFc28/edit 3.) Sample OpenVAS Scenario where a VM can --only-- operate a HTTP server on port 80. Any other server that is detected is a violation of policy and would need to be blocked. https://docs.google.com/file/d/0B7WyzOL96X9QYXdFdC1XbHp2R3M/edit 4.) OpenVAS Heartbleed Demo (as described above): https://docs.google.com/file/d/0B7WyzOL96X9QMzRMR1UzX09vRDA/edit 5.) Earlier prototype of my thesis working with XEN instead of KVM: https://docs.google.com/file/d/0B7WyzOL96X9QTVowem1ZYjJrRWM/edit Please let me know if the above could prove useful for the OpenStack project. Concurrence from you guys would be helpful illustrating the significance of my research. Thank You, Mike Grima, RHCE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
