Jump to content

itman

Most Valued Members
  • Content Count

    8,042
  • Joined

  • Last visited

  • Days Won

    195

Everything posted by itman

  1. Background data on SDK Labs here: http://www.skdlabs.com/html/english/ . Of note is they are an AMTSO member which I verified on the AMTSO web site. Also of interest is SDK Labs state that Eset in a test participant. My best guess to Eset's poor performance is they are located in Peoples Republic of China. As such, their malware samples might reflect attacks prevalent within China. There have been past multiple discussions on that regard to Eset's detections of those. What I believe is the issue is malware identification data for in-China distributed malware is limited. Appears
  2. The only time I have observed the desktop toolbar network behavior you described is when there is a network connectivity issue; i.e. no IPv4 connection established. I have never observed it in regards to network adapter entering sleep mode while desktop was active. I have seen the "globe" status appear on the icon after resume from PC sleep mode on the Win 10 sign on screen. It immediately disappears on the subsequent password entry screen. The only service related directly to Win Updating is wuauserv of those you posted. Again, I can't see in any way Eset changing that or any other of
  3. Below are my network adapter power settings: Also, Win 10 PCI-E LInk State Power Management setting is set to Moderate. I have no network adapter issues with Eset upon resume from sleep mode or otherwise. Eset queries the Win Update Catalog to determine if applicable Win OS updates are available. If such exist, it just shows in the GUI that this status exists. Eset does not affect current Win Update OS settings in any way. If this Eset option is set to "No Updates," it should not be displaying in the Eset GUI that Win Updates are available.
  4. If you are not using Eset's Anti-Theft protection, it can be permanently disabled per below screen shot. This should resolve this issue.
  5. First, verify that you have properly set up your router to perform Minecraft Server port forwarding properly. Below are a couple of references on how to do this. https://www.informit.com/articles/article.aspx?p=2424329&seqNum=4 https://helpforum.sky.com/t5/Archive/TRYING-TO-CREATE-A-MINECRAFT-SERVER-FIREWALL-RULES-HELP/td-p/3315579
  6. One possibility is the Win 10 firewall is either disabled or not starting automatically. By default, the Eset firewall will also use the Win firewall inbound rules. This is required for Win apps including Store to establish Internet connectivity. It is possible that for some reason the Eset installation is not setting up the Win firewall to run properly concurrently with its firewall. With Eset Internet Security installed, verify that the Win firewall service is not disabled, is running, and set to run automatically per the below screen shot:
  7. My best guess is this Eset firewall profile was created as a result of Xbox activity. This will be a bit of an involved posting. By default, Eset uses the Win inbound firewall rules unless a specific Eset firewall inbound firewall rule exists that block the activity. Also Eset has a default rule to allow all IPv6 tunnel activity. Next is the Win inbound firewall rule in regards to Teredo allows all UDP traffic originating from the Win iphelper service. A while back, I had an issue with outbound Xbox traffic occurring despite the fact I never used the app or had a Xbox controller
  8. FYI. I had a "brain cramp" past moment. Forgot there is an easy way to check this issue. Shortly after noon today, I checked Eset's scheduled update scan for time of next update check. It was set to 12:22 PM EST. I then put my Win 10 installation in to lock screen mode. Later returned to the PC around 2 PM and checked for time of last update check. It was 12:52 PM. Again note that I do update checking at 30 min. intervals. Also PC went into sleep mode shortly after 1 PM. Hence, no further update checks after 12:52 PM. Bottom line is Eset does indeed check for updates while in lo
  9. It is unclear which Eset product you are referring to. Re-post in the the appropriate Eset Business User Products section of the forum for better exposure and response.
  10. Refer to this: https://support.eset.com/en/kb2850-troubleshooting-for-modules-update-failed-message for possible mitigations to the issue.
  11. As far as I am aware of, there are no relationships between trial and paid Eset licenses. As such, Eset paid license duration is for the duration purchased. Trial license days are not added to a paid license duration. Further if you purchase an Eset license from any source other than Eset directly or an authorized retailer, remaining existing Eset license days are not added to the new license.
  12. All the svchost.exe connections look legit except to port 8000. Review this: https://www.speedguide.net/port.php?port=8000 and determine if you are using any legit apps listed in the article. What you can do is create an Eset firewall rule to block all inbound and outbound network traffic for C:\Windows\System32\svchost.exe for protocol UDP remote port 8000. Enable alerting and logging for the rule. This rule will at least notify you of this activity from which you might be able to determine the source app for the activity.
  13. This was explained previously. You will have to bypass the router in able to test Eset firewall settings. This is usually done by temporarily disabling the router's firewall. Again, the Shields Up test is testing your router's settings when one is present. The test cannot bypass the router nor will the echo request transaction be forwarded by the router to your device. The router is sending the echo response to the GRC web site server and this is what is shown in the test result. If you don't believe, search the web on this test. There are multiple postings attesting to what I h
  14. You have to enable the "Show built in (predefined) rules" setting to view Eset firewall default rules.
  15. The main disadvantage is Microsoft created Code Intregrity Guard in Win 10 to prevent malicous code injection into the process:
  16. FYI. Below is a screen shot of Eset firewall default rules in regards to IPv4 ICMP. As shown, it doesn't not allow outbound echo response traffic outside of the local subnet:
  17. In the Cisco WSA documentation in regards to HTTPS proxy configuration, it is stated that transparent proxy mode was provided in the instance where individual client devices are not configured to use a proxy. It was already stated in this thread that this installation does not configure individual client devices to use a proxy. As such, I believe setting Cisco WSA HTTPS proxy to transparent mode would be the solution to this issue. Broadcom has a short article of the difference between explicit and transparent proxies: https://knowledge.broadcom.com/external/article/166958/the-difference
  18. You might want to explore Chrome Incognito mode: https://www.lifewire.com/incognito-mode-google-chrome-4103635
  19. This is one of the newer STOP ransomware variants. Doubtful that files can be decrypted.
  20. Think I found the issue and it confirms my earlier suspicions. The Cisco WSA has two types of HTTPS proxies; explicit and transparent. If an explicit proxy is setup, everything being routed to/from the HTTPS proxy is using port 80: If a transparent HTTPS proxy is set up, everything being routed to/from the HTTPS proxy is using expected HTTPS formatted port 443 network traffic: My guess is if a transparent proxy was used, there would be no issues with Eset since it would be examining expected port 443 HTTPS traffic. Ref.: https://www.cisco.com/c/en/us/produc
  21. This posting might be informative as to why you are seeing port specification attached to URL's : https://stackoverflow.com/questions/50888270/why-do-we-need-to-specify-a-port-number-while-using-http-protocol . This lends further credence that it is originating from the proxy servers you have deployed. There is also a way to verify all this. As a test, configure Eset proxy settings on a client device used at home to match those for the Cisco WSA proxy. When this device is used on the corporate network, does Eset perform as expected in regards to logged and blocked Web Content HTTPS browse
  22. No. Only Eset moderators can view forum attachments. You will have to upload the video to a file sharing site and post the link for me to access it.
  23. I assume Chrome works similar to FireFox in this regard. Eset's B&PP creates a new profile in Firefox and uses that profile when B&PP is active. As such, none of your custom settings made to Firefox used during normal browser mode are deployed. As noted, you will have to duplicate your normal Chrome browser mode settings to the instance opened in B&PP mode. Also in this mode, browser extensions are disabled by default for security reasons.
  24. Let's get back to this. First of note is none of your client devices have Eset proxy settings enabled and configured. As such, Eset is unaware that a proxy is being deployed on the corporate network. It appears the default proxy port for the Cisco WSA appliance is port 80; the same as Windows uses. What appears to be happening is the Cisco WSA is forwarding all incoming network traffic using its port 80; i.e. HTTP, with a port specification. The port specification in the case of HTTPS traffic would be 443. Hence, Eset is just reporting in the log entry the network traffic as it recei
×
×
  • Create New...