Forum Discussion

Eric_Singer's avatar
8 years ago

Read only agent / collector

I know I've brought this up before, but I'd like to bring it up again.  LM's requirement that collectors run as local admins (or system) is a GAPING security hole in your product.  No amount of certificate signing, or other like security measures are a replacement for running a collector or an agent as a read only account.  The fact is, with every security measure you take, if the collector is running as an admin account or a system account, its going to be exploitable in one way or another.  Having the signed scripts and what not, would be great, but really it shouldn't be the primary focus IMO.  Security is much better when its locked down by default and opened up as needed, compared to what you guys are doing, which is a completely open system, that you're trying to add security enhancements on top of.  It's almost akin to you guys having no firewall,and then adding a few rules here an there to block certain types of traffic, while the rest of the network is completely exposed.

A more prefered architecture (security wise) would be an agent / collector that can run as a read only account and be supported.  WMI, perfmon, and many other functions all work fine with a regular user, when it's executed locally.  That is why an agent or a special collector is needed.  Most ideal communication path would be an "agent" talks to a "collector" which then talks to the portal.  This would also allow us to keep our internet locked down.  I suspect this would also have the other advantage of taking a lot of load off the collectors and really putting most of the work on the agent, which is ultimately better given that the workload would be distributed.

For now though, even having a "supported" configuration for a collector not running as a local admin / system would be a great step in the right direction.

The reason this is less of a concern for solution like Solarwinds and SCOM is they're on premises based solutions, meaning there is much lower external risk factor.  You guys are cloud, and there for need to design the solution from an untrusted point of view.  

11 Replies

Replies have been turned off for this discussion