Welcome
Welcome to vistafirewallcontrol

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today!

HostProcess Instance Protection

HostProcess Instance Protection

Postby metal450 » Thu Dec 22, 2016 9:10 am

I’m curious about the “HostProcess individual instances protection” feature offered with the Network/Cloud version, but am not entirely clear the situations in which it might be desirable to have per-user rules. The software includes five sample zones that appear to be related:
HostProcess(loc) NoUpdates
HostProcess(net) Local+Updates
HostProcess(svchost) NoUpdates
HostProcess(svchost)+Updates
HostProcess(sys) Local+Updates

The difference between “+Updates” and “+NoUpdates” is clear - either it allows or doesn’t allow Windows Update to run. However, it looks like all 3 “+Updates” zones are identical, and the 2 “+NoUpdates” are identical. I can see that by default 4 of these 5 are applied to svchost, each as different a user: "LocalService" & "Any" get “+NoUpdates,” and "NetworkService" & "System" get “+Updates.”

So my questions:
1) If the 3 “Updates” zones are the same and the 2 “NoUpdates” zones are the same, is there a reason we'd need all these 5 – wouldn't it be the same to have just 2 total, one for “NoUpdates” and one for “Updates?”
2) Could you explain why the default config applies a "+Updates" zone to the NetworkService & System users, but a "+NoUpdates" zone to LocalService & Any? Is this intended to result in "able to run windows update" or "not able to run windows update" - as it seems to imply both simultaneously? (i.e. maybe the goal is to allow scheduled/automatic updates, but not to allow the user to manually run it?)
3) Could you provide some insight as to when & why it might be desirable to have different rules applied to svchost, depending on user? I understand why per-user rules would be valuable for "regular" software, i.e. block only a child's account from certain web activities, but in the case of this service the usages aren't quite as clear.
4) Related, I see that the Network/Cloud edition offers the ability to individually manage "Wuauserv", "Dhcp", "Dns", "Server", "Workstation," and "CryptSvc." Again, I’m curious if you could provide some examples as to why or when one might want to limit these differently; I figure that since you went to the trouble of implementing these abilities specifically, there must have been some particular use-cases that you or your users had in mind :)

Thanks!
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm

Re: HostProcess Instance Protection

Postby VistaFirewallControl » Thu Dec 22, 2016 4:17 pm

>However, it looks like all 3 “+Updates” zones are identical, and the 2 “+NoUpdates” are identical.

That’s right.
We were unable to compose strict rules for different svchost instances precisely.
The instances functionally may vary between Windows versions and update levels.
So we have no a universal predefined set.


>So my questions:
>1) If the 3 “Updates” zones are the same and the 2 “NoUpdates” zones are the same, is there a reason we'd need all these 5 – wouldn't it be the same to have just 2 total, one for “NoUpdates” and one for “Updates?”

The choice is yours.
However if you are going to implement a very strict connection policy you would need different permissions for different instances.


>2) Could you explain why the default config applies a "+Updates" zone to the NetworkService & System users, but a "+NoUpdates" zone to LocalService & Any?

LocalServices (as they are named) are local by nature.
So there are no reasons to allow them worldwide.

“Any” is useful when you have single svchost listed for all the users at once.

>Is this intended to result in "able to run windows update" or "not able to run windows update" - as it seems to imply both simultaneously?

No, please look carefully taking into account the rules priorities.

>(i.e. maybe the goal is to allow scheduled/automatic updates, but not to allow the user to manually run it?)

The both are generally equal from the network behavior point.
There may be some Windows version dependencies we did not investigate yet though.
However switching updates on and off is the general reason to change (reapply) the zones.


>) Could you provide some insight as to when & why it might be desirable to have different rules applied to svchost, depending on user? I understand why per-user rules would be valuable for "regular" software, i.e. block only a child's account from certain web activities, but in the case of this service the usages aren't quite as clear.

Svchost has multiple instances that are grouped per (system level) users
Svchost Localservice should be local only, NetworkService are for network related operations (including DNS,DHCP) , etc.
So the multiplicity is for fine grain permissions.
As the behavior may be Windows version dependent those “placeholders” may be equal.


