Nono

Following the release of the ESET PROTECT 11.0.19.0 virtual appliance I follow every steps of https://help.eset.com/protect_deploy_va/11.0/en-US/va_upgrade_migrate.html#recommended but when I try to pull the database, I end-up having this error: I tried to manually upload the "era-backup.sql" from my previous appliance and rename/put it on /opt/appliance/confi/db-upgrade-backup.sql but the error is the same. Is there a way to see the log and/or the script file to debug this ? Note: Regarding this "pull database" script, two things: 1. when asking for the host, luckily, using "user@host -p 2222" in case the SSH connection isn't on the port TCP/22 works, otherwise it wouldn't work on my case 2. I had to give the user "esmc" sudo priviledge (it wasn't the case on my current appliance). Could two things be the reason of the fail ?

At that time (as I already did), they simply answered : and after that that I can: You can disable the notifications by setting up a EP policy , or directly on the endpoints product as described in the links below: https://support.eset.com/en/kb8050-disable-windows-update-or-windows-firewall-notifications-in-eset-protect https://support.eset.com/en/kb6973-disable-windows-update-notifications-in-eset-endpoint-products Which isn't really helping...

It's kind of a duplicate of which is still going on ... We do *not* manage Windows update via WSUS and still have this behaviour on many W10 & W11 systems. Is there anything I can do to fix this ?

Hi itman, If I agree with your statement (and use it too on some occasion), it's not as secure as: Fine filtering as suggested Signed code check If you have something on a TEMP folder, this is something you clearly don't want to do (allowing EVERYTHING). For instance, you rule all softwares and scripts in any subfolder (including on the very untrusted C:\Users\\AppData\Local\TEMP\xxxxxxx\badscript.ps1) This is clearly a no-go for us and I can only highly suggest the same for anyone else.

Could you also (or instead?) consider using the rules based on codesigning ? That would be even more secured IMO.

No, "normal" update done manually. But we use a dedicated software for firmware & driver update.

We are several in our team reporting this issue, either on W10 and W11 (up-to-date to the latest build/version). ESET is showing available Windows Update : We all use the latest version of Endpoint Security Note: As soon as I click on "Run System Update" it goes green and no more update are seen as available. Also, I precise, the drivers & firmware are also up-to-date (via a dedicated software from the computer manufacturer)

Since many years now, I'm using HIPS to protect our endpoints, and for most of it, it works really well, the main issue is and always was, the filtering options to catch random folder/name of the application. This become quite difficult since we use VS Code, which trigger 2 alerts everytime we open it. The logs of those errors looks like this : Time;Application;Operation;Target;Action;Rule;Additional information 2023-05-10 1:43:33 PM;C:\Users\User\AppData\Local\Programs\Microsoft VS Code\Code.exe;Start new application;C:\Users\User\AppData\Local\Temp\vscode-update-user-x64\CodeSetup-stable-6a995c4f4cc2ced6e3237749973982e751cb0bf9.exe;Allowed;Executables ExecAsk; 2023-05-10 1:43:36 PM;C:\Users\User\AppData\Local\Temp\vscode-update-user-x64\CodeSetup-stable-6a995c4f4cc2ced6e3237749973982e751cb0bf9.exe;Start new application;C:\Users\User\AppData\Local\Temp\is-BVE93.tmp\CodeSetup-stable-6a995c4f4cc2ced6e3237749973982e751cb0bf9.tmp;Allowed;Executables ExecAsk; The issue here, relies on the fact that the filename (and not the path) are random char, when the HIPS rules can only afford a "wildcard" for folder, aka : to catch all you can use as filter: But you cannot catch any "*.exe" within this same folder. (see proposal here : )

any chance to see this coming in future version ? VS Code is a pain to use without allowing too much things ex: Time;Application;Operation;Target;Action;Rule;Additional information 2023-05-10 1:43:33 PM;C:\Users\User\AppData\Local\Programs\Microsoft VS Code\Code.exe;Start new application;C:\Users\User\AppData\Local\Temp\vscode-update-user-x64\CodeSetup-stable-6a995c4f4cc2ced6e3237749973982e751cb0bf9.exe;Allowed;Executables ExecAsk; 2023-05-10 1:43:36 PM;C:\Users\User\AppData\Local\Temp\vscode-update-user-x64\CodeSetup-stable-6a995c4f4cc2ced6e3237749973982e751cb0bf9.exe;Start new application;C:\Users\User\AppData\Local\Temp\is-BVE93.tmp\CodeSetup-stable-6a995c4f4cc2ced6e3237749973982e751cb0bf9.tmp;Allowed;Executables ExecAsk;

This is particularly annoying for VSCode with the Python Plugin. As we can't whitelist such file as they always have a new name. Or, is there a workaround that I can't think of ?

