Windows Firewall Control (WFC) by BiniSoft.org

This is the same on Home and Pro since Windows Vista. The OS sees these features enabled or disabled based on the presence of certain group names. It is not really the display name, but a resource name: @FirewallAPI.dll,-28502 (File and Printer Sharing), @FirewallAPI.dll,-32752 (Network Discovery). If your rules set doesn't have the expected firewall rules in the group names @FirewallAPI.dll,-28502 and @FirewallAPI.dll,-32752 then these functionalities will appear as disabled in the OS. If you need these functionalities it is better to leave the rules from these two group names untouched. If you want to use Secure Rules feature you also need to add "Network Discovery" and "File and Printer Sharing" in the Authorized groups list to leave these rules alone.

 

Thanks for the info, looks like as I suspected I'll have to add those Authorized groups. Damn. Oh well, life goes on.

I know it's gonna be hard to believe, and I can't even prove it now since I've formatted, but my previous install was LTSC 2019 for about a year, upgraded LTSC 2021 over the top of it later, and then forcefully stopped Windows updates after the first day. I was running the WFC Recommended rules and Network Discovery etc was working. Now you have me wondering how I managed to get around that lol. Kind Regards!

 

WFC recommended rules are a subset of the Windows Firewall default set of rules. Network Discovery works with WFC recommended rules only for connecting to a remote device in your LAN by using the IP address. If you need to use the hostname or other advanced scenarios, you need all the rules from Network Discovery group from Windows Firewall default set of rules.

 

There's something wrong about rule creation or naming in 6.14.0.0, i first noticed that there's new Learning Mode rules with the Group as the Name, the group name is duplicated as the actual Name of the rule. ALL of these, this far, are some Apps rules, like:
@{Microsoft.StorePurchaseApp_22503.1401.3.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.StorePurchaseApp/Resources/DisplayTitle}

I have Secure Rules on with Disable unauthorized rules.

This far, manually changing the rule name was enough to turn it into a proper rule. Until I came across with the exact above rule, when I renamed the Name to:
"- UPDATE ENABLE ALLOW Z @{Microsoft.StorePurchaseApp_22503.1401.3.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.StorePurchaseApp/Resources/DisplayTitle}" (without quotes) it simply DISAPPEARED from WFC rules list. Refreshed, sorted, searched -- it's not there. There are other rules with the same naming scheme, - comes before some other letters in sorting, so it can't be that.

But it still does exist, and WF.MSC shows it. It's kind of a huge problem now, because it's got a Group set, and WF.MSC cannot edit the rule if it has a Group set. Lucky i can still Enable/Disable the rule from WF.MSC but yeah, this is kinda bad.

 

Indeed, this setting does not work as expected.



It does nothing. Once Secure Rules is enabled, Windows Store rules are processed and disabled or deleted instead of being skipped. I checked on Github the history of the line of code that is responsible for this and it is like this since version 6.0.2.0 release in March 2019. I guess, this never worked in the past 6 years and nobody discovered it until now? Yes, I installed version 6.1.0.0 from January 2020 and the functionality is broken.

I identified the problem and a new WFC release will be published soon.

But before this, Learning Mode rules are always created in Windows Firewall Control group name. Windows Store apps rules are created by their installer when they are installed. Windows Store rules are not detected by their name anymore, but after some properties which are not exposed in WFC. To enable a disabled rule by Secure Rules logic, it must be placed in one of the Authorized groups names.

 

Windows Firewall Control v.6.15

Change log:
- Fixed: "Allow Windows Store rules" checkbox from Secure Rules does not work.
- Improved: The logic that checks if a file is digitally signed or not was improved for certain processes.
- Improved: In Rules Panel it is now possible to use "Authorize group" option on multiple rules at once instead of just one by one.

I also used Biniware Translation Tool to update all included translation files.

Download location: https://binisoft.org/download/wfc6setup.exe
SHA256: 91636648ae9ad7fa2e82306a65e723920f8599999792ddbd3a610f20bfbc873b
SHA512: 2d85b85894c123a2a57f92fc968db3142568a646475ea9b378c5ae4ecfa7553f6fc2ce42c7b7193c14917758c2d2e2785daf0444ace0cec40ede42c2a0ba47dc

Thank you for your feedback and your support,
Alexandru Dicu

 

Hello,
I'm trying to update from v 6.14 to v 6.15 by using manual check for new version on WFC settings but I can't update because I get the following error. I don't get any UAC prompt. I never had this issue with the previous updates of Windows Firewall Control.

 

I can not reproduce your scenario, not even by disabling UAC entirely and trying from a standard user account. Maybe a machine restart fixes the problem.

