itman

Then and again, I wouldn't worry about those messages.

I believe I saw a similar message the last time I manually installed ver. 12; possibly after I imported my previously exported settings. Also, I periodically get these alerts when creating properly formatted manual rules on occasion. If the HIPS is functioning properly after Eset installation and/or your manual rules are properly created in the HIPS, I would just ignore these Eset messages.

https://www.actiontec.com/wp-content/uploads/2017/02/ActiontecGT784WNncsdatasheet.pdf It appears there is no user manual with detailed setting explanations. The best I could find is: https://setuprouter.com/router/actiontec/gt784wnv/manual-1341.pdf . I ran into the same issue with my AT&T provided router. I had to do web research to determine the actual mfg. of the router and determine their equivalent model number. With that information, I was able to download an user manual with settings options and details. Also there is a Verizon version of this router; if that is what you have. That version's firmware might have been modified to prevent end users from accessing the detailed protection settings options. -EDIT- Here's a web site that shows all setting screen shots for the Verizon model: https://setuprouter.com/router/actiontec/gt784wnv/screenshots.htm . The firewall has four settings; NAT, low, medium, and high. Click on the firewall screen shot for further details. Note the following. The default firewall security level is set to "Off". Suspect this results in only NAT being shown? I believe you may have disabled NAT in its stand-alone setting since it is not compatible with VPN? It appears the low - high firewall settings control what Win network protocols(services) and their corresponding ports are monitored. I don't believe if the firewall is off, it would affect SPI. However, disabling NAT would expose the actual sending port used by Windows. One thing I don't like is this router has the ability to support remote GUI andTelnet login to the router. I believe there have been multiple remote attack instances against Actiontec routers using this feature. Make sure it's preferably disabled or strong password used. In theory, a firewall with SPI and NAT should block most unwanted inbound external network traffic. Also, SPI only works for stateful protcols; namely TCP. UDP and ICMP for example are stateless protocols. Most routers will block incoming unsolicited ICMP pings by default. So UDP is the protocol that needs attention and can be blocked effectively by simply disabling unnecessary services that use it such as UPnP. If the router has default password of "Admin," change it to sometime more secure.

What is the router make and model number?

I agree with what @Marcos has posted. The report is a 6 page executive summary devoid of any specific details. Assuming the vendor used the Mitre matrix for exploit reference, they most likely used known POC exploits against known vulnerabilities. The best way to protect against vulnerabilities is applying in a timely fashion, vendor provided OS and app software patches/updates. Then there is the known and documented fact that many vulnerabilities are never exploited; only a small percentage are. I have strong suspicions that the exploits used in this test fall into the catagory of POC developed but never actually employed "in-the-wild." It is fairly obvious that Cymulate is recommending an "anti-exec" solution as far as the monitoring inbound external network traffic. This is only doable on a gateway device if the concern is willing to dedicate the system knowledgeable resources to monitor such activity. Based on postings on this forum, this certainly is not case frm the corp. sourced postings I have seen. BTW - this approach is certainly possible using custom Eset Firewall and HIPS rules. I for one, employ them.

You finally mentioned that you are using a VPN. As such, you are in essence bypassing the router's firewall. This is one reason I have never considered VPN use.

All that type stuff is already disabled. Do me a favor. Have someone look that that file and see what it contains. I have a hunch on what is going on and it involves Microsoft uploading data via ftp port 21. In the meantime, I am disabling WD periodic scanning and see it this stops Eset detecting this file.

This just started recently: Time;Module;Event;User 6/22/2019 4:35:46 PM;ESET Kernel;File 'ESET_5D0E710A.tis.log' was sent to ESET for analysis.;SYSTEM Time;Module;Event;User 6/27/2019 11:07:39 AM;ESET Kernel;File 'ESET_5D14C01A.tis.log' was sent to ESET for analysis.;SYSTEM Appears to occur approx. one minute after a signature update. Also and interestingly, this started after I enabled Windows Defender periodic scanning. I searched for this file via Win Explorer and it doesn't exist.

Check the router's firewall log. If it is stateful, you should see numerous inbound connection blocked log entries. You can also use the GRC Shields Up test here: https://www.grc.com/x/ne.dll?bh0bkyd2 to verify that all ports on the WAN side of the router are in a closed or stealth status. Stealth is the preferred status.

If you post the Cymulate report on a file sharing site, all on the forum could review it. Obviously, any device sensitive info should be removed/masked in the report. Note that only Eset moderators can view any forum attachments.

Let's back up a bit. The Eset firewall is stateful. It will block any inbound connection: 1. That is not associated with a previous outbound connection. 2. Where an explicit block rule exists to prevent the inbound connection. All the Network Troubleshooting Wizard shows in regards to the above no. 1). are connections that were blocked. There is no need to create additional user firewall rules to handle these stateful blocked inbound connections. This is why they are not logged , eventually time out, and no longer are displayed by the Wizard. There is also the risk that by manually creating firewall rules to block this activity, they are not properly created. Earlier versions of Eset did not have the Network Wizard. Hence the user was totally unaware of the above activity; just as if they they would be if using a router with a stateful firewall. As a rule, router firewalls log all blocked activity which allows the user to be aware of this activity for forensic purposes. On any given day, my router's firewall log contains dozens of blocked inbound connections; primarily port 23, Telnet, attempted access. The Network Wizard's primarily purpose in this context is to provide the ability for example, to inform and create an allow rule for some internal network legitimate inbound connection that was blocked for some reason. I assume Eset does not log stateful activity blocked inbound connections to prevent the Network Connections log from becoming too large. Another reason would be not to be "bombarded" in this forum with never ending questions about these firewall stateful blocked log enties. One suggestion to Eset you might request in like forum topic section is Eset provide an option for the Network Connection log where all Network Wizard blocked connections are logged. Similar to like HIPS logging capability, this option would be disabled by default.

