The Windows Firewall: A Few Bricks Loose?
This will be a several-parts-long post concerning how I batten down the hatches of a Microsoft Windows 10 desktop before connecting it directly to the Internet for the express purpose of remote desktop access.
That gives us a reason to discuss:
- Recent trends that have loosened some of the Windows 10 inbound firewall rules.
- Managing rules in the Windows Firewall.
- Reading the log of the Windows Firewall.
- The differences between public and private Internet Protocol addresses, and trends that indicate that your PC at home may have a public address instead of a private one some time in the not-too-distant future.
- Setting up Remote Desktop Access for Windows 10 once it’s better secured and limiting the Remote Desktop Access to specific IP addresses.
Recent Firewall Changes
I have noticed in recent years that the default inbound firewall settings in desktop versions of Windows (XP, Vista, Windows 7, Windows 8 and Windows 10) have been getting looser—not that they were over-tight when first introduced with Windows XP Service Pack 3.
I took a few notes while setting up a desktop the other day. I started from what should have been a fairly secure point: I installed Windows 10 with a private IP address. During the installation, I specified that my local network was "not to be trusted." You specify that when the installation process asks you whether your network is home, work, or public. “Public” is the one not trusted.
A public IP address can be reached from any other device on the Internet. A private IP address sits behind the router, and the router by default will not let a public address reach a private address, unless the private address reached out to the public address first.
With that choice, i.e., public network, I should have had a set of fairly restrictive inbound firewall rules. If you’re sitting with your notebook computer in an airport lounge, which is what people usually think of when they think of a public network, you want security. Nope.
Let me bottom line it for you. Many of the “store” type programs that have proliferated starting with Windows 8, such as xBox, OneNote, Photos, Mail/Calendar—you know, all the ones that want to be full screen with big type and entry boxes—set up exceptions in the rules to “listen” for incoming traffic. Note: I did not include the core networking inbound rules. Those are for normal network “housekeeping” tasks. Here are the default “enabled” rules I found in that fresh, “untrusting” installation, which you can partly see in the image above, and summarized in the table below:
|xbox app||any||any||domain, public, private|
|ms cloud experience host||any||any||domain, public, private|
|ms aad broker plugin||any||any||domain|
|ms windows wireless display||any tcp||any||private|
|ms wifi direct spooler||any||any||public|
|ms wifi direct scan||any||any||public|
|ms wifi direct discover||any||any||public|
|ms wfd asp coordination||any udp||any||public|
|ms weather app||any||any||domain|
|ms store app||any||any||domain, public, private|
|ms search||any||any||domain, public, private|
|ms proximity sharing||any||any||domain, public, private|
|network discovery||tcp: 2869, 5357,5358; udp: 137, 138, 1900, 3702, 5350||any||private|
|ms news app||any||any||domain, public, private|
|msn money app||any||any||domain|
|ms photos app||any||any||public, private|
|ms edge||any||any||domain, public, private|
|ms mail/calendar app||any||any||domain, public, private|
|DIAL protocol server||tcp 10247||any||domain, private|
|ms delivery optimization||7680 tcp and udp||any||domain, public, private|
|ms contact support||any||any||public, private|
|cast to device||tcp 2869||any||domain, public, private|
|cast to device||tcp 10246, 23554, 23555, 23556||any||domain, public, private|
|cast to device||any udp||any||domain, public, private|
|cast to device||Udp 2177||any||private|
|Get Office||any||any||domain, public, private|
|MS Solitaire collection||any||any||domain|
In many of these cases, Windows starts up these programs automatically, and it’s for traffic between Microsoft and the program. The problem is that the default inbound firewall rules for those programs are sometimes open to all IP addresses, on all types of networks: public, private, and your work domain.
Let’s look at the purposes of these of enabled rules, taken from the virgin installation I just mentioned:
- Note that much is advertising and sales oriented. For example, the domain rules for applications from Microsoft, to expedite communications from Microsoft even in corporate environments.
- Microsoft Edge rules for all types of networks; to better enable all those annoying push notifications via your browser from what seems to be every other site on the Internet these days.
- A great deal of network “openings” to share wifi, entree to your friends’ and associates, and so forth. The social networking panopticon a la Microsoft.
So what could possibly happen given the loosening of the firewall rules? We’ll take the worst case. You’ve got your notebook PC in an airport, and the ISP there forgot to isolate all the connected devices from each other. Any other machine attached to the network can query your xBox app (taking just the first in the list) on the standard port for xBox communications. If the app has a vulnerability, it can be exploited.
At home, behind your router, it gets more complicated. You’ll probably be OK. It is possible, but not likely that your home router could see your PC initiating an outbound connection (because sometimes Microsoft starts the application without your knowing it). The router may assume that you wanted to establish a connection. It may then forward all traffic for xBox to your PC. But it’s not likely.
It will be likely that anyone can probe your PC if it has an external address; yet that’s what the rule says: allow any inbound traffic from anywhere on any type of network for the xBox application. And that’s just the first rule of several like it.
You probably think, “that’s no problem. I have a private address.” But that situation is changing, and that’s the subject of the next post.
Copyright Information: This article’s content by John Iacovelli, for islevue.com is licensed under a Creative Commons Attribution 4.0 International License. Permissions beyond the scope of this license may be available at mailto:email@example.com.