Windows XP SP2 Firewall - Developer Implications IPv4 inbound connections for services

[Scott Herriman]

I have a question regarding the MSDN help for Windows XP SP2 on the page,
"Firewall - Developer Implications" in the section entitled "IPv4 inbound
connections for services"
http://msdn.microsoft.com/security/productinfo/XPSP2/networkprotection/firewall_devimp.aspx

The paragrah in question reads (see link for more context):
"If the user does not consent, then the service should still use the
INetFwV4OpenPort COM interface to add rules to Windows Firewall to open the
fixed port or ports needed by the service. These rules, however, should not
be enabled so that an administrator can easily turn the rules on if
necessary at a later time."

I do not understand the last sentence? Can some one clarify what they mean.

Is this the same sentiment as found under the heading "IPv4 Inbound
Connections for Services" on another page?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/securityinxpsp2.asp
I think that on the second page they are more clear when they say:
"If the user does not consent, then the service should still use the
INetFwV4OpenPort API to add rules to ICF to open the fixed port or ports
needed by the service. However, these rules should not be enabled. "

Sorry for the cross post I think that it should be on topic for the most
part. I am hoping that one of MS guys will read this and see if they can
clearup the confusion on the page in question.

Thanks,
Scott

 

[PA Bear]

Are you participating in the beta testing of WinXP SP2, Scott? Your query
should not be posted to non-beta newsgroups (where very few "MS guys" lurk).
--
HTH - Please Reply to This Thread

~Robear Dyer (PA Bear)
MS MVP-Windows (IE/OE), AH-VSOP

AumHa Forums
http://forum.aumha.org

What You Should Know About Spyware
http://www.microsoft.com/mscorp/twc/privacy/spyware.mspx

 

[Louis Solomon [SteelBytes]]

I think it is saying that although a program can punch holes on the XP SP2
firewall without user interaction or warnings, it should have this feature
of itself able to be disabled by an admin.

 

[Michael Kleef [MSFT]]

Let me clarify:

Ill make some assumptions first.

1. We're using Windows XP SP2.
2. Windows Firewall allows outbound traffic (and associated responses for a
period of time)
3. Windows Firewall blocks inbound traffic (including app listeners running
locally on the machine) unless exceptions exist

The statement made below says that inbound traffic will not be allowed
unless you explictly add a rule to the firewall to allow the traffic inwards
and thus expose a port that your app is needing to have exposed for
communications. You can programmatically add the port exception so that the
user is not prompted when the app needs to communicate. By default, Windows
Firewall will prompt the user to open a port exception in the list if the
user agrees to the dialog UI (that was caused by the app trying to open a
listener port).

The reason this article indicates that this may not be a good idea is that
it reduces the system's administrator's ability to manage the firewall rules
centrally through Group Policy. If you do this in code and someday a
vulnerability is found that exploits this port the sys admin will have no
way to shut it down and your app could place that business at risk.

Does that help??


Michael Kleef
(e-mail address removed)
Microsoft

 

[AndyC]

It's basically all about making the end user experience as consistent and
simple as possible.

The MSFT recommended experience for an application that needs to listen to
unsolicited traffic goes something like this:

* During installation you ask if the user wants the application to be able
to listen for incoming traffic.

* If the user says Yes, then add the necessary port exceptions to the
firewall and enable them.
* If the user says No, add the necessary port exceptions but leave them
disabled.

By following this approach the user will get a consistent experience, i.e.
Your application will be listed in the Windows Firewall dialog as an option
that can be enabled or disabled wth a simple checkbox. If you don't follow
this approach then a user may get a different experience depending on their
initial choice during installation.

AndyC