Borked HIPS

[itman 1,659]

This is the second time the Eset HIPS has malfunctioned in recent months in ver. 17.2.24. Both with no indication from Eset that something was amiss.

This morning after system startup, I noticed I wasn't receiving any alerts from my HIPS ask rules. Triggered a couple of them and zip from Eset. No alerts, log activity, nada. Rebooted system and they were again working.

I am really questioning the reliability of this product anymore.

[New_Style_xd 69]

50 minutes ago, itman said:

This is the second time the Eset HIPS has malfunctioned in recent months in ver. 17.2.24. Both with no indication from Eset that something was amiss.

This morning after system startup, I noticed I wasn't receiving any alerts from my HIPS ask rules. Triggered a couple of them and zip from Eset. No alerts, log activity, nada. Rebooted system and they were again working.

I am really questioning the reliability of this product anymore.

It's really hard to know if we're safe like you said it's the second time.
"I liked your review saying that you are questioning the reliability of the product."
I don't know why ESET takes so long to fix its product issues?

[NewbyUser 73]

1 hour ago, itman said:

This is the second time the Eset HIPS has malfunctioned in recent months in ver. 17.2.24. Both with no indication from Eset that something was amiss.

This morning after system startup, I noticed I wasn't receiving any alerts from my HIPS ask rules. Triggered a couple of them and zip from Eset. No alerts, log activity, nada. Rebooted system and they were again working.

I am really questioning the reliability of this product anymore.

Do you just let the system go to sleep or do you log off? I’ve taken to logging off. Not sure if it’s Windows or Eset or both, but there’s definitely something wrong with waking from sleep/hibernate with the two of them. 

[itman 1,659]

3 minutes ago, NewbyUser said:

but there’s definitely something wrong with waking from sleep/hibernate with the two of them. 

I have Win 10 fast startup enabled.

However, in the first HIPS bork incident, only an Eset reinstall fixed it. This would be indicative of internal corruption.

[New_Style_xd 69]

1 hour ago, itman said:

I have Win 10 fast startup enabled.

However, in the first HIPS bork incident, only an Eset reinstall fixed it. This would be indicative of internal corruption.

Is the eset team aware of this problem with the product?

[stackz 112]

I've had this happen on multiple occasions prior to going back to beta testing. I'm currently beta testing and this has occured 4 times that I'm aware of in the last 5 days (I've reported it in the beta forum and through beta support). Reloading the saved settings seems to wake the HIPS ask rules up for me. To say I'm unimpressed is an understatement.

Edited September 14, 2021 by stackz

[NewbyUser 73]

21 hours ago, New_Style_xd said:

Is the eset team aware of this problem with the product?

Doesn’t seem so. There is apparently zero interest from Eset as no one from the company has commented or asked for more information in a day so far. 

[itman 1,659]

18 hours ago, stackz said:

I've had this happen on multiple occasions prior to going back to beta testing.

I guess I am the lucky one since this is the first time it every happened to me. Also, I would be aware of this malfunction since at least one of my HIPS ask rules triggers daily.

BTW - my prior noted HIPS bork incident was much more serious. The HIPS was not injecting its ebehmoni.dll and/or ebehmonl.dll Deep Behavior Inspection .dlls into select processes; e.g. cmd.exe, that it monitors. This required a re-install to fix.

Edited September 14, 2021 by itman

[NewbyUser 73]

I guess they only view HIPS as a marketing tool to genrate more moeny. Beyond that they don't really seem to care about it. You'd figure it would used more, but it's not, nor do they seem to care when it doesn't work.

[New_Style_xd 69]

8 minutes ago, NewbyUser said:

I guess they only view HIPS as a marketing tool to genrate more moeny. Beyond that they don't really seem to care about it. You'd figure it would used more, but it's not, nor do they seem to care when it doesn't work.

I get very thoughtful when I see these things, and it takes a lot of time to fix them. always have something or excuses, while other protection products have daily fixes and released daily, for example the avast forum, you see an error and inform them, on the same day they fix and launch the update. on the same day.
That's because I don't like using avast products. but I always stay up to date on security products.

[stackz 112]

I can reliably reproduce one bug, where I can perform some task that should trigger an ask dialog but doesn't (e.g process launch) as soon as I log in.