Description: Adding a more fine tuned way of filtering rules (HIPS, etc) Detail: Currently on HIPS rules, you can specify only the exact file name at the end of the path for source application. Wildcard works only for inner path like : C:\Users\\AppData to replace any AppData user's folder. It would be really useful to have a more fine tuned filtering options like the following : * (single wildcard) permits any sequence of characters between directory terminators. Single wildcards are NOT recursive. For example: c:\example\* allows anything to run in c:\example. c:\example*\temp.exe allows a file called temp.exe to run within in a single subdirectory of c:\example c:\example*\system*.exe allows any file with the extension .exe to run, within two subdirectories of c:\example (with the latter subdirectory called system) ** (double wildcard) permits any sequence of characters for the remainder of a path. Double wildcards ARE recursive. For example: c:\example** allows any file to run in c:\example and all subdirectories c:\example**.dll allows any file with the extension .dll to run in c:\example and all subdirectories ? (question mark) permits the replacement of a single character in a path. For example: c:\example\explore?.exe would allow c:\example\explorer.exe to run but not c:\example\explorer2.exe c:\??ample\explorer.??? would allow c:\example\explorer.exe, c:\example\explorer.dll and c:\trample\explorer.exe to run ?:\test.exe would allow the file test.exe to run on any drive letter.

Description: Adding a more fine tuned way of filtering rules (HIPS, etc) Detail: Currently on HIPS rules, you can specify only the exact file name at the end of the path for source application. Wildcard works only for inner path like : C:\Users\\AppData to replace any AppData user's folder. It would be really useful to have a more fine tuned filtering options like the following : * (single wildcard) permits any sequence of characters between directory terminators. Single wildcards are NOT recursive. For example: c:\example\* allows anything to run in c:\example. c:\example*\temp.exe allows a file called temp.exe to run within in a single subdirectory of c:\example c:\example*\system*.exe allows any file with the extension .exe to run, within two subdirectories of c:\example (with the latter subdirectory called system) ** (double wildcard) permits any sequence of characters for the remainder of a path. Double wildcards ARE recursive. For example: c:\example** allows any file to run in c:\example and all subdirectories c:\example**.dll allows any file with the extension .dll to run in c:\example and all subdirectories ? (question mark) permits the replacement of a single character in a path. For example: c:\example\explore?.exe would allow c:\example\explorer.exe to run but not c:\example\explorer2.exe c:\??ample\explorer.??? would allow c:\example\explorer.exe, c:\example\explorer.dll and c:\trample\explorer.exe to run ?:\test.exe would allow the file test.exe to run on any drive letter.

Thanks @Marcos, This seems quite unsecure especially for folder like "temp". Would it be possible to sugget a modification on this for future release ? It would be really nice to have something like : * (single wildcard) permits any sequence of characters between directory terminators. Single wildcards are NOT recursive. For example: c:\example\* allows anything to run in c:\example. c:\example*\temp.exe allows a file called temp.exe to run within in a single subdirectory of c:\example c:\example*\system*.exe allows any file with the extension .exe to run, within two subdirectories of c:\example (with the latter subdirectory called system) ** (double wildcard) permits any sequence of characters for the remainder of a path. Double wildcards ARE recursive. For example: c:\example** allows any file to run in c:\example and all subdirectories c:\example**.dll allows any file with the extension .dll to run in c:\example and all subdirectories ? (question mark) permits the replacement of a single character in a path. For example: c:\example\explore?.exe would allow c:\example\explorer.exe to run but not c:\example\explorer2.exe c:\??ample\explorer.??? would allow c:\example\explorer.exe, c:\example\explorer.dll and c:\trample\explorer.exe to run ?:\test.exe would allow the file test.exe to run on any drive letter.

We're using HIPS Rules filtering since few years now and I'm facing a new challenge. I usually use the following for generic cases : Real path : C:\Users\Admin\AppData\Local\Temp\AeaeAE\setup.exe Filtered path (without "Admin" and "AeaeAE" to make it generic) : C:\Users\\AppData\Local\Temp\\setup.exe But what shall I do to replace a dynamic name (in bod) within the application like so : C:\Users\Admin\AppData\Local\Temp\vscode-update-user-x64\CodeSetup-stable-74b1f979648cc44d385a2286793c226e611f59e7.exe I think *.exe isn't valid, is there something else I can use ? Version: ESET PROTECT (Server), Version 9.0 (9.0.2141.0) ESET PROTECT (Web Console), Version 9.0 (9.0.138.0)

Ok, so the captcha isn't visible on Chrome, but it is on Edge ... (what a shame). I don't know who to blame but this looks definitely like a bug to me... Note: I tried private navigation, without any cookies on Chrome, the captcha is simply never displayed.