>) Related, I see that the Network/Cloud edition offers the ability to individually manage "Wuauserv", "Dhcp", "Dns", "Server", "Workstation," and "CryptSvc." Again, I’m curious if you could provide some examples as to why or when one might want to limit these differently;


Sorry unfortunately no useful samples are available.
The first reason is the Windows version dependence, the second is some Windows related bugs.
In spite of Windows declared possibility to use a service name as a user name in full, the functionality may just not work. So the functionality was declared but not unconditionally implemented correctly. Using some service names as users may work on (say so) Windows 8.1 and may not work on Windows 7/8.
The best way to move forward on the subject is trying and gathering allowed/blocked events.
Honestly there is a not tiny set of features declared in WindowsFilteringPlatform (BFE service), but not operable in full or partially… in all Windows versions at once at least.
VistaFirewallControl
Site Admin
 
Posts: 1492
Joined: Fri Mar 27, 2009 11:25 am

Re: HostProcess Instance Protection

Postby metal450 » Thu Dec 22, 2016 7:29 pm

>>We were unable to compose strict rules for different svchost instances precisely. [...] However if you are going to implement a very strict connection policy you would need different permissions for different instances.

Yeah - I understand you might need to make different zones for different users if you wanted to customize; I guess I was just trying to understand why the software might've *included* duplicates of the same thing, which confused me into thinking "maybe they actually aren't the same, and there's some other reason why we need i.e. 3 different ones that *look* the same." Maybe they were just included as reference though, to illustrate that the user *could* customize them differently if they wanted? i.e. as they are by default, there's no reason to have 5 because 2 would do the same - but they're included just to say "hey! You could customize these differently if you wanted" ?

>>2) Could you explain why the default config applies a "+Updates" zone to the NetworkService & System users, but a "+NoUpdates" zone to LocalService & Any?

I think my question may've been a little misunderstood. I do understand the difference between the various users; my question was, more specifically, about the choice to apply an "+Updates" zone to some users and a "+NoUpdates" zone to others. It seemed to me like if the goal is to block windows updates, "+NoUpdates" would be applied everywhere, and if the goal is to allow windows updates, "+Updates" would be applied everywhere - but having these +Updates & +NoUpdates applied at the same time I found confusing. Like, what's the goal: to block windows updates or to NoBlock?

However, looking at this again, I wonder if the reason is because Windows Updates will run only under NetworkService+System. Thus, the goal of applying this way is to ALLOW Windows Updates (and the reason the other 2 users get NoUpdates is just because those users aren't relevant to performing the windows update at all, so whether you apply +Updates or +NoUpdates to those users wouldn't actually affect your ability to run updates either way)...?

>>Svchost has multiple instances that are grouped per (system level) users
Svchost Localservice should be local only, NetworkService are for network related operations (including DNS,DHCP) , etc.

I think it finally just dawned on me :)

**With applications, we can apply individual zones for each one.
**With services, we can't apply to each one. So instead, grouping by user gives us slightly more control than just "apply a zone to every service at once." So for instance, if there's a service like "Dropbox Updater," we can't apply a zone to just that one service like we could to just one Dropbox.exe, but we *can* apply a zone to all "Local System" services without affecting "Network Services." So while we don't have total granularity with services as we do with applications, this gives us a little more granularity than just applying to "all services at once." :)

>>The best way to move forward on the subject is trying and gathering allowed/blocked events.

So I guess this means just to keep an eye on the "Events" pane, and if the "User" column explicitly shows i.e. NT SERVICE/CryptSvc, it means this feature is working for that service & I can block/allow on that basis? Fwiw I'm on Win7, so is this particular feature probably best left unused in my case?

Thanks again...I think the fog is starting to clear...! :)
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm

Re: HostProcess Instance Protection

Postby VistaFirewallControl » Fri Dec 23, 2016 4:31 pm

>Maybe they were just included as reference though, to illustrate that the user *could* customize them differently if they wanted?

Actually it’s a reason.

