Secure communication within Paessler PRTG

In the rapidly evolving cybersecurity landscape, security is crucial. At Paessler, we understand the importance of security and have committed ourselves to providing a robust and secure network monitoring solution. In this blog, we are going to explore how Paessler PRTG ensures the confidentiality and integrity of the transmitted data. Specifically, we will discuss how secure communication is established, and what options you have at your disposal to further improve your setup

Encrypted communication

By default, PRTG encrypts the communication between its components, which means that the communication between the PRTG web server and the probes is secured by default using the SSL/TLS protocol.  Specifically, PRTG 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 by default allows only state-of-the-art secure ciphers. While TLS 1.2 is also perfectly fine, users should know that it brings some weak ciphers as well (e.g. ECDHE-RSA-AES256-SHA384 and ECDHE-RSA-AES256-SHA). Users have the option to specify exactly the which ciphers are allowed according to their needs by editing registry keys. Since this can be an error-prone action which can make PRTG unusable, we encourage you to open a ticket to express your exact needs and receive a suitable configuration that meets those needs.

An example of instructing the PRTG web server 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 PRTG core server service using the PRTG Administration Tool

Another example is to restrict the PRTG web server 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 PRTG core server service using the PRTG Administration Tool

This will make the PRTG 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.

The role of OpenSSL

To use all the above protocols and ciphers, PRTG does not use custom implementations, which could introduce mistakes. It depends on OpenSSL 1.1.1, which will be upgraded to OpenSSL 3 in the future. OpenSSL is a well trusted and industry-recognized open-source software for cryptographic operations.
When a new update of OpenSSL is released, our security team reviews the vulnerability fixes (CVEs) and performs context analysis. This gives us the ability to plan how fast we can update the embedded OpenSSL version. A strong commitment to maintenance is one of our core values, and thus we make sure that OpenSSL also gets updated in a timely manner, even if our current version does not ship vulnerabilities which actively affect PRTG.
As a customer, you can always open a ticket at our helpdesk portal for clarifications regarding protocol support, specific setups, or CVE fixes.

Input sanitization

In addition to the SSL/TLS implementation, PRTG protects users from various web security threats as well. We are achieving this by enforcing input sanitization methods within our code, reducing the risk for successful attacks like cross-site scripting (XSS) or path traversals. However, since we are aware that there is no such thing as 100% security, on top of our input sanitization methods, we constantly run automated security tests against our web server to further improve the defenses of PRTG.

HTTP (custom) headers

In all server requests, we include HTTP headers. Specifically, we use: X-Content-Type-Options, Content-Security-Policy, and Cache-Control. Although PRTG does not officially support HSTS headers yet, we at Paessler are aware that the missing HSTS header sometimes come up in pentests or from tooling that does automated security scans. For this reason, in the future, we plan to allow users to set custom headers in the Application Server.
Users that 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. You can read how to add a proxy in this knowledge base article:

👉 Using nginx web server as SSL Proxy for PRTG

With all the above security features, PRTG 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.
As security is a never-ending story for the users as well as for us, we encourage everyone to contact us at security@paessler.com to report potential security issues or concerns.