bvj

Tomcat uses log4j. You obviously don't know what you're talking about.

Is this an apple or an orange? And do you know which ESET software uses tomcat? ./usr/share/java/tomcat/log4j.jar

You realize the ESET business/enterprise line covers servers, right? And I never mentioned anything about patching. If this isn't ESET's problem, why the following? To appease the "uninformed"? https://support.eset.com/en/alert8188-information-regarding-the-log4j2-vulnerability?ref=esf As of December 11th, the Network Attack Protection feature in ESET security products on Windows was updated to detect the vulnerability. ESET has been blocking attempted attacks from 14:24 CET the same day. Interesting that ESET was on it from Day Zero despite the ridiculous and irrelevant company responses that were posted.

The issue concerns the endpoints under ESET protection! InfoWorld How to detect the Log4j vulnerability in your applications https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html Kaspersky Critical vulnerability in Apache Log4j library https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/ CrowdStrike Log4j2 Vulnerability “Log4Shell” (CVE-2021-44228) https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/ ESET "We don't use Log4J in our products so they are not affected by the vulnerability." "it’s not up to Eset to patch endpoints."

Another irrelevant entry.

That's irrelevant in terms of mitigating the vulnerability at the endpoint.

Thanks, @foneil. The override mode works and helps! Looking forward to v7, @MichalJ. Is there a page dedicated to info about upcoming releases, or a roadmap?

Thanks for the prompt reply. Here are the hints shown in ERA. My goal is to keep the Replace setting, but also permit a workstation to edit the Zones locally on occasion. Notice that only the first mode (hollow circle) indicates editable (unlocked). Do you have a link that shows how to enable and use override mode with the Replace setting active?

Last week, I had the ability to modify the Trusted zones from the client workstation. Today I cannot. It's locked. I have no explanation about the change in behavior. I have a SOHO environment, and I'm the only administrator. I'm on the latest ERA linux install from months ago, 6.5.417.0. The client workstation in question was updated to the latest EP many weeks ago, 6.6.2072.0. The 2nd revision, 6.6.2072.2, didn't make a difference. Looking deeper, I revisted the related policy in ERA, and made the observation that in order to unlock the Zones policy setting, the policy setting must be ignored. Both ERA and the docs stipulate the Setting won't be set by this policy. Is it not possible to configure a policy setting in ERA that will also permit the user to edit the setting? If so, then it's not clear in the documentation.

OS: 64 bit SLES 11.3. ERA: 6.5.417.0 I have this continual problem where ERAServer hangs after a day or two. And the only way to stop it is with a hard kill. kill -9 <pid> Same issue occurred in previous versions. Is there a debug build I can deploy to determine what's causing the hang?

Okay. Thanks.

The Win 10 installations were performed years ago, but the version now displayed is 1703.

Possibly 6.2.2021.0 or 6.4.2014.0 not sure, but the systems now have 6.5.2094.0. Using ERA, The Remote Agent service was also removed; however, the binaries remained on the file system. Also had to reinstall the Cisco VPN on both boxes as that service was also removed, but VPN binaries still on the system. BTW, the program shortcuts were also removed for both ESET and VPN. I know ESET EP was running properly on workstations prior the OS update and automatic activation of Defender. It's as if the OS update detected these services and removed them because they seemed suspicious. Program shortcuts also removed. Binaries left in place.

Just want to pass along the following: This last week, Windows Updates on 2 Windows 10 Pro workstations caused the removal of ESET services; primarily ekrn and the remote agent. Windows Defender was also automatically enabled despite it being disabled since installing ESET EP more than a year ago. To correct the situation, it was easiest to reinstall ESET. No one else was involved in the Windows Updates, and I was prompted at any point to enable Windows Defender. The issue has not yet occurred in Win 7.

