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
Hi, Please find reply in line .. Thanks regards, Keshava.A -Original Message- From: Mike Grima [mailto:mike.r.gr...@gmail.com] Sent: Thursday, May 22, 2014 3:55 PM To: A, Keshava Cc: OpenStack Development Mailing List (not for usage questions) Subject: 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... Keshava: Yes that's correct 2.) Group Policy does support a Hierarchy. (Is this correct?) Keshava: Yes that's 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
Hi Mike. I think we still owe you a response to your earlier email as we recover from the summit but let me address your current questions below. On May 22, 2014, at 6:55 PM, Mike Grima mike.r.gr...@gmail.com wrote: 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. 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. 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. — 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... So you may reconsider how you group your endpoints into groups so you can apply policies to groups of endpoints with similar characteristics/roles. 2.) Group Policy does support a Hierarchy. (Is this correct?) Yes. A contract can have another as a child contract. 3.) On a separate note: Is the Group Policy feature exposed via a RESTful API akin to FWaaS? Yes, That's the plan for the group policy extension similar to other extensions. 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 ___ 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
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
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, 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
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project
Sumit, I am in the process of wrapping up my thesis, and I would like to include a section about OpenStack. However, before doing so, I will need to gain a better understanding of the relationship between the Neutron Group Policy and FWaaS. Could you provide some background on how (if?) they are related? 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
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
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project
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.
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project
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.gr...@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
[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
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project
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 From: Mike Grima mike.r.gr...@gmail.com To: openstack-dev@lists.openstack.org, Date: 05/06/2014 09:21 PM Subject:[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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
