Summary of IP spoofing principles and Preventive Measures

Even if the TCP/IP protocol is well implemented, the TCP/IP network can be attacked due to its own security. These attacks include serial number spoofing, route attacks, Source Address Spoofing, and authorization spoofing. In addition to the IP spoofing attack method, this article also describes how to prevent this attack.

The above attacks are based on the attacker's computer (including routes) connected to the INTERNET. The attack method here is targeted at the defects of TCP/IP itself, rather than a specific implementation.

In fact, IP spoofing is not an attack, but an attack. Attack is actually the destruction of trust relationships.

IP spoofing Principle

Trust Relationship

In the Unix field, trust relationships can be easily obtained. If you have an account on host A and host B, you will find that when using host A, you need to enter the corresponding account on host, when using host B, you must enter an account on host B. host a and host B treat you as two unrelated users, which is obviously inconvenient. To reduce this inconvenience, you can establish mutual trust between two accounts on host A and host B. Create the. rhosts file in your home directory on host A and host B. From host A, enter echo "B username"> ~ in your home directory ~ /. Rhosts; from host B, enter echo "A username"> ~ in your home directory ~ /. Rhosts. At this point, you can use Remote logins starting with r *, such as rlogin, rcall, and rsh without any worries about password verification. These commands allow address-based authentication or allow or deny access services based on IP addresses.

Here, the trust relationship is based on IP addresses.

Rlogin

Rlogin is a simple client/server program that uses TCP transmission. Rlogin allows users to log on from one host to another, and if the target host trusts it, Rlogin allows users to use resources on the target host without answering the password. Security Verification is based entirely on the source host's IP address. Therefore, based on the above example, we can use Rlogin to remotely log on to A from B without being prompted to enter A password.

TCP serial number Prediction

The IP address only sends data packets and ensures its integrity. If you cannot receive the complete IP packet, the IP will send an ICMP error message to the source address, and you want to re-process it. However, this package may also be lost. Because the IP address is non-connection-oriented, it does not maintain any connection status information. Each IP packet is sent out loose, regardless of the first and last packets. It can be seen that the IP stack can be modified, and any IP address meeting the requirements can be placed in the source address and destination address, that is, a false IP address is provided.

TCP provides reliable transmission. Reliability is provided by the multi-bit control word in the data packet. The most important is the data sequence and data validation, which are expressed by SYN and ACK respectively. TCP assigns a serial number to each Data byte and can confirm the data packet sent to the received and source address (the packet sequence confirmed by the destination address ACK is the data packet sequence of the source address, instead of the data packet sequence sent by yourself ). ACK also carries the data serial number that is expected to be obtained. Obviously, the reliability provided by TCP is more difficult to fool than the IP address.

Serial number, validation, and other flag Information

Because TCP is based on reliability, it can provide mechanisms to handle packet loss, duplication, Order disorder, and other adverse situations. In fact, TCP can ensure reliable transmission by allocating serial numbers to all transmitted bytes and expecting the receiving end to provide the receiving confirmation for the data sent by the sending end. The acceptor uses the serial number to ensure the data sequence and remove repeated data packets. The TCP serial number can be considered as a 32-bit counter. They are arranged from 0 to 2 ^ 32-1. The data exchanged by each TCP connection (represented by a certain flag) is sequentially numbered. In a TCP packet, the identifier of the serial number (SYN) is defined at the front end of the Data Segment. ACK confirms the received data and specifies the serial number of the data to be received.

TCP uses the sliding window concept to control traffic. It is assumed that when the sending end sends data quickly but the receiving end receives the data slowly, in order to ensure that the data is not lost, it is necessary to control the traffic and coordinate the working pace of both parties. The so-called sliding window can be understood as the buffer size provided by the acceptor. TCP uses a sliding window to tell the sender how much buffer the data sent by it can provide. Because the window is defined by 16 bits, the receiving end TCP can provide a buffer of up to 65535 bytes. Therefore, you can use the window size and the serial number of the first data to calculate the maximum data serial number that can be received.

Other TCP flag BITs include RST (connection Reset, Reset the connection), PSH (Push function), and FIN (the sender has No data, No more data from sender ). If the RST is received, the TCP connection is immediately disconnected. RST is usually sent when the receiving end receives a packet unrelated to the current connection. In some cases, the TCP module needs to transmit data immediately instead of waiting until the entire segment is full. A high-level process will trigger the PSH mark in the TCP header and tell the TCP module to immediately send all the arranged data to the data receiving end. FIN indicates that an application connection has ended. When the receiving end receives the FIN, it determines that it will not receive any data.

