[openstack-dev] [neutron] blueprint ovs-firewall-driver: OVS implementation of security groups

Amir Sadoughi amir.sadoughi at RACKSPACE.COM
Mon Jun 9 20:08:58 UTC 2014


Paul,

Beyond explicit configuration for the cloud operator, documentation and API validation for the end user, is there anything specific you would like to see as a “warning label”? Does iptables do TCP sequence number validation? Where we can, we should strive to match iptables behavior.

Regarding OVS flows and security groups, we can provide a tool to explain how security group rules are mapped to the integration bridge. In the proposed solution contained in the blueprint, security group rule flows would be distinguished from other agent’s flows via cookie.

Regarding packet logging, I don’t know if OVS is capable of it. If iptables in Neutron does not currently support that feature, I don’t think Neutron should explicitly support out-of-tree features.

Amir

On Jun 3, 2014, at 6:59 AM, CARVER, PAUL <pc2929 at att.com<mailto:pc2929 at att.com>> wrote:


Amir Sadoughi wrote:

>Specifically, OVS lacks connection tracking so it won’t have a RELATED feature or stateful rules
>for non-TCP flows. (OVS connection tracking is currently under development, to be released by 2015

It definitely needs a big obvious warning label on this. A stateless firewall hasn’t been acceptable in serious
security environments for at least a decade. “Real” firewalls do things like TCP sequence number validation
to ensure that someone isn’t hi-jacking an existing connection and TCP flag validation to make sure that someone
isn’t “fuzzing” by sending invalid combinations of flags in order to uncover bugs in servers behind the firewall.


>- debugging OVS is new to users compared to debugging old iptables

This one is very important in my opinion. There absolutely needs to be a section in the documentation
on displaying and interpreting the rules generated by Neutron. I’m pretty sure that if you tell anyone
with Linux admin experience that Neutron security groups are iptables based, they should be able to
figure their way around iptables –L or iptables –S without much help.

If they haven’t touched iptables in a while, five minutes reading “man iptables” should be enough
for them to figure out the important options and they can readily see the relationship between
what they put in a security group and what shows up in the iptables chain. I don’t think there’s
anywhere near that ease of use on how to list the OvS ruleset for a VM and see how it corresponds
to the Neutron security group.


Finally, logging of packets (including both dropped and permitted connections) is mandatory in many
environments. Does OvS have the ability to do the necessary logging? Although Neutron
security groups don’t currently enable logging, the capabilities are present in the underlying
iptables and can be enabled with some work. If OvS doesn’t support logging of connections then
this feature definitely needs to be clearly marked as “not a firewall substitute” so that admins
are clearly informed that they still need a “real” firewall for audit compliance and may only
consider OvS based Neutron security groups as an additional layer of protection behind the
“real” firewall.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140609/e62f6af2/attachment.html>


More information about the OpenStack-dev mailing list