Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

How do I open ports in the Windows Firewall?

How do I open ports in the Windows Firewall?

  • Comments 22

One of the side-projects I recently was assigned to work on was to switch the Windows Media Connect project from using the home-brewed HTTP server that was originally coded for the product, to using HTTP.SYS, which is included in XP SP2.  This was as a part of a company-wide initiative to remove all home-brewed HTTP servers (and there were several) and replace them with a single server.  The thinking was that having a half dozen HTTP servers in the system was a bad idea, because each of them was a potential attack vector.  Now with a single server, we have the ability to roll out fixes in a single common location.

The HTTP.SYS work was fascinating, and I’ll probably write about it more over time, but I wanted to concentrate on a single aspect of the problem.

I got the server working relatively quickly until we picked up a new version of XP SP2.  That one featured additional improvements to the firewall, and all of a sudden, the remote devices couldn’t retrieve content from the web server.  The requests weren’t getting to our service at all.  What was weird was that they WERE getting the content directory (the names of the files on the machine) but when they tried to retrieve them, they failed. 

Well, we had suspected that this was going to happen; the new build of SP2 moved HTTP.SYS behind the firewall (it had been in front of the firewall previously).  So now we needed to open a hole in the firewall for our process, the UPnP hosting service had already opened their port, that's why the content directory was available.  Over the next several posts, I’ll go through the process that I went through do discover how to do this.  Everything I needed was documented, but it wasn’t always obvious. 

The first thing we had to deal with was the fact that we only wanted to open the firewall on local subnet addresses.  To prevent users’ multimedia content from going outside their home, WMC will only accept connections from IP addresses that are in the private network IP address range (192.168.x.x) and the AutoIP address range (169.254.x.x).  We also open up the local address ranges of 10.x.x.x and 172.16.x.x (with a netmask of 0xff, 0xf0, 0, 0) .  So we only wanted to open the firewall on private IP addresses,  it would be a “bad” thing if we opened the WMC port to public addresses, since that could potentially be used as an attack vector.

The Windows firewall has been documented since Windows XP, the first MSDN hit for “internet connection firewall” returns this page that documents the API.  For XP SP2, there’s a new firewall API, if you use an MSDN search for “firewall API” the first hit is this page which describes the XP SP2 firewall API in great detail.  For a number of reasons (chief among which was that when I wrote the code the firewall API hadn’t been published), my implementation uses the original firewall API that’s existed since Windows XP.  As a result, my code and the techniques I’ve described in the next couple of posts work should work just fine on Windows XP as well as working on XP SP2.

Anyway, on with the story.  So, as always, I started with the API documentation.  After groveling through the API for a while, I realized I was going to need to use the INetSharingConfiguration interface’s AddPortMapping API to add the port.  I’d want to use the INetSharingConfiguration API on each of the IP addresses that WMC was using.

So to add a mapping for my port, I simply called INetSharingConfiguration::AddPortMapping specifying a name (in my case I used the URL for the IP address), internal and external port (the same in my case), and a string with the local IP address.  That API returned an INetSharingPortMapping object, which we have to Enable to make it effective.

Tomorrow: How do we get the INetSharingConfiguration?

Edit: Clarified IP addresses used for WMC after further investigation.

