Network monitoring software is one such tool that helps to ease the workload so that the IT teams can focus on their core jobs and, in positive developments, software developers have provided key features which provide further bolster a robust and secure network monitoring solution that helps to ensure the integrity and confidentiality of transmitted data when using network monitoring software.

In this article, I will discuss how secure communication is established and what options can further improve the initial setup.

Encrypted communication
By default, network monitoring solutions should encrypt the communication between its components, which means that the communication between the network monitoring web server and the probes is secured by default using the SSL/TLS protocol. Specifically, the monitoring software can be configured to use only HTTPS combined with secure ciphers. TLS 1.3, for example, is supported (and recommended for use if the user’s setup allows it), which allows only state-of-the-art secure ciphers by default. While TLS 1.2 is also perfectly fine, users should know that it also brings some weak ciphers (e.g. ECDHE-RSA-AES256-SHA384 and ECDHE-RSA-AES256-SHA).

Users have the option to specify exactly which ciphers are allowed according to their needs by editing registry keys. Since this can be an error-prone action which can make the software unusable. You should be able to open a ticket with your network monitoring supplier to express your exact needs and receive a suitable configuration that meets those needs.

An example of instructing the webserver to allow only TLS 1.3 can be seen below:
1. Open regedit.exe
2. Go to path
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Paessler\PRTG Network Monitor\Server\Webserver
3. Create a new DWORD (32-bit) with:
a) Name:  OverrideSSLVersionV2
b) Value: 128 (as decimal)
4. Restart the core server service using the Administration Tool

Another example is to restrict the webserver to use only TLS 1.2 and disable CBC ciphers that are enabled by default:
1. Open regedit.exe
2. Go to path
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Paessler\PRTG Network Monitor\Server\Webserver
3. Create a new DWORD (32-bit) with:
a) Name:  OverrideSSLVersionV2
b) Value: 64 (as decimal)
4. Create a new string with:
a) Name:  OverrideSSLCipherV2
b) Value: ECDH+AESGCM
5. Restart the core server service using the Administration Tool

This will make the web server only accept TLS 1.2 with the following ciphers:
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256

Note that to make the above work, both OverrideSSLVersionV2 and OverrideSSLCipherV2 should be present in the registry.

OpenSSL’s role
To use all the above protocols and ciphers, some network monitoring tools do not use custom implementations, which could introduce mistakes. It depends on OpenSSL 1.1.1, which will be upgraded to OpenSSL 3. OpenSSL is a well-trusted and industry-recognised open-source software for cryptographic operations.

When a new update of OpenSSL is released, a security team should review the vulnerability fixes (CVEs) and perform context analysis. This gives them the ability to plan how fast the embedded OpenSSL version can be updated. A strong commitment to maintenance should be one of the core values, and thus making sure that OpenSSL also gets updated in a timely manner, even if your current version of software does not ship vulnerabilities that actively affect the network monitoring software.

Input sanitisation
In addition to the SSL/TLS implementation, security features in network monitoring software protect users from various web threats as well. This is achieved by enforcing input sanitisation methods within the software code, reducing the risk for successful attacks like cross-site scripting (XSS) or path traversals. However, as there is no such thing as 100% security, on top of the input sanitisation methods, security teams should constantly run automated security tests against the network monitoring solution provider’s web server to further improve their defences.

Including HTTP (custom) headers
In all server requests, HTTP headers should be included. Specifically X-Content-Type-Options, Content-Security-Policy, and Cache-Control. Although some programs do not officially support HSTS headers yet, the missing HSTS header sometimes comes up in pen-tests or from tooling that does automated security scans. For this reason, in the future, users should be allowed to set custom headers in the Application Server.

Users who are currently required to use the HSTS headers can do so by deploying another software in between, such as a reverse proxy, that adds the header to the requests.

With all the above security features, modern network monitoring software ensures the integrity and confidentiality of all the transmitted data, while reducing the risk for successful web attacks. Nevertheless, admins should always implement further security measures (e.g. firewall, antivirus etc.) to protect their infrastructure.