cpetry

I honestly love ESET and I've been using your products since 2.X. I can remember being in high school using your products. So fast forward 10-12 years I'm a senior systems engineer. Being a senior IT professional, I gain influence over what products we use and I push the button to fire McAfee and deploy my lifelong favorite anti-virus - ESET. The biggest weaknesses ESET has in my opinion are -- 1) Management in a corporate environment. This is being improved. ERA 6.X is a step in the right direction regardless of how others feel. ERA 6.X's biggest issue is documentation and proper labeling in the GUI. It's not that the product can't do it, it's that the customer can't figure it out. I had to continuously click on things until I figured them out. One good example being the relationship between trusted zones and known networks in the Endpoint Security products personal firewall. 2) The installation/uninstallation/upgrade procedures. Now I have no idea if these issues are thanks to the Windows Installer or what, but ESET has huge issues getting onto a system. I've seen too many error 1603's, or general install/uninstall failures of ESET products. You need to use the same methods that the ESET rip and replace code uses to get onto a system. I understand the rip and replace product is a paid service. However, it can't be. It must be built into the product's logic and the natural way the product installs itself onto a system. If your customers can't get your products on their systems, it's useless to them. I don't like having to boot a system up into safe mode to run the ESETUninstall.exe application. The normal installer should be able to RIP out anything on that system that would otherwise conflict and replace it with the version of ESET a customer is trying to install. In situations where we've had to use ESETUninstall.exe in safe mode, we've tried to uninstall the product normally first, it fails. You'll get a window asking for the install files because something is corrupt and even pointing the product to the installer location doesn't work. This is my number one problem with your products. If you could just fix your installer I'd be very happy. We don't have a "ESET doesn't work problem". We have a "we can't get ESET onto all of our systems problem". It conflicts with itself so upgrades are something I take a pass on in favor of stability. Yeah, not upgrading my endpoints is a security risk, but the installation becoming damaged and not having any product running on the endpoint is an even bigger risk.

This confirmed bug is definitely an issue with migrating from 4.5 to 6.3 -- "You cannot upgrade from EFSW 4.5 to EFSW 6.x using the ERA “software install task” because the upgrade will fail due to a necessary restart." I've tried to use the "uninstall task" to remove 4.5 first, but that fails as well. So I can't upgrade and I can't uninstall to reinstall. There's also no rip and replace for file security. What's worked so far -- 1) Push the upgrade anyway, knowing it will fail. The upgrade actually UNINSTALLS the product. 2) Reboot after the failed "upgrade" aka UNINSTALL. 3) Push a new install task for file security 6.3, which will then work. 4) Log onto each server and make sure all components are running - some fail to work (on about 25% of my test servers I had to click enable on a component to get it started...) ** I have attached a picture of the components that fail to start on some file security servers; rebooting the server doesn't work, you have to manually click enable ** I hope these file security bugs are all fixed in 6.4.X. I have 200+ servers and the idea of having to logon to each one to hold ESETs hand would be daunting. I've seen upgrades UNINSTALL ESET products before. It's the reason why I'm afraid to upgrade ESET once it's installed. Every time I post about this or contact support I feel like I'm told this can't be and that I must be crazy. You need to start using the rip and replace technology for installation/upgrade. Or you need to revisit your installation/upgrade procedures. I constantly tell people on our IT staff once you get ESET installed don't touch it, don't even breath on it. It might randomly fail and require you to run ESETUninstaller.exe in safe mode for a clean install to work and fix it. In contrast the ESET rip and replace app works FLAWLESSLY. Why can't your products use the rip and replace code? Whoever wrote rip and replace actually knows what they are doing, because it works.

I think I was able to find a way to do the above. It's not documented. I know it's not because I went looking and clicked on all of the ?'s in the interface to see what each field did. I had to guess and hope. lmao It turns out inside of a home/work "known network" that field labeled "additional trusted networks" can actually take the catch-all addresses. So I was able to slap a catch-all subnet in there and I can now ping clients at other sites. Now I'm going to take this further and install the ESET Network Authentication app for added security.

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.

