Jump to: navigation, search

Difference between revisions of "OSSN/OSSN-0029"

(Created page with "__NOTOC__ == Neutron FWaaS rules lack port restrictions when using protocol 'any' == === Summary === A bug in the Neutron FWaaS (Firewall as a Service) code results in iptab...")
 
Line 4: Line 4:
  
 
=== Summary ===
 
=== Summary ===
−
A bug in the Neutron FWaaS (Firewall as a Service) code results in
+
A bug in the experimental Neutron FWaaS (Firewall as a Service)
−
iptables rules being generated that do not reflect desired port
+
extension results in iptables rules being generated that do not reflect
−
restrictions. This behaviour is triggered when a protocol other than
+
desired port restrictions. This behaviour is triggered when a protocol
−
'udp' or 'tcp' is specified, e.g. 'any'.
+
other than 'udp' or 'tcp' is specified, e.g. 'any'.
  
−
The scope of this bug is limited to Neutron FWaaS and systems built upon
+
The scope of this bug is limited to the experimental Neutron FWaaS
−
it. Security Groups are not affected.
+
extension and systems built upon it. It does not affect the supported
 +
core Neutron functionality. Security Groups are not affected.
  
 
=== Affected Services / Software ===
 
=== Affected Services / Software ===
Line 23: Line 24:
 
rule might be defined:
 
rule might be defined:
  
−
neutron firewall-rule-create --protocol any --destination-port 53 --action allow
+
  neutron firewall-rule-create --protocol any --destination-port 53 --action allow
  
 
However, this rule results in the generation of iptables firewall rules
 
However, this rule results in the generation of iptables firewall rules
Line 29: Line 30:
 
iptables rule might look like the following:
 
iptables rule might look like the following:
  
−
-A neutron-l3-agent-iv441c58eb2 -j ACCEPT
+
  -A neutron-l3-agent-iv441c58eb2 -j ACCEPT
  
 
Note that the restriction on port 53 is missing. As a result, the
 
Note that the restriction on port 53 is missing. As a result, the
Line 48: Line 49:
  
 
=== Recommended Actions ===
 
=== Recommended Actions ===
−
Avoid the use of 'any' when specifying the protocol for Neutron FWaaS
+
The Neutron FWaaS extension is currently experimental, and should not be
−
rules. Instead, create multiple rules for both 'tcp' and 'udp' protocols
+
used in production at this point. If you are using it, you should avoid
 +
the use of 'any' when specifying the protocol for Neutron FWaaS rules.
 +
Instead, create multiple rules for both 'tcp' and 'udp' protocols
 
independently.
 
independently.
  
−
A fix has been submitted to Juno.
+
This issue has been fixed in the Juno release of OpenStack.
  
 
=== Contacts / References ===
 
=== Contacts / References ===

Revision as of 19:31, 29 September 2014


Neutron FWaaS rules lack port restrictions when using protocol 'any'

Summary

A bug in the experimental Neutron FWaaS (Firewall as a Service) extension 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 the experimental Neutron FWaaS extension and systems built upon it. It does not affect the supported core Neutron functionality. 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

The Neutron FWaaS extension is currently experimental, and should not be used in production at this point. If you are using it, you should avoid the use of 'any' when specifying the protocol for Neutron FWaaS rules. Instead, create multiple rules for both 'tcp' and 'udp' protocols independently.

This issue has been fixed in the Juno release of OpenStack.

Contacts / References

Retrieved from "https://wiki.openstack.org/w/index.php?title=OSSN/OSSN-0029&oldid=63966"