Jump to content
DJD

ESET Endpoint Antivirus is not configurable

Recommended Posts

I'm one of those who have arrived on ESET Endpoint Antivirus (Endpoint Security had too much stuff in it) from Microsoft SCEP: https://support.eset.com/kb7026/

I've previously configured SCEP through the command line, however ESET doesn't appear to behave correctly.

Using the "/Applications/ESET\ Endpoint\ Antivirus.app/Contents/MacOS/esets_set" command-line initially reports that the configuration file: /Library/Application Support/ESET/esets/etc/esets.cfg is non-existent.

Creating an empty version of it then allows the esets_set command to work, similar to SCEP for Mac, and values are added into it per the command-line.

However, the product doesn't seem to actually use any of this.

All the configuration changes are being made into: /Library/Application\ Support/ESET/esets/cache/data/settings.json

Which is a completely different beast, and a nightmare to read and figure out. The entire esets_set/esets.cfg is just plain ignored.

All I want to do is figure out how to configure the web and email protection, as the web filter is messing up our VPN software. However, none of the documentation covers anything but the GUI activities, and mostly this is on Windows. The Mac product does not seem to be very well documented at all, and where it is, it's demonstrably wrong.

How do I actually configure the product from the command-line?

Additionally, I note that there are new versions of the client software, as of November 13. Again, none of the information provided helps. We have just started out with ESET, using 6.7.500.0, provided from the download links provided. We have neither ESET Security Management Center nor ESET Remote Administrator. So, how do we get access to the product updates?

Share this post


Link to post
Share on other sites

Another thing I've noticed is that if the ESET daemon needs to be restarted, it's pretty much impossible to do so without the user being very visible alerted.

Even if the esets_set command worked, historically, based on my experience with Microsoft SCEP, the daemon would need to be restarted. This is typically done by launchctl stop and start, or even a "kill HUP".

However, even ESET's own restartDaemon.sh script buried in the app almost immediately triggers an alert that most users would find alarming. Even though they don't need to do anything - the daemon has restarted, but the GUI just hasn't figured it out. Killing the GUI process beforehand results less alarm to the user, but involves a full relaunch, including splash screen.

670873907_ScreenShot2018-11-27at6_28_24pm.png.f784fb38ab5c6910ee9dfe5a9eae80ee.png

Share this post


Link to post
Share on other sites

Hello DJD,

I am sorry to hear about the issues you have experienced migrating from Microsoft SCEP for Mac to ESET Endpoint Antivirus/ESET Endpoint Security for Mac. Will do my best to assist you in any way I can.

Just to be sure that all the topics are covered, it seems that the issues can be split into the following areas:

 

1) Configuration/Remote configuration of the client without using ERA/ESMC

First of all, I would like to mention that with the license for ESET Endpoint Antivirus/ESET Endpoint Security for Mac, you are eligible to use ESET Remote Administrator/ESET Security Management Center without any additional charge. ERA/ESMC can be deployed as a virtual appliance on Linux, so it would not require a Windows server to operate.

If I understand it correctly, you would rather not use an additional remote management console (other than SCCM) and would prefer to use the command line interface to configure the clients.

2) Web and Email protection conflict with VPN software

Could you please share some more details about the clash with the VPN software? Which VPN app do you use? I will check with our developers and/or technical support to see what can be done about it, both at the moment and for a future version.

3) Documentation

I agree that most of our current documentation seems to be focused around GUI actions and remote configuration using ERA/ESMC, as the majority of our customers use those. I will discuss with the documentation/KB team to see what we have available on the KB, and ask them to prepare a KB article specifically for the command line configuration (if we do not have one already).

4) New versions of products

Version 6.7.500.0 is the most recent version of ESET Endpoint Antivirus/ESET Endpoint Security for Mac available. We will be updating the KB article for migration from SCEP for Mac with new installers with each future version. I presume you used a .dmg installer for ESET Endpoint Antivirus that you downloaded from www.eset.com? At the moment, it is not possible to check for newer versions directly from the GUI, since most of our customers (whether enterprise or education) prefer to maintain control of the product versions installed on their clients.