Edited September 15, 2021 by stackz

[Marcos 5,074]

1 hour ago, stackz said:

I can reliably reproduce one bug, where I can perform some task that should trigger an ask dialog but doesn't (e.g process launch) as soon as I log in.

Have you rebooted the machine in the last 2 days?

We have found a bug in the HIPS module 1420 which was put on the pre-release update channel a week ago and then slowly released to all users with a full release on this Monday. Until Itman reported the issue, we hadn't received any reports from users. A reboot fixes the issue.

Today we're going to release a hotfix update of the HIPS module which addresses the issue.

[itman 1,659]

2 hours ago, Marcos said:

We have found a bug in the HIPS module 1420 which was put on the pre-release update channel a week ago and then slowly released to all users with a full release on this Monday. Until Itman reported the issue, we hadn't received any reports from users. A reboot fixes the issue.

What I am observing is there is a bigger issue. Appears Eset is not properly initializing coming out of Win 10 fast startup mode. I am having issues with Eset Network Protection; namely Network Inspection not working properly.

[Marcos 5,074]

3 hours ago, itman said:

What I am observing is there is a bigger issue. Appears Eset is not properly initializing coming out of Win 10 fast startup mode. I am having issues with Eset Network Protection; namely Network Inspection not working properly.

Do you mean that you hadn't experienced this issue before a particular module or program update? Could you elaborate more on the issue? Do you get any errors on the home screen and the protection status changes?

[itman 1,659]

2 hours ago, Marcos said:

Do you mean that you hadn't experienced this issue before a particular module or program update? Could you elaborate more on the issue? Do you get any errors on the home screen and the protection status changes?

I was referring to Eset Network Protection "borking" my existing local network settings.

I have made multiple posting in regards to my unique router hardware issue with Eset networking processing. For a while, my existing settings were stable with no issues. This has changed with ver. 17 with the situation becoming unbearable.

I suggest Eset modify the firewall to give an option to only use its firewall for outbound user custom rule processing. All network identification and inbound rule processing would be done by the Win 10 firewall.

[SlashRose 25]

On 9/13/2021 at 8:52 PM, itman said:

I am really questioning the reliability of this product anymore.

After today Eset once again stuck to the update and even after 1 hour waiting nothing changed, I doubt the reliability of Eset now more than just! The last few months are just too many errors that Eset has had since several builds and therefore I doubt so slowly the reliability of this AV's

Edited September 16, 2021 by SlashRose

[New_Style_xd 69]

10 minutes ago, SlashRose said:

After today Eset once again stuck to the update and even after 1 hour waiting nothing changed, I doubt the reliability of Eset now more than just! The last few months are just too many errors that Eset has had since several builds and therefore I doubt so slowly the reliability of this AV's

It was informed here in the forum on Monday 13/09/2021 that there would be an update of the HIPS but so far nothing. as shown in the image below.

I believe the last update was on 8/27/2021

[Marcos 5,074]

The module was released to the pre-release update channel yesterday and is gradually released for all other users.

[peteyt 393]

2 hours ago, SlashRose said:

After today Eset once again stuck to the update and even after 1 hour waiting nothing changed, I doubt the reliability of Eset now more than just! The last few months are just too many errors that Eset has had since several builds and therefore I doubt so slowly the reliability of this AV's

This sounds like the same issue I had, which I added to the posts on here 

 

I had noticed the updates generally had been quicker as of lately, and didn't notice much system issue. However while this update occurred, the PC was very sluggish, with Google Chrome for example taking a while just to open, and browsing seemed very slow, like Eset was causing it to be slow. However I did download a test download from https://www.thinkbroadband.com/download, using the 512MB one which was a lot bigger than Eset's update. I was able to download that in about a 1-2 minutes while as Eset took well over half an hour and even crashed at the end and had to restart. 

The thing is I can't remember any update issues before the updates where designed to use less resources. I don't know if this feature is any good because if anything it seems to be causing more resource issues/slowdowns, like everything is waiting for Eset to finish

[itman 1,659]

@Marcos, I found a workaround to my IPv6 networking issues and it was by sheer luck. More on that later. First, a brief review of my network situation.

My ISP is AT&T Uverse. It is a long known fact that they require you to use their DNS servers.

