Windows Firewall Control (WFC) by BiniSoft.org

You made one step forward and two back, hate to say.
Secure rules were an excellent addition. But with obfuscation/hiding the code removed?
It's all about money.

 

Thankyou for making such a great program. I created this account as the tray icon wasn't showing up after moving from 5.0.2.0 to 5.3.0.0, but it has since appeared.

Sounds like you need a ticket system with an autoresponder for that false-positive issue. Then again I do think there is a lot of goodwill for this software, and I'll be telling my friends about this great security tool.

 

Hello again Alexandrud,
I have decided to reiterate my suggestion but will also attempt to cover it a bit more thoroughly as I suspect I may not have explained well before.

I did something similar to the new version of 'secure rules' with my Windows 7 builds after I began using the Windows Firewall but found it was impractical for many reasons especially after moving to Windows 10.

The recently implemented version of secure rules is, in my opinion, flawed in many ways. Some of these have already been experienced by users and reported to you here. These tend to be the aspects I first tried to warn you of when I urged you to do more testing before you began rewriting code. Things like the windows store apps failing to install but as you've also seen by now this extends to quite a few (not all) normal software installers and even windows updates.

If those few compatibility issues I've listed are not enough to convince you perhaps a complete bypass of the new 'secure rules' might help?
Without touching registry permissions at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy >while 'secure rules' is active< it is possible to have to the Windows Firewall ignore every single rule and policy located there.

To test this I loaded a Windows 10 VM, installed Windows Firewall Control 5.3.0.0.
I then cleared the existing rules list and created only 2 rules. One for "Block All Programs Outbound", one for "Block All Programs Inbound".
I then selected "Secure Rules" & "Secure Profile"
I also set the profile to High Filtering so there were now 2 Blocks for each direction in the firewall for all programs on all ports and all protocols. There should be no way anything can connect now?!
To verify I opened regedit and navigated to the Keys where I was prompted with an "Error Opening Key" alert upon attempting to inspect them. I found this odd as there isn't really any benifit to preventing admins from reading the data. Only write permissions should be removed IMHO but that's not related to this so...
I then opened Edge and tested trying to reach www.google.com and it failed to do so as expected.
Next I imported a simple pre-made .reg file that will work on Windows 7-10. I did this with admin rights like a majority of software installers also require anyway. (Do not try this on a real PC as it would open your computer up in both directions despite WFC and the current revamped 'secure rules'!)

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile]
"AllowLocalPolicyMerge"=dword:00000000
"EnableFirewall"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\FirewallRules]
"{EVIL1}"="v2.0|Action=Allow|Active=TRUE|Dir=Out|Name=EVIL1|"
"{EVIL2}"="v2.0|Action=Allow|Active=TRUE|Dir=In|Name=EVIL2|"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\PrivateProfile]
"AllowLocalPolicyMerge"=dword:00000000
"EnableFirewall"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\PublicProfile]
"AllowLocalPolicyMerge"=dword:00000000
"EnableFirewall"=dword:00000001

After a reboot or waiting for the policy to refresh (which every computer will inevitably do at some point- I used gpupdate /force for speeds sake) I then opened up Microsoft Edge and navigated to www.google.com without an issue.
WFC still showed 4 rules. 2 from High profile blocking all and the two I had manually created that mirrored them.
In reality there were 6 rules but only 2 being applied by the Windows Firewall, the two added in the .reg file, EVIL1 & EVIL2!

How safe will WFC users feel knowing an installer or other program they thought would be stopped from communicating online via 'secure rules' can simply create invisible ones that bypass it?
WFC 'Secure Rules' went POOF and it didn't even know anything was wrong!

So I would like to propose, once again, that you abandon the current method of applying secure rules via modifying registry permissions under Shared Access. Instead I think it would be better to make use of Windows Firewalls own pre-existing version of 'secure rules' and simply remove the write permissions for the Administrator group for HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall and the subkeys. This would leave only SYSTEM with write abilities and allow both the WFC Service (wfcs, which already runs as NT AUTHORITY\SYSTEM) and (if the user or an Admin uses it locally) Group Policy to be applied/edited properly on Pro+ systems while still removing the ability of a .reg file bypass (as Admin) like shown in my example.

Making use of the 'policy area' for 'secure rules' in WFC would not only be a security boon, it would allow you to leave the Shared Access permissions untouched most of the time and resolve the many issues people are seeing with installers, store apps, updates and more.

