itman 1,659 Posted April 12, 2019 Share Posted April 12, 2019 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 comment Share on other sites More sharing options...
itman 1,659 Posted April 12, 2019 Share Posted April 12, 2019 (edited) 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: 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 April 12, 2019 by itman Link to comment Share on other sites More sharing options...
Kurt 4 Posted April 12, 2019 Share Posted April 12, 2019 Thanks Itman. I will let you know the results of my testing of the IDS rule you recommended. Preliminary test are favorable. Link to comment Share on other sites More sharing options...
Kurt 4 Posted April 12, 2019 Share Posted April 12, 2019 4 hours ago, itman said: 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/ Nice find, and people were calling me crazy... Link to comment Share on other sites More sharing options...
Kurt 4 Posted April 12, 2019 Share Posted April 12, 2019 IDS exception rule works like a charm. Thank you ITman. Link to comment Share on other sites More sharing options...
itman 1,659 Posted April 12, 2019 Share Posted April 12, 2019 (edited) 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 April 12, 2019 by itman Link to comment Share on other sites More sharing options...
Clark T 3 Posted April 13, 2019 Share Posted April 13, 2019 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 comment Share on other sites More sharing options...
itman 1,659 Posted April 13, 2019 Share Posted April 13, 2019 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 comment Share on other sites More sharing options...
Clark T 3 Posted April 13, 2019 Share Posted April 13, 2019 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 comment Share on other sites More sharing options...
itman 1,659 Posted April 13, 2019 Share Posted April 13, 2019 (edited) @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 April 13, 2019 by itman Link to comment Share on other sites More sharing options...
itman 1,659 Posted April 13, 2019 Share Posted April 13, 2019 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 comment Share on other sites More sharing options...
itman 1,659 Posted April 14, 2019 Share Posted April 14, 2019 (edited) @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). https://help.eset.com/glossary/en-US/dos_attacks.html?tcp_desynchronization.html Edited April 14, 2019 by itman Link to comment Share on other sites More sharing options...
Administrators Marcos 5,074 Posted April 16, 2019 Administrators Share Posted April 16, 2019 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 comment Share on other sites More sharing options...
itman 1,659 Posted April 16, 2019 Share Posted April 16, 2019 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 comment Share on other sites More sharing options...
Purpleroses 21 Posted April 17, 2019 Author Share Posted April 17, 2019 How long do we stay on Pre-release updates before firewall module 1387 gets updated on normal update mode? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,074 Posted April 17, 2019 Administrators Share Posted April 17, 2019 We don't know yet. If you don't want to use pre-release updates, stay on regular updates and the module will be updated automatically after some time. Link to comment Share on other sites More sharing options...
Purpleroses 21 Posted April 20, 2019 Author Share Posted April 20, 2019 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 comment Share on other sites More sharing options...
itman 1,659 Posted April 20, 2019 Share Posted April 20, 2019 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 comment Share on other sites More sharing options...
Recommended Posts