All your Servers in 1 Application!
 

A denial-of-service attack occurs when a user consumes so much of the shared resources such as CPU consumption, modems, telephone lines, disk space, printer paper, memory utilization, and so on—that none is left for others to use. A common way to launch such an attack is to set up a tool to automate access to a shared resource, quickly consuming CPU resources on the server. TCP/IP SYN Attack A SYN attack (sometimes called SYN flooding), targets computers running TCP/IP. It is a protocol-level attack that can render a computer's network services unavailable. You may be subject to a SYN attack if some or all network services are rendered unavailable and error messages such as the following appear on the network client screen: "The connection has been reset by the remote host." How SYN Flooding Works SYN flooding works as follows: · A TCP connection request (SYN) is sent to the target computer. The source IP address in the packet is "spoofed," or replaced with an address that is either not in use on the Internet, or one that belongs to another computer. An attacker will send many of these TCP SYNs in order to tie up as many resources as possible on the target computer. · Upon receiving the connection request, the target computer allocates resources to handle and track the new connection. It then responds with a "SYN-ACK." In this case, the response is sent to the nonexistent IP address. · There is no response to the SYN-ACK. A computer running default-configured Windows NT 3.5x or 4.0 will retransmit the SYN-ACK five times, doubling the time out value after each retransmission. The initial time out value is three seconds, so retries are attempted at 3, 6, 12, 24, and 48 seconds. After the last retransmission, 96 seconds are allowed to pass before the computer gives up on receiving a response, and deallocate's the resources that were set aside earlier for the connection. The total elapsed time that resources are in use is 189 seconds. For more information see CERT Advisory CA-96.21 at ftp://info.cert.org/pub/cert_advisories/. How to Verify Your Computer is Under a SYN Attack If you suspect that your computer is the target of a SYN attack, you can type the following command at a command prompt to view connections in the "SYN_RECEIVED" state: netstat -n -p tcp If a large number of connections are in the SYN_RECEIVED state, as in the example below, it is possible that the system is under attack. A network analyzer can be used to track down the problem further, and it might be necessary to contact your ISP for assistance in attempting to trace the source. Active Connections Proto Local Address Foreign Address State TCP 127.0.0.1:1030 127.0.0.1:1032 ESTABLISHED TCP 127.0.0.1:1032 127.0.0.1:1030 ESTABLISHED TCP 10.57.8.190:21 10.57.14.154:1256 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1257 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1258 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1259 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1260 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1261 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1262 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1263 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1264 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1265 SYN_RECEIVED TCP 10.57.8.190:21 10.57.14.154:1266 SYN_RECEIVED TCP 10.57.8.190:4801 10.57.14.221:139 TIME_WAIT Figure 8.16 A sample trace from netstat -n -p tcp showing a computer that is possibly being attacked by a SYN flood. The effect of tying up connection resources varies depending upon the TCP/IP stack and applications listening on the TCP port. For most stacks, there is a limit on the number of connections that can be in the half-open (SYN_RECEIVED) state. Once the limit is reached for a given TCP port, the target computer responds with a reset to all further connection requests until resources are freed. Resolution Windows NT 4.0 Service Pack 3 (required to run IIS 4.0) includes several fixes. Tcpip.sys Times Out "Half-Open" Connections Faster With the current version of Tcpip.sys you can control the number of times a response to a TCP connection request (SYN-ACK) is retransmitted. Control is handled through the following registry parameter: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBt \Parameters \TcpMaxConnectResponseRetransmissions Value Type: REG_DWORD Valid Range: 0-0xFFFFFFFF Default: 3 The default value for this parameter is 3. The following table shows Windows NT 4.0 TCP/IP behavior for various values of this parameter: Table 8.2 TcpMaxConnectResponseRetransmissions values Value Retransmission Times Elapsed Comments 3 3, 6, and 12 seconds 45 seconds Cleanup 24 secs after last retx 2 3 and 6 seconds 21 seconds Cleanup 12 secs after last retx 1 3 seconds 9 seconds Cleanup 6 secs after last retx This parameter changes the default time that it takes to clean up a half-open TCP connection from 189 seconds to 45 seconds. A site that is under heavy attack might set the value as low as 1. You can also set the value of this parameter to 0, but doing so would cause the SYN-ACKs not to be retransmitted at all, and they would time-out in 3 seconds. Also, with the value this low, legitimate connection attempts from distant clients could fail. NetBT Has a Higher, Configurable Backlog NetBT (NetBIOS over TCP/IP) uses TCP port 139, and is used by Microsoft Network Services such as file and print sharing. Version 3.51 and 4.0 NetBT has a "backlog" of available connections that is based on the number of NetBT clients (such as the redirector, server and any NetBIOS applications running). On a typical server, this number will be between 7 and 11. The current version of NetBT automatically allocates more connection blocks as needed, in a configurable manner. On a connection event, it checks to see if the number of free blocks is less than 2 and, if so, adds an "increment" number of blocks, where "increment" is configurable in the registry as shown below: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBt \Parameters \BacklogIncrement Value Type: REG_DWORD Valid Range: 1–0x14 (1–20 decimal) Default: 3 Each connection block consumes 78 bytes of memory. The total number of connection blocks that can be allocated by NetBT is also registry configurable: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBt \Parameters \MaxConnBackLog Value Type: REG_DWORD Valid Range: 1–0x9c40 (1–40,000 decimal) Default: 1000 MaxConnBackLog defaults to 1000, but can be set as high as 40,000. Connection blocks are "scavenged," or recycled, when the SYN-ACK retransmission timer expires and TCP fails the connection attempt. Afd.sys Has Been Modified to Withstand Large Numbers of "Half-Open" Connections Efficiently Windows Sockets applications such as FTP and Web servers have their connection attempts handled by Afd.sys. Afd.sys has been modified to support large numbers of connections in the "half-open" state without denying access to legitimate clients. It does so by allowing the administrator to configure a dynamic backlog. The current version of Afd.sys supports four new registry parameters that can be used to control the dynamic backlog behavior. EnableDynamicBacklog is a global switch to enable or disable dynamic backlog. It defaults to 0 (off). This setting provides no change from the existing versions. Setting it to 1 enables the new dynamic backlog feature. HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \AFD \Parameters \EnableDynamicBacklog Value Type: REG_DWORD Valid Range: 0,1 Default: 0 Suggested value for a system under heavy attack: 1 MinimumDynamicBacklog controls the minimum number of free connections allowed on a listening endpoint. If the number of free connections drops below this value, then a thread is queued to create additional free connections. This value should not be made too large, because the dynamic backlog code engages whenever the number of free connections falls below this value. Too large a value can cause a performance reduction. HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \AFD \Parameters \MinimumDynamicBacklog Value Type: REG_DWORD Valid Range: 0–0xFFFFFFFF Default: 0 Suggested value for a system under heavy attack: 20 MaximumDynamicBacklog controls the maximum number of "quasi-free" connections allowed on a listening endpoint. "Quasi-free" connections include the number of free connections plus those connections in a half-connected (SYN_RECEIVED) state. No attempt is made to create additional free connections if doing so would exceed this value. HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \AFD \Parameters \MaximumDynamicBacklog Value Type: REG_DWORD Valid Range: 0–0xFFFFFFFF Default: 0 Suggested value for a system under heavy attack: This is memory dependent. The value should not exceed 5,000 for each 32 MB of RAM installed in the server, in order to prevent exhaustion of the non-paged pool when under attack. DynamicBacklogGrowthDelta controls the number of free connections to create when additional connections are necessary. Use this value with caution, because a large value could lead to explosive free connection allocations. HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \AFD \Parameters \DynamicBacklogGrowthDelta Value Type: REG_DWORD Valid Range: 0–0xFFFFFFFF Default: 0 Suggested value for a system under heavy attack: 10 (0xa) To take advantage of the changes to Afd.sys, Windows Sockets applications must specifically request a backlog greater than the value configured for MinimumDynamicBacklog when they issue their listen() call. Microsoft applications, such as IIS (which has a default backlog of 25), are configurable. Application-specific details are available from the Microsoft Knowledge Base at http://www.support.microsoft.com/support/.

User Comments SYN Flood Part II
There are no user comments for this topic.