Forum Discussion

Brandon's avatar
Brandon
3 years ago

hostProps.set() workaround

Hey all,

So it looks like I'm not the only one trying to find a way to update device properties on the fly using the collector. 

 

I'm not sure why a hostProps.set() isn't a working function yet but my workaround involved making API calls when device properties needed to be updated right away.  Of course, it doesn't make sense to have a collector server do the extra work of making API calls in order to accomplish this - especially considering it could cause downstream effects like API throttling.  So I went through the effort of learning some java and dissecting the collector jar files to figure out if there was some other way to do it.  Here's what I found: 

import com.santaba.agent.debugger.*

println "Updating property: system.${LMObj} :: OldValue: ${hostProps.get("system.${LMObj}")} :: NewValue: ${currentObj}"
task = "!hostproperty action=add host=${hostProps.get("system.hostName")} property=${LMObj} value=${currentObj}"
HostPropertyTask updater = new HostPropertyTask(task)
updater.run()
println updater.output
return updater.exitCode

 

A few words of caution:

  • ❗❗❗❗❗ This code updates SYSTEM properties, NOT AUTO.* properties.  This is a very important distinction.  This functionality could really ruin your day if you go deploying a datasource that updates properties such as system.ips, system.hostname, system.<user>, system.<password>, etc. ❗❗❗
  • This does not work unless you update your Agent config file (agent.conf) on the collector (and restart the service for it to take effect):

❌ groovy.script.runner=sse

✔️groovy.script.runner=agent

More on that here

  • LogicMonitor could break this functionality at any time in a future release.  I've only tested this on the latest few general releases and it appears to work well - but it could break at any time.
  • The audit log won't tell you that the host properties were modified.  Instead, you only see the results of the change: auto groupmembership, autodiscovery, SDT, etc.  If the change itself gets logged somewhere, I don't know where you might find it.

Lastly, you definitely should not be using this method each every time your datasource runs.  Make sure to implement some logic to only update the property if and when needed.  I have no idea how well this code snippet scales outside of a few hundred resources per minute and since I haven't found any documentation on it, I'm using it sparingly and not yet heavily relying on it to work 100% of the time.  That being said, so far it seems to work quite well.  Feel free to report how well it worked out if you aren't afraid to scale it like crazy and measure the performance.  

3 Replies

Sort By
  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    3 years ago

    I have been aware of the debugger method for some time -- was not familiar with the secret debugger library, but you can access the debugger similarly via the API.  So.... sleep well knowing that any set of leaked admin API keys could expose your entire network to remote attack via arbitrary PowerShell scripts executed via the debugger API.  I was forced at the time to use that method to set the system.ips list to fix NetFlow ingestion for Palo Alto firewalls at the 5000 series or higher.  No alternate method of binding device NetFlow export has yet been provided.

    Recognizing how dangerous this was, I asked about having certain API calls like this locked to an allow list, but that went nowhere.  I have also tried changing Windows collector service accounts to use the Performance Monitoring group rather that Domain Admins (especially after the SolarWinds hack), but I found too many things broke so had to move back.  Even today well after the damage done during the SolarWinds hack due to lateral movement from compromised servers, LM collector installation instructions still include "If this Collector is monitoring other Windows systems in the same domain, run the service as a domain account with local administrator permissions."  

    Tick, tick tick...

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    3 years ago
    8 minutes ago, Brandon said:

    That being said - if I'm understanding you correctly, it sounds like the solution I posted above might negate the need for the API accounts you mentioned.  So if you migrate your primary API functions to use the native java library, you can shut off the API keys entirely and just let the collector do its thing.  I'm no security expert so please correct me if my assertion is incorrect.  

    In any case - please reply to this post if you start playing around with the library.  I'm really curious if it works well for others.  So far it's been a lifesaver for me.  

    Cheers!

     

    Excellent point -- the other functions we need could likely be satisfied with an API user having manager and not admin role.  I will see if we can leverage the library to avoid needing an admin API user -- thanks!  That said, it should still be possible to bind an allowlist to any API user to limit the attack surface.  I as well can dream...

  • Brandon's avatar
    Brandon
    3 years ago
    Quote

     LM collector installation instructions still include "If this Collector is monitoring other Windows systems in the same domain, run the service as a domain account with local administrator permissions."

    Ah - a tale as old as time. ?  

    I think everyone would agree that admin permissions - local or otherwise - isn't ideal.  Unfortunately, as you've discovered, so many seemingly innocuous read-only actions are locked to administrators only in Windows.  WMI, CIM methods, remote script execution, etc - none of that works predictably without granting uncomfortable levels of permissions.  The alternative to the all or nothing approach is to use agent-based monitoring solutions that run locally on the targets themselves.  Of course, this has its own nightmarish drawbacks.  Who knows - Microsoft might surprise us with a new OS that overhauls user permissions in such a way that - out of the box - remote monitoring can be safely accomplished with some reasonable assurances that there are minimal security implications.  A man can dream...

    That being said - if I'm understanding you correctly, it sounds like the solution I posted above might negate the need for the API accounts you mentioned.  So if you migrate your primary API functions to use the native java library, you can shut off the API keys entirely and just let the collector do its thing.  I'm no security expert so please correct me if my assertion is incorrect.  

    In any case - please reply to this post if you start playing around with the library.  I'm really curious if it works well for others.  So far it's been a lifesaver for me.  

    Cheers!