Hi folks,
We can add the option "shutdown webroot" check here: http://prntscr.com/ico9f6
on the policies manager for the agent, i get a captcha when click on shutdown but is there an option we can set a admin password or PIN when that option is selected? that way only the admin can shut it down.
Userlevel 7
+35
Hello @ , this feature does not currently exist but has been suggested by another user in our feature requests forum. Please take a look at the feature request and add your kudo to encourage our product team to implement this. Thanks!
Folks, we definitely need this option ASAP, we just got a ramsomware on one of our clients due to a RDP brute force attach they somehow get into the server disable the AV with the captcha and execute the ramsomware, is there an ETA for this feature?
Thanks
Thanks
Userlevel 3
+7
onuxtech,
You have two good questions. Managing whether the admin can uninstall is done through policies as you noted. In the instance you do need this ability, you can simply move the system into a policy that allows it. Once the admin is done working, move the server back to your standard server policy. This way, the agent is better protected.
In your reference to the RDP brute force, this is a difficult scenario. If your server is exposed to RDP connections from the outside (3389) – even if the port you are using is changed, the server is vulnerable. I would strongly recommend requiring a VPN connection to access the RDP and close your port forward. If this is not a possibility, it is important to enable a maximum number of failed logon attempts before the account locks. The default configuration will never lock the admin account, allowing RDP to be brute forced.
In relation to the agent being removed, if bad guys gain administrative rights to a computer, I have complete faith in their ability to disable any protection that is installed – password or not.
Hopefully this helps. Any questions, just ask.
Thanks,
You have two good questions. Managing whether the admin can uninstall is done through policies as you noted. In the instance you do need this ability, you can simply move the system into a policy that allows it. Once the admin is done working, move the server back to your standard server policy. This way, the agent is better protected.
In your reference to the RDP brute force, this is a difficult scenario. If your server is exposed to RDP connections from the outside (3389) – even if the port you are using is changed, the server is vulnerable. I would strongly recommend requiring a VPN connection to access the RDP and close your port forward. If this is not a possibility, it is important to enable a maximum number of failed logon attempts before the account locks. The default configuration will never lock the admin account, allowing RDP to be brute forced.
In relation to the agent being removed, if bad guys gain administrative rights to a computer, I have complete faith in their ability to disable any protection that is installed – password or not.
Hopefully this helps. Any questions, just ask.
Thanks,
Userlevel 5
+24
Note, this is a highly requested feature that I have asked for myself for 2-3 years now (in a feature request), as there are times when our techs need to temporarily disable a WR client for testing an app, with the idea in mind that it would be on a 10/15/20/30 minute reactivation timer that would turn Webroot back on, as it is difficult for a tech to remember everything, and the current method of turning Webroot off for us means setting the policy to Unmanaged or to one that allows shutdown from the GSM.@ wrote:
Folks, we definitely need this option ASAP, we just got a ramsomware on one of our clients due to a RDP brute force attach they somehow get into the server disable the AV with the captcha and execute the ramsomware, is there an ETA for this feature?
Thanks
I have yet to see any traction on this feature, or an ETA. Specifically, in concept the feature would allow a temporary disable of Webroot on the agent, from the agent, using a specified password, for a limited period of time, whereupon it would reactivate on its own. The first time, I was told this was a security concern, but honestly, I'd find the captcha more of a concern than any secure password I might implement (assuming I allowed our agents to be shut down that way; as an MSP, we don't unless there's a specific client need), and since our policy hides Webroot in the Start menu, it's also hard to manually start again.
This is a feature that is available on several competing products. Don't take this as a rant on my part, but it is a frustration.
A password or PIN to temporarily shut down protection would be extremely useful for us as well as an MSP.
Also, the fact that once disabled it gets removed from the System Tray is not ideal either. This means that the user has to manually search for the application elsewhere to turn it back on, as previouosly mentioned.
An ETA on the feature request would be much appreciated.
One other note, the feature request linked above is marked as "Closed/Archived" with a note saying that "it's in the backlog!"... To me, this is misleading and suggests that the request has either already been completed, or is not going to be implemented. I think it would make sense to leave it as "Under Review" so that if there are more customers that would like to weigh in to let the developers know how important a request is to the customer-base, and could therefore move up the priority list or "backlog".
Also, the fact that once disabled it gets removed from the System Tray is not ideal either. This means that the user has to manually search for the application elsewhere to turn it back on, as previouosly mentioned.
An ETA on the feature request would be much appreciated.
One other note, the feature request linked above is marked as "Closed/Archived" with a note saying that "it's in the backlog!"... To me, this is misleading and suggests that the request has either already been completed, or is not going to be implemented. I think it would make sense to leave it as "Under Review" so that if there are more customers that would like to weigh in to let the developers know how important a request is to the customer-base, and could therefore move up the priority list or "backlog".
Userlevel 7
+35
Here is the response from our product team:
This is a feature request that is absolutely on our radar, but we unfortunately don’t have a release date to share just yet. We appreciate the importance of the feature and are working on a programme of releases through the next 6-9 months that will update the underlying code base for our console as well as its supporting technologies.
This foundational work will cement an enhanced and tuned platform for our services to run within, allowing our development teams to release this feature (along with additional administrative features) more easily than we currently can.
Having said all of this, we’d love to make sure we have your request detailed accurately. Would you be willing to join a call with one of our PM’s, and they can run through this, what’s in the pipeline and get your feedback on the direction we’re heading?
This is a feature request that is absolutely on our radar, but we unfortunately don’t have a release date to share just yet. We appreciate the importance of the feature and are working on a programme of releases through the next 6-9 months that will update the underlying code base for our console as well as its supporting technologies.
This foundational work will cement an enhanced and tuned platform for our services to run within, allowing our development teams to release this feature (along with additional administrative features) more easily than we currently can.
Having said all of this, we’d love to make sure we have your request detailed accurately. Would you be willing to join a call with one of our PM’s, and they can run through this, what’s in the pipeline and get your feedback on the direction we’re heading?
@ wrote:
Having said all of this, we’d love to make sure we have your request detailed accurately. Would you be willing to join a call with one of our PM’s, and they can run through this, what’s in the pipeline and get your feedback on the direction we’re heading?
I can't speak for anyone else, but I would absolutely be willing to join a call to discuss.
Thanks!
Yes i can be contact it for the call.
Userlevel 5
+24
I would be available for a call, absolutely.
Userlevel 5
+24
@ wrote:
Here is the response from our product team:
This is a feature request that is absolutely on our radar, but we unfortunately don’t have a release date to share just yet. We appreciate the importance of the feature and are working on a programme of releases through the next 6-9 months that will update the underlying code base for our console as well as its supporting technologies.
This foundational work will cement an enhanced and tuned platform for our services to run within, allowing our development teams to release this feature (along with additional administrative features) more easily than we currently can.
Having said all of this, we’d love to make sure we have your request detailed accurately. Would you be willing to join a call with one of our PM’s, and they can run through this, what’s in the pipeline and get your feedback on the direction we’re heading?
Any traction on this phone call, Anna?
I need to keep pushing on this one. While I've detailed my request here, I can't stress how strongly this feature is needed, and has been needed for the several years it has been noted by myself and others through various feature requests.
Thanks for your assistance.
Userlevel 7
+35
I have not received an update, but I will find out and let you know.
+1
Was there ever any update on this?
Reply
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.