WO2015058324A1

WO2015058324A1 - Method for verifying security of tcp connection

Info

Publication number: WO2015058324A1
Application number: PCT/CN2013/001314
Authority: WO
Inventors: 邱文乔
Original assignee: 邱文乔
Priority date: 2013-10-22
Filing date: 2013-10-30
Publication date: 2015-04-30
Also published as: CN103532964B; CN103532964A

Abstract

Disclosed is a method for verifying the security of a TCP connection, using NDIS to modify SYN packet data when a client initiates a connection. Additional verification information is added to an option area or a data area, and only under the conditions that a server detects the verification information and the verification information is correct, subsequent connection actions are allowed to be performed so as to finish access; otherwise, the connection is hung up, or the packet is discarded, so that the connection cannot be finished, and subsequent attacks, stealing and the like cannot be finished; and by means of the method, the security of the server may be protected effectively immediately.

Description

A method for verifying the security of a TCP connection

The present invention relates to a method of verifying the security of a TCP connection.

Background technique

In existing network systems (local area networks, Internet), interactive data is mainly connected through the TCP/IP protocol. When the TCP/IP protocol was determined in the 1970s, it was mainly used for military purposes and used in closed networks. I didn't expect to get such a huge application, and of course I didn't consider security risks at all.

Existing security systems such as firewalls can effectively prevent attacks from external attacks. But for computers in the internal trust zone, there is no way to make more precise control. For example, users want to protect an important database system, and only allow anti-virus software and third-party audit software to be installed on the client computer to allow access to the database. Security systems such as existing firewalls cannot provide a solution to this requirement. Summary of the invention

The technical problem to be solved by the present invention is to provide a method for verifying the security of a TCP connection, which is effective for protecting the security of the server in the first time.

In order to solve the above technical problem, the technical solution provided by the present invention is: A method for verifying the security of a TCP connection, comprising the following steps:

1 On the client side, when the specified program sends a TCP connection request to the specified server address and port, the NDIS is used to modify the data packet of the TCP connection so that it can be accompanied by the padding data as the verification information;

2 On the server side, when receiving the TCP client connection request, first determine whether access is allowed by detecting whether there is attached data in the option area of the TCP packet; if there is no attached data, check the data of the TCP packet. Whether the area has accompanying data to determine whether access is allowed;

3 After the TCP connection is completed, when the client develops data, the data is encrypted by the SEAL algorithm and the previously saved key;

4 After receiving the data, the server decrypts the received data through the previously saved key and the SEAL algorithm.

The step 1 is specifically: first filling the TCP data packet with the accompanying data; then placing the generated incidental data directly at the end of the original SYN packet, and comparing the original SYN packet, the modified packet has 32 bytes of data. , To do this, the corresponding "Total Length" field indicating the length of the IP packet in the IP packet is also modified.

The incidental data filled in the TCP packet may be fixed data or variable data. The specific method for filling the TCP packet with the variable attached data is: according to the preset static value, the client address, the client port, the server address, the server port, the SEQ serial number in the SYN packet, and the sending time. The MD5 algorithm calculates a HASH value (16 bytes), which is placed in the check area; and generates a random 16-byte key, which is placed in the key area (and this value is local) Saved); The accompanying data obtained at this time is plaintext. To protect the key from being compromised, the data is encrypted with the RSA algorithm public key.

The accompanying data filled in the TCP packet may be placed in an option area of the TCP packet header or in a data area of the TCP packet.

The step 2 is specifically: after receiving the TCP connection request, the server first checks whether there is attached data in the option area, and if there is attached data, it determines whether it meets the rule feature, and if it matches, allows access, if not, then Deny access, and discard this packet or RST to hang up; if there is no data attached, determine whether there is a data area, if there is no data area, refuse access, and discard the packet or RST to hang up; if there is a data area, Then check the length of the data; if the data length is 16 bytes, determine whether it meets the rule characteristics, if it is consistent, allow access, if it does not, then refuse access, and discard the packet or RST to hang up; if the data length If it is 32 bytes, the RSA algorithm is used to decrypt the data, and then it is judged whether the first 16 bytes conform to the rule feature. If it matches, the access is allowed, and the last 16 bytes are saved for decryption of the data transmitted after the connection, if not If the match is denied access, and the packet is dropped or the RST hangs up.

