Sec-C

I saw that support for MacOS 15 landed in Eset 8.1. Are there plans to support MacOS 15 in Eset 7 as well?

OK, this did not help. I unfollowed the subforum on thursday. The topic was no longer part of my daily digest mail. Today (monday) I started following the subforum again. 2 minutes later I got a new digest mail informing me about the creation of the same old topic 🤦‍♂️ Is anyone else seeing this behavior when following this subforum? Or is it just me?

Sorry, I should have been more accurate. Its not always the same mail. Its a daily digest mail ("one mail per day with new content from that day") - but the first entry in the mail is always this one topic. It is usually the only topic, since I don't follow many forums. But sometimes other topics show up further down in the same mail. I'll try your suggestion anyways and get back to you in a week.

Long time ago I started following the ESET Products for Windows Servers subforum by clicking the "follow this content" button. This worked fine for a long time. In February I started receiving a daily mail with the following content: "Marcos created a topic in ESET Products for Windows Servers ESET Server Security 11.0.12008 for Microsoft Windows Server " All other topics send creation mails only once (right after creation). Only this single topic keeps sending repeated "topic creation" mails, like it's beeing re-created every day. Is there a chance of fixing this? I don't want to unfollow the subforum, just because this one topic keeps sending weird mails.

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?!?