Windows Firewall in Windows Server 2003 Service Pack 1

Applies To: Windows Server 2003 with SP1

What does Windows Firewall do?

Windows Firewall (previously called Internet Connection Firewall or ICF) is a software-based, stateful filtering firewall for Microsoft Windows XP and Microsoft Windows Server 2003. Windows Firewall provides protection for computers that are connected to a network by preventing unsolicited incoming traffic through TCP/IP version 4 (IPv4) and TCP/IP version 6 (IPv6). Configuration options include:

  • Configuring and enabling port-based exceptions

  • Configuring and enabling program-based exceptions

  • Configuring basic ICMP options

  • Logging dropped packets and successful connections

Windows Firewall in Windows Server 2003 Service Pack 1 is not enabled by default when the update is applied to your server. It will only be enabled in the following situations:

  • If Internet Connection Sharing was previously enabled.

  • If Internet Connection Firewall was previously enabled.

  • If the server is a new installation of Windows Server 2003 with Service Pack 1 (also known as a slipstream installation).

The best resources to help you fully understand how Windows Firewall works and how it can be used in your environment are the Windows Firewall Information and Help topics on the Windows Server 2003 Tech Center Web site at https://go.microsoft.com/fwlink/?LinkId=48911 and the Windows Firewall Operations Guide on the Windows Server 2003 TechCenter Web site at https://go.microsoft.com/fwlink/?LinkId=48912.

Note

If you decide to use Windows Firewall with your server, it is strongly recommended that you restart your servers after turning on and configuring the firewall. Windows Firewall in Windows Server 2003 with Service Pack 1 now supports application exceptions and needs to maintain the state of those applications. As a result, any applications or services that you add to the firewall exceptions list that were running prior to the firewall starting will still fail. After the server is restarted, the firewall will be running before any of the applications on the exceptions list and will be able to successfully maintain the state of the applications and handle them correctly.

Who does this feature apply to?

This feature applies to:

  • All computers that are connected to a network, including the Internet.

  • All programs (applications and services) that listen on the network.

  • All programs that do not work with stateful filtering.

What new functionality is added to this feature in Windows Server 2003 Service Pack 1?

Integration of Internet Connection Firewall and IPv6 Internet Connection Firewall into Windows Firewall

Detailed description

The version of Internet Connection Firewall that was introduced with Windows XP filtered only IPv4 traffic. IPv6 Internet Connection Firewall was introduced with the Advanced Networking Pack for Windows XP. With Windows Server 2003 Service Pack 1, Internet Connection Firewall and IPv6 Internet Connection Firewall are integrated into a single component called Windows Firewall.

With this change, any configuration change applies to both IPv4 and IPv6 traffic. For example, when a static port is opened, it is opened for both IPv4 and IPv6 traffic.

Why is this change important?

This allows for easier configuration management and application compatibility.

What works differently?

The Internet Connection Firewall service is removed from the system and replaced with the Windows Firewall service, which filters both IPv4 and IPv6 traffic. All firewall APIs are superseded by new APIs introduced with Windows Server 2003 Service Pack 1.

How do I resolve these issues?

For more information, see "Do I need to change my code to work with Windows Server 2003 Service Pack 1?" later in this document.

On-by-default for new installations of Windows Server 2003 that include a service pack

Detailed description

Windows Firewall is on by default only during new installations of Windows Server 2003 that include a service pack (also known as a slipstream release). Windows Firewall provides network protection while users update their system with the latest patches using the new Post-Setup Security Updates feature. As soon as the updates are finished the firewall is turned off unless it was explicitly enabled.

If a server running Windows Server 2003 is updated or upgraded to Service Pack 1 the firewall is off by default and the Post Setup Security Updates feature is not used.

Why is this change important? What threats does it help mitigate?

By enabling Windows Firewall by default on new installations, the computer has more protection from many network-based attacks while it is being set up and configured. For example, if Windows Firewall had been enabled by default, the MSBlaster attack would have been greatly reduced in impact, whether or not users had installed the relevant updates on their computers.

What works differently?

After a new installation of a slipstream version of Windows Server 2003 with Service Pack 1, Windows Firewall is enabled by default and incoming traffic is blocked until after Post-Setup Security Updates have been completed. This might create application or service incompatibility if the application or service does not work with stateful filtering by default.

How do I resolve these issues?

Complete Post-Setup Security Updates, which will automatically turn off the firewall, before proceeding with any other server configuration tasks.

It is also possible to configure the firewall to work with applications or services you need to use, if you don’t want to complete Post-Setup Security Updates until a later time.

Configuration by the Security Configuration Wizard

Detailed description

The recommended means of turning on Windows Firewall and performing its initial configuration for Windows Server 2003 with Service Pack 1 is to use the Security Configuration Wizard (SCW). SCW will automatically turn on Windows Firewall and create the appropriate settings based on the needs of your server. For more information about SCW, see "Security Configuration Wizard", in this document.

Why is this change important?

Some server components and applications should not be used with Windows Firewall or should be used in very specific configurations. SCW has been designed to help you determine the recommended settings for the Windows Firewall based on your environment.

