Examine individual changes

'GABE NEWALL W0Z 3R3 2015 <---SUCKA!!!!! [[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.]] [[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.]] 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. ==Technical details== 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: #The client requests a connection by sending a <code>SYN</code> (''synchronize'') message to the server. #The server ''acknowledges'' this request by sending <code>SYN-ACK</code> back to the client. #The client responds with an <code>ACK</code>, and the connection is established. 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. 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>. 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. ==Countermeasures== There are a number of well-known countermeasures listed in RFC 4987 including: #Filtering #Increasing Backlog #Reducing SYN-RECEIVED Timer #Recycling the Oldest Half-Open TCB #SYN Cache #[[SYN cookies]] #Hybrid Approaches #Firewalls and Proxies ==See also== * [[Denial-of-service attack]] * [[IP address spoofing]] * [[Internet Control Message Protocol]] * [[Ping flood]] * [[UDP flood attack]] * [[Fraggle attack]] * [[Smurf attack]] ==References== <references/> ==External links== *[http://www.cert.org/advisories/CA-1996-21.html Official CERT advisory on SYN Attacks] {{DEFAULTSORT:Syn Flood}} [[Category:Denial-of-service attacks]]'