Nono

I'm still on the situation that some endpoint aren't communicated with the server. Any help on this @Marcos ?

Hi @Marcos How am I supposed to install this on my endpoint, knowing that there is no communication anymore with the server, but the rules are still "locked" / not editable ? I've generated (a quite huge) dump + log collection. Where/how can I send it to you ?

Correct, and that's quite fair.

I'm on the process to upgrade from ESET Security Endpoint 7 to version 8 (following my upgrade from ESMC to ESET Protect). Depending of the user (for a similar configuration), some agent upgrade failed because either explorer.exe or msiexec.exe process can't access ESET files, here is the HIPS log : C:\Windows\explorer.exe;Get access to file;C:\Program Files\ESET\RemoteAdministrator\Agent\*;blocked;Self-Defense: Protect ESET files;Write to file C:\Windows\explorer.exe;Get access to file;C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Modules\**;blocked;Self-Defense: Protect ESET files;Write to file C:\Windows\System32\msiexec.exe;Get access to file;C:\Program Files\ESET\RemoteAdministrator\Agent\*;blocked;Self-Defense: Protect ESET files;Write to file C:\Windows\System32\msiexec.exe;Get access to file;C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Modules\*;blocked;Self-Defense: Protect ESET files;Write to file on SOME case, uninstall manually the agent and installing the new works, but on some others, it didn't, leaving some user without agent at all (but the rules still applied from the server aka, not editable). Now, two things: 1) How can I install back the agent, knowing that I can't access user rules (without agent / with the client still manage by the server?) 2) How to prevent this self protection, when the installation is legit ?

Thanks @MichalJ Indeed, I found the "configuration" which is more a "task" to me. The Question / suggestion was more : Why the notification send multiple time "configuration failed", when it could easily say : The Client Task "Install EES" failed And with eventually the information "Because XXXXX".

I'm currently migrating my user from ESET Endpoint Security 7 to 8, following my upgrade from ESMC to ESET Protect. I'm receiving quite some emails, always with the same extra frustrating email : Why frustrating ? All the markers are green, and I can't see ANY details regarding this "invalid configuration". As far as I remember (v6 or prior), it was always the case that 'a configuration' failed ... But it's nowhere written where / how etc .. This seems to be a severe lack of information for the administrator trying to figure out (and want to fix) the issue. Would it be possible to write directly on the notification WHAT is failing and for WHICH user/computer ? I assume that if an error is catch, it's quite easy to know the source/cause of it.

I guess not for the cost ... Otherwise, CloudLinux / Lenix seems a good (and better IMO) alternative https://lwn.net/Articles/840221/

For a long LTS, staying on Linux, I would peak Ubuntu LTS which is by far the best choice IMO. I would definitely NOT use Oracle Linux as Oracle isn't known to be a Long Term Free solution (see ZFS, MySQL, Java etc ....). On another way, if you're up to go on the unix world, I would definitely looking at free/openBSD

Okay, the problem was on my side. Indeed, I was missing the private key somehow (was already generated by a colleague).

Hi @MartinK, As stated initially, I have only 3 types of certificate from my provider : - Server Certificate (PEM) in .crt format - Server Certificate (PKCS7) in .p7b - CA Intermediate Certificate (PEM) in .crt So, no private key per say ... That's why I used the following openssl commands with "-nokeys". openssl pkcs12 -export -nokeys -in server_certificate.crt -out keystore.pfx openssl pkcs12 -export -nokeys -in intermediate_certificate.crt -in server_certificate.crt -out keystore.pfx openssl pkcs12 -export -nokeys -certfile server_certificate.crt -out keystore.pfx Please note that the creation ofthe .pfx file is asking me for a password, it's this one I use when I wan't to import it (and used on the tomcat config). Note: I tried without the "-nokeys", but ending up with the following error: unable to load private key 139852820779456:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY

I hope I'm falling on the right thread for this .. Description: (Next) Up-to-date system to host the ESMC Virtual Appliance Detail: The ESMC Virtual Appliance is running under CentOS 7 with some higly outdated software (like tomcat 7 among others). What's the plan for the next virtual appliance version, knowing the recent information about the End Of Life of CentOS in 2021: https://www.cyberciti.biz/linux-news/centos-linux-8-will-end-in-2021-and-shifts-focus-to-centos-stream/ ?

Thanks @nhesetnod32 on my case, the passphrase contains only letters & digits, no special chars. @MartinK could you point me (or ping) someone who may help me ?

EDIT: Ok, I finally finds out the correct "all in one installer" but ended up with: Hi @MartinK, I setup a "test server" in order to do that, but when I use the all-in-one installer, generated from my production server, there is no screen like the one you show me to use a custom certificate. Did I miss something ?