Boot-time security

Detailed description

In earlier versions of Windows, there is a period of time between when the network stack comes up and when Internet Connection Firewall provides protection. This results in the ability for a packet to be received and delivered to a service without Internet Connection Firewall providing filtering and potentially exposes the computer to vulnerabilities. This was due to the firewall driver not starting to filter until the firewall user-mode service was loaded and had applied appropriate policy settings. The firewall service has a number of dependencies, which causes the service to wait until those dependencies are cleared before it pushes the policy down to the driver. This time period is based upon the speed of the computer.

In Windows Server 2003 Service Pack 1, the IPv4 and IPv6 firewall drivers have a static rule to perform stateful filtering. This static rule is called a boot-time policy. This allows the computer to perform basic networking functions such as DNS and DHCP and communicate with a domain controller to obtain policy settings. After the Windows Firewall service is running, it loads and applies the runtime policy settings. The boot-time policy cannot be configured.

There is no boot-time security if the Windows Firewall service (which is listed as Windows Firewall/Internet Connection Sharing (ICS) in the Service Control Manager) is set to either Manual or Disabled.

Why is this change important? What threats does it help mitigate?

With this change, the computer is open to fewer attacks during startup and shutdown.

What works differently?

If the Windows Firewall service fails to start, boot-time security remains in effect. This means that all incoming connections are blocked. In this case, an administrator will not be able to remotely troubleshoot the issue because all the ports will be closed, including the port used by Remote Desktop.

If a service attempts to start before the firewall service a "race condition" might result. If a necessary service is blocked by this condition you will need to disable Windows Firewall.

How do I resolve these issues?

To turn off boot-time security, stop the Windows Firewall/Internet Connection Sharing (ICS) service and set its startup type to either Manual or Disabled.

If the computer is in boot-time security mode because the firewall service has not started, an administrator must log on to the computer, resolve the cause of the failure, and then manually start the firewall service.

Running in safe mode (Safe mode firewall)

Detailed description

The firewall state is maintained when the server is started in safe mode.

Why is this change important?

With this change your computer is less vulnerable to attack when starting in safe mode with network connectivity.

What works differently?

In previous versions, Internet Connection Firewall was not available when running in safe mode.

Global configuration

Detailed description

In earlier versions of Windows, Internet Connection Firewall was configured on a per-interface basis. This meant that each network connection had its own set of firewall settings, for example, one set of settings for wireless, another set of settings for Ethernet. This made it difficult to synchronize firewall settings between connections. Additionally, new connections would not have any of the configuration changes that had been applied to the existing connections. Non-standard network connections, such as those created by proprietary dialers (for instance, ISP-configured dial-up networking connections) could not be protected.

With global configuration in Windows Firewall, whenever a configuration change occurs, it automatically applies to all network connections in the Network Connections folder, as well as any non-Microsoft dialers. When new connections are created, the configuration is applied to them as well. Configuration can still be performed on a per-interface basis. Non-standard network connections will have only global configuration. Configuration changes also apply to both IPv4 and IPv6.

Why is this change important?

Having global configuration makes it easier for users to manage their firewall policy across all network connections and enables configuration through Group Policy. It also allows you to enable applications to work on any interface with a single configuration option.

What works differently?

In earlier versions of Windows Server, firewall configuration was on a per-interface basis. In Windows Server 2003 Service Pack 1, the configuration is global and applies to both IPv4 and IPv6.

How do I resolve these issues?

If your application or service requires static openings to work, you should open the ports globally, as described later in this topic, in "Do I need to change my code to work with Windows Server 2003 Service Pack 1?"

Audit logging

Detailed description

Audit logging enables you to track changes that are made to Windows Firewall settings and to see which applications and services asked your computer to listen on a port. After audit logging is enabled, audit events will be logged in the security event log. Audit logging can be enabled on client computers running Windows XP Service Pack 2 and servers running Windows Server 2003 Service Pack 1. You can use the following procedure to enable audit logging on your computer.

To enable audit logging

  1. Log on using an account that is a local administrator.

  2. Click Start, click Control Panel, and then click Administrative Tools.

  3. In Administrative Tools, double-click Local Security Policy to open the Local Security Settings console.

  4. In the console tree of the Local Security Settings console, click Local Policies, and then click Audit Policy.

  5. In the details pane of the Local Security Settings console, double-click Audit policy change. Select Success and Failure, and then click OK.

  6. In the details pane of the Local Security Settings console, double-click Audit process tracking. Select Success and Failure, and then click OK.

You can also enable audit logging for multiple computers in an Active Directory directory service domain using Group Policy by modifying the Audit policy change and Audit process tracking settings at Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy for the Group Policy objects in the appropriate domain system containers.

After audit logging is enabled, you can use the Event Viewer snap-in to view audit events in the security event log.

