Sec-C

Hello @Sec-C
thank you for sharing this, the team responsible has a task tracked to analyze possibility of using it.
Peter 
Note for us: P_EESU-1800

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.

Does anyone know when Endpoint Antivirus version 10.1.2063.0 will be available via the auto-update mechanism? We would like to upgrade to this version due to the reported vulnerability (CVE-2024-0353) but our endpoints are not receiving this update yet (auto-update policies are applied). The update is only downloaded if a manual "check for updates" is done but it is not automatically deployed via the auto-update option yet.
Thanks,
Stefan

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

I also experienced this issue first in December and only on Server 2019 systems (mix of virtual and physical servers) and again now in January, although it appears to have spread to 2016 servers as well. Server 2022 doesn't appear to be affected so far.
As with others, it's a timeout on ekrn during the reboot following application of the monthly updates. Either manually starting the "ESET Service" or a second reboot will re-enable functionality.
I would also add that I think it's rather disingenuous to simply point at Microsoft and wipe your hands of the issue. Even if it is something Microsoft did to cause it, at the very least, you should be working with them to figure out why and what can be done to resolve this, whether it's on their end or yours. All it takes is one moment of inattention on a customer's part and there's a public-facing server with no protection for who knows how long until the problem is noticed. I personally feel like if you have no intention of taking this matter up with them and getting it resolved, I'm going to soon be forced to find another vendor. This is too big an issue to just shrug your shoulders and live with indefinitely.
 

Description: Dynamic Tag Creation
Detail: Our team would like the ability to automate the tag creation process in ESMC. We would like it so that we can apply a tag to a dynamic group and then that tag applies to all the children of that group as well.

Include BadUSB Prevention like G Data's USB Keyboard Guard. That would be cool. It scans all connected devices and after that, every other/new connected usb device will need to be allowed manually. user interaction or by eset protect backend.

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.

Thank you very much for your suggestion. We also have a negative filter in your backlog. We plan to pilot it on the computer screen with a new Filter Advisor (planned in H1/2022). Please stay tuned

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.

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.

Please check if the detection is still being triggered. Today the detection was fine-tuned to avoid certain false positives.