Bug 1667887 - Dangerous iptables rules are kept after the deploy (v4 and v6)
Summary: Dangerous iptables rules are kept after the deploy (v4 and v6)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 15.0 (Stein)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Cédric Jeanneret
QA Contact: Gurenko Alex
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-21 10:49 UTC by Cédric Jeanneret
Modified: 2019-01-28 13:53 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-28 13:53:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1812695 0 None None None 2019-01-21 16:29:40 UTC
OpenStack gerrit 632117 0 None MERGED Ensure we get a clean firewall 2020-07-22 15:04:50 UTC

Description Cédric Jeanneret 2019-01-21 10:49:44 UTC
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-prohibited

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-prohibited


We need to:
- find out what pushed those rules at the first place
- find the best way to drop them

For the first one, I think it comes from the iptables-services package, as it adds the capability to save/restore iptables rules, and pushes the /etc/sysconfig/ip6tables and /etc/sysconfig/iptables files, with those very default rules.

For the second step, I'd propose to do a prep_host_tasks that will, with the ansible "iptables" module, drop the rules namely (instead of a big flush that will create more issues than anything).

Dropping those rules at an early stage would be possible IFF the iptables-services package is installed prior all of that (namely, if it's a dep of a tripleo package, for instance puppet-iptables package?) - and we can do this dropping without any risk since the INPUT policy is to accept anything anyway.

What do you think?

Cheers,

C.

Comment 1 Cédric Jeanneret 2019-01-21 11:06:48 UTC
Additional note: priori undercloud deploy, iptables INPUT table is empty. Digging for the cause of those nasty rules.

Comment 2 Cédric Jeanneret 2019-01-21 11:24:10 UTC
OK, so more digging results:
- package iptables-service is installed by puppetlabs-firewall (included by puppet-tripleo)
- that very same puppetlabs-firewall activate the service that pushes the default rules

This means: we will need to do the changes in puppet-tripleo, NOT as a prep_host_task in ansible. We probably want to push that in the tripleo::firewall::pre class directly.

Comment 3 Cédric Jeanneret 2019-01-21 12:57:09 UTC
Some more info, digging and comments:

[root@undercloud ~]# iptables -vnL INPUT
Chain INPUT (policy ACCEPT 24 packets, 1676 bytes)
 pkts bytes target     prot opt in     out     source               destination         
[root@undercloud ~]# systemctl start iptables
[root@undercloud ~]# iptables -vnL INPUT
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    7   504 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           
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 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-prohibited
[root@undercloud ~]# systemctl stop iptables
[root@undercloud ~]# iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

[root@undercloud ~]# cat /etc/sysconfig/iptables
# sample configuration for iptables service
# you can edit this manually or use system-config-firewall
# please do not ask us to add additional ports/services to this default configuration
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT


So, basically, I think we should:
- manage the iptables-services package install on our own (in t-h-t, or package dependency on either python-tripleoclient or puppet-firewall for instance)
- ensure we remove all lines starting with "^-" that don't have "--comment" in it

Doing so will ensure that we:
- don't remove rules managed by puppet (the module uses the $name as a comment for each and every rule it injects)
- actually remove ALL unmanaged rules, even if a new version changes the default content

We should also ensure the policy is OK for, at least, INPUT (the :INPUT ACCEPT line) in order to avoid any lock up, although this case is not really realistic (to dangerous).

@Juan: any thoughts?
@DF: any thoughts, other ideas, leads, hints?


Note You need to log in before you can comment on or make changes to this bug.