Jump to content

Nono

Members
 View Profile  See their activity

  • Posts

    90

  • Joined

 Content Type 

Posts posted by Nono

    Unable to pull database on the new ESET PROTECT 11.0.19.0 virtual appliance

    in ESET PROTECT On-prem (Remote Management)

    Posted · Edited by 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:

    image.png.3b614da8f21746b522311f4c02d36abe.png

     

    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 ?

    ESET Endpoint Security ask for windows Update; none are available (W10 & W11)

    in ESET Endpoint Products

    Posted · Edited by Nono
    hit the "send" too early

    At that time (as I already did), they simply answered : 

    Quote

    The thing is that Endpoint retrieves the list of available updates via a 3rd party API  from Microsoft,this does not always coincide with the available updates via Windows Update. However, ESET cannot do anything about this, but this is a limitation of the interface.

    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...

    VS Code and HIPS issue

    in ESET Endpoint Products

    Posted

    16 hours ago, itman said:

    You can detect any .exe startup in a directory/folder and subordinate folders by creating a HIPS rule to Ask or Deny any application startup in C:\Users\folder and C:\Users\folder\* .

    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

    Quote

    C:\Users\\AppData\Local\*

    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.

    ESET Endpoint Security ask for windows Update; none are available

    in ESET Endpoint Products

    Posted · Edited by Nono
    adding info about driver

    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 : 

    image.thumb.png.eadd1b61976c5256f5d4b97a71374fee.png

    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)

    VS Code and HIPS issue

    in ESET Endpoint Products

    Posted

    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

    Quote

    C:\Users\*<USERNAME>*\folder

    you can use as filter:

    Quote

    C:\Users\\folder

    But you cannot catch any "*.exe" within this same folder.

    (see proposal here : 

     )

    Future changes to ESET Endpoint programs

    in ESET Endpoint Products

    Posted

    On 10/5/2022 at 1:06 PM, Nono said:

    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.

    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;

    Future changes to ESET Endpoint programs

    in ESET Endpoint Products

    Posted

    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.

    Future changes to ESET PROTECT (formerly ESET Security Management Center / ESET Remote Administrator)

    in ESET PROTECT On-prem (Remote Management)

    Posted

    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.

    How to create generic HIPS Rules for application name

    in ESET PROTECT On-prem (Remote Management)

    Posted

    11 minutes ago, Marcos said:

    To my best knowledge you can specify only the exact file name at the end of the path for source application. As for target path, there is currently a bug which allows to enter a valid path only via import from file, otherwise redundant characters would be appended to the path. This will be fixed in the next version of the product.

    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.

     

    How to create generic HIPS Rules for application name

    in ESET PROTECT On-prem (Remote Management)

    Posted

    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)

    Unable to create Business Account

    in ESET Licensing for Business

    Posted

    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)

     

    Windows Installer failed to proceed when "Scan On - File Open" is turned ON

    in ESET Endpoint Products

    Posted

    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 :

    image.png.619f5ec2330404aded27771b5dbde5f3.png

    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 ?

    Updating the ESET Management Agent got HIPS-Locked by "Self-Defense: Protect ESET files"

    in ESET PROTECT On-prem (Remote Management)

    Posted

    On 1/15/2021 at 10:27 AM, Marcos said:

    We need to know if temporarily disabling self-defense make a difference or not. Or is it the scan-on-open option that resolves the issue?

    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".

    Updating the ESET Management Agent got HIPS-Locked by "Self-Defense: Protect ESET files"

    in ESET PROTECT On-prem (Remote Management)

    Posted

    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.

    Updating the ESET Management Agent got HIPS-Locked by "Self-Defense: Protect ESET files"

    in ESET PROTECT On-prem (Remote Management)

    Posted

    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.

    Updating the ESET Management Agent got HIPS-Locked by "Self-Defense: Protect ESET files"

    in ESET PROTECT On-prem (Remote Management)

    Posted

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

    Updating the ESET Management Agent got HIPS-Locked by "Self-Defense: Protect ESET files"

    in ESET PROTECT On-prem (Remote Management)

    Posted

    1 hour ago, Marcos said:

    You can upload it to OneDrive, Dropbox, Wetransfer, Google Drive, etc. and drop me a pm with a download link.

    Please check C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html and trace.log for possible errors.

    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\)

×
×
  • Create New...