Skip to main content
To Customer Support To Customer Support
Hi,

I am trialling Webroot endpoint protection on a small network ( workgroup/no dedicated server) 3-5 endpoints.

 

We have two physically separate networks ( 3 endpoint and 4 endpoint). As the 3 point network does not need a constant internet connection we share one broadband connection  as necessary ( simply physically connect the router to the appropriate network's switch).

 

On our lesser internet used network we recently had an external  tech support technician log on do a remote sesion with Teamviewer to update some software. Although he could access the PC he was logged into he had problems accessing other files on mapped drives - he could "see" them but not access. I later discovered (email received late as internet connection was switched to smaller network) that Webroot had flagged an infection ( a false positive - both VirusTotal and Jotti's scan confirm ) on the PC he was logged into - Webroot is installed on that PC not the other two. I am now wondering whether it was actually Webroot which was blocking his access as the Webroot default policy seems to block unknown processes on an "infected" - even if a false positive - endpoint. I am presuming I am correct in my reading of the firewall policy ? As far as I know no firewall warning  fired during his session  and I can find no log of firewall events in the web interface logs.

 

I had trialled Prevx a couple of years ago but eventually had to remove it because of false positives taking up time. I would like to use Webroot as the client agent is so light on the system but  I fear now that Webroot endpoint protection - with Prevx underlying it - might also be prone to false positives ( it has cropped up for us within a week of trialling) which would also silently block network access as well.

 


  • Am I reading the situation/policy correctly ?
  • What suggested changes to the default policy would I need to make ?
  • Should the firewall not have an option to block internet but not local network traffic ? Switching the firewall off altogether would be too risky as then an unknown infection would have free rein to "phone home"/steal files/ passwords until it was recognised as bad in the Webroot cloud
  • Should the logs not record firewall block events at least ?
Sorry for the long involved post but it is in order to explain the environment / setup in which we are trialling Webroot.

 

All / any comments welcome. Thanks in advance

 

Rocky

 

 
Hi Rocky,

Please describe exactly what you mean by them being unable to access a file? What error or symptoms were encountered?

 

WSA blocks any program from accessing sensitive windows unless they are whitelisted as other protected applications or as legitimate remote access software by Webroot. Obviously TeamViewer is one of those and I've used it without issue.

 

The default policy is completely silent and designed for companies with no IT staff. You should make a copy to a new policy and go through each option deciding which you want before you review the product. . However, regardless of configuration there are no local identity shield/monitoring alertsfor users. Monitored/blocked processes for identity shield don't show up in the console. You'll have to look on the local client's GUI and scan log (right click green circle > scan log) and look for monitored processes.

 

2.) You'd need to specify exactly what you're trying to accomplish

3.) It's not a firewall in the traditional sense of the word. It on it hooks into the Windows Firewall/networking API in order to control traffic from processes it doesn't like. The firewall has no direct management ability. You cannot turn it off without causing an alert. Any firewall policies will need to be implemented through Windows Firewall via GPO.

4.) The logs show closed connections but they are very unspecific

 

Identity shield/firewall interactions are almost completely opaque to an administrator. I need more detail about what the technician encountered before I can say more. 
From our experience I know that portable application TeamViewer Quick Join (temviewerqj.exe) is marked as Bad by Webroot. Maybe that was the problem.
@ explanoit  - Thanks for your reply.

 

As I was not present at the time of tech support session I cannot be sure of what messages they received - only that they could not access files on the network that they needed. I am assuming the technician was competent on the particular software package but that may be a big assumption 😉!  I may be able to get more information when I speak again with them within the next couple of days.

 

Regarding going through the options in the policy one by one and determing what I prefer -  although I am reasonably "tech - competent " I found some of the options difficult to fully understand and am not sure I would trust myself to make the correct selections.I suppose I was hoping for something a bit more set and forget or at least a preset policy somewhere between silent audit and the current default.

 

It may be that the business version of Webroot simply requires a bit too much of a time investment for me - although I will keep my options open for the moment. Perhaps also the endpoint package is not best suited for our set up - I may perhaps be better off with multiple copies of the "consumer " version.

 

Rocky

 

 
@przemek83 - We were using the quick support version although it was not that file that was flagged - a bit odd that Webroot would mark legit teamviewer files as BAD ?

 

Rocky
@ wrote:

@ - We were using the quick support version although it was not that file that was flagged - a bit odd that Webroot would mark legit teamviewer files as BAD ?

Yes it seemed strange at first glance but later we realised that it may not be so. From the point of view of end user it is odd but if I was an administrator I wouldn't want nobody to use this software without my permission. It can be used to send critical files from my company to the outside world. By marking it as BAD Webroot lets administrators decide whether they want to whitelist it or not...or at least I think so:)
Rocky,

If WSA needs to query the cloud to get a determination on your offline computers and can't do so, you're going to end up with a lot of unclassified files which WSA will treat with a higher level of suspicion than necessary. In the end, it is a cloud-based system. Not allowing it to connect to the cloud is going to somewhat limit its functionality. We always recommend leaving the computers connected to the internet when possible. Alternatively, you can parse through your list of undetermined software through the admin console and manually mark them, but that's extra work for you. Best advice is to leave the computers online to let the cloud do the heavy lifting.

Reply


Terms & Conditions