The workaround I thought of related to using the APIs was to use the APIs normally then simply copy the string(s) to the policy area. This method could have some potential pitfalls [and would likely require a spiderweb of alterations for you =( ] but I was able to do this with .bat files so surely you would figure out a better way being an actual programmer with access to APIs so here we go with my thinking and manual tests:

Note: For my test .bats I had a cmd window open and running as SYSTEM (eg RunAsTI, PowerRun, etc) but these actions could esentially be handled by the WFC Service with the same rights.

1)
When 'Secure Rules' is first activated it copies the existing strings (rules) from SharedAccess to the Policy area and sets AllowLocalPolicyMerge to no (0)
In my test .bat I used regedit to export the key along with findstr and set to update them to the target area then simply re-imported via regedit.

2)
The rules in SharedAccess are removed, eg cleared out
In my test .bat I simply used reg delete to do this

3)
The firewall state then needs to be refreshed.
In my test .bat I used gpupdate

4)
When a rule is to be created or edited first set the registry permissions for SharedAccess then clear it of any existing keys to prevent picking up potential additions we don't want getting added to the 'Secure Rules' later.
For my test .bat I used regini for this (along with txt files containing the original perms and the 'secure state')

5)
Once the rule is added or updated it is copied back to the policy area (see 1) and once again original permissions are restored to the SharedAccess area.
For my test .bat I used regini for this (along with txt files containing the original perms and the 'secure state')

6)
Removing a rule from the policy area should be an easy task.
For my test .bat I used reg delete to do this

7)
When 'Secure Rules' is deactivated it clears the SharedAccess area and copies the keys back from the Policy area. It then sets the AllowLocalPolicyMerge to yes (1) (or simply delete the value entirely). Then it restores registry permissions to original and refreshes the firewall state. eg return everything to normal.
For my test .bat I used a mix of the above

Obviously there may be things I haven't thought through (like WFC would also need to parse the new location to show it in rules, etc) and other potential issues that could still prevent you from implementing it this way even IF you even wanted to but I suspect they could also be worked around given time.

Heck, being able to simply see and report rules from the policy area, even if you have to copy them back to SharedAccess just to do so, would be a huge improvement allowing WFC to do something few others can.

The 'quick and dirty' answer might be to simply lock down this portion of the registry at the same time as you do SharedAccess but that still wouldn't resolve the usability issues the current secure rules method faces while my suggestion might solve both quite neatly. If not, sorry for wasting your time (again)!

I'm not a WFC user so beyond wanting to help you and the people who use your product I have no real care for what happens next. In the end it is entirely up to you how and what you do with your software. I'm no programmer and I hope I haven't come across as arrogant. I wish you luck and hope you keep up the good work.

 

@syrinx

Great post. When I have some spare time I'll follow your instructions to reproduce your findings.

 

Thank you for your reply; I am sorry for my misunderstanding. Yes, the Avast updater did get through when I used Low Filtering.

However, in the last few days using Medium Filtering, I have seen a few rules that, it seems, are not being imposed consistently by the windows firewall. Not only for the Avast updater but also a few others, e.g. Internet Explorer, where first the application's connection is allowed and later it is blocked.

I am very puzzled, but I understand now that it is not WFC that is responsible. Thank you again.

 

You are partially correct. Through Group Policy Editor (gpedit.msc) you could navigate to Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security and take over the control of Windows Firewall. You can define there if you want to take over the inbound filtering, outbound filtering, you can set to ignore the existing firewall rules (the ones that you see in WFC and WFwAS) and you can also define new firewall rules. All of these settings will be then saved in HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall and the settings from HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess will be ignored.

However:
1. Your workaround works only for Professional and Enterprise versions of Windows where Group Policy Editor exists. For Home versions of Windows, this workaround will not work.
2. Secure Rules was not intended to be used against network administrators. Having this in mind, the current Secure Rules was not intended to cut off the network administrators from being able to configure security policies in the networks that they administrate.
3. For the workaround you provided, you need administrative privileges. Let's say a bad software gains administrative privileges, usually allowed by the user in the UAC prompt. At this point, it could disable entirely Windows Firewall service, making all the rules useless. So, it won't matter anymore where are stored the firewall rules.
4. The same workaround could be executed on the old Secure Rules implementation too. So, even the old versions of WFC have the same "flaw". But, this is not the point. Someone really determined, could circumvent any WFC tricks, including activation, unlocking the application, permissions, etc. The same applies to Windows Firewall itself. Once you have administrative privileges, you can do a lot of good and/or bad things. Nothing new here.