Next up is how IPv6 network and connectivity is established. It is not done via conventional DHCPv6 methods. Note that AT&T Unverse provider routers are programmed to perform the actual IPv6 network setup and connectivity to it at system startup time. First, limited IPv6 connectivity is established. Next the router using ICMPv6 sets up the actual local device IPv6 network and establishes full AT&T IPv6 connectivity to it. This includes, and most important, IPv6 connectivity between AT&T actual IPv6 DNS servers, a dedicated IPv6 relay DNS server, and a dedicated IPv6 local device DNS server as shown in the following diagram:

ATT real IPv6 DNS servers

                <---->

reserved AT&T relay DNS server allocated within local device Ethernet IP address range

               <---->

local device IPv6 DNS server controlled by IPv6 gateway.

The above takes about 1 - 2 mins after system startup to perform and the IPv6 network and DNS servers to initialize and become fully operational.

The above IPv6 network processing co-existed with Eset network processing aside from an occasional "hiccup" until ver. 17; with 17.2.24 totally breaking the processing. My strong suspicion is overly aggressive Eset Network Inspection processing "choking" on the setup of an IPv6 network "on-the-fly."

Now for the workaround.

Trying over time every solution "know to networking mankind," I thought "what the hell." Let's try Cloudflare IPv6 DNS ervers. To my utter amazement, it worked! At least. so far. Note, I did not change my IPv4 DNS servers to Cloudflare ones. I am now receiving full IPv6 network initialization at boot time resulting in Eset Networking not "going bonkers." All system startup modes; restart, win 10 fast startup, and resume from sleep all work presently w/o issue. My suspicion is AT&T is using IPv4 DNS server settings to determine that their DNS servers are used and allowing third party IPv6 servers. I also believe that the third party IPv6 DNS servers are now acting as the relay DNS servers to the actual AT&T IPv6 DNS servers.

Edited September 17, 2021 by itman

[itman 1,659]

Well, I'll be damned! It appears AT&T is indeed forwarding IPv6 DNS requests to Cloudflare:

Quote

tracert wilderssecurity.com

Tracing route to wilderssecurity.com [2600:3c00::f03c:91ff:fe92:3446]
over a maximum of 30 hops:

  1     4 ms     4 ms     4 ms  2600:1700:xxxx:xxxx::1  ...........> My local device IPv6 DNS server
  2     9 ms     8 ms     8 ms  2001:506:6000:101:69:235:126:28
  3     9 ms     8 ms     9 ms  2001:506:6000:101:69:235:126:17
  4    19 ms    19 ms    25 ms  cgcil403igs.ipv6.att.net [2001:1890:ff:ffff:12:122:132:121] ......> AT&T
  5    17 ms    15 ms    16 ms  be3039.ccr41.ord03.atlas.cogentco.com [2001:550:3::231]
  6       *           *             *     Request timed out.                                                  
  7       *           *             *     Request timed out.                                                  
  8    38 ms     *             *     be2433.ccr32.dfw01.atlas.cogentco.com [2001:550:0:1000::9a36:3d5]
  9       *          37 ms     36 ms  be2764.ccr41.dfw03.atlas.cogentco.com [2001:550:0:1000::9a36:2fd6]
 10    38 ms    38 ms    37 ms  2001:550:2:31::59:2
 11    39 ms    39 ms    39 ms  2600:3c00:2222:15::2
 12    37 ms    37 ms    36 ms  wilderssecurity.com [2600:3c00::f03c:91ff:fe92:3446]

Trace complete.

* Cogent hosts Cloufare DNS servers. Also, GoDaddy ones

 

Edited September 17, 2021 by itman

[itman 1,659]

Well, true to Eset form and unfortunately, Eset dropped monitoring of the IPv6 connection upon resume from sleep mode. See below screen shot.

As previously discovered, performing ipconfig /all or showing existing networking details within Win 10, causes Eset to immediately recognize the IPv6 connection.

 

Edited September 17, 2021 by itman

[itman 1,659]

It's a new day. I have discovered a new networking feature, And of course, Eset networking support borked it!

