carmik

Hello, I've enabled web filter, blocking a number of categories. Unfortunately a large number of "xxxxx site is blocked" alerts pop up on the clients. Is it possible to inhibit this type of alerts via the eset protect console? If so, which area of the configuration should I modify? Thanks in advance.

EDIT: correction, defender is disabled but is shown as an active AV application. Defender-provided cloud protection is enabled, as is automatic submission to MS...

Recently we got some Windows Server 2019 Standard boxes, which we fully patched. Afterwards we installed Server Security (currently at version 8.0.12003.0). We've noticed that in windows update we're constantly reminded to install intelligence updates for windows defender. Looking further, Windows defender seems to be still enabled. This happens on all of our 3 server 2019 systems. Shouldn't ESET have registered itself as the security application? How can we fix this?

Thank you for the clarification. One favor though: is it possible to attach here the httpd.conf file of 9.x esxi VA? I'd like to do a diff of what I have with the vanilla 9 VA.

Hello, I've just taken the plunge to update our ESET 8.1 VA to 9. I did not use the recommended method of database pull, too much hassle. Used a components upgrade task in the web console. We do use the Apache HTTP proxy on our VA, and there's a note in https://help.eset.com/protect_install/90/en-US/components_upgrade.html titled "Important instructions before upgrading Apache HTTP Proxy on Virtual Appliance" which states to back up the original httpd.conf (located in /opt/apache/conf). Problem is that no such directory exists. Under /opt there's only "eset", nothing else. I did a wget https://help.eset.com/protect_install/90/apache/httpd.conf -O /tmp/httpd.conf -o /tmp/wgeterror.log but the httpd.conf file downloaded was quite a bit different compared to the existing /etc/httpd/conf/httpd.conf How should I proceed?

I see, thank you for your detailed analysis!

@Marcos tested with Firefox 92 (64-bit), normal installation made via group policy. Downloaded cloudcar.com from https://amtso.eicar.org/cloudcar.exe Furthermore, the downloaded file was intact. It was when I right-clicked on it and selected to demand-scan it that it got detected and quarantined: However, right now it works just fine (crazy)! That is, I immediately got a "suspicious" window and the download of eicar.com ended up with a zero-length file! This lack of consistent defense does scare me. But the fact that I can not reproduce the issue is problematic. Would current logs of the pc in question have any decent information that would help, or should extended logging have been enabled beforehand?

Was looking into something policy-related and ended up checking whether livegrid works/is enabled on our 8.1 endpoint clients. AFAIK, both livegrid as well as tls filtering are enabled. So I ended up at this test https://support.eset.com/en/kb5552-enable-or-disable-eset-livegrid#TestLiveGrid where for various reasons I could not test (regular HTTP) hxxp://amtso.eicar.org/cloudcar.exe but I could test secure http https://amtso.eicar.org/cloudcar.exe I was able to download the latter just fine!!! Which is a twofold surprise for me: first, why didn't the web filter block this download in the first place? Second, why didn't saving the file to disk trigger the on-access tagging of this file as malevolent (even though I think that eset scans on read access and not on write access by default). Any ideas why this happens? For the record, all options regarding live grid are enabled and all options regarding TLS scan are also enabled:

Ok, back at work. The scenario is this: we have a Checkpoint VPN software that does not run well under Windows 10. In order to be able to actually utilize it successfully, a user has to start internet explorer as an admin. This is problematic as you can understand, since this opens a full can of worms. So we've been instructed to follow this approach: install powertoys and create two scripts. One that launches internet explorer named script.cmd: elevate "C:\Program Files\internet explorer\iexplore.exe" And one that resides on the user desktop, named vpn.cmd: runas /user:local_admin_user /savecred "cmd /c c:\path\to\script.cmd" So the user runs vpn.cmd, which in turn starts cmd to execute script.cmd. Hope this makes sense now. The bug (if it is one) is that admin block rules in the eset HIPS policy seem to be case-sensitive, regarding the name of the application used!

elevate "C:\Program Files\internet explorer\iexplore.exe" itman the issue is that the allow rule for the action above does not match the same command when "internet explorer" above is written as "internet Explorer".

Not sure if this is a bug or not (I think it is though). Got a number of Endpoint security 8.1 boxes on which I've loaded the KB6119 HIPS policy. Since I had a script that starts Internet explorer, I made a new policy to append a rule that allows wscript.exe to start C:\Program Files\internet explorer\iexplore.exe (note especially how the underlined part is written). For the record, the script is named script.cmd and contains: elevate "C:\Program Files\internet explorer\iexplore.exe" This worked on a couple of systems. However, I was receiving HIPS alerts from other systems. Upon closer inspection the problem was that in the scripts used in those systems, I had written script.cmd with different casing in the words internet explorer, ie: elevate "C:\Program Files\internet Explorer\iexplore.exe" It seems that the HIPS rule differentiates between these two cases, although it shouldn't (as far as I know, Windows file system names are case insensitive, therefore the first rule should match the 2nd case as well. Can someone from ESET check if this is an issue indeed, and, if so, provide a fix?

@Marcosthank you for your intervention. ESET support replaced the key with another one! Much obliged!

Very interesting! Have to ask: how did you isolate this task. That is, how did you go about investigating the cause of this?

I'll follow that route most likely, thanks!

Two thirds of my systems are dell optiplex desktops, whereas the other third consists of HP desktops. No dism so far...

I'll follow that approach most likely.

That's understood. However, in my setup it's not one or two systems generating alerts, but about half of my installed base, meaning I'd have to disable the rule completely until finding a way to tune it somehow. Otherwise, this policy defeats its merits, at least on my installation. For example, I was blocked while interactively starting installation of the Microsoft windows installer cleanup utility (blocked wscript).

@Marcos I've been communicating with Amazon. Due to the time passed they can not provide a refund, but they've provided an email statement that the license is defective. Due to the personal information enclosed, I'll be passing this to you over a PM.

@PuterCareI'm running into some similar issues, as outlined in If you manage to find something that actually helps you here, please drop me a line!

I've imported and applied an ESET-provided HIPS rule to our LAN clients, as per KB6119. After doing so I'm bombarded by the following event types: C:\Windows\System32\cscript.exe trying to start C:\Windows\System32\cmd.exe C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe trying to start C:\Windows\system32\ipconfig.exe C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe trying to start C:\Windows\System32\Conhost.exe This behaviour seemed similar to the one described in: However, my own clients are normal PCs which are not connected to AzureAD but rather to our local AD servers (2019). Around 30 out of 120 systems are triggering this policy at the moment. Since I have just applied, I expect this figure to rise. I must say though that this policy has not been triggered on any of the IT stuff client systems. Which is a bit worrisome, suggesting that this might be something more than false positives. I'll try to raise logging level as per the thread above, but I'd be grateful if someone could provide better instructions on how to do it.

Marcos, this was a sealed ESET package, not an electronic key. I will provide you with the details over a PM.

Thanks, sent.

I'm sorry, I was not provided with a public ID upon purchase, just a license key...

Hello @Marcos, on a related context I've got a multi user license similar to the one described here, that I am unable to activate. According to the installer it is already expired, although I recall that I have never used it. This license was bought from Amazon if I recall correctly two years ago and I'm unable to figure out who to contact... Would it be ok if I contacted you with the license key and my details? Thanks in advance!

I'm sorry I had to try some things to return the pc to its user. What I did was disable the antivirus protection, which seemingly disabled both eset and defender. Then I enabled eset only and it all looked well.