http://www.microsoft.com/downloads/details...&DisplayLang=en
Quick Info
File Name:
WinXPSP2_Documentation.doc
Download Size:
932 KB
Date Published:
3/18/2004
Version:
1.0
Overview
In Microsoft Windows XP Service Pack 2, Microsoft is introducing a set of security technologies that will help to improve the ability of Windows XP-based computers to withstand malicious attacks from viruses and worms. The technologies include network protection, memory protection, safer e-mail handling, more secure browsing, and improved computer maintenance.
Together, these security technologies will help to make it more difficult to attack Windows XP, even if the latest updates are not applied. These security technologies together are particularly useful in mitigation against worms and viruses.
This document specifically focuses on the changes between earlier versions of Windows XP and Windows XP Service Pack 2 and reflects Microsoft’s early thinking about Service Pack 2 and its implications for developers. Examples and details are provided for several of the technologies that are experiencing the biggest changes. Future versions of this document will cover all new and changed technologies.
++++++++++++++++++++++++++++++++++
Windows Firewall
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 PCs that are connected to a network by preventing unsolicited inbound connections through TCP/IP version 4 (IPv4) and TCP/IP version 6 (IPv6). Configuration options include:
• Enabling on a per-interface basis
• Using static port openings
• Configuring basic ICMP options
• Logging dropped packets and successful connections
For more information about Windows Firewall for IPv4, see “Internet Connection Firewall Feature Overview” on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=20927. Support for filtering of IPv6 traffic was added with the release of IPv6 Windows Firewall in the Advanced Networking Pack for Windows XP. The Advanced Networking Pack is available through Windows Update on the Microsoft Web site at http://go.microsoft.com/fwlink/?linkid=18539.
Who does this feature apply to?
This feature applies to
• All computers that are connected to a network
• All applications and services that listen on the network
• All applications that do not work with stateful filtering
What new functionality is added to this feature in Windows XP Service Pack 2?
On-by-Default
Detailed description
Windows Firewall is turned on by default for all network interfaces. This provides more network protection by default for Windows XP on new installations and upgrades. On-by-Default also protects new network connections as they are added to the system. This applies to both IPv4 and IPv6 traffic, and is enabled even if there is another firewall already present on the system.
Why is this change important? What threats does it mitigate?
Prior to Windows XP Service Pack 2, Windows XP shipped with Windows Firewall disabled by default. The user either needed to run a wizard or navigate through the Network Connections folder to manually enable Windows Firewall. This experience proved too difficult for many users, and resulted in many computers not having any firewall protection.
By enabling Windows Firewall by default, the computer has more protection from many network-based attacks. For example, if Windows Firewall had been enabled by default, the recent MSBlaster attack would have been greatly reduced in impact, regardless of whether users were up-to-date with patches.
What works differently or stops working?
After installing Windows XP Service Pack 2, Windows Firewall is enabled by default. This might break application compatibility if the application does not work with stateful filtering by default. It may also conflict with other active software and hardware firewalls.
How do I fix these issues?
Modifying an application to work with a stateful filtering firewall is described in detail later in this document, in “Do I need to change my code to work with Windows XP Service Pack 2?”
+++++++++++++++++++++++++++++++++++++++++++++++++
Local subnet restriction
Detailed description
By default, when a port opening is created, it is open globally—incoming traffic can come from any network location, such as a local network or the Internet. In Windows XP Service Pack 2, you can configure the port to only receive network traffic with a source address from the local subnet.
When the file sharing ports are opened with the NetShare application programming interface (API), the Network Setup Wizard, or through the Windows Firewall user interface, the local subnet restriction will be applied by default. Additionally, when UPnP™ ports are opened, they are restricted to the local subnet.
It is recommended that you apply local subnet restriction to any static port that is used for communicating on the local network. It can be done programmatically, through the Windows Firewall Netsh Helper, or the Windows Firewall user interface.
This applies to IPv4 port configuration. IPv6 port configuration does not support this restriction. However, IPv6 itself supports this restriction through its use of link-local and site-local addresses.
Why is this change important? What threats does it mitigate?
Some applications only need to talk to other hosts on the local network and not hosts on the Internet. Allowing a port to only receive traffic from the local subnet restricts the scope of who can access a port. This mitigates attacks that occur because ports are open to computers that connect from any location.
What works differently or stops working?
When file and printer sharing is enabled, four ports are specifically affected by local subnet restriction. The following ports will only receive traffic from the local subnet.
• UDP port 137
• UDP port 138
• TCP port 139
• TCP port 445
If an application or service also uses these ports, it will only be able to communicate with other nodes on the local subnet.
When the UPnP architecture is enabled, two ports are specifically affected by local subnet restriction and only receive traffic from the local subnet:
• UDP port 1900
• TCP port 2869
How do I fix these issues?
If your application or service does not work with this restriction, you should use the new APIs to open the port for global connections, as described later, in “Do I need to change my code to work with Windows XP Service Pack 2?”
++++++++++++++++++++++++++++++++
Windows Firewall Exceptions List
Detailed description
Some applications act as both network clients and servers. When they act as servers, they need to allow unsolicited inbound traffic to come in, because they do not know who the peer will be ahead of time.
In earlier versions of Windows, an application 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 application to close the port again once communication was completed. Without this, there would be unnecessary openings in the firewall if the application terminated unexpectedly.
Additionally, these ports could only be opened if applications were running in the security context of a local administrator. This violated the principle of least privilege by requiring applications to run in an administrative context, rather than only with the minimum necessary privileges.
In Windows XP Service Pack 2, an application that needs to listen to the network can be added to the Windows Firewall exceptions list. If an application is on the Windows Firewall exceptions list, Windows opens the necessary port automatically, regardless of the application’s security context.
An application can be placed on the Windows Firewall exceptions list in three ways.
First, it can be added programmatically by the application. It is recommended that independent software vendors (ISVs) place their application on the Windows Firewall exceptions list during installation.
Second, you can use a notification. When an application performs a TCP listen or UDP bind to a specific port, the network stack passes the application name and port to Windows Firewall. Windows Firewall will look up the application name on the exceptions list. If the application is on the exceptions list and enabled, then the corresponding port will be opened in the firewall. If the application is on the exceptions list and disabled, then the corresponding ports will not be opened. If the application is not on the exceptions list, then users are asked to make a choice. If the user is an Administrator, they can allow the application to listen on the network (added to the exceptions list as Enabled and ports opened), not allow the application to listen on the network (added to the exceptions list as Disabled and ports not opened) or be asked again later (not added to the exceptions list and ports not opened). If the user is not an Administrator, they will be notified that the application is not allowed to listen on the network and to have an Administrator enable the application. At this point the application is listed in the exceptions list as Disabled.
Third, the user can configure it manually. The user can decide to enable an application manually by selecting it from a list which is populated from the list of applications in the Start Menu, or by browsing for the application on their computer’s hard disk.
Applications that work with stateful filtering do not need to be placed on the Windows Firewall exceptions list. Only administrators can add an application to the Windows Firewall exceptions list.
Why is this change important? What threats does it mitigate?
When an application is on the Windows Firewall exceptions list, only the necessary ports are opened, and they are only opened for the duration that the application is listening on those ports. An application cannot open a port that it is not using, which might deliberately or inadvertently expose another application or service to network traffic from that port.
This also allows applications that are listening to the network to run as a regular user. In earlier versions of Windows, the user had to run these applications with Administrator rights.
What works differently or stops working?
If an application needs to listen on the network, it must be on the Windows Firewall exceptions list. If it is not, then the necessary port in Windows Firewall is not opened and the application will not be able to receive unsolicited inbound traffic.
How do I fix these issues?
For more information, see “Do I need to change my code to work with Service Pack 2 for Windows XP?” later in this section.
Multiple Profiles
Detailed description
Multiple profile support in Windows Firewall allows you to create two sets of firewall policy: one for when the computer is connected to the corporate network and one for when the computer is not. You can specify policy that is less strict when the computer is connected to the corporate network to enable line of business applications to work. You can also have a more aggressive security policy that will be enforced when the computer leaves the corporation network, which helps to protect against Internet-based attacks.
Multiple profiles for Windows Firewall only applies to computers that are joined to a domain. Computers that are in a workgroup only have one profile.
Why is this change important? What threats does it mitigate?
For a mobile computer, it is desirable to have more than one firewall configuration. Often, a configuration that is safe on a trusted network is likely to be susceptible to attack on the Internet. Therefore, being able to have ports opened on the trusted network and not on the Internet is critical to ensuring that only the necessary ports are exposed at any given time.
What works differently or stops working?
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. 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 fix these issues?
If the computer is joined to a domain, you must ensure that the application is listed in both profiles.
RPC support
Detailed description
In earlier versions of Windows, Windows Firewall blocked remote procedure call (RPC) communication. While Windows Firewall could be configured to allow network traffic to the RPC Endpoint Mapper, the port that RPC 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:
• File and print sharing
• 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. Since so many RPC servers are included with Windows XP, Windows Firewall takes a different approach for RPC. When opening a port, a caller can claim that the port is to be used for RPC. Windows Firewall will only accept this claim if the caller is running in the Local System, Network Service, or Local Service security contexts. Windows Firewall supports a profile level flag that enables RPC ports to be opened even if the caller is not on the Windows Firewall exceptions list.
Note, however, that the authorized application settings always override the generic RPC setting. For example, if the RPC setting is “allow local,” but the RPC server executable is also on the Windows Firewall Permissions List with the local subnet only set to False, the port of the RPC server will be opened for all subnets.
Why is this change important? What threats does it mitigate?
Ensuring that Windows Firewall works with RPC is required for many enterprise-wide deployments. However, you do not want every RPC service exposed to the network by default. By using more precision, you can control which RPC services are exposed to the network.
What works differently or stops working?
By default, RPC will not function through Windows Firewall. All services and applications that use RPC are affected. However, Windows Firewall can be configured to allow RPC to work for services.
How do I fix these issues?
See “Do I need to change my code to work with Windows XP Service Pack 2?” later in this document.
Restore Defaults
Detailed description
Previously there was no way for a user to reset the configuration of Windows Firewall. Over time, Windows Firewall might be configured to allow unsolicited incoming traffic, either through adding applications or ports to the Windows Firewall exception list. This may 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 OEMs and businesses to provide custom 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 or stops working?
This feature adds configuration flexibility to Windows Firewall. No functional changes in Windows Firewall result from this addition.
How do I fix these issues?
Not applicable.
Unattended Setup support
Detailed description
In earlier versions of Windows, it was not possible to configure Windows Firewall during installation. This made it difficult for OEMs and businesses to preconfigure Windows Firewall before distributing the computer to their end users. In Windows XP Service Pack 2, 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 or stops working?
This feature adds configuration flexibility to Windows Firewall. No functional changes in Windows Firewall result from this addition.
How do I fix these issues?
Not applicable.
What existing functionality is changing in Windows XP Service Pack 2?
Enhanced multicast and broadcast support
Detailed description
Multicast and broadcast network traffic differ 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 3 seconds from any source address on the same port from which the multicast or broadcast traffic originated.
Why is this change important? What threats does it mitigate?
This allows applications and services which use multicast and broadcast for communicating to work without either the user or application/service 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.