Windows Firewall uses the following event IDs:

  • 848 - Displays the startup configuration of Windows Firewall.

  • 849 - Displays an application exception configuration.

  • 850 - Displays a port exception configuration.

  • 851 - Displays a change made to the application exceptions list.

  • 852 - Displays a change made to the port exceptions list.

  • 853 - Displays a change made to the Windows Firewall operation mode.

  • 854 - Displays a change made to Windows Firewall logging settings.

  • 855 - Displays a change made to ICMP settings.

  • 856 - Displays a change made to the Prohibit unicast response to multicast or broadcast requests setting.

  • 857 - Displays a change made to the Remote Administration setting.

  • 858 - Displays the application of Windows Firewall Group Policy settings.

  • 859 - Displays the removal of Windows Firewall Group Policy settings.

  • 860 - Displays a change made to a different profile.

  • 861 - Displays an application attempting to listen for incoming traffic.

Why is this change important?

Auditing the activity of Windows Firewall is part of a defense in depth strategy because it can be used to alert you to malicious software that is attempting to modify firewall settings. Auditing also generally helps administrators determine the network needs of their applications and design an appropriate policy for deployment to large numbers of users.

Traffic scoping for exceptions

Detailed description

ICF allowed excepted traffic to come from any IPv4 address. With Windows Firewall in Windows Server 2003 with Service Pack 1, you can also configure an exception to allow incoming traffic only from addresses that are directly reachable by selecting the My network (subnet) only scope option (based on entries in the IPv4 and IPv6 routing table), or from specific IPv4 address ranges by selecting the Custom list scope option.

For computers in a workgroup, some exceptions are restricted to locally reachable addresses by default. These exceptions are those needed for file and printer sharing and the UPnP framework. Additionally, when these exceptions are opened for locally reachable addresses on an Internet Connection Sharing (ICS) host, the exceptions will not be opened on the ICS public interface. If you enable these exceptions for all possible addresses they will be opened on the ICS public interface, which is not recommended. When the File and Printer Sharing built-in exception is enabled with the NetShare application programming interface (API), with the Network Setup Wizard, or through the Windows Firewall user interface, incoming file and printer sharing connection requests can come only from directly reachable addresses by default.

If you are enabling Windows Firewall on a server that is already configured for file and printer sharing, the File and Printer Sharing exception might be enabled automatically. It is recommended that you apply the locally reachable addresses restriction to any exception that is used for communicating on the local network. It can be done programmatically at the command line using Windows Firewall Netsh Helper, or by clicking Windows Firewall in Control Panel.

Note

As a best practice, identify custom scopes with specific addresses or subnets for the exceptions that you specify for Windows Firewall. When you configure and enable an exception, you are instructing Windows Firewall to allow specific unsolicited incoming traffic sent from the specified scope (from any address, from an address that can be reached directly, or from a custom list). For any scope, enabling an exception makes the computer accessible to attacks based on incoming unsolicited traffic from computers that are assigned the allowed addresses and from malicious computers that spoof traffic. There is no way to prevent spoofed attacks from the Internet on connections assigned public IPv4 addresses except by disabling the exception. Therefore, you should try to configure scope options so that the number of computers that are allowed to send unsolicited traffic through an exception is kept to a minimum. This will reduce, but not eliminate, the likelihood of a spoof attack. If your organizational security policy requires you to ensure that no one outside your network can access a resource, then you should consider using an approach such as IPsec that supports network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection.

Why is this change important? What threats does it help mitigate?

Some applications need to communicate only with other computers on the local network and not computers on the Internet. Configuring Windows Firewall to allow only traffic from locally reachable addresses or from specific address ranges corresponding to locally attached subnets restricts the set of addresses from which unsolicited incoming traffic can be accepted. This mitigates, but does not eliminate, attacks that can occur for enabled exceptions.

What works differently?

When the File and Printer Sharing or the UPnP framework built-in exception is enabled using the Control Panel on a computer that is a member of a workgroup, the locally reachable addresses scope is applied to the ports opened. If an application or service also uses these ports, it will be able to communicate only with other nodes that are assigned locally reachable addresses. However, if the computer is a member of a domain, the global scope is applied.

If these exceptions are enabled using an API call or using Netsh.exe instead of from Control Panel, the default scope setting is locally reachable addresses, regardless of whether the computer is a member of a workgroup or a domain.

How do I resolve these issues?

If your application or service does not work with this type of restriction, you should open the port for any computer, as described in "Do I need to change my code to work with Windows Server 2003 Service Pack 1?" later in this document.

Command-line support

Detailed description

The Windows Firewall Netsh Helper was added to Windows XP in the Advanced Networking Pack. This helper applied only to IPv6 Windows Firewall. With Windows Server 2003 Service Pack 1, the structure and syntax of the helper changed and expanded to include support for configuring IPv4 as well. With the Netsh Helper, you can fully configure Windows Firewall, including:

  • Configure the default state of Windows Firewall (Off, On, On with no exceptions).

  • Configure the ports that must be open.

  • Configure the ports to enable global access or to restrict access to the local subnet.

  • Set ports to be open on all interfaces or only on a specific interface.

  • Configure the logging options.

  • Configure the Internet Control Message Protocol (ICMP) handling options.

  • Configure and enable program-based exceptions.

