Marcos

We didn't tell that a solution was available. The developer used future tense:
it will work from BPP module 1253.
I guess it was a misunderstanding of "it was fixed". Yes, it was indeed fixed in the code but the second part of the sentence was telling that it will be available in a next version of the module. ESET staff (typically developers) that replies in this forum besides moderators may not have experience with how to formulate replies precisely to avoid possible confusion so please bear with them. Moreover, they are not native English speakers.

ESET's products fully support Windows 11.

ESET's products fully support Windows 11.

Thanks for the heads-up, fixed.

Thanks for the heads-up, fixed.

Please try it now. We believe that the issue has been resolved with the latest BPP module 1256.

You have purchased a boxed version of ESET so the code that was supplied with it expired with the new year. Please contact the seller or your local ESET distributor for a new code.

It should help if you do not set the above setting via a policy. After a reboot or after disabling and re-enabling the above setting the warning should be gone.

If you didn't install v15 from scratch but have also custom firewall rules created years ago by an older version, I'd recommend resetting settings to defaults or uninstall EIS and installing it from scratch.

Currently it's not possible to remove it. When opening Internet banking sites, the green border indicates the user that a secure browser is being used and that the payment will be secured by BPP. Without that, users could doubt if a secure browser is active or not.

Did you configure Apache HTTP proxy as per https://help.eset.com/protect_deploy_va/90/en-US/?enable_apache_http_proxy.html ?
Troubleshooting
If you get the EPNS service servers are not accessible Web Console error, follow these steps to disable the connection timeout limits:
1.Create a configuration file reqtimeout.conf:
sudo touch /etc/httpd/conf.d/reqtimeout.conf
2.Open the file in a text editor:
nano /etc/httpd/conf.d/reqtimeout.conf
3.Type this setting into the file:
RequestReadTimeout header=0 body=0
4.Save the changes a close the file:
CTRL+X > type Y > press Enter
5.Open the httpd.conf file:
nano /etc/httpd/conf/httpd.conf
6.Add the following line at the end:
IncludeOptional conf.d/reqtimeout.conf
7.Save the changes a close the file:
CTRL+X > type Y > press Enter
8.Restart the Apache HTTP Proxy service:
systemctl restart httpd

There are currently no such plans since LiveGuard is a feature generating extra costs, hence it's included only in the premium product ESET Smart Security Premium.

You would have to simulate an actual attack to get a notification about security vulnerability exploitation attempt.

While users were protected in this case, I could imagine how this could be misused to evade detection. I've created an improvement proposal for developers who deal with automated detections and blocks so that such files are blocked in LiveGrid.

While users were protected in this case, I could imagine how this could be misused to evade detection. I've created an improvement proposal for developers who deal with automated detections and blocks so that such files are blocked in LiveGrid.

Network attack protection works even if the firewall is disabled.

The root cause of the error is currently not known, the issue is being investigated.

I see the problem now, the module has been released for all products but v15-release. I've notified the HIPS developer to look into it and release it also on v15 regular update channel.

We didn't tell that a solution was available. The developer used future tense:
it will work from BPP module 1253.
I guess it was a misunderstanding of "it was fixed". Yes, it was indeed fixed in the code but the second part of the sentence was telling that it will be available in a next version of the module. ESET staff (typically developers) that replies in this forum besides moderators may not have experience with how to formulate replies precisely to avoid possible confusion so please bear with them. Moreover, they are not native English speakers.

HIPS module 1427 has already been released for general public yesterday so you can switch to the regular update channel.
However, we recommend using the pre-release update channel on all but mission critical or work machines. Modules on the pre-release update channel have passed QA tests and later they are virtually always released for general public without changes. With pre-release modules you have always an option to switch to regular updates should an issue occur. This is not possible when using regular updates and a fix is not yet available.

We didn't tell that a solution was available. The developer used future tense:
it will work from BPP module 1253.
I guess it was a misunderstanding of "it was fixed". Yes, it was indeed fixed in the code but the second part of the sentence was telling that it will be available in a next version of the module. ESET staff (typically developers) that replies in this forum besides moderators may not have experience with how to formulate replies precisely to avoid possible confusion so please bear with them. Moreover, they are not native English speakers.

We didn't tell that a solution was available. The developer used future tense:
it will work from BPP module 1253.
I guess it was a misunderstanding of "it was fixed". Yes, it was indeed fixed in the code but the second part of the sentence was telling that it will be available in a next version of the module. ESET staff (typically developers) that replies in this forum besides moderators may not have experience with how to formulate replies precisely to avoid possible confusion so please bear with them. Moreover, they are not native English speakers.

Poziadali sme cesky support o znovuotvorenie pripadu, nakolko neevidujeme hlaseny podobny pripad. Tiket by mal byt nasledne rieseny v sucinnosti s ESET HQ.

Thanks for the heads-up. I see that it was a 3rd party phishing FP which was automatically resolved after several minutes.
https://www.virustotal.com/gui/url/b1d5fef9f7b900d8fec281dce088ffada06850ec8b6efe90541516828c7d4c3a?nocache=1
0 / 93

To sum it up, the issue may be caused by 2 things:
1, If you use Apache http proxy on Linux - the configuration of the http proxy is incorrect. Please refer to the post above how to fix it. Apache HTTP proxy for Windows is not affected.
2, If you don't use Apache http proxy - the issue is caused by a bug in Endpoint v9 which checks for EPNS connectivity even if checking for license changes via EPNS is disabled, ie. when the interval check is set to "Limited". Solution: change it to Automatic. If you need to have it set to Limited for whatever reason, there will be a fix via an automatic module update within a couple of days. Please use "Automatic" at least temporarily until the new Direct cloud communication module is available.