[Openstack] [OSSN 0029] Neutron FWaaS rules lack port restrictions when using protocol 'any'

Nathan Kinder nkinder at redhat.com
Mon Sep 29 19:39:21 UTC 2014


-----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-security at lists.openstack.org OpenStack
> Security Group : https://launchpad.net/~openstack-ossg
> 
> _______________________________________________ Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post
> to     : openstack at lists.openstack.org Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUKbVpAAoJEJa+6E7Ri+EVSB0H/0CA1GqqdG3TaM0vIqvBPXJM
PKlmkdD3L2oZPFKliA0sH4X5nmTVzky9/WYYQG32w/9+4K9p4s/gfZL2H57YF7xF
yYz8dB9w5zppugWio02qaAeRzrUmIaKujsJsqpmYIKckGdBqstJjUpAXasZ5MWv+
TKwTXzUofyaQLRt9ACZ4uR904kksCwY6QBYSPXTWWJ/sALcu/IemGmdo975OmxIU
w8wdVfAtPHp/GQhbzS9PAAzrbTvNG8Er148xBHeInjd0tgIIWa0gpMeP/v8yb9IW
NGvwKJ3JsiUwzIL1HdfULH+VvfQRxhniCEubAFcYeFpvwOolOUrx0DbX/XepGuc=
=FbOu
-----END PGP SIGNATURE-----




More information about the Openstack mailing list