Windows Firewall configuration and status information can be retrieved at the command line by using the Netsh.execontext: firewall.

To use this context, type netsh firewall at a command prompt, and then use additional Netsh commands as needed.

The following commands are useful for gathering firewall status and configuration information and can be useful for troubleshooting the operation of your firewall:

  • Netsh firewall show state

  • Netsh firewall show config

The following commands can be used to modify the configuration of Windows Firewall.

Command Description

add allowedprogram

Used to add excepted traffic by specifying the program's file name.

set allowedprogram

Used to modify the settings of an existing allowed program exception.

delete allowedprogram

Used to delete an existing allowed program exception.

set icmpsetting

Used to specify allowed ICMP traffic.

set logging

Used to specify logging options.

set notifications

Used to specify whether notifications to the user when programs try to open ports are enabled.

set opmode

Used to specify the operating mode of Windows Firewall either globally or for a specific connection (interface).

add portopening

Used to add excepted traffic by specifying a TCP or UDP port.

set portopening

Used to modify the settings of an existing open TCP or UDP port exception.

delete portopening

Used to delete an existing open TCP or UDP port exception.

set service

Used to enable or drop RPC and DCOM traffic, Remote Desktop, file and printer sharing, and UPnP traffic.

reset

Resets firewall configuration to Default. This provides the same functionality as the Restore Defaults button in Control Panel/Windows Firewall.

The following table details the show commands supported for Windows Firewall.

Command Description

show allowedprogram

Displays the allowed programs.

show config

Displays the detailed local configuration information.

show currentprofile

Displays the current profile.

show icmpsetting

Displays the ICMP settings.

show logging

Displays the logging settings.

show notification settings

Displays the current settings for notifications.

show opmode

Displays the operational mode for profiles and interfaces.

show portopening

Displays the excepted ports.

show service

Displays the services exception settings.

show state

Displays the current state information.

You can compare the output from these commands with the output from the netstat –ano command to identify the programs that may have listening ports open and that do not have corresponding exceptions in the firewall configuration.

Why is this change important?

Providing a command-line interface provides administrators with a method to configure Windows Firewall without going through the graphical user interface. The command-line interface can be used in logon scripts and remote management.

What works differently?

Any script that was created with the Netsh Helper that was made available with the Advanced Networking Pack for Windows XP no longer works and must be updated.

How do I resolve these issues?

Update any scripts you might have so that they include the new firewall context and syntax.

"On with no exceptions" operational mode

Detailed description

Windows Firewall can be configured for exceptions to allow specific unsolicited incoming traffic during normal use. Typically, this is because key scenarios, like file and printer sharing, must be enabled. If a security issue is discovered in one or more of the listening services or applications that are running on the computer, it may be necessary for the computer to switch into a client-only mode, which is called "On with no exceptions." Switching into this client-only mode configures Windows Firewall to prevent all unsolicited incoming traffic without having to reconfigure the firewall.

When in this mode, all exceptions are temporarily disabled and any existing connections are dropped. Any application interface that calls into Windows Firewall to create an exception is allowed and the requested firewall configuration is stored, but it is not enabled until the operational mode switches back to normal operation. All listen requests by applications are also ignored and notification dialogs are not displayed, effectively blocking the application from listening on a port while the computer is in this operational mode.

Why is this change important?

When a network system is under attack by viruses, worms, and other attackers, the attacker looks for services to exploit. The “On with no exceptions” operational mode provides a way for you to quickly lock-down your system in the event of an attack so that valid exceptions cannot be used to circumvent the protection provided to your computer by Windows Firewall.

What works differently?

When in this operational mode, the computer cannot listen for requests that originate from the network. Any existing incoming connections are terminated. Outgoing connections are the only connections that succeed.

How do I resolve these issues?

When in this operational mode, it is expected that some functionality will fail because of the strict network security in place. You can restore functionality by returning the operational mode to On. This action should be performed by the user only after the threat has been identified and mitigated, because the security of the computer is reduced by performing this action.

Program-based exceptions

Detailed description

Some programs (applications or services) act as both network clients and servers. When they act as servers, they must allow unsolicited incoming traffic, because they do not know in advance who the peer will be.

In earlier versions of Windows, a program needed to call the firewall APIs to enable the necessary listening ports to be open. This proved difficult in peer-to-peer situations when the port was not known in advance. It was up to the program to close the port again after communication was completed. If the program terminated unexpectedly this could result in unnecessary open ports in the firewall.

An additional issue with the previous method of opening firewall ports was that ports could be opened only if programs were running in the security context of a local administrator. This violated the basic information security principle of least privilege by requiring programs to run in an administrative context, rather than only with the minimum necessary privileges.

In Windows Server 2003 with Service Pack 1, a program that needs to listen to the network can be added to the Windows Firewall exceptions list. If a program is enabled on the Windows Firewall exceptions list, Windows Firewall opens and closes the necessary listening ports automatically, regardless of the program’s security context. For more information about adding programs to the Windows Firewall exceptions list, see "How do I resolve these issues?" later in this document.

