Registry modifications that harden a system against TCP exploits
Microsoft has documented five TCP registry modifications you can implement to reduce a Windows 2000 system's vulnerability to Denial of Service (DoS) attacks and other common exploits. These techniques are suitable for Win2K systems connected to a WAN or the Internet and for sites operating under strict security controls. Because these modifications are sophisticated and require that you manually adjust many core TCP algorithms, I recommend that you experiment with a test system before attempting any changes on production systems. Incorrect or inappropriate TCP/IP settings can adversely affect most Win2K services and applications. Because these techniques affect the low-level algorithms that Win2K uses to manage and route messages, you should connect your test system to multiple subnets with one or more routers.
TCP/IP Registry Settings
Win2K stores all information about a running system in the system's HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet registry subkey. This subkey contains the Services subkey, which has one subkey for every configurable Win2K service*even services that are disabled or not installed. Figure 1 shows generic TCP/IP configuration data that the system stores in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters subkey. (By convention, configuration data for each service is in a Parameters subkey under a subkey that corresponds with the service's name.)
To accommodate multiple adapters*whether hardware network adapters or software-based Routing and Remote Access ports*the system creates a corresponding subkey for each adapter's class ID in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces subkey. As Figure 2 shows, when you click an adapter's class ID, the registry editor displays adapter-specific configuration data in the right pane.
The \Tcpip\Parameters subkey contains value entries that define TCP/IP behavior for all interfaces. When you configure an adapter that supports TCP/IP connectivity, the system copies many of these settings to the adapter's Interfaces subkey. When the same value entry appears in \Tcpip\Parameters and in the adapter-specific subkey, you can modify TCP/IP operation for an individual adapter by changing the adapter's value entries. Keep the general and adapter-specific settings in mind as I describe the registry modifications you can make to reduce your system's vulnerability.
If an entry I describe doesn't appear on your system under the subkey I reference, you must create the entry. When creating registry entries, make sure that you enter the correct data type and value. You can't predict how, or even whether, a system will respond if you enter an incorrect data type or value. After you adjust TCP configuration parameters, you must reboot the system to activate the changes.
1. Protect Against SYN DoS Exploits
Malicious users make heavy use of TCP SYN DoS attacks. Before you can understand how to protect your systems from such attacks, you must understand the mechanics of TCP/IP.
To initiate a TCP over IP connection, system A sends a SYN (synchronize) packet to system B. System B replies to system A by sending an acknowledgement (SYN-ACK). If system B doesn't then receive an acknowledgment of the SYN-ACK from system A, system B retransmits the SYN-ACK up to five times. After each retransmission that system A fails to acknowledge, system B increases the interval that it waits before trying again. These intervals ensure that systems can communicate across slow networks.
If system A fails to respond, system B eventually times out the connection request. The timeout process can take as long as 3 to 4 minutes because system B must complete the required number of retransmissions to system A before it closes the connection. When system B times out the connection, TCP releases the connection resources it had allocated to the incoming connection. The process of making the resources available can take another 3 to 5 minutes.
In a typical SYN attack, a malicious user runs code on system A that causes it to flood system B with many SYN requests in a short period. Each SYN request travels in an IP packet that contains the TCP/IP address of the system that ostensibly sent the packet. This address might point to the malicious user's system, but more commonly, a "spoofed" address points to another user's system or a system that doesn't exist. Regardless, system B tries to send a SYN-ACK reply to the source address for every SYN message. When system A doesn't respond, system B must keep the connection half-open and make the required number of tries before it can close the connection. You can see that a SYN attack can quickly overload a system.
Win2K systems support hundreds of concurrent TCP/IP connections. When a system is under a SYN attack, the system can commit up to half of its available TCP/IP resources to incoming connection requests. The process of allocating, managing, and recycling the TCP/IP resources eventually hangs the system.
You can use the command
netstat n p tcp
to monitor a system that you suspect is sustaining a SYN attack. The n switch directs Netstat to display addresses and port numbers in numeric form; the p switch tells Netstat to display active TCP connections only. Figure 3 shows a system with multiple TCP connections in the SYN_RECEIVED, or half-open, state. Each connection includes the source address of the system that presumably sent the SYN. If such connections remain in the SYN_RECEIVED state for more than a few minutes, a SYN attack is likely under way. (Typically, a connection's status changes to ESTABLISHED in less than a minute.)
Prev. page
[1]
2
3
next page 
