Marcos

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.

I'd recommend raising a support ticket since further investigation and logs will be needed.

Yes, we did a mistake in the past when we announced ETA too early and then it turned out that the development and especially subsequent testing took a lot of time. A lesson learned and since then we tried to avoid giving any ETA unless a particular product or feature was about to be released. We apologize for that.

We expect a new Outlook plug-in to be implemented next year.

You wrote that you had Endpoint configured to connect through http proxy.
Please refer to the Troubleshooting section at https://help.eset.com/protect_deploy_va/90/en-US/enable_apache_http_proxy.html:
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
 

Nope, it's unrelated.

Pre-release updates have passed QA tests and were found to be suitable for release. In 99% same modules from the pre-release channel are later released for all users. If we get no feedback from users with pre-release modules, these are released for all typically after a couple of days.

Does temporarily pausing real-time protection make a difference? What version of ESET Server Security do you have installed?

Please try switching to the pre-release update channel in the advanced setup and see if it makes a difference.

Just to make sure, did you continue as follows?
- enabled advanced logging
- opened Running processes
- after a while disabled adv. logging ?
In case when there's a problem with LG communication (e.g. if network is disconnected), the following is logged:
"encrypted Http LiveGrid request to c.eset.com ended up with error 21202"
Also the SysInspector log that you generated with ELC contains LiveGrid data so it doesn't look like a communication problem. Please let us know if the CloudCar test file is detected upon download as itman asked.

Endpoint connects either directly or through an http proxy server, if configured. If there are changes in network, we detect them and use the current DNS server for address resolution.
If a machine sometimes connects through a proxy and sometimes directly, you may need to enable this setting in the proxy setup:

Does switching to the pre-release update channel in the advanced update setup make a difference?

Why the vulnerability in Log4j poses a grave threat – What businesses should know about Log4Shell – ESET wraps up a series of deep-dives into Latin American banking trojans
The post Week in security with Tony Anscombe appeared first on WeLiveSecurity
View the full article

Dobry den,
Automaticka kontrola pri starte je dolezita ochrana, nakolko moze odhalit uz pri starte, resp. po aktualizacii potencialy malware, ktory by mohol bezat v pamati. Standardne trva max. niekolko sekund a bezi s nizkou prioritou, ktora sa da nastavit vo vlastnostiach prislusneho tasku:

Ak viete problem zreplikovat manualnym spustenim tasku z kontext. menu v Scheduleri, zapnite predtym Advanced OS logging pod Tools -> Diagnostics:

Po niekolkych minutach, pocas ktorych bezi startup sken, vypnite logovanie, pozbierajte logy s nastrojom ESET Log Collector a nahrajte sem vygenerovany archiv s logmi. Ten moze byt dost velky, v takom pripade ho nahrajte napr. na OneDrive, Dropbox a pod. a poslite mi linku na stiahnutie.

We understand that not all users want to update to the latest version automatically, that's also why we provide the option to turn off automatic program updates with the exception for security and stability updates. You can even specify the last version that you want to keep installed:

I'd like to emphasize that program updates (uPCU) are not released immediately with new versions of Endpoint. There is at least 1 month delay before the release and distribution to users. If a non-trivial issue is reported during the period, we fix it, prepare and test a new build which is then released and the 1-month delay period starts to count down again. Only then we start to distribute the new version automatically and gradually to users.

Are you currently in Indonesia? Both licenses were purchased there so you should not have issues activating them unless you're in a different country.

No. The program updates (also referred to as uPCU) are downloaded and installed only after the machine has been restarted so the upgrade is seamless.
No. Program updates are installed when the system starts next time. All features are fully functional and are not temporarily inactive while a restart is pending.
 
 

Not sure if it would be possible without any adverse effect on performance. At any rate, we cannot change unrelated system settings. If administrators prefer not to use Fast startup, they must disable it themselves in Windows.

The changelog is available within the announcement on this forum for instance. In case of the latest version v9.2032.6 (some language versions have 9.2032.7), the only change was an important security fix.

That's because the setting is not applied for security and stability updates. V9.0.2032.6/7 is a security update.
https://help.eset.com/ees/9/en-US/security_stability_updates.html

In this case it is an important security update which is installed and therefore the protection status changes to red and tells to reboot the machine. After the reboot, the product will be upgraded to the latest v9 version and no further restart will be needed. In the future when there's a standard program update available, the protection status won't turn red and users will not be distracted by a change of the protection status. Upgrade will be performed silently the next time the OS is (re)started.

In this case it is an important security update which is installed and therefore the protection status changes to red and tells to reboot the machine. After the reboot, the product will be upgraded to the latest v9 version and no further restart will be needed. In the future when there's a standard program update available, the protection status won't turn red and users will not be distracted by a change of the protection status. Upgrade will be performed silently the next time the OS is (re)started.

I have reached out to the German sales to make sure to remove the information about the already discontinued product for Linux from the purchase information above. If you don't need a license for all devices because of this, you can contact the seller for a complete or partial refund.