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 The benefits are that you don't have to specify another smtp server to relay to, and that you can accept and reject mail real-time based on the ESET Mail Security outcome (e.g. respond with a 500 code when malware is found). I've found this to work quite stable with Postfix, even though it's officialy a sendmail filter. Right now I'm just using it with socat as a system service: [Unit] Description=Socat tcp to eset socket After=esets.service [Service] ExecStart=/usr/bin/socat -d -d TCP4-LISTEN:3537,range=127.0.0.1/8,fork UNIX-CONNECT:/var/run/esets_smfi.sock Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

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 agent and base the GUID on the system hostname. the result of this is that you won't have to use a "Reset" task. There are some downsides though: You will have to create an automatic task to activate the endpoint upon first connection. This is not a big problem but might potentially cause high traffic towards the ESET activation servers. Tasks that use the "ASAP Trigger" will re-run every time an image is refreshed, because the new agent thinks the task has not been executed yet. Other than that, it seems to work just fine without the need for removing double entries. But please, only use at your own risk and test first :).

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