Sec-C

You could simply put a DKMS config file in the right place, so it is picked up automatically in case DKMS is installed. This does not hurt and does not add dependencies.

Description: use DKMS (Dynamic Kernel Module Support) for Eset Kernel Modules on Linux Detail: The forum is full of problem reports due to signing of eset kernel modules on Linux with activated secure boot. The standard solution for the problem is the DKMS framework, which takes care of automatic module signing on kernel update or eset update. Please drop the custom made signing script in favor of a DKMS based solution. It makes the whole update and signing process soooo much more reliable and predictable - which is why NVIDIA, VMware and most other Vendors use it to ship their kernel modules. We even had to hire a software developer, just to automate the eset signing for our fleet of Linux devices 🤦‍♂️. But it is still unreliable and we have to work around all the race conditions that would not even exist with DKMS.

We reviewed our different auto-update policies and now our clients are starting to auto-update as expected. We are using multiple auto-update policies and might have missed some ordering/inheritance problem. Unfortunately, the "request configuration" feature in eset protect 10.1 does not show the effectively used "auto-update" policy on a client (after merging the different policies). So we are not 100% sure. Maybe Eset just changed something on their end, which allows auto-update to propagate better...

Strange. Is this an acknowledged bug? What is the point of configuring an auto-update, if you need to trigger it manually🤔

Same here. The eset scheduler of our clients shows an "update" Task, which runs every hour automatically. But it but won't find the 10.1.2063 update. When running the same task manually (right click -> "run now") the client suddenly finds the update. Is this expected behavior? Our "auto-update" policy explicitly allows updates up to 10.1.2063.0

@Marcos, in our case all devices are running Version 10 (Agent + Endpoint or Server Security) - not version 11.

Today we suddenly have ~700 devices, which report this Warning. It would be really helpful to know if this is caused by a temporary fault in the central EPNS Infrastructure, so we can stop looking for a possible cause in our own infrastructure. Our whole team already spend half a day trying to debug this. Is there a EPNS problem right now? It seems like the Warning does not disappear - even if the problem is resolved. We sent "wake up" EPNS call to some of the affected devices. They reacted immediately, but still reported a problem reaching the EPNS?!?

We tried starting the eset service manually on ~10 machines. There where no more obvious errors afterwards. We have not tried additional reboots, since we need the machines online. Is there a way to make the agent try starting the security product?

We also have ~40 win servers VMs with the same error message. And this is just the first batch. Is there a way to prevent this from happening? We have hundreds of VMs ready for automated win update deployment and we really can not handle them all individually afterwards.

Description: new client task "Upload quarantined file to Eset Protect server" Detail: Currently, files quarantined on an eset endpoint can only be upload to a windows file server (via client task). This requires 2 things: 1) a windows file server 2) network access to the windows file server (which can be a problem when the endpoint is a server in a firewalled DMZ) It would be much easier, if there was a way to request the transfer of a quarantined file directly to Eset Protect, using the existing management agent connection (agent port 2222 + agent http proxy settings). This way you can get hold of quarantined files immediately (for fast evaluation and response), without requiring additional infrastructure or network firewall changes.

Description: Improve Browser Plugin handling Detail: Browser Plugins are an ever growing security threat. They have privileged access to web traffic (inject/redirect traffic, read passwords, manipulate downloads), don't need admin rights, are persistent, remotely updatable, synced across all user devices, and their actions cannot be distinguished from the legitimate main browser process. Adware and Malware are increasingly often distributed as Browser Plugins. It would help to see a list of all browser plugins installed on a computer in Eset Protect without the need to deploy 3rd party tools (like Nirsoft's BrowserAddonsView). It would also help, if Eset Protect would offer a way to uninstall/block selected browser plugins

Description: Allow active directory group membership to be used in dynamic group templates or policy assignments Detail: We currently have a dynamic group template which sorts all devices of selected users into a "dynamic group". Then we assign special policies to these dynamic groups. However, the list of employees changes frequently and the list has to be updated by hand. On the other hand, our active directory has a user group which is automatically kept up to date. Instead of manually replicating the ad group members in the eset template, it would be easier and more reliable to just reference the ad group in the template and have a sync task replicate the usernames.

Short answer: No, there is no way. Lang answer: Eset Updates are digitally signed. This is how Eset verifies the integrity of downloaded files, even when they are transferred over an insecure connection. So in this specific scenario, there is no additional risk in using unencrypted http. The benefit of downloading updates over unencrypted connection is caching on your apache proxy. In an end-to-end encrypted download (https) the proxy would not be able cache any of the downloaded updates, since it sees only garbled ciphertext. It can only cache files from unencrypted connections. Blocking these unencrypted connections would defeat the whole point of using a caching proxy.

Description: Provide "process signature" and "process signature verification status" in real-time scaner logs Detail: In the logs of the real-time scanner eset already provides information which "process name" tried to access a suspicious file. Since a lot of windows security is based on processes signing, it would make sense to also add the signature information to the log. When the process name is "firefox.exe" and the process is signed by "mozilla corporation" and the process signature is "valid", then I can be sure that the process is not a virus pretending to be Firefox.

Hi there, now that Version 7 of Endpoint Antivirus for MacOS is released, I'm curious about the release plans for Endpoint Security 7. Is there any information available?

Can you elaborate? Does that mean that "Product updates -> update mode -> never update" is handled differently on clients and on servers? Or is there a different option to manage auto-update of critical patches on servers? I have not found this in the documentation.

I'm not sure about @st3fan's use case, but updates always carry the risk of breaking stuff. Which is why we test new releases before we roll out to thousands of managed devices. Eset has quite a history re-introducing problems that were already fixed in past releases (like here ). Another point is, that large companies usually have a software managment system that might undo your automatic update (downgrade) - just to watch eset redo the update - creating race conditions and reboots along the way... So every time you decide to ignore an explicit "do not update automatically" configuration our whole software management team starts to panic... We love the "waiting state" feature for updates - but PLEASE give us a chance to choose the activation date of this feature by ourself! In an enterprise environment we justify decisions for/against updates to our management and to our customers - not to Eset.

Customers running Server Protect 8.0.12003.0 don't see the critical update. Neither 8.0.12010 nor 8.0.12011. So there is no "waiting state" for those. Is this still an intended delay caused by "spread control"?

Some of our Eset users see this notification when opening Internet Explorer. Eset blocks an outgoing IE connection with Detection Name "JAVA/Exploit.CVE-2021-44228". Event Description is not "Blacklisted IP" but "Security vulnerability exploitation attempt". It does not happen every time IE is started. I suspect it's caused by something that is embedded in IE's default start page "www.msn.com". Maybe an advert.