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!

Zones that contain the 'WindowsUpdate' rule (& etc)

Zones that contain the 'WindowsUpdate' rule (& etc)

Postby Deadeye » Mon Jan 04, 2016 7:59 pm

Hi,

I like WFC and have been using it for years. Recently I reinstalled my system and moved to Windows 10 and of course one of the first things I did was upgrade & install WFC. I think WFC has evolved nicely and has made some good progress, especially in working correctly with it's default settings.

However, I'm reviewing my WFC firewall rules and am concerned about the 'http-WindowsUpdate' and 'https-WindowsUpdate' rules that are assigned to the '+Update' zones. These *-WindowsUpdate rules open up outbound ports 80 & 443 to the entire internet. The +Update zones are automatically assigned to the 'Host Process for Windows Services' executable which is where more and more spyware hides. Since WFC can't distinguish one service from another, these issues compound each other. Doesn't this mean that windows services get a free pass to connect anywhere to the internet?

In my opinion, WFC needs to be more granular in how it controls services by being able to distinguish the services opening ports from the SVCHOST.EXE process and be able to filter traffic by service. (Hint: look at the source code for ProcessHacker and PeerBlock to see how they do it)

Also, WFC needs to become better able to filter traffic by outbound address. I know this adds all sorts of complications related to IP address vs hostname filtering. Perhaps at a minimum WFC needs to provide some sort of minimal whitelisting web service that allows Microsoft's WindowsUpdate to function (while blocking the rest of their privacy invasive stuff).

Since there is now competition in the Windows Firewall Control product space, I suggest that WFC up it's game by becoming a better product by listening to it's customer requests and adding important new features such as the above. Internet privacy solutions are needed now more than ever and I expect the best product with the easiest to use, most complete privacy protection to have a bright future.

I might suggest that WFC consider open-sourcing their client software and move to a subscription service providing whitelist/blacklist services, but that's probably asking too much.
Deadeye
 
Posts: 25
Joined: Sat Aug 29, 2009 6:56 pm

Re: Zones that contain the 'WindowsUpdate' rule (& etc)

Postby PietO » Tue Jan 05, 2016 12:36 pm

possibly this approach is oke for you: works also under Win10: svchost-windowsupdates-crlupdates-strict-rules-t444.html.

Other methods (filtering on user, services of svchost . . ) were tested under Win7 but failed due to limitation of WFP of Windows-itself. Most unfortunately, the mapping of domain used by windows-update to translation to IP-addresses is not 1 to 1 (also dynamic).
PietO
 
Posts: 192
Joined: Wed Mar 02, 2011 12:09 pm

Re: Zones that contain the 'WindowsUpdate' rule (& etc)

Postby VistaFirewallControl » Tue Jan 05, 2016 12:49 pm

Thank you for the suggestions.
You are generally right but there are some hard (and sometimes) pure theoretical obstacles.

>WFC needs to be more granular in how it controls services by being able to distinguish the services opening ports from the SVCHOST.EXE process and be able to filter traffic by service.

Network/Cloud Edition offers per-user/per-service settings that can be used to distinguish traffic from different services partially. All the rest are pure WindowsFilteringPlatform (WFP) related limitations. So there is no problem to distinguish a specific process of svchost. WFP just does not allow to specify process (via PID for instance) for filtering rules. The technical background is clear more or less, the main is that PID is a mutable entity, but the firewall rules are persistent, so PID can't be used as a filtering parameter.

You could say “get rid of WFP and make your own filtering engine”. Unfortunately only WFP allows firewall creation without need of a custom kernel driver. So WFP based products may have no driver and be 100% compatible with any arbitrary software and so may be stable. If you recall old XP related firewall “competition” you will understand how the driver-less approach is important.

Regarding “https+WindowsUpdate” has not enough granularity.
That’s right. The problem is rather theoretical again. Any firewall operates with IP addresses, not with URLs or hostnames. Obviously URL is an http related entity only, but firewall is not for http filtering only. Also there are many applications that use IPs directly as well.
A hostname may be resolved to a mutable IP addresses set/range. So a strict solution for filtering hostnames using IPs instead is hardly feasible in full. However PietO and NoelC made a good progress. Please read the related posts for the details. PietO for instance offered a good idea to distinguish Windows update related traffic from the other http activity. Unfortunately the solution is not 100% strict, but the significant step was made.

