Edit filter log

[ 0 => '{{unreferenced|date=December 2013}}', 1 => '[[Image:Tcp normal.svg|thumb|right|A normal connection between a user ([[Alice and Bob|Alice]]) and a server. The three-way handshake is correctly performed.]]', 2 => '[[Image:Tcp synflood.png|thumb|right|SYN Flood. The attacker ([[Alice and Bob|Mallory]]) sends several packets but does not send the "ACK" back to the server. The connections are hence half-opened and consuming server resources. Alice, a legitimate user, tries to connect but the server refuses to open a connection resulting in a denial of service.]]', 3 => 'A '''SYN flood''' is a form of [[denial-of-service attack]] in which an attacker sends a succession of <code>[[SYN (TCP)|SYN]]</code> requests to a target's system in an attempt to consume enough server resources to make the system unresponsive to legitimate traffic.', 4 => '==Technical details==', 5 => 'Normally when a client attempts to start a [[Transmission Control Protocol|TCP]] connection to a server, the [[client (computing)|client]] and [[Server (computing)|server]] exchange a series of messages which normally runs like this:', 6 => false, 7 => '#The client requests a connection by sending a <code>SYN</code> (''synchronize'') message to the server.', 8 => '#The server ''acknowledges'' this request by sending <code>SYN-ACK</code> back to the client.', 9 => '#The client responds with an <code>ACK</code>, and the connection is established.', 10 => false, 11 => 'This is called the [[Transmission Control Protocol#Connection establishment|TCP three-way handshake]], and is the foundation for every connection established using the TCP protocol.', 12 => false, 13 => 'A SYN flood attack works by not responding to the server with the expected <code>ACK</code> code. The malicious client can either simply not send the expected <code>ACK</code>, or by [[IP address spoofing|spoofing]] the source [[IP address]] in the <code>SYN</code>, causing the server to send the <code>SYN-ACK</code> to a falsified IP address - which will not send an <code>ACK</code> because it "knows" that it never sent a <code>SYN</code>.', 14 => false, 15 => 'The server will wait for the acknowledgement for some time, as simple network congestion could also be the cause of the missing <code>ACK</code>, but in an attack increasingly large numbers of ''[[half-open connection]]s'' will bind resources on the server until no new connections can be made, resulting in a denial of service to legitimate traffic. Some systems may also malfunction badly or even crash if other operating system functions are starved of resources in this way.', 16 => false, 17 => '==Countermeasures==', 18 => 'There are a number of well-known countermeasures listed in RFC 4987 including:', 19 => false, 20 => '#Filtering', 21 => '#Increasing Backlog', 22 => '#Reducing SYN-RECEIVED Timer', 23 => '#Recycling the Oldest [[TCP half-open|Half-Open TCP]]', 24 => '#SYN Cache', 25 => '#[[SYN cookies]]', 26 => '#Hybrid Approaches', 27 => '#Firewalls and Proxies', 28 => false, 29 => '==See also==', 30 => '* [[Denial-of-service attack]]', 31 => '* [[IP address spoofing]]', 32 => '* [[Internet Control Message Protocol]]', 33 => '* [[Ping flood]]', 34 => '* [[UDP flood attack]]', 35 => '* [[Fraggle attack]]', 36 => '* [[Smurf attack]]', 37 => false, 38 => '==References==', 39 => '<references/>', 40 => false, 41 => '==External links==', 42 => '*[http://www.cert.org/advisories/CA-1996-21.html Official CERT advisory on SYN Attacks]', 43 => false, 44 => '{{DEFAULTSORT:Syn Flood}}', 45 => '[[Category:Denial-of-service attacks]]' ]