The new and important find is if you are using an IPv6 only network which is the case for my ISP, AT&T Unverse, and using third party IPv6 DNS servers, you should be using DNS servers that fully support DNS64. Again, DNS64 is used to convert IPv4 addresses to IPv6 addresses in a 4-6-4 tunnel on the ISP network. The new find is Cloudflare has such dedicated servers. You can read about this here: https://developers.cloudflare.com/1.1.1.1/ipv6-networks . Great! Set my network connection to those IPv6 addresses and modified Eset's connected network setting likewise.

Now for the Eset bork of this capability. The first thing I noticed was it appeared Eset was having trouble establishing a connection on port 8888 likewise on port 443 which is what Push Notifications falls back to. Sure enough, after a half hour Eset displayed the dreaded could not establish a connection to its Push Notifications server. So what is the friggin problem?

Eset Push Notifications uses the MQTT protocol designed to create machine-to-machine; i.e. tunnel, connections to IoT devices. It appears this protocol is not compatible with DNS64 which makes sense if you think about it. So once again Eset implements something without thoroughly testing its compatibility with established networking features.  @MarcosEset needs to be sending Push Notification traffic via IPv6 to resolve this issue. Assume Eset will have to provide a GUI setting option to receive Push Notifications via IPv6 or IPv4 connection. Or better, if Eset sees an IPv6 connection is established, prefer that over IPv4 for Push Notifications communication.

Edited September 18, 2021 by itman

[SlashRose 25]

On 9/15/2021 at 4:54 PM, itman said:

Was ich beobachte, ist, dass es ein größeres Problem gibt. Es scheint, dass Eset das Herauskommen aus dem Win 10-Schnellstartmodus nicht richtig initialisiert. Ich habe Probleme mit Eset Network Protection; nämlich dass die Netzwerkinspektion nicht ordnungsgemäß funktioniert.

This error has been around for quite a while, namely since the Windows 10 May Update.  
I find it really, very strange that the Eset developers/coders do not notice this and this error is taken over by Eset from build to build, as well as other bugs and all this moved me to stop constantly sending logs etc. and not to engage me so much anymore, 

[itman 1,659]

Today is Sunday and I can finally state I have Eset Networking finally setting up a stable and correct networking configuration. Additional things I had to do to accomplish this is:

1. Configure my network adapter IPv4 connection DNS settings to use Cloudflare IPv4 DNS servers. Again, amazed AT&T allows this.

2. Ensuring all Eset network settings where "use Windows settings" are applicable are enabled. Since the Windows firewall defaults to Public profile use and this is what I want my system to use, this suits me just fine.

3. Using the latest network connection Eset establishes and deleting any others that might exist.

At this point, I have in effect bypassed any networking auto configuration activities my router was performing and Eset's resulting bork network configuation of those auto configuration activities.

The interesting part now is I observe ekrn.exe performing UDP and UDPv6 local proxy monitoring activities but Eset Network Connections tool no longer shows local host 0.0.0.0 and 0.0.0.0.0.0 addresses.

My final comment is Eset needs to immediately address this Push Notifications issue with DNS64 use. When I was using Cloulfare's IPv6 DNS64 servers, I performed the AMTSO Cloudcar test. Immediately Eset detected and blocked the connection prior to any attempted file download activities which is the correct result for this test. Such is not the case when the Clouldflare's non-DNS64 IPv6 DNS servers are used. As shown below, Eset is detecting a "stub" download of the clouldcar.exe file:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
9/18/2021 2:35:18 PM;Real-time file system protection;file;C:\Users\xxxxxx\AppData\Local\Temp\Z76h0z2s.exe.part;Suspicious Object;cleaned by deleting;xxx-xx\xxx;Event occurred on a file modified by the application: C:\Program Files\Mozilla Firefox\firefox.exe (C4BD2C3764935F306A02DF54090F9435EB922780).;F4053231135502B4E8EA2B4D2E32ABEFE3A08765;9/18/2021 2:16:02 PM

-EDIT-

I guess I should clarify what I posted above. There is noting wrong with Eset's detection in the Cloudcar test. Rather, it is the speed difference the detection took when using Cloudflare IPv6 DNS64 servers. The connection to Eset cloud servers and resultant detection was almost instantaneous versus a 2 - 4 sec. delay when not using those servers. This translates to a dramatic increase in browsing speed if I can use those servers. Something I can't presently do because of the Eset Push Notification issue with DNS server based DNS64 processing.

Edited September 19, 2021 by itman