itman
-
Posts
12,261 -
Joined
-
Last visited
-
Days Won
322
Posts posted by itman
-
-
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.
-
In regards to the HIPS rule it should begin with "User rule:" followed by some descriptive text. For example;
User rule: allow atbroker.exe startup
As far as the first rule screen goes:
Action = Allow
Operations affecting - checkmark "Applications"
Enabled - checkmark
Logging severity - Warning
Click on the "Next" tab
The next screen shown is titled "Source Applications"
In the drop down box select "All Applications"
Click on the "Next" tab
The next screen shown is titled "Application Operations"
Check mark "Start New Application"
Click on the "Next" tab
The next screen shown is titled "Applications"
Click on the "Add" tab
Enter both atbroker.exe files from windows system32 and syswow64 directories
Click on the "Finish" button
Click on any subsequently displayed "OK" button to save your newly created rule.
Verify your newly created HIPS rule conforms to the above settings by reopening the HIPS rule you just created.
-
I also noticed something else odd.
For some reason, "Filtering" was enabled on my Eset Network protection log. I know I didn't manually do so. I have since disabled it and will wait if that somehow has something to do with this unexpected protocol data issue.
-EDIT- Nope. No relation to this very odd Eset behavior.
-
32 minutes ago, Kurt said:
Can you share steps to accomplish this?
https://www.thewindowsclub.com/check-for-windows-store-app-updates
-EDIT- Another way to do so: https://support.microsoft.com/en-us/help/4026259/microsoft-store-check-updates-for-apps-and-games
-
16 minutes ago, Kurt said:
I got it, I am seeing the same additional log entries.
Forgot to mention that when the IDS exception is created, it will only create the exception for the IP address associated with the log event. Refer to the below screen shot. Open IDS Exceptions in the Network Attack Protection section of the Eset GUI . Then edit the existing exception removing the existing Remote IP address. This will then apply the exception to all IP addresses.
-
16 minutes ago, Kurt said:
I am also required to disable the IDS to allow access to my hosting machine for an internal app which I still have not received an answer to why that is happening.
Leave Firewall and IDS alone for the time being.
Refer to the below screen shot. Right click on one of the related Network log entries and select "Don't block similar events in the future." This should create an IDS exception for this activity. See if that stops your logging and corresponding network share performance issues. I am not going to do so presently since I not getting that many log entries; only for Win Store related activity.
-
This is definitely related to Win 10 Store updating. Connected to the Store and performed a manual update. Ended up with a bunch of new Eset Network Protection log entries.
-
Latest theory is Microsoft is using some new ICMPv6 Type Code that is not defined in the Eset default "Allow essential outgoing ICMPv6 communication" firewall rule.
In any case, starting to believe this is related to Eset firewall rules and not IDS.
Also the Eset blocking is bogus since its only supposed to manifest on inbound traffic which not the case per logged Eset Network entries.
-
Well, so much for the Win Store app update theory. None on 4/8 and first update on 4/9 was at 10:30 AM. As noted previously, the Ethernet packet log entries started at boot time on 4/9; i.e. approx. 8 AM.
However, it is obvious to me this issue is in regards to the servers hosting Win Store updates. Why is "my gut telling me" Microsoft is using some new tunneling protocol crap that Eset is "hiccupping" on.
-
A bit of an update.
Did the ipconfig /release6 and /renew6 bit which didn't help. What is a bit strange is /release6 or /release, did that also, did not terminate my network connection as always occurred in the past.
Upon signing on again after resume from standby mode had a slew of Network log entries, 19 in total, all attempting to connect to IP address, 2600:141f:8000:19c::4106 and Microsoft server associated IP addresses as stated previously. No further Ethernet packets log entries after that point so far. One of the first things Win 10 does at boot/resume time is dial out for Win Store updates. I suspect Microsoft pushed a borked or possibly malicious Store update yesterday or late evening before that. Now to find the "bad guy."
-
2 hours ago, Marcos said:
Obviously Avast is installed there and many of its drivers are running.
I assumed as much. OP probably forgot to uncheck the free version PUP of it when installing CCleaner. In any case, uninstalling Avast free will not remove oversee.exe. It has to be manually removed per the link I posted previously.
Also Eset should be flagging the CCleaner installer as a PUA.
-
Grrrr …..…… I read the log wrong.
In my case its outbound traffic being block. In other words, the source IP address is my ISP assigned IPv6 address and the target IP address is Akamai or Microsoft. Since no application is recorded in the Network log, it is almost impossible to what Is the source. Although it appears at this point, it is anything performing outbound IPv6 Internet traffic.
-
Some further info in my case.
All the inbound Akamai traffic is originating from this IP address, 2600:141f:8000:19c::4106. The other inbound traffic is from various Microsoft servers. All traffic is TCP and IPv6.
Definitely looks to me Microsoft is the culprit here.
-
17 minutes ago, Kurt said:
I need guidance what disabling the IDS affects and what is my risk if I leave it disabled.
That depends on what you have installed at the network perimeter. For example If you have a commercial grade router with a stateful firewall, NAT, DoS protection, etc. etc., then Eset IDS would only be protecting your internal network from internal attacks for the most part. On the other hand if you have an infected client/device on the network, you're SOL.
-
I just checked my Eset Networking Protection log; something I don't do regularly since its usually empty.
This incorrect ethernet packet business started at yesterday's cold boot at 8:29 AM EST. This was prior to the 1809 cumulative update which occurred in mid-afternoon. So it is not related to that. Also there was no Eset module update activity yesterday or prior to that for some time. Did received a module update this morning however which appears to have not resolved the issue.
Very strange activity here I must say.
-
Hum ……….. Since Eset is detecting oversee.exe connection to Google Analytics as Kryptik, a very nasty Trojan, and it appears the source of oversee.exe is CCleaner, are we possibly looking at another CCleaner supply chain server attack?
-
Appears Microsoft might have snuck in some hidden telemetry in the last 1809 cumulative update. Perhaps in regards to upcoming 1903 Feature upgrade?
-
I "spoke to soon." Just saw it on ver. 12.1.31 and appears related to an Akamai server connection:
-
The only thing I can think of that is triggered these alerts, is the Eset IDS Packet Inspection setting of :
QuoteVerification of incoming/outgoing TCP and UDP packets (checksum validation) – Select this option for testing purposes only. This functionality validates the checksum of incoming/outgoing TCP/UDP packets.
The problem is that this setting no longer exists in ver. 12.1.31. If one is using a prior ver. of Eset and this setting exists and is enabled, disable it and see if that resolves the alerts.
-
Suspect this might be related to oversee.exe. How to get rid off it is given in this article: https://askleo.com/how-do-i-get-rid-of-overseer-exe/
-
-
Post a screen shot of this "red notification from Eset." Suspect you are referring to the Eset alert shown?
Also check your Eset Detection and Filtered Web Sites logs for any entries related to this activity. If they exist, also post a screen shot of a log entry related to this activity.
-
Creation of any security software media should be done preferably on a "clean" PC. Simply because resident malware might try to interfere with either the creation of the media, or corrupt what is stored on the media.
Incorrect Ethernet Packet
in ESET Internet Security & ESET Smart Security Premium
Posted
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?