Edit: Updated link

 

  • What about 10.x.x.x or 172.[16-31].x.x? I happen to use both of these on different parts of my home network for various reasons.

    Of course, then you also have the problem with stupid ISPs.

    My ISP attempts to route 10.x.x.x addresses globally (yes, I can send something from a 10.x.x.x address to someone on a different ISP and if their routers aren't too smart it'll get through as from a 10.x.x.x address. Of course they can't reply, but that's another story). They also route them all throughout their internal network (which happens to be AT&T, so I can reach most stuff connected directly to AT&T with a 10.x.x.x address (both ways).

    I don't think such a simple filtering scheme as "block all not 192.168.x.x or 169.254.x.x" will be sufficient...
  • Interesting question Skywing. According to http://www.rfc-editor.org/rfc/rfc3330.txt you SHOULD be able to use 10.x and 172.16 (I don't know about 17-31) and WMC doesn't.

    I've forwarded it to the WMC team.

    Btw, your ISP's behavior is a really good reason for us to NOT share on 10.x.x.x - we only want to address machines in your home - the last thing that you want to have happen is for some guy in east podunk trying to listen to your music or watch your home videos.
  • Skywing, my error in my post - WMC correctly lets through 10.x.x.x and 172.16.x.x (netmask 0xff, 0xf0, 0, 0)

  • Just wondering if there is any indication by means of UI popop dialog, when a custom application tries to make changes to the Firewall via the API.
  • I hope that this can be configured through the registry. I don't want MS-apps to be too smart like this: Only accept from that IP.

    Things like this that restrict the users possibilities to use it in other ways (like sharing stuff through the internet) should never be hardcoded blocked in code! I think MS should back off a bit of the security-hype and not completely forbid everything potentially unsafe.
  • I'm currently asking the firewall guys the exact restrictions, I should have done this before posting.

    I BELIEVE that you need to be an admin to modify the firewall config, but it may be more restrictive than that.
  • Larry: Just because my ISP uses 10.x.x.x doesn't mean some other ISP doesn't use, say, 192.168.x.x or 172.16.x.x.. Plus, I've seen plenty of home networks that use (exclusively) 10.x.x.x..

    One option might be to send an ARP on the appropriate interface(s) and see if anybody replies (in order to tell if an address is "local").
  • Skywing: We're allowing 10.x.x.x. RFC 3330 clearly states that 192.168.x.x should never appear on the public internet, so if an ISP is issuing that IP address, they're supposed to put some kind of NAT-like filtering between the client and the public internet.
  • An ISP also isn't supposed to allow 10.x.x.x on the public internet, either; if they're {stupid|misconfigured} enough to allow that, who knows what else they're doing wrong :-p
  • Even if the ISP completely follows the RFCs, they have no requirement to filter between customers. If I enable promiscuous mode on my border machine, I get to watch a couple hundred people on the "private" network sending our rarps. They shouldn't be placing any trust in me just because we use the same service.
  • About firewall API restrictions: The firewall API allows anyone to read the firewall config (do a "netsh firewall show portopening" or "netsh firewall show config" sometime at the command line prompt). However administrators are the only people allowed to modify the firewall config.

    Btw, just because you have WMC in your house, even if your neighbors are on the same local subnet, it doesn't mean that your content is viewable by your neighbors - before we allow another machine (or device) to access content, we require that the user manually enable the device.
  • Thanks, Larry. It's reassuring to know that things will be safe by default. But I don't understand how users are supposed to make an informed decision that enabling the device is safe. There's a pretty technical question that they have to understand and solve (are there untrusted machines within your network block). The consequences for getting the decision wrong are pretty high. If they err towards caution, they lose cool features. If they err towards cool features, they open a vector for private data to get out and, potentially, malicious users to get in. I'm assuming that if someone has purchased WMC, it's almost certain they're going to want the cool features no matter how you phrase the question.
  • Hmm... I go to the store and buy my new Sony Roomlink, which has support for WMC in it. I buy a PC/MCIA network card for it, and plug it into my home network.

    I then go to my windows PC, and double click on the WMC control panel applet. There are two devices listed - one of them is the Sony Roomlink. The other one is an Omnifi device that I've never heard of. I go to the WMC and select the Sony Roomlink and enable it.

    Since I've never heard of the other one, I don't know what to do with it. I know I only have one of these thingys so it's not mine, it must be my neighbors. So I don't enable it.

    Until it's enabled, the devices can't access any of the content on the PC.
  • Ok, that certainly sounds like a much easier decision to make. I just have to find my device and say that it's permitted access. If there are 50 Roomlinks on the network, am I still going to be able to find out which one is mine?
  • Possibly not. The hope is that scenarios like that don't happen. But it IS possible if the technology gets widely deployed.
Page 1 of 2 (22 items) 12