Sec-C

OK, I expected "botnet detection" to also block outgoing traffic (from an infected bot device to it's c&c server). If you are right, it would in deed be difficult to test.

I tested several fedotracker IPs, but non of them were blocked by eset on linux. I also searched the logs for IPs blocked by eset on windows (detection name "EsetIpBlacklist.A" or "EsetIpBlacklist.B" + detection category "firewall"). Non the IPs blocked by eset on windows were blocked on linux. I tested by using a simple "wget hxxp://x.x.x.x".

Hi, I was wondering if there is a way to test if the botnet detection added in ESET Server Security for Linux 10.2.41.0 is actually doing anything. Maybe an harmless Test-URL or Test-IP I can use with wget/curl to see if botnet detection is blocking/reporting correctly. Something similar to what the EICAR file does for the on-access file scanner. Maybe even a list of test cases for each individual protection module available in Eset products.

We were looking for the cause and found there where some critical "Intel Management Engine Firmware" Updates in 2023. Lenovo seems to use a vulnerable driver to patch their vulnerable Intel-ME Firmware: https://download.lenovo.com/pccbbs/mobiles/n20rg24w.exe The "Lenovo vantage" updater still presents this package to unpatched devices.

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