The specific method for judging whether the rule characteristics are met is: first, the attached data is decrypted by using the RSA algorithm private key; then the TCP connection is verified to be trustworthy, and the algorithm is the same as the client, according to the preset static value, the client address, and the client. The port number, the server address, the server port, the SEQ sequence number in the SYN packet, and the sending time are calculated by the MD5 algorithm to calculate a HASH value (16 bytes). If this value matches the check value in the attached data, then Indicates that the connection is trusted, allows access, continues the subsequent connection process, and saves the key in the attached data; otherwise, rejects or ignores the request.

After adopting the above technical solution, the present invention has the following beneficial effects: In the process of handshake before data transmission, the invention adds the verification of the connection information, and the connection is allowed only when the connection packet containing the specific information is allowed, and the other Ordinary connection request packets, hang up the connection, or discard the package, so that the connection can not be completed, subsequent attacks and theft can not be completed, through this way, the server security can be effectively protected in the first time. DRAWINGS

In order to make the content of the present invention easier to understand, the present invention will be further described in detail below with reference to the accompanying drawings,

Figure 1 is a timing diagram of the TCP protocol when it is connected. Figure 2 is a diagram showing the structure of a packet when a standard TCP connection is made.

Figure 3 is a block diagram of the attached data using the option area of the TCP packet.

Figure 4 is a block diagram of the data area used to place the attached data using the TCP packet.

Figure 5 is a flow chart of the client generating variable accompanying data.

Figure 6 is a flow chart when the server processes the TCP connection. detailed description

(Embodiment 1)

This embodiment is mainly directed to an application using the TCP protocol. For the TCP protocol, a handshake connection must be made before data transmission. If the connection information is checked during the handshake process, the connection is allowed only when the connection packet contains the specific information, and the other ordinary connection request packet is hang up, or the packet is discarded, so that the connection cannot be completed. Subsequent attacks and theft can not be completed. In this way, the security of the server can be effectively protected in the first time.

As shown in Figure 1 to Figure 4, according to the TCP protocol, the TCP header can have an option area with a maximum space of 40 bytes, and the options that may be used in the first step of the client connection handshake to the server. There are: MSS maximum segment length, Kind=2, 4 bytes. Window Scale window expansion factor, Kind=3, 3 bytes. SACK-Permit selective confirmation, Kind=4, 2 bytes, Timestamp timestamp option, Kind=8, 10 bytes, after alignment, the maximum possible space is 20 bytes, that is, there are 20 bytes available. space. You can use this 20 bytes of free space to transfer some of the data we specify to verify the trustworthiness of the connection. For example, if the agreement "1234abcd" is the data recognized by both the TCP client and the server, then when the client initiates the connection, modify the SYN information through NDIS, and then add "1234abcd" at the end of the option area. When the server receives the TCP connection signal, it detects the option area. If there is more data than the normal option area, and it is "1234abcd", the connection is considered to be from a trusted computer, otherwise the connection is ignored or hanged. .

In addition to using fixed data, values generated from certain algorithms can also be used as a basis for both tests. For example, at the IP layer, we can get the source IP address and destination IP address. At the TCP layer, we can get the source port number, destination port number, SEQ number and other variables. In addition, we can fill in the predetermined dry code, combine these variables, and then pass the hash algorithm such as MD5/SHA1, or AES. Reversible algorithm, after calculation, get a value. Then fill it in the option area. When the server receives the connection request, if the check finds that there is extra data in the option area, the values of these variables are obtained one by one, and then calculated according to the same algorithm of the client, if it is related to the option. The same value stored in it indicates that the TCP connection is from a trusted client. Otherwise, the connection is ignored or hanged.