5) ESET daemon restart without alarming the end user

Could you please share the use case for the daemon restart?

From what I understand, there is a way to prevent the GUI from launching if you would prefer that, which should also take care of the splash screen being displayed.

 

If you agree, I will contact you via private message later for some additional details regarding the issues.

Thank you.

Best regards, Alexander

Share this post


Link to post
Share on other sites

Hi Alexander -

1. I was not aware of this ERA/ESMC entitlement. The migration guide doesn't mention anything about it: https://support.eset.com/kb7026/ It also doesn't mention how to configure the address of your ERA/ESMC server. I don't object to setting up a server to manage ESET, but its not what I expected, as SCEP didn't require it, and it means justifying adding another server into our data centre. If I can get away with configuring from the command-line, it would actually be easier for me, as I can do it all myself without a server administrator.

2. We use Cisco AnyConnect. Upon attempting to connect to our VPN, the following message appears:

1415189222_VPNconnection.png.bf7b26d2cb5a82d7c1e8da1dfb862aba.png

Turning off the web and mail filter, which we've never had before, restores the ability to connect to the VPN. At a minimum, I need to be able to set our domain as an exclusion.

3. If I know which tool is the right one, I can usually figure things out on my own. esets_set doesn't seem to be it, unless I'm missing a step that makes it actually pay attention to the esets_set-supplied configuration. Right now, though, I just don't know where to start and it's not making much sense at present.

4. Yes, downloaded from here: https://support.eset.com/kb3614/ If that's the latest, that's fine; I realise now the "ESET Endpoint Security and ESET Endpoint Antivirus versions 7.0.2091, 6.6.2089 and 6.5.2132.2 have been released" may have been about Windows, not Mac.

5. As I mentioned, historically with Microsoft SCEP, scep_daemon had to be restarted to pick up the changes to the .cfg file. Trying to figure out how the ESET product works and get it to pay attention to the esets.cfg file, I was restarting esets_daemon and observing this behaviour. If the command line management tools interact with it more directly and it picks up change on the fly without a restart of the daemon, this may not be a big deal.

Edited by DJD

Share this post


Link to post
Share on other sites

Hi DJD,

I'm in the same boat at you - migrating from Microsoft SCEP - it's disappointing to see a lack of documentation and support around deploying and managing this on macOS but as always, the community has got your back! After some conversations with other helpful members of the MacAdmins Slack in #endpoint_security we've worked out how to get ESET AntiVirus configured in via the command line - both the system level settings and user-specific GUI stuff.

This is all still fresh and it's the weekend but I will write this up fully soon, like I did for SCEP at my blog https://soundmacguy.wordpress.com - here's the short of it:

For system level settings:

Set up ESET how you need it in the GUI - scan options, disable the email/web modules etc. Then export your settings as a file via the menu icon --> Setup --> Import/export settings. Then you can use the command line esets_daemon to import them (you need to specify the full path to esets_daemon of course - I've omitted it for simplicity here):

esets_daemon --import-settings /path/to/settings/file

You should kill the GUI and daemon as part of this process then re-load them to avoid user nags, e.g:

killall esets_gui
launchctl unload /Library/LaunchDaemons/com.eset.esets_daemon.plist
esets_daemon --import-settings /path/to/settings/file
launchctl load /Library/LaunchDaemons/com.eset.esets_daemon.plist

Then restart or log out/in to bring the GUI back - or you can add the necessary commands to do that in a script, but this might vary depending on your management tools - I would work out the username of the logged in user then run an open command on the ESET application in their context, myself - a bit beyond the scope of this post.

What's slightly annoying about this is you can't change settings in a granular, programatic way - it's just the whole file's worth or nothing. Maybe ESET support can offer some guidance?

For user level (GUI) settings:

You'll notice that the settings file doesn't account for GUI preferences that are user specific (everything under Preferences --> User --> Interface/Alerts and Notifications). If you've turned off the web and email modules, you'll see nags about that too which are suppressed with those user level preferences - definitely something we don't want!

Anyway, those are stored in the file ~/.esets/gui.cfg and you can modify those with the old esets_set command, much in the same way as you did with scep_set. You can apply individual settings to it with esets_set, or just capture that file and re-import it, e.g:

esets_set --apply=/path/to/exported/gui.cfg --cfg=/Users/username/.esets/gui.cfg

This has to be run in the current logged in user's context (i.e. via a Launch Agent, or with something like Outset, or appending sudo -u username to the commands if running at root level with Jamf, it depends on your environment) and the --cfg flag needs to have the full path to the user's home directory - ~ didn't work in my testing. That's easy enough via a script - e.g

#!/bin/bash

loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}' )

