Windows Firewall Control (WFC) by BiniSoft.org

>>DomainProfile, StandardProfile, PublicProfile -> are protected by Secure Profile.
Disable Secure Profile and you can access these keys.
No, it does not work!

Does SYSTEM have Full Control rights ?
Yes




Are you able to delete a rule from WFwAS (wf.msc) ?
No = no access at all!
error: you do not have the authorizations etc..

What about WinFirewall service ?
Same as in your image.

 

It looks like the permissions are broken. Take ownership of the problematic registry key with RegOwnerShipEx and delete all keys or perform an operation with LiveCD. Then uninstall, clean up traces and clean install the WFC.

 

perhaps, but why?

 

So, WFwAS can't access these keys, Windows Firewall API can't either, WFC service can't either. Maybe a broken Windows Update ? Who knows.

 

A virus could have done it. Make a full backup of the registry (or system), reset the registry permissions. It will be like on a freshly installed Windows.
At first, you can reset permissions only for HKEY_LOCAL_MACHINE

 

Figured this! The "System" referred to is "NT Kernel and System (ntoskrnl)".

 

Hi,

Until July 21st I had WFC 5020 without any problem. Then I installed the 6300.
I had already read in this forum all the discussions about 'secure rules'. Obviously they were a source of problems. That's why I never tried to activate them. I let some time go by and thought that now I could afford to activate them safely.

After that, all the problems started.

It says in the manual: "Secure Profile:This feature is automatically disabled when Windows Firewall Control is uninstalled."
Unfortunately it didn't work. Also the reinstallation (from scratch) of the program didn't work either since it took over all the old settings (including the rules).

My current version of Windows is 1803
I hate continuous updates of W10 so I bought W10Pro.
As you can see below W10 is not happy and informs me that I am not up to date.