With the above method, the application can be further extended by encrypting the data transmitted by the subsequent TCP while verifying whether the connection is from the trusted computer, and further enhancing security. The method is as follows: The client initiates the connection The accompanying data consists of two parts, the first half is used to detect whether the connection is trusted, and the second half is used to transmit the key. When the client initiates the connection request, the above method is first filled in as the first half of the inspection area, and then a random value is generated as the key to fill in the second half (and the random key is saved) to obtain the complete attached data. (Clear text). This data (cryptotext) is then encrypted with the public key of the RSA algorithm. Then fill in the options area. When the server receives this attached data, it decrypts it with the private key of the RSA algorithm. First, it uses the first half of the attached data to check whether the connection is trustworthy. If it is trusted, it allows the connection, and the attached data of the second half (also Is the random key), save it. After the handshake connection is established, when the client transmits data, the data is first encrypted by the symmetric algorithm (DES\AES\SEAL\RC4, etc.) and then sent. When the server receives the data, it decrypts the data with the saved key.

If the amount of data that is attached is large, the option area cannot be placed all. The data can be placed in the data area of the TCP packet at SYN. The implementation process is the same as placing the accompanying data in the options area.

In summary, the method for verifying the security of a TCP connection in this embodiment includes the following steps:

1 On the client side, when the specified program sends a TCP connection request to the specified server address and port, the data packet at the time of the TCP connection is modified by NDIS so that the padding data can be attached as the verification information.

The step 1 is specifically: first filling the TCP data packet with the accompanying data; then placing the generated incidental data directly at the end of the original SYN packet, and comparing the original SYN packet, the modified packet has 32 bytes of data. For this purpose, the corresponding "Total Length" field indicating the length of the IP packet in the IP packet is also modified.

The accompanying data populated in the TCP packet can be either fixed data or variable data.

As shown in Figure 5, the specific method for populating the TCP packet with the variable data is: according to the preset static value, the client address, the client port, the server address, the server port, the SEQ sequence number in the SYN packet, and the sending time. , using the 5 algorithm to calculate a HASH value (16 bytes), this value is placed in the check area; at the same time generate a random 16-byte key, this value is placed in the key area, (and this value is The machine is saved.) The attached data obtained in this case is plain text. To protect the key from being compromised, the data is encrypted with the RSA algorithm public key.

The accompanying data populated in the TCP packet can be placed in the option area of the TCP packet header or in the data area of the TCP packet.

2 On the server side, when receiving the TCP client connection request, first determine whether access is allowed by detecting whether there is attached data in the option area of the TCP packet; if there is no attached data, check the data of the TCP packet. Does the zone have accompanying data to determine if access is allowed.

As shown in Figure 6, step 2 is as follows: After receiving the TCP connection request, the server first checks whether there is attached data in the option area. If there is attached data, it determines whether it meets the rule characteristics. If it matches, it allows access. If it does not match, the access is denied, and the packet is discarded or the RST hangs up; if there is no data attached, it is judged whether there is a data area, if there is no data area, the access is denied, and the packet is discarded or the RST hangs up; Data area, check the data length; If the data length is 16 bytes, it is judged whether it meets the rule characteristics. If it matches, the access is allowed. If it does not, the access is denied, and the packet is discarded or the RST hangs up. If the data length is 32 bytes, The RSA algorithm is used to decrypt the data, and then it is judged whether the first 16 bytes conform to the rule feature. If it is met, the access is allowed, and the last 16 bytes are saved for decryption of the data transmitted after the connection, and if not, the access is denied. And discard this packet or RST to hang up the connection.

The specific method for judging whether the attached rule character is met is as follows: firstly, the attached data is decrypted by using the RSA algorithm private key; then the TCP connection is verified to be trustworthy, and the algorithm is the same as the client, according to the preset static value, the client address, and the client. Port, server address, server port, SEQ sequence number in SYN packet, transmission time, calculate a HASH value (16 bytes) by MD5 algorithm; if this value is consistent with the check value in the attached data, it indicates The connection is trusted, allowing access, continuing the subsequent connection process, and saving the key in the attached data; otherwise, rejecting or ignoring the request.