This happened to us to the point where we had to UNINSTALL ESET on 4-5 of our SYSPRO user systems. The program connects to an IIS6.0 server using http. The user thinks adding port 5555 (which is what the app uses) to the ESET web filtering HTTP filter is how you fix such an issue. I told him that makes no sense since that list of ports is what you WANT to scan not an exclusion list. Also, there's a KB article describing that ESET will scan ANY HTTP traffic on ANY port for ANY application on Windows Vista and newer. He insists that we need to add ports to that web filter though. I wish ESET would take the option to add ports to the HTTP scanner OUT since we all know it has no effect (if the ESET KB article is correct). ESET KB: hxxp://help.eset.com/eea/6/en-US/index.html?idh_config_epfw_scan_http.htm So, is your server using IIS6.0? If so, check this out. I haven't been able to try it because this user is preventing the infrastructure team from doing their jobs. https://support.microsoft.com/en-us/kb/828726 So now I have this user and his 4-5 works masquerading around on my network with no AV protection. Edit: BTW, it happened after the weekend of the 15th. I was told everything was working on Friday, April 15th, and the following Monday, April 18th, half of the SYSPRO users using K3 ovr HTTP couldn't connect to the server. The app was reporting error 400, bad verb, but UNINSTALLING ESET resolved the issue. Disabling the web filter had no effect. Also, we've tried using the ESETUnintaller.exe and installing the latest 5.X build of ESET. That didn't work either. So between the user not allowing us to troubleshoot further or take corrective action on the server we are left with "ESET did it..."

One of my biggest complaints with ESET is the installation process. It's a straight up battle repairing a damaged ESET installation. I've noticed on some systems the installation "decays" and if you attempt to reinstall it, it will fail. The only solution for me is to have the user boot up into safe mode and run the ESETUninstaller.exe app. It's to a point where I'm afraid to upgrade any of my clients to a newer build. My fear is they won't upgrade correctly, they'll become damaged, won't report back or worse will uninstall and then I will need field support to visit the endpoint/user. The installation process is exactly why I block PCU's for ESET. I have clients running on very old builds of 5.X because of it. I've seen ESET randomly disappear from a system before. This happens more often with the file security version 4.5 software. I have a damaged installation of file security on a server right now I need to repair. I have to boot the VM up into safe mode, run ESETUninstaller and reinstall it.

Yeah, I want the known networks list to have the ability to populate the trusted zone. This way if you put in a catch-all subnet, it's only in that trusted sites zone as long as you're within a known network. Say you're corporation "domain.local" uses 192.0.0.0 addressing scheme (it likely doesn't but this is an example); I should be able to list domain.local as a home/work "known network" and list 192.0.0.0/32 as the catch-all subnet for my entire network. Then, that catch-all would only populate into the trusted sites zone if the computer identified the network as the known network, you're home/work network. You could then go a step further and setup network authentication so that it's 100% solid. This way as long as your clients are on domain.local, and you had your catch-all subnets (one or more) listed, it would treat the entire network, not just one site, as the trusted zone, while only on the known network. If the endpoint went off of the known network, it would be marked as public, and that automatic population of the trusted sites zone, those catch-all addresses, would be pulled from the list, because they are only associated with the known network. If you paired that with network authentication, you wouldn't have to worry about hackers mimicking your corporate environment, as they would be missing the network authentication component, even if they copied your DNS suffix or subnetting. As it stands, the personal firewall in Endpoint Security 6.3.X isn't suited/fit for corporate use in my opinion. If you're someone who manages very large scale networks and has several dozen subnets, you will quickly come to the conclusion that the firewall in ESET Endpoint Security 6.3.X wasn't suited for a large scale corporate network. It would work much better for a very small company with a single site or a home user. ESET in my opinion is confusing "home/work network" with the term site. What they have defined as a "home/work network", one subnet, the subnet the client is running on, is NOT the corporate network, it's the site the endpoint happens to be running on.

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/

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

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.

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.

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

That's good to know.. At least that means for the most part that should work for us. Our workstation LAN is DHCP. We rarely hand out statics. If we hand out a static, it's because we are actually blocking that user from the network due to bad behavior and we don't want the blocked IP to float. So, if we had to, and I've mentioned it internally, we create known networks for each of our sites, and base those ones off of the DNS address being used at each site (which is normally the IP of that sites domain controller..)

I wish ESET would stop putting all of this effort in home product betas and focus on the business sector. It's crazy how bug laden the business 6.3.X products still are. I'm waiting on an ESET tech to call/email me so we can go over my concerns with the ESET Endpoint Security firewall. I want it enabled so it can detect and block file coder activity (requires the networks scanner which is apparently built into the firewall). Now I'll have to look out for this issue the OP is talking about. I was hoping to set my domain.local as the home/business network so LAN communication isn't blocked with the firewall on automatic mode. I just don't want it stopping the service desks remote control softwares.

Yeah, that's what I thought. I fixed the IO blender issue another way - all flash storage and plenty of physical CPU cores. I'll stick to the agent/endpoint on each guest approach for now. It works well with Smart Optimization/Scan enabled. I noticed you guys didn't have the host based scanning for a while. I figured you were pretty much pushed into it.

