TCP Three-time handshake connection four handshake disconnects and Dos attacks

Reprint: http://blog.csdn.net/fw0124/article/details/7452695

status graph for TCP connections


TCP Three handshake process to establish a connection, and four handshake process to close the connection


Paste a telnet to establish the connection, disconnect the packet using Wireshark capture.


1. Establish Connection Agreement (three handshake)
(1) The client sends a TCP message with a SYN flag to the server. This is the message 1 in the three-time handshake process.
(2) server-side response to the client, this is the 2nd message in the three handshake, the message with both an ACK flag and a SYN flag. So it represents the response to the client's SYN message, and it also flags the SYN to the client and asks the client if it is ready for data communication.
(3) The customer must again respond to the service segment an ACK message, which is the message segment 3.

2. Connection Termination protocol (four handshake)
Because TCP connections are full-duplex, each direction must be closed separately. The principle is that when a party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means there is no data flow in this direction, and a TCP connection can still send data after receiving a fin. The first party to close will perform an active shutdown, while the other side performs a passive shutdown.
(1) The TCP client sends a fin to shut down the client-to-server data transfer (message segment 4).
(2) The server receives this fin, it sends back an ACK, confirms that the serial number is the received sequence number plus 1 (message Segment 5). As with Syn, a fin will occupy a sequence number.
(3) The server shuts down the client connection and sends a FIN to the client (message segment 6).
(4) The customer segment sends back ACK message confirmation, and the confirmation serial number is set to receive the serial number plus 1 (message segment 7).

CLOSED: This is nothing to say, it means the initial state.
LISTEN: This is also very easy to understand a state, that the server side of a socket is listening state, can accept the connection.
SYN_RCVD: This status means that the SYN message is received, under normal circumstances, this state is the server side of the socket in the establishment of a TCP connection during the three handshake session process of an intermediate state, very short, basically with netstat you are very difficult to see this state, Unless you specifically write a client-side test program, deliberately not send the last ACK message during the three TCP handshake. Therefore, when the ACK message is received from the client, it goes into the established state.
Syn_sent: This state is echoed with the syn_rcvd thinking back, when the client socket performs a connect connection, it sends the SYN message first, so it then enters the syn_sent state and waits for the server to send the 2nd message in the three-time handshake. The Syn_sent status indicates that the client has sent a SYN message.
Established: This is easy to understand, indicating that the connection has been established.
Fin_wait_1: This state should be well explained, in fact, the real meaning of fin_wait_1 and fin_wait_2 state is to wait for each other's fin message. The difference between the two states is: The fin_wait_1 state is actually when the socket in the established state, it would like to actively close the connection, send a FIN message to the other side, when the socket is entered into the fin_wait_1 state. And when the other party responds to the ACK message, then into the fin_wait_2 state, of course, under the actual normal circumstances, regardless of the circumstances of each other, should immediately respond to the ACK message, so fin_wait_1 state is generally more difficult to see, and Fin_wait_ 2 states can also sometimes be seen with netstat.
Fin_wait_2: Above has explained in detail this state, actually fin_wait_2 the socket in the state, indicates the half connection, also namely has the party request close connection, but also tells the other side, I temporarily also some data need to transmit to you, later closes the connection again.
Time_wait: Said to receive the other side of the fin message, and sent out an ACK message, just wait for 2MSL to return to the closed usable state. If the fin_wait_1 state, received the other side with the FIN flag and the ACK flag message, you can directly into the time_wait state, without having to go through the fin_wait_2 state.
CLOSING: This kind of state is special, the actual situation should be very rare, belong to a relatively rare exception state. Normally, when you send a fin message, it is supposed to receive (or receive) the other's ACK message before receiving the other's fin message. But closing status indicates that you send fin message, and did not receive the other's ACK message, but also received the other side of the fin message. Under what circumstances will this happen? In fact, it is not difficult to come to a conclusion: that is, if the two sides close a socket at the same time, then there is a situation where both sides send the fin message, there will be a closing state, indicating that both sides are shutting down the socket connection.
Close_wait: The meaning of this state is actually expressed in waiting to be closed. How do you understand it? When the other side close a socket to send fin message to yourself, you will undoubtedly respond to an ACK message to each other, then enter into the close_wait state. Next, the real thing you really need to consider is whether you still have the data sent to the other person, if not, then you can close the socket, send fin messages to each other, that is, close the connection. So what you need to accomplish in the close_wait state is waiting for you to close the connection.
Last_ack: This state is still relatively easy to understand, it is the passive close side after sending fin messages, and finally wait for each other's ACK message. When an ACK message is received, it is also possible to enter the closed available state.

