I would like to know more about the high security standards of PRTG. Is there a list of PRTG security features?
What security features does PRTG include?
Votes:
0
9 Replies
Votes:
0
This article applies as of PRTG 23
PRTG Network Monitor security features
We at Paessler take the responsibility for your network safety seriously. We put a lot of effort into providing you with the most secure network monitoring solution possible. A strong focus is especially on the secure connections to and from the PRTG web server. However, PRTG also includes many other security mechanisms to protect against potential attacks.
The list below shows you sample security features of PRTG:
- The PRTG web server supports SSL encryption (HTTPS, TLS, Elliptic Curve Cryptography, Forward Secrecy) with OpenSSL libraries of the 1.1.1t branch.
- PRTG only accepts the most secure ciphers for SSL/TLS connections. These ciphers have to allow Perfect Forward Secrecy and TLS 1.3. See below for used ciphers.
- PRTG does not support SSL v3 or cryptographically broken ciphers (MD5, DES, RC4) for outgoing connections. Note: HTTP sensors that do not offer any ciphers supported by OpenSSL 1.1.1 show the error ssl3_read_bytes:sslv3 alert handshake failure.
- All communication between probe(s), PRTG core server(s), and clients is secured via SSL encryption. The same goes for cluster probe connections. For more information about how PRTG uses SSL, see this article.
- PRTG uses an RSA certificate with 2048 bits as the default certificate.
- PRTG uses uniquely generated Diffie-Hellman (DH) parameters with a 1024-bit key by default. Note: You can also change the key length manually. See this article for details.
- You can filter probe connections to the PRTG core server. This means that you are able to allow connections from specific IP addresses only or deny connections from certain IP addresses (or even from all). A remote probe or mini probe must also have a special access key to connect.
- The PRTG web server cleans and sanitizes all GET and POST parameters that could potentially be used for cross-site scripting (XSS) attacks.
- PRTG replaces angle brackets (<>) with braces ({}) in Name fields to prevent XSS attacks.
- The PRTG System Administrator user can give individual access rights to each user account and to each user group. By default, users do not have permissions to see or change anything in the PRTG web interface without the explicit rights provided by the administrator.
- The PRTG web server does not deliver files from folders that are not configured by PRTG. This feature helps to avoid directory traversal attacks.
- The internal data management of PRTG is not based on an SQL server, so SQL injection attacks are impossible.
- You cannot edit script files for custom sensors, SQL sensors, and custom notifications within the PRTG web interface, so anyone who wants to edit these scripts must have access to the file system. This prevents users that have access to the PRTG web interface from injecting and running malicious scripts on the PRTG core server system. See this article for more information about this security feature.
- Every user account requires a password.
- A password that you enter into any web page of the PRTG web interface (for example, login credentials for a sensor) will never be sent back to the browser.
- PRTG stores internal passwords encrypted and never in log files. If you send a support bundle to the Paessler support team, passwords are removed from the configuration file in advance by default.
- PRTG logs out users that were inactive for a defined time span.
- PRTG system administrators must reauthenticate with their credentials every 15 minutes while working on administration pages. Both the logout and the reauthentication mechanism help to prevent unauthorized access to PRTG and secure the PRTG web interface against potential phishing attacks.
Other optional security settings include:
- The ability to disable browser auto-complete in the login form
- To deny loading of PRTG web pages in frame elements. This is an additional protection mechanism against clickjacking attacks.
- Note: PRTG also never allows login forms in frames.
Elliptic curve and ciphers
PRTG uses the secp384r1 elliptic curve and the following ciphers:
High security modus (default):
'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256!ADH!aNULL!eNULL!LOW!3DES!MD5!EXP!PSK!SRP!DSS!RC4' https://www.ssllabs.com/ssltest: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Weak security modus:
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS' https://www.ssllabs.com/ssltest: TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSH sensors: ciphers, MAC, key xxchange (KEX), key types
The default SSH engine of SSH sensors uses the following ciphers, MAC, KEX, and key types:
Ciphers: aes256-ctr, aes192-ctr, aes128-ctr, aes256-cbc, aes192-cbc, aes128-cbc MAC: hmac-sha1, none or hmac-sha2-512, hmac-sha2-256, hmac-sha1, none KEX: [email protected], ecdh-sha2-nistp256, diffie-hellman-group1-sha1, diffie-hellman-group14-sha1 Key types: ssh-dss, ssh-rsa or ssh-ed25519, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, ssh-dss, ssh-rsa
Created on Aug 7, 2014 9:46:02 AM by
Gerald Schoch [Paessler Support]
Last change on Mar 8, 2024 3:57:12 PM by
Jacqueline Conforti [Paessler Support]
Votes:
0
Hi,
Is there a way to disable 3DES-CBC from the weak security modus? It triggers alarms when vulnerability scans are executed against the PRTG server.
Votes:
0
Hello,
I'm afraid to tell you that this is not possible. Please take a look here for what is supported in default mode.
Kind regards
Felix Wiesneth - Team Tech Support
Votes:
0
Hello,
Is it possible to update this article with recent security improvements?
This is a question we often have to answer internally or externally and this note is not very up-to-date.
Thank you!
Votes:
0
Hi Matthieu,
Thank you for your feedback. I will check with our team and we will update this KB article if necessary.
Kind regards
Felix Wiesneth - Team Tech Support
Votes:
0
Hello,
are there any news about updating the security features? I would like to know which ciphers are supported in version 22.2.76.1705.
Thank you!
Votes:
0
Hi Marvin,
You can define your very own security ciphers via a regsitry hack. IMPORTANT! Applying this registry hack comes at your own risk and you will be responsible to maintain the cipher suites once the registry value is set. Please note that not all features might work after the changes.
If you want to have here some more insights, please contact us via [email protected] since we do not share this information publicly.
Kind regards
Felix Wiesneth - Team Tech Support
Votes:
0
We are reviewing our current hardened PRTG configuration/setup and evaluating options/features are being offered by NEW UI (introduced since version 21.4.73). In terms of the web server protection:
Q1: Could you, please advise us whether it is planned or feasible to enable custom HTTP headers configuration within NEW UI on a PRTG web server?
For example, we have to tweak some default header values (for instance, extend the Cache-control or remove the Server field value
), but also inject some new header values (CSP and STS, for instance
).
Q2: Is it planned or feasible to use any SSO federation (OIDC, WS-FED, AAD, Okta, or any of your choice) on a PRTG web server, located behind a load balancer(LB)/reverse proxy(RP), using split DNS?
For example, consider a classic scenario - a PRTG web server has an internal-only DNS name and located behind a LB/RP, while the LB/RP is connected to & accessible from Internet over HTTPS using a published public DNS name.
Thanks in advance!
Votes:
0
Hi there,
we do plan to implement these features in future. However I can't give you an ETA on how and when this will be implemented in the new UI. Therefore I would like to encourage you to take a look at our Roadmap and invite you to take part in our surveys we linked to different topics. In this way you can make sure that we receive your feedback.
Kind regards
Felix Wiesneth - Team Technical Support.
Add comment