Windows Firewall Control (WFC) by BiniSoft.org

That's a catchphrase, nature is perfect.

Of course they must listen to everyone and implement what is right and proper, whether it is requested by many or by just one person.

Not always less is more.

Well, I'll say no more about this.

 

The old WFC EULA mentions "The software is provided 'as-is', without any express or implied warranty. In no event will the author be held liable for any damages arising from the use of the software." Nobody was forced to use WFC. When a software does not fit your needs, you can uninstall it. Problem solved.

More than 30% WFC features were implemented after suggestions received from Wilders community users. The discussion is not even about the software itself, is about an optional firewall rule that was added (not enforced) as a convenience for majority of users. Some may find it too permissive. No problem, it can be restricted or removed.

Anyway, I decided to take a break for a period of time. I can use my free time better than arguing here. Good bye everyone and thank you for your support over the years.

 

@alexandrud
I fully support your correct act with WFC. Good luck in everything.

 

To be honest, I still don't understand how Adobe X uses svchost.exe to connect out, is this some kind of backdoor in Windows? The good news is that SpyShelter can block this.

 

Just wanted to share a big thanks to alex for WFC, and especially for his tireless support all these years since WFC's inception (a decade+ now, time flies!).

Not to get all sentimental, but I participate in a number of forums for various programs or software packages, and by far, Alex takes the cake when it comes to dev support and responsiveness, especially as a one-man operation. His openness to feedback and willingness to consider feature suggestions, along with his prompt responses to user questions or issues, is unparalleled in my book.

The continuing growth of this thread is a testament that many continue to use and appreciate this utility, myself included, and I'm sure I'd speak for most when I say we appreciate all you do!

 

I'm glad the thread has at least been reopened , despite losing another developer on this forum.

 

Thank you all for your good thoughts. I reconsidered my position and I decided to continue contributing to the community.

 

Now that's good news.

 

I was about to post this when ronjor locked the thread so I'm posting it now.

I'm sure @alexandrud does not need to justify or explain himself.
He is a developer that loves his creation (heck, v1 was created for his own use, and he released it to the puclic on a romanian forum as freeware, if I remember correctly).
After that he had implemented a great deal of users suggestions. And was always fast to fix reported bugs.

As for this "wfc update rule". We told popescu how to fix it, and he shifted from "the firewall does not work" to a "you made the world less secure" campaign...

I wonder, what his reaction would be, if he had used a previous version and then windows, denfender, etc. updates were blocked; and was unable to fix it...

Bottomline, this rule was introduced, because he did listen to novice users complaints, instead of ignoring them.

As for the "insecure" part; that rule is not insecure; no incoming ports are opened and is used only for services that run from dlls. And is far more restricted from the default windows setting, that allows outbound to all remote ports.

If one allows a malware/trojan/worm to run and install a service, does he/she really beleave that he/she'll contain it through the windows firewall? It won't and, if he/she really beleaves so, is just fooling himself/herself...

 

