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