plex

For anyone following or finding this post, more information is available here: https://support.eset.com/en/ca8223-local-privilege-escalation-vulnerability-fixed-in-eset-products-for-windows

Maybe you could use the web interface to configure the server they way you want, then export the settings and apply them to other servers? Web Interface Configuration Or, are you trying to get the license applied in order for the server to connect to eset.com and download updates? Activate ESET File Security 8 for Linux Or, do you have an old license type? If so, convert the username/password into the newer license key? License converter

We run EES and CbR as well. We usually see this happen with external storage and time machines (usually 100,000's of files, suspect it's trying to scan them all). Also, when an installer is mounted and has adware, EES and CbR will go back and forth touching the same file causing high CPU usage. Seems as though EES goes to scan it so CbR touches it, then EES sees CbR touch it and scans it, etc, etc... We've had 60,000 events get logged in our ERA in an hour due to this. Mostly happens with mounted installers, so just get the user to unmount it.

Our current policy locks all settings with a password. Therefore, users cannot change any of the settings. We originally deployed ESET for the first time last year with version 6.4.2014.0, replacing Symantec Endpoint Protection. With SEP, we could upgrade versions without users knowing it. No splash screens, no notifications, no calls to the support desk. This is our first update to EES in our environment since initial deployment. We have a small group of about 20 machines that we have been testing newer versions. The last version they had before getting 6.6.2072.2 was 6.6.2068.0. No splash or notifications were displayed so we didn't expect any issues. Originally we were about to deploying 6.6.2068.0 but it was pulled from the repository the day we went to deploy. 6.6.2072.2 became our only 6.6 option. Since the 6.6.2068.0 to 6.6.2072.2 went well for our test group, we figured we would be ok to proceed. Unfortunately this has been a nightmare. Despite numerous email notifications to users warning of popups from ESET, we are getting calls about EES needing activation, modules out of date, firewall not functioning, protocol filtering not functioning, anti-phishing protection not functioning, and a reboot is required. Users panic due to getting these warnings even though we have warned them. To make matters worse, even after a user reboots, many of these notifications are not clearing up until after a second reboot. We have 1800 Windows machines to update. We've only done 300 this week. We thought we would be done by now. We even tried the no GUI setting to see if it would help, sadly it hasn't. Initially we used the ERA console to push out the update. This ended with many failures due to users switching from ethernet to wireless or shutting down before the download completed. Why doesn't the download try to continue if interrupted? Seems like you could try several times before failing the task. Due to these failures, we have had to switch deployment to our client management software in order to ensure the installer gets downloaded completely. We are also doing this because we can hopefully avoid more calls by setting the install to start after the user logs in so hopefully EES will get installed and splash screen and notifications will show before they start working, use PowerPoint in meetings, or screen sharing with remote offices. Conversely, our upgrade of 800 Mac users went great. Users had no idea they got upgraded. No splash screen, no notifications, no drama. Exactly what we expected. If this truly is the expected and intended behavior, I would like to beg ESET to please get this resolved before our next upgrade cycle. It's leaving a very bad impression in people's minds about the product. It's becoming very difficult to convince users/managers/C-level that ESET is truly better than our Symantec protection. Are we doing something wrong? Is there anything we can do to stop the notifications and the support desk calls? Should I open a ticket again? We want to deploy a new version of the product without a user knowing about it. Is that too much to ask?

Thanks. Although I opened a ticket for this issue and was told it was expected behavior.