Programs that work with stateful filtering do not need to be placed on the Windows Firewall exceptions list. Only administrators can add a program to the Windows Firewall exceptions list.

Why is this change important? What threats does it help mitigate?

When a program is on the Windows Firewall exceptions list, only the necessary ports are opened, and they are opened only for the duration that the program is listening on those ports.

What works differently?

If a program needs to listen on the network, it must be enabled on the Windows Firewall exceptions list. If it is not, then the necessary port in Windows Firewall is not opened and the program will not be able to receive unsolicited inbound traffic.

How do I resolve these issues?

A program can be placed on the Windows Firewall exceptions list in five ways:

  1. Programmatically. It is recommended that independent software vendors (ISVs) place their programs on the Windows Firewall exceptions list during installation. For more information about how to programmatically add a program to the exceptions list, see "Do I need to change my code to work with Windows Server 2003 Service Pack 1?" later in this section.

  2. Command-line interface. This method can be used by IT administrators who manage Windows XP and Windows Server 2003 systems using scripts or other command-line tools.

  3. Group Policy settings. This method can be used by IT administrators to add the program to the exceptions list through Group Policy.

  4. Windows Firewall notification message. A user with Administrator rights can interact with the Windows Firewall notification message and add the application to the exceptions list.

    When an application performs a TCP listen or UDP bind to a non-wildcard port, the network stack passes the application name and port to Windows Firewall. Windows Firewall looks up the application name on the exceptions list. If the application is on the exceptions list and enabled, then the corresponding port is opened in the firewall. If the application is on the exceptions list and disabled, then the corresponding port is not opened. If the application is not on the exceptions list, then users are asked to make a choice. If the users have administrative rights, they can:

    • Unblock the application to allow it to listen on the network. It is added to the exceptions list as Enabled and the port is opened.

    • Block the application from listening on the network. It is added to the exceptions list as Disabled and the port is not opened.

    • Choose to be asked again later. The application is not added to the exceptions list and the port is not opened.

    If the user does not have administrative rights, the user is notified that the application is not allowed to listen on the network and that an Administrator must enable the program exception. If the user selects the Do not ask me again check box, the application is listed in the exceptions list as Disabled.

    Note

    Notification messages can only be used with applications. They cannot be used with services.

  5. Manual configuration. Administrators can decide to enable a program manually in the Windows Firewall control panel by selecting it from a list that is populated from the list of programs in the Start menu or by browsing for the program.

Multiple profiles

Detailed description

Multiple profile support in Windows Firewall allows you to create two sets of firewall policy settings: one for when the computer is connected to a managed network and one for when the computer is not. You can specify settings that are less strict when the computer is connected to the corporate network to enable line-of-business applications to work. You can also have more aggressive security policy settings that will be enforced when the computer leaves the corporate network, which helps to protect mobile users.

Note

Multiple profiles for Windows Firewall apply only to computers that are joined to an Active Directory domain. Computers that are in a workgroup use only one profile.

Why is this change important? What threats does it help mitigate?

For a mobile computer, it is desirable to have more than one firewall configuration. Often, a configuration that is safe on a corporate network is likely to be susceptible to attack on the Internet. Therefore, being able to have ports opened on the corporate network and not on other networks is critical to ensuring that only the necessary ports are exposed at any given time.

What works differently?

If an application needs to be listed in the Windows Firewall exceptions list in order to work correctly, it might not work on both networks as the two profiles might not have the same set of policy settings. For an application to work on all networks, it must be listed in both profiles. For more information about the Windows Firewall exceptions list, see the earlier section.

How do I resolve these issues?

If the computer is joined to a domain, you must ensure that the application is listed in both firewall configurations. Consider creating exceptions though the command-line interface or Group Policy as you will only have access to the currently running profile through Windows Firewall in Control Panel.

RPC support for System Services

Detailed description

In earlier versions of Windows, Internet Connection Firewall blocked remote procedure call (RPC) communication. While Internet Connection Firewall could be configured to allow network traffic to the RPC Endpoint Mapper, the port that an RPC server used was unknown and the application would still fail.

Many enterprise applications and components fail if RPC is not allowed to communicate over the network. Some examples include, but are not limited to, the following:

  • Remote administration, such as the Computer Management feature and the Select User, Computers, and Groups dialog box, which is used by many applications

  • Remote Windows Management Instrumentation (WMI) configuration

  • Scripts that manage remote clients and servers

RPC opens several ports and then exposes many different servers on those ports. It then requests that Windows Firewall create associated exceptions for these ports. If Windows Firewall is configured to allow such requests, the required ports will be opened for as long as RPC needs the exception (similar to a program exception).

Why is this change important? What threats does it help mitigate?

In order to enable remote administration scenarios, many enterprise-wide deployments require that the system services that use RPC work with Windows Firewall by default.

What works differently?

By default, RPC does not function through Windows Firewall. All system services that use RPC are affected. However, Windows Firewall can be configured to allow RPC to work for these services using the remote administration setting. This setting also enables exceptions for the RPC Endpoint Mapper (TCP 135), SMB over TCP (TCP 445), and ICMP echo requests.

How do I resolve these issues?