Would I still be able to use a dual update profile with a proxy in place with the Apache HTTP proxy acting as a cache? I have it setup right now so that if they can't reach my internal cache they hit up the ESET servers. This is good for laptops as well as DMZ servers. I think Sam is doing more research on the updating of clients on a large network. Even he mentioned getting a lot of different recommendations from various ESET employee, and he's an ESET employee. We only have a few test clients being managed right now. So if we are going to change anything now would be the time to do it. I'm waiting on my new licensing before we start the rip and replace. We are upgrading from the Endpoint AV to the Endpoint Security product.

How do people normally add their domain to the trusted zones list? I don't want the personal firewall blocking connectivity for domain.local to domain.local connections but I still want the network filtering to take place. Does the network filtering logic still apply for a trusted zone? By logic I mean IDS & network scanner (for file coders, etc). I was going to just add domain.local and list each DNS server (each DC) but we have over a dozen sites and I'd like to know how other large corporations handle the personal firewall. I'd like to leave it on automatic and still gain the benefit of listing all networks not in the trusted zones list as public. It also wouldn't let me list more than one DNS server in the "add zone" pop-up under trusted zones. The only thing I can think of being blocked based on unsolicited incoming connections for workstations would be our remote admin tools. If we do list things as a trusted zone is there anyway to report on what would have been blocked but wasn't?

You're right, it was the PCU files I used that caused my clients to uninstall vs updating (placed in the mirror directory in 5.X). I update by pushing full installers now and that works most of the time.

It's also not good the good end of security when updates fail and break the client leaving the client with nothing vs something. I'd rather handle everything by hand until I can see that ESET has polished their upgrade process. I can just as easily push a newer version to several systems to see what happens. I still occasionally have endpoints become corrupted and basically disappear from a system. I have a EFSE 4.5 installation right now that's actually malfunctioning on me. I have to uninstall/reinstall EFSE 4.5 on a few servers every now and then. I'm hoping it's better on 6.X.

I was told the updates are universal by Sam and that ESS would be able to update signatures for the AV as well as ESS. We are doing a full swing migration from 4.5/5.0 to 6.3.X. We only use File Security and now Endpoint Security. I'm not interested in using the other products right now. It's hard to configure anything by a "standard" with ESET when I have forum mods conflicting with ESET engineering. Honestly, I don't want automatic ERA or endpoint component updates. I've had very bad experiences in the past with trusting ESET's software to self-update components. I remember seeing a component update uninstall clients, not upgrade them. Of course according to ESET that never happened even though it clearly did as I remember reinstalling endpoint clients on the affected systems that day.

We have 1,650 clients, or around that, and we never had an issue with it. We had every system reporting back to a single ERA 5.X server. We are about ready to perform a brief test of 6.3 and roll it out. We've been on 4.5/5.0 for years. I've seen too many file coders hit us so we are upgrading to Endpoint Security.

Hello, This is definitely not our statement and/or attitude towards this product/situation. Could you please specify who told you this information and what might be the reason? Thank you, T. Sam didn't tell me to avoid the appliance but when calling support in the past I've been told a lot of people didn't have much "luck" as they put it, using the appliance. Sam did say he prefers the Windows based installation. I can see why after using the AGENT/Endpoint mirror "trick" to create an update mirror/cache on the network. Not sure I could have done that with the appliance. hxxp://help.eset.com/era_install/63/en-US/?mirror_tool_linux.htm Yeah, I knew about that. I consider it a half measure. Really this function should have never been pulled from ERA itself. I can understand why you did if most of your customers are smaller.

Yeah, it may not work for most people if that's the case. I have multiple blades with 18 x 4 Xeon processors (72 cores per full-height blade) and the storage system is a ~40 TB all-flash array connected to the blade center with 6 x 8 GB FC links. The blade center has two 10 GB redundant network connections to our core. So I think we will be okay....

I can tell you a lot of people have asked on this forum and those questions went unanswered for those people. I know I didn't know I could do this until I complained to ESET engineering that they removed the mirror function from ERA 6.X. So I'm telling. lol

Hello, This is definitely not our statement and/or attitude towards this product/situation. Could you please specify who told you this information and what might be the reason? Thank you, T. Sam didn't tell me to avoid the appliance but when calling support in the past I've been told a lot of people didn't have much "luck" as they put it, using the appliance. Sam did say he prefers the Windows based installation. I can see why after using the AGENT/Endpoint mirror "trick" to create an update mirror/cache on the network. Not sure I could have done that with the appliance.