>i.e. as they are by default, there's no reason to have 5 because 2 would do the same - but they're included just to say "hey! You could customize these differently if you wanted" ?

If there is a single zone only applied to all instances by default, there is a risk that user could accidentally modify a zone for another instances. It would be hard to notice that easily.

>I think my question may've been a little misunderstood. I do understand the difference between the various users; my question was, more specifically, about the choice to apply an "+Updates" zone to some users and a "+NoUpdates" zone to others. It seemed to me like if the goal is to block windows updates, "+NoUpdates" would be applied everywhere, and if the goal is to allow windows updates, "+Updates" would be applied everywhere - but having these +Updates & +NoUpdates applied at the same time I found confusing. Like, what's the goal: to block windows updates or to NoBlock?


Svchost (localservices) is not involved into WindowsUpdate, so there are no reasons to enable updates, to use +updates to Svchost (localservices), even if you need Windows updates allowed.



>However, looking at this again, I wonder if the reason is because Windows Updates will run only under NetworkService+System. Thus, the goal of applying this way is to ALLOW Windows Updates (and the reason the other 2 users get NoUpdates is just because those users aren't relevant to performing the windows update at all, so whether you apply +Updates or +NoUpdates to those users wouldn't actually affect your ability to run updates either way)...?

Precisely, but may be Windows version dependent.


>I think it finally just dawned on me

>**With applications, we can apply individual zones for each one.
>**With services, we can't apply to each one.

We can though. The approach is simplified, but safe enough.

>So instead, grouping by user gives us slightly more control than just "apply a zone to every service at once."

Before we start using the “more control” we have to understand the goal in full.
The policy may be wrong, may be compromise, maybe strict and maybe “paranoid”.
The latter is an attempt to block connections that will never be attempted to establish.
However no connection asked at present does not mean no the same connections asked in the future (due to various third party circumstances)
The “more control” is just by default for svchost.


>So for instance, if there's a service like "Dropbox Updater,"

Strictly speaking DropBox updater is not a good sample.
The service instance is the only, and probably launched from System account solely.


>So I guess this means just to keep an eye on the "Events" pane, and if the "User" column explicitly shows i.e. NT SERVICE/CryptSvc,

It’s a pure BFE specific. BFE declares ability to set permissions on by-service basis additionally to by-user basis. But in spite of the declaration exists, the implementation existence is foggy and Windows version dependent. So it may work and may not. It’s determined by BFE, not by the firewall. We can’t guarantee the by-service permissions unconditional operability, it’s just beyond the firewall control.

Moreover even if the by-service feature is supported by BFE on your system (with your update level), you should not expect CryptSvc (or another by-service) shown in the user column.
It's the USER column only.
In spite of by-service permissions are supported, the by-service reporting is not supported (even not declared) at all.
So if you set a by-service permission, the related events will report blocking/allowing on by-user basis. It’s just deep inside BFE.


>it means this feature is working for that service & I can block/allow on that basis? Fwiw I'm on Win7, so is this particular feature probably best left unused in my case?

It’s rather a subject of trying….. unfortunately, because of the BFE specifics.
VistaFirewallControl
Site Admin
 
Posts: 1492
Joined: Fri Mar 27, 2009 11:25 am

Re: HostProcess Instance Protection

Postby metal450 » Fri Dec 23, 2016 7:48 pm

>>We can though. The approach is simplified, but safe enough.

Wait, we can apply zones explicitly to any individual service?

>>Strictly speaking DropBox updater is not a good sample. The service instance is the only, and probably launched from System account solely.

Sorry, I didn't understand these sentences. With regards to DropBox, I was just picking a random service as an example; i.e. we can individually apply different zones to App1.exe, App2.exe, App3.exe, but we cannot individually apply zones to Service1, Service2, Service3**. Thus, I thought I understood the benefit of being able to apply zones to "Services that run as System," vs "Services that run as user," vs "Services that run as Network Service": it gives us a little more granularity than just "apply this zone to all services at once." Right?

(**This description is revised below, based on your later replies.)

>>So it may work and may not. It’s determined by BFE.

