Windows Firewall Control (WFC) by BiniSoft.org

Actually it does work on home versions as well and does not require gpedit.msc to import or create the .reg as shown in my example.....I assume that means you didn't bother to test it /sigh
It is applied the same way older versions of "CryptoPrevent" were, directly in the registry policy area...only this one is firewall related instead of SRP.......

My example (see 1 again) is not meant to thwart network administrators or those who actually connect to a domain or otherwise use group policy. I believe I covered this aspect in the original post where I explicitly said (See underlined):

"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."

I do not dispute this and I also covered it in the original post where I said:

"I did this with admin rights like a majority of software installers also require anyway."

No arguments there but my suggestion retains the ability to apply more restricted permissions (simply in a different location that the Windows Firewall already processes [and trumps SharedAccess with "AllowLocalPolicyMerge"=dword:00000000 set]) yet prevents the issues caused in scenarios with the current 'new' version of secure rules especially with (but not limited to) the latest version of Windows (eg 10) while also preventing those rules from being used! It's win-win....so I'm honestly flabbergasted I've had to argue this point even once!

I can't argue here but as my other post said, I was able to do all this with just .bat files and other preexisting programs found in Windows. While I surely wouldn't suggest you do it the same way I did for my tests I must say I find this argument to be...lacking...

I refer you back to point 1. Yes it does....add the rules and .reg I pasted in the original post and reboot. See for yourself as you really should have before dismissing it all!

I did not encounter any new issues and it solved all the problems in my (limited) test. What is it you think isn't solved?

The point with the steps was to keep the rules which are actually applied (in the policy area) until something needs to be added or changed via WFC. The short span in which you would alter permissions in SharedAccess, starting by temporarily setting permissions as they are now followed by clearing any existing rules there that 'might' have been created outside WFC then copy the actual rules from the policy area back to the SharedAccess location (so you can use existing APIs) and create or change a rule before copying them all and restoring them back to defaults should be small enough to avoid the current issues but have the exact same level of security as the current 'new' secure rules....plus a bit more as it prevents the simple .reg bypass which WFC is currently (and as you so kindly pointed out, also previously) blind to.

So simply refresh the firewall after every edit, creation, or deletion? What's the big deal? That's what I did with my example and gpupdate /force...

It allows installers, including UWP installs/updates, Windows Defender and Windows Update or whatever else might deign to try and add a firewall rule to do so and succeed in creation of the rule under SharedAccess
yet still prevent the rule(s) from actually being applied.
If you didn't get that I see why you argued with it all. I suggest you play/test with gpedit.msc and the firewall policy area (via import/export even on home) a bit! Instead only those rules which WFC (or an admin via group policy) add would be applied so long as the proper keys are set and 'secured'.

It really wasn't my intention to argue anything but I must say I am getting frustrated at how no one seems to grasp the points. I actually hoped I had made my goal and methods clear but you and others here seem to have completely missed both so I figured I'd give it one more go by responding to your points.

 

Preventing those rules from being applied (SharedAccess), will not solve the problem of Windows Store applications which will still not work. It will solve the installation problems but they won't connect to the Internet. I do understand what you are saying, but implementing this is more complex than a forum post presenting some general ideas.

Anyway, as I already mentioned, version 5 won't receive any new updates and there is no plan for a version 6. There are two working versions 5.0.2.0. and 5.3.0.0. with two flavors of Secure Rules.

 

"Anyway, as I already mentioned, version 5 won't receive any new updates and there is no plan for a version 6. There are two working versions 5.0.2.0. and 5.3.0.0. with two flavors of Secure Rules."

A big Windows 10 update is coming up and there is always something to fix, although version 5.0.2.0 is already the best at the moment.

If it is a financial problem, I would release the next version as a paid version.
I do not believe that voluntary donations cover the costs, development must also be paid for.

 

Will it stop the keygen developers?

 

WFC is perfect as is so no new versions anytime soon is of no worry, it's a frontend for Windows own Firewall, is that going to break anytime soon? Maybe from the next big Windows update? of course not. WFC seems feature complete to me, maybe alexandrud thinks so too, time for a rest.

 

For those of you that used 5.1.0.0 or later, and now want to get back to 5.0.2.0 to make Store Apps work again: you are probably missing some @ rules that prevent these Apps from working properly. If you have Secure Rules enabled, you obviously need to have @ in the Authorized groups list before doing this.

To get the rules back:

1. Go to "Add or remove programs"
2. Find the Microsoft Store app and click
3. Advanced options/Reset
4. This will re-create the rules for the Store itself
5. Repeat 1-3 for any other app you want its rule(s) re-created.

 

The version 5.3.0.0 does not work correctly in my opinion and needs a revision and I was insufficiently informed about this big change, therefore I am also back to 5.0.2.0.
Took me a long time before.

AmigaBoy, I export regularly the user rules and reset the complete Windows Firewall, I think it is enough.
Otherwise I cannot follow you.
"Add or remove programs", you mean from Windows control panel?

 

