This bug was initially created as a copy of Bug #1704592 I am copying this bug because: Need a dedicated bug for puppet-tripleo backport on rocky/osp-15 This bug was initially created as a copy of Bug #1694471 I am copying this bug because: Need dedicated bug on osp-14 for backport. Description of problem: The current default configuration set by director for SSH access opens SSH for all the remote subnets: +++ [root@overcloud-controller-0 ~]# iptables -S | grep -i ssh -A INPUT -p tcp -m multiport --dports 22 -m state --state NEW -m comment --comment "003 accept ssh ipv4" -j ACCEPT [root@overcloud-controller-0 ~]# iptables -t filter -vnL | grep -i ssh 1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 state NEW /* 003 accept ssh ipv4 */ [root@overcloud-controller-0 ~]# netstat -tnpl | grep -i ssh tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 5268/sshd tcp6 0 0 :::22 :::* LISTEN 5268/sshd +++ This leaves the nodes vulnerable to brute force attacks. The allowed remote subnets should be restricted to required subnets only like provisioning and internal_api subnets. Do we currently have a way to achieve this in a already running environment ? It is a known fact that iptable rules can be modified with tripleo templates; however we are unsure as to which subnets should be left open for ssh access. Some guidance is required here for restrict the SSH access without breaking the current functionality. Version-Release number of selected component (if applicable): [root@undercloud13 ~]# rpm -qa | grep -i tripleo-heat openstack-tripleo-heat-templates-8.0.7-21.el7ost.noarch [root@undercloud13 ~]# rpm -qa | grep -i puppet-tripleo puppet-tripleo-8.3.6-7.el7ost.noarch [root@undercloud13 ~]# How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: SSH is open to all remote subnets Expected results: SSH access on the overcloud nodes should be open only to the required subnets Additional info:
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://access.redhat.com/errata/RHBA-2019:1672