Borked HIPS

[itman 1,659]

One important observation I forgot to mention.

When I using Cloulfare's IPv6 DNS64 servers besides the Eset Push Notifications issue, the first thing to manifest was the Eset "hung" updating and constant Eset desktop toolbar icon spinning wheel issue.

I therefore conclude this current Eset hung updating issue has nothing to do with what has been stated to date in the forum. Rather, the problem is related to Eset Push Notification processing malfunction in some way.

[SlashRose 25]

I'm curious if you're right itman. For me, the network has always been public.

[itman 1,659]

4 hours ago, SlashRose said:

I'm curious if you're right itman. For me, the network has always been public.

By default, Eset network Profile selection is "use Windows settings." As I previously posted, Win 10 firewall default network Profile setting is Public. Therefore if using default settings on both, Eset's Network profile would always be set to Public.

-EDIT- Some additional detail here.

Win 10 firewall defaults to the Public profile for a reason. It auto disables Network Discovery. The way you're supposed to securely do file sharing on a Win 10 device is to right mouse click on the file to be shared on the network and select the "Give Access" option.

This also brings up why Eset has the "Home or Office networking" profile option in the first place since it in effect, overrides Win 10 built-in network security. The most damning aspect of the Home or Office networking Eset profile is it enables NetBIOS access by default.

Edited September 20, 2021 by itman

[itman 1,659]

Well, there was one last thing I had to perform to get the router, Win 10, and Eset networking to play together nicely.

I have long suspected that Win 10 Smart multiple-homed DNS name resolution was the source of most of my network issues. This was further amplified by Eset networking initialization. But since this feature was using my ISP DNS servers combined with the way the router establishes Win 10 network connectivity, I could never definitively nail it down.

You can read about what Win 10 Smart multiple-homed DNS name resolution does here: https://www.ghacks.net/2017/08/14/turn-off-smart-multi-homed-name-resolution-in-windows/ . The gist of the what is does is:

Quote

The feature is designed to speed up DNS resolution on a device running Windows 8 or newer by sending DNS requests across all available network adapters. Microsoft refined the feature in Windows 10 as it selects the information that is returned the fastest automatically.

What I have been observing after my Win 10 networking "from hell" reconfiguration activities described previously is at Win 10 fast startup and/or startup from sleep mode predominately is multiple connections to IPv4 address 1.1.1 to port domain. Err what? Port domain turns out to be port 53 and of course, 1.1.1.1 is Cloudflare's IPv4 DNS address. First, I have never ever seen these domain connections before. Next is I shouldn't be using Cloudflare's IPv4 DNS server on an IPv6 network. Bottom line is here is a graphic example of my Win 10 network connection being borked by Smart multiple-homed DNS name resolution processing. As far as what this did to Eset's network connectivity processing can best described as a double-whammy bork from the deepest depths of networking hell.

Anyway, I have disabled Win 10 Smart multiple-homed DNS name resolution and finally, all is well networking-wise.

Edited September 22, 2021 by itman

[itman 1,659]

Well, it didn't take AT&T long to detect my Cloudflare IPv6 DNS server usage and start interfering with that. So I am now back to using their auto assigned DNS servers and Eset's networking resultant borking of those connections.

But I have finally confirmed the Eset culprit. It is the Network Inspection feature. Disabling that not only solved the auto IPv6 configuration by my router problems but most importantly, the totally spastic Eset firewall behavior upon resume from sleep mode.

I also question the use of Network Inspection processing when the Public profile is deployed. Its applicable Eset firewall rules only allow Trusted network device communication. When using the Public profile, no local network devices are trusted.

Edited September 25, 2021 by itman

[NewbyUser 73]

I obviously don't have the IT knowledge you do, but by switching to another product and using windows firewall I have noticed a generalized speed increase in browsing and overall network performance. What protection gets lost by disabling Network Inspection?

[SlashRose 25]

I, like you itman and others, no longer see Eset as trustworthy and where since Corona the attacks have increased a few times. This is not a fine kind of Eset.

[Marcos 5,074]

3 hours ago, itman said:

But I have finally confirmed the Eset culprit. It is the Network Inspection feature. Disabling that not only solved the auto IPv6 configuration by my router problems but most importantly, the totally spastic Eset firewall behavior upon resume from sleep mode.

