Jump to content


ESET Staff
  • Posts

  • Joined

  • Last visited

About Matus

  • Rank

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

2,808 profile views
  1. Hi Zauberonkel, If there are multiple licenses (or sites) in 1 EBA account, results (thus protection) is shared across all computers. If there are multiple licenses in 1 EMA account, results (thus protection) is shared only within managed company. (different companies are not sharing results) Does it make sense? Thank you
  2. Hi Kostadin, If you set policy via Protect, you can't change that locally. Password protected settings are meant in case you're not managed or some settings are not managed... If you set every setting like that (even defaults) from Protect, user can't change that. On Mac, ESET Agent password protection is not present. To limit/protect against uninstallation ensure, that users are not administrators (root access) of a machine. In UNIX world, root can do everything.
  3. Hi, You can create a "remote installation" .pkg and install scripti file where you're able to choose which components should be installed exactly same as in "custom installation". With this I think you can achieve leaner agent as you want. You can install it using ssh, apple tools or any other way...
  4. Hi, OK I really got it now (I think:D)... Yes it works in a way that Disable policy is applied after product works fine... Disable is in a meaning like "Pause". So everything has to work, be integrated and then it can be "Paused" via policy (so you can enable/disable as you wish)... What you want to do is to not even install it & integrate with system. This is possible, and it has to be done via "custom installation": https://help.eset.com/ees_mac/6.10/en-US/?ud_install_custom.html where you can choose which components should not be installed - disabled for eternity... Please note, that you've to uninstall the product and then install it to see those options. Not just execute Installation on top of currently installed product. Now it'll not even try to integrate into a system. However you then can't "enable" them. They're not installed. Is that what you're looking for? If you're looking for some hybrid where disabling = un-integrating from system and enabling is integrating, this is not possible and not even on a roadmap as integrating on big sur is quite complicated process...
  5. @Matus If I understand correctly, the only way to allow system extensions and full disk access is via MDM? It's not possible via ssh/terminal? - Yes. that's how Apple designed it. You need https://support.apple.com/en-us/HT204142 and then use with some MDM (JAMF, simpleMDM...) to control things remotely. As far as I know, it's not possible via ssh/terminal. I got it. It's normal that user sees error messages. It's a warning that protection which SHOULD be enabled, is disabled and is risk for security. If you do not want to show those messages, you've to also disable showing of application statuses: ESET application preferences > alerts and notifications > Protection statuses: or in ESET management console
  6. Accepting of SEXT is possible (learn more or here), but so far we haven't figured out how to approve "Proxy Configuration". We've contacted Apple about 1-2 month ago and we've received information that it's not possible to do remotely... But we're still looking into a way how to do it (so far without any results)... "Of course, we do not enable these two components..." - could you please elaborate a little more? Which components and how did you not enabled them. I'm not sure what is goal you're trying to achieve by not enabling them. Thank you
  7. Hi J-Gray, Thank you for contacting us. Unfortunately this message is most likely caused by a bug causing error message in ESMC even though there is not an actual problem. This will be fixed in upcoming version available in March. To verify that, please check in Endpoint directly (in Endpoint GUI) there there is any error message or it's green. If it's green then it's a mentioned bug. You can also check via terminal command: "systemextensionsctl list" and you should see: * * <somenumber> com.eset.network (6.10.800/6.10.800) ESET Web and Email Protection [activated enabled] You can also verify WEP module by visiting http phishing site, ideally on some testing environment as it's real phishing site (not not enter or click on anything), eg. http://<.>gilbaneco-validate<.>com/ (first you probably get Browser antiphishing message. if you proceed then you get ESET blocking message). If you however see something wrong with WEP in GUI or terminal command, please check if: SEXT was approved: System Preferences > Security & Privacy > General Network Proxy was allowed: https://help.eset.com/ees_mac/6.10/en-US/?ud_install_typical.html Big Sur part, point 3. You can see it running in System Preferences > Network (see attachment)
  8. Hi fascik, there was a problematic update of a module, which was fixed within few hours. However it seems that EVS machine some did not recovered from that. From Installation and Upgrade > Service Deployment if you erase EVS and then re-add, it'll work. I'm not sure right now if there is some less intrusive way of fixing However, thanks to vCenter it'll redeploy within a minutes and will work fine after that.
  9. @khalis711, I'd kindly ask you to elaborate more regarding following problem: "this setup also slows down my internet connection speed during download by huge margins." Can you please, for example, do a speedtest on https://www.speedtest.net/ with Proxy disconnected and with connected and paste here a screenshots? Or any other way how can we understand those huge margins? We do scan http network traffic for malware. As you explicitly allowing us as a Proxy, we can discuss if it's unknowingly or not. This is however a way how every anti malware solution have to work on Big Sur if he wants to scan network traffic for malware. Of course, you can disable Web Access Protection in settings and disable Proxy to feel saver. We can assure you, we do not have other interest than keeping you save by looking for malware. We do not sell personal information or gather private details about our users other than necessary to protect you in a better way.
  10. Hi Guys, we're working on adding support for RHEL 8 and Suse Linux Enterprise Desktop (SLED) 15. What is means is, that we're actively testing our product on those distributions and we're fixing bugs occured on those systems. It might happen that on other distribution the product will work, but it'll not be officially tested and in case of bugs specific for that system, fix is not guaranteed. There are just too many distributions and we're not capable of supporting everything. Thank you for understanding
  11. Hello, Listed below are package dependencies. However, each of those dependencies can have its own dependencies on particular distro. Unfortunately, we don't have such a list of really master dependencies (dependencies of our dependencies). I'm sorry. Also, list of officially supported distributions is not that big. Therefore if you have really diverse environment outside of supported list, you may experience issues which we may not fix. RPM: /bin/sh /etc/cron.d /usr/bin/crontab gcc kernel-devel make perl rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 DEB: Depends: gcc, make, perl, linux-headers-generic | linux-headers-amd64, libelf-dev | libelf-devel | elfutils-libelf-devel, libudev1, cron | cronie | systemd-cron
  12. Hello KPS, hashes of malicious files are shared via LiveGrid Reputation System or other mechanism mentioned above as Marcos wrote. Please don't forget, that if you're the first with a new malware and you would not upload anything to ESET and non of detection layers on the endpoint itself would detect it, you get infected. That's why EDTD works only with when files are sent. Otherwise it's almost the same as LiveGris... Also, EDTD analysis can result in file being suspicious or highly suspicious... for Endpoint, it looks clean so far. For LiveGrid it looks clean as well. However, with EDTD, you can set a sensitivity to block also files with such result.
  13. Hi guys, to question no.1, which is probably solved anyway, here is a guidance: https://help.eset.com/efs/7/en-US/realtime-protection-cannot-start.html?zoom_highlightsub=headers To question about CLI: To receive module updates, product have to be activated (CLI, ESMC, WebGUI). When you initiate an update, you get a message that product is not activated (if it's not activated), other server:~$ sudo /opt/eset/efs/bin/upd -u Product is not activated. Otherwise you get following: server:~$ sudo /opt/eset/efs/bin/upd -u Update is not necessary - the installed modules are current. But yes, this could be solved better via some direct command on lic utility. We'll add that into the product.
  14. OK, please share it:) Also, please write us an ideal flow, how would you like that activation in terminal with offline file would be implemented.
  15. Hi Sangator, please can you tell me, how do you plan to solve updating of Detection engine and other modules? Unfortunately, right now it's not possible to activate using offline file via console. If you'd have some proxy, which would be connected to internet then it would work.
  • Create New...