If we do a rename task using ComputerName, the Active Directory sync won't match up. If HostName was an option in the rename task, it would work because we have the FQDN set as the HostName. Then the AD sync will match up correctly. So if you gathered HostName as a Device Identifier on a Mac, you could add HostName as an option in the rename task which will make getting a FQDN to match up with an AD sync much more reliable. Or, at least something a company using LDAP/AD has a chance for a more reliable method of getting FQDN. Also, we can't use FQDN as the ComputerName because it would be confusing. If someone were to see a ComputerName is SAMPLE.EXAMPLE.COM, most people would think they could ping just SAMPLE. But that wouldn't work, they would have to ping SAMPLE.EXAMPLE.COM instead. I doubt most people would even think to do that. Also, a NSLOOKUP would might then result in SAMPLE.EXAMPLE.COM.EXAMPLE.COM, or in the case of a home router or different domain, something like SAMPLE.EXAMPLE.COM.OTHER-DOMAIN.COM.

Since there hasn't been a response, I'm hoping you were able to recreate this issue and are working on a fix before responding? If this is the case, is there an ETA on a fix? We are holding off on our 6.4 -> 6.6 upgrade for Windows machines until we hear back. We would prefer to not risk user phone calls to the support desk due to notifications showing up if we can avoid it.

Here's the results: testmac.example.com testmac.example.com testmac.example.com Here's locale: LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL= If this is similar to the method that is being used by the server, then we know why we are getting these results. Here is the NSLOOKUP results from the test machine: testmac.example.com:~ username$ nslookup testmac.example.com Name: testmac.example.com Address: 10.0.0.163 Name: testmac.example.com Address: 192.168.1.34 Since it's grepping anything with "^Name:", what ends up happening, for whatever reason (multiple adapters, DNS/router with old DNS entries), the script will return multiple names for one machine. We have one machine that apparently is getting 4 IP addresses reported from NSLOOKUP on their home router. So it has the name quadrupled in our ERA console. Another issues is that some home routers will use the WAN side for DNS results. This means that a machine outside of our company network may show the NSLOOKUP DNS results for the public IP address of the router (we also have seen this with our Macs). For example, we have a Mac named dhcp-1x-1xx-x4-1xx.wireless.northwestern.private right now. It also explains why special characters like the single quotes and spaces getting converted into decimal code. Probably due to what's happening with the script when translating the non-standard characters that a Mac will allow. We suspect you've had customers complain that their Macs (and maybe Linux) machines are not matching up with their LDAP/AD syncs. Since a Mac has 3 separate possible names for the same computer, and ComputerName is always set, you're using ComputerName as the primary choice for a Mac. Since this name typically doesn't (and probably shouldn't) have the DNS suffix, you're using NSLOOKUP to try and get the DNS suffix for a Mac. This is a tough situation, we wished Apple would make this more robust. Trying to get the DNS suffix from NSLOOKUP is unreliable. You may get more than one DNS result, which result do you choose? If the Mac reports back to your server and it's not on your company network, NSLOOKUP won't return the correct domain suffix. As you can see from our results above, we are setting our Mac's HostName to include our DNS suffix. We suggest you have a setting we can put in a policy to have the Mac clients use HostName as the primary name. Since the HostName is not set by default and may be blank, you could then fallback to using the ComputerName instead. Then, if we see a Mac that does not have the LDAP/AD name with the domain suffix, we can verify and fix the HostName on that Mac. You could then recommend to ERA customers that they populate the HostNames of their Macs to include the domain suffix so that it will match up during a LDAP/AD sync and results will be much more reliable than trying to guess the DNS suffix as you're having to do now.

This occurred immediately after upgrading the server from 6.4 to 6.5. All the machines with this issue should have had both the Agent and Endpoint Security before the upgrade took place. Sorry for being unclear. We discovered the removing from the console was not a good idea already. So I wasn't planning on doing that again. But, because removing from the console wasn't a good idea, we want to try uninstalling both the Agent and EES and then reinstall again. Hopefully it will generate a new GUID and we'll see if this was caused by the upgrade process or due to still existing issue. We won't be able to do this until tomorrow since we have to coordinate with an affected user. I'll report back the results once we're able to uninstall/reinstall.