Hi @MartinK, I tried to generate 2 keystores with KeyStore Explorer: 1) Including only my Server Certificate 2) Including my Server Certificate + Intermediate one. On both case, I'm still having the CIPHER Mistmatch error ... Note, I had to remove this entry from server.xml : keyAlias="tomcat" (Do you know anyone who have) any idea how I can check my keystore cipher list in order to "correct" the server.xml following entries ?: sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA"

Hi @MartinK Indeed, I'm trying to replace the one from Tomcat (to access the web console over https). This is our wildcard "real" SSL Certificate. Indeed, for the peer-certificate, we use a auto-signed one generated from the console itself (which will not expired anytime soon). To summarize, I would say that I need to : 1) "Transform" my .crt certificate into either a .pfx or a .jdk / .keystore file 2) Get the correct protocol & cipher match the server.xml configuration in order to "accept" the new certificate.

I'll soon reach the end of validity of my Web Console certificate. I tried to follow the following KB: https://support.eset.com/en/kb6721-set-up-an-httpsssl-connection-for-eset-security-management-center-web-console-7x But I'm always getting a Cipher mismatch "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" on the browser (when I don't get any error on tomcat). My SSL Certificate provider gave me for my wildcard a: - Server Certificate (PEM) in .crt format - Server Certificate (PKCS7) in .p7b - CA Intermediate Certificate (PEM) in .crt (When I currently have a keystore.jdk certificate file). I'm generating the .pfx by doing: openssl pkcs12 -export -nokeys -in intermediate_certificate.crt -in server_certificate.crt -out keystore.pfx I'm generating the .jdk by doing: keytool -import -trustcacerts -alias server -file server_certificate.p7b -keystore keystore.jks In both cases, I've adjusted the right/SELinux types by doing : chown root:tomcat /etc/tomcat/CERTFILE chmod 644 /etc/tomcat/CERTFILE /usr/sbin/semanage fcontext -a -t etc_t /etc/tomcat/CERTFILE /sbin/restorecon -v /etc/tomcat/CERTFILE Here are the different config I tried on /etc/tomcat/server.xml making sure that SELinux was correctly configured Current (working) config, with old certificate : <Connector port="64991" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA" keystoreFile="/etc/tomcat/keystore.jks" keyAlias="tomcat" keystorePass="xxxx" /> Using the same with the new .jks file as well as this config (using a .pfx) give me the mismatch <Connector port="64991" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA" keystoreFile="/etc/tomcat/keystore.pfx" keystoreType="PKCS12" keystorePass="xxxx" /> I also try to update the certificate using the GUI, but ending up with this error as soon as I'm entering the password (WITHOUT validating !) : Here is my server versions: ESET Security Management Center (Server), Version 7.2 (7.2.2236.0) ESET Security Management Center (Web Console), Version 7.2 (7.2.230.0) Copyright (c) 1992-2020 ESET, spol. s r.o. All Rights Reserved. CentOS (64-bit), Version 7.8.2003

What's your suggestion then ? What should I tick on ESET Log Collector to give you the information ?

Here it is ees_logs.zip

Where can I send you the log ?

One of my collegue have a "buggy" Detections section on the logs files section of ESET Endpoint Security (7.2.2055.0) : I don't have the same behavior. On the ESMC, I can see his detection fine, so it seems to be only a "display" issue.

Thanks @MartinK, Could you then confirm it will always have the same pattern (for regex style whitelisting) ? C:\Windows\Temp\ra-run-command-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.bat where the X are following the pattern: group of 8, group of 4, group of 4, group of 4, group of 12 letters/digits ?

Hi there, We're using ESMC (previously ERA from version 6.x or so), recently updated to : ESET Security Management Center (Server), Version 7.1 (7.1.503.0) ESET Security Management Center (Web Console), Version 7.1 (7.1.393.0) and our client to : ESET Management Agent 7.1.717.0 ESET Endpoint Security 7.2.2055.0 It seems that since this update, the task "Run Command" is executing a file C:\Windows\Temp\ra-run-command-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.bat where the hash is not always the same (as per the random "xxx" part of the name I guess). As we have a Application whitelisting software aside ESET to block unkown hash/file, would it be possible to keep the same file as previously (ra-run-command.bat) without the random part in the name ?

Thanks Marcos, So, going back to my original question : What could make it works on one computer and not another ?

Is there an "officially supported" way to do this for HIPS rules ?

I'm not sure I fully understand, but I have a working rule which is like : C:\Users\\AppData\Local\Temp\\soft.exe (aka with 2 \\) and still work like a charm. So, I agree this is maybe not "officially" supported, but why it works on SOME machines, but not the others ? Is there a way to check this ?