See "Do I need to change my code to work with Windows Server 2003 Service Pack 1?" later in this document.

Restore defaults

Detailed description

Previously, there was no way for a user to reset the configuration of Internet Connection Firewall (ICF). Over time, the firewall might be configured to allow unsolicited incoming traffic to ports no longer used by other applications. This might make it difficult for the user to easily and quickly go back to a default configuration.

This option enables the user to restore Windows Firewall settings to their original defaults. In addition, the Windows Firewall defaults can be modified by original equipment manufacturers (OEMs) and businesses to provide custom default configuration options.

Why is this change important?

This option allows end-users to restore their Windows Firewall settings to the out-of-the-box defaults.

What works differently?

No functional changes in Windows Firewall result from this addition. However, use of this feature disables Internet Connection Sharing and Network Bridge.

Unattended setup support

Detailed description

In earlier versions of Windows, it was not possible to configure Internet Connection Firewall during installation. This made it difficult for OEMs and businesses to preconfigure Internet Connection Firewall before distributing a computer to their end users. In Windows Server 2003 with Service Pack 1, you can configure the following options of Windows Firewall through unattended setup:

  • Operational mode

  • Applications on the Windows Firewall exception list

  • Static ports on the exception list

  • ICMP options

  • Logging options

Why is this change important?

A method to preconfigure Windows Firewall allows Windows resellers and large enterprises more flexibility and customization options for Windows Firewall.

What works differently?

This feature adds configuration flexibility to Windows Firewall. No functional changes in Windows Firewall result from this addition.

The syntax used to enable or disable ICF in an unattend script has been replaced with the new syntax for Windows Firewall.

The sections of the Unattend.txt file for Windows Firewall configuration consist of the following:

  • [WindowsFirewall]

    A required section that defines which profiles to use and Windows Firewall log file settings.

  • [WindowsFirewall.profile_name]

    The domain profile section, [WindowsFirewall.Domain], contains settings for when a computer is connected to a network that contains domain controllers for the domain of which the computer is a member. The standard profile, [WindowsFirewall.Standard], contains settings for when a computer is not connected to a network that contains domain controllers for the domain of which the computer is a member. If you do not want Windows Firewall to be used you can specify Profiles = WindowsFirewall.TurnOffFirewall

    The [WindowsFirewall.profile_name] section is a user-defined section that is referenced by the [WindowsFirewall] section to make changes to Windows Firewall's default configuration, including programs, services, ports, and ICMP settings.

  • [WindowsFirewall.program_name]

    A user-defined section that adds a program to the Windows Firewall exceptions list.

  • [WindowsFirewall.service_name]

    A user-defined section that adds a predefined service to the Windows Firewall exceptions list (such as file and printer sharing, UPnP framework, Remote Desktop service, and Remote Administration).

  • [WindowsFirewall.portopening_name]

    A user-defined section that adds a port to the Windows Firewall exceptions list.

  • [WindowsFirewall.icmpsetting_name]

    A user-defined section that adds ICMP message types to the Windows Firewall exceptions list.

What existing functionality is changing in Windows Server 2003 Service Pack 1?

Enhanced multicast and broadcast support

Detailed description

Multicast and broadcast network traffic differs from unicast traffic because the response comes from an unknown host. As such, stateful filtering prevents the response from being accepted. This stops a number of scenarios from working, ranging from streaming media to discovery.

To enable these scenarios, Windows Firewall will allow a unicast response for three seconds from any directly reachable source address on the same port from which the multicast or broadcast traffic originated.

Why is this change important? What threats does it help mitigate?

This allows applications and services that use multicast and broadcast for communicating to work without either the user or application/service needing to alter the firewall policy. This is important for things like NETBIOS over TCP/IP, so that sensitive ports such as port 135 are not exposed.

What works differently? Are there any dependencies?

In Windows Server 2003, Internet Connection Firewall statefully filtered multicast and broadcast traffic, which required the user to manually open the port to receive the response. In Windows Server 2003 Service Pack 1, Windows Firewall accepts the response to the multicast or broadcast traffic without additional configuration.

Updated user interface

Detailed description

The firewall user interface is updated in Windows Server 2003 Service Pack 1 to accommodate the new configuration options and the integration of IPv6 Internet Connection Firewall. The new Windows Firewall interface provides the user with the ability to change the operational states, the global configuration, logging options, and ICMP options.

The primary entry to the user interface has been moved from the Properties dialog box of the connection to a Control Panel icon. A link from the old location is still provided. Additionally, Windows Server 2003 Service Pack 1 creates a link from the Network Connections folder.

Why is this change important?

The functionality that is added in Windows Server 2003 Service Pack 1 required updates to the user interface.

What works differently?

The user interface is moved from the Advanced tab of the network connection’s Properties dialog box to a specific Windows Firewall icon in Control Panel.

New Group Policy support

Detailed description

