Jump to content

Endpoint Security: Home/work network not being treated as trusted zone


Recommended Posts

Posted

It was 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.

 

I have it set to make any other network that isn't known to public automatically.

 

I'm running the latest version of 6.3.  I'm also opening a ticket since this product has several obvious bugs this may be another one.

 

Thanks

Posted

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 really hope this is a bug.  I can't imagine having to add each subnet on my very large corporate network to the trusted zone just so we can RDP/ping workstations.

Posted (edited)

So level 1 support confirmed it should automatically add IPs from a home/work network to the trusted zones like the GUI says it should.  So I'm scheduled to WebEx with level 2 support later today.

 

This "bug / bad behavior" is happening on all of the several systems I'm testing Endpoint Security 6.3.2016.0 on.

Edited by cpetry
  • ESET Staff
Posted (edited)

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.

For example, your network is 10.1.117.x, you connect new device, IP 10.1.117.19 is assigned. If I configure this network as Home/Work, the trusted zone is set to 10.1.117.x

You should be able to ping a machine 10.1.117.79 or connect via RDP to the machine with 10.1.117.19.

If user wants to ping outside of the trusted zone, for example to the network 10.1.222.X, then he has to configure a trusted zone in advanced settings to 10.1.0.0 and mask to 255.255.0.0

Edited by MichalJ
Posted (edited)

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.

 

If I add rules as a work around that's just as good as turning the firewall off (enabling RDP/ICMP for everything vs my domain.local).

 

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)?  

Edited by cpetry
  • ESET Staff
Posted

Thank you for your feedback. We will analyse your case further tomorrow with the respective developers. We will come back to you tomorrow.

Posted (edited)

I think there's multiple ways to make it more "compatible" with a large corporate network with a very unmanageable subnet list.  

 

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.

 

So I've noticed a few limitations with the personal firewall so far.  It's making it rather hard to actually use as a corporate endpoint firewall.  

 

I told ESET support to keep my case open until you guys can talk to the developers.  

 

Thanks!

 

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: https://dirteam.com/tomek/2009/10/06/one-subnet-to-catch-them-all/

Edited by cpetry
Posted

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.

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...