Multiple services exposed over network

[Adam Heczko]

Observed on Fuel master:
  release: "8.0"
  openstack_version: "2015.1.0-8.0"
  api: "1.0"
  build_number: "264"

Problem description:
It was observed that multiple services are exposed over network making possible attack or unexpected interaction easy to trigger.
Note that Fuel allows to define 2 network interfaces, and if two interfaces configured, these services are exposed on both (all) network interfaces.
This should be avoided as there is no need to expose these services on networks other than admin/PXE.

[root@fuel ~]# netstat -anp | grep LISTEN | grep -v LISTENING
tcp 0 0 10.20.0.2:5672 0.0.0.0:* LISTEN 19523/beam
tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 18667/python
tcp 0 0 0.0.0.0:8777 0.0.0.0:* LISTEN 9544/python
tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 4973/rsync
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 11462/nginx: master
tcp 0 0 0.0.0.0:4369 0.0.0.0:* LISTEN 19511/epmd
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 16310/dnsmasq
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1068/sshd
tcp 0 0 10.20.0.2:15672 0.0.0.0:* LISTEN 19523/beam
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 3544/postgres
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1540/master
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 11462/nginx: master
tcp 0 0 0.0.0.0:35357 0.0.0.0:* LISTEN 18667/python
tcp 0 0 0.0.0.0:41055 0.0.0.0:* LISTEN 19523/beam
tcp 0 0 127.0.0.1:25151 0.0.0.0:* LISTEN 11095/python2
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 11462/nginx: master
tcp 0 0 0.0.0.0:8001 0.0.0.0:* LISTEN 8077/uwsgi
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 7480/rsyslogd
tcp6 0 0 :::873 :::* LISTEN 4973/rsync
tcp6 0 0 :::61613 :::* LISTEN 19523/beam
tcp6 0 0 :::80 :::* LISTEN 6768/httpd
tcp6 0 0 :::53 :::* LISTEN 16310/dnsmasq
tcp6 0 0 :::22 :::* LISTEN 1068/sshd
tcp6 0 0 ::1:25 :::* LISTEN 1540/master
tcp6 0 0 :::443 :::* LISTEN 6768/httpd
tcp6 0 0 :::514 :::* LISTEN 7480/rsyslogd

Solution proposal:
Try to make these services to listen only on admin/PXE network.
The only services expected to listen on 0.0.0.0 (0:::) are nginx and sshd

[Alex Schultz (alex-schultz)]

This should be cross checked against the iptables rules on the fuel master as I'm not sure this bug is 100% accurate. Additionally things like DNS, NTP, rsyslog must be available as well.

[Alex Schultz (alex-schultz)]

Correction, those services might need to be available as well. We will just need to verify what is currently allowed.

[Stanislaw Bogatkin (sbogatkin)]

I check those ports with last ISO. Next looks not nice for me:
67, 69, 5000, 35357 is accepted for all, listen on 0.0.0.0
41055 is blocked by default rule, we have not explicit rule for this port, listen on 0.0.0.0
514 for non-admin interface blocked by default rule.

[Adam Heczko (aheczko-mirantis)]

Hello Stanislav, I've created the related ticket to track Fuel's firewall refactor:
https://bugs.launchpad.net/fuel/+bug/1524750

The main concern in this ticket is related to services listening on 0.0.0.0 / 0::: :
rabbitmq/epmd/beam , rsync, dnsmasq, postgres

[Stanislaw Bogatkin (sbogatkin)]

After talking with guys, next things revealed:

we need 67 and 69 opened for multirack.
Need 5000 and 35357 due to https://bugs.launchpad.net/fuel/+bug/1521955

So, there is no much sense to create 514 and 41055 explicitly as those ports already blocked by default rule. I closing this bug as 'invalid'.