Very glad to hear this, you have many positive supporters here! (even if we don't post very often)

 

Hi. I'm sorry if this was asked and answered before, but I'd need to take many vacation days to read through 200+ pages (I read quite a few pages already!)

I'm having trouble with Windows Firewall (WFC is probably not to blame): I noticed that any service-related outgoing connections are blocked (e.g. downloading of Windows updates is stuck at 0%). I can see this in WFC's very nice "Connections log" dialog, where svchost-related services (Delivery Optimization and Cryptographic Services) are blocked. Of course there are allow rules for exactly these services. For testing, I do currently not have a single block-rule.

Is there anything I can do about this? I'm connected to my router via Ethernet. In addition to the real Ethernet adapter, I also have 5 virtual ones (one for Cisco Anyconnect, one for NordVPN, one for OpenVPN, and 2 for VirtualBox). I cannot spare any of these programs, so uninstalling the corresponding software is not really an option. Could these adapters be the problem, though? I'd like to note that I have this problem while I'm not using any VPN.

Best regards!

 

Welcome to the forum.
The first thing to try is to deactivate/disable the virtual adapters. try to perform the update and check if it is still blocked. Then you can reactivate/reanable them.
If that does not help...
- What OS? if win10 what version?
- post a screenshot of the allowed rules in question
- post a screenshot of any block rules related to svchost services
- post some of the bock logs
(on the above you can hide/delete the ips before posting them)

Finally open cmd and run this command for the services that logs report them as blocked

Code:

sc qsidtype <ServiceName>

(replace <ServiceName> with the service name) and report the result you get.

 

Thank you! The problem seems to be solved. This is what I did:
- I first deactivated all but the real network adapters, but the problem persisted
- Then I thought: why not completely reset the firewalls to the defaults, just to make sure that this is not causing the problem, so I clicked on "Restore Windows Firewall default set of rules" in WFC
- Then I saw that most svchost-related connections were blocked and Windows update (as well as the Windows Defender threat definitions checks) still failed.
- Checking the rules I realized that there is no single "update" rule, apparently (using WFC's search box). So I also clicked on "Restore WFC recommended rules" in WFC
- From that point on, WU worked, so did the Windows Defender threat definitions check
- I re-enabled all the other network adapters and checked again - WU still works

So I guess the problem were incorrect rules, after all? I find this curious though, because I remember not having changed anything in the installer of WFC6. By default the WFC6 installer, IIRC, resets firewall rules, there is a checkbox I vaguely remember, anyways. I should note that I had WFC 5 installed earlier, which I uninstalled, as instructed by the WFC6 installer.

FYI: I'm still on Windows 10 1809 (Windows Update simply won't offer me 190x for some reason, so I'll have to update manually). Also, the command you asked about returned "SERVICE_SID_TYPE: UNRESTRICTED" for the affected services like windows update.

 

You are welcome.
Yes, the problem was with incorrect rules or a rule deleted by mistake.
It could also be that there is a bug in the update procedure of wfc (another member pmed me earlier that his "wfc - update rule" was missing the port 80; only 443 was permitted); or maybe another program messed with the rules?
about the sid and why I asked, check here https://www.wilderssecurity.com/thr...-by-binisoft-org.347370/page-218#post-2896932

 

The port 80 was removed a while ago from the rule WFC - Windows Update. These communications must be on SSL these days.

 

I suspected that maybe was removed in v6.x and advised to disable the existing rules and recreate and compare them with the "Restore windows firewall recommended rules".
As for the must be on ssl only... microsoft for wsus, advises both http and https to be used

https://docs.microsoft.com/en-us/configmgr/core/plan-design/hierarchy/ports#bkmk_note3
https://docs.microsoft.com/en-us/configmgr/core/plan-design/hierarchy/ports#BKMK_PortsSUP-Internet

 

Configurable rule WFC can't provide suggestions for all scenarios.

 

Plus we enjoy or look forward to your other creations, though I know family comes first now!

 

One day later, I found one minor and one larger issue with Windows Firewall (Control):
1) To update the Windows Defender Antivirus Threat Definitions, updating them sometimes only works when allowing svchost.exe to also use port 80 - so I just modified the WFC-rule for Windows Update to allow port 80 (in addition to the pre-set SSL 443 port) to fix that problem.
2) The "Antimalware Service Executable" (MsMpEng.exe), for which I created an allow rule (because I guess that it will send sample files to Microsoft for cloud-based malware analysis) is located in directory "C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2001.10-0". I guess you can already see the problem: this directory will definitely change over time. There seem to be only 2 options to fix this (or do you know better solutions?):
a) Keep WFC notifications enabled - but then I'll have to constantly tune the firewall rules to block various services and apps - anyways, this way I'll notice once the "Antimalware Service Executable" pops up again, located in a new version directory.
b) Write a third party tool that regularly scans for existing files with pattern "C:\ProgramData\Microsoft\Windows Defender\Platform\*\MsMpEng.exe" and creates allow-rules for them (unless such a rule already exists). I wonder whether such a feature could be added to WFC? I know that Windows Firewall doesn't support glob pattern wildcards, but WFC could have the ability to define special wildcard rules, which WFC converts to WF rules (with hard coded paths) at runtime. Windows Defender surely isn't the only application with the pattern of having multiple versions of the same application installed, which causes several subfolders to exist which contain the respective binaries.

Best regards!

 

Previously, such a proposal was met. If the application path changes each time it is updated, and the application connects to the network through a specific port, then create a rule for this port (for example, 45190) for all programs (without specifying a path).
This can help avoid editing the rule every time after updating the application.

 

It is on the backlog list to provide an auto update feature for such programs that use a different path after an update. I will try to add this in next WFC release.

 

Cooooool
And thank you VERY much for all your EXCELLENT support all the years!!!

 

So, what is the practical solution , for the time being, to allow Windows update and Office update if the path changes each and every time ?

The solution provided by aldist I assume was a joke.

 

If we do not want the topic to be closed again and forever, we ignore floder Popescu's posts

 

Sure, let's open all ports in WF ,to avoid any issue, and ignore users who are pointing of that .

Who said "Ignorance is bliss"