But at least W10 leaves me alone and does nothing behind my back.
I do a total overhaul of my entire PC about every 15/18 months during my holidays. I update all the programs ending with W10.
So, no, it's not a virus, it's not Windows, and it's not an alien!
It's a bug in WFC.
Having said that, I uninstalled WFC 6300 for the nth time. I took back an old registry (because I'm one of the cautious people who make regular backups of the registry...). And with some tinkering (not so simple!) I put back the 5020 version.

For your information.
To indicate the type of network you are connected to (private-VPN) the 5020 version works better than the 6300.
The 6300, as I pointed out a few days ago, puts me on a public network all the time (with or without VPN connection).

With the 5020 version the display is correct.
First picture without VPN: private network is shown on the top left corner.




And now with functional VPN: VPN is shown in the top left corner.




And when I stop the VPN, I go back to the situation of the first shot.

Finally, needless to say that I didn't try to enable the secure rules...
P. Brussels Belgium

 

This can be tested. Create a system backup and enable Secure Rules and Secure Profile. On all versions of WFC, I repeatedly enable/disable these functions, and nothing bad happened to the registry. v1809 x64.

 

Definitely. But I'm a (paying!) user, not a tester! Moreover everyone knows that a bug can very well appear on one system and not on another. So, as far as I'm concerned, the ball's in Alexandru's court!
By the way, thanks for the information about RegOwnerShipEx, it can always be useful on occasion.

 

Would it be possible to add the ability for search to also include the "Service" column values?

Also, I recall this was discussed before but can't find where -- how does one go about tracing down why a particular entry in the log was blocked when there is already an "Allow" rule for the particular program? For example, I'm getting blocked svchost.exe entries in my log, but I can't find any blocks for it in my rules.

 

You mentioned that you have used versions 5.0.2.0 and 6.3.0.0. With version 5.0.2.0 are you able to create/delete firewall rules, from WFC and from WFwAS ?

Secure Rules from version 5.1.0.0. to 5.3.1.0 were setting permissions on HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules If you have used only version 5.0.2.0 and 6.3.0.0 WFC did not touch this registry key permissions. I am not sure where or which is the bug in WFC since it could not have caused this problem.

Back to reported location that you can see in Main Panel, WFC does not put you in any location, it does not set any location. It just displays a value which is available in Windows Firewall API. Due to the fact that the returned value may not be accurate when multiple network adapters are available, in version 5.x.x.x WFC will report PRIVATE and in version 6.x.x.x it will report PUBLIC. Maybe the bug here is that in version 6.x.x.x it sohuld report Private instead of Public, but other than that, there is no functional problem with version 6.3.0.0.

 

Sure, I will extend the search to service column too.

Check this forum post which describes a way to discover which rule blocked a connection.

 

You mentioned that you have used versions 5.0.2.0 and 6.3.0.0. With version 5.0.2.0 are you able to create/delete firewall rules, from WFC and from WFwAS ?
>>yes, it's OK

Secure Rules from version 5.1.0.0. to 5.3.1.0 were setting permissions on HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules If you have used only version 5.0.2.0 and 6.3.0.0 WFC did not touch this registry key permissions. I am not sure where or which is the bug in WFC since it could not have caused this problem.
>>correct: only 5020 and 6300
...but I do not understand what you write. The key you mention (HKLM\SYSTEM\Curr.....rewallPolicy\FirewallRules) was the only one I could still access to with version 6300 (domain, public and standard profile were refused).

 

Small request. I've noticed you put the Start Menu shortcut outside the Programs folder. That's fine, since we can manually move it inside if preferable (and obviously that is what I do). Here's the problem though:

Windows is quite sensitive when the user edits/moves/deletes/adds shortcuts in the C:\ProgramData\Microsoft\Windows\Start Menu folder. Small things can break and they cannot be reverted. It is often related with folder security permissions etc.

Solution: create the WFC Start Menu shortcut in the C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs folder. Windows has no issues when the user edits shortcuts in there.

 

I am trying to say that I doubt that version 6.3.0.0 is the culprit for the problems that you encountered.

Yes, but with this approach the shortcut will be available only for the current user, not for all users. If you login with another user account, you will not have the shortcut and you may not be aware that the software is installed. This is why I use: C:\ProgramData\Microsoft\Windows\Start Menu. For a path like C:\ProgramData there should be no folder security permissions problems.

 

And that is indeed what I found on my system: after the version 6300 and after enabling the secure profile this key is the only one that I could still access to.
So it makes perfect sense.

On the other hand the 3 other keys* were blocked by the 6300 version when I checked 'secured profile'.
And unfortunately, unchecking or uninstalling WFC did not allow me to turn back the clock.

So WFC is at the root of this.
P.

* here they are:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\PublicProfile
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile

 

Fair enough. Several programs, during installation offer the option to install for all, or current user only. Perhaps you could consider that, if technically possible.

Unfortunately there are, even if they usually go unnoticed or cause no apparent trouble.

 

These keys were unavailable as a result of enabling Secure Profile, not Secure Rules.

 

This can be done, I will update the code to provide such option.

 

Right, lapsus corrected.

 

Thank you for this. Here's a minor issue. When I import user settings from a file, WFC 6.3.0.0 says it will restart to load the settings but it never does. It quits without restarting.

 

I noticed this a while ago but I forgot to fix it. I have to update the restart code with the one I used in Biniware Run, that code uses a different approach. I will fix this too. Thank you for mentioning it.

 

I'll make another small suggestion. When Secure Rules is turned on, we get a warning prompt which allows us to select No. The suggestion is to add a similar warning when Secure Rules is already turned on, and we switch from "Disable rules" to "Delete Rules" mode. This will remind the user that all currently disabled rules (the U - ones) will be deleted instantly.

Another approach to this, would be to just add the automatically disabled rules to the WFC Group right from the start. This would prevent these rules from getting deleted, and make the above warning unnecessary.

 

No, no, not that, it's just harmful. The user has a set of his rules, there are both enabled and disabled, and then a lot of rules that have come from nowhere will appear, and even an advanced user will not be able to understand whether these are his disabled rules, which he sometimes turns on, or those that have fallen from heaven.

 

I didn't say to create any extra rules. Nothing new will appear. From a quick test, it seems the "U - " rules WFC auto-creates are not included to the WFC group. My suggestion was to create them as part of the WFC group.