Re: [openstack-dev] [OSSN 0029] Neutron FWaaS rules lack port restrictions when using protocol 'any'

2014-09-29 Thread Nathan Kinder
-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


[openstack-dev] [OSSN 0029] Neutron FWaaS rules lack port restrictions when using protocol 'any'

2014-09-24 Thread Nathan Kinder
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUIvg/AAoJEJa+6E7Ri+EV9bUH/RLDncR7tUCdz6jxDBECj/Uq
wGshhd0YiLaOIJ57tHQNNQedUSNOe0ErPgpSHQifb5nLYE5JvR+YK1QS3n+aM8vL
1teVJDpHU6hoJBmLD8MfB2ZodikSDT/Lfjm3SemfgVtAjHwKEzUE1vGWsq5z+8KB
I8HDffLQjPPbzgxhS0wwCoLouwP07trodg01j93uON6PwMnY4+8eRquiCpr8/dva
aqjT1eKuaTvfDKnXhiVcXDACH1uKKEgmeHKcqLYNKut8n/8F4WOSigAzwGlCDpre
9lpuTWpfIDDR6mDFgrrlanhdyQzo7SV9jupKvYnWHVr72x+E4OCSHtVXq7BLiVw=
=2m+Z
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev