Jump to content

itman

Most Valued Members
  • Content Count

    6,955
  • Joined

  • Last visited

  • Days Won

    183

Everything posted by itman

  1. The problem is Eset SSL/TLS; i.e. HTTPS, protocol scanning uses the Windows Filtering Platform to do so. The installed version of Adguard also does the same and also by default, uses Windows Filtering Platform. That is where the conflict is and why WFP must be disabled in installed Adguard. This doesn't weaken Adguard's SSL/TLS protocol scanning in any way since it will install a network adapter mini-port filter driver instead to do this protocol scanning. In the browser add-on version of Adguard, it is examining HTTPS traffic after it has been processed by the browser. As such, it can't
  2. Yes. Most of the Adguard issues are embedded in other titled postings. Eset's forum search capability "sucks" when it comes to finding embedded search criteria by word or phase reference.
  3. There have been issues with installed AdGuard and Eset. Search the forum for those postings. The above said, it is recommended that the browser add-on version of AdGuard be used for maximum compatibility. If it is desired that the installed version of AdGuard be used, it is imperative that its Windows Filtering Platform option; i.e. WFP, be disabled: https://kb.adguard.com/en/windows/solving-problems/wfp-driver when using Eset.
  4. Right button mouse click on the file in Quarantine and select "Submit for analysis" per the below screen shot:
  5. My best guess is the following is the cause of this: https://help.eset.com/antitheft/en-US/issue_no_fakeuseraccount.html?issue_autologin_fake.html
  6. https://play.google.com/store/apps/details?id=com.lookout.stagefrightdetector&hl=en_US
  7. Continuing my last posting let's see if you can confirm my suspicions. Create an Allow firewall rule for C:\Program Files\ESET\ESET Security\ekrn.exe. Set direction to Both. Leave protocol at default TCP & UDP. Important - set logging level to Warning. Set remote port to 53. Finally, move this rule to the top of the rule set and save your changes. What this rule will do is create an Eset Network log entry every time Eset's ekrn.exe is performing DNS related activity. The next time your blocked DNS activity occurs, check if a Network log entry exists for the above created rule and
  8. First, do as @Marcos instructed in regards to Eset log collection data. Next, I just made a posting here: https://forum.eset.com/topic/25158-eset-monitoring-of-gateway-ipv4-dns-server-connection/ in regards to what appears to be Eset checking of gateway/router DNS server status. I am wondering if this activity might be in some way related to the mysterious DNS blocking issue you are having. Something along the line of this Eset status check fails for some reason resulting in Eset internally blocking outbound DNS traffic on your device.
  9. Refer to below screen shot. Seen these connections periodically. Given the low byte count, it appears to be some type of status check?
  10. Check mark the highlighted setting per below screenshot and see if it solves this issue:
  11. The above indicates that you have Internet connectivity since Eset apparently updated to ver. 13.3.16. Follow the steps given here: https://support.eset.com/en/kb2850-troubleshooting-for-modules-update-failed-message and see if this resolves the module update issue.
  12. On the device with the Viasat browser, Eset B&PP will default to using IE11 when the Windows default browser is set to an unsupported Eset browser. Assumed is the Windows default browser is set to Viasat browser. On the other device as long as the Windows default browser is set to a supported Eset browser, Eset B&PP will use that browser. Eset does not change the Windows default browser.
  13. Ping your router's IP address; e.g. ping 192.168.1.254. Does that work?
  14. Officially, Eset B&PP only supports the following browsers: https://support.eset.com/en/how-to-use-eset-banking-and-payment-protection If it worked previously with this Viasat browser, it was probably a "fluke."
  15. Appears FireFox ESR ver. 68+ default behavior is different than the retail ver.. On the retail 68+ ver., first successful attempt using Win root CA store will permanently set EnterpriseRoots to true value.
  16. Exactly. As I posted previously, you can't just set outbound block rules en-mass. This is a sure recipe for borking necessary Win outbound network traffic. Each block rule needs to be thoroughly tested for impact before permanently allowing it.
  17. Also it appears to be that what has been created is a plain Win Task Manager scheduled task. WMI based scheduled tasks are created as shown in this article: https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-tasks--scheduled-tasks . Also: https://docs.microsoft.com/en-us/windows/win32/wmisdk/connecting-to-wmi-remotely-starting-with-vista Just create an Eset firewall rule for svchost.exe schedule service not specifying a specific inbound port. Also remote IP address specification should be Trusted Zone only. Note there is a security vulnerability here. If an attacker can gain access
  18. A few comments about DNS firewall rules: 1. Eset's default DNS firewall allow both outbound TCP and UDP traffic port 53. 2. Windows uses mDNS outbound port 5353 as a fallback for DNS traffic. As such, this traffic should not be blocked.
  19. According to this: EEA Linux doesn't officially support Fedora: https://help.eset.com/eeau/7/en-US/system_requirements.html
  20. As I posted previously, because the problem is intermittent. As you stated: What I would recommend is setting the Eset firewall back to default values. This will reset Filtering mode back to Automatic which will allow all outbound traffic unless specifically blocked by an existing Eset default firewall rule. Also, only Eset default firewall rules would exist. At this point, you should have no further DNS issues. If you do, we can rule out Eset as the source. If you want to block some outbound network traffic, you can manual create a firewall rule to do so. I would do so caref
  21. It's not clear how you arrived at this conclusion. Does the problem disappear if Eset is uninstalled and you're only using the Windows firewall and Windows Defender?
  22. Here's an article on fixes for "DNS_PROBE_FINISHED_NXDOMAIN" issue: https://www.hostinger.com/tutorials/fix-dns_probe_finished_nxdomain . This would be indicative of an issue with your ISP provider and/or VPN provider if you are using a VPN. Note that if Eset was the cause, this behavior would be constant and not of a sporadic nature.
  23. Are you using the WMI scheduler to effectively hide a scheduled task within WMI? Ref.: https://nathangau.wordpress.com/2019/03/06/using-scom-to-detect-wmi-persistence-attempts/
  24. This has been known for some time: https://stackoverflow.com/questions/44246527/turn-wifi-off-using-python-on-windows-10 On the other hand, no Python installation is needed since netsh interface set interface name ....... works just fine from Admin level command prompt or via PowerShell.
×
×
  • Create New...