Yes, to be exact in Windows 10's "Settings", not the old UI Control Panel. Typing "Add or remove programs" in the Start Menu will reveal it instantly.
When I later mention "Authorized groups", I mean in WFC's panel / Security / Authorized groups. This is only available in 5.0.2.0, not later versions.

By the way, resetting the Windows Firewall rules to default does not bring the @ rules back. They may start appearing eventually at a later time as Windows 10 does its internal checks/maintenance etc.

 

"not the old UI Control Panel" !
THX

I reseted the app Camera and get back:
U - @{Microsoft.WindowsCamera_2018.227.30.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.WindowsCamera/Resources/AppStoreName}

If I need this rule later, I can easily manage it with "authorized groups".

 

I see that you wrote "U - @{..." which probably means you will keep this rule as disabled. Note that when Store Apps update themselves, their path changes and thus the previous rule becomes invalid (they automatically delete it and create a new one).

Check this section in WFC's manual: Rules Panel / How to allow Windows Store apps that have a different path after an update?

 

Wow, I missed this. WFC has been one of my prime applications for a long tiime. All the best Alex.

 

Installed three March Windows Updates (stand-alone installers) today with Secure Rules disabled.
Two new @ rules (now Block n' will Delete).

5.3.0.0 - W10 Home (15063.994)

 

Q.E.D.

 

Well, since I had hiccups with February Windows Updates with Secure Rules enabled.
Before reinstalling 5.0.2.0 with @ group.
I wanted to see whether 5.3.0.0 was workable, for me.

 

From the version 5.1.0.0 changelog:

The WFC recommended rules contain now some inbound rules required for accessing the computers from the local network.

I've uploaded here all the WFC recommended rules from that version as a partial policy file (.wpw), for anyone interested in importing them in WFC 5.0.2.0. Got them on Windows 10 Pro x64, I don't know if they can be used on other Windows versions. They could, but I'd advise against it just to be safe.

If you import them, you should first delete your current recommended WFC rules. Their name starts with: WFC -

 

Why so complicated, in 5.0.2.0 everything with "U -" remains untouched, for the out/incoming traffic the blocked app is simply allowed or not.

The main thing is that Windows does not allow in/outgoing rules automatically.

Under 5.3.0.0 I have my problems with this, because I simply cannot deactivate incoming traffic for various apps, maybe this is just a display problem.
And I often need to check if an app needs updating.
Suddenly my calc stopped working and I was standing there and ...

Updated: The WFC recommended rules contain now some inbound rules required for
accessing the computers from the local network.

If my rules are right, five new in-rules have been added, even a few important ones, I see,
and "WFC - Network Discovery (NB-Name-Out)".

 

I use Windows Firewall only, without any 3rd party SW.
After most of Windows updates, even the normal "patch Tuesday" ones, new rules are created by Windows itself.
If I remember correctly, TinyWall had the option to block rule creation for any SW (including the OS) except TinyWall itself. Too bad TinyWall has no longer being developed

By the way, after every Windows update, I check the rule list and I remove the new entries.
I set up my rules according to this guide: http://hardenwindows10forsecurity.com/
Right now I don't have any inboud rule because I set a static IP to connect my PC to the router, so I don't even need the DHCP rule.

 

It is not only tiny, it's too very simple, not for advanced users, without fine tuning, without pop-ups, and is much inferior to WFC.

 

The option that you mention was implemented by restoring the entire full policy with a fixed (previously saved) one. This means it could not block the creation of the rules, but it checked if the number of rules is greater than the count it has, so it just restored all rules. This would not cover changes of the rules. Anyway, the discussion here is about WFC not about TinyWall.

 

TinyWall was meant to be as simple as possible and in my opinion it was great on that regard.

I know, I was just pointing out that blocking Windows from creating new rules is difficult to implement for a SW that works as front end for Windows Firewall

 

I politely request the following.

Please put the latest version of the program up for download, that is the last release before you changed "secure rules"

I personally much prefer the older "secure rules" and I really feel you probably should keep both variants in the program or just revert to the older variant. But I expect you wont so the next best thing is to have access to the latest version of the old "secure rules".

You dont need to support this older build, just add a download link, thank you.

 

Perhaps later this link will appear on the binisoft.org.

 

thank you.

 

Lately, even though option is checked, WFC has not been reverting to Secure Boot at shutdown . I have tried reinstalling, but didn't help. Any thoughts?

 

Try to clean the system of traces of WFC, but I do not know whether it will help you or not:
A) Close the wfc.exe process via the WFC icon in the tray.
B) In the CMD with admin, run the following three commands:
Sc.exe stop _wfcs
Sc.exe delete _wfcs
reg delete "HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Uninstall \ Windows Firewall Control" / f
C) Manually delete the WFC installation folder.
Now your system is completely cleaned of the traces of WFC installation (note that your firewall rules and settings still exist and work!).
Now you can perform a clean WFC installation.
P.S. Check this before rebooting and after the system boots