The Device Identifier has the doubling as well. We have a hourly rename task. It ran 15 minutes prior to the above screenshot. Rename is based on Computer FQDN. Active Directory sync runs hourly as well. We are going to try uninstalling Agent and Endpoint Security and reinstalling to see if it will resolve. We found that when we deleted the computer from the console, it reconnected with the same GUID. The trace.log showed that no data needed updating after it saw the deleted machine had the same GUID so the computer name still was doubled.

Several Macs have the \266\128\153 in the name. Appears to be a single quote. U+2019 RIGHT SINGLE QUOTATION MARK, 0xE2 0x80 0x99 in hexadecimal, or 226 128 153 in decimal. So that explains what that part is, but not why it's displaying that way.

We upgraded from Server 6.4 to 6.5 and started seeing about 5% of the Macs with their names displaying doubled, eg. hostname hostname. Some seem to have strange path names in the computer name. Not all Macs have been updated to 6.5 Agent and 6.5 Endpoint Security. There are both upgraded and not upgraded Macs with the doubling issue. I've tried deleting a Mac from the Console and when it reports again, it has it's name doubled again. Server 6.5.522.0 Web Console 6.5.388.0 EES for macOS 6.5.600.1/6.5.376.0 Remote Agent 6.5.376.0/6.4.246.0 Below are Macs that show the name doubling. Also the last one has some weird path in the name that isn't part of the machine name. Since this has occurred with both Macs that have been updated to Agent 6.5 and ones still on 6.4, and it didn't begin until the Server upgrade, seems like it's related to the upgrade. Is there a fix I can do for this or will it require a ticket to be opened?

Also seeing Windows notifications as well. Shortly after this displays and checking the GUI, there are no issues showing. But, there is a reboot required showing in the console, so I'm guessing this is being displayed due to the reboot requirement. I'm going to guess that none of our polices are applying immediately after the upgrade occurs.

Just noticed on another system after the upgrade, in addition to the splash displaying, an "all moduled updated" notification displayed despite a policy not to display such notifications.

We are deploying Endpoint Security 6.6.2072.2 for Windows (from 6.4.2014.0) with a policy to not display the splash screen. After the upgrade occurs and EES is launched for the first time, the splash screen is displayed even though there is a policy to not display the splash screen. It does not display if you log off and back in again, or on reboot.

The post says 6.6.2072.2 did you mean that or is there another 6.6.2072.3?

Please disregard. This has been addressed with this post a moment ago: ESET Endpoint Security and ESET Endpoint Antivirus version 6.6.2072.2 and 6.5.2118.2 have been released

I was literally starting to deploy 6.6.2072.0 and created a task to test. A few minutes later when I went to create another new client task, version 6.6.2072.0 was not available but 6.6.2072.2 is available. I tried deploying 6.6.2072.2 but started getting "Package not found in repository" results from clients. Eventually, 6.6.2072.2 became available and it's working now. I came here to find out the reason for x.2 but found nothing. I noticed the announcement for 6.6.2072.0 is no longer sticky. Is a post coming soon for the x.2 update?

That's understandable. What about a web service that could be used to auto-populate the Web Access Protection address lists?

We recently had a problem with a successful phishing scam and it got me thinking. We have a system where users can report suspect emails to our security team for evaluation. They have it setup so it can automatically add a phishing URL to our web filtering via our SIEM. It helps us reduce (and also indirectly educate) users exposure to phishing scams. It is good that users on the company network have the phishing page blocked, but what about our remote/traveling users? It would be great if ESET could block those URLs for our remote users too. Unfortunately, the number of URLs makes it unreasonable to have someone use ESET's phishing report page to report them each time. So, is there an API we can use to automate reporting of phishing/malicious URLs? If not, would it be something ESET would consider providing one day? Is there a 3rd party that does have this capability that we can report to that is also used by ESET to gather phishing/malicous URLs? If not reported directly to ESET, could an API be added to the ERA system so we can automate the URLs to a list that is updated to our clients? Or both, to ESET and as well as our own internal list applied to clients?