Mycompany just purchased ESET in January, on my recommendation. I am new to the product but have used Sophos, Symantec, McAfee, and others in previous companies. ESET endpoint security is blocking connections to localhost and 127.0.0.1 for services running on the endpoint. We are pretty much all developers/system engineers so we constantly run docker or other products as we test solutions so there is good reason for doing this.
the only workaround I can figure out is to ensure all services are exposed on all interfaces ('0.0.0.0') instead of loopback/localhost and then make sure the endpoint falls into a profile that allows all local network connections. this essentially makes all services running on an endpoint exposed to the network which is not ideal. We are a consulting company so we frequently go on client networks both physically and via remote access vpn with all different levels of security. I would prefer not to expose these just as a matter of practice.
Context: I am primarily responsible for setting this up and I am stuck on this issue. I have found, interestingly that if you create a vm in VirtualBox and use a bridged adapter ESET does NOT block any of the connections -- seems like a complete loophole. I can access anything exposed from a VM on the endpoint from that computer or any computer on the network even when 'vboxnet1' falls into an untrusted network (vboxnet1 interface isn't used for bridged connections in VirtualBox) AND the wireless also falls into an untrusted network (IE. profile does not have the rule to allow all local network connections), which is the bridged adapter. Yet, I can't make localhost connections. Advice on this issue would be helpful. I have already reached out to support which has not yielded results as of yet so I thought the community might have an idea.
ESET Support Personnel, Devs, and Moderators: we need a way to make rulesets that target more than just IP addresses. We ned to be able to to zone zone (profile) rules and interface interface rules.
I understand the security implications of that, it would allow anything running on loopback adapter to filter through the wireless network adapter w/o any additional firewall intervention. that's basically how a SOCKS proxy works. yes malware could be written to abuse rules like that, thats what IPS/heuristics is use to prevent.
Local connections should be allowed in the home / work firewall profile. Since that doesn't work for you, I'd recommend collecting logs as per -use-eset-logcollector-on-macos-and-send-the-logs-to-eset-technical-support and raising a support ticket with ESET LLC.
Hi @Marcos, thank you for your reply. I realize my post was a bit long, but as mentioned I raised a support ticket a few days ago and so far support has not been able to resolve the issue. Logs say "no usable rule found". I think the next step is live chat/screen sharing with support, but I was hoping someone in the community would have an idea of how to solve this.
We've just taken over our ESET business account and I see a column in the active devices section that is title "Managed" and some devices say Yes and some say No. What does this mean? how is this altered?
Hi Marcos,
I'm pretty sure I've used the ECA live installers for all my endpoints and servers. Some displays "No" for "Managed". I've looked in "Services", the "ESET Management Agent" is there and running for these noers. All OS are up to date.
Maybe you have identified a bug in the implementation. What I would recommend is to perform "reactivation" using the product activation task from the ECA console. After task being performed, can you double-check the machine? What I am thinking of, is that the "managed" is written there in case when the computer has been activated by agent, which is not the case in case when the installer has been generated from the console, but only on case when it was performed via task.
Are any sort of Application Control and/or Application Whitelisting features planned for a future release of ESET Endpoint protection? I ask because I currently use Microsoft's built in Software Restriction Policies (SRP) along with ESET Endpoint, but Microsoft has indicated that SRP is no longer being developed and support for it may be pulled. Of course they recommend using Applocker as the successor to SRP, but that's only available in Windows 10 Enterprise, and we have Windows 10 Pro. Licensing Enterprise is somewhat more expensive than I thought, so I'm looking at third party options. I noticed some other endpoint business products have application control included, such as Kaspersky and F-Secure. I really like the configuration options of ESET HIPS, but it cannot quite replicate the whitelisting controls provided by SRP or Applocker. Just curious if any consideration has been given to including similar capabilities in ESET.
There are a few other third party options out there for strictly whitelisting, but few have centrally managed web consoles available (Excubits Bouncer, NoVirusThanks Smart Object Blocker, etc.). About the only centrally managed options are Appguard or Airlock Digital, but once you factor in the cost for those, on top of ESET, Kaspersky or F-Secure might make more sense. I think most of these products work largely the same and use the same Windows APIs. Long story short, it would be great if ESET had application control/whitelisting features in the pipeline.
As far as I know, we don't plan to have Application control any time soon (meaning in the next few moths). Currently it's only possible to create HIPS rules to block execution of specific executables based on the path.
As for the code ECP.20003, it means that communication with the host failed. Please make sure that communication with activation servers is allowed as per -ports-and-addresses-required-to-use-your-eset-product-with-a-third-party-firewall. You will need to allow also communication with other ESET servers to take advantage of some other protection features.
As for the problem contact ESET support in Australia, you can try contacting them via phone ( ). If a support ticket was created, you would have received a confirmation email with a ticket ID. Please check your junk and spam folders, just in case.
If the machines can connect to the Internet via a proxy, you should not use an offline file for activation. Since the clients cannot obviously communicate with activation servers, it's not a problem now but you won't be able to take advantage of other protection features such as LiveGrid or streamed updates. If you fixed the problem with the proxy at a later time and the clients would start to communicate with ESET's servers, you'd get notifications in EBA and lose the ability to create offline license files.
Does all of the update communication between the client and the ERA go via 2222. If not which port does it use. Looking at this diagram _install/70/en-US/ports_used.html, I assume all updates would go via port 2222 ?
The question is how you configured the clients to update. If from a local mirror, is a correct path to the mirror configured in the update setup? If configured to update from ESET's servers, communication with the update servers listed in the KB article must be allowed and the proxy server must be configured correctly. In case of update from a mirror, there are two possibilities: update via http (mirrored files must be made available through an http server) or update from a share. This communication has nothing to do with the ESMC server listening on port 2222.
LiveGrid is a crucial feature which affects detection, malware cleaning and scan performance. We recommend keeping LiveGrid enabled and working. Also streamed updates delivering up to date detections as soon as new malware emerges are possible only when updating from ESET's update servers.
The ESMC server does not download updates. We recommend using a proxy server in larger networks to cache update files. Alternatively it's possible to create a mirror with the mirror tool ( _install/70/en-US/mirror_tool_windows.html) or use an ESET security product to create the mirror.
MirrorTool.exe --mirrorType regular ^
--repositoryServer AUTOSELECT ^
--intermediateRepositoryDirectory E:\Temp\IntermediaryFiles ^
--outputRepositoryDirectory E:\Temp\FinalRepository
--languageFilterForRepository en_US ^
--productFilterForRepository Antivirus Security ^
--offlineLicenseFilename c:\temp\Esetendpointsecurityforwindows.lf
ESET, s.r.o., is a software company specializing in cybersecurity. ESET's security products are made in Europe[3] and provide security software in over 200 countries and territories worldwide. Its software is localized into more than 30 languages.
The company was founded in 1992 in Bratislava, Slovakia. However, its history dates back to 1987, when two of the company's founders, Miroslav Trnka and Peter Paško, developed their first antivirus program called NOD. This sparked an idea between friends to help protect PC users and soon grew into an antivirus software company. At present, ESET is recognized as Europe's biggest privately held cybersecurity company.[4][5][6]
The product NOD was launched in Czechoslovakia when the country was part of the Soviet Union's sphere of influence. Under the communist regime, private entrepreneurship was banned. It wasn't until 1992 when Miroslav Trnka and Peter Paško, together with Rudolf Hrub, established ESET as a privately owned limited liability company in the former Czechoslovakia. In parallel with NOD, the company also started developing Perspekt.[7] They adopted the name ESET, from the Czech name of Isis, the Egyptian goddess of health, marriage and love, as the company name.
3a8082e126