-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An update for this Security Note has been published to clarify that Neutron's FWaaS extension is still experimental. The updated version of OSSN-0029 is available here:
https://wiki.openstack.org/wiki/OSSN/OSSN-0029 Thanks, - -NGK On 09/24/2014 09:58 AM, Nathan Kinder wrote: > Neutron FWaaS rules lack port restrictions when using protocol > 'any' --- > > ### Summary ### A bug in the Neutron FWaaS (Firewall as a Service) > code results in iptables rules being generated that do not reflect > desired port restrictions. This behaviour is triggered when a > protocol other than 'udp' or 'tcp' is specified, e.g. 'any'. > > The scope of this bug is limited to Neutron FWaaS and systems built > upon it. Security Groups are not affected. > > ### Affected Services / Software ### Neutron FWaaS, Grizzly, > Havana, Icehouse > > ### Discussion ### When specifying firewall rules using Neutron > that should match multiple protocols, it is convenient to specify a > protocol of 'any' in place of defining multiple specific rules. > > For example, in order to allow DNS (TCP and UDP) requests, the > following rule might be defined: > > neutron firewall-rule-create --protocol any --destination-port 53 > \ --action allow > > However, this rule results in the generation of iptables firewall > rules that do not reflect the desired port restriction. An example > generated iptables rule might look like the following: > > -A neutron-l3-agent-iv441c58eb2 -j ACCEPT > > Note that the restriction on port 53 is missing. As a result, the > generated rule will match and accept any traffic being processed by > the rule chain to which it belongs. > > Additionally, iptables arranges sets of rules into chains and > processes packets entering a chain one rule at a time. Rule > matching stops at the first matched exit condition (e.g. accept or > drop). Since, the generated rule above will match and accept all > packets, it will effectively short circuit any filtering rules > lower down in the chain. Consequently, this can break other > firewall rules regardless of the protocol specified when defining > those rules with Neutron. They simply need to appear later in the > generated iptables rule chain. > > This bug is triggered when any protocol other than 'tcp' or 'udp' > is specified in conjunction with a source or destination port > number. > > ### Recommended Actions ### Avoid the use of 'any' when specifying > the protocol for Neutron FWaaS rules. Instead, create multiple > rules for both 'tcp' and 'udp' protocols independently. > > A fix has been submitted to Juno. > > ### Contacts / References ### This OSSN : > https://wiki.openstack.org/wiki/OSSN/OSSN-0029 Original LaunchPad > Bug : https://bugs.launchpad.net/neutron/+bug/1365961 OpenStack > Security ML : openstack-secur...@lists.openstack.org OpenStack > Security Group : https://launchpad.net/~openstack-ossg > > _______________________________________________ OpenStack-dev > mailing list OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUKbWMAAoJEJa+6E7Ri+EVhn4H/3i6o52SNZQsE6eofCWJag1h GK4rECMuCw1TTe1a8mT0zrA9vigxZFlnpjfb/mXfFprQG4365VuqxxOFN1gimN+Q xG8oFrm32RhEGi45FAbJr5g00LbemfNCVrJO+GJMSRjv3WykClwXz2HN13OAvejO KkTaTeLKJQoPjLP1qeAb0Ihce8wR+pgAE+2g0MuaWBbZUIVZXK5CVvfU6NpBzat7 QoFLI9G+mUAHN8faGm15NvslkH+s5wzm9PDhE0ASOUzjKcaSFgLBcNiMTG2dCvjX 7SLrsYQErQop3LwQOpVlfnmhgTA96m5QsN3DaF1RAeAKSf7WU2yeYSujGtBdpes= =tPf/ -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