Add:
A. By default (without changing the socket option), when you call Close (or closesocket, which says close no longer repeats), TCP continues to send the data out if there is data in the send buffer.
B. Sending fin simply means that the end cannot continue sending the data (the application layer can no longer call send), but may also receive data.
C. How does the application layer know the peer-to-peer shutdown? Typically, in the simplest blocking model, when you call recv, if you return 0, it means that the peer is closed. At this point the usual practice is to also call Close, then the TCP layer sends fin and continues to complete four handshake. If you do not call Close, the peer will be in the Fin_wait_2 state, and the local side will be in the close_wait state. This can write code to try.
D. In many cases, the TCP connection will be disconnected automatically by the TCP layer, for example, you have CTRL + C to terminate your program, the TCP connection will still shut down normally, you can write code to try.

1, why to establish a connection agreement is three handshake, and close the connection is four handshake it?
This is because the socket in the listen state of the server is sent in a message after it receives a request for the connection of the SYN message, and it can put the ACK and SYN (ACK response, and SYN synchronous). However, when the connection is closed, when receiving the other's fin message notification, it simply means that no data is sent to you, but not all of your data are sent to the other side, so you may not immediately close the socket, that is, you may also need to send some data to the other side, Send the FIN message to the other side to show that you agree that you can now close the connection, so it is here that the ACK message and fin messages are sent separately in most cases.

2, why time_wait state also need to wait 2MSL to return to closed status?
What is 2MSL? The MSL is maximum Segment Lifetime, which is the maximum lifetime of the message, in the words "TCP/IP Detail": "It (MSL) is the longest time in the network before any message segments are discarded." "Then, 2MSL is twice times the time, when the TCP connection completes the exchange of four segments, the active shutdown will continue to wait for a certain time (2-4 minutes), even if the end of the application ends." For example, after the Telnet program client is turned off, use Netstat to view the results:
C:\>netstat-na | Find "172.29.21.25"
TCP 172.29.132.60:2795 172.29.21.25:23 time_wait

Why do we need this 2MSL,
First, although both sides agreed to close the connection, and the handshake of the 4 messages are also coordinated and sent, can be directly back to the closed state (like from the Syn_send state to establish state); but because we have to assume that the network is unreliable, You cannot guarantee that the last ACK message you send will be received by the other party, so the socket in the Last_ack state may be re-sending the fin message because the timeout does not receive an ACK message, so this time_wait state is used to resend the possible missing ACK message.
Second, the message may be confused, meaning that other times the connection may be used as the connection. Direct reference to the TCP/IP guide saying: The second is to provide a "buffering period" between the end of this connection and any subsequ ENT ones. If not for this period, it was possible that packets from different connections could was mixed, creating confusion.

When one end of a connection is in the TIME_WAIT state, the connection will no longer be used. In fact, for our comparison, this port will no longer be used. When a port is in the TIME_WAIT state (which should actually be the connection), this means that the TCP connection is not disconnected (completely disconnected), and if you bind the port, it will fail. For a server, if the server suddenly crash out, it will not be able to restart within 2MSL because bind will fail. One way to solve this problem is to set the socket's SO_REUSEADDR option. This option means that you can reuse an address.

When a TCP connection is established, the server will continue to listen on the original port and use this port to communicate with the client. The client, by default, uses a random port to communicate with the server-side listening port. Sometimes, for server-side security, we need to authenticate the client, which is the client that qualifies a particular port on an IP. The client can use bind to use a specific port. For the server side, when the SO_REUSEADDR option is set, it can be started within 2MSL and listen successful. However, for clients, when BIND is used and SO_REUSEADDR is set, if bind is started within 2MSL, connect fails on the Windows platform. There is no such problem on Linux. (My experimental platform: WinXP, ubuntu7.10)

To resolve this issue with the Windows platform, you can set the So_linger option. The So_linger option determines the behavior of TCP when the close is called. So_linger involves the linger structure, if the set structure L_onoff is non-0,l_linger is 0, then call Close when the TCP connection is immediately disconnected, TCP will not send the unsent data sent in the buffer, but immediately send an RST message to the other side, At this point, the TCP connection (when closed) will not enter the TIME_WAIT state. As you can see, this solves the problem, but it's not safe. Setting the So_linger state in the above manner is equivalent to setting the So_dontlinger state.