killall esets_gui

"/Applications/ESET Endpoint Antivirus.app/Contents/MacOS/esets_set" --apply=/path/to/exported/gui.cfg --cfg=/Users/"$loggedInUser"/.esets/gui.cfg

open "/Applications/ESET Endpoint Antivirus.app"

I haven't tested the above example but it should work.

This is basically identical to how you'd do it in SCEP and I have a detailed post about that here: https://soundmacguy.wordpress.com/2017/11/19/managing-microsoft-system-center-endpoint-protection-scep-part-3/

For proper management of the those user GUI settings I'm looking to replace ESET's Launch Agent with my own script that will set the preferences then open the GUI when users log in - that'll make sure they revert back at each login in case users change things. It'll also avoid the need to kill the process first (except during installation/deployment in the first place - that's another piece of the puzzle I'm working on but it should be solvable).

ESET - it would be really great to have some administrator-level documentation on the esets_set and esets_daemon commands please (hint - the ESET Linux documentation and manpages are good here - maybe we could have manpages for the macOS version too?) - we've basically had to dig in and work all this out for ourselves. 🙂

An interesting thing I noticed was that if you install ESET on top of SCEP, it'll handle the uninstall of SCEP as well as pick up its settings - both GUI (for the logged in user if present, taking root ownership of ~/.esets - not good!) and system level stuff.

Last nugget of goodness - you can grab loads of useful information with esets_daemon --status

I'm working on a few Jamf Extension Attributes to pull things like the definitions versions/dates, real-time protection status etc from it (I did this with SCEP but tended to scrape files instead - I like this better but didn't discover scep_daemon until afterwards and never got around to it...) - it's quite straightforward. I'm sure other management tools could leverage it as well.

Hope this helps!

Edited by neilmartin83

Share this post


Link to post
Share on other sites

Hi DJD.

I was having the same issue so what I did was install ESET and configure via the gui. Made a copy of the settings.json file then created a separate package installer that unloads the ESET LaunchDaemon, deletes the default settings.json file, copies in the pre-configured son file then starts the LaunchDaemon. Seems to work ok so far.

Now if only I could get ESET to observe the privacy preference for full disk access.

Cheers,

Shannon

Share this post


Link to post
Share on other sites
On 11/28/2018 at 6:15 AM, DJD said:

Hi Alexander -

1. I was not aware of this ERA/ESMC entitlement. The migration guide doesn't mention anything about it: https://support.eset.com/kb7026/ It also doesn't mention how to configure the address of your ERA/ESMC server. I don't object to setting up a server to manage ESET, but its not what I expected, as SCEP didn't require it, and it means justifying adding another server into our data centre. If I can get away with configuring from the command-line, it would actually be easier for me, as I can do it all myself without a server administrator.

2. We use Cisco AnyConnect. Upon attempting to connect to our VPN, the following message appears:

1415189222_VPNconnection.png.bf7b26d2cb5a82d7c1e8da1dfb862aba.png

Turning off the web and mail filter, which we've never had before, restores the ability to connect to the VPN. At a minimum, I need to be able to set our domain as an exclusion.

3. If I know which tool is the right one, I can usually figure things out on my own. esets_set doesn't seem to be it, unless I'm missing a step that makes it actually pay attention to the esets_set-supplied configuration. Right now, though, I just don't know where to start and it's not making much sense at present.

