Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Documentação do SUSE Enterprise Storage 7.1 / Security Hardening Guide / Hardening meassures / Network
Applies to SUSE Enterprise Storage 7.1

4 Network

SUSE Enterprise Storage is a complex system that communicates internally and externally via networks. As with all other systems careful design and control of this network access is vital for ensuring the security of your cluster.

While SUSE Enterprise Storage can be run with a single network connected to all nodes, it is important for security to use the setup recommended in Seção 2.1, “Visão geral da rede” and have two separate networks connected to your cluster. It is to be preferred to have physically separate networks. If this is not possible, you can use VLANs to logically separate them.

The internal network is used for replication and recovery and should not be available to clients. Unless special measures are taken (described in Chapter 7, Confidentiality) data stored on SUSE Enterprise Storage is transfered in cleartext on this network. Even when you ensure that data is transfered only in encrypted form, we highly recommend to use a dedicated network.

The public network is used as interface for clients and can be restricted to the minimal necessary access and also be monitored for anomalies.

These are the TCP ports that are necessary for various services:

  • 3300, 6789: Monitor nodes

  • 6800-7300: OSD nodes

  • 6800-7300: MGR nodes

  • 6800: MDS nodes

  • 80,443,7480: Radosgw

  • 8080,8443: Dashboard

  • 4505,4506: Administration via salt

You should ensure on a network and on a host level that these ports are only accessible to the strictest possible set of clients. All other ports should be blocked by a default-deny rule. Remember to block the ports you want to deny access to for IPv4 and IPv6 if that is enabled in your environment.

Consider your use case and then analyze what network access is necessary on each network. For example, the Ceph Dashboard usually does not need to be accessible to users and access to it can be restricted via firewalls. The RADOS Block Device, CephFS, and the Object Gateway must be available to the clients that use them. If certain services are not used, or only a limited set of users use it, you can prevent access to these ports in general or for groups that do not need access. This limits the damage that can be done if a vulnerability in this component is found.