Table of Contents

DataMiner hardening guide

In today’s digital landscape, properly securing your data and systems is of the utmost importance. You should therefore go beyond the out-of-the-box DataMiner configuration and take the necessary steps to make sure your DataMiner configuration is as secure as possible.

This guide will give you a comprehensive overview to help you make the necessary changes to secure your DataMiner System as much as possible.

Keep your system up to date

Your first step should be to make sure your system is always up to date. This includes the operating system and all installed software. This way, you have access to the latest security fixes and features.

To obtain the most recent version of DataMiner and related software, go to the Downloads page on DataMiner Dojo.

Use BPA tests

A good start for hardening your DataMiner System is to make use of the available BPA tests. These scan your DataMiner System for all sorts of issues and will help you resolve any detected issues.

For information on how to run these tests, refer to Running BPA tests.

From DataMiner 10.4.5/10.4.0 [CU3] onwards, you can run the Security Advisory BPA test to run all security-related checks at the same time. In earlier DataMiner versions (starting from DataMiner 10.2.12/10.3.0), the security checks are available in the following dedicated BPA tests:

After you have run a BPA test, it will provide an overview of the detected issues and point you to the right documentation to resolve them.

DataMiner Agent hardening

Secure Cube-server communication

By default, Cube currently uses .NET Remoting to communicate with DataMiner. From DataMiner 10.1.7 onwards, this communication is encrypted using the Rijndael algorithm using a 256-bit key, which is negotiated over a 1024-bit RSA encrypted communication channel. However, .NET Remoting is a legacy technology and is widely considered insecure. For this reason, DataMiner 10.3.2/10.3.0 introduces the possibility to use gRPC instead as a secure alternative.

Important

The gRPC connection feature is still a beta feature in DataMiner 10.3.2/10.3.0 CU0, which means you may still encounter issues and the connection might still be less stable than with .NET Remoting.

To enable gRPC for the client-server connection, edit the ConnectionSettings.txt file on each DataMiner Agent. For detailed information, refer to ConnectionSettings.txt.

Secure server-server communication

gRPC

For the inter-DMA communication, like for the communication with DataMiner Cube, you can also use gRPC instead of .NET Remoting from DataMiner 10.3.2/10.3.0 onwards.

Important

The gRPC connection feature is still a beta feature in DataMiner 10.3.2/10.3.0 CU0, which means you may still encounter issues and the connection might still be less stable than with .NET Remoting.

To enable gRPC for the communication between DataMiner Agents in a cluster, add redirects in DMS.xml or, from 10.3.6/10.3.0 [CU3] onwards, disable .NET Remoting completely in MaintenanceSettings.xml.

NATS

By default, NATS does not employ TLS encryption, leaving communication susceptible to eavesdropping. Consequently, we strongly recommend enabling TLS encryption for enhanced security within your NATS cluster.

DataMiner Webpages hardening

HTTPS

By default, DataMiner uses HTTP to serve the web applications. HTTP is unencrypted and vulnerable to man-in-the-middle attacks, so we highly recommend setting up HTTPS instead.

HTTP headers

When configuring HTTPS in IIS on your DataMiner Agent, we also recommend setting the following HTTP headers:

There are some other HTTP headers that can improve security. However, their value depends on your specific DataMiner setup (e.g. resources used in Dashboards/Low-Code Apps):

Disable legacy components

DataMiner has some components that are considered legacy. They are still around to support existing setups that depend on them, but if you have a new setup or you want to secure your existing setup, we recommend disabling them. Currently we recommend disabling the Annotations component and the legacy Reports and Dashboards component. You can do so by adding the following code in the C:\Skyline DataMiner\SoftLaunchOptions.xml file:

<SLNet>
   <LegacyAnnotations>false</LegacyAnnotations>
   <LegacyReportsAndDashboards>false</LegacyReportsAndDashboards>
</SLNet>

To make the changes take effect, you then need to run the ConfigureIIS.bat script as Administrator located in the C:\Skyline DataMiner\Tools folder.

Note

The legacy Annotations and Reports and Dashboards modules are disabled by default as from DataMiner versions 10.4.0/10.4.1.

Operating system hardening

TLS versions

In addition to enabling HTTPS, we also recommend that you configure your operating system to block deprecated SSL/TLS versions. HTTPS uses SSL/TLS for encrypting communication, but the older versions of this protocol are no longer considered secure. At present, all major browsers support the latest TLS version (TLS 1.3), but TLS 1.2 is also still regarded as secure.

Protocol Published Status
SSL 1.0 Unpublished N/A
SSL 2.0 1995 Deprecated since 2011
SSL 3.0 1996 Deprecated since 2015
TLS 1.0 1999 Deprecated since 2020
TLS 1.1 2006 Deprecated since 2020
TLS 1.2 2008 Supported
TLS 1.3 2018 Supported (most secure)