Hi, I tried to access my licence management interface on https://ela.eset.com/ but it asks me to transfer it to a Business Account. When trying to do so on https://eba.eset.com/Account/Register it fails silently on the last step, when clicking on "Register". The Console says : ERROR Error: Uncaught (in promise): TypeError: Cannot read properties of undefined (reading 'value') TypeError: Cannot read properties of undefined (reading 'value') at e.<anonymous> (main-es2015.js?v=xxx:1) at Generator.next (<anonymous>) at vendor-es2015.js?v=xxx:1 at new Z (polyfills-es2015.js?v=xxx:1) at r (vendor-es2015.js?v=xxx:1) at e.onSubmit (main-es2015.js?v=xxx:1) at main-es2015.js?v=xxx:1 at Di (vendor-es2015.js?v=xxx:1) at s (vendor-es2015.js?v=xxx:1) at HTMLDivElement.<anonymous> (vendor-es2015.js?v=xxx:1) at T (polyfills-es2015.js?v=xxx:1) at new Z (polyfills-es2015.js?v=xxx:1) at r (vendor-es2015.js?v=xxx:1) at e.onSubmit (main-es2015.js?v=xxx:1) at main-es2015.js?v=xxx:1 at Di (vendor-es2015.js?v=xxx:1) at s (vendor-es2015.js?v=xxx:1) at HTMLDivElement.<anonymous> (vendor-es2015.js?v=xxx:1) at u.invokeTask (polyfills-es2015.js?v=xxx:1) at Object.onInvokeTask (vendor-es2015.js?v=xxx:1)

The fact that we DISABLE it (only on specific computer is intended). I ran the issue with the latest version of Dell Command Update (the software to update the firmware on DELL computers) : https://dl.dell.com/FOLDER06231658M/1/Dell-Command-Update-Application-for-Windows-10_34T96_WIN_3.1.2_A00.EXE Everything runs normally until the "real" copy & installation phase.

We're using ESET PROTECT: ESET PROTECT (Server), Version 8.0 (8.0.2216.0)ESET PROTECT (Web Console), Version 8.0 (8.0.175.0) with Client version: ESET Endpoint Security 8.0.2028.0 ESET Management Agent 8.0.1238.0 We have two sets of policies, one with Scan On > File Open is ENABLED and the other where it is DISABLED : On all the computer that have the feature ENABLED, it seems that Windows Installer failed to proceed. It simply hang forever. As soon as the feature is disabled, re-starting the windows installer succeed. I can reproduce the issue with two (private aka unsharable) .msi but can't seems to find any logs to troubleshoot the issue. Would it be possible to know how can I deal with such issue ? AKA: got some logs somewhere and understand why this feature blocks the installations ?

Hi @Marcos I can't tell now. I already tried to explained you many times (and provide you the log) that I can't disable self-defense. I finally "solve" my issue by uninstall ESET completetly. This thread can now be closed, but I don't considered it "resolved".

Without anwser, I'll have to uninstall ESET, and re-install it manually, which is a shame 😕

Hi @MartinK, please liase with @Marcos. I send him the log over wetransfer, so I hope he has it as his end. When I realised that this failed, I tried to donwload the msi (which is on the bat) manually over my webbrower : this works ! On top of that, I put the manually download files on the %temp%/.eset.XXXXX/ folder and try to execute it manually (together with the config file). The behaviour was almost the same : the .msi didn't really finish the installation, but I ddidn't remember if it's was still caused by the SELF-DEFENSE or not. Note: On both of my policy (advanced & not advanced), the self-defense is activated.

Hi @Marcos I had another endpoint to update so I give it a try : Disabling the SD didn't help. What helps on this case, was changing the policy. I've two sets of policy "advanced" and "not advanced" user. The main difference between the 2 policies are the rules : DETECTION ENGINE => Real-time file system protection => File open. the "Not advanced" group have it enabled, when the "advanced" group have it disabled. Could this be the reason ?! After checking, it seems that the installer failed to download the .msi / shasum checker application.

The policy is enforced, and I can't deal with the override mode, as there is no agent installed anymore. Unless there is another way that this link : https://help.eset.com/era_admin/65/en-US/admin_pol_override.html to do if from the client ?

@Marcos The problem is : Those endpoint are not able to disable self-defense by themselve. It has to be disable/enable via the ESET Protect Server (using the agent). I'm on the situation that : Rules are still applied (not editable) ""from the server"". The endpoint are still getting the Client updates, that's it. Does it means that I will have to uninstall the client, to be able to install the agent v8, before re-installing the client ?

As I failed to OVERWRITE the agent, I manually try to uninstall the current agent, to install the new. But installing the new AND the previous (working one) failed, so I ended with no agent installed at all ... Therefor there is no such file / folder (C:\ProgramData\ESET\RemoteAdministrator\)