st3fan

Hi @Peter Randziak I messaged you privately. Please advise which logs you need. Thank you.

Follow-up question: since we generally only reboot servers for Windows updates, is this going to cause problems if both Windows updates and the ESET update is done at the same time?

We use ESET Protect 9.0.1144.0 and have ESET Server Security 8.0.12011.0 installed on our Windows Servers. Yesterday we started noticing that some of our servers are automatically updated to ESET Server Security 9.0.12013.0. This seems to happen even though we have disabled this new auto-update feature, following these intructions. I would like to understand why the 9.0.12013.0 update is being rolled out and I hope someone can clarify this for me. 1. According to this article, only ESET Endpoint Antivirus/Security 9.0 and later and ESET security products for Windows Server version 9.0 and later support automatic updates. We currently use ESET Server Security 8.0.12011.0, so why did we receive the automatic update? Sounds to me this is not even supported. 2. According to this article, it is not possible to disable the auto-update for "security and stability" updates. Is ESET Server Security 9.0.12013.0 a "security and stability" update? In the release notes I found this: - Fixed: Issues with upgrading to the latest product version - Fixed: Issues to uninstall a product version - Fixed: Machine deadlock after a reboot Sounds like it might qualify as a stability update, however, do these bugs and fixes even affect our version 8.0.12011.0? I am honestly confused about ESET's approach. Half of our servers are now red in the PROTECT console, we have no clue what is happening and no control over this entire process. I would appreciate if someone could explain to me why we are receiving this update in this case, referring to points 1 and 2. Thanks a lot!

In one of your previous replies you specifically mentioned that "servicing updates with stability and security fixes... are mandatory, however, currently we offer an option to skip even such critical servicing updates on servers". Is this no longer the case @Marcos? Does this not apply to ESET Server Security version 8.0.12011.0, for example?

@Marcos please let us know how we can skip these updates in future. Thank you.

Please advise how we may skip this?

But aren't you contradicting yourself? Based on your previous comment, I assumed that automatic updates should only apply to builds where security vulnerabilities were fixed? Did I misunderstand you? I can understand if servers are forced to version 8.0.12010.0 since this version contains a fix for CVE-2021-37852. But I cannot understand why they would be forced to version 8.0.12011.0. Does version 8.0.12011.0 contain security fixes that would justify the auto-update? Yes I understand that version 8.0.12011.0 also includes the fix for CVE-2021-37852 but my point is that servers should only be auto-updated to version 8.0.12010.0 in order to receive the security fix for CVE-2021-37852 - and not to version 8.0.12011.0. It takes weeks for us to evaluate and test new ESET versions. I do not feel comfortable this way. There is no way for us admins to evaluate and test newer versions anymore. As soon as we reboot, we are on the latest versions. We have zero control - and it should not be this way.

This only seems to affect ESET Server Security version 8.0.12010.0. 8.0.12003.0 has not received any automatic updates from what I can see. 8.0.12010.0 has been updated to 8.0.12011.0. Please advise what is going on @Peter Randziak and how we can avoid this from happening again. Thank you.

Hello @Peter Randziak Thanks for clarifying this. This highlights the dangers of this approach in my opinion. On servers we use ESET Server Security 8.0.12010.0. All our servers have now received an automatic update too. They all appear red in the web console, saying that a device restart is required and that a "Security and stability update to newer version is prepared". Version 8.0.12010.0 does contain the security fix. Version 8.0.12011.0 does not contain security fixes according to the changelog. Please, what on earth is going on here and how can we stop this? This should not happen unannounced and unplanned, certainly not on servers.

hmm ok. We didn't have any 8.1.2037.2 endpoints in our environment. That's why I am a bit surprised that some were upgraded to 8.1.2037.9 instead of 8.1.2031.3. This does not make sense to me. There were quite a few other fixes in version 8.1.2037.2 that are not related to security at all. I don't feel comfortable with these automatic updates to be honest, especially if this is not consistent. Please correct me if I am wrong but according to the documentation and your feedback, endpoints on 8.1.2031.0 should never be auto-updated to 8.1.2037.9 They should only be auto-updated to 8.1.2031.3.

Hello @Peter Randziak RSS and RSC has not made a difference for us unfortunately. My colleague has opened a ticket with Support. I will keep you posted.

@Peter Randziak / @Marcos one more question please. All our endpoints had version 8.1.2031.0 installed. Some of them updated to 8.1.2031.3 whereas others have updated to 8.1.2037.9. What is this dependent on and why is this not consistent?

Wow, thanks for clarifying this @Peter Randziak. Am I correct in assuming that this will not impact endpoint version 7.x and only 8.x and higher? Can this also impact ESET Server Security or only ESET Endpoint Antivirus?

