I agree and have spoken with SimpleHelp support about this before. There needs to be a confirmation prompt to the technician. We have been burn a few times on running the wrong toolbox task.
I would highly recommend that the logoff button be moved to the top row where you see remote support, access etc. I have been using Simple Help for nearly two years and never realised that there was a logoff button because I usually never click on that preferences tab.
Sorry you misunderstood me. I don’t recommend removing the ability to deploy scripts etc to say 700 computers. However I think that there needs to be more security steps/confirmation to ensure that you really did intend to run that toolbox to prevent a malware script from accessing the toolbox and running things automatically. Another feature I could suggest would be before a file is deployed to machines it is checked against virustotal.com to make sure it’s not a virus. There are lots of things that can be done to protect against malware scripts, although it sounds to me in this particular case that a human agent manually did the damage.
Thank you for confirming about remote access Service Machines as this was something I wanted to look into. My next step will be to decide whether to have all clients using tcp or udp as the connection.
I would like to see the ability to send the logs to syslog (in linux) or event viewer (in windows) or other logging service.
Or even a way to specify they be automatically sent to a rsync or sftp service.
Can someone point me to the specific setting that restricts a tech from running scripts outright? I understand why some of you guys want to run scripts against all Access PCs at once, but this is not a feature that we need.
The tech PC that was hacked was not logged in as SimpleHelpAdmin. I don’t understand how the hacker was able to remove the logs without being a Simple Help Admin. The hacked PC was also outside the SimpleHelp server LAN, so it only had access to Simple Help server via the Simple Help technician client.
We do have nightly backups of the SimpleHelp server. I’ll see if a backup from the night of 7/13 would happen to contain any trace of their activity. If the rogue connection and the deletion of the log file both happened ‘after’ that backup, then they have successfully covered their tracks.
You should log in as administrator, click on ‘Groups’ in the administration tab, and then click on the group your techs are in. Then click on the ‘Permissions’ tab on the right, then scroll down to the ‘Toolbox’ section where you can allow tools to run in the access tab, and also whether tools can be run during sessions.
I noticed you and @Darrell_Swafford mentioning this months ago, but since the topic has been bumped I really, really third this.
Off-topic: The toolbox is frankly quite dangerous the way it stands, especially as it doesn’t carry over the notes via a tool tip or something. I often go to run something on a machine, hesitate about whether this is the correct tool, and have to go to the toolbox tab to look at the tool/notes and then go back to the endpoint, and I wrote the damn things. My prefered UI would be click the tool > this drops down/reveals a Run button along with the note for the tool if present > confirm that this will be run on $MachineName
If it could have an option to schedule a later time and a “skip offline machine” checkbox that would really make my year.
To be fair to SimpleHelp, Automate/Labtech don’t show the descriptions for the script either and SimpleHelp is definitely far better than anything from CW in terms of UI, but this would be a really important addition.
Great suggestion for the toolbox. Open a Feature Request ticket about it. I’ve found the developer to be extremely responsive to new ideas/changes/bug reports, with many of my requests ending up in the next released update.
There are risks with all automation. I feel like SimpleHelp has evolved it’s security to mitigate most issues. Provided the end user enforces good policy to back it up.
Never leave the tech console logged in and unattended. ESPECIALLY where the technician app is installed on a mobile device. Enable MFA. Never use the primary admin account for day to day. Enable session timeouts Make sure the device that is running the technician app is properly protected and secured.
The above is not a comprehensive list of security items but a good starting point.
Yay! I actually do all those things. The session timeouts are a pain, but I set them like that for a reason.
Another thing we practise: If you are on site, never be tempted to use a customer PC for remote support, just because you happen to be in front of it. Use your own laptop or tablet, or nothing at all.
Yes - MFA must be available and used on all systems where there is reputational, operational and security risks. A right pain as my main client has identified 150 web based systems already where there may be even a little bit of their clients data.
Many of them don’t offer MFA/2FA so are at risk of being banned. Worryingly, there are several major systems that don’t offer 2FA.