Changing the PRTG Core Service Account

Dear Aaron

The core service should be run via the Local System account to make sure it has all access rights required. An account for the core service for example needs access to the local registry.

There are plenty of account types that have access to the registry without signing on as the full LOCAL SYSTEM account. I have many other resources on this system which I do not want a compromised (in theory) PRTG account to be able to access.

Surely you are aware of best practices regarding assigning designated local accounts for services which have exposed external ports. Can you please be more specific on what rights I need to grant to this service account so that it can be used for the PRTG Core Service Account?

Dear Aaron

I am sorry, we don't have a list specifying all those rights. We develop for and test PRTG to be run with the local system account.

This is not an acceptable answer. Running a service or application in the security context of the LSA gives the service almost unlimited privileges on a Windows system. The LSA’s powers are comparable to those of the root account on UNIX systems. If the PRTG installation were to be compromised, then the entire server would then be compromised. Do you really find this to be acceptable security design?

Dear Aaron

PRTG uses the local system account for both the probe and the core service because it needs a wide range of access rights. PRTG needs to be able to open ports below 1024, access the registry, the file system, Windows API, WMI and so on. As long as PRTG has enough rights to function, it could also be misused if compromised.

A computer running PRTG should be physically protected from unauthorized access, see our note here:

We assume that all computers on which the PRTG core server with its local probe or any remote probes run are secure. It is every administrator's responsibility to make sure that only authorized persons can access these machines. For this reason we highly recommend that you use dedicated machines for your PRTG system parts.

Please consider the following common scenario:

1 remote PRTG server and 5 locations each with a PRTG probe on site. The five on-site probes need and can safely use the LSA because they are on an internal, secured private network. However they have a need to report back to the remote PRTG server. The PRTG server is necessarily remote because if it is on-premise and the internet circuit there goes down, there is no way for the PRTG to do alerting. Therefore a remote PRTG server is necessarily part of good design.

Considering this requirement, a remote PRTG server will then require firewall ports to be opened both for the probes to deliver data AND for the Enterprise Console / iPhone apps to view the status of the probes. Yes, the PRTG server is physically secured and yes the firewall source port can be restricted to the probe IP addresses. That is not a concern. But the firewall source port cannot be similarly restricted for iPhone / Enterprise Console apps connecting via HTTP/S because users of these systems are necessarily and always mobile.

So what is required here is that a web server is ALWAYS up and running for remote access and monitoring, but this web host is running under the Local System Account (LSA). No IT professional, anywhere, ever would find the practice of running a web server under a fully privileged account like LSA. But it is necessarily a requirement due to how PRTG has implemented remote iPhone/Console access to PRTG via HTTP/S. This is an ENORMOUS security risk that is wildly outside of what is considered best practice by any security conscious IT professional. Why do you find this to be acceptable? Considering that the PRTG core often holds many credentials to access remote systems, this particular use of LSA for an HTTP/S web server seems especially egregious and dangerous.

I do not find any of your replies thus far to be reasonable or acceptable responses. Please consult with your security team about this seemingly overlooked vulnerability in the PRTG design.

Dear Aaron

As the core server / web server is operated by the same service, it does need the local system account. If you need additional security, please use a proxy server for the access, or a VPN. Right now, these are the only options.

Will PRTG be splitting off the web server and core server into two separate service accounts in the future? I understand if the core needs to run under the LSA, but any and all web servers should never run as LSA.

Dear Aaron

A separate web server would have many advantages. In the foreseeable future, the webserver is operated by the PRTG coreservice. We don't want to talk about our road map as it could create expectations when an improvement is available.