Eset Endpoint Security Trusted Zone

[Billy Habash]

Itwas my understanding that home/work networks (networks you set to home/work in known networks) are treated as trusted zones? Do I have to nest the known network into the trusted zones somehow? I can tell you this isn't working. I can see the network connection being listed as home/work network. However, RDP/ICMP is being blocked to my system from another system on the network on the same known network.

My network connection is showing up as home/work right now. It's the only connection enabled on my system (a single wired connection). However, if I open the firewall and view trusted zones, it shows no IP addresses being "automatically populated" as it says they should.

I have checked with one of the QA engineers. Basically, wen you configure any network as being Home/Work, trusted zone will be set as /24, meaning trusted zone is anything that matches on mask 255.255.255.0.

If I have to list all of my subnets in my trusted zone I may as well turn the personal firewall OFF. We are a large company. These subnets may overlap with something any other public network would use. I would honestly be shocked if they didn't overlap.

That's why I added my domain.local as a known network. I was hoping that would open up that entire network connection as being trusted while on a network with my domain DNS suffix. That's how it should work in my mind. In other words, the trusted zone should be dynamic for security reasons. I don't want anything in that trusted zone if they are on a public network matching one of my subnets if it's not a real known network.

Also, it's not showing anything in my trusted zone at all, shouldn't that populate with the /24 you mentioned (unless it doesn't show up in the trusted zone GUI but that logic is still applied automatically)?

1) When the customer marks a network as a known network, the adapter matching that criteria is whitelisted as a trusted zone. Yeah, hackers could set up a bogus network with the same DNS suffix and trick an ESET client into thinking it's trusted. However, they can honestly do the same thing with subnets being in the trusted zones list by subnet (they could create a subnet that they know your corp network uses).

2) You can have the customer list all subnets in the trusted zone, but allow some kind of linking to a trusted network. This way if the endpoint goes off of that trusted network, all of those subnet's drop out of the trusted zone. Right now if I list subnets in the trusted zone, they stay there, regardless of what network the client is on.

The first one would be easier on the customer. The scenarios where a hacker could trick the endpoint into thinking it's on a known network can honestly be done with either solution. The fact is if the user is connecting to somewhat known network - starbucks, a hotel, an airport, a home network. In other words, a user would have to connect to a network setup to trick the client. I can't think of any "legitimate" network that would share our DNS suffix in addition other identifiable perimeters.

Right now, the known networks feature bases it's "network identification" off of AND, not OR, logic. It would be nice to choose if it's "AND" or "OR" based logic. I found that out when I tried to list both my DNS suffix domain.local as well as my wireless SSID for my home/work known network. It turned out ESET would only identify my wireless as a home/work network when I had it set that way. I had to break it out into two known networks; one for DNS suffix safariland.local for wired, and one for wireless SSIDs for my wireless.

Edit: If ESET went with something like option 2, and you had to list subnets, but they would at least pop out of the trusted zone if it could be linked to a known network, I'd likely use a catch-all subnet for my network so it becomes more like option 1 for me (192.0.0.0/16,172.0.0.0/8, etc). I was talking to a co-worker and he agreed that he likes how the Windows firewall automatically knows that the network isn't a single site or subnet, and whitelists the actual corporate domain as the domain. Anyone who's managed a very large corporate Windows environment will have experience with catch all subnets. Ref: -subnet-to-catch-them-all/

I think I found my own workaround. You can list additional trusted addresses in the known network. Not sure why that field isn't documented. I tried hovering over the ? to see what it would tell me. It only told me what format the field took, not really what it would do. I had to start punching things into that field to see it was actually being used to populate the trusted zone. So that does help. It's not as automatic as it could be like the Windows firewall, but it will work and I can live with that.

It's not like I didn't look into how to do it or ask ESET support. I went through all of that and no one told me I could do that. I think this product is still so new even some ESET employees are still learning it. No big deal, I can understand that.

So I am helping my parents remove a virus from their computer. I, while computer literate, do not have a lot of expierence dealing with viruses. According to the AVG logs the virus was dectect on their computer and several files were removed including:

There virus scan was setup weekly and the next week it detected and removed the same files. The virus had set their LAN settings to proxy so when the virus was deleted this time, their internet stopped working, and that is when I got a phone call...

Anyway, I ran AVG and it removed several of these files again. I ran mbam and it also detected some additional files (not sure if they were all from the virus, who knows how long since they had checked for spyware, etc.)

