InfosecAtom

We recently upgraded to ESET PROTECT Server 8.1 on Linux and we are noticing the ERAServer process slowly grows to consume all available file descriptors, hitting the open file limit for the process. I believe that is what then leads to the trace.log showing these messages: Taking a look at the file descriptors they all appear to be held open sockets from various endpoints. Bumping the client connect interval from 5 minutes to 15 minutes temporarily alleviated the issue, but it then reappeared. We did not seem to have this same problem on EP 8.0. We have about 800 active clients at any given moment, running on a host with 4 2.2GHz Xeon cores and 8 GB memory, so I don't feel it should be overloading the server. I searched to see if there was any guidance that recommended raising file descriptor limits per file, but didn't seem to see anything. Any ideas how we might better troubleshoot what is leading to ERAServer saturating all the available file descriptors?

That is precisely what we seek to do. When an agent gets installed, but with an improper config, then we want to be able to detect that the agent is not healthy. Short of it's absence in ESMC, we don't have a way to identify that.

I am aware of the diagnostic files that reside in C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs but I am curious whether EMA has any command line functionality that dumps status data which is similar to that found in the status.html file of the above directory? My reason for asking is devising an easy way to assess health of the agents in an automated manner on endpoints (i.e. pick-out non communicative endpoints) using an endpoint configuration management solution. Would scraping the status HTML be the only way? Or is there indeed a command line method of interacting with EMA direct?

It was a Windows 10 endpoint, so it would not be vulnerable. It was flagging only on the attempt. I figured out what the issue was, I falsely believed that program name was supposed to be a IDS exception rule name. Removing all input from the program name field resolved my issue.

I am getting these alerts from our vulnerability scanner in ESMC, despite having created an IDS exception policy to not alert or log on scans from the vulnerability scanner. Am I supposed to be creating the exception elsewhere to avoid all endpoints filling my detections log with all these events?