vistafirewallcontrol.freeforums.org

[bupov]

Hello, I would like to understand behavior of "Local+DNS+DHCP+Update(svchost)" rule. Does this rule allow outgoing communication to ports 80 and 443 for all services hosted by svchost.exe or just for Windows Update (wuauserv) service ? Thanks.

[VistaFirewallControl]

Actually "Local+DNS+DHCP+Update(svchost)" zone includes two rules allowing all instances of svchost to communicate with ports 80 and 443.
We were unable to specify the update IP as the IP varies significantly. You can do that yourself by determining/specifying your specific update servers IP(s).

W7FC identifies applications by full EXE path, so all instances of the same EXE will have the same access permissions.
Unfortunately wuauserv is just placeholder referencing svchost, not a real executable.

[bupov]

Thank you. Unfortunately you confirmed my expectations. This is one feature which I'm missing in SW firewalls products for Windows. I like that finally ate least in W7 build in firewall there is option to create rules for services based on name of specific service (placeholder) and not just for svchost.exe. Unfortunately this build in firewall has other shortcomings. Maybe combination of W7FC and build in W7 firewall is solution. E.g. set enable all communication for svchost.exe in W7FC and allow svchost.exe communications in built-in W7 firewall just for selected services (like W7 update). On other side it's not most convenient to handle firewall rules on two places.

[VistaFirewallControl]

Technically there can hardly be a possibility to distinguish svchost-for-wuauserv from other instances of svchost.
There are just no strict and formal criteria. Obviously different svchost processes have different process IDs (PIDs) , but PIDs are volatile and can not be used for the instance identification.
PIDs are just numbers assigned by the core sequentially.
From the core point there are just svchost with PID=AAA and PID=BBB, there is no way to determine what PID=AAAA is for. All the processes are equal for the core and are just processes.

W7FC and WindowsFirewall are built on the top of the same security core -WindowsFilteringPlatform (WFP) and WFP does not use PID as an identifier for the reason above probably.

If you would like to enable WindowsUpdate but not to allow all svchost-to-80/443 activity we could still recommend setting the same 80/443 enabling rules with the specific windows update IP.
The approach is rather secure as if the IPs are safe and trusted they can be expected trusted and safe for all svchost instances.
Do you need a how to suggestion?

[Deadeye]

Just curious.

I abandoned purchasing new versions or testing beta versions of Win7 Firewall Control partly because poor services blocking. I requested this feature years ago and the response was "we'll look into it".

I think I mentioned that the way to key on the various services in to use service process's the command line. To see the command line associated with all processes including services, run SysInternals Process Monitor. Right-click the column header and click 'select columns'. Go to the Process Image tab and check the 'Command Line' checkbox and hit OK. Now procmon displays the command line for each process. They're all unique and there's a lot revealed in that command line that could potentially be parsed and exploited by Win7FC.

But then, I've said all this before so it's probably a lost cause...

[Deadeye]

Yep, it's part of ther WMI API. WMIC displays it, just type "WMIC PROCESS get Caption,Commandline,Processid" to get a list of command lines and associated process ids.

[VistaFirewallControl]

It hardly helps. Anyway WindowsFilteringPlatform (WFP, the security core W7FC is based on) does not use command line,pid or so as a filtering parameter. Only EXE path. Other parameters just can not be specified to WFP
The solution is a dedicated kernel driver, but the driver presence kills the main W7FC benefits - stability and 100% compatibility.

[Deadeye]

It hardly helps. Anyway WindowsFilteringPlatform (WFP, the security core W7FC is based on) does not use command line,pid or so as a filtering parameter. Only EXE path. Other parameters just can not be specified to WFP
The solution is a dedicated kernel driver, but the driver presence kills the main W7FC benefits - stability and 100% compatibility.

If you get event notifications based on exe path, go ahead and trap on that, then get command line using WMI, then filter on that. No kernel driver required. I'm not seeing the issue (?)

[VistaFirewallControl]

Might we explain?

For instance, we have an event with svchost.exe path and without any other details. The machine has about 5-8 running instances (known PIDs and command lines) at once. Which instance produced the event? The paths of all the instances are equal. Have we missed something important?

Vice versa, we would like to set a special rule for an svchost process (PID and command lines are known), but the underling engine does not allow neither PID nor command line, only path. Evidently all the instances are on the same path.

Path is not equal to a command line the process is started with. Path is just a Disk:/folder/filename string.