3 After the TCP connection is completed, when the client develops data, the data is encrypted by the SEAL algorithm and the key saved in advance.

4 After receiving the data, the server decrypts the received data through the previously saved key and the SEAL algorithm. The above described specific embodiments of the present invention are described in detail, and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

claims

1. A method for verifying the security of TCP connections, characterized by: including the following steps -

① On the client side, when the specified program sends a TCP connection request to the specified server address and port, use NDIS to modify the data packet during the TCP connection so that it can be accompanied by filler data as verification information;

② On the server side, when receiving a TCP client connection request, it first determines whether access is allowed by checking whether there is attached data in the option area of the TCP packet; if there is no attached data, it then checks the data of the TCP packet. Whether there is accompanying data in the area to determine whether access is allowed;

③After completing the TCP connection, when the client develops data, the data is encrypted through the SEAL algorithm and the key saved in advance;

④After receiving the data, the server decrypts the received data through the pre-saved key and SEAL algorithm.

2. A method for verifying the security of a TCP connection according to claim 1, characterized in that: the step ① is specifically: first filling the TCP data packet with incidental data; and then placing the generated incidental data directly in the original At the end of the SYN packet, compared with the original SYN packet, the modified packet has 32 bytes more data. For this reason, the "Total Length" field in the IP packet that indicates the length of the IP packet must also be modified accordingly.

3. A method for verifying the security of a TCP connection according to claim 2, characterized in that: the incidental data filled in the TCP data packet can be fixed data or variable data.

4. A method for verifying the security of a TCP connection according to claim 3, characterized in that: the specific method of filling the TCP data packet with variable incidental data is: based on the preset static value, client address , client port, server address, server port, SEQ sequence number in the SYN packet, and sending time, use the MD5 algorithm to calculate a HASH value (16 bytes), and place this value in the check area; at the same time, generate a random The 16-byte key of this data.

5. A method for verifying the security of a TCP connection according to one of claims 2 to 4, characterized in that: the incidental data filled in the TCP data packet can be placed in the option area of the TCP data packet header, or can be Placed in the data area of the TCP packet.

6. A method for verifying the security of a TCP connection according to claim 1, characterized in that: the step ② is specifically: after the server receives the TCP connection request, first check whether there is accompanying data in the option area , if there is attached data, determine whether it meets the rule characteristics. If it matches, access is allowed. If it does not match, access is refused, and the packet is discarded or RST hangs up the connection. If there is no attached data, it is determined whether there is a data area. , if there is no data area, access is refused, and the packet is discarded or RST hangs up the connection; if there is a data area, the data length is checked; if the data length is

b 16 bytes, then determine whether it conforms to the rule characteristics. If it conforms, access is allowed. If it does not conform, access is denied, and the packet is discarded or RST hangs up the connection; if the data length is 32 bytes, use the RSA algorithm to decrypt it. This data is then judged whether the first 16 bytes comply with the rule characteristics. If it matches, access is allowed, and the last 16 bytes are saved for decryption of data transmitted after the connection. If it does not match, access is refused and the packet is discarded. Or RST hangs up the connection.

7. A method for verifying the security of a TCP connection according to claim 6, characterized in that: the specific method for judging whether the attached data conforms to the rule characteristics is: first, decrypting the attached data using the RSA algorithm private key; and then verifying the TCP connection. Whether it is trustworthy or not, the algorithm is the same as that of the client. It is calculated using the MD5 algorithm based on the pre-set static value, client address, client port, server address, server port, SEQ sequence number in the SYN packet, and sending time. A HASH value (16 bytes); if this value is consistent with the check value in the attached data, it indicates that the connection is trustworthy, access is allowed, the subsequent connection process continues, and the key in the attached data is saved; otherwise , the request is rejected or ignored.