The installer wfc6setup.exe will spawn another instance of itself with the -update parameter. This is when you see the UAC prompt. Try to manually download the installer from https://binisoft.org/download/wfc6setup.exe and in an elevated CMD window, execute: wfc6setup.exe -update

This should update your WFC installation to the latest version. It should work because you already elevated cmd.exe. Please let me know if this works.

 

The "Windows Store" group contains an inbound and an outbound rule, the in bound rule has "Allow edge traversal"
These rules have no limitations and here is no program assigned to these rules:

Code:

Get-NetFirewallRule -Group "Microsoft Store" | Get-NetFirewallApplicationFilter

Program : Any
Package :

Program : Any
Package :

This looks as if these two rules allow everything except block rules. But that's not the case, WFC asks if an app without rule wants internet access.
Same is with e.g. "Lenovo Commercial Vantage".
Does

Code:

Get-NetFirewallApplicationFilter

not retrieve Windows apps? Is there a different powershell command for these? I couldn't find anything related on the Internet.

 

Many thanks for the latest update.

Minor suggestion: how about including the WFC version in the Tray icon ToolTip?

 

These are a special kind of firewall rules. In WF.msc you can see they are different, they are defined for a specific SID in the Local User Owner column. Even if the Program is set to Any, they apply to a specific SID only in a specific context only. To me they look like an app packages SID. If this specific package tries to connect, it is allowed.

 

Sure, in the next version.

 

Here the column shows the local user with admin rights.
Any idea how to find out more about the rule with PowerShell?

 

The machine restart didn't solve the issue but executing wfc6setup.exe -update in admin command prompt did it without any UAC prompt so thank you very much for your help.
Anyway I discovered that, unlike other folders on my system, I can't modify the content of C:\Program Files\Malwarebytes\Windows Firewall Control because when I tried to move wfc6setup.exe to that folder I got the message that the access to that destination folder is denied and that for performing the operation an authorization is needed. The only options were to retry (it didn't work) or cancel. Probably that was the reason of my previous failed attemps to update WFC. As I wrote above I don't get this message when copying or moving files to other folders and I think I never got this message before. Furthermore I'm running the file manager FreeCommander XE as Admin. Is this a normal behavior ?

[edit] The same behavior occurs when copying or moving files to C:\Program Files\Malwarebytes or C:\Program Files\Malwarebytes\Anti-Malware so the issue is restricted to these folders only. I never had any issue to update Windows Firewall Control before today so could a recent Malwarebytes Anti-Malware update to have modified some properties for C:\Program Files\Malwarebytes and its subfolders, maybe for protecting them from malware attacks ? However, if that is the case, I prefer to leave things as they are since the method to update Windows Firewall Control via command prompt works well.

 

Windows Firewall Control v.6.16

Change log:
- Fixed: The installer is vulnerable to local privilege escalation. (A script combined with a hacker tool could gain elevated privileges during installation from a non elevated process. Not anymore.)
- Fixed: When showing duplicate rules in Rules Panel, all Windows Store apps rules are reported as duplicates even if they are not.
- Improved: After checking for updates, if there is a new update, sometimes the new installer does not launch. (About this one, the logic will apply starting with the next releases since only version 6.16 has the new logic).

Download location: https://binisoft.org/download/wfc6setup.exe
SHA256: 464bd94bc3f74396e33d3052f597ddd2d083d057c1bfd7f2635aed4db8c99ec7
SHA512: 587ad5cd3c9ba4dc0c95a1168153f802a1d3005cb5f5206555c08e604fd526c7c84aa19d3c390a32f63e9205820d0d3c543e4c7b0e17511948fba1c4e7c5acca

Thank you for your feedback and your support,
Alexandru Dicu

 

@alexandrud, unrelated to the new update but I've noticed an odd behavior. Whenever I try to enter the vertical bar character (|) in name or description fields, all rule changes get reverted.

For example:

a) Original rule is named "Rule 1 - Program A", that allows outbound access to remote address 1.2.3.4

b) If its name is changed to "Rule 1 | Program A", it immediately reverts to "Rule 1 - Program A"

c) Now if I change the name to "Rule 1 | Program A" and remote access address to 6.7.8.9, then both fields get reverted.

Is this the intended behavior or a Windows Firewall limitation? Not really an issue, just find it curious how the veritcal bar is a no go whereas other special characters are fine.

 

I think it is related to how Windows Firewall itself stores the firewall rules. Do you see in the screenshot below which character Microsoft uses to separate different properties?
| can't be used anywhere since it is used as a separator. I will update the UI validator in WFC to display the field in red when this character is used. At least it will be more obvious that this character is not allowed.

 

I see, it's by design then. Thanks for explaining it.