Unmanaged iptables rules are kept after the deploy (v4 and v6)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Fix Released
|
High
|
Cédric Jeanneret |
Bug Description
Hey folks,
We apparently have a "small" issue with iptables in tripleo:
there are rules that are apparently NOT managed by puppet, and they can cause some security issues.
For instance, on an undercloud deployed against latest master packages as of today, we can see the following rules being unmanaged:
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
2 104 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-
Here, we can see SSH service is allowed world-wide, and a repetition of some other rules that are actually pushed by puppet-iptables.
Also, the last REJECT one prevent any logging to happen:
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW limit: avg 20/min burst 15 /* 998 log all ipv4 */ LOG flags 0 level 4
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW /* 999 drop all ipv4 */
And we have the same behaviour with ipv6, of course:
0 0 ACCEPT all * * ::/0 ::/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmpv6 * * ::/0 ::/0
0 0 ACCEPT all lo * ::/0 ::/0
0 0 ACCEPT tcp * * ::/0 ::/0 state NEW tcp dpt:22
0 0 ACCEPT udp * * ::/0 fe80::/64 udp dpt:546 state NEW
0 0 REJECT all * * ::/0 ::/0 reject-with icmp6-adm-
That issue has the following impact:
- unmanage rules are present after the deploy
- as they are unmanaged, we can't drop them easily or, if needed, update them (puppet-firewall relies on the comment/resource name)
- the current situation prevent any LOG to happen, since we hit the REJECT rule before any logging.
- the current situation prevent the final DROP to happen, since the REJECT is hit before
Changed in tripleo: | |
status: | Triaged → In Progress |
Changed in tripleo: | |
milestone: | none → stein-3 |
tags: | added: queens-backport-potential |
Reviewed: https:/ /review. openstack. org/632117 /git.openstack. org/cgit/ openstack/ puppet- tripleo/ commit/ ?id=f25c27aa2c6 eff327d612d163c 1758b59618d6ed
Committed: https:/
Submitter: Zuul
Branch: master
commit f25c27aa2c6eff3 27d612d163c1758 b59618d6ed
Author: Cédric Jeanneret <email address hidden>
Date: Mon Jan 21 15:05:47 2019 +0100
Ensure we get a clean firewall
The iptables-services package pushes a bunch of default rules, activated as soon
as we start the "iptables" systemd unit.
This patch intends to remove those default rules, in order to ensure we get
only managed firewall rules (either by puppet, or by any openstack service like
neutron).
In order to prevent any issue, instead of erasing the file, we actually save the
current state prior the iptables-services installation and subsequent service startup.
The iptables-services installation and activation is done at the "include ::firewall" sysconfig/ iptables and /etc/sysconfig/ ip6tables files before we include the
step.
Prior that, iptables is empty, meaning if we save, and pre-create the
/etc/
"::firewall" class, we will get an empty, clean ruleset.
Please note, this won't correct already deployed infrastructure though - that will heat-templates.
probably requires an upgrade_tasks directly in tripleo-
SecurityImpact /bugzilla. redhat. com/show_ bug.cgi? id=1667887 4ac42a0839430ae 9afe2554d16
Related: https:/
Partial-Bug: #1812695
Change-Id: I74d15b8de21698