itman

Appears to be a bug with the allow/deny alert in firewall Interactive mode. Did you submit a support ticket on it?

It would also help to narrow down the problem. Is the quick closing of alert messages only occurring for alerts when the firewall is in Interactive mode? For example when an Eset update status alert appears, does it remain on the desktop so a while.

Under the Alerts Window section, make sure the "Display Alerts" setting is enabled; i.e. check marked.

I am "throwing in the towel" on this issue. I see absolutely no evidence of port 993 IMAPS inbound e-mail scanning by Eset. At least I resolved that .tmp file issue I mentioned previously . I had a long time ago activated the anti-virus scanning option in Thunderbird under the assumption is was required for Eset to scan incoming e-mail. Well, it turns out that option only applies to POPS scanning as detailed in this article: https://fitzcarraldoblog.wordpress.com/2016/03/17/thunderbirds-defective-method-of-enabling-anti-virus-software-to-scan-incoming-pop3-e-mail-messages/ . For all I know, these are the files Eset was scanning it the past.

See this posting: https://forum.eset.com/topic/20056-eset-issue-with-sandboxie-persistent-holding-of-registry-keys/?do=findComment&comment=99558 . Appears module 1199 falls into the PMFBNC catagory; pretty much fixed but not completely. 🤨

@Marcos, I finally found out what the problem it. There is this great web site that will check how secure your e-mail provider servers are: https://www.checktls.com/ . You do have to provide your e-mail address however. Really impressed with AOL e-mail security; they scored 100% across the board. Now for the Eset e-mail scanning issue. As was shown in another thread where the poster was connecting to a Canadian gov. web site, AOL e-mail servers in the U.S. are using an additional root CA certificate in their chaining which defeats Eset MITM certificate use. So I guess I will have to wait till Eset figures out a way around this activity. I can only theorize why it worked for you in Slovakia is that the e-mail servers connected to from there are not employing the additional root CA certificate.

Below is the Eset online help reference to real-time scanning exclusions: Note what I underlined. A startup of a child process is not a file operation; it is an application operation. Therefore, the only way to exclude the child process from real-time scanning would be to do so by explicit full path entry of the process.

@Marcos , here's my latest theory. Eset e-mail processing is attempted to treat T-Bird e-mail as it does the other plug-in e-mail versions it supports, versus special casing it as done previously by just scanning IMAPS incoming port 993 traffic and deleting it if infected. As posted when it tries to process the e-mail under plug-in processing criteria, it gets "confused" and borks the processing.

I use normal password for authentication but did try online auth. No dice. First thing I always check. Did it. Still no dice. Here's what I have done: 1. Reinstall Thunderbird - no dice. 2. Reinstall EIS ver. 12.2.23 - no dice. There is something weird going on here. If I try to add the Eicar string to an e-mail and send it, Eset detects it via alert. However what it is detecting is the .tmp file T-bird creates: Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here 8/20/2019 2:15:52 PM;Real-time file system protection;file;C:\Users\XXXXX\AppData\Local\Temp\nsmail.tmp;Eicar test file;cleaned by deleting;XXXXXXX;Event occurred on a new file created by the application: C:\Program Files (x86)\Mozilla Thunderbird\thunderbird.exe (91C9ED6047E42F95EAFA27C66A75140A198128C0).;2481FB4EBCC232E0E061B79470B10A9EE1FAC07E;8/20/2019 2:15:51 PM Then it get weirder. The actual T-Bird .eml file is sitting in my user temp directory with the Eicar string removed. This same behavior manifests for incoming e-mail when a malicious attachment is opened, etc.. E-mail is sitting in the temp directory with an empty attachment. All this behavior clearly indicates Eset e-mail scanning is doing nothing and all detections are being made by the real-time scan engine at file creation time.

It doesn't work for AOL e-mail. I have a separate thread open on this issue. It appears to work for Gmail.

@Marcos , two more URLs to add to the blacklist: invoicesoftware360[.]xyz clipoffice[.]xyz Per Dr. Web. article: https://news.drweb.com/show/?i=13388&lng=en

Actually, Eset was detecting it at 2 PM EST at VT when I rechecked. So again, Kudos to Eset.

@Marcos , I am pretty sure there is an issue with Eset regular module updating. Last Friday evening , I inadvertently signed off my PC instead of shutting it down. As expected, Win 10 scheduled task fired off at 2 AM that woke up the PC to perform Win Updates. Shortly thereafter, Eset also downloaded a full module update as confirmed by corresponding Eset Event log entry. This is the first one received since upgrading to ver. 12.2.23 on 7/18. Also a bit strange this full module update occurred when I was not logged onto the PC. The ver. number for Cleaner module was still 1195. This morning I switched to pre-release updating and finally the Cleaner module was updated to ver. 1199 per below screen shot. Also a few other modules were updated that don't appear to be pre-release vers.; i.e. no "P" suffix appended to the end of the module number.