For more information about disabling legacy SSL/TLS versions, refer to TLS, DTLS, and SSL protocol version settings in the Microsoft documentation. We have also made tools and scripts available for this on GitHub, or you can use third-party tools such as IIS Crypto.

Configure the firewall

On DataMiner versions installed using the 10.0 installer (or older), the DataMiner installation opens the following (inbound) ports and rules in the Windows firewall:

  • TCP 23: Telnet (disabled by default)

  • TCP 80: HTTP

  • TCP 8004: Remoting (client-server & inter-DMS communication)

  • TCP 9004: Web Services (end of life)

  • TCP 7000: Cassandra (inter-node communication)

  • TCP 9042: Cassandra (client-server communication)

    Note

    This rule and the one above for TCP 7000 only apply when the DataMiner System uses a Cassandra database locally. If Cassandra is configured to use TLS, port 7001 and 9142 are used instead. For detailed information on securing Cassandra, refer to securing self hosted storage.

  • TCP 9200: Elasticsearch (client-server communication)

  • TCP 9300: Elasticsearch (inter-node communication)

    Note

    This rule and the one above for TCP 9200 only apply when the DataMiner System uses an Elasticsearch database locally.

  • TCP 4222, 6222, 8222: NATS (inter-process communication)

  • TCP 9090: NATS Account Server

  • UDP 161, 162, 362: SNMP (disabled by default)

  • Allow Remote Administration

  • Allow ICMP: Ping

If you use the DataMiner 10.1 installer or a more recent installer, the ports that are displayed in bold above are no longer opened by default during DataMiner installation. However, to avoid breaking changes, these ports are not closed when you upgrade an existing DataMiner System that was installed with an installer prior to version 10.1. We therefore recommend that you verify if any of the following ports can be closed manually:

  • TCP port 23 can be closed if the DataMiner Telnet feature is disabled. For more information, see DataMiner.Telnet.

  • TCP port 80 can be closed if IIS is configured to require HTTPS connections and if IIS is not configured to redirect HTTP to HTTPS. We highly recommended enabling HTTPS on your DataMiner System. Note that TCP port 443 needs to be open for HTTPS connections. For more information, see Setting up https on a DMA.

  • TCP port 9004 can always be closed from DataMiner 10.0.11 CU0 and 10.0.0 CU6 onwards.

  • TCP port 8222 can always be closed. The port is closed by default from 10.1.12 CU0 and 10.2.0 CU0 onwards.

  • The ports for NATS communication (4222, 6222, and 9090) can be closed when the DMA is not part of a cluster.

  • UDP ports 161 and 362 can be closed if the DataMiner SNMP Agent feature is disabled, which is the case by default from DataMiner 9.6.11 onwards. However, if a DMA was installed prior to DataMiner 9.6.11 and is upgraded to DataMiner 9.6.11 or higher, this functionality will remain enabled until it is manually disabled. For more information, see Enabling DataMiner SNMP agent functionality.

Note

From DataMiner 10.3.6/10.4.0 onwards (or in earlier versions used with DataMiner CloudGateway 2.10.0 or higher), inbound TCP port 5100 communication should also be enabled, because this is required for communication to the cloud via the endpoint hosted in DataMiner CloudGateway. When you upgrade, the Firewall Configuration BPA will run to check wether this port is correctly configured.

The Remote Administration rule must be enabled when the DataMiner server is monitored by a remote element using the Microsoft Platform protocol. This is for example the case when two DataMiner Agents are used in a Failover setup, and both servers are monitored through the Microsoft Platform protocol.

ICMP is only required when Failover heartbeats are active or the pingCount attribute in the DMS tag in DMS.xml is set to a value greater than 0. For more information, see Attributes of the DMS tag. Allowing ICMP is also useful to debug connectivity issues.

Tip

See also: Configuring the IP network ports

Disable the local Administrator account

DataMiner has one built-in user, named "Administrator". This user is the local administrator on the Windows server hosting DataMiner and intended for recovery and initial configuration purposes. Once Operator users have been created, we recommend disabling the local Administrator user on the DataMiner server.

Secure self-hosted DataMiner storage

If you do not make use of Storage as a Service (STaaS) but manage DataMiner storage yourself, you need to make sure that the databases used for DataMiner storage are fully secure.

If you use on-premises databases, we recommend using a Cassandra cluster and OpenSearch cluster. It is important that you spend some time making sure the configuration of these databases is as secure as possible. For detailed information, refer to Securing Cassandra, Securing OpenSearch, or Securing Elasticsearch.

Note
  • If you do use Storage as a Service, Skyline will take care of protecting your data, making use of existing and secure storage solutions provided by Microsoft Azure.
  • Previously, Elasticsearch was recommended as the on-premises indexing database instead of OpenSearch. For more information on why OpenSearch is now recommended instead, see From Elasticsearch to OpenSearch to StaaS.
Propose changes