Windows Firewall Control (WFC) by BiniSoft.org

A few more details regarding the customization of the Secure Boot block rules (the rules created when the High Filtering profile is enabled). The entire problem can be solved by providing a way to customize the remote IP ranges of these block rules. Defining allow rules is useless, because a block rule which includes the ranges from the allow rule will result in blocking of that IP range. Block rules have higher precedence than allow rules. We can solve this by allowing the user to define custom remote IP addresses for those two block rules.

VARIANT 1

I will include two text boxes in the Profiles tab which will be used to define the blocking ranges for the High Filtering inbound and outbound rules.

Scenario 1 - The user wants to block all connections.
This is the current implementation. Two block rules that apply to all possible connections are created. Those two text boxes are empty.

Scenario 2 - The user wants to block all connections, but still allowing local LAN connections.
The user fill in those two new text boxes with the following IP ranges: 1.1.1.1-192.168.0.0,192.168.0.255-255.255.255.255 When the High Filtering profile will be enabled, these remote IP addresses will be used in those two rules that are created. Having the block rules defined this way will result in allowing all connections to/from local LAN computers. The list can be modified according to the user taste.

Important: The other properties of these two block rules remain like they are today. I don't see (now) the point to allow the user to change also other properties of these rules.

VARIANT 2

The user can modify the remote IP addresses directly from the Rules Manager for those two special block rules. These custom IP ranges are saved and reused, until the user changes or removes them.

What do you think ?

 

I knew that - of course - that block rules have higher priority than allow rules. With allow rules, I meant exceptions in the High Filtering block rules too - not REAL allow rules.

THIS is exactly my idea which I meant (with a special list), except we would have only IPs here, but - at least for moment - this would be really enough. The handling would be also easy enough!

This is then my other idea, direct from the Rule Manager.

I would prefer the text boxes (in the Secure Boot Menu Section?). So it would not confusing the user within the Rule Manager. Eventually later (if you WOULD implement other elements (not just IP), it could be adaptet to the Rule Manager. For now, I would say: text boxes are enough.

ONE thing I would change (as I suggested): make the LAN automatically (after the user has selected). A "normal" user maybe has not the knowledge to make SUCH IP-ranges?!

So here my suggestion (adjusted):

- Secure Boot All ........... [ ]
Blocks all connections in-/outbound - from/to LAN/Internet - while boot process.
--> The actual implementation.

- Secure Boot Internet, Allow LAN (IPv4-only) ........... In [ ] Out [ ]
Blocks all connections in-/outbound - from/to Internet - while boot process. Allows LAN access as defined while boot process.
--> Make the exceptions in High Filtering List automatically (IPv4 should be enough (yet)).

- Secure Boot Custom (for expert users only) ........... [ ]
Define which connections are allowed while boot process.
--> OPENS THE TWO NEW TEXTBOXES! Here can the user define as we discussed above!

So, for MOST users LAN in/out should be enough and easy tick(s) to "Secure Boot Internet ..." should be enough and EASY! And last but not least - this prevents access from/to outside the LAN, because a not desired IP-range is created too fast and this should be avoided!

Alpengreis

 

I have implemented the VARIANT 2. Having the textboxes under Secure Boot section is not intuitive because it customizes the High Filtering profile which is set from the Profiles tab. These changes apply even if the Secure Boot is not used and the user manually uses High Filtering profile. Regarding the LAN only rule, it is difficult to detect the IP ranges of the local network. For example, at work I use two networks and if I check with ipconfig, I have assigned the IPs 192.168.150.70 and 172.23.101.30, but I also connect to a VPN and I have also the IP 10.10.16.34 assigned. As you can see, it is not so easy to detect the ranges required for the LAN only rule.

I still have some items to fix and I will make a new release. You will find the VARIANT 2 implementation very easy to follow.

Thank you for your feedback.

 

I think you may have just provided WFC with a VPN killswitch feature, by going with VARIANT 2. (Assuming I understood correctly)

1) Can the Secure Boot rules be updated on-the-fly? For example after enabling High Filtering... having LAN IP in text box, then connect to VPN, then replace LAN IP with VPN IP after connection completes. (or can this be covered by using a LAN IP and a VPN RANGE since there are two text boxes, and then relying on rules to limit LAN IP reach?)
2) What takes precedence: LAN IP in High Filtering Mode OR block rules with LAN IP (eg: WFC allowing LAN IP vs Rules created to block LAN IP)

