Bug 1268413
| Summary: | security groups iptables can block legitimate traffic as INVALID | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Benjamin Schmaus <bschmaus> | ||||||
| Component: | openstack-neutron | Assignee: | Nir Magnezi <nmagnezi> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Alexander Stafeyev <astafeye> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6.0 (Juno) | CC: | amuller, chrisw, dmaley, jlibosva, lpeer, nyechiel, oblaut, sputhenp, yeylon | ||||||
| Target Milestone: | async | Keywords: | ZStream | ||||||
| Target Release: | 6.0 (Juno) | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | openstack-neutron-2014.2.3-23.el7ost | Doc Type: | Bug Fix | ||||||
| Doc Text: |
Cause:
The Linux iptables implementation of security groups includes a default rule to drop any INVALID packets.
Before this fix, User-defined iptables rules were processed before the INVALID DROP rule.
Consequence:
Security groups iptables can block legitimate traffic, such as SCTP protocol, as INVALID.
Fix:
Process user-defined iptables rules before the INVALID DROP rule.
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 1269849 1338971 (view as bug list) | Environment: | |||||||
| Last Closed: | 2015-10-29 11:39:36 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1269849, 1338971 | ||||||||
| Attachments: |
|
||||||||
|
Description
Benjamin Schmaus
2015-10-02 18:58:34 UTC
Proposed fix:
- --- iptables_firewall.py 2015-10-02 11:17:12.643029791 -0500
+++ iptables_firewall.py.new 2015-10-02 11:18:11.224579502 -0500
@@ -425,7 +425,6 @@
def _convert_sgr_to_iptables_rules(self, security_group_rules):
iptables_rules = []
- - self._drop_invalid_packets(iptables_rules)
self._allow_established(iptables_rules)
for rule in security_group_rules:
if self.enable_ipset:
@@ -454,6 +453,7 @@
args += ['-j RETURN']
iptables_rules += [' '.join(args)]
+ self._drop_invalid_packets(iptables_rules)
iptables_rules += ['-j $sg-fallback']
return iptables_rules
Added upstream bug and patch. Hi Assaf, Assuming this is possible with iptables (and AFAIK it is), why not explicitly add SCTP as a classification option under Neutron's security-group? Although not common on the enterprise, allowing SCTP is a common request on the carrier/NFV space. Thanks, Nir Created attachment 1080203 [details] before_and_after.txt (In reply to Nir Yechiel from comment #4) > Hi Assaf, > > Assuming this is possible with iptables (and AFAIK it is), why not > explicitly add SCTP as a classification option under Neutron's > security-group? Although not common on the enterprise, allowing SCTP is a > common request on the carrier/NFV space. > > Thanks, > Nir nyechiel, The implementation is actually not far from what you suggest. It is possible to add SCTP rule by protocol number (via CLI), and it will be processed before the INVALID DROP rule. snipped from commit message: "Process user-defined iptables rules before the INVALID DROP". see the attached example. I'm leaving the needinfo as-is in case amuller has something to add. @Nir Yechiel - Does that mean there is a potential workaround via the CLI and what would that look like then? We need to backport the patch, then you'll be able to add a specific accept rule for your SCTP traffic. Without the patch that won't work because of the way the iptables rules are ordered: First we catch INVALID packets, then we go through the rest of the chains. What the patch does is reorder the rules, so that your SCTP accept rule will be first, and the INVALID rule second. Created attachment 1084372 [details] verification.txt Adding the content of comment #12 as an attachment, since the paste will eventually expire. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1950.html |