Do you mean that disabling this option resolves the issue with the auto IPv6 configuration by your router?

[Marcos 5,074]

3 hours ago, NewbyUser said:

I obviously don't have the IT knowledge you do, but by switching to another product and using windows firewall I have noticed a generalized speed increase in browsing and overall network performance.

The question is if the other product performs SSL inspection, scans downloaded archives completely, if it filters the communication on the WFP layer, etc. to make sure we compare apples with apples. I'd strongly recommend creating a new topic for any issue not connected with the initially reported HIPS issue where it could be discussed further.

[itman 1,659]

1 hour ago, Marcos said:

Do you mean that disabling this option resolves the issue with the auto IPv6 configuration by your router?

Correct.

It also resolved a more serious issue that manifested on ver. 17. Upon resume from sleep mode, it appears the Eset firewall wasn't initializing itself properly; or not fast enough. Note this didn't happen upon every system startup from sleep mode, but it happened enough to be disconcerting.

Network Wizard showed blocked svchost.exe inbound traffic to ports 53, 137, 1900, 3702, 5353, and 5355. The "rub" is the remote IPv4 address shown was my device assigned IPv4 address. In other words, Eset firewall; or more likely Network Inspector, wasn't initializing properly and was interpreting legit outbound traffic from my device as inbound traffic and blocking it!

Edited September 25, 2021 by itman

[NewbyUser 73]

2 hours ago, Marcos said:

The question is if the other product performs SSL inspection, scans downloaded archives completely, if it filters the communication on the WFP layer, etc. to make sure we compare apples with apples. I'd strongly recommend creating a new topic for any issue not connected with the initially reported HIPS issue where it could be discussed further.

It uses WFP, an odd comment as I'm not aware of any AV that doesn't. I turn off SSL scanning.

[itman 1,659]

Let's talk about Eset's Network Inspection Inspector processing since there is zip technical details on it.

To begin, Eset's network inspection processing  is not new and has existed on every EIS version I used dating to 2014. Past versions were relatively benign and non-troublesome. Once I configured Eset's network connection to accommodate my router, the settings remained stable. All this changed when Eset decided to get "cute" and expand network Inspection to examine router settings for the purpose of detecting suspected hacking activities. Great idea for off-the-self routers and the like that perform standard network initializing activities. A very bad idea for ISP provided routers with customized firmware settings.

The only positive thing in recent Eset versions is that now Network Inspection Inspector can be disabled via GUI setting which was not possible in the past.

For those who like technical details, let's get into those. Using a networking connection monitor such as TCPView, open it immediately after system startup time. Look for an ekrn.exe connection monitoring UDP port 138. Eset is examining network connections via proxy using this port. This is also where the problems start. My router is using NetBIOS which also uses that port to initialize it's router connectivity to my device. It then goes downhill network-wise from here.

Edited September 26, 2021 by itman

[New_Style_xd 69]

7 hours ago, SlashRose said:

I, like you itman and others, no longer see Eset as trustworthy and where since Corona the attacks have increased a few times. This is not a fine kind of Eset.

Tell us in more detail why you are not finding it more reliable, talk a little more about the attacks that have increased do you think this version 14 is not good?

[itman 1,659]

I will again mention that if my router contained a DHCPv6 server, there probably would be no issue with Eset Network Inspection Inspector processing. It appears Eset is relying of DHCP initialization activities to identify network elements.

This router is internally via communication with the AT&T network setting up the IPv6 local network and its related DNS servers.

Edited September 26, 2021 by itman

[SlashRose 25]

15 hours ago, New_Style_xd said:

Sagen Sie uns genauer, warum Sie es nicht zuverlässiger finden, sprechen Sie ein wenig mehr über die Angriffe, die zugenommen haben, denken Sie, dass diese Version 14 nicht gut ist?

Yes the v14 is bad because it has too many errors and an AV that has many errors is not trustworthy for me!

This is only a small excerpt, since the Eset protocol has not logged everything that takes place in port scans and attacks for some builds.                  

I have had between 30 and 40 attack attempts every day since the Corona craze, before Corona came I had maybe 10 attacks in half a year, that's what I mean!

 

And that's why it's all the more important to have a reliable AV during this time.

Edited September 26, 2021 by SlashRose

[itman 1,659]

