Jump to content

Recommended Posts

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.

Link to post
Share on other sites
  • Replies 92
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I am also having this issue and now I am unable to share files on the network.  This occurred after the most recent windows 10 update on 4-9-19.

Unblocking these "Incorrect ethernet packet" errors (and there were many, DNS, DHCP, Microsoft Publication Service (there were multiple of these), and  Akami) the network file share works, but they ar

Disabling Network Attack Protections (IDS) on the PC being accessed has addressed the issue of accessing the fileshare quickly and allowing access to the app hosting machine (screenshot reflects my PC

Posted Images

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:

Eset_Port_0.png.3080041cecc0be0d333a34fd4c744606.png

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:

Quote

To 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.

Edited by itman
Link to post
Share on other sites

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:

Quote

Assigned 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:

Quote

4.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.

Edited by itman
Link to post
Share on other sites

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?

Link to post
Share on other sites
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.

Link to post
Share on other sites
1 hour ago, itman said:

Read the entire thread. Temporary workaround posted. Use of which is at your discretion.

I don't know what the best is for me or if this has any effect on me.  I even don't know if this is dangerous or not.

I did read the entire thread.

Link to post
Share on other sites

@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.

Firewall_Logs.zip

Edited by itman
Link to post
Share on other sites

I also today checked out my router's firewall settings. It does have  an "Attack Detection" section in the advanced configuration section that detects among other things, invalid ICMP types/codes and drops the packet in such case. So I am confident that whatever Eset's IDS is "hiccupping" on, it is not ICMPv6 Type 0 packets since those have been blocked as standard practice for some time.

Link to post
Share on other sites

@Marcos Since this "Incorrect Ethernet Packet" IDS detection is being triggered on TCP packets, Eset should be reviewing TCP Flag setting on the packets from Microsoft associated servers. It may very well be that Microsoft has started using a new flag setting that Eset is erroneous detecting.

Another possible Eset misidentification:

Quote

TCP desynchronization

TCP desynchronization is a technique used in TCP Hijacking attacks. It is triggered by a process in which the sequential number in incoming packets differs from the expected sequential number. Packets with an unexpected sequential number are dismissed (or saved in the buffer storage, if they are present in the current communication window).

Edited by itman
Link to post
Share on other sites
  • Administrators

It turned out that this was already fixed in the firewall module 1387 which was put on pre-release update servers  about 2 weeks ago. You can switch to pre-release updates in the advanced update setup to get the latest modules instantly.

Link to post
Share on other sites
7 hours ago, Marcos said:

It turned out that this was already fixed in the firewall module 1387 which was put on pre-release update servers  about 2 weeks ago. You can switch to pre-release updates in the advanced update setup to get the latest modules instantly.

Verified via manually connection to Windows Store that the IDS "Incorrect Ethernet Packet" detection has been eliminated.

Also as a "bonus," I now have Eset deep behavior inspection module.

How about a "heads up" notification when firewall module 1387 is released so I can switch back to normal update mode.

Link to post
Share on other sites

Thank you everyone for the advice on this issue

I have stayed on regular updates and as of yesterday at 3pm something has changed because I don't get any blocked unknown devices with incorrect ethernet packet. I have not made any changes to Eset . No Eset has not updated the firewall to 1387 I'm at 1386.4. 

Link to post
Share on other sites
6 minutes ago, Purpleroses said:

I have stayed on regular updates and as of yesterday at 3pm something has changed because I don't get any blocked unknown devices with incorrect ethernet packet. I have not made any changes to Eset . No Eset has not updated the firewall to 1387 I'm at 1386.4. 

Someone over at wilderssecurity.com commented likewise. Appears Eset issued a patched ver. to the firewall module dated 4/18/2019.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...