Resource attack

This article may be deleted soon.
	To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions. For the monthly nomination lists, see Category:Articles for deletion. In computer and network security — the two are very hard to separate in this context — a resource attack overwhelms "the victim’s CPU, memory, or network resources by sending large numbers of spurious requests." . Frequently, resource attacks combine with other attack modes, such as amplification attacks, but are harder to distinguish because the attack, at least superficially, resembles a legitimate system use. They are often identifiable only by the statistical properties of the multiple events that make up most resource attacks. Resource attacks differ from attacks that intend to disable a resource with a single operation. Instead, they are a version of the tragedy of the commons; the system attacked could very well tolerate a reasonable number of events, but not a flood of them. A simple amplification attack like smurf is distinctive, as was a basic worm attack such as Slammer. Nevertheless, even though smurf and Slammer were amplification attacks, they were also attacks against network bandwidth. SYN-FLOOD A SYN-FLOOD attack specifically targets computer rather than network resources, although network elements, as well as operating system hardware, helps mitigate it. In the normal operation of the Transmission Control Protocol, a connection is established with a three way handshake: The requester sends a TCP message with the SYN flag set The responder, if it chooses to accept the connection, sends back a new TCP message with SYN set The requester confirms by sending a message with SYN and ACK set; other parameters were agreed-to in the exchange, and communications begins. Conventional TCP implementations, at step 2, reserved system resources for the presumed connection. In the SYN-FLOOD attack, the miscreant would send SYN after SYN, with sufficiently different parameterization so they were not seen as duplicates, to lock up all the per-connection resources in the target host. An early version of this attack, targeting several operating systems, illustrates early experience with the attack Even at this stage of development of the attack, however, IP spoofing was an important part of the attack, so ingress filtering could help mitigate it. If, however, the flooding rate were not mitigated, the attack minimally tied up resources so that there could be no new legitimate use of the computer. The effects, however, were more catastrophic, a number of operating systems. In those more vulnerable operating systems, when all those resources were committed, a number that the software designers had never expected to be reached, the reception of one more SYN could cause the entire operating system to crash. Clearly, those systems needed immediate patching such that they stopped rather than overflowed when receiving an excessive number of SYNs. Other mitigation techniques worked, but could interfere with legitimate use. Rate-limiting the number of TCP connection attempt packets could slow access for authorized access to a busy server. Setting timers to clear half-open connections after a plausible interval was a more useful technique, but not a complete solution. That approach took resources, and the half-open ports still consumed resources for a time. If the purge timer value was too small, however, connections with slow connection requesters might never complete. Delaying part of the resource allocation until step three completes is effective. The system uses some resources tracking half-open connections from the time it receives the SYN packet, but if it delays allocating buffers until after the SYN/ACK then the resources wasted by incomplete connections are less. References