vistafirewallcontrol.freeforums.org

[claudiubotezatu]

Hi,
I've just bought Win7 Firewall control, looking good/working nice.

One question, though:

I created one zone with 1 rule
"TCP208.111.161.0/24 Outgoing" and I picked from repository the grren arrow for outgoing. If I press F3 (Enable/Dissable) the "Result' for rule will change from "Enable' to greyout for "Disable" . Shouldn't change to "Dissable" instead of just being greyout?

One more thing:

The zone has , on the botom,"Zone Result"; what is that and how can a zone have a rezult as long as is just a collection of allow/deny rules?

Thanks,
Claudiu

[VistaFirewallControl]

>Shouldn't change to "Dissable" instead of just being greyout?

If a rule is not enabled (grayedout), the rule is skipped and does not participate in the traffic filtering (regardless of the RuleResult set)
So if you want the rule to work, the rule must not be grayed.
Only enabled rules follow the Result (Enable/Disable) set.


>The zone has , on the botom,"Zone Result"; what is that and how can a zone have a rezult as long as is just a collection of allow/deny rules?

The ZoneResult comes into operation if none of the specifies rules are triggered.
Imaging you have a zone with a single rule “TCP x.x.x.x Outgoing” Result=Enable.
What the FW should do if an application (with the zone applied) requests
TCP x.x.x.y Outgoing or UDP x.x.x.x Outgoing or any sort of Incoming.
The behavior is determined by the Zone result.

Practically there are two approaches while creating the zones
-Creating a zone with the ZoneResult=Enable and add disabling exceptions – the rules with the RuleResult=Disable
and vice versa
-Creating a zone with the ZoneResult=Disable and add allowing exceptions – the rules with the RuleResult=Enable

[jclarkw]

>>Practically there are two approaches while creating the zones
-Creating a zone with the ZoneResult=Enable and add disabling exceptions – the rules with the RuleResult=Disable
and vice versa
-Creating a zone with the ZoneResult=Disable and add allowing exceptions – the rules with the RuleResult=Enable<<


This seems a vitally important point (that ought to be covered in the documentation), but can you take it further?
1) Which approach do you prefer (or a mixture of the two, depending on the app)?
2) What are their relative effects on the utility of the AllAps zone?

Here are my tentative conclusions:
A) If you use the former approach, you have to itemize ALL the actions that are disabled -- potentially a tall order.
B) On the other hand, if you use the latter approach (itemizing only the relatively few actions that would be enabled in a typical app and potentially safer), aren't you effectively limiting the use of the AllAps Zone (which I presume is normally ZoneResult=Disable with only a few actions RuleResult=Enable) to only those apps without zones applied? (Maybe that's good enough to cover installers/updaters, which would not normally be in the Program List...)

If the ZoneResult of most zones is Disabled most of the time, won't the AllAps zone have very little left that it can enable?
Or am I misunderstanding the logic of AllAps relative to other zones and/or their constituent rules? What am I missing here?

Two related questions about the AllAps Zone:
3) If you have more than one installer/updater to worry about, do you just add more than one permitting rule to that zone?
4) If you want to put conditions on incoming traffic that's not application-specific (like a traditional firewall -- and maybe turn off Windows Firewall altogether?), is the AllAps Zone the means to do this? In that case, can you give a simple example?

Thanks. -- jclarkw

[VistaFirewallControl]

>1) Which approach do you prefer (or a mixture of the two, depending on the app)?

Rather depending the resulting/required policy implementation.
If you would like an application generally enabled with a set disabling exceptions – ZoneResult=Enable + a set of disabling rules.

If you would like an application generally disabled with a set enabling exceptions – ZoneResult=Disable + a set of enabling rules.

Check the repository. You can find a lot of samples there, mostly with ZoneResult=Disable, however.

>2) What are their relative effects on the utility of the AllAps zone?