When a TCP connection occurs with some physical exception, such as a network cable disconnection, the TCP implementation on Linux still considers the connection to be valid, and Windows returns an error message after a certain amount of time. This may seem to be resolved by setting the So_keepalive option, but it is not known whether this option is valid for all platforms.

3. Why can't I connect with a two-time handshake?
We know that 3 times handshake completes two important functions, both sides are ready to send data (both sides know each other is ready), also allow the two parties to negotiate the initial serial number, this serial number is sent and confirmed during the handshake.
Now it is possible to change the three-time handshake to just two handshakes. As an example, consider the communication between the computer S and C, assuming that C sends a connection request packet to S, s receives the packet and sends a confirmation reply packet. In accordance with the two-time handshake agreement, S believes that the connection has been successfully established and can begin sending data groupings. However, c in the case of S answer packet is lost in the transmission, will not know if S is ready, do not know what kind of serial number s to build, C even doubt whether s receive their own connection request grouping. In this case, C considers that the connection is not yet successful, ignores any data groupings that are sent by S, and waits only for the connection acknowledgment answer packet. and S repeats the same grouping after the emitted packet timeout. This creates a deadlock.

Dos attacks
Dos attacks, DDoS attacks, and DrDoS attacks I believe you have heard it already! DOS is a denial of service is a denial of services, and DDoS is distributed denial of service shorthand is distributed denial of service, and DrDoS is distributed Reflection denial The short of the service, which is the meaning of the distributed reflective denial service.
However, the most powerful attack method in the 3 is DDoS, the DrDoS attack is a new attack method, but it is only a distortion of DDoS attacks, it is the only difference is not to occupy a large number of "broilers." All three methods exploit the vulnerability of the TCP three handshake, so they have a similar defensive approach.

Dos attacks are the first to appear, and its attack method is plainly singled out, is better than who's machine performance, fast. But now the rapid development of science and technology, the general web hosting has more than 10 hosts, and the processing capacity of each host, memory size and network speed have a rapid development, and some network bandwidth even more than the gigabit level. This way our one-to-one combat attack will have little effect, and the machine will die. For example, if your machine can send 10 attack packets per second, and the machine you attack (performance, network bandwidth is top of the line) can accept and process 100 attack packets per second, then your attack is useless, and it is very likely to crash. You know, if you send this 1VS1 attack, your machine CPU utilization is more than 90%, your machine if the configuration is not high, then you are dead.
However, technology is developing and hacker technology is developing. The so-called however persuasive, magic a battle. After countless times, hackers have finally found a new approach to Dos attack, which is a DDoS attack. Its principle is OU, with a lot of machines on the target machine to launch a Dos attack, but this is not a lot of hackers involved, this attack is only a hacker to operate. The hacker does not have a lot of machines, he is through his machine on the network to occupy a lot of "broiler", and control these "broiler" to launch a DDoS attack, otherwise what is called distributed it. Or just that example, your machine can send 10 attack packets per second, and the attacked machine can accept 100 packets per second, so your attack will certainly not work, and you use 10 or more machines to attack the target of the machine attack, hey! I won't tell you the result.
DrDoS distributed reflex denial of service attack This is a distortion of DDoS attacks, unlike DDoS, where DrDoS does not need to occupy a large number of "broilers" before attacking. Its attack principle is similar to the Smurf attack principle, but DrDoS can be done on the WAN, and the Smurf attack is done on the LAN. It works based on the broadcast address and the response request. When a computer sends some special packets to another computer, such as a ping request, it receives a response from it, and if the request packet is sent to the broadcast address of the network, it will actually reach all the computers on the network, and the response will be received by all computers. These responses are processed by a computer that needs to be received, and each processing one consumes a system resource, and if the response to all the computers on the network is received at the same time, the receiver's system is likely to be overwhelmed, as if it were a DDoS attack. However, no one is stupid enough to attack themselves, but this method has been improved by hackers has great power. The hacker sends the request packet to the broadcast address, all the computers get the request, but does not send the reply to the hacker, but sends to the attacked host. This is because the hacker is impersonating the attacking host. The software used by the hacker to send the request package can forge the source address, and the host receiving the spoofed packets will send the response according to the source address, which is the address of the attacking host. The hacker will also reduce the time interval for sending the request packet, so that a large number of request packets can be issued in a short time, so that the attacked host receives a flood response from the spoofed computer, as if a DDoS attack caused the system to crash. Hackers use all the computers in the network to attack the victim without having to capture the spoofed hosts beforehand, which is the Smurf attack. And the DrDoS attack is this principle, the hacker also uses the Special Contract tool, first the forged source address of the SYN connection request packet sent to those spoofed computers, according to the TCP three handshake rules, these computers will issue the source IP syn+ack or RST packet response to this request. As with the Smurf attack, the source IP address of the request packet sent by the hacker is the address of the attacking host, so that the spoofed host will send the response to the attacking host, causing the host to be busy with the response and be paralyzed by the attack.
Explain:
SYN: (Synchronize sequence numbers) is used to establish a connection in connection request, syn=1,ack=0, connection response, syn=1,ack=1. That is, SYN and ACK to differentiate between connection request and connection Accepted.
RST: (Reset the connection) is used to reset the wrong connection caused by some cause, and also to reject illegal data and requests. Some errors usually occur when the RST bit is received.
ACK: (acknowledgment field significant) 1 indicates that the confirmation number (acknowledgment numbers) is legal, 0 indicates that the data segment does not contain confirmation information, the confirmation number is ignored.