hxxp://nord-vpn.club/ * Edited to show correct reference link. Ref.: https://www.bleepingcomputer.com/news/security/hackers-use-fake-nordvpn-website-to-deliver-banking-trojan/

An absolutely fascinating article: https://krebsonsecurity.com/2019/08/the-rise-of-bulletproof-residential-networks/

This might also be related to "Great Firewall" activity: https://en.wikipedia.org/wiki/Great_Firewall

Hopefully the laptop you are referring to is a work issued and supported device. The quickest way to infect a corp. network is to allow employee personal devices to connect to it. Also make sure that what you are doing is allowed under your employer's IT policies.

@MarcosI set T-Bird e-mail to html format and it appears Eset is still not scanning incoming e-mail. I use AOL mail. IMAPS server name, imap.aol.com. Port 993. Really starting to appear to me that Eset can no longer perform MITM scanning with its root cert. for AOL mail.

Either post in English or re-post in the forum Slovak language section.

Follow the instructions given here: https://developers.google.com/speed/public-dns/docs/using . The details given for Windows 7 apply to all Windows desktop OS versions. Make sure you select Internet Protocol Version 4 (TCP/IPv4) setting assuming that is what your router supports.

On this forum's home page, scroll down and on the right hand side locate the box labeled "FAQ." Click on the link titled "How do I use Eset Log Collector."

Make sure the Eset firewall filtering mode is set to "Automatic." This will allow all outbound Internet traffic unless a specific manually created firewall exists to block the Internet outbound traffic. On this regard, make sure you haven't inadvertently created such a rule. For example, a rule present at the end of the existing rule set to block all outbound network traffic.

To begin with, @Marcos instructed you to add the IP address to the existing Trusted Zone category; not created a new zone category. Delete that remote access zone you created. The existing Eset firewall rules refer specifically to the predefined Zones. Next it appears you added the IPv4 address for your laptop? What you need to add to the Trusted Zone is the IPv4 address for each remote device you are using to remotely access the laptop. Note that any IPv4 address in the 192.168.xxx.xxx range is a dynamic assigned local network address. If you are trying to connect to another device on your local network via RDP, simply add its router DHCP assigned 192.168.xxx.xxx address to the Trusted zone and your done with any further modifications. One problem that can arise is that certain routers do not always assign the same local network IP address to a device. If this is your situation, the only secure solution is to ask your ISP for static fixed IP addresses for devices you wish to use for remote connection to the laptop. Many ISPs charge extra for static IP addresses. You then assign the static IP address to each remote network device and also add those IP addresses to Eset's Trusted Zone. If your trying to connect to the laptop from a device external to your local network, proceed as follows. To determine the external IPv4 address of the remote device, you will have to be logged on to it. Then in a browser use this URL, https://whatismyipaddress.com/ , to determine the device's external IPv4 addresses. Enter this IP address into Eset's Trusted Zone on the laptop. Important: Never ever enter an external IP address into Eset's Trusted zone unless the remote device is fully trusted such as your work computer's external IP address. Do not under any circumstances enter an IP address for any device that is publicly accessible such as a public library or hotel computer. Note that the above only works in the situation where you always connect remotely to the laptop from the same remote devices and the external network those devices use never changes. If you wish to do so from any remote device anywhere, obviously the above will not work. Since you are using the Win Pro version, verify if the Win firewall already has existing rules in place to allow inbound RDP traffic. If not, you will have to create these rules. Here's an article on how to do so: https://itstillworks.com/allow-tcp-port-3389-windows-firewall-22570.html . Note the reference at the end of the article about UDP rule activation. Since you can connect remotely to the laptop with the Eset firewall disabled, it appears the above Win firewall rules are already in place. Next deactivate the existing Eset RDP rules by performing the following. Under Eset GUI Firewall, click on Advanced -> Services. Remove the check mark for Allow remote desktop in the Trusted zone . Click on OK tab to save your changes. This will in turn deactivate corresponding Eset firewall RDP rules. By default and unless manually disabled, the Eset firewall will additionally use the Win firewall inbound rules. Note that I am not sure however this applies to inbound RDP traffic. Note that by using the Win firewall RDP protection, your laptop will be vulnerable to RDP password brute force and like attacks. It is therefore strongly advised you use Group Policy and establish a 3 password attempts with lockout thereafter policy setting on the laptop.

By standard user account, I assume you literally mean just that and not the default local admin account. This is done obviously for security reasons. You can alter standard user account privileges using Group Policy. See this article for reference: https://community.spiceworks.com/topic/333331-how-do-i-enable-remote-desktop-for-local-standard-user

You need to first establish what the IPv4 address of the remote device you are trying to connect to via RDP. Then add that IP address to Eset's Firewall -> Advanced -> Zones - edit. Then select Trusted Zone, then the Edit tab. Add the IPv4 IP address there. Click on the OK tab and any other OK tab shown to save your settings.