4. Yes, downloaded from here: https://support.eset.com/kb3614/ If that's the latest, that's fine; I realise now the "ESET Endpoint Security and ESET Endpoint Antivirus versions 7.0.2091, 6.6.2089 and 6.5.2132.2 have been released" may have been about Windows, not Mac.

5. As I mentioned, historically with Microsoft SCEP, scep_daemon had to be restarted to pick up the changes to the .cfg file. Trying to figure out how the ESET product works and get it to pay attention to the esets.cfg file, I was restarting esets_daemon and observing this behaviour. If the command line management tools interact with it more directly and it picks up change on the fly without a restart of the daemon, this may not be a big deal.

Hi DJD,

1. My apologies if this was not communicated clearly in the landing page where you registered for the ESET Endpoint Security for Mac license. I have already asked the responsible team to include this information in the KB article, it should be updated in the next few days.

2. At this moment, I do not have an update on the VPN issue, but will do my best to chase it and post a follow-up later today.

3. I agree with neilmartin83 and Shannon that the best way to approach this would be to create a configuration locally using the GUI and export the settings. This can be done either using the GUI (Import and Export Settings), or using command line (sudo /Applications/.esets/Contents/MacOS/esets_daemon --export-settings [file_name]).

If you prefer to only change a specific setting, the way that could be done is by exporting settings before you change the specific one, change the setting in the GUI, export the settings with the change and compare the two exported settings files to determine the difference using a comparison tool. Then you can modify the second exported settings file and only leave the tag with the required setting and appropriate parent tags that you would like to change in the configuration on the clients.

It is not possible to directly import an XML into the product, so for the import, it would be necessary to create a gzip-ed tar file from application settings (XML) and user local settings (empty eset.gui file). Once you have that, you can push the configuration to Macs on your network, using e.g. Apple Remote Desktop, or command line (/Applications/.esets/Contents/MacOS/esets_daemon --import-settings [file_name]).

4. Yes, the version in the KB article is the latest one. There is an email list and an RSS feed with information about new releases, but not a specific one for the Mac product. Similar information is also available in ESMC, which can also indicate that there is a newer version of the client software available from ESET.

5. Restarting daemon should not be necessary for the configuration to be applied. If it is the case, please let us know. Thank you.

Share this post


Link to post
Share on other sites
On 12/1/2018 at 9:15 AM, neilmartin83 said:

An interesting thing I noticed was that if you install ESET on top of SCEP, it'll handle the uninstall of SCEP as well as pick up its settings - both GUI (for the logged in user if present, taking root ownership of ~/.esets - not good!) and system level stuff.

Yes, I believe this has been the case since version 6.6.

Share this post


Link to post
Share on other sites
On 12/2/2018 at 10:42 PM, Shannon Pasto said:

Now if only I could get ESET to observe the privacy preference for full disk access.

Yes, we are aware of this issue and are looking into it.

Share this post


Link to post
Share on other sites
5 hours ago, AlexW said:

Yes, I believe this has been the case since version 6.6.

Well, it seems to handle the uninstall properly, but doesn't seem to pick up any of the customized SCEP settings.    So you still need to craft a comparable set of preferences and export/import that for ESET to be useful

Share this post


Link to post
Share on other sites

Agreed. Installing ESET did not pick up the existing SCEP configuration. Treat it as a new install and configure as required.

 

System level settings (eg firewall etc) are stored in "/Library/Application Support/ESET/esets/cache//Library/Application\ Support/ESET/esets/cache/settings.json"

User settings (eg notifications etc) are stored in "~/.esets/gui.cfg"

 

It's easy enough to transfer these to new installs...

% sudo launchctl unload /Library/LaunchDaemons/com.eset.esets_daemon.plist

copy the relevant files into place and set correct permissions if needed

% sudo launchctl load /Library/LaunchDaemons/com.eset.esets_daemon.plist

 

Shannon

Edited by Shannon Pasto

Share this post


Link to post
Share on other sites

Awesome, thanks very much. I have been on leave for a bit so haven't looked at it in a while, but great to see what others have figured out.

Going to go through this right now, as the deadline is rapidly approaching.

Share this post