Understood that you have no control over whether or not it will work - I was just trying to determine if there's a way to know whether or not it's working. If it isn't working, then there's nothing that can be done; but if it is, then at least I'll realize it could be safe to use on my system, if desired at some later point :)

>>In spite of by-service permissions are supported, the by-service reporting is not supported

Ahh, I see. So really, although you can (maybe) block by-service, even on systems where you can, there's no way to specifically debug it - you just have to sort of "guess" which service various connections are coming from. So that brings me to revise my above paragraph: although you can individually apply zones to Service1, Service2, Service3 on *some* systems, it may not work on all systems, & even if it works you can't view specific logs. Thus, the benefit of the Network/Cloud feature mentioned at the start of the thread is that it lets you apply a zone to i.e. all "Local System" services without affecting "Network Services." So while we may not have total granularity with services as we do with applications, this gives us a little more granularity than just applying to "all services at once."
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm

Re: HostProcess Instance Protection

Postby VistaFirewallControl » Fri Dec 23, 2016 8:44 pm

>Wait, we can apply zones explicitly to any individual service?

Yes. Not “any” however. A limited set of windows predefined services only. CryptSvc, for instance is a service name, not a user name. There is no such user.



>Sorry, I didn't understand these sentences. With regards to DropBox, I was just picking a random service as an example;

Typically a service (excepting svchost) has a single instance and is launched under system account. So there is no such per-user variety.

>i.e. we can individually apply different zones to App1.exe, App2.exe, App3.exe, but we cannot individually apply zones to Service1, Service2, Service3**.

The firewall makes no difference between App.exe and Service.exe.
Any such entity is a system process. It can be launched from a specific account.
User account is a just a filtering parameter. (user just may be a service name as declared by BFE).
Anyway it’s not an arbitrary service name, it’s a set of known-to-the-system names only.
So CryptSvc may work as a service name instead of user name while specifying the user, but a Dropbox Updater will never be recognized as a service name.


>Thus, I thought I understood the benefit of being able to apply zones to "Services that run as System,"

All the services (using the Windows terminology) are launched from SYSTEM only.
The only exception is svchost.

>vs "Services that run as user,

Service can’t be launched as user. If a program is launched as user, it’s just a user program.


>" vs "Services that run as Network Service": it gives us a little more granularity than just "apply this zone to all services at once." Right?

Right, but it’s for svchost only.
In spite of it’s technically possible to launch any service from NetworkServices, there are no practical samples of that.


>Understood that you have no control over whether or not it will work - I was just trying to determine if there's a way to know whether or not it's working. If it isn't working, then there's nothing that can be done; but if it is, then at least I'll realize it could be safe to use on my system,

You should understand specific services implementation first or make a set of experiments.
Anyway we could hardly imagine a scenario of a public value. Can’t exclude something specific though.



> So that brings me to revise my above paragraph: although you can individually apply zones to Service1, Service2, Service3 on *some* systems, it may not work on all systems, & even if it works you can't view specific logs. Thus, the benefit of the Network/Cloud feature mentioned at the start of the thread is that it lets you apply a zone to i.e. all "Local System" services without affecting "Network Services." So while we may not have total granularity with services as we do with applications, this gives us a little more granularity than just applying to "all services at once."

This subject can be applied to svchost only, all the other services are launched as SYSTEM only. All the mentioned above "DNS",DHCP", "CRYPTSVC" are individual functions of svchost.
So user name can be ANY or SYSTEM and generally the both are equal from the security point as anything that is launchable from SYSTEM will never be launched from another user.
ANY is just simpler.
VistaFirewallControl
Site Admin
 
Posts: 1492
Joined: Fri Mar 27, 2009 11:25 am

Re: HostProcess Instance Protection

Postby metal450 » Thu Jan 05, 2017 12:57 am

Understood (for the most part). I guess this level of granularity probably isn't necessary for most people anyway.

Thanks for all the explanation :)
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm


Return to What is VistaFirewallControl, features

Who is online

Users browsing this forum: No registered users and 0 guests

suspicion-preferred