One additional comment about Eset's Network Trouble Shooting Wizard. You should not be relying on this as your primary method to block unwanted inbound network traffic. The Wizard was actually designed primarily to automated firewall rule creation for internal apps that are being blocked for some reason. And as far as I am concerned, it creates very permissive rules. If your router does not employ a stateful firewall that will block any incoming unsolicited network traffic, you should seriously consider purchasing one that does. The router is the point where you want to block any unwanted inbound traffic.

Set the logging severity to "Warning" for all existing Eset firewall "Block" rules. This includes the default ones. This will result in a log entry always being created. Not that I am aware of. The HIPS has such capability; but only for blocked activity. On the other hand, Network Wizard shown "Blocked" activity is primarily a result of existing Eset firewall block rules. Hopefully by modifying logging severity as noted above, you will be provided with most of the detail you desire.

I believe what we are talking about here is the difference between machine learning and deep learning as noted in this article: https://www.zendesk.com/blog/machine-learning-and-deep-learning/ . Eset has employed machine learning for years. I assume with the inclusion of the "advanced machine learning" module, they are introducing established and proven AI algorithms into the Augur engine.

Then your slow web page loading issue is not due to Eset.

What browser/s is this slow loading activity occuring on?

Check this out as an alternative: https://community.spiceworks.com/topic/1403966-any-alternative-to-www-systemrequirementslab-com Alternatively, just override Eset's PUA detection. Just don't download anything from that web site. I believe this is the activity Eset is objecting to.

Hum ........ Not sure "You're out of the woods" on this browser and also Waterfox. To begin, other things need to be in place for Eset's SSL/TLS browser protcol scanning to work properly. The browser must either use the Windows root CA store where Eset's root certificate is installed by default at installation time, or Eset's root certificate must be added to the browser's root CA store. The later is done by Eset automatically for browser's it officially supports; Chrome, Firefox. IE11, Edge, and possibly Opera use the Win root CA store. The fact that you were able to pass the AMTSO phishing test by force enabling Eset SSL/TLS scanning for both, does not imply that it is functioning properly on both Brave and WaterFox.

Very strange behavior. I use the Network Trouble Shooting feature all the time. In fact, as recently as last weekend. This last instance was because of some old deeply embedded malware that appears to related to a drive I have Win 7 installed on. I haven't accessed this drive directly in years but running a WD periodic scan must have triggered it somehow. It was a pretty ugly event with my assumption that my Win 10 1809 build on the same device was totally trashed. Turns out luckily it wasn't. Appears the malware injected explorer.exe but couldn't run properly from there on Win 10. Anyway, prior to this I had created Eset firewall rules to monitor all outbound explorer.exe traffic. As I knew from years ago past experience with this malware, it attempted to connect to an IP address in Taiwan via port 21 that serves up the Conifiker worm of all things. Anyway when the Eset firewall alert appeared, I blocked it and had it create a firewall rule to block port 21 outbound traffic from explorer.exe. Thereafter, I monitored for any like outbound traffic using Eset's Network Wizard until the previous block connections shown timed out. From everything I have observed, Eset Network Troubleshooter is working w/o issue.

As far as what systemrequirementslab.com does: And one example of negative effects from using the site: Ref.: https://www.reddit.com/r/lowspecgamer/comments/8jbwex/can_you_run_it_a_site_that_will_check_you_systems/

As far as I am aware of Eset IS,SS, and NOD32 Web Access protection filters all port 80 and 443 communication. It is therefore not restricted by browser used. Proof of this can be had by opening the Web and Email section in Advanced setup option of the Eset GUI. Then open the List of SSL/TLS filtered applications section. You will observed a number of apps listed that are not browser related. What specific problems are you having with Anti-phishing protection?

Assuming you have configured IE11 for max. protections including and most important EPM, AppContainer will protect you against most browser based non-user initiated downloaded malware. There is also the "security through obscurity" factor. Since IE11 usage these days is in the single digit category, malware authors have turned their attention to Chrome and FireFox. Also although IE11 in its heyday topped the vulnerability charts, most of those have been resolved. Forget IE11 SmartScreen as a protection mechanism except for possibly unknown executables. I used IE11 for years and during that time had no more than two or three alerts from it. UAC at maximum level is your biggest native protection since it will prevent most but not all hidden privileged escalation attempts. Your biggest risks on these PCs are user initiated downloads and in-browser based Javascript malware such as coin miners. MSE PUA protection is for all practical purposes non-existent. Only recently in Windows Defender has it become reasonably effective and only if manually enabled. I certainly woundn't use these PCs for any e-commerce activities since AppContainer won't prevent IE11 banking Trojan web site injection. Finally, MSE lacking any web filtering capability will only increase the odds of being adversely impacted by web site/server in-browser based malware. -EDIT- Go to this web site using one of your Win7/IE11/MSE PCs and see what the results are in regards to coin miner protection: https://cryptojackingtest.com/ . Note: if SmartScreen blocks access to the site, that's a false detection.

👍

Site looks clean to me. I checked with URLVoid and did a new scan at Quttera.

Blanket statements like this are meaningless without a frame of reference. For example, none of those devices are used on a daily basis for Internet activities via browser. Do those devices employ supplemental security protection? If used for browser activities are those restricted to accessing know safe web sites? Etc., etc. Overall, consider yourself very lucky. There is no way that using Win 7 and MSE equates to the protection provided by Win 10 and Windows Defender.