Sorry for the confusing wording, I can try to elaborate if you require more explanation. It always sounds better in my head, haha...

 

Ah, yes - I had not considered VPN situations ...

Regarding the textboxes: I understand!

Then: I totally agree for Variant 2!

Thank you for clarification and implementation!

 

If I have to choose between Variant 1 and 2, I also prefer #2 if implemented conveniently. Variant 1 will be messy if I want to include several local IP addresses to be protected from blocking, since for each desired pass-through address I need to include two bracketing IP addresses, and if implemented in a text box this would be unwieldy.

P.S. Need to also consider IPv6 management for those who use it...

P.P.S. to detect local address it is sufficient to detect 10.*.*.* , 172.16-31.*.* and 192.168.*.* which are IANA-reserved as private. However, I don't know how easy it is to implement these pass-through ranges in WFC.

 

The Security log of the system where all these events are stored is overridden after the size gets to the upper limit. I tried different settings and the maximum entries that I've seen is somewherearound 35 thousands. These 35 thousands entries can be filled in just a few hours. The answer is no, you can't see connections from a few months ago.

1) Yes, when the rule is updated (on-the-fly), the changes are applied immediately.
2) All block rules are applied and they are combined.

IPv6 ranges and IPs can be defined also in these block rules, the same you would define them for any other rule which deals with IPv6 addresses.

 

Windows Firewall Control v.4.5.0.5 - New version

What's new:
- New: The remote IP addresses of the two block rules that are created when High Filtering profile is enabled ("High Filtering profile - ...") are now customizable. These rules can be modified to block custom user defined connections instead of all connections. The values entered are reused until they are modified again.
- Fixed: The update button is missing from the installer if the user wants to update a version older than 4.4.0.0.
- Fixed: Open file location for rules defined for All programs does nothing.
- Fixed: Exporting and importing the user settings do not work on mapped network drives.
- Improved: Code refactoring to improve the speed and stability. Removed references to some 3rd party assemblies which are not required anymore after the refactoring.

Other notes:
The user settings saved with previous versions can't be imported in this version because the format has changed a little bit. Please export the rules again with this version and keep this new file for backup.

Download location: http://binisoft.org/download/wfc4setup.exe
SHA1: c987ccdd4e1322f67ee4961214a014841f9b7a20

Have a great weekend and thank you for your contribution.
Alexandru

 

Thank you for the new release.
I guess I don't understand the newly implemented Variant 2: I can customize the remote IP ranges when "High Filtering Profile" is on, but I can not change local IP ranges - they are set to "any" and locked.
Does that mean that if I want, for example, to have the local IP 10.0.0.5 to pass through, this is considered "remote" and so I will customize remote ranges as 10.0.0.0 - 10.0.0.4 and 10.0.0.6-255.255.255.255 ?

 

First impressions of Variant 2:
1 - This thing is a freakin' monster!
2 - I take it browsing whilst High Filtering is enabled should not be attempted?
I tried for a while, but cannot imagine inputting IPs all the time just to access sites... therefore Medium Filtering will suffice. One could assume allowing through some websites, frequently visited perhaps? Thoughts...
3 - Now I feel kinda' cool... can keep VPN connection going whilst blocking everything inbound and outbound (High Filtering).
I had to modify the outbound rule to allow VPN Server IPs (eg: 10.66.0.9), VPN DHCP IPs (eg: 10.66.255.254), DNS addresses (the ones in Network & Sharing + others if pushed by VPN) and other stuff (VPN company dependant). I also had to allow VPN DHCP IPs through the inbound rule. The TAP Adapter driver would not fire up when prompted by my VPN connection widget. All worked well after inbound rule was tweaked.

PC boots up in Secure Boot mode, High Filtering enabled... VPN connects, Medium Filtering enabled to browse and update software... back to High Filtering when idle or gaming etc...

 

After upgrading to 4.5.05 from 4.5 I see that the product is not activated. I used my activated code but it doesn't work. What is happening?

 

I had this too a long time ago. I had to generate a new activation code. You can make this on binisoft.org (Login required).

 

@Alpengreis: Thanks.

 

From your local machine, allowing 10.0.0.5 means to allow a remote machine. This means that you define a rule which allows a remote connection. Defining a local IP for a rule makes sense only if you connect to multiple networks at the same time (LAN and VPN) and you wish a rule to apply only for a specific connection. Otherwise, it doesn't make any sense.