Hi everyone When I logged onto the PROTECT web console today, I noticed quite a few yellow warnings, saying "device restart recommended" and "...newer version is prepared. Restart your computer". I looks as if all our Endpoint Antivirus 8.x endpoints have been updated automatically to the most recent 8.x version. First time seeing this. I thought that these auto-updates only apply to PROTECT 9.x and not to 8.x. And I thought this only impacts endpoint version 9.x but not 8.x. Does anyone understand what is going on? I emailed Support but they were just as surprised. I have reviewed the ESET Endpoint for Windows policy. There is an auto-updates option that is disabled (and this one clearly says that it only applies to version 9.0 and higher anyway. And then there is another section for "Product Updates" where "Update mode" is set to "Never update". This one only seems to apply to version 8.x and lower. And then there is a "pause auto-updates" setting (disabled) but that also only applies to version 9.0 and higher. Please advise what is going on and how I can stop these auto-updates for 8.x endpoints connected to PROTECT 8.0. Thank you! Regards, Stefan

Thanks for your comments @Peter Randziak and apologies for my late reply. We have upgraded a few servers to 8.0.12010.0 in the interim - unfortunately things have not improved. We will run a few tests so that we can answer your questions. I have asked the server owners to check regarding RSC and RSS.

Thank you.

@Peter Randziak please advise.

Is the HTTP proxy affected by CVE-2021-44224 or CVE-2021-44790 (see https://httpd.apache.org/security/vulnerabilities_24.html)? I would assume yes for CVE-2021-44224 since it is configured as a forward proxy (ProxyRequests on) and no for CVE-2021-44790 since mod_lua is not enabled. Would appreciate if ESET admins could clarify and update the now outdated apachehttp.zip (https://www.eset.com/int/business/download/eset-protect/#standalone) from 2.4.51 to 2.4.52. Thank you, Stefan

Hi everyone Once again we are experiencing slow network performance with ESET. We are seeing what has been described here (https://forum.eset.com/topic/22793-efs-network-performance-issues). Summarized, when we copy files (e.g. an ISO image) from any Windows Server 2012R2/2016 machine (most recent updates installed) to pretty much anything on the network (e.g. a NAS device), we get around 100 MB/s on a 10 Gbps Ethernet link. If ESS is uninstalled we see around 700 MB/s. We had the exact same issue last year. After countless tests and extensive troubleshooting with support, we upgraded to version 7.1.12010.0 back then. This kind of resolved the issue at the time, and we got around 500 MB/s instead of 700 MB/s - not perfect but much better than 100 MB/s. Many months ago we updated to version 7.2.12004.2 and to be honest, we kind of forgot about this issue. Lately we have noticed a lot of performance related issues and started troubleshooting again. And it turns out that ESS is once again the culprit. The ESS policy has not changed since the last time we experienced this problem. In fact, we added more exclusions. Despite all of this, we once again only get a fraction of the available network speed if ESS is installed. We immediately upgraded ESS to the most recent version (8.0.12003.0) yesterday, after we identified the root cause, but this has not made a difference. We are still troubleshooting and are doing lots of tests but there is no doubt that ESS is causing this. Is anyone else experiencing this? I would appreciate your feedback and would be grateful for any advice. Thanks a lot.

I see that version 2.4.51.0 is now available (https://www.eset.com/int/business/download/eset-protect/#standalone).

Thank you Marcos. Do you know why ESET does not provide a more recent version? I am assuming version 2.4.48.1 is affected by this (https://www.rapid7.com/blog/post/2021/11/30/active-exploitation-of-apache-http-server-cve-2021-40438)? Or does this vulnerability only affect 2.4.48 but not 2.4.48.1? In the ESET release notes I found the following statement but I am unsure if they are referring to the above vulnerability or something else: FIXED: Apache HTTP Proxy (v 2.4.48) replaced with the newer version (v 2.4.48.1) due to discovered vulnerabilities in the older version I would appreciate if you could clarify this. Thank you.

Hi everyone The Apache HTTP Proxy version (for Windows) that one can download from the ESET website is out-of-date and vulnerable (2.4.48.1). Does anyone know how to update this component to the most recent version (2.4.51)? Support has been unable to help so far. I downloaded the Windows versions listed here (https://httpd.apache.org/download.cgi#apache24) but I doubt this will work as the folder content seems to be different compared to the installer files that ESET provides (e.g. the entire "modules" folder seems to be missing). It would be great if anyone could point me in the right direction. Thank you.

Yes I did. It is just as bad unfortunately.

Thanks for your reply Marcos. Yep, that's what we did a few years ago when we first encountered this problem. We spent a lot of time on troubleshooting with Support but in the end we had to disable this setting. Pity this is still a problem after all these years.

Hi everyone We have had issues with the ESET addin and Outlook 2016 (but also with Outlook 2010, 2013...) for many years. Outlook often freezes when emails and attachments are opened, especially emails from shared mailboxes. What made a huge difference and fixed the problem for us: we disabled the scanning of "Read email" in "Web and Email - Email client protection". We only disabled the scanning of read email - sent/received emails are still scanned without causing any issues. Currently we are on Endpoint Antivirus 7.3.2041.0 and 8.0.2028.0. This morning I disabled the above policy for testing purposes as I wanted to see if things have improved in the interim. Outlook stopped responding almost immediately, so it seems scanning of read emails is still not working well. The are a few posts on this topic, so I a assume this is (still?) a common issue. How is everyone else handling this? Is disabling this setting still the way to go? Thank you. Regards, Stefan