TCP serial number prediction was first elaborated by Morris on this security vulnerability. He uses TCP serial number prediction to generate a TCP packet sequence even if no response is received from the server. This allows him to cheat hosts on the local network.

A TCP connection usually establishes a sequence that includes three handshakes. The customer selects and transmits an initial serial number (SEQ flag) isn c and sets the flag SYN = 1 to tell the server that it needs to establish a connection. The server confirms the transfer, sends its own serial number isn s, sets the flag ACK, and notifies the next expected data serial number ISN = 1. The customer confirms it again. After the three confirmations, data transmission starts. The entire process is as follows: (C: Client S: Server)
C---S: SYN (isn c)
S---C: SYN (isn s), ACK (isn c)
C---S: ACK (ISN seconds)
C---S: data or S---C: Data

That is to say, for a session, C must be confirmed by isn s. Isn s may be a random number.

It is important to know how to select the initial sequence number and how to change the sequence number based on time. It seems that this should happen when the serial number is initialized to 1 after the host is started, but this is not actually the case. The initial serial number is determined by the tcp_init function. ISN increases by 128000 per second. If a connection occurs, the counter value increases by 64000 for each connection. Obviously, this means that the 32-bit counter of ISN is reset every 9.32 hours without connection. This is because it helps minimize the chance that the information of the old connection will interfere with the current connection. Here we use the 2MSL wait time concept (not covered in this article ). If the initial serial number is randomly selected, the existing serial number cannot be different from the previous one. Assume that a packet in a routing loop jumps out of the loop and returns to the "old" connection (which is actually different from the existing connection in the former ), apparently, it will interfere with existing connections.

Assume that an intruder X has a way to predict isn s. In this case, he may send the following serial number to host T to simulate the real isn s of the customer:
X---S: SYN (isn x), SRC = T.
S---T: SYN (isn s), ACK (isn x)
X---S: ACK (isn s), SRC = T

Although the message S * T is not X, X can know its content and therefore send data. If X wants to launch an attack on a connection and the connection allows command execution, other commands can also be executed.

So how to generate random ISNs? In the Berkeley system, the initial serial number variable is generated by a constant plus one per second. When this constant is half done, a connection starts. In this way, if you start a valid connection and observe that an isn s is in use, you can calculate it with high reliability. isn s is used in the next connection attempt.

Morris pointed out that the reply message
S---T: SYN (isn s), ACK (isn x)
In fact it does not disappear. The real host will receive it and try to reconnect. This is not a serious obstacle.

Morris found that by imitating a port on T and requesting a connection to that port, he could generate a serial overflow, making it look that S * T messages are lost. Another method is to wait until you know that T is shut down or restarted.

The following is a detailed introduction.

IP Spoofing

IP spoofing consists of several steps. Here we will briefly describe it and then explain it in detail. First, the target host is selected. Second, the trust mode has been discovered and a host trusted by the target host has been found. In order to perform IP spoofing, hackers can perform the following tasks: to make the trusted host unable to work, sample the TCP serial number issued by the target host, and guess its data serial number. Then, disguise as a trusted host and establish an application connection with the target host based on address verification. If successful, hackers can use a simple command to place a system backdoor for unauthorized operations.

Deploy Trusted Hosts

Once a trusted host is discovered, it is often unable to work in disguise. Because the attacker will replace the truly trusted host, he must ensure that the truly trusted host cannot receive any valid network data; otherwise, the host will be exposed. There are many ways to do this. Here we will introduce "tcp syn flood ".

As mentioned above, the first step to establish a TCP connection is that the client sends a SYN request to the server. Generally, the server sends a SYN/ACK signal to the client. The client is determined by the IP address. The client then sends an ACK to the server, and then the data can be transmitted. However, the TCP processing module has a maximum number of concurrent SYN requests, which can be considered as the queue length for storing multiple connections. Among them, the number of connections includes the three-step handshake method that is not finally completed, but also the connections that have been successfully completed but not called by the application. If the maximum queue limit is reached, TCP rejects all connection requests until some connection links are processed. Therefore, there is an opportunity to multiply.

Hackers often send a large number of SYN requests to the target TCP port. The source address of these requests uses a valid but false IP address (the host using the valid IP address may not start up ). The attacked host often sends a response to the IP address, but it is a pity that there is no audio message. At the same time, the IP packet will notify the TCP of the attacked HOST: the host cannot be reached, but unfortunately TCP will think it is a temporary error, and continue to try the connection (for example, continue to route the IP address, send SYN/ACK packets, etc.) until you are sure you cannot connect.

Of course, this time has passed a lot of valuable time. It is worth noting that hackers will not use the IP addresses that are currently working, because in this way, the real IP address holder will receive a SYN/ACK response and then send the RST to the attacked host, disconnect. As described earlier