The activation is preserved when the updates are applied incrementally, release by release. If some versions are skipped then the activation may be required again. Because of the piracy I have to change the licensing schema from time to time. Just log in into your registered account and activate it again.

 

Alex! As always, I love the software. Below is another round of some minor suggestions/feedback I've documented since my last round -- take 'em, leave 'em, mock 'em -- it's all good.

I love WFC, so hopefully they're not misconstrued as complaints. The programs I don't share feedback with are the ones I don't care enough to use/support/help

1. On alerts, the ability to have "Local port" default to grayed-out -- I've never used local-port in any outbound rules due to the wildly dynamic nature. Thus, I have to manually clear its value each and every time before setting a rule via alert. It'd be great if we could set an option to prevent this value from automatically being included in alert rules -- perhaps still initially displayed, just grayed out with an option to enable/include it in the current rule.
   
   Perhaps even better, an option to allow a user to pre-set which values are included in alert-rules by default. For example, a user could say "I only want remote-port + remote-IP pre-filled in alert rules, with the other values only manually enable-able."
   
   
2. On alerts, combine the two "panes" (informational + rule-set) into one -- Not a huge deal, it's just tedious always having to jump between the two panes, especially since I never want any rules set with "local port", so I have to edit them no matter what and can't just click allow. It'd be great if these panes were combined into one and the same -- perhaps either the initial display-values themselves being directly editable when clicked (i.e., a click changes it from text->filled textbox), or even just having the textboxes themselves function as the informational display upfront.
   
   
3. On alerts, the ability to pre-set a default temporary time -- I almost always use the same temporary-rule time, so it'd be great if a time could be defaulted, with the ability to select a non-default time via dropdown, if desired.
   
   
4. On alerts, a slight UX issue with Allow's "T(emporary)" button dropping into a context menu while Block's button immediately sets a block-until-restart rule -- I see that the buttons display what they will do when mouse-hovering on them, however, it'd still be sounder UX to have them perform the same, structurally. I've had a few temp-rules mistakenly set because I thought T-block would show me the same dropdown menu as allow's.
   
   
5. Option to allow secure-boot feature to be deactivated by the timed auto-profile-switch feature -- While I understand the need for those who want their machine on complete lockdown until they manually unfreeze it, it'd also be useful for those who just want secure-boot to protect the system during its semi-unsecured bootup routine where the system isn't fully awake, so to speak.
   
   I.e., I'd prefer my machine on total network lockdown until it's finished stretching and yawning awake from sleep, then resuming standard network operation when fully booted and alert. It's during the bootup itself that I'm concerned about, like if any possible rogue registry-set "RunOnce" program are able to sneak off some connections before my system's fully awake. After the machine's booted and alert, and any rogue programs have already been fired and had their chance to connect*, I'd feel okay allowing "Medium Filtering" to be automatically resumed after a time beyond completed bootup.
   
   I occasionally need to reboot my machine remotely, and if I've forgotten to disable secure-boot, I get remotely locked out until I arrive back home. I could script a custom workaround for this, but think it'd be useful if WFC had this option by default.
   
   *Sure, malware could be set to persistently attempt connections beyond a single run-once volley, but by the time the system's fully booted, such should be caught with medium-filtering alone. Of course, rootkits would be a whole different ballgame, but when are they not?
   
   
6. Regarding the taskbar tray icon, the ability to differentiate the color between "High filtering" icon and "Medium filtering" icon -- Currently, it's only possible to know (quickly) if low-filtering is set via its red color. It'd be nice if we could differentiate all by a quick glance at the tray, rather than having to check the menus manually.
   
   Blue would be a good choice, in my opinion, as it's figuratively opposite of red/"fire", as well as also being opposite in literal nature of low-filtering vs. high-filtering. And it could even be thought of as a frosty-cold blue with the system's network stack completely iced-over.
   
   EDIT: Upon a magnified inspection, I see "High filtering" is different! Perhaps a more obvious color contrast then? Or perhaps I just need to get my eyes checked, because it's a little difficult to differentiate between the two on quick glance
   
   
7. Ability to use easier/faster block notation for setting IP-ranges -- I know I've mentioned this before, but I'm still hoping we can get the ability to set block IP ranges quicker with faster notation, like so:
   
   192.168.1.*
   127.*.0.1-50
   *.168-169.1-2.*
   
   I know Windows' firewall doesn't officially accept this format/notation, so it would just be a WFC ability, where WFC automatically converts it into proper form behind-the-scenes. If you'd like, I could even write the program logic to do this and pass it along, if you're too busy.

 

