Security Hardening of LM

Important Security Announcement | LogicMonitor - 15844

There was an announcement, but since replies can't be posted there, I'm replying here.

Regarding the Linux/Windows Collectors Least Privilege, there is some confusion. In the Linux section, it mentions the following. It's also ambiguous in the Windows section:

Previously, LogicMonitor required collectors to use root credentials to collect data from the resources it monitored. As part of our commitment to increasing security standards, and meeting the feedback of our customer base, with the release of GD 36, we have introduced the capability of collectors to run using non-root credentials.

This seems to indicate two different sets of credentials. One is for monitoring the devices, as in root access on the devices you are monitoring and the other is the account running the daemons on the Linux collector. I'm pretty sure this is actually referring to the user that's running the daemon.

It should say something like this:

Previously, LogicMonitor required collectors to use root credentials to run the daemons. As part of our commitment to increasing security standards, and meeting the feedback of our customer base, with the release of GD 36, we have introduced the capability of collector daemons to run using non-root credentials.

Unfortunately, LM doesn't really provide any instruction on how to tell whether or not this even applies to you. 

Fortunately this is pretty easy to do. All you need to do is create a propertysource that makes a property containing the username then create a dynamic group looking for any collectors where the username is root (or run a report). And you're in luck, here's one that you can build yourself that works for Linux and Windows both.

Go to Settings >> PropertySources >> Add >> PropertySource

Give it a name like "Collector RunAs User"

Set the AppliesTo like this:

isCollectorDevice() || system.collector == "true"

Set the Script to look like this:

try{
    try {
        println("collector.run_as=${'whoami'.execute().text}")
    } catch(Exception e) {
        println("collector.run_as=${System.getProperty('user.name')}")
    }
    return 0
} catch(Exception e){println(e);return 1}

Then create a dynamic group in your resource tree with a membership rule like this:

auto.collector.run_as == "root"

Alternatively, you could create a device inventory report that shows all the collectors with this property value.

Regarding API Tokens - it has been stated in the community before that the way to get around this restriction is to clone the default admin role. The logic doesn't actually check that the role has admin rights. Rather, it checks whether it's the default role that is available out of the box (which has full admin rights). Cloning this role will give the same permissions while still allowing you to generate API tokens. The warning is the same for this as it should have always been, "with great power comes great responsibility." A compromised API token with full admin rights could extract every secret in your portal. If you have your portal integrated to a secret vault like Thychotic (Secret Server), the compromised API token could be used to extract the credentials used by LM to access your vault, opening up your entire vault to compromise. 

In our portal, we generate new API credentials for every datasource, automation, or integration. Not only does this help when troubleshooting problems with authentication but it also minimizes fallout when a credential goes rogue.

We default to generating read only API tokens, but in some cases we have to provide the automation the ability to RW globally. We pipe our audit logs into LM Logs and have setup alert pipelines to look for unusual behavior with regards to our tokens (including the recent bug introduced by 206 around rate limiting). I suggest you do something similar.