dmenl

Hello, I experienced the same issue right after the update, but it has not occured since restarting all esets services.

Hmm, nevermind. The same thing happened to me just now when using esets_smfi. It really seems to be esets_daemon freezing for some reason.

Well, what I've found out during my experiments is that you can use the "esets_smfi" component with Postfix. Now, this is officialy a sendmail filter, but Postfix supports this filter with the "smtpd_milters" directive (hxxp://www.postfix.org/MILTER_README.html). The only downside is, the socket is created with root-only permissions so postfix cannot access it directly. A workaround for this is using socat: /usr/bin/socat -d -d TCP4-LISTEN:3537,range=127.0.0.1/8,fork UNIX-CONNECT:/var/run/esets_smfi.sock And using this smtpd_milters option: smtpd_milters = inet:127.0.0.1:3537

With ERA 6, everything is stored in the database, so you can simply backup and restore the database to achieve the same goal.

Could you try (temporarily) stopping the "eraagent" service and see if that makes a difference? In my testlab it almost always freezes the esets_daemon when changing a lot of settings through ERA.

Just out of curiousity, are you guys using the ERA Agent on those machines as well?

Hi Guys, The agent installer actually has a "hidden" flag to specify a custom GUID during installation (P_CMD_PRODUCT_GUID). Whenever we deal with these situations we use that flag to specify the MD5 hash of the computer name as GUID, and re-install the ERA agent every time the image is "refreshed". For this we use the following PowerShell script: https://transfer.eset.nl/s/18j0qGcY0i9ZetQ For the base image, we make sure to pre-install the endpoint security software, but not activate it. Then, we use a GPO to run the above mentioned script upon boot. This will install the agen

How are you testing? For me that sample is detected as: Python/Filecoder.AM trojan