21 minutes ago, SlashRose said:

This is only a small excerpt, since the Eset protocol has not logged everything that takes place in port scans and attacks for some builds.      

Interesting.

My ISP router has an excellent stateful firewall plus IDS protection. Hence, external network attacks like these are dropped on the WAN side of the router. Also, more reason to disable Eset Network Inspector if there are suspicions it might be tampering with any internal router mechanisms.

[itman 1,659]

I need to correct my prior postings in regards to Eset Network Inspector and network inspection processing.

Eset's network inspection processing is a critical security mechanism used to inspect IPv4 and IPv6 network traffic via proxy mechanism. It is "baked" into Eset and there is no way to disable it. Nor should you ever want to do so. Its malfunction in regards to monitoring of IPv6 network traffic in ver. 14 is the primary reason I embarked on this long resolution quest.

Eset Network Inspector is the newer feature Eset introduced to monitor router tampering activities. It however does deploy Eset network inspection processing to do so. Besides Network Inspector borking my router's IPv6 configuration activities at system startup time, it was also failing to initialize the network inspection IPv6 network connection.

BTW - disabling Network Inspector doesn't appear to fully disable its processing. Another Eset feature that uses it is the Network Wizard. The difference being when the Wizard is deployed is after system startup time. Since my router would be fully initialized at this time, it causes no adverse activities to occur against it.

Edited September 26, 2021 by itman

[NewbyUser 73]

I’ll have to reinstall it to see what it says but I believe in the settings it says Network Inspector is to identify other devices are the network. It doesn’t say anything about adding anything protective in nature. It’s merely informative. 

[itman 1,659]

15 minutes ago, NewbyUser said:

I’ll have to reinstall it to see what it says but I believe in the settings it says Network Inspector is to identify other devices are the network.

In order to do this, it has to establish a local network "baseline" of legit devices that exist at system startup time.

[NewbyUser 73]

It sort of says it "helps" with identifying open ports and vulnerabilities, but doesn't seem to indicate it has any protective role. So how is it a critical security mechanism?  And on a side note, now I have to/should post about updates hanging again, this product is a mess. 

 

[New_Style_xd 69]

1 hour ago, NewbyUser said:

It sort of says it "helps" with identifying open ports and vulnerabilities, but doesn't seem to indicate it has any protective role. So how is it a critical security mechanism?  And on a side note, now I have to/should post about updates hanging again, this product is a mess. 

 

I see there are a lot of people talking about these glitches that you have in v14, but I don't think anyone at eset is seeing what consumers are reporting. if by chance they are seeing it, it takes a long time to make the correction, it always says it will stay for the next V15.
I noticed that the product version always and after 1 year. does it take so long to fix?

[itman 1,659]

With Network Inspector no longer interfering with proper configuration of my local network, let's talk about the correct bindings being established. @Marcos, you should find this of interest.

I won't talk about the ipv4only.arpa; i.e. DNS64, binding since that one was always being established.

First up in the IPv4 binding. Nothing unusual here:

Quote

attxxxxx.net
    ----------------------------------------
    Record Name . . . . . : attxxxxx.net
    Record Type . . . . . : 1
    Time To Live  . . . . : 10397
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 192.168.1.xxx  <----- Local network assigned IPv4 DNS server

    Record Name . . . . . : attxxxxx.net
    Record Type . . . . . : 1
    Time To Live  . . . . : 10397
    Data Length . . . . . : 4
    Section . . . . . . . : Additional
    A (Host) Record . . . : 192.168.1.xxxx  <---- IPv4 Gateway

 

Next up is the IPv6 binding:

Quote

attxxxxx.net
    ----------------------------------------
    Record Name . . . . . : attxxxxx.net
    Record Type . . . . . : 28
    Time To Live  . . . . : 10395
    Data Length . . . . . : 16
    Section . . . . . . . : Answer
    AAAA Record . . . . . : 2600:xxxx:xxxx:2420::1  <---- Local network assigned IPv6 DNS server

    Record Name . . . . . : attxxxxx.net
    Record Type . . . . . : 1
    Time To Live  . . . . : 10395
    Data Length . . . . . : 4
    Section . . . . . . . : Additional
    A (Host) Record . . . : 192.168.1.xxx <---- IPv4 Gateway

 