In earlier versions of Windows, Internet Connection Firewall had a single Group Policy object (GPO): Prohibit Use of Internet Connection Firewall on your DNS domain network. With Windows Server 2003 Service Pack 1, every global configuration option can be set through Group Policy. Examples of the new configuration options available include:

  • Define program exceptions

  • Allow local program exceptions

  • Allow ICMP exceptions

  • Prohibit notifications

  • Allow file and printer sharing exception

  • Allow logging

Each of these objects can be set for both the corporate and standard profile. For more information about Group Policy options, see "Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2" in the Microsoft Download Center at https://go.microsoft.com/fwlink/?linkid=23277. This document also covers developments in Windows Server 2003 Service Pack 1.

Why is this change important?

It is important for administrators to centrally manage Windows Firewall policy settings to enable applications and scenarios to work in the corporate environment.

What works differently?

The IT administrator can now decide the default Windows Firewall policy set. This can either enable or disable applications and scenarios. This allows more control, but the policies do not change the underlying functionality of Windows Firewall.

What settings are added or changed in Windows Server 2003 Service Pack 1?

Setting name Location Previous default value Default value Possible values

Protect all network connections

(Group Policy object) Computer Configuration \Administrative Templates \Network\Network Connections\ \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Do not allow exceptions

(Group Policy object) Computer Configuration \Administrative Templates \Network\Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Define program exceptions

(Group Policy object) Computer Configuration \Administrative Templates \Network\Network Connections \Windows Firewall

Not applicable

Not configured

Enabled [Program path] [Scope]

Disabled

Allow local program exceptions

(Group Policy object) Computer Configuration \Administrative Templates \Network\Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Allow remote administration exception

(Group Policy object) Computer Configuration \Administrative Templates \Network\Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Allow file and printer sharing exception

(Group Policy object) Computer Configuration \Administrative Templates \Network\Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Allow ICMP exceptions

(Group Policy object) Computer Configuration \Administrative Templates \Network\Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Once enabled, select which of the following message types to allow:

[Allow outbound destination unreachable]

[Allow outbound source quench]

[Allow redirect]

[Allow inbound echo request]

[Allow outbound time exceeded]

[Allow outbound parameter problem]

[Allow inbound timestamp request]

[Allow inbound mask request]

[Allow outbound packets too bug]

Disabled

Allow remote desktop exception

(Group Policy object) Computer Configuration \Administrative Templates \Network\Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Allow UPnP framework exception

(Group Policy object) Computer Configuration \Administrative Templates \Network\Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Prohibit notifications

(Group Policy object) Computer Configuration \Administrative Templates\Network \Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Allow logging

(Group Policy object) Computer Configuration \Administrative Templates\Network \Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Prohibit unicast response to multicast or broadcast requests

(Group Policy object) Computer Configuration \Administrative Templates\Network \Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Define port exceptions

(Group Policy object) Computer Configuration \Administrative Templates\Network \Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Allow local port exceptions

(Group Policy object) Computer Configuration \Administrative Templates\Network \Network Connections \Windows Firewall

Not applicable

Not configured

Enabled

Disabled

Do I need to change my code to work with Windows Server 2003 Service Pack 1?

We recommend that you use the Security Configuration Wizard to configure Windows Firewall for use with Windows Server 2003 Service Pack 1. SCW is designed to accommodate the requirements of different server roles and workloads and configure the firewall settings correctly. If you are going to manually configure your firewall settings, review the following information for how your applications might be affected.

Outbound connections

Description

For typical consumer and office computers, the computer is a client on the network. Software on the computer connects out to a server (an outbound connection) and gets responses back from the server. Windows Firewall allows all outbound connections, but applies rules to the types of communication that are allowed back into the computer.

Some examples of tasks involving Microsoft applications that might work this way include:

  • Surfing the Web using Microsoft Internet Explorer.

  • Checking e-mail in Outlook Express.

  • Chatting in MSN Messenger or Windows Messenger.

Action Required

None. Windows Firewall will automatically allow all outbound connections, regardless of the program and the user context.

Note

When a computer initiates a TCP session request to a target computer, it will accept a response only from that target computer. When the computer sends UDP packets, Windows Firewall allows UDP responses to the port from which the UDP packets were sent from any IP address for approximately 90 seconds. Unicast responses to multicast and broadcast traffic are allowed through Windows Firewall for three seconds if the responses are to the port from which the traffic was sent and are from IP addresses on the same subnet as the computer. A setting in the firewall controls this behavior, which is enabled by default.

Unsolicited inbound connections for applications

Description

This scenario covers an application that completes a listen operation on a TCP socket or successfully binds to a specific UDP socket through Winsock. For this scenario, Windows Firewall can automatically open and close ports as needed by the application.

Some examples of tasks involving Microsoft applications that might work this way include:

  • Using audio and video in MSN Messenger or Windows Messenger.

  • Transferring files in MSN Messenger or Windows Messenger.

  • Hosting a multiplayer game.

Action required

If you are developing an application that needs to listen on a port (or ports) Microsoft requests that you update your code to ask the users to indicate whether they want to allow the application to open ports in the firewall:

  • If the user consents to this, then the application can use the INetFwAuthorizedApplication API to add itself to the AuthorizedApplications collection as Enabled.

  • If the user does not consent, then the application can use the INetFwAuthorizedApplication API to add itself to the AuthorizedApplications collection as Disabled.