I suspect that there are still some additional registry entries from the virus, as I noticed when I look at start-up items there is still a entry for dwm.exe (it is currently unchecked, and the file it references was deleted). The location is listed under SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Windows. I checked in that folder of the registry but I guess I'm not exactly sure what I'm looking for. Not sure if it is excessively important, but it's atleast unpleasent to still have the virus file on my startup programs list.

I disabled AVG as per the your instructions. I ran GMER and have included the log below (it indicates some AVG processes still running, but I triple checked the instructions to make sure I disable everything it said to). I could not get Combofix to run as it stated that it would not run unless AVG had been uninstalled.

Depending on your security settings, you may have to allow cookies and put the ESET website, www.eset.com, into the trusted zone of Internet Explorer if the scan has problems starting (in Vista this is a necessity as IE runs in Protected mode).

To do that, on the Internet Explorer menu click Tools => Internet Options => Security => Trusted Sites => Sites. Then UNcheck "Require server verification for all sites in this zone" checkbox at the bottom of the dialog. Add the above www.eset.com url to the list of trusted sites, by inserting it in the blank box and clicking the Add button, then click Close. For cookies, choose the IE Privacy tab and add the above eset.com url to the exceptions list for cookie blocking.

C:\Documents and Settings\Paul_Orig\Local Settings\Temporary Internet Files\Content.IE5\93HVTTC3\img[1].htmHTML/TrojanClicker.IFrame.AIW trojan (cleaned by deleting - quarantined)00000000000000000000000000000000C

C:\Documents and Settings\Paul_Orig\Local Settings\Temporary Internet Files\Content.IE5\93HVTTC3\img[2].htmHTML/TrojanClicker.IFrame.AIW trojan (cleaned by deleting - quarantined)00000000000000000000000000000000C

C:\Documents and Settings\Paul_Orig\Local Settings\Temporary Internet Files\Content.IE5\93HVTTC3\img[3].htmHTML/TrojanClicker.IFrame.AIW trojan (cleaned by deleting - quarantined)00000000000000000000000000000000C

C:\Documents and Settings\Paul_Orig\Local Settings\Temporary Internet Files\Content.IE5\G52Q9BPP\img[1].htmHTML/TrojanClicker.IFrame.AIW trojan (cleaned by deleting - quarantined)00000000000000000000000000000000C

C:\Documents and Settings\Paul_Orig\Local Settings\Temporary Internet Files\Content.IE5\RWLCP4BQ\img[1].htmHTML/TrojanClicker.IFrame.AIW trojan (cleaned by deleting - quarantined)00000000000000000000000000000000C

C:\Documents and Settings\Paul_Orig\Local Settings\Temporary Internet Files\Content.IE5\RWLCP4BQ\img[2].htmHTML/TrojanClicker.IFrame.AIW trojan (cleaned by deleting - quarantined)00000000000000000000000000000000C

C:\Documents and Settings\Paul_Orig\Local Settings\Temporary Internet Files\Content.IE5\RWLCP4BQ\img[3].htmHTML/TrojanClicker.IFrame.AIW trojan (cleaned by deleting - quarantined)00000000000000000000000000000000C

Tech Zone provides this operational tutorial to help you with your Workspace ONE environment. In this tutorial, explore how to configure and deploy the Workspace ONE Tunnel app across iOS, Android, macOS, and Windows platforms to enable Per-App Tunnel on a managed device. Procedures include enabling per-app tunneling on managed devices and SDK-enabled applications, configuration of Tunnel policies, deployment of the client and profiles to devices, and general lifecycle maintenance.

This operational tutorial is intended for IT professionals, network and security administrators, and Workspace ONE administrators of existing production environments. Both current and new administrators can benefit from using this tutorial. Familiarity with networking in a virtual environment, knowledge of Tunnel Service on Unified Access Gateway, and Workspace ONE UEM is assumed.

Workspace ONE Tunnel enables secure access for mobile workers and devices. Users have a simple experience and need not enable or interact with Tunnel, and IT organizations may take a least-privilege approach to enterprise access, ensuring only defined apps and domains have access to the network.

Tunnel provides industry-best security and builds on TLS 1.3 libraries, implements SSL Pinning to ensure no MITM attacks, and includes client certificates on the allowlist to ensure identity integrity. Combined with explicit definitions of managed applications and integration with the Workspace ONE compliance engine, Tunnel can help customers attain Zero Trust goals for their workforce.

3a8082e126