[Bug] Found out the Bug which is also related to the notification problem for ICMPv6

It's a bug in the WFC duplicate function for ICMPv6 rule(s): the ICMP-Type is not correct duplicated! This has influence to the notification system and even for the rule purpose itself. So a originally Echo Request becomes another type after the duplicate - this can NOT see within WFC itself. A such duplicated rule does not work correctly (PING/ECHO request is no more allowed).

I sent Alexandru already a detailled bug report via mail. So it should be fixed soon ...

Alpengreis

PS: The same bug WAS for ICMPv4 too (long time ago) - that is already fixed.

 

+1 if the display for the local port remains! For some rules, the local port is interesting too - for example UPnP, Multicast, DHCP or maybe Broadcast over Port 137 ... it's rarely, but should remain - however: greyed out as default is a good idea!

I read your other suggestions yet (now I have not enough time)

Alpengreis

 

If there's already a rule with Local Port = [Any] then don't populate the value in the Notice. And if everything else is the same except the Remote port and the existing rule is [Any] and nothing else is different, then don't display a Notice at all.

 

Orange would be nice instead of grey and is the easiest for the human eye to focus on. (Green is next easiest).

But instead of check marks, why not use the letters H, M and L along with the X. Even if that might raise a question re: letter and language, at least that would be much easier to differentiate than just tick marks.
H = orange (whatever)
M = green (normal)
L = yellow (caution)
X = red (stopped)

 

Yes, if ports already allowed in a activated rule with ANY or even defined, a ACTIVE display is not necessary, do not remove it completely - grey out is better (for control purposes with exist rule(s) or so). The greyed out field should be clickable, to make it active - so if it's desired, the user could nevertheless edit the field, whatever the reason is.

The most important is: WHENEVER a connection is NOT allowed, display the necessary details - except it's blocked through a related block rule of course.

Or in other words: show all, editable as default only the not allowed things, greyed out the rest but let the user decide to make it editable too (via click).

 

I agree with you that the local port is not very wide used when defining an outbound rule. Now, you have to press a button to clear the value. If I add a new check box button that will enable/disable the local port, the users that want to set the local port will have to press on the new check box to define the local port. The same applies to the remote IP addresses. Usually, an outbound rule made for just a single IP address is not very usual.This will remain unchanged.

If you just allow/block a program from the notification dialog without opening the edit mode, then an allow/block all rule will be created for that program. You don't have to worry about local ports or other details. If you customize the rule before creating it, then the rule will contain what you input in the edit mode. Is not that simple to combine those two modes into one single mode. In the normal mode we also have extra info that is not customizable. If we will have anything customizable without entering in edit mode, which properties will be used with the original values and which ones will be used with the modified values ? Having a notification dialog full of editable text boxes doesn't looks very nice.

The current implementation does not support this because a context menu is used. I could add a textbox in the Notifications tab to set the default temporary rule time in minutes. Similar to the one that sets the notification timeout. Setting the timer to 0 will make the temporary rule to expire on WFC restart. Left click on the T button will use the default timer value. Right click will open a context menu with "Until restart" and "Timer value" entries.

I will update the behavior to the one used by the T allow choices.

This will defeat the whole purpose of the Secure Boot feature. During the "semi-unsecured boot-up" new unwanted rules may be created by other services that may start before WFC service. These rules will remain in place after the WFC service is up and running. At this point, if WFC will switch the profile back to Medium Filtering, then these new unwanted rules will be enabled. The user must review manually the rules and then decide if he wants to switch the profile from High Filtering. This is how it works. If you don't have such services on your computer, then Secure Boot is not required. You could leave Medium Filtering profile enabled and that's enough. For the "locked out" scenario you can customize the High Filtering rules to allow your remote machine still connect to your machine.

The existing colors seems very different to me. I could add the profile used in the tooltip of the system tray icon. When hovering over the icon the profile will be displayed.

If you write a generic method that can accept all input variants and which produces the correct output I will gladly integrate it in WFC. The code must be in C# (.NET 4.5). To me it doesn't seem a trivial job.

I already fixed this. The next version will include this fix.

 

@Alexandru

Full ACK to all points in your latest posting!

Thank you.

 

About the Tray-Icons ...

something like this?

 

I like these

 

[Feature Request: Natural sorting of numbers]

Now, for ex. the ports are sorted this way ...

10243
110
1701
21
2177

... it would be easier to have ...

21
110
1701
2177
10243

Alpengreis