Future changes to ESET Endpoint programs

[ShaneDT 13]

^^^ 100% this. This is just silly. Why suddenly are we alerting users that their product will be end of life in 12 months!? 

[Ryan Dey 6]

On 12/1/2022 at 11:25 AM, Ryan Dey said:

In a managed environment, like we're using with ESET Protect, we absolutely need the ability to suppress end of life warnings.

ESET updated a module last week and these EOL warnings are no longer displayed on managed clients (I assume the red alerts are still shown?).  This portion of my feature request has been implemented, though the management console warnings have not yet been implemented.  I'm guessing those would be in a future release of the server software.

[labynko 5]

Description: Disable automatic installation blocking of ESET Endpoint Security on server versions of Windows OS.
Detail: Current versions of ESET Endpoint Security cannot be installed automatically on server versions of Windows.
In this regard, the wish is that such a restriction be removed completely or that a special command line parameter be added that would allow to bypass this restriction.

[labynko 5]

Description: adding automatic update of ESET Endpoint Security via PCU to new versions installed on server versions of Windows OS
Detail: current versions of ESET Endpoint Security installed on Windows Server OS cannot be upgraded to new versions via PCU, which is a strange limitation. It would be nice if there were no such restriction.

[Marcos 5,069]

7 hours ago, labynko said:

Description: Disable automatic installation blocking of ESET Endpoint Security on server versions of Windows OS.
Detail: Current versions of ESET Endpoint Security cannot be installed automatically on server versions of Windows.
In this regard, the wish is that such a restriction be removed completely or that a special command line parameter be added that would allow to bypass this restriction.

Endpoint is not intended for installation on servers and ESET Server Security should be installed instead. Installation of Endpoint on servers is neither tested nor supported and would be against EULA if not used with a license that allows installation on servers.

[Marcos 5,069]

7 hours ago, labynko said:

Description: adding automatic update of ESET Endpoint Security via PCU to new versions installed on server versions of Windows OS
Detail: current versions of ESET Endpoint Security installed on Windows Server OS cannot be upgraded to new versions via PCU, which is a strange limitation. It would be nice if there were no such restriction.

ESET Server Security supports automatic program updates.

[labynko 5]

Description: add support for Windows server operating systems to ESET Endpoint Security

Detail: ESET Server Security does not have a firewall, but ESET Endpoint Security does, but ESET Endpoint Security does not have support for Windows server operating systems.

[labynko 5]

Description: "Logging severity" column missing in ESET Endpoint Security firewall rules table

Detail: It is very common to debug firewall rules, and setting the "Logging severity" option in one or more of the rules with a non-default value makes it difficult to find the rules where it is configured. Of course, you can first go to the firewall log and find the names of all the rules for which logging is configured there, but this is extremely inconvenient. In this regard, it would be very good if ESET Endpoint Security had a "Logging severity" column in the firewall rules table.

[labynko 5]

Description: in ESET Endpoint Security, in the firewall rule settings, when selecting an application, add the ability to use a template

Detail: many network applications change their path when updated, such as WhatsApp, Opera's update checker, and many others.

C:\Users\User\AppData\Local\Programs\Opera\95.0.4635.46\opera_autoupdate.exe C:\Users\User\AppData\Local\Programs\Opera\94.0.4606.65\opera_autoupdate.exe

The template could look, for example, as follows:

C:\Users\User\AppData\Local\Programs\Opera\<n>.<n>.<n>.<n>\opera_autoupdate.exe

[Nono 3]

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;

[Rodd Kennedy 0]

Hello,

In Endpoint Security, under Advanced Settings -> User Interface -> Startup Type, there is an option for Silent.

Please add this option to ESET Server. We run Windows Servers as Terminal Servers with RDP access. I know that you can install without the UI, but I prefer the UI.

As Silent Mode exists for Endpoint, it should be simple to port over to Server. Thank you.

[Marcos 5,069]

10 minutes ago, Rodd Kennedy said:

In Endpoint Security, under Advanced Settings -> User Interface -> Startup Type, there is an option for Silent.

Please add this option to ESET Server. We run Windows Servers as Terminal Servers with RDP access. I know that you can install without the UI, but I prefer the UI.

As Silent Mode exists for Endpoint, it should be simple to port over to Server. Thank you.

Is there any problem with using "Terminal" mode in ESET Server Security?

[Nate Simpson 2]

It would be useful to be able to see the latest detection rather than only the 1st detection to be able to confirm if an issue is now resolved in some views

[Marcos 5,069]

8 hours ago, Nate Simpson said:

It would be useful to be able to see the latest detection rather than only the 1st detection to be able to confirm if an issue is now resolved in some views

Unfortunately it is not clear what you mean. Please create a new topic and post there also some screenshots for clarification.

[Sec-C 5]

Description: use DKMS (Dynamic Kernel Module Support) for Eset Kernel Modules on Linux

Detail: The forum is full of problem reports due to signing of eset kernel modules on Linux with activated secure boot. The standard solution for the problem is the DKMS framework, which takes care of automatic module signing on kernel update or eset update. Please drop the custom made signing script in favor of a DKMS based solution. It makes the whole update and signing process soooo much more reliable and predictable - which is why NVIDIA, VMware and most other Vendors use it to ship their kernel modules.
We even had to hire a software developer, just to automate the eset signing for our fleet of Linux devices 🤦‍♂️. But it is still unreliable and we have to work around all the race conditions that would not even exist with DKMS.

[Viatcheclav Bukas 3]

Please create a forum topic about the changes in version 11.0.2044. It has been released for a long time, and the download section on the official ESET website has this information, but the forum still can't find it...

[Peter Randziak 1,130]

On 3/28/2024 at 11:31 AM, Sec-C said:

Description: use DKMS (Dynamic Kernel Module Support) for Eset Kernel Modules on Linux

Detail: The forum is full of problem reports due to signing of eset kernel modules on Linux with activated secure boot. The standard solution for the problem is the DKMS framework, which takes care of automatic module signing on kernel update or eset update. Please drop the custom made signing script in favor of a DKMS based solution. It makes the whole update and signing process soooo much more reliable and predictable - which is why NVIDIA, VMware and most other Vendors use it to ship their kernel modules.
We even had to hire a software developer, just to automate the eset signing for our fleet of Linux devices 🤦‍♂️. But it is still unreliable and we have to work around all the race conditions that would not even exist with DKMS.

Hello @Sec-C

thank you for sharing this, the team responsible has a task tracked to analyze possibility of using it.

Peter 
Note for us: P_EESU-1800

[Peter Randziak 1,130]

On 4/12/2024 at 11:46 AM, Peter Randziak said:

Hello @Sec-C

thank you for sharing this, the team responsible has a task tracked to analyze possibility of using it.

Peter 
Note for us: P_EESU-1800

Sadly, on the RHEL based systems the DKMS is a part of third-party EPEL repository only. So we cannot add DKMS as a dependency to our software (i.e. base our software/product on dkms technology) as that would require adding unofficial third-party repositories to all our customers...