Your proposed solution is hard to implement, because:
5. Windows Firewall API doesn't expose firewall rules that are created through Group Policy Editor. WFC will have to parse those Windows Registry entries instead of accessing them directly through an API that already has the validations and methods out of the box. I will have to write WFC own API for this which will take time and will be slower compared to the existing API from Microsoft.
6. It will not work for Home version of Windows. This means I will have to keep a lot of code for compatibility purposes.
7. The final result may not be the expected one. I thought about this and there is no win-win situation. Either way, the current way, or your proposed way, there will be problems that have no solution.
- For example, your step 4 is already made by Secure Rules. The permissions are restored, WFC adds a new rule, then permissions are removed. The problem is not when WFC is adding or modifying a rule. The problem is that when the permissions are removed, there is no way to detect if an external program tries to add a new rule. It will fail and that's all. WFC can't detect a new rule, because there is no rule that is added or modified. So, there is nothing to be copied from SharedAccess area to Policy area.
- Another example, just adding or removing new Windows Registry entries will not refresh the state of Windows Firewall. If you delete an entry (rule) it will be still there until you force it with gpupdate. The same works for adding a new rule.

I still don't see how your proposed solution will fix the Windows Store apps problem.

Who likes better the old Secure Rules, version 5.0.2.0 can be downloaded from: https://www.binisoft.org/download/old/5020/wfc5setup.exe
Who likes better the new Secure Rules, version 5.3.0.0 can be downloaded from: https://www.binisoft.org/download/wfc5setup.exe

Again, if a malware gains administrative privileges on your computer and your antivirus does not detect it and stop it, then it could just disable Windows Firewall service directly.

I can't make everyone happy

If Low Filtering is enabled, all programs without block rules can connect at their free will. For Internet Explorer (if you still use it, move to another browser), if you are on a x64 machine, you have to create two rules for iexplore.exe, one located in Program Files and one located in Program Files (x86). Note that, these are two different processes with a different path, but with the same name. Maybe this was your scenario?

 

And why? I'm already happy with 5.3.0.0
Can you remove the vertical scrolling in the Rule Edit Window? It is always present there, regardless of the size of the Window.

 

It does not appear on my side. Do you use a custom border size, custom DPI ?

 

No, I only use the custom font size with System Font Size Changer https://www.wintools.info/index.php/system-font-size-changer
I'll try it on another PC.

 

I checked, yes, this is the effect of the increased size of the system font

 

The new version could broken the windows 10 apps updates through microsoft store
the secure rules option in security tab
enable that will prevent any apps could install properly inside the microsoft store or using powershell for fixing apps error
when using powershell it would have this error
0x80070005: Windows cannot create the AppContainer profile for the XXXX
Even turning off manually,sometime it still could blocked the powershell for reinstalling the apps

 

Who likes better the old Secure Rules, version 5.0.2.0 can be downloaded from: https://www.binisoft.org/download/old/5020/wfc5setup.exe
Who likes better the new Secure Rules, version 5.3.0.0 can be downloaded from: https://www.binisoft.org/download/wfc5setup.exe

 

The latest Windows 10 update does not like WFC at all. I had an issue yesterday where all my Store and apps from it plus every Windows 10 app would not work all of a sudden. It just started without me changing anything. I could not even get the Start Menu to show. I did a refresh of Windows and reinstalled all my programs. It was working fine and again just now, the Store, all apps are not working again. They are grayed out. I had already allowed the Store access with a working rule. I allowed any app I used access with a working rule, like Weather app in Windows 10. Now it just says it This app can't open, contact your system administrator. Nothing asked me for internet access besides Cortana which I blocked.

I don't want to let Windows just go crazy adding rules for every little thing it wants to fix this. No idea what to do now.

EDIT: I am going to remove WFC and reboot. Then see if it fixes the issue. I will edit this post after seeing what happens.

EDIT2: Weather, Store and other apps worked within seconds after reboot. They never asked for access before breaking.

I guess I will wait until there is a fix for this issue. It has to be related to the last windows update. This is when it all started. On a positive note, at least I have a clean windows install now. It was years old, since windows 10 first offered free update from 7. I installed the upgrade, then reformatted clean. Been running that until yesterday.

I am not mad at WFC for this. It happens with windows updates. I will wait for a fix or to find out how to avoid the issue so I can reinstall WFC.

 

@Eliot

Same thing happened to me, and i'm pretty sure that's related to the new "Secure Rules".

Start Menu, Action Center, Calendar, Volume, Network & Edge wouldn't open after installing the new update (KB4089848 ). I uninstalled it but the problem persisted. I used this fix from Microsoft and apparently it fixed the issue (not really sure on this as i think i already disabled "Secure Rules" at this point) it said that "ShellExperienceHost" & "Cortana" weren't registered properly or something along those lines.

Went ahead and re-installed KB4089848 again, this time with "Secure Rules" disabled and everything worked as intended. So yea, if you update your machines make sure "Secure Rules" are disabled or you might end up with a broken system.

 

