Appendix D: Firewall Rules and Requirements

A firewall is a key part of any organization’s protection strategy. You should have a consistent policy to manage the settings of your organization’s firewall to ensure that users are not exposed to unknown or unnecessary risk from programs that receive unsolicited data over the network. Use the information in this appendix to help draft your organization's firewall policy.

On This Page

Firewall Rules and Requirements
Application Quality
Least Privilege
Informed Consent UI

Firewall Rules and Requirements

If you are currently running on Windows XP SP2 or Windows Server 2003, please adhere to the following conditions and requirements.


Port-specific rules (permitted only when one or more of the following conditions are TRUE)

1. Customer and User Behavior

  • Empirical data is provided that shows that at least 80% of your users are or will be using a feature that requires the port within the next year.

Port-specific rules (permitted only when one or more of the following conditions are TRUE)

2. Informed Consent

The user has provided explicit informed consent (the user must be prompted for and grant informed consent for the port to be open).

  • Data showing that 80% of customers will answer “Yes” to a dialog asking them whether they want to open the port.
Program-specific rules (permitted only when all of the following conditions are true)
  1. The program does not run as a service.
  2. The program listens on the network only when the user is using the functionality that listens. This includes programs that start when the user logs in.
  3. The program can be prevented from starting automatically through a GUI.

If you are currently running on Windows Vista or Windows Server 2008, please adhere to the following conditions and requirements.

In addition to the port- and program-specific requirements for Windows XP SP2 listed earlier, the following requirements must be met for Windows Vista and Windows Server 2008.

Inbound firewall rules
  1. Applications must create rules during setup for traffic that is expected in more than 80% of installations of the application. Explicit user consent is required to enable the rules.
  2. Rules must be scoped to all these parameters—Program, Port, and Profile(s).
  3. For features that implement services, rules must also be scoped to that service.
  4. Services must implement Windows Service Hardening firewall rules.

Application Quality

Programs, applications, services, or other components that wish to receive unsolicited traffic must:

  • Produce an independent threat model for the service which identifies each entry point explicitly, including services that are “multiplexed” behind a common port.
  • Meet the network fuzzing requirements.

Least Privilege

Firewall rules must adhere to the principle of least privilege by:

  • Scoping the rule to “local subnet” or tighter when practical.
  • Scoping the rule to only the network profile(s) where the feature is likely to be used. For example, if it is an enterprise feature, then you should scope the rule to domain, private profiles. Unless you expect your feature to be used in a public place like a WiFi hotspot, you should not scope the rule to the public profile.
  • Unless your feature requires NAT traversal using transition tunnel technologies, do not set the “Edge” traversal flag.
  • Limiting the privileges of the service that use the port to Network Service or more restrictive when practical. When not practical, the threat model should explicitly call out the reasons why.

If services must run with privileges greater than Network Service, it is recommended that the services be split into “privileged” and “non-privileged” components such that only the code that requires higher privileges receives them, and other code is addressed through some IPC mechanism. The end result being that the non-privileged service is the one that receives the traffic. More information is available at

Informed Consent UI

This policy addresses user interface issues, but nothing in the policy should be interpreted to specify a particular user interface. For example, when it says “The user is informed and acknowledges the open port,” it does not imply that there must be a dialog that tells the user port 123 has been opened. The requirement is that the user is informed of the change in some explicit fashion via the UI (not an entry in a log file), and that the details are available for users who want to know.



In Windows XP SP2, this is a setting that when enabled allows unsolicited traffic through the firewall. There are two types of exceptions:

  • Port exceptions, which allow unsolicited traffic on the specified port.
  • Program exceptions, which allow a particular program to receive unsolicited traffic, regardless of port.

The setting may be enabled, which means the traffic is allowed to bypass the firewall, or disabled, which has no effect on the firewall. In Windows Vista SP1 and Windows Server 2008, this term has been replaced by inbound firewall rule.

firewall rule

Firewall rules are created to allow or block a computer sending traffic or receiving traffic over a network. Rules can be created for either inbound traffic or outbound traffic. The rule can be configured to specify traffic that matches specific programs, services, ports, and protocols.

firewall profile

A firewall profile is a way of grouping settings that are applied to the computer depending on the security profile of the network the computer is connected to.

  • On Windows Vista and Windows Server 2008, there are three profiles—domain, private, and public.
  • On Windows XP SP2, there are two profiles—domain and standard.

domain profile

This profile is applied when the computer is connected to a network in which the computer's domain account resides. Typically, this is the least restrictive profile.

private profile

This profile is applied when the computer is connected to a network like a home or small office network (without an Active Directory infrastructure).

public profile

This profile is applied when the computer is connected to a network in a public place, like a coffee shop or airport.

Windows Service Hardening

Windows Service Hardening restricts services from doing abnormal activities in the file system, registry, network, or other resources that could be used to allow malware to install itself or attack other computers. For example, the Remote Procedure Call (RPC) service can be restricted from replacing system files or modifying the registry.

Content Disclaimer

This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it.

This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2012 Microsoft Corporation. All rights reserved.

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported