Windows Firewall replaces the Internet Connection Firewall provided with Windows Server 2003 with no service packs installed. Windows Firewall is a stateful firewall that drops unsolicited incoming traffic that does not correspond to either traffic sent in response to a request of the computer (solicited traffic) or unsolicited traffic that has been specified as allowed (excepted traffic). Windows Firewall provides a level of protection from malicious users and programs that rely on unsolicited incoming traffic to attack computers.
For more information about Windows Firewall in Windows Server 2003 Service Pack 1, see the Microsoft Windows Server 2003 Windows Firewall TechCenter.
The Netstat –b option
The Netstat tool displays a variety of information about active TCP connections, ports on which the computer is listening, Ethernet statistics, the IP routing table, and IPv4 and IPv6 statistics. In Windows Server 2003 Service Pack 1, the Netstat tool supports a new –b option that displays the set of components that are listening on each open TCP and UDP port.
With Windows Server 2003 with no service packs installed, you can use the –o option to display the set of ports being listened on and the corresponding process ID (PID). You can then lookup the PID in the display of the tasklist /svc command to discover the name of the process that owns the port. However, in some cases, there are multiple services within a single process and it is not possible to determine which service within the process owned the port.
With the –b option, Netstat displays the TCP or UDP port, the file names corresponding to the components of the service that owns the port, and the PID. From the file names and PID, you can determine which of the services in the display of the tasklist /svc command owns the port.
Netsh Commands for Windows Sockets
There are now Windows Sockets (Winsock) Netsh commands to view the set of installed Winsock Layered Service Providers (LSPs) (the netsh winsock show catalog command) and to reset the Winsock LSP catalog to a default configuration (the netsh winsock reset catalog command). The netsh winsock reset catalog command is useful for restoring the Winsock LSP catalog when it has been corrupted by programs or services that install LSPs. However, you must reinstall the programs or services that use LSPs.
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 the half-open connection. 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 Service Pack 1, SynAttackProtect is set to 1 by default.
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. For information about these new APIs, see the Microsoft Developer Network (MSDN).
TCP/IP for Windows Server 2003 SP1 supports a new registry parameter that restricts the number of host routes that can be added to the local IP route table by receiving ICMP Redirect messages. The new registry parameter is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \Tcpip\Parameters\ MaxICMPHostRoutes (REG_DWORD type). MaxICMPHostRoutes has a default value of 1000. You should not change this value unless the computer needs to be able to add a large number of host routes by receiving ICMP Redirect messages.
The update to Windows Server 2003 SP1 available from Microsoft Knowledge Base article 898060 changes the default value of MaxICMPHostRoutes to 10000.
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’s 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 open, 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 by 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 TcpTimedWaitDelay is contrary to the original design of TCP and the MSL.
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 Service Pack 1 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 TcpTimedWaitDelay registry entry.