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?