Link to post
Share on other sites

Things were going so well then I spoke too soon... I've started seeing serious activation issues since Friday (where there were none before) - wondering if anyone else has?

Clients are appearing to activate properly via the installer package with token applied, using the command line method via esets_daemon or via entering the code/logging into our EBA account in the GUI. An activation record shows up for the client in EBA, but the client is reporting back that it's unactivated.

I'm basically seeing this on every client I'm trying to activate now (over 20) including a VM I've been testing with at home, so I'm pretty sure it's not network related (i.e. proxy/firewall - we don't use a proxy at work anyhow).

I've tried deactivating a problem client in EBA then re-activating it and that hasn't helped. The client re-appears in EBA though as expected, and the GUI/esets_daemon reports that the initial activation is actually okay, but doesn't actually activate.

This is after successfully installing/activating it earlier in the week on approx 40 Macs that are showing no issues.

I'm going to give support a shout soon but was wondering if anyone here has also seen this? Perhaps it's an issue with our specific EBA account?

We've got nearly 500 Macs and I'm still at the "evaluation" stage for ESET - I need to pass on my recommendations as to whether we'll adopt it (following the discontinuation of SCEP) or go for something else, so this isn't favouring too well right now... :(

Share this post


Link to post
Share on other sites

@neilmartin83 Would it be possible to share a screenshot of the client in this broken state? I assume, that the behavior is the following:

  1. When you activate locally, you actually end up seeing an "success" screen, that product activated. This is also reflected on EBA, where a "seat" for such client is created (record showing a computer name)
  2. However, the client starts to report as not being activate after a while, locally on the Endpoint.

Can you please send us the following (you can do it in the private message):

  1. Your public license ID of ESET license (XXX-XXX-XXX)
  2. Seatname of any (or all) affected machines
  3. Screenshot from the local UI of at least one of those "broken" clients from "protection status", "update" and  "help&support" screens.

I would pass it to our backend infrastructure team to check out, as it looks to me like a problem with license file delivery. Activation process in case of ESET works in a way, that the client first reaches the activation server, seat is created, and later in a response a digitally signed license file is delivered, which includes the information needed tor updating the detection engine or other modules on the client. This looks to me (although it´s only a guess) that something happened with the license file, and it was not delivered / parsed correctly.

Share this post


Link to post
Share on other sites

Hi @MichalJ,

Thank you very much for your reply - I've sent you a private message with those details you requested. Please let me know if you need any further information.

Kind regards,

Neil.

Share this post


Link to post
Share on other sites

Neil can you share what you had to change in your process for mac activation. I am currently struggling with this also. I followed your process in the blog to the letter. My clients do everything but update/activate automatically. Any assistance you could provide would be great. BTW your blogs for SCEP & ESET are AWESOME!!

Share this post


Link to post
Share on other sites

Hi @alvinbridges,

Thank you!

Activation started working again - it was an issue at ESET's end. However, I did notice occasionally the installer with token applied using the add_token tool wouldn't activate for some reason, so built a way to remediate using Jamf.

If you're using Jamf, this might be useful:

I have the following Extension Attribute that returns the activation state: https://github.com/neilmartin83/Jamf-Pro-Extension-Attributes/blob/master/ESET Endpoint Antivirus - Activation Status.xml

I have a Smart Group called "WARNING - ESET Endpoint Antivirus - Not Activated" with the criteria "ESET Endpoint Antivirus - Activation Status" "is" "Unactivated"

I have a Policy scoped to the above Smart Group, set to run at Recurring check-in, Ongoing frequency.

It runs a script that does the following:

#!/bin/bash

"/Applications/ESET Endpoint Antivirus.app/Contents/MacOS/esets_daemon" --wait-respond --activate key=$4

sleep 60

exit 0

$4 is a parameter for the serial number which I specify in the policy Script payload, rather than hard-coding it in the script itself (although you could put it in the script if you like - I just don't like hard-coding this sensitive/confidential things in scripts).

After it runs the script, it performs an Inventory Update.

Hope this helps.

 

Edited by neilmartin83

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×