WFC is not a Firewall, it is a front-end to the windows firewall to make things easy to understand
and adjust, you cant complain to the developer about your disruptive rules that you use in windows.

If you need have such complex requirements, do it within the windows firewall its self don't
rely on WFC to compensate for the elite missing or blocked rules.that are not available.

WFC is not a Firewall

--
Skinny

 

Thanks @yeL I ran that before I did my "refresh" of windows. It didnt work for me though.

I am going to wait until I hear back from more users and @alexandrud on this before I reinstall WFC.

I know WFC is not a firewall @Skinny ... It was related to the new version and the windows update that just came out.

 

I like to call it a well thought out and effective "Controller", giving the windows end user some vital flexibility and instant monitoring which can go a long way fast in making the best use of Windows default firewall. Great effort and most gracious developer if you ask me.

 

I'm on the latest W10 with the latest WFC and have no issues at all, so it's something else then WFC Mr. Eliot.

And I just wanna say that Secure Rules are an amazing addition to WFC, if you don't want store apps getting blocked then don't use such an advanced feature.

It's also worth noting that WFC won't break Windows anymore then Windows' own Advance Firewall would. Hint: There the same thing.

Uninstalling and reinstalling WFC won't change anything if your Firewall rules are already a mess because of user error, If I were you I would wipe everything and > Recommended Rules to start fresh.

 

I did that after my refresh. I let WFC create all recommended rules and then started using my computer to make the other rules. Then the issue happened today about 16 hours after the refresh causing the same issue. If you have Secure Rules enabled and have no issues then you don't have that latest update.

 

Oh, okay, my mistake. https://i.imgur.com/GBzSpXW.png

 

Let me say it again, maybe explained differently:

If you are using the following operating systems: Windows 7, Windows 8, Windows 8.1, Windows Server. Then, you can install and use version 5.3.0.0. and use Secure Rules which will prohibit any change to Windows Firewall rules.

If you are using Windows 10 and you:
- want full control over your firewall
- don't like telemetry
- don't care about Windows Store apps
Use version 5.3.0.0. with Secure Rules enabled.

With Secure Rules enabled, Windows Store apps won't install or update properly and some Windows Updates wont install properly. But, when this happens you see notifications from Windows 10 that something could not be installed. Then you know that you have to manually disable Secure Rules, let the operating system install what it wants, and then just re-enable Secure Rules. If this is something that doesn't work for you and this is way too complicated, you can:
1. Disable and don't use Secure Rules feature.
or
2. Install version 5.0.2.0 which can be downloaded from https://www.binisoft.org/download/old/5020/wfc5setup.exe Add '@' in the authorized group names and let any Windows Store app to connect to the Internet.

There is nothing to be fixed in WFC. The side effects of using Secure Rues are known and already mentioned in the user manual and this forum.

The real problem is actually Windows 10 which tries very aggressively to install everything it wants, anytime it wants. When Secure Rules is enabled:
- Some Windows Updates fail to install because they can't add new firewall rules. Usually, telemetry rules.
- Windows Store apps install until the last step when they want to allow themselves through Windows Firewall by adding new rules on their own. Why? They should install and should display a message that they can't connect to the network when they are launched, letting the user to add a new firewall rule, if he wants, not because an app wants. The user should have the control, especially when outbound filtering is enabled in Windows Firewall.

Secure Rules does what it is supposed to do. If the side effects are giving you headaches, just don't use Secure Rules or install version 5.0.2.0. which is not so effective, but more flexible.

 

but how could it be even we disable that feature,and it will turning it back on in 5.3.0 without any touches? ?
I know secure rules was suppose to be do like that

 

While you keep suggesting this, it really isn't much of a solution for those that prefer the old secure rules since 5.0.2.0 will not continue to receive other updates or bug fixes.

 

To be fair Alex has explained in detail how you can run 5.3.0.0 with Secure Rules in W10 if you wish. There are just a few obstacles to navigate along the way. I doubt that anyone who feels comfortable using secure rules would find his instructions too complicated. And if they do, he gives two alternatives. Not sure what else you expect him to do.

 

@alexandrud
WFC enforcing the block of Metro Apps or some WU is not better than MS forcing them.

Users should be able to use Secure Rules without having Metro Apps or WU being broken, it is not because some people don't like Metro Apps that others must be forced to follow.

I need secure rules for some specific reasons, but i also want my Metro Apps and WU to work as intended.

You said if you want the old Secure Rules, use the old version, so what will happen in the future, will i be stuck with an old build?

Blocking Metro Apps (and co) via secure rules should be a choice, not enforced. You can easily make a checkbox that will enable/disable Metro Apps rules rather than me being forced to disable Secure Rules to use/update my apps