Experiencing similarly confusing situations with Windows Firewall behavior. I was under the impression ESET ES 6.x would take over firewall responsibilities similar to what other vendors1 do; however, the Windows Firewall went "active" on a couple of machines locking out remote access and other services configured with ESET EP. The Windows Firewall activation may have occurred after an OS patch and reboot. I don't recall. Nonetheless, I'm under the impression EP didn't properly couple with the OS firewall framework on a few (Win7 SP1 32/64) machines. To get into the machines, I ran the following client command task followed by Send Wake-Up Call, (and waited, got some coffee, read a book, etc...): netsh firewall set opmode disable On one particular domain machine, I had to disable the firewall via a Local Computer Policy: Computer Configuration, Administrative Templates, Network, Network Connections: Windows Firewall, Domain Profiles: Windows Firewall: Protect all network connections [Disabled] I'd like to reverse this policy revision, but I can't afford to have the Windows Firewall block the machine's provided services I'm allowing via ESET ES 6.x. And I don't want to deal with firewall rules in two locations (i.e., WIndows Firewall and ESET ES.) And of course, ERA 6.x is reporting Critical status because the OS Firewall is inactive, but only for the machine where I applied the above local policy. Any related tech notes, ESET? Note: The machines had SEP 11.x installed, and subsequently removed by an ERA task.

I managed to get a body in front of the workstation to release the Block. From what I could tell, not even the agent could communicate to ERA. ESET, I recommend providing the user the chance to specify a duration for the Block with the default value set to 15 min. Other duration values could be 1 hour, 4 hours, and Indefinite. It would also make sense to keep the agent port active unless the user elects otherwise. In theory with the agent port open, I could have applied a corrective policy. My click error that activated the Block occurred over a slow VNC connection where visualization of mouse movement lagged actual activity. I never expected the immediate shutout.

Working remotely, I managed to click Block all network traffic instead of Pause firewall, on a workstation's Endpoint Security 6.x task menu. I didn't intend to lock myself out of the workstation. The target workstation is registered with ERA 6.x. I tried a variety of policies to permit remote access to the workstation, but no luck. Any ideas to reverse/undo the Block that can be facilitated by ERA and the workstation's installed agent?

There's the possibility that ESET's online management portal might provide what you need. I'm using the portal to review licensing status. My ERA installation also relies on the portal for license allocation. Perhaps, ESET could help you with a batch file that would connect to the portal instead of a local ERA installation. I'm new to ESET, so I'm not that familiar with support requests.

We're also using ZCM. We're now migrating our AV requirements to ESET away from another vendor unrelated to Zenworks. I recommend using ESET Remote Administrator understanding you may be able to do the initial agent deploys using ZCM. If you haven't setup the remote administrator (ERA), do so. Then using the ERA, you can prepare agent installers (batch files) for the client computers. The installed agents then communicate to ERA for managing subsequent product installs and related ESET tasks. Our ERA is installed on the same SLES 11.3 64 bit server hosting ZCM. After taking care of the initial requirements such as the database, I copied the ERA webapp (era.war) to the same Tomcat instance serving Zenworks 11.3. No problems. The agent installer, at least for Windows, is a batch file that can likely be deployed from ZCM. You can modify the batch file to specify the source agent MSI files which (in my environment) are normally fetched directly from eset.com. You can generate these batch files using ERA. Look for Agent Live Installers. Also, be aware of the reliance on a working WMI environment (for Windows.) I had to repair a Win7 workstation in order for the ESET agent to function properly. If you take the ERA route, be prepared to check the agent logs (on the target client) for problematic installations. On Windows: C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs This post was helpful in correcting the WMI problem I mentioned: hxxp://www.sevenforums.com/performance-maintenance/243922-wmi-corrupt.html#post2033998 The WMI errors were reported by the agent as something similar to: CWbemServices: Could not connect. Error code = 0x8007007e If you don't mind, let me know how things progress. I'm still working through the ESET / ZCM relationship and haven't made any hard conclusions regarding endpoint management. BTW, we're installing ESET Endpoint Security which includes ESET AV. Of course with Zenworks, only ESET AV is required. Our ZCM is used primarily for managing linux servers.

I share verus' frustration regarding the mysterious delays concerning task execution. Some improved feedback about Send Wake-Up Call failure would help. If ERA reported the next scheduled agent sync, that would help too. One of the biggest gripes I have with centralized remote management is inadequate feedback of vital activity, especially activity that is intended to execute immediately. It often results in wasted time, doubt about product quality, and inevitably diminished reliance on the product. Regarding ERA 6.x and the related security products, I'm very happy, but I might be ecstatic if immediate mode scheduling had better instrumentation.