We do not recommend the AllApp zone utilization until you understand the behavior in full.
AllApps zone is applied to all listed and _unlisted_ applications.
The below would be too formal but then exhaustive.
1. Without initial (or any sort of) blocking, new applications can not be detected/listed.
So if an application is permitted (with AllApps zone for instance) in advance, the app will not be detected/listed.

2. All the blocking entities are set with priorities (levels).
Any disabling item takes the supreme priority and generates “rejecting” result being found at any level
Any enabling items allows to pass to the next level. So, theoretically (W7FC does not allow that practically), if no disabling items are found at all, the activity is enabled.
So the layers
- Rules explicitly (not ZoneResults) set to the listed applications. W7FC verifies the rules of target application only obviously. If not listed – the layer is skipped.
- Rules from the allapps zone. Applied to all the applications, the both listed and unlisted
- ZoneResults from listed applications.W7FC verifies the listed applications only.
- a universal (internal/predefined) blocking rule for anything. So if nothing is specified an AllApps and the application is not listed, it will be blocked, detected and so listed.

So AllApps zone overrides only ZoneResults of listed applications and can not override the rules set to the applications.



>Here are my tentative conclusions:

You are correct generally

>aren't you effectively limiting the use of the AllAps Zone (which I presume is normally ZoneResult=Disable with only a few actions RuleResult=Enable) to only those apps without zones applied?

Please see description of the priorities. The logic is a bit more complex but more flexible at once

>(Maybe that's good enough to cover installers/updaters, which would not normally be in the Program List...)

All programs will be listed under the typical circumstances. Although there is a problem (rather a hint) of mutable installers (see the FAQ), intallers/updaters are just internet active applications from W7FC point and W7FC can’t distinguish an installation related network activity from operational network activity. The both are just activities you can permit or deny.


> If the ZoneResult of most zones is Disabled most of the time, won't the AllAps zone have very little left that it can enable?

Not at all, please review the priorities.


>Two related questions about the AllAps Zone:
3) If you have more than one installer/updater to worry about, do you just add more than one permitting rule to that zone?


Actually only mutable installers problem should be solved via AllApps. Typically installers are stable and no workarounds are required. The installers are just network applications.
Anyway if an installer is “mutable” you can (temporarily) create a set of by-IP rules for each the installer accordingly. Anyway every installer goes to a specific IP for the installation/update, so the IP can be solely permitted in AllApps

>4) If you want to put conditions on incoming traffic that's not application-specific (like a traditional firewall -- and maybe turn off Windows Firewall altogether?), is the AllAps Zone the means to do this? In that case, can you give a simple example?

Sorry, did not understand this in full. Could not be simpler to list the application first (manually at least) and set the application with explicit permissions. Could you please be more descriptive?
WindowsFirewall is an independent entity could be used or not used alongside of W7F......
Could be (especially) enabling incoming for any app unpredictably dangerous practically? .......
The main AllApps usage scenarios are mutable installers workaround and VPN (if you need to enable all the listed apps to a new save (a remote network) destination at once)

[jclarkw]

NOTE that the following edits have NOT been sanctioned by Tech Support!

>>The below would be too formal but then exhaustive.<<

Formal and exhaustive are both desirable qualities in the description of a complex logical tree like a firewall. I think much of my difficulty understanding how to use W7FC had been due to the lack of such. I encourage you to make this sequence of events even clearer and more formal and to include it prominently in your software documentation. An accompanying flow chart might be even more beneficial.

To check my understanding, I've edited your outline below [as indicated by square brackets, where practical] in an effort to make it even clearer. Since I have undoubtedly introduced new errors and ambiguities resulting from my own misunderstandings, this revised draft should be corrected by Tech Support and re-posted:

>>Without initial (or any sort of) blocking, new applications can not be detected/listed. [One danger of activating the AllApps Zone
(which is deactivated by default) is that,] if an application is permitted in advance, the app will [never] be detected/listed. [[This paragraph might be rendered unnecessary by some of the changes below.]]