Err, what ..........? Well, not really. The only hardware based gateway on my router is an IPv4 one. Again, this is a Pace IPv4 router that AT&T hacked the firmware to support IPv6. I suspect this assignment of an IPv6 DNS server to an IPv4 gateway is what is causing Eset Network Inspector to go bonkers.

Edited September 26, 2021 by itman

[itman 1,659]

I guess I should give a complete network picture associated with the above posted network bindings. This being done so that Eset never attempts to perform Network Inspector activities in this situation.

At system restart time which is the only time Win 10 performs full network initialization activities, the router performs the following activities:

1. The router attempts to establish connectivity with a dedicated external AT&T IPv6 DHCP/DNS server with an IP addresses of 2600:xxxx:xxxx:2421::1. The important point to note at this point is that this IP address is not within my assigned fe80:: IPv6 gateway range of 2600:xxxx:xxxx:2420::/60 but within my allocated Ethernet range of 2600:xxxx:xxxx:2420::/64.

2. If connectivity can be established to the 2600:xxxx:xxxx:2421::1 server, this is assigned as Win 10 primary IPv6 DNS server. If this is activity is fully successful, I am assigned an IPv6 lease and my complete IPv6 network subnet is established. I will discuss later what happens if this activity is not successful.

3. Next, the router will try establish connectivity between the 2600:xxxx:xxxx:2421::1 external server and pre-allocated local subnet IPv6 DNS server 2600:xxxx:xxxx:2420::1 address. It does this via ICMPv6 with two necessary types being blocked by default Eset firewall walls upon installation.

This specific connectivity many times takes a minute or two after system startup to succeed. If successful, then the router assigns 2600:xxxx:xxxx:2420::1 as my Win 10 IPv6 secondary DNS server; a fact never recorded in Eset DNS server settings in regards to active Network connection status.

At this point my IPv6 network is fully initialized and operational.

In regards to point 3). connectivity failure that happens on rare occasions:

1. The router will establish limited IPv6 functionality. I have full external IPv6 connectivity but no IPv6 lease is issued nor is my IPv6 local network established. My local subnet DNS dedicated IPv6 address of 2600:xxxx:xxxx:2420::1 is assigned as  the primary IPv6 DNS server address. Eset Network Inspector totally borked this processing.

2. After the next system restart activity; usually upon resume from sleep after prior system sign-off, full IPv6 network initialization is completed with lease assigned and local subnet established. At this point, primary IPv6 DNS server address is 2600:xxxx:xxxx:2421::1 and secondary address is 2600:xxxx:xxxx:2420::1.

Edited September 26, 2021 by itman

[Marcos 5,074]

Disabling Network Inspector (previously known as Connected Home Monitor) resolves which of the issues?

And what issues are resolved by disabling the firewall?

 

Note that:
- CHM/NI has nothing to do with IPv6 communication according to the developers
- CHM/NI does not actively manipulate with network communication; it merely monitors the network to report devices and this has not changed since CHM was first added to ESET's products. The only difference are home/office networks when routers can be tested for vulnerabilities; however, this is only performed after clicking the "Scan your network" button.

[itman 1,659]

7 hours ago, Marcos said:

Disabling Network Inspector (previously known as Connected Home Monitor) resolves which of the issues?

Err, what? I posted previously that it resolved all my IPv6 connectivity issues and Eset recognizing that an IPv6 exists via establishment of an ekrn.exe connection monitoring UDPv6.

7 hours ago, Marcos said:

And what issues are resolved by disabling the firewall?

All of them. There never has been an issue with the Win 10 firewall properly recognizing my IPv6 connection or interfering with any aspect of it connectivity processing.

I have previously posted Eset needs to provide an option to only use its firewall for outbound network traffic of user custom rules. All other network traffic would be handled by the Win firewall.

7 hours ago, Marcos said:

Note that:
- CHM/NI has nothing to do with IPv6 communication according to the developers
- CHM/NI does not actively manipulate with network communication; it merely monitors the network to report devices and this has not changed since CHM was first added to ESET's products. The only difference are home/office networks when routers can be tested for vulnerabilities; however, this is only performed after clicking the "Scan your network" button.

This, I 100% disagree with. If everything I have posted in this thread hasn't  effectively communicated there is an issue with Network Inspector, nothing I posted further would do so and would be a waste of my time.