You could say “why you can’t get hostname directly from the traffic and make the filtering precise”. Because of the following:
- hostname is transmitted in the network payload directly by HTTP (and successors) only. All the other protocols require IP address specified explicitly while trying to connect. Hostname-to-IP resolving is made by accessing to a DNS service and we will hardly able to find a match between DNS and payload connections of the same application. The DNS requests are made in the name of svchost generally, when an application tries to resolve hostname to IP. There is a set of proprietary protocols as well.
- HTTPS encrypts the payload. So hostname can be hardly extracted from the payload. We have been making some experiments to "conquer" HTTPS, but even the feasibility is not confirmed yet.
Once the progress is made you will see the related functionality in WxFC for sure.


> Perhaps at a minimum WFC needs to provide some sort of minimal whitelisting web service that allows Microsoft's WindowsUpdate to function (while blocking the rest of their privacy invasive stuff).

It’s hardly feasible practically. The Windows own network activity is huge and the details are not published/documented. So we will hardly be able to know what specific activity is for. So every new Windows version/update may change the behavior. The evidences exist. For instance Windows Update country dependencies were discovered.
Additionally needless to say that users security policy varies significantly. Some users (about 50%) consider Windows Update as safe and “must”, the other half of the users prefer to block WindowsUpdate at all along with the other native Windows “telemetry”. So maybe just using “-Update” zones is a good solution.


>I might suggest that WFC consider open-sourcing their client software and move to a subscription service providing whitelist/blacklist services, but that's probably asking too much.

Going to open source is an utopia in spite of whether a subscription service is involved.
Almost any “alive” open source project belongs to a “sponsor”. All the others are pure homebrew projects that are supported/developed occasionally.

Regarding while/black listing. Obviously the genuine idea is bright, but good (trusted) implementation would be hardly possible.
We faced a similar problem many years ago while trying to create an application database. The genuine idea looked bright initially. Imagine the firewall knows almost any application and offers a reasonable network permission for the application from scratch. We failed finally because of we were not able to create a “complete” applications list even of world known applications. Every new user submitted practically unique applications set. Needless to say that the suggested permissions were unique (and so conflicting) as well. Actually the users security policy varies significantly and is almost unique.

Please realize we are not “pouting”, the above is just the reality and the development is continuous.
VistaFirewallControl
Site Admin
 
Posts: 1493
Joined: Fri Mar 27, 2009 11:25 am

Re: Zones that contain the 'WindowsUpdate' rule (& etc)

Postby MACK » Fri Apr 29, 2016 5:34 pm

Several of these concerns about granularity and windows by-passing settings are pretty big security holes.

What about adding another layer such as a much smaller custom kernel driver that works side by side with Windows 10 WFC but at a pre-emptive layer and can address concerns that vanilla WFC cannot?
MACK
 
Posts: 20
Joined: Mon Aug 06, 2012 2:11 am

Re: Zones that contain the 'WindowsUpdate' rule (& etc)

Postby VistaFirewallControl » Mon May 02, 2016 10:02 am

We are working on it actually.
VistaFirewallControl
Site Admin
 
Posts: 1493
Joined: Fri Mar 27, 2009 11:25 am

Re: Zones that contain the 'WindowsUpdate' rule (& etc)

Postby MACK » Wed May 04, 2016 3:13 pm

That sounds exciting!

You have a willing purchaser here. (As long as its not too expensive...)
If you need help in alpha/beta testing... PM me please.
MACK
 
Posts: 20
Joined: Mon Aug 06, 2012 2:11 am

Re: Zones that contain the 'WindowsUpdate' rule (& etc)

Postby VistaFirewallControl » Wed May 04, 2016 3:36 pm

Thank you!
Please stay tuned, we will contact you when there is something to test.
If you are willing to play with the initial solution (or a proof of the concept (*) ) please inform us.

(*) Actually at the moment the developers are focused on a simplified command line utility that makes available per-name/domain (not per-IP only) rules creation.
After the utility is polished, the engine into WxFC integration will be started.
VistaFirewallControl
Site Admin
 
Posts: 1493
Joined: Fri Mar 27, 2009 11:25 am

Re: Zones that contain the 'WindowsUpdate' rule (& etc)

Postby MACK » Wed May 04, 2016 4:48 pm

I am interested. PM sent.
MACK
 
Posts: 20
Joined: Mon Aug 06, 2012 2:11 am


Return to What is VistaFirewallControl, features

Who is online

Users browsing this forum: No registered users and 0 guests

cron
suspicion-preferred