itman

Interesting discussion on AppNexus over at reddit.com: Appnexus sending malware/popups/redirects https://www.reddit.com/r/adops/comments/bchkqo/appnexus_sending_malwarepopupsredirects/ Appears the main issue is secure configuation of AppNexus by web site admins:

Appears you misunderstood what @Marcos posted. Anything detected malicious by EDTD would be immediately added to Eset's detection blacklist. Shortly thereafter when completed, a full signature detection would be pushed to all Eset installations.

Was the file restored?

Here's a thought. Does the location; i.e. full original directory path, where the PUA was originally detected still exist? Eset may have an issue with quarantine restoration if this is the case. -EDIT- Nope. Just tested this and Eset will recreate the required directory path if necessary.

I just restored a previous PUA detection from quarantine in EIS ver. 13.0.24. It restored w/o issue. It is restored to its original detected directory and is no longer present in Eset quarantine. So if this is an issue, it must be in Endpoint versions only which I somewhat doubt.

Since AT&T now owns AppNexus, will be interesting to see how this plays out if they take Eset to court over blocking of their ads.

https://www.theguardian.com/technology/2012/apr/23/adnxs-tracking-trackers-cookies-web-monitoring

Are you stating that the file upon being restored from quarantine later is again detected as a PUA and placed back into quarantine? If so, this is desired behavior since real-time protection re-scanned the file. The file needs to be excluded from real-time scanning either prior to restoration from quarantine or immediately thereafter.

This is the second recent posting that indicates there is an issue with the Eset firewall default setting for Protection type of new networks. That default setting is Use Windows setting. Review of all the OP's unblocked Network Wizard rules clearly indicate that the Win firewall Public profile was in effect. This in turn would have resulted in Eset not populating any local subnet addresses in the Trusted Zone. Now when Windows is installed, the Win firewall is set by default to the Home network profile. However, the user could have at some time later changed that to the Public profile prior to Eset installation. Then there is this "tidbit" I discovered on my Win 10 firewall Public profile setting. All the rules pertaining to Public profile use had been mysterious disabled somehow. I know I certainly did not do that. What I recommend is that Eset change the default Protection type of new networks setting to Ask User which I believe was the setting in previous Eset versions. Or, set the default setting to Home/Office profile which I believe the majority of Eset retail version users deploy.

Is there any reason why port 443 needs to be open on the WAN side of the router? I had a similar situation with my ISP, AT&T, Pace gateway. The "phony baloney" explanation given was they created a pinhole in the gateway firewall so they could access my TV desktop devices for maintenance purposes. Never worried about this since the pinhole only allowed access from their IP address. Well, recent gateway firewall log review showed know malicous IP addresses were accessing that pinhole. So I deleted the pinhole on the firewall and have had zip problems since.

I was thinking about that directory also since its a backup of prior OS version and is huge. You can always delete it if your upgrade is working trouble free. I believe Win will auto delete it after 10 days or so.

Also verify that only one Eset scan is running at an given time. There could be a bug and multiple scans are triggering and running at the same time.

Basically Idle-State scanning is continuous scanning. Granted it only runs when the device is idle. However when one scan ends, another starts immediately as I understand it: https://help.eset.com/ees/7/en-US/idh_config_idle_scan.html . Eset documentation is silent on this subject but this is how I inferred it works. In contrast a scheduled scan say set once a week runs just once during that weekly period. Therefore, I assume Idle-Time scanning is going to create a lot more log activity.

Do you have Idle-State scanning enabled?

I was eventually going to get to this. When the "Use Windows setting" is specified for an Eset network adapter connection, this will defer to the Win firewall network profile. If that profile is set to "Public," file sharing is disabled by default unless manually overridden as shown below: Don't know if you were doing something like this. If so, it might explain why file sharing worked for you with the Eset firewall disabled. Most likely what happened was when you disabled the Eset firewall, the Win firewall was also disabled which I believe is the case. As such, no firewall fire sharing restrictions were in place which is why you could perform file sharing. In any case, looks like your issue is resolved.