itman

It's adware/browser hijacker: https://www.precisesecurity.com/hijacker/remove-free-forms-now-freeformsnow-com

Suspect OP is referring to this product, Array AG Series SSL VPN Appliances. Ref.: https://www.arraynetworks.com/products-ssl-vpns-features.html

This is also worth a read and very much indicates that what Avast/AVG is doing is something Google doesn't approve of: https://techdows.com/2019/08/chrome-you-are-using-an-unsupported-environment-variable-sslkeylogfile.html

Interesting article. I checked the environment variables for FireFox; I don't use Chrome, and Eset does not use or need to use this baloney. Both Avast and Kaspersky were having issues with use of their root CA certificates in Chrome a while back to decrypt SSL/TLS traffic. Appears this is Avast's solution to the problem and a very insecure one at that.

The Eset firewall doesn't recognize the APIPA: https://www.pcmag.com/encyclopedia/term/37858/apipa assigned address range; i.e. 169.254.xxx.xxx. Personally, I think its a bug. In any case if the router or gateway is assigning APIPA addresses to devices, it is indicative of a problem with the DHCP server.

Based on what is posted in online help, the answer is no. Simply because EEI has no real-time interface as far as client to server communication goes: https://help.eset.com/eei/1/en-US/?rules_only_in_pdf.html

This query: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=brute+force+rdp on the Mitre web site yields 440 CVE's; all related to specific device or OS brute-force password vulnerabilities. Unfortunately, Mitre doesn't classify RDP overall as a vulnerability as I do.

To highlight the dangers of Google Play apps, Eset has its own detailed analysis on another commonly used app: https://www.welivesecurity.com/2019/08/22/first-spyware-android-ahmyth-google-play/

Per below, Eset's IDS RDP protection applies to known vulnerabilities; i.e. CVE's, in the protocol. It also should not be relied upon to the determent of Win OS patches. These should always be applied when Issued by Microsoft: https://help.eset.com/ees/7/en-US/idh_config_epfw_network_attack_protection.html?idh_config_epfw_advanced_settings.html

Kaspersky just published an analysis on CamScanner: https://securelist.com/dropper-in-google-play/92496/

Can't explain why this happened on your installations. I have been on this forum for 5 years and this is the first posting I can recollect this happening. From whom/where did you purchase your Eset licenses?

Try entering the TCP Port Scanning attack exception w/o an IP address. If the above doesn't work, you might have to exclude the displaying of IDS after detection alerts as shown in this Eset knowledge base article: http://support.eset.com/kb2951/ . As the article states, only the alerting is being disabled; not the IDS protections. Also assuming your external network gateway has like WAN side TCP port scanning detection capability and mitigation, you could just disable the Eset IDS TCP Port Scanning attack detection on the endpoints.

One thing that is unclear from the above postings. Did you set the setting shown in the below screen shot to 120?

You can downgrade to NOD32 w/o issue. Again, I could not duplicate this issue using EIS on Win 10. As such, I can only assume it has something to do with your Win 7 installation.

Since this server has Win 2012 installed on it, have you applied this OS patch: https://forum.eset.com/topic/20484-patch-new-wormable-vulnerabilities-in-remote-desktop-services-cve-2019-11811182/ ? -EDIT- Also the patch needs to be applied to all endpoint devices.

This first thing any attacker is going to scan for is open ports on the WAN side of the gateway.

https://malwaretips.com/blogs/remove-backdata-qq-com-qbix/

I have the setting disabled and have exported and imported Eset settings multiple times w/o it ever being reset to the on setting. Are these Eset installations "Trial" versions? That might explain this behavior.

Believe this will only work for South Africa. For Eset Vodacom users in other countries, it would be best to contact your local Eset customer support for the appropriate server name/port.

When Eset is installed, it overrides all Win inbound and outbound firewall processing. The only exception is Win inbound rules as long as that option remains enabled in the Eset firewall settings. As such, you will not receive any alerts from the Win firewall for outbound traffic regardless of the outbound monitoring setting. Pertaining to existing Win inbound firewall rules, only the existing allow rules are used. Any blocked inbound traffic will be handled by the Eset firewall and reflected by Eset alert.

One additional comment I forgot to make. Eset firewall rules are executed in top to bottom rule precedence; this was not always the case in earlier Eset versions. New rules are always added at the bottom of the existing rule set. As such, it is entirely possible a rule with higher precedence could be overriding or negating the activities of a lower precedence rule. In other words, firewall rules created in Interactive mode must be constantly reviewed in regards to the above actions. Another reason to keep the firewall in its default Automatic mode.

Good. Just make sure you haven't disabled the Win firewall service. At this point, I am clueless as to what is causing your Eset alert issue. Only thing I can think of is deleting all created user rules leaving only the Eset default ones; i.e. set the firewall settings to default settings by doing a Revert to default settings. Then switch the Eset firewall to Learning mode for a while to create rules for system processes and your apps. This can be sped up my performing a cold boot. Then opening up all your Internet use apps. Also force a Win Update check. Finally, switch back to Interactive mode and see if the issue has been resolved. Note: there is always a risk when when employing either firewall or HIPS learning mode. If there is some resident malware, it's actions will be auto allowed. Personally, I would just set the Eset firewall to its default Automatic mode which will allow all outbound traffic and be done with it. You can always create manual rules for select processes you feel outbound traffic should be monitored.

No. You should never disable the Win firewall by manual means; disabling its service, etc.. Eset at install time will configure it property to disable the necessary parts of it. Note that the Eset firewall will use the core components of the Win firewall. Hence, the "managed" reference.

What is possible and likely is the OP couldn't install Cyber Security Pro due to existing malware. He was charged for removal of that malware. Once Cyber Security Pro was installed, his e-mail got hosed; probable network connection related, and Eset fixed that w/o additional charge. Now his e-mail is again hosed again.

My son has bought Mac's for years. Based on his experience with them, I will say emphatically their hardware reliability is terrible; especially the HDDs. In fact, he is going the opposite direction and buying a MS Razor notebook.