Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

Gavsto last won the day on December 6

Gavsto had the most liked content!

Community Reputation

106 Excellent


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. As an added bonus you don't even need to open ConnectWise Automate to do it. See my post here https://www.gavsto.com/one-script-to-get-an-overview-of-all-your-clients-open-ports-and-cve-vulnerabilities-using-powershell-connectwise-automate-and-shodans-free-api/
  2. This is a massive pain in the ass for me too, but it is fixable. First you need to enable enhanced logging by setting a property in the dashboard of plugin_reportcenter_loglevel and giving it a value of 6 Check to make sure the property does not already exist, if it does set it to 6. A restart of the DBAgent service is needed for it to process this. Open the report and generate the error. You will find a log locally at "C:\programdata\LabTech Client\Logs\20190524_LTcErrors.txt" which may or may not give a good indication as to what the problem is. Post the relevant bit here once you have it and I'll help you diagnose why.
  3. @Brant @LVasquez SELECT COUNT(*) AS TestValue, c.name AS IDentityField, c.Computerid AS ComputerID, acd.NoAlerts, acd.UpTimeStart, acd.UpTimeEnd FROM computers c JOIN eventlogs e ON (e.computerid = c.`ComputerID`) LEFT JOIN AgentComputerData acd ON (c.computerid = acd.computerid) WHERE e.EventID IN (529,644,681,4625) AND (e.Message LIKE '%Logon Type:2%' OR e.Message LIKE '%Logon Type:7%' OR e.Message LIKE '%Logon Type:10%') AND TimeGen > (NOW() - INTERVAL 1 HOUR) GROUP BY c.`ComputerID` HAVING TestValue > 8 This is a RAWSQL Internal Monitor. I have extensive documentation on how to set them up: https://gavsto.com/rawsql-help-and-tutorial-a-how-to-plus-an-internal-monitor-example-to-detect-hung-servers-and-run-custom-sql-in-labtech/ This focuses on just the logon types people give a shit about, remote, remoteinteractive, unlock and console. The TestValue on the bottom line indicates the number to trigger it. 8 seems perfect in my testing. I run this hourly.
  4. This is something that I am constantly seeing, and I am wondering if anyone has any insight in to it. I have a significant number of network devices where MAC Addresses are being detected that don't seemingly exist - these MAC addresses are always 2 Hexadecimal places away from a MAC address that does exist and they end up being/creating duplicate devices. It's easier to show in a screenshot: Checking on the probe to see how this was detected I find nothing in lt_LTNETScan.Log. The only mention of this MAC address is in ly_LTNETMap.log. Here is the section it is in: Hooking up interface Slot: 0 Port: 23 10/100 Copper - Level- - 23 (23)Inteface Detected Macs: MacAddress: 00:04:F2:F9:4F:C1 IP: Hooking up interface Slot: 0 Port: 24 10/100 Copper - Level- - 24 (24)Inteface Default Macs: Hooking up interface Slot: 0 Port: 25 Gigabit - Level- - 25 (25)Inteface Default Macs: Hooking up interface Slot: 0 Port: 26 Gigabit - Level- - 26 (26)Inteface Detected Macs: MacAddress: 00:01:2E:82:73:B9 IP: MacAddress: 00:0B:D6:1F:2D:DB MacAddress: 00:0B:D6:46:31:B6 IP: MacAddress: 00:1D:AA:0A:53:30 IP: MacAddress: 0C:80:63:B2:DA:1D IP: MacAddress: 14:B3:1F:23:C7:7E IP: MacAddress: 14:B3:1F:24:21:6C IP: MacAddress: 2C:30:33:9D:90:72 MacAddress: 34:64:A9:2E:E8:86 IP: MacAddress: 34:64:A9:2E:E8:FA IP: MacAddress: 40:B0:34:3C:F3:F7 IP: MacAddress: 5C:E2:8C:67:45:9C MacAddress: 64:00:6A:0A:B9:48 IP: MacAddress: 80:CE:62:1C:54:5D IP: MacAddress: 8C:3B:AD:14:63:D7 <------------------- Naughty MAC Address MacAddress: 90:2B:34:BF:1F:2E IP: MacAddress: B0:83:FE:69:4D:BE IP: MacAddress: B0:83:FE:69:77:AD IP: MacAddress: B0:83:FE:7F:24:FC IP: MacAddress: B0:83:FE:B7:B5:BA IP: MacAddress: B0:83:FE:BC:06:DC IP: MacAddress: B4:A3:82:2F:B5:87 IP: MacAddress: BC:AD:28:E1:C8:77 IP: MacAddress: DC:4A:3E:8F:6D:4D IP: MacAddress: DC:EF:09:EB:2F:FA MacAddress: F4:39:09:40:A4:EF IP: MacAddress: F8:BC:12:3B:1E:40 IP: AssignInterfacesEnhanced for device 3-NetgearFS728TPv2-24PoE Mac: 2C:30:33:9D:90:70 Description:FS728TP Smart Switch 2F46615F000D5 FS728TPv2Hooking up interface Slot: 0 Port: 1 10/100 Copper - Level- - 1 (1)Inteface Default Macs: Hooking up interface Slot: 0 Port: 2 10/100 Copper - Level- - 2 (2)Inteface Default Macs: Hooking up interface Slot: 0 Port: 3 10/100 Copper - Level- - 3 (3)Inteface Detected Macs: MacAddress: B4:A3:82:2F:B5:87 IP: Hooking up interface Slot: 0 Port: 4 10/100 Copper - Level- - 4 (4)Inteface Default Macs: Hooking up interface Slot: 0 Port: 5 10/100 Copper - Level- - 5 (5)Inteface Detected Macs: MacAddress: 00:0B:D6:1F:2D:DB Hooking up interface Slot: 0 Port: 6 10/100 Copper - Level- - 6 (6)Inteface Detected Macs: MacAddress: 34:64:A9:2E:E8:FA IP: For all intents and purposes in all of these duplicate detections the MAC doesn't seem to exist. What this is doing though is polluting network devices with duplicate devices that are inaccurate. Anyone seeing this or got any insight?
  5. Is that information not within the Manage UI itself? See https://docs.connectwise.com/ConnectWise_Documentation/030/020/035/060
  6. I'm not even sure what you are trying to do when you say e-mail tracking. Can you outline a bit more? Is this for Manage or Automate because that's the SOAP API for Manage.
  7. I mean... did you really read it? It basically says there that the version of Automate you are on will stop working on the 9th of March and all agents will break. What more motivation do you need?
  8. Please read If you are on Automate 12 Patch 12, get yourself updated ASAP as a PRIORITY.
  9. You can build up a search in the advanced search. Computer.Drives.IsSSD
  10. We, as a team, have noticed over the last couple of days that there has been some pretty heavy criticism of ConnectWise across forums, Slack, and social media outlets like Reddit in relation to the problems with the Automate binaries. A lot of the criticism has been relatively unfounded. The problems found within the product are not issues that we believe could have been picked up by any standard QA or testing measures - bearing in mind that our team member only stumbled on to this by complete accident. In regards to the criticism surrounding ConnectWise's notification to partners, it's much easier for the leaders in a community like ours to notify our members as we are not bound by the processes, procedures and multiple teams required to get a fix like this out successfully at a corporate level. Though there are clear areas for improvement in QA and testing processes, every member of the MSPGeek team was impressed at the speed of response and subsequent delivery of a fix by the Automate team. Our community was founded and based upon the idea of mutual assistance, open sharing, good communication and, for the past 6 years, has provided a trusted platform for users to support each other while helping ConnectWise make the product better. Let's continue to help ConnectWise by providing constructive criticism while helping them, and each other, through this bump in the road; it's the MSPGeek way.
  11. Following the MSPs who were impacted by this https://www.reddit.com/r/msp/comments/ani14t/local_msp_got_hacked_and_all_clients_cryptolocked/ a number MSPGeekers had an impromptu call to discuss security in general and what best practices we all followed to ensure our systems are as secured as possible. This prompted an idea from @MetaMSP that we have a place where best practices can be defined - things that we can put in place to make our RMMs as secure as possible. I will update this with a list of generally agreed upon methods based on the discussion. How can I apply better security? 1) Enable Multi-Factor Authentication. This is a functionality that already exists within Automate in the form of plugins, and for the effort to implement it gives a massive boost to security. As an MSP every single account you have should have 2FA on it 2) Do not publish your Automate URL publicly - anywhere. If you are linking to your Automate site, or even your Control site from anywhere on your website - remove it and ensure to the best of your ability it is removed from search engine indexes. Attackers can find servers like this on Google using very simple methods and you will be one of the first they attempt to attack. 3) Review all plugins/extensions installed and disable, remove the ones you no longer use. Having an added benefit of speeding your system up, each of these adds a small risk profile as you are relying on third party code being secure running in the background. Removing plugins you no longer use or need reduces the surface area of attack. 4) Review ports you have open and close ports that are not needed. You will find the ConnectWise documentation here on what ports should be open. https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/020/010/020 . Don't just assume this is right - check. Ports like 3306 (MySQL DB Port) and 12413 (File Redirector Service) should absolutely not be opened up externally. 5) Keep your Automate up to date. ConnectWise are constantly fixing security issues that are reported to them. You may think you are safe on that "old" version of Automate/LabTech, but in reality you are sitting on an out-of-date piece of software that is ripe for someone attacking 6) DON'T share credentials except in cases of absolute necessity (one login is available ONLY and you can't afford a single point of failure if that one person that knows it disappears). <-- Courtesy of @MetaMSP 7) DO ensure that robots.txt is properly set on your Automate server. If you can Google your Automate server's hostname and get a result, this is BROKEN and should be fixed ASAP. <-- Courtesy of @MetaMSP 8 ) Firewall Blocking. I personally block every country other than the UK and the USA from my Automate Server on our external firewall. This greatly reduces your chance of being attacked out of places like China, Korea, Russia etc. 9) Frequently review the following at your MSP Check that the username and passwords set are secure, better yet randomise them all and use a password manager Treat vendors/services that don't support or allow 2FA with extreme prejudice. I will happily drop vendors/services that don't support this. If you 100% still need to keep them, setup a periodic review and pressure them secure their systems because you can almost guarantee if they are not doing customer logins properly that there will be other issues Setup a periodic review to audit users that are active on all systems. PSA, Office365, RMM, Documentation Systems (ITGlue/IT Boost) Audit 3rd Party Access, Consultants and Vendor access to your systems <-- Thanks @SteveIT 10) DON'T share credentials except in cases of absolute necessity (one login is available ONLY and you can't afford a single point of failure if that one person that knows it disappears). <-- Courtesy of @MetaMSP
  12. Version 1.0.0


    This SQL can be imported in System > General > Import > SQL File. It will add an additional role definition that detects when a TPM is in a ready state.
  13. Version 1.0.0


    This SQL can be imported in System > General > Import > SQL File. It will add an additional role definition that detects when a TPM is present.
  14. I completely agree, which is precisely why there should be a proper structure in place for reporting security vulnerabilities. Losing vulnerabilities because a support ticket got closed because a partner didn't respond is serious amateur hour stuff. This is also the second time I know of it has happened (one of my privately reported ones got lost in the same way, mostly because the initial support engineer could not comprehend what I was trying to raise). I implore ConnectWise to put a proper procedure in place for reporting security vulnerabilities allowing for responsible disclosure. In the mean time at least train the existing staff to escalate anything like this immediately to the appropriate resource.
  • Create New...