This project has moved. For the latest updates, please go here.
6
Vote

Notifications keep popping up for allowed programs - leading to many duplicate rules

description

First of all, I love the program so far. The method in which it operates is pure genius, and this nice lean piece of software is very much needed.

I am having one issue though where programs which are fully allowed, keep popping up notices, and when I allow them, it just creates duplicate rules.

For example, firefox keeps popping up over and over, and I keep clicking allow. Now I have about 30 duplicate allow rules for it, and it still pops up. I even manually created rules for firefox in windows firewall, but it doesn't help.

I have full allow rules for firefox with multiple path names
C:\program files (x86)\mozilla firefox\firefox.exe
%ProgramFiles% (x86)\Mozilla Firefox\firefox.exe
but no luck, firefox notifications keep popping up.

comments

Marnes wrote Feb 4, 2015 at 3:42 PM

I get this same thing for the IP Helper service, for example when torrenting. Even if I whitelist svchost.exe purely by itself, it keeps popping up for IP Helper.

GmCity wrote Feb 5, 2015 at 8:23 PM

Perhaps it might be plugins/extensions in Firefox causing the repeat popups, try temporally disabling or removing any & all of the plugin files that could try to update or connect

Marnes wrote Feb 5, 2015 at 8:40 PM

It only happens with Qbt in my case, Firefox being open or not.

Marnes wrote Feb 7, 2015 at 12:44 PM

Ah, sorry, Qbt = Qbittorrent.

It actually kind of makes sense for torrenting to trigger it in my case, depending on what the problem is. I imagine the popup comes up for each individual peer Qbt tries to connect to, each time trying to make a new connection with the same variables except the destination IP. Maybe the destination IP being different every time causes the popup to come back?

pvx wrote Mar 14, 2015 at 6:43 PM

I noticed that sometimes WFNotifier asks for the short path version of an executable that it already has stored as rule. It does not help to reapply that rule, it keeps popping up.
Maybe this is related or a similar issue.

Then again I noticed when WFN goes "insane" and ask for the same rule over and over again a restart of the machine helps.

wfnuserx wrote Mar 25, 2016 at 9:36 PM

For me too, any click on allow or block will create a duplicate rule.
This is fair to avoid race conditions (reading the rules before trying to add one is not atomic).
What is faulty is the repeating popups. Obviously something wrongs in the detection code.

A few items to check:
a) case sensitivity of paths and service names. A number of times I saw lowercase, all capps, and 1st letter cap.
b) variables in the paths. I have seen svchost.exe with various case sensitivity but also with %systemroot% and %systemdrive%, which could require resolving to a string, to be then compared with case insentive tests.
c) I suspect UDP detection is not working too well, but that only because I get far too much of those popups from svchost.exe, which is deeply involved in discovery, DNS and LLMNR stuff upon cable connection. I also get plenty of popups for tcp port 80 and 443 for svchost.exe for collections of services... and that is the main case that pops up all the time...
d) I wonder how the detection code understand the origin of the blocked connection, if it came from the WSH (windows service hardening) rules... If such rule blocked a connection, no popup should occur.
e) I also wonder about the notifier.exe commandline args; could there be clipping of strings to a max length? loosing precious info to perform accurate matching?

wrote Mar 25, 2016 at 9:38 PM

wfnuserx wrote Mar 25, 2016 at 11:02 PM

After reading a bit and on the events and the hookup of the notifier.exe in the "task scheduler", you can figure how this works. Here is my understanding.

The trigger is the event id 5157, log level error or info. That can be seen on the event filter "xml" when you examine the trigger details. The event model is passed partially to the command line of notifier.exe. This includes remote ip and ports, process path, protocol, process id and thread id. Nothing more....

Now, to identify a simple process, this is fine. The notifier check the rule set for a matching rule and if so, simply shuts up. If not, the default rule must have denied connection; do popup.

But to identify a service, the information is not in the event. The notifier.exe is racing to capture the thread of the process causing the event, but after the fact. This could lead to inaccurate identification of service because the thread could be gone, or somewhere else. This explain why WFN would have erratic reports of the initiating service of blocked connections.

I think the bug stems from the innacurate service information. How could the rule set be searched for a service name that is not the right one? For example, this afternoon, I knew some connection was made by the BITS service (as seen on port 80 with wireshark as per the revealed user-agent Microsoft BITS/7.8 and destination IP involved) but I never saw it in my detected service(s). It's usually a list of a dozen other services... It's just impossible that more than one service be used on a given connection, but that's how WFN reports it so you can make a choice of the most likely service involved. Unfortunately, the one service I should allow is not even listed, so the popup can only add a rule for the wrong service, and the blocking continues. At least that's how I understand it.

Now, factor in the dozens of svchost rules from the hidden WSH (windows service hardening) rules and that makes it only a tiny bit more likely to find a rule that matches the wrong service detected.

I think WFN will not ever get that solved. Not as a passive log watcher like it currently is anyway. The best you can do is train your FW to allow svchost according to the protocol, port and ips used. If there is no event 5157, there cannot be any popup.

If WFN wants to detect services correctly, it will have to be a real firewall. Perhaps not intending to veto any connection (to remain light and non-interfering), but at least capture the proper origin.

I really wish we will hear from the authors...
I will be pleased to read any correction to my understanding.

DanielPharos wrote May 25, 2016 at 7:15 AM

Sorry for the late response.

wfnuserx, your analysis seems very promising. I'll have to investigate the details, but I won't be surprised if your assessment of the situation is 100% accurate. In which case WFN indeed will never be able to handle this situation correctly (without becoming a full-blown firewall).

wrote May 25, 2016 at 7:17 AM

rotorb wrote Mar 15 at 10:36 PM

I'm having this issue with the latest version. Is there any way to manually define an allow rule for c:\program files\bonjour\mdnsresponder.exe ?

wrote Mar 15 at 10:36 PM

DanielPharos wrote Mar 16 at 6:00 PM