itman
-
Posts
12,258 -
Joined
-
Last visited
-
Days Won
322
Posts posted by itman
-
-
@Marcos, attached is two Eset Network logs with advanced logging enabled. They reflect a connection to Windows Store which 100% causes the IDS behavior to occur. Note that the IDS exception I noted previously is in effect when this connection was made. Since one of the logs is a pcap one, this should be more than enough for Eset to figure out what is the issue with the IPv6 packets.
-
1 hour ago, Clark T said:
I have also incorrect ethernet packets. Starting day is the 10.04.2019 than everyday till now, like 4 to 6 entries. It is always the same source. Do we have to be worried? How should we handle this?
Read the entire thread. Temporary workaround posted. Use of which is at your discretion.
-
What I will say is based on the Eset diagnostic data provided, it really is difficult to determine what really is the problem. The only thing I know for sure based on what is occurring on my device is this is related to IPv6 communication.
If this issue is indeed a protocol "0" issue, IANA defines it as:
QuoteAssigned Internet Protocol Numbers
Decimal Keyword Protocol
0 HOPOPT IPv6 Hop-by-Hop Option Y [RFC8200]
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
Further reference to the RFC8200 publication yields:
Quote4.3. Hop-by-Hop Options Header
The Hop-by-Hop Options header is used to carry optional information
that may be examined and processed by every node along a packet's
delivery path. The Hop-by-Hop Options header is identified by a Next
Header value of 0 in the IPv6 header and has the following format:https://tools.ietf.org/html/rfc8200
And it is not normal to see this header in regards to IPv6 communication. Appears Microsoft has started using it however.
-
Quote
On the Windows 10 system I noticed that a new module is now listed: 'Deep Behavioral Inspection Support Module' (version 1068.1 / dated 03/21/2019).
I just upgraded to ver. 12.1.34. This module is still missing on my Win 10 x(64) 1809 build. Is this by design?
-
I am ready to give my full synopsis of the problem.
First, the prior screen shot of the Eset created IDS exception was missing a key element. So below is another screen shot showing that element:
Note the "0" reference in that rule. That means the exception was created for use of Port 0.
Next, an excerpt from the livewire.com link I posted previously in regards to Port 0 usage:
QuoteTo allocate its source port number, applications call TCP/IP network functions like bind() to request one. The application can supply a fixed (hard-coded) number to bind() if they prefer to request a specific number, but such a request can fail because some other application running on the system may currently be using it.
Alternatively, it can instead provide port 0 to bind() as its connection parameter. That triggers the operating system to automatically search for and return a suitable available port in the TCP/IP dynamic port number range.
Note that the application will not actually be granted port 0 but rather some other dynamic port. The advantage of this programming convention is efficiency. Instead of each application having to implement and run code for trying multiple ports until they obtain a valid one, apps can rely on the operating system to do so.
Unix, Windows, and other operating systems vary slightly in their handling of port 0, but the same general convention applies.
Finally, "putting it altogether."
It appears Microsoft has modified Win 10 1809, at least, to perform dynamic outbound port allocation to its own IPv6 and its proxy vendors; e.g. Akamai servers. It is rather obvious that Eset's IDS cannot handle any port 0 use and is unconditionally blocking such use. It also appears that its default IDS logic is set up to assume this must be inbound network traffic since the default IDS exception it creates specifies "In" at rule creation time.
-
1 minute ago, Purpleroses said:
But is it safe to do this and does Marco think it is alright to do this also? Plus it is not putting my computer at risk for creating a rule to IDS exception?
I already answered this question.
-
21 minutes ago, Purpleroses said:
So I have more then one unknown device blocked with incorrect ethernet packets. Do I have to click on unblock each one to create Unexpected Network Protocol" IDS exception.
Sorry. I forgot to mention that when you click on "Unblock" in the screen you show, it will only create an IDS exception for that given IP address shown.
Just click on one of the blocked communication events shown to create the IDS exception. Then besides editing the "Direction" to "Both" in the created IDS exception as previously posted , remove the IP address reference in the exception. In other words, the field should be blank. This will result in the IDS exception applying to all inbound and outbound traffic from the device.
Below is a screen shot of how the IDS exception should appear after all editing is completed:
-
More info on "borked" AV vendors as a result of last Tuesday's cumulative updates: https://www.bleepingcomputer.com/news/microsoft/microsofts-april-2019-updates-are-causing-windows-to-freeze/
-
3 minutes ago, Purpleroses said:
What I meant to say is that when I have the ethernet on I get unknown devices blocked and then it says incorrect ethernet packet in network protection logs.
If you click on the "Unblock" tab, Eset will create an "Unexpected Network Protocol" IDS exception.
The problem is it won't stop this activity since the exception rule created "Direction" mode specifies "In"; i.e. Inbound traffic. You will have to edit the IDS exception and change the "Direction" mode to "Both" as I previously posted here: https://forum.eset.com/topic/19197-incorrect-ethernet-packet/?do=findComment&comment=93725 .
-
Time to get things into a broader perspective.
Avast users on Win 7 are getting boot blue screens "up the wazoo" after the last cumulative update. Avira user systems have "slowed to a crawl" on both Win 7 and 10 after last cumulative update with symptoms similar to that reported in this this thread.
Perhaps Microsoft has implemented its "hardball" strategy against third party AV vendors?
-
26 minutes ago, Purpleroses said:
So if I don't make any changes to rules etc. Is it alright just to leave it blocking unknown devices? My computer is not at risk with this continuing to block unknown devices? I will just have tons of logs in my network protection.
As I stated previously if your network perimeter is protected with a router is stateful and employs NAT, DoS, and other like protections, Eset's protections in regards to unknown protocol detection is redundant.
-
13 minutes ago, itman said:
I am also going to experiment a bit with it today by enabling alerting for it in an attempt to isolate the source processes. That way and hopefully, a like exception could be created for those processes alone.
Problem is much worse than initially thought.
A check for Win Update status via Win 10 System Settings will trigger the "Unexpected Network Protocol" detection. The app though not shown is svchost.exe - windows update service, I believe.
-
37 minutes ago, Kurt said:
I need guidance what disabling the IDS affects and what is my risk if I leave it disabled.
Did you try my prior posted workaround? I haven't received a Network log entry since implementing it.
I am also going to experiment a bit with it today by enabling alerting for it in an attempt to isolate the source processes. That way and hopefully, a like exception could be created for those processes alone.
-
11 hours ago, Joliet_tech said:
Can you shine some light on your Port 0 usage comment. I am unaware of this in any regard. What is Port 0 or what does it refer too?
https://www.lifewire.com/port-0-in-tcp-and-udp-818145
Whereas the article states ISP's routinely block it, there is nothing to stop the ISP from using it as noted, to ping its own issued routers.
-
A while back I created a HIPS rule to block loading of lxcore.sys and lxss.sys drivers plus a HIPS rule to prevent enabling of Developer mode to prevent bashware.
-
I am also starting to lean toward Port 0 usage by Microsoft as the possible culprit.
This would not be the first instance I had in that regard using Eset. I believe in ver. 11, Eset changed something in this regard. My ISP for reasons beyond me does ICMPv6 pinging against my router; probably for connectivity purposes. My Win firewall event log was expanding a phenomenal rate from block activity related to this. That plus Eset's firewall wizard showed the same phenomenal counts. I resolved this one by just creating firewall rules to allow the activity for the IPv6 IP addresses involved.
-
Think I found a temporary solution until Eset has a fix for this.
Create an IDS "Unexpected Network Protocol" exception with no IP address specified and everything else set to "No." Note: "Direction" in the rule must be set to "Both."
Initial test was to connect to Win Store and no Network log entries were generated. Although security-wise this is not an ideal solution, it is far better than totally disabling IDS protection.
-
Appears it has something to do with IPv6 HTTPS to Microsoft direct or delegated servers. However, I have received the "Incorrect Ethernet Packet" block when doing some testing in regards to DNS checking on other sites. So the problem might have an Eset SLL protocol scanning element to it. Normal browser connections are completely unaffected by the issue for the most part.
-
Perhaps this is pertinent: https://dnsflagday.net/
-
@Marcos these are the IP addresses connections from Microsoft related Windows processes running at boot time. None are domain routable addresses from what I can determine:
2600:141f:8000:195::4106
Akamai Aggregate
location - United States
ptr - g2600-141f-8000-0195-0000-0000-0000-4106.deploy.static.akamaitechnologies.com2a01:111:200a:8::ff04 - Microsoft V6
2a01:111:f330:1790::a01 - Microsoft V6
-
18 minutes ago, Kurt said:
I think your initial thoughts that the router is bad may have some merit.
I don't believe that is the problem since multiple Eset users are having the issue.
Microsoft has changed something on at least Win 10 1809 in regards to its server communication and that is what Eset needs to concentrate on.
Also why when an IDS exception for an "Incorrect Ethernet Packet" log event is created, does Eset generate an "Unexpected Network Protocol" exception? Note the Eset definition for this:
QuoteDetected unexpected data in protocol – Improperly formatted ARP, DNS or ICMP echo packets. Or zero port in TCP/UDP/.
"My money" at this point is on Microsoft has changed something in their DNS protocol requests and Eset can't handle it.
-
A new update today.
Observed Eset Networking log activity at today's first cold boot. It's not just Win Store network activity causing the Eset IDS detection logging, but all outbound activity to Microsoft. For example, BackgroundTaskHost.exe, etc.. In total, 45 event log entries created.
I also did a hard reset on my router last night to no avail. All Eset has to do to duplicate this on a Win 10 1809 build is to reboot the device.
The question now is only Win 10 1809 affected or are prior Win 10 versions also?
-
I finally got "Incorrect Ethernet Packet" IDS exception to work. I had to set the Direction in the rule to "Both" and presently doing it by detected IP address; after verifying the IP address is associated with a Win Store connection.
Sure hope Eset figures out what the problem here is proto.
-EDIT- Forget any exceptions. When I set direction to Both I started seeing blocked Google server connections appearing whose IP addresses were never seen before.
Appears to me something serious is borked in IDS detection.
-
Damn it - another Eset bug.
I just noticed the IDS exception created by right clicking on the Network log entry is not the correct one! It created an "Unexpected Network Protocol" exception instead of an "Incorrect Ethernet Packet" exception. So you will have to manual delete the "Unexpected Network Protocol" exception and add an "Incorrect Ethernet Packet" exception.
Now see if the blocked network activity stops.
End of Support Win 7
in General Discussion
Posted · Edited by itman
I have to agree - Win 10 is much more a secure OS; especially with newer PC hardware.
There are a number of third party software that can "harness" Win 10 telemetry. I use O&O ShutUp10 for example.
Macs or Linux OS are being attacked as much as Windows OSes currently. So the perception they are more secure is pretty much a myth.
Perhaps you can find a Win 8.1 license, but that too will end in the near future.