[Basic Concepts:]
[A) ]All the blocking entities are set with priorities (levels) [and are checked in the logical sequence given below].
[B) ]Any disabling item takes the supreme priority and generates “rejecting” result being found at any level. [The sequential level checking terminates at that point and OverallResult=Disable is returned.]
[C) ]Any enabling items allows to pass to the next level. So, theoretically, if no disabling items [were] found at all, the activity [would be] enabled[. Nevertheless, if there is no disabling result (and if the event is not permitted by activating the AllApps Zone in the Settings tab), W7FC traps any event from an unlisted program and generates an OverallResult=DIsableAll(Detection). (Note, however, that the result of a detection can also be modified in the Settings tab.)]

Sothe [sequential] layers [are as follows:]
[1)] The program requesting network access is compared to the Program List. [If not listed – Layer 2 below is skipped.]
[2) For a program matching any entry, the] RuleResults (not ZoneResults) [explicitly] set to [that] application [are checked in order from bottom to top of the Rules list. Any violated rule sets OverallResult=Disable, and the rest of the sequential level checking terminates at that point .

**NOTE: (2) makse sense together with (4) for a zone with ZoneResult=Enable and disabling rules, but it CONNOT be correct for ZoneResult=Disable. The latter would make OverallResult=Disable even if RuleResult=Enable for all rules in the zone! Perhaps the logic of "disable trumps all" is reversed for ZoneResult=Disable? Please correct my misunderstanding. (Better yet, please provide a flow chart!)**

[3)] Rules from the allapps zone [(if it is activated in the Settings tab) are then checked. Note that this level applies] to [ALL] applications, the both listed and unlisted[. If AllAppsResult=Enable, OverallResult=Enable, and the rest of the sequential level checking terminates at that point. Otherwise, an AllAppsResult=Disable causes the testing to continue at Level 4. -- CORRECT?)]
[4) The] ZoneResult from [any] listed application [is then checked. If ZoneResult=Disable, OverallResult=Disable and the sequence is terminated.][5) Finally, a] universal (internal/predefined) blocking rule [is applied to anything that drops through this sequence.] So if nothing is specified an AllApps and the application is not listed, it will be detected and so listed. [It will also be blocked unless the default setting for detected events has been changed in the Settings tab -- IS THIS CORRECT???]

So AllApps zone overrides only ZoneResults of listed applications and can not override the rules set to the applications.<<

It should also be mentioned how (if at all) this seqeunce of levels differs in the Free version. -- jclarkw


P.S. -- I'm still hoping for an equally clear discussion of how the LANs Zone, Rule, substitution, or whatever it is operates... -- jcw

[jclarkw]

>> >>4) If you want to put conditions on incoming traffic that's not application-specific (like a traditional firewall -- and maybe turn off Windows Firewall altogether?), is the AllAps Zone the means to do this? In that case, can you give a simple example?<<

Sorry, did not understand this in full. Could not be simpler to list the application first (manually at least) and set the application with explicit permissions. Could you please be more descriptive?<<



The function of the AllApps Zone is now clear (assuming that my above edits are correct). Beyond its use for "mutable" install/update operations (which I take it from your response are relatively rare), I was trying to envision its use as a substitution for a "traditional," application-independent firewall. Based on the above logic, however, I can see that this cannot work without also preventing detection of new applications -- not a good idea!

You mentioned VPN (and in the documentation, gaming I think) as other potential applications, although my understanding of how this might work would require a specific example. -- jclarkw

[VistaFirewallControl]

>I was trying to envision its use as a substitution for a "traditional," application-independent firewall. Based on the above logic, however, I can see that this cannot work without also preventing detection of new applications -- not a good idea!

Well, compromise is compromise always.
Seems you do need a compromise, you need applications-independent fw and application detection at once. Right?
The intention is not clear in full. So what is the application detection is for, of the entire security police is applicationless?

