This article applies as of PRTG 22
Security feature: No access to scripts via the PRTG web interface
As a network monitoring tool, PRTG has a high responsibility for your network safety and comes with a lot of features that address security. Just see this Knowledge Base article for a list of security features in PRTG: What security features does PRTG include?
You may not directly realize many security-related features, but some are more prominent. One of the more visible security features is for sensor that execute custom scripts. These not only include custom script sensors, but also the SQL sensors that we introduced with PRTG 14.4.12.
For security reasons, these sensors require that you store your SQL query in its own file. You must store this script on the local or remote probe system to which you add a database sensor.
Security and ease of use
In some cases, this approach confuses our customers a bit because affected sensors might not be as intuitive and easy to use as features in PRTG usually are.
For example, some customers suggest that we provide the option to create and adjust SQL queries directly via the sensor settings in the PRTG web interface like in old versions of PRTG. And yes, we agree. On the one hand, this would be an easier approach in some use cases. But on the other hand, it would be also less secure, so going the indirect way is worth the effort.
Network security and read/write access to scripts
The main point of our security concept for such sensors is that to create or modify a script that PRTG executes on a remote system, you must have access to the local disk of this system. We assume that local or remote probe systems (the system where PRTG will execute a script) are secure, because the administrator will do everything to make sure that only authorized persons can access these systems.
This way, if an attacker manages to capture a login into your PRTG web interface, they will not be able to compromise your network by running malicious scripts on the PRTG core server or probe system. Just imagine someone sending a DROP TABLE statement to your database server. Our security concept ensures that someone who only has access to the PRTG web interface is neither able to inject a script into a remote system, nor able to modify an existing script. They always need access to the file system itself.
A positive side effect of this concept is that even if a possible attacker obtains read rights for your PRTG web interface, they would not get more than the name of the remote script. No internal structure information about your databases is exposed.
Add comment