Search the Community

Showing results for tags 'security'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • From LogicMonitor
    • General Announcements
    • LM Staff Contributions
    • Community Events
  • LogicMonitor Product Discussion
    • Feature Requests
    • LM Exchange
    • Ask the Community

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me

Found 9 results

  1. @Sarah Terry Please address urgently. These new verbose error dialogs expose the WMI password. Ideally I'd like a Settings options to disable such verbose error messages, or restrict them by role. (Also can these dialogs be more responsive, no a 1920x1080 screen these appear as narrow panels in the middle.)
  2. Curious if anyone is leveraging LM for first line Ransomware detection. Reading indicators typically include a high number of file name changes on the server/PC. Seems like that would be something that LM could help us identify early on and alert out to take action before additional servers are compromised. Looks like a working number is about 4 renames a second for the threshold. Thanks, Mitch
  3. 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.
  4. Problem I have a datasource that collects information from the LogicMonitor API. In order for this to work correctly I need a valid user on the LM platform with a valid API token. I can see two potential paths forward. Case 1 - Use my existing account as the datasource author with my API token. This has a big downside that if I have to leave the company for any number of reasons and my account gets disabled this datasource will stop working and is customer facing. This is probably not so good. Case 2 - Create a 'service account' inside LogicMonitor that can have its' own API token and if any one human needs to leave the company there really is not a big problem. The issue with this is that this user has a username and a password that can grant it access to the UI under all the permissions granted by the role but this account should/will never be used within the UI. This also generates a potential security problem because the password will most likely never be rotated because as long as the API user and token work this is simply going to sit there. Request Be able to create a new user type of 'API only' which will never have access to the UI and therefore you should not have to set any of the UI specific information for the account. This would remove the need for any of this information under that account: First/Last name/Email/Password/Force password change/2-factor/Phone/SMS/SMS Email format
  5. Our team has verified that secure syslog forwarding (via TLS) is not supported currently and would like to submit a feature request to LogicMonitor DEV team to asses whether secure syslog forwarding can be implemented. An example will be syslog-ng forwarding secure (i.e. encrypted) syslog messages to LogicMonitor collector. This will enable centralized logging server to forward secure syslog messages to LogicMonitor collector then. Thanks & Best Regards, Horace
  6. It would be great if I could create a user role that had power user capabilities but without the ability to escalate their own account to the administrator level. The role would need to have permissions to create new users.
  7. We sometimes see datasource scripts with passwords in the body of their script. For testing this is fine, but in production datasource scripts, passwords in plain view isn’t just bad, it should be a cardinal sin. You can use Powershell to secure a password by creating a PSCredential object that uses the cmdlet Get-Credential and stores the output into a file. Note that it saves as a System.Security.SecureString. Now you can use the file in your script: $hostname= "##HOSTNAME##" $pass= Get-Content "\\Encryptedfile.txt" $user= "##PS.USER##" $password1= ConvertTo-SecureString -String $pass When your script is finished just run it in powershell GUI to check it works fine. Make sure you alter our tokens to the correct values. We had a recent case that when the collector tries to run the datasource script it failed. The below error was in the logs. New-PSSession : [PROD-TP-DB01] Connecting to remote server HOST failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x8009030e occurred while using Negotiate authentication: A specified logon session does not exist. It may already have been terminated. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. The script is failing with an authentication error. Even though it works fine in the Powershell GUI. The reason for this was the account the collector ran under. PowerShell uses the Windows Data Protection API (DPAPI) to encrypt/decrypt your strings. That means if you created the file using one user account only the same user account on the same computer will be able to use this encrypted string. So the collector account cannot read the file Encryptedfile.txt. We proved this by running the Powershell GUI under the same account your collector uses. So make sure that you create the file using the same account. Keep in mind that if you change the collector account, the script will fail. It is possible that you can encrypt the file using a machine key, which means any user on the collector can use the file and decrypt it, but that’s for another post!
  8. Hi, As much as i love the graphs and visuals that LM produces for all sorts of metrics, unfortunately a big part of our monitoring is keeping an eye on Windows Event Logs, which i have to say LM is not that good at. Adding exceptions is a pain (i now have so many i often delete them by accident when adding new ones). I have been told this is in the pipeline for the new UI several times but it has not been mentioned as yet. My first line guys check our gfi & LM dashboard every morning and i hear time again that they prefer the gfi one for looking at Event log messages. I have even caught them loading gfi on to servers that already have LM on them (costing us twice the cost). Is there anything in the pipeline for this? I know it's not a priority for you guys, but i think for a lot of customers it would be.
  9. We need to be able to grant a user to be able to see only select or tagged instances of a datasource. For example VM statics inside a vcenter. We have Instance Groups with the tags by group or client. Need to be able to link users to see those. or a new security Tag we can add.