Anyway the compromise exists.
Just do not create enabling rules in AllApps. Even typical applicationless approach is based on disabling particular network target and the entire policy is mostly enabling. Right?
If so, use (mostly) disabling rules in AllApps to retain the ability to detect new applications.
At least limit enabling AllApps rules with particular targets only.
If an ordinary applications starts, it would hardly ask for the particular target from the beginning.
Imagine you have A.B.C.D address enabled in AllApps.
It would be hard to believe an arbitrary new application started would ask http://A.B.C.D or ftp://A.B.C.D or aProtocol://A.B.C.D right from the beginning. So the application will be detected.

Also WindowsFirewall (WF) is for you as well. If you need to disable a simple per-IP set of destinations, you could use WF alongside W7FC.
Simple rules can be managed with WF easily. Only complex (per-application,IP,port,etc) rules management is mush more handy with W7FC.

>You mentioned VPN (and in the documentation, gaming I think) as other potential applications, although my understanding of how this might work would require a specific example.

If you have the formal security policy in full, the sample is evident (more or less).
You have a set of application set with required permissions. Later you obtain a VPN to access to 10.0.0.0/8 or 192.168.0.0/16 or 172.16.0.0/12 subnetworks (the addresses are from RFC specifications for free sunbetwork IP addressing, so not random). After VPN connection, your computer joins the subnetwork and (typically) as safe in the subnetwork as in the local network. The initial per-application permissions are set before the VPN availability so the VPN- unaware. All the applications adjusting is laborious. So adding a or 192.168.0.0/16 (say so) to AllApps solves the problem at once.
Is it the sample you would like to have?

[jclarkw]

>>Anyway the compromise exists.
Just do not create enabling rules in AllApps... use (mostly) disabling rules in AllApps to retain the ability to detect new applications.<<

Thanks. I had missed the point that blocking (as opposed to enabling) in AllApps drops through to the next "zone" in the testing sequence. I'm going to insert the correspond change into my re-write of your firewall logic -- post of Fri Feb 03, 2012 11:33 am, above. (Note that this kind of oversight on my part emphasizes the importance of having a flow chart to understand the logic.) Could you please check my re-wirte over and verify and/or correct it for us?


>>...Later you obtain a VPN to access to 10.0.0.0/8 or 192.168.0.0/16 or 172.16.0.0/12 subnetworks (the addresses are from RFC specifications for free sunbetwork IP addressing, so not random). After VPN connection, your computer joins the subnetwork and (typically) as safe... So adding a or 192.168.0.0/16 (say so) to AllApps solves the problem at once.
Is it the sample you would like to have?<<

Yes, exactly. (I wish more like this appeared in the manual.) I would fully understand it if I really understood the workings of the LANs option. There's a pending question on this to e-mail Tech Support that should probably be moved to its own new thread here, but I'll leave that up to them... -- jclarkw

[jclarkw]

I asked above,

>>I'm going to insert the correspond change into my re-write of your firewall logic -- post of Fri Feb 03, 2012 11:33 am, above. (Note that this kind of oversight on my part emphasizes the importance of having a flow chart to understand the logic.) Could you please check my re-wirte over and verify and/or correct it for us?<<

I still don't think I have the logic correct there, particularly the connection between RuleResult=Enable and ZoneResult=Disable in my levels 2 and 4 respectively. Could you please respond? -- jclarkw

[VistaFirewallControl]

Could you please repeat the policy you would like to implement?
We will definitely offer you the best advices for the configuration.
Otherwise the discussion would hardly be usable

>……particularly the connection between RuleResult=Enable and ZoneResult=Disable in my levels 2 and 4 respectively. Could you please respond?

The security zone is a set of rules (permissions by protocols/IPs/ports/etc) + the zone result (the final permission for the application if none of the rules is triggered)
W7FC iterates through the rules for target application, if none of the rules is matched, the final permission for the application is ZoneResult.