When using the INetFwAuthorizedApplication API to add an application to the AuthorizedApplications collection, the following values are required:

  • Image File Name. This is the file that calls Winsock to listen for network traffic. This must be a fully-qualified path, but it might contain environment variables.

  • Friendly Name. This is the description for the application that will be shown to users in the Windows Firewall user interface.

For more information about the INetFwAuthorizedApplication API, see "INetFwAuthorizedApplication" in the Microsoft Platform Software Development Kit (SDK) on the MSDN Web site at https://go.microsoft.com/fwlink/?LinkId=32000.

Windows Firewall monitors Winsock to see when applications start and stop listening on ports. As a result, ports are automatically opened and closed for applications after their entries have been enabled in the Windows Firewall exceptions list. This means that no action is required by Winsock applications to actually open and close ports in the firewall.

Note

An application must be running in the context of a user with Administrator rights to add itself to the Windows Firewall exceptions list. Ports are automatically opened and closed in the firewall for allowed Winsock applications, regardless of the user context in which the applications are running. Applications should get user consent before adding themselves to the INetFwAuthorizedApplications collection. Svchost.exe cannot be added to the INetFwAuthorizedApplications collection.

Inbound connections for services using fixed ports

Description

While developers are advised to use the INetFWAuthorizedApplication APIs for all other scenarios, the use of global port APIs in Windows Firewall is recommended for services that listen on fixed ports. Because these ports are always open, there is minimal benefit to dynamically opening the ports. Instead, users gain the ability to customize the firewall settings for these fixed ports when the global port APIs are used.

Some examples of services that require inbound connections are:

  • File and printer sharing.

  • UPnP architecture.

  • Remote Desktop.

Action Required

When a service needs to listen on a fixed port, it should ask the user whether it should allow the service to open ports in the firewall. Ideally this should be done when the service is being installed.

If the user consents to this, then the service should use the INetFwOpenPort API to add rules to Windows Firewall for the fixed port (or ports) needed by the service. These rules should be enabled.

If the user does not consent, then the service should still use the INetFwOpenPort API to add rules to Windows Firewall for the fixed port or ports needed by the service. These rules, however, should not be enabled.

When using the INetFwOpenPort API to add a port opening to Windows Firewall, the following values are required:

  • Protocol. Specifies the network protocol that is used by the service, either TCP or UDP.

  • Port. This is the number of the port to be opened.

  • Friendly Name. This is the description for the port opening that will be shown to users in the Windows Firewall user interface.

For more information about the INetFwOpenPort API, see "InetFwOpenPort" in the Platform Software Development Kit on the MSDN Web site at https://go.microsoft.com/fwlink/?LinkId=35316.

When a service is disabled, it should use the INetFwOpenPort API to close the static ports that it opened, whenever possible. This can be easily done if it is the only service that uses the ports. If the service potentially shares the ports with other services, however, it should not close the ports unless it can verify that none of the other services are using the ports.

An application must be running in the context of a user with Administrator rights to statically open ports in Windows Firewall.

Note

When statically opening ports through the INetFw API, a service should limit itself to traffic from the local subnet whenever possible. Services should get user consent before statically opening ports in Windows Firewall. A service should never just automatically open ports without first warning the user.

Inbound connections on RPC and DCOM ports for system services

Description

Some system services require the use of RPC ports, either through DCOM or RPC directly, for inbound connections. Because of the significant security implications when opening RPC ports, these ports are handled as a special case, and developers should try to enable RPC for system services through Windows Firewall only when absolutely necessary.

Action required

Windows Firewall can be configured to enable the automatic opening and closing of RPC and DCOM ports for system services. By default, however, RPC will be blocked by Windows Firewall. This means that applications that use the RPC ports to transfer data to system services will need to configure Windows Firewall appropriately. When an application needs to enable this feature, it should ask the user whether it should allow the services to open ports in the firewall. Ideally, this should be done at installation time.

If the user consents to allowing the RPC ports to be opened, then the service should use the INetFwRemoteAdminSettings API to open the ports that are needed by the service.

If the user does not consent to allowing the RPC ports to be opened, then the application or service should not configure Windows Firewall to allow the RPC ports.

For more information about the INetFwRemoteAdminSettings API, see "INetFwAuthorizedApplication" on the MSDN Web site at https://go.microsoft.com/fwlink/?linkid=32000 and, in the table of contents, click "RemoteAddresses Property of InetFwAuthorizedApplication."

Note

To enable or disable the automatic opening of RPC ports in Windows Firewall, an application or service must be running in the context of a user with Administrator rights. An application or service should try to allow the RPC ports through Windows Firewall only when absolutely necessary. If the RPC ports are already allowed, then the application or service does not need to do anything in order to function correctly. You can determine which ports are already opened using the IsPortAllowed API. The RPC ports setting works only for RPC servers that run in the context of local system, network service, or local service. Ports opened by RPC servers running in other user contexts will not be enabled through this setting. Instead, those RPC servers should use the Windows Firewall exceptions list.