We're going to set up a connection and the server is in a normal listening state.
The first step: we are the client to send a request with a SYN bit, to the server to indicate the need to connect, assuming the request packet sequence Number 10, then: syn=10,ack=0, and then wait for the server response.
Second step: After the server receives such a request package, check whether the specified port is being answered, and if not send rst=1 response, refuse to establish the connection. If the request packet is received, then the server sends a confirmation response, and the SYN is an internal code of the server, assuming that the 100,ack bit is the client's request sequence number plus 1, the data sent in this example is: syn=100,ack=11, with such data to respond to us. Show us that the server connection is ready and waiting for our confirmation. When we receive the response, we analyze the information and prepare to send a confirmation connection to the server.
Step three: We send a confirmation to establish the connection to the server. The SYN bit of the acknowledgment information is the ACK bit sent by the server, and the ACK bit is the SYN bit sent by the server plus 1. namely: syn=11,ack=101.
So our connection is set up.

How exactly does DDoS attack? The most popular and best-used attack method is to use Syn-flood to attack, Syn-flood is the SYN flood attack. Syn-flood does not complete the third step of the TCP three handshake, which is to not send the information confirming the connection to the server. In this way, the server cannot complete the third handshake, but the server does not give up immediately, and the server retries and waits for a certain amount of time to discard the incomplete connection, which is called SYN Timeout, which is about 30 seconds-2 minutes. It is not a big deal if a user has a problem connecting to a thread that causes the server to wait for 1 minutes, but if someone uses a special software to simulate the situation a lot, the consequences can be imagined. A server that handles these large amounts of semi-connected information consumes a lot of system resources and network bandwidth, so that the server is no longer free to handle normal user requests (because the client's normal request rate is small). This server will not work, this attack is called: Syn-flood attack.

So far, the defense of DDoS attacks has been difficult. First, this attack is characterized by its exploitation of the TCP/IP protocol vulnerability, which can be completely protected against DDoS attacks unless you do not use TCP/IP. But that doesn't mean we have no way of blocking DDoS attacks, and we can do our best to reduce DDoS attacks. Here are some defense methods:
1. Ensure that the server's system files are up-to-date and update the system patches in a timely manner.
2. Turn off unnecessary services.
3. Limit the number of SYN half connections that are open at the same time.
4. Shorten the time out of the SYN half-connection.
5. Set up the firewall correctly
6. Prohibit access to the host's non-open services
7. Restricting access to specific IP addresses
8. Enabling anti-DDoS properties for firewalls
9. Access to external servers strictly restricted to the open
10. Run the port mapper scourge port scanner to carefully check both the privileged and the non-privileged ports.
11. Carefully check the network equipment and the host/server system logs. This machine can be attacked as long as the log is compromised or time is changed.
12. Restrict the sharing of network files outside the firewall. This will give hackers the opportunity to intercept the system files, the host of information exposed to the hacker, is undoubtedly to the other side of the opportunity to invade.

TCP Three-time handshake connection four handshake disconnects and Dos attacks