The Cable Guy - December 2004
New Networking Features in Microsoft Windows Server 2003 Service Pack 1
.gif "TechNet's The Cable Guy")
Microsoft® Windows Server 2003 Service Pack 1 (SP1) includes the new networking features included with Windows® XP Service Pack 2 (SP2) and provides additional features and enhancements to support server services and operations.
Windows Server 2003 SP1 has all the networking improvements in Windows XP SP2, which include the following:
Windows Firewall
Windows Peer-to-Peer Networking
Client-side support for Wireless Provisioning Services (WPS)
Updates to Internet Protocol version 6 (IPv6)
The new Netstat option
Enhancements to wireless LAN networking
These networking improvements are described in detail in New Networking Features in Microsoft Windows XP Service Pack 2 (the January 2004 The Cable Guy article) and Wireless LAN Enhancements in Windows XP Service Pack 2 (the August 2004 The Cable Guy article).
Windows Server 2003 SP1 also includes the following:
Differences in default behavior for Windows Firewall
Server-side support for WPS
Updates to the Wireless Network (IEEE 802.11) Policies Group Policy extension
Rqs.exe and Rqc.exe are now included for Network Access Quarantine Control
Enhancements to Transmission Control Protocol/Internet Protocol (TCP/IP)
Differences in Default Behavior for Windows Firewall
Windows Server 2003 SP1 includes Windows Firewall, which works the same way as Windows Firewall in Windows XP SP2. However, because the purpose of a server computer is to accept incoming unsolicited traffic, Windows Firewall for Windows Server 2003 SP1 is disabled by default.
The exception to this behavior is the following: for a new installation of Windows Server 2003 that already includes SP1 (known as a slipstream installation), Windows Firewall is enabled by default for the duration of the Post-Setup Security Updates, a portion of the initial setup of the server computer in which the latest security fixes are downloaded and installed from Windows Update and Automatic Updates are configured. After the Post-Setup Security Updates is complete, Windows Firewall is disabled. If you do not want the Post-Setup Security Updates, you can use the Unattend.txt file or Group Policy to configure Windows Firewall settings. The Post-Setup Security Updates does not occur if there are configured Windows Firewall settings.
You can enable Windows Firewall on a computer running Windows Server 2003 with SP1 manually using the Windows Firewall component of Control Panel, through Group Policy settings as described in Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2, or you can use the new Security Configuration Wizard in Windows Server 2003 SP1. The Security Configuration Wizard is the recommended method to enable and configure Windows Firewall and other security settings on computers running Windows Server 2003 with SP1.
If you enable Windows Firewall interactively after the server computer is up and running, you should restart the server computer. This assures that Windows Firewall can add entries to its exceptions table for the ports opened by programs that correspond to enabled program-based exceptions. Windows Firewall cannot determine the ports that have been opened by a program if they were opened before the Windows Firewall was started. Various messages for Windows Firewall have been updated in Windows Server 2003 SP1 to remind the computer user to restart the system if Windows Firewall is enabled interactively.
Server Side Support for WPS
WPS extends the wireless client software and the Internet Authentication Service (IAS) included with Windows Server 2003 SP1 to allow for a consistent and automated configuration process when connecting to the following:
Public wireless hotspots that provide access to the Internet.
Private organization wireless networks that provide guest access to the Internet.
For example, when wireless clients connect to a public wireless hotspot and they are not already a customer of the wireless Internet service provider (WISP), the user of the wireless client is faced with the challenge of performing the following:
Configuring network settings to connect to the WISP network.
Providing identification and payment information to the WISP.
Obtaining connection credentials.
Reconnecting to the WISP network after valid credentials have been obtained.
WPS is designed to simplify, automate, and standardize initial sign-up and subscription renewal so that the user does not have to perform a different set of steps for each wireless provider to which they want to connect.
WPS client side support is provided with Windows XP SP2 and Windows Server 2003 SP1 and includes the services and components to automate registration, configuration, and connection to wireless networks that support WPS.
WPS server-side support is provided in Windows Server 2003 SP1 as enhancements to IAS to support the wireless client provisioning process. For example, IAS in Windows Server 2003 SP1 sends the location of a provisioning server to wireless clients during the initial connection process.
For more information about how WPS works for a WISP, see Wireless Provisioning Services Overview, the December 2003 The Cable Guy article. For detailed information about deploying WPS, see the Introduction to Deploying Wireless Provisioning Services (WPS) Technology white paper.
Updates to the Wireless Network (IEEE 802.11) Policies Group Policy Extension
The Wireless Network (IEEE 802.11) Policies Group Policy extension allows you to configure IEEE 802.11 and 802.1X settings that are part of Computer Configuration Group Policy for a domain-based Group Policy object. For more information, see Configuring Wireless Settings Using Windows Server 2003 Group Policy, the July 2004 The Cable Guy article.
The Wireless Network (IEEE 802.11) Policies Group Policy extension in Windows Server 2003 with no service packs installed does not include options for configuring Wi-Fi Protected Access (WPA) authentication and encryption. The Wireless Network (IEEE 802.11) Policies Group Policy extension in Windows Server 2003 SP1 has been enhanced to include WPA authentication options (you can now choose WPA or WPA preshared key [WPA-PSK]) and encryption options (you can now choose the Temporal Key Integrity Protocol [TKIP] or the Advanced Encryption Standard [AES]). These enhancements are supported by computers running Windows XP with SP1 and the WPA Wireless Security Update in Windows XP, Windows XP with SP2, or Windows Server 2003 with SP1.
RQS.EXE and RQC.EXE Now Included for Network Access Quarantine Control
Network Access Quarantine Control delays normal remote access to a private network until the configuration of the remote access computer has been examined and validated by an administrator-provided script. When a remote access computer initiates a connection to a remote access server, the user is authenticated and the remote access computer is assigned an IP address. However, the connection is placed in quarantine mode, with which network access is limited. The administrator-provided script is run on the remote access computer. When the script notifies the remote access server that it has successfully run and the remote access computer complies with current network policies, quarantine mode is removed and the remote access computer is granted normal remote access.
Deploying Network Access Quarantine Control requires the use of a notifier component that is run by the script when the remote access computer has successfully passed network policy tests and a listener component that runs on the remote access server. The listener component listens for the notification from the notifier component to remove the remote access client from quarantine mode.
For Windows Server 2003 with no service packs installed, Microsoft provided an example of a notifier component, named Rqc.exe, with the Windows Server 2003 Resource Kit Tools. Windows Server 2003 SP1 now includes Rqc.exe, which is installed with the Connection Manager Administration Kit component in the Program Files\CMAK\Support folder of the system drive.
To install the Connection Manager Administration Kit on a remote access server running Windows Server 2003 with SP1, do the following:
Click Start, point to Settings, click Control Panel, double-click Add or Remove Programs, and then click Add/Remove Windows Components.
Under Components, scroll to and click Management and Monitoring Tools.
Click Details.
Under Subcomponents of Management and Monitoring Tools, click Connection Manager Administration Kit, and then click OK.
For Windows Server 2003 with no service packs installed, Microsoft provided an example of a listener component, named Rqs.exe, with the Windows Server 2003 Resource Kit Tools. Windows Server 2003 SP1 now includes Rqs.exe, which is installed as the Remote Access Quarantine Service component.
To install the Remote Access Quarantine Service on a remote access server running Windows Server 2003 with SP1, do the following:
Click Start, point to Settings, click Control Panel, double-click Add or Remove Programs, and then click Add/Remove Windows Components.
Under Components, scroll to and click Networking Services.
Click Details.
Under Subcomponents of Networking Services, click Remote Access Quarantine Service, and then click OK.
Installing the Remote Access Quarantine Service does not automatically start the Remote Access Quarantine Agent service. As the network administrator, you must decide the best time to start the service in relation to the configuration of the Routing and Remote Access service. The Remote Access Quarantine Agent service depends on the Routing and Remote Access service. However, when the Routing and Remote Access service is restarted, the Remote Access Quarantine Agent service is not automatically restarted. You must manually restart the Remote Access Quarantine Agent service.
Part of setting up the Remote Access Quarantine Agent is configuring the script version strings, which must match the script version string configured on the Rqc.exe command line as run from the quarantine script. Rqs.exe can be configured to accept multiple script version strings. You must manually modify the registry of the remote access server to specify the allowed script version strings.
To modify the script version strings, use the Windows Registry Editor (Regedit.exe) to modify the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\AllowedSet registry entry (type REG_MULTI_SZ). By default, the value of AllowedSet is set to RASQuarantineConfigPassed. For multiple allowed script version strings, type the strings on separate lines in the Edit Multi-String dialog box when modifying the AllowedSet entry.
By default, Rqs.exe listens for notifications from Rqc.exe on TCP port 7250. To change the default TCP port, create the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\Port registry entry (type REG_DWORD) and set it to the desired port. Restart the Remote Access Quarantine Agent service so that the changed port number takes effect. Make sure that the port you configure for Rqs.exe is the same TCP port that Rqc.exe uses to send its notifications.
For more information about deploying Network Access Quarantine Control, see Network Access Quarantine Control in Windows Server 2003.
For examples of Network Access Quarantine Control scripts, see the free Sample Scripts for verifying client configuration for VPN Quarantine download.
Enhancements to TCP/IP
TCP/IP in Windows Server 2003 SP1 has the following enhancements:
SYN attack protection is enabled by default
New SYN attack notification IP Helper APIs
Smart TCP port allocation
SYN attack protection is enabled by default
A TCP Synchronize (SYN) attack is a denial-of-service attack that exploits the retransmission and time-out behavior of the Synchronize-Acknowledgement (SYN-ACK) segment during the TCP three-way handshake to create a large number of half-open TCP connections. Depending on the TCP/IP protocol implementation, a large number of half-open TCP connections could do any of the following:
Use all available memory.
Use all possible entries in the TCP Transmission Control Block (TCB), an internal table used to track TCP connections. Once the half-open connections use all the entries, further connection attempts are responded to with a TCP connection reset.
Use all available half-open connections. Once all the half-open connections are used, further connection attempts are responded to with a TCP connection reset.
To create a large number of TCP half-open connections, attackers send a large number of SYN segments, each from a spoofed IP address and TCP port number. Each spoofed IP address and TCP port number are for a process that does not respond to the SYN-ACKs being sent by the attacked host. SYN attacks are typically used to render Internet servers inoperative.
To mitigate the impact on a host experiencing a SYN attack, TCP/IP minimizes the amount of resources devoted to incomplete TCP connections and reduces the amount of time before abandoning half-open connections. When a SYN attack is detected, TCP/IP in Windows Server 2003 and Windows XP lowers the number of retransmissions of the SYN-ACK segment and does not allocate memory or table entry resources for the connection until the TCP three-way handshake has been completed.
You can control SYN attack protection through the SynAttackProtect registry entry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters (type REG_DWORD). You set SynAttackProtect to 0 to disable SYN attack protection and to 1 to enable it.
For TCP/IP in Windows XP (all versions) and Windows Server 2003 with no service packs installed, SynAttackProtect is set to 0 by default. For TCP/IP in Windows Server 2003 SP1, SynAttackProtect is set to 1 by default.
For more information about TCP connection behavior and related registry entries, see Microsoft Windows Server 2003 TCP/IP Implementation Details.
New SYN attack notification IP Helper APIs
To allow an application to notify network administrators that a SYN attack is taking place, the IP Helper API supports new SYN attack notification APIs named NotifySecurityHealthChange and CancelSecurityHealthChangeNotify. Information about these new APIs has not yet been published in the Microsoft Developer Network (MSDN). A link to the MSDN topics describing these new APIs will be posted here when available.
Smart TCP port allocation
When a TCP peer initiates a TCP connection termination and the connection termination completes, the TCP connection enters the TIME WAIT state. Once the TIME WAIT state is reached, TCP must wait twice the maximum segment lifetime (MSL) before a connection with the same set of socket addresses can be created. The set of socket addresses consist of the combination of the source and destination IP addresses and source and destination TCP ports. The MSL is the maximum amount of time a TCP segment can exist in an internetwork, and its recommended value is 120 seconds. This delay prevents a new connection TCP segments that are using the same set of socket addresses from being confused with duplicated TCP segments of the old connection.
The TCP port for a connection in the TIME WAIT state is considered an available port and can be assigned for use by an application. This can lead to the following situation:
An application requests any available TCP port.
TCP/IP assigns a TCP port to use for the application socket.
The application attempts to open a socket with a specific destination IP address.
The application establishes a TCP connection and sends data.
The application terminates the TCP connection.
TCP/IP places the application's TCP connection in the TIME WAIT state until twice the MSL has passed.
The same application requests another available TCP port.
TCP/IP assigns a TCP port to use for the application socket. Because the port for the connection in the TIME WAIT state is considered available, it can be chosen as the next port to assign to the requesting application.
Assuming that TCP/IP assigns the same TCP port number, the application attempts to open a socket with the same destination IP address.
Because the connection is using the same set of socket addresses as the connection in the TIME WAIT state, TCP/IP indicates an error to the application.
You can mitigate this situation through the following:
Setting the MaxFreeTWTcbs registry entry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters (REG_DWORD type) to a lower value. The value of MaxFreeTWTcbs controls the number of connections that can be in the TIME WAIT state. Once this number is exceeded, the oldest connection is automatically removed from the TIME WAIT state.
Setting the TcpTimedWaitDelay registry entry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters (REG_DWORD type) to a lower value. The value of TcpTimedWaitDelay determines the length of time that a connection stays in the TIME WAIT state.
However, lowering the value of these registry entries is contrary to the original design of TCP and the MSL.
For more information about these registry entries, see Microsoft Windows Server 2003 TCP/IP Implementation Details.
To prevent an application from creating a connection with the same set of socket addresses of a connection that is in a TIME WAIT state, TCP/IP in Windows Server 2003 SP1 has implemented a smart TCP port allocation algorithm. When an application requests any available TCP port, TCP/IP first attempts to find an available port that does not correspond to a connection in the TIME WAIT state. If a port cannot be found, then it picks any available port.
This new behavior makes it much more unlikely that an application will be assigned a TCP port that is in the TIME WAIT state when connecting to the same destination. You no longer need to modify the values of the MaxFreeTWTcbs and TcpTimedWaitDelay registry entries.
For More Information
For more information, consult the following resources:
Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2
Introduction to Deploying Wireless Provisioning Services (WPS) Technology
For a list of all The Cable Guy articles, click here.