Bug 1284080 - [RFE] Overercloud Nodes Should Have Basic iptables Ruleset
[RFE] Overercloud Nodes Should Have Basic iptables Ruleset
Status: CLOSED DUPLICATE of bug 1274196
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 8.0 (Liberty)
Assigned To: chris alfonso
yeylon@redhat.com
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-20 13:30 EST by Dan Sneddon
Modified: 2016-04-26 09:38 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-23 07:48:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Sneddon 2015-11-20 13:30:27 EST
Description of problem:
OSP-Director installs the overcloud nodes with open firewall rules. This leaves the provisioning interface (which is typically the default gateway for Overcloud nodes) vulnerable to port scans and attacks on non-ssh ports and services. We should apply a basic deny all rule, and then add rules to allow connections to certain ports.

We shouldn't be accepting all traffic by default. Generally the Overcloud is accessed via the Public API, and the APIs listening on the provisioning network are just for local access from the Undercloud. We might want to limit traffic to the control plane VIP on the provisioning network to the local subnet by default.

Version-Release number of selected component (if applicable):
OSP 7
OSP 8 Beta 1

Actual results:
The firewall is completely open. I can open up and connect remotely to arbitrary ports:

[heat-admin@overcloud-controller-0 ~]$ sudo nc -l -p 44

[stack@instack ~]$ nc 192.0.2.19 44
asdf
^C 

[heat-admin@overcloud-controller-0 ~]
asdf

Expected results:
The ssh port and ICMP should be open to remote connections, but the rest of the ports should probably not be open by default. This should be configurable, however, as there will be deployments where the APIs need to be accessible from local networks outside the provisioning network.

Another reasonable approach (though slightly less secure) is 

Additional info:
There is a TripleO patch that has gone through many revisions. Once it merges, it may be possible to use Heat to configure the iptables firewall for the provisioning network. This will need to be documented and sane defaults developed. https://review.openstack.org/#/c/191195
Comment 2 Dan Sneddon 2015-11-20 13:32:17 EST
(In reply to Dan Sneddon from comment #0)

Unfinished sentence under Expected Results above:

Another reasonable approach (although slightly less secure) is to leave the API ports open, but apply a default DENY policy so that other unknown ports are not left open.
Comment 3 Mike Burns 2015-11-23 07:48:53 EST

*** This bug has been marked as a duplicate of bug 1274196 ***

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