CN107277035B

CN107277035B - Method for transmitting client information in TCP connection stage

Info

Publication number: CN107277035B
Application number: CN201710540886.2A
Authority: CN
Inventors: 张正新
Original assignee: BEIJING INFORMATION TECHNOLOGY COLLEGE
Current assignee: BEIJING INFORMATION TECHNOLOGY COLLEGE
Priority date: 2017-07-05
Filing date: 2017-07-05
Publication date: 2020-04-07
Anticipated expiration: 2037-07-05
Also published as: CN107277035A

Abstract

The invention discloses a method for transmitting client information in a TCP connection stage, which filters a connection request initiated by an application layer at an upper port of a client transmission layer, filters the sending and receiving of a network packet at an interface between a lower end of the client transmission layer and a network layer, and filters the receiving of the network packet at an interface between a server transmission layer and the network layer by modifying protocol stacks of both communication parties; the handshake process of the TCP is set to comprise an agreed mode and a negotiation mode, and application program information of the exchange client is additionally arranged in the handshake process of the TCP, so that fine network access control is realized, the effect of enhancing network security is achieved, and a basis is provided for packet screening aiming at service guarantee. The invention transmits the detailed information of the client process in the TCP connection message, can be used for the TCP monitoring end to carry out access authorization, and can be widely applied to access control in network security.

Description

Method for transmitting client information in TCP connection stage

Technical Field

The invention belongs to the technical field of network security, relates to access control in network security, and particularly relates to a method for transmitting client process detailed information in a TCP connection message middle section, wherein the client process detailed information can be used for a TCP monitoring end to carry out access authorization.

Background

In order to support interconnection and intercommunication among heterogeneous networks, reduce complexity of network design and simplify implementation of network equipment, a transmission control protocol/internet protocol (TCP/IP) is implemented by adopting a layered structure. Taking the four-layer model of TCP/IP as an example, the following are provided from top to bottom: application layer, transport layer, network interconnect layer, host-to-interface layer. All mainstream operating systems implement TCP/IP (protocol stack) in compliance with this layered model. The internet is developed to the scale of today, the layered model is unavailable, but the layered implementation has the weaknesses: with the gradual transmission of information, part of information of a high level in the process can be discarded, so that the network access control aiming at information safety is difficult to realize, and the basis for packet screening aiming at service guarantee is lacked.

TCP is a connection-oriented communication protocol, a connection is established through three-way handshake, and the connection is removed when communication is completed. The handshake process is as follows: the client sends a packet with a SYN ("sync") flag to request a connection; the server sends a packet with SYN and ACK ("acknowledgement") flags to answer the connection; and the client sends a packet with an ACK mark, and the connection is established. Taking a typical TCP-based client/server communication as an example: when a server program monitors connection on a designated TCP port, a client program initiates connection, and a connection request is sent to a protocol stack, process information of the client is still known, and after the request is transmitted from an application layer to a transmission layer through the protocol stack and then constructed into a SYN message, process related information (such as a process name, a user account and the like) is discarded and replaces a network address and a port number. For example, a Web service listens at a TCP 80 port and expects a response to a connection request initiated by a browser, but when a connection request arrives, it cannot be determined whether the opposite party is a browser or a malicious tool only according to the network address and the port information. The access control model is applied, and the control is invalid due to the fact that the subject is not clear.

Internet Protocol Security (IPsec) is a combination of protocols that protects the Internet transport Protocol suite (a collection of interrelated protocols) of the IP Protocol by encrypting and authenticating IP messages. IPsec consists of two major components:

key exchange protocol for establishing safe packet flow, namely Internet Key Exchange (IKE) protocol;

and (II) protocols for protecting the packet flow, including an encapsulating security payload protocol (ESP protocol) or an authentication header protocol (AH protocol) for encrypting the packet flow, are used for ensuring the confidentiality of data, the source reliability (authentication), the integrity of connectionless and providing anti-replay service. IPsec is used to provide:

ingress-to-ingress communication security, in which the security of packet communication is provided by a single node to multiple machines (and possibly even the entire local area network);

and (II) end-to-end packet communication security, wherein a computer as an endpoint completes security operation.

The primary use of IPSec is to construct Virtual Private Networks (VPNs), often implemented as dedicated devices. Any of the above modes may be used to construct a Virtual Private Network (VPN). However, limited to the layered framework, the authentication process of IPSec is only for the user identity, and is not related to specific network applications, that is, after the tunnel based on IPSec is established, the access between the client and the server is still unrestricted, and at this time, if malicious code tries to attack the server, data is still reachable. Furthermore, IPSec can significantly change the usage habits of users when applied, for example, requiring an authentication process requiring user intervention, such as entering an account password or inserting a smart card, before accessing a given network resource. Furthermore, IPSec is designed to be end-to-end (tunneling), not matching the open features of the existing internet as much, and is difficult to apply widely.

Disclosure of Invention

In order to overcome the defects of the prior art, the invention provides a method for transmitting client information at the TCP connection stage, which reforms the realization of a protocol stack on the premise of being compatible with the prior TCP/IP specification and not influencing the development of upper-layer application, and realizes fine access control by additionally exchanging the application program information of the client in the handshaking process of TCP, thereby achieving the effect of enhanced network security and providing additional support for quality of service (QoS).

The technical scheme provided by the invention is as follows:

a method for transmitting client information in TCP connection stage, through modifying the protocol stack of both sides of communication, add the application program information of the exchange client in the handshaking process of TCP (including agreement mode and negotiation mode), realize the meticulous access control, thus achieve the security effect of the enhanced network, and offer the additional support for quality of service (QoS);

specifically, the protocol stacks of both communication parties are modified by rewriting a TCP/IP protocol stack driver (for an open source system) or a filter/hook technology (for an open source system or a non-open source system), and for a client system: at the upper port of the transmission layer, filtering the connection request initiated by the application layer; filtering the transmission and reception of the network packet at the interface between the lower end and the network layer; for a TCP server-side system: at the interface between its transport and network layers, the reception of network packets is filtered.

In the process of handshaking the TCP connection, the method defines two working modes to adapt to different application scenes: in the mode, a client and a service party both assume that the other party can process client application program information carried in a handshake message; and secondly, negotiating a mode, wherein in the mode, the client assumes that the service party does not need or cannot process the client application program information carried in the handshake message, and the client constructs and sends the handshake message carrying the client application program information until the server explicitly returns a request of the client application program information.

The processing of the method in the TCP connection stage comprises the following steps:

step one, when a connection request of a client process reaches a protocol stack, starting to collect process information of the client, wherein the process information can comprise an account number, a name, a hash value, a code signature state of a process and call stack information of a current thread, and caching the information.

Step two, after a transmission layer module of a protocol stack completes analysis of a TCP connection request, a SYN message is constructed and sent to a network layer, and under an agreed mode, client process information cached in the step one is extracted and coded into a load of the SYN message; in the negotiation mode, the connection information in the SYN message is extracted, and the mapping between the connection information and the client process information extracted in the step one is established in a cache for subsequent processing.

Further, the second step specifically includes, in the default mode:

step A1, extracting the cached client process information, converting the client process information into a byte array by using a predetermined packaging algorithm, and adding the byte array into the transport layer load data of the SYN message;

the packing algorithm encodes the information into an array of bytes, for example: the contents contained in the information are added into a structure (struct) of a C language one by one, then the structure is encrypted by using an AES encryption algorithm, and then the memory of the encrypted structure is copied into the load data of the SYN message.

Step A2, recalculating the checksum of the TCP header of the SYN message;

step a3, the message length field in the SYN message IP header may be adjusted and the checksum of the IP header recalculated.

Further, the second step specifically includes, in the negotiation mode:

step B1, extracting the initial connection information contained in the SYN message, specifically including the destination IP address, the destination port number, and the SYN sequence number.

Step B2, a mapping of the initial connection information to the client process information is established in the cache, so as to reconstruct the SYN message when the server sends back the request.

Here, mapping refers to maintaining a one-to-one correspondence relationship between initial connection information and client process information in a memory, and a hash table may be used for storage in implementation, so as to accelerate the lookup speed.

Step B3, a timer process is created for the mapping established in step B2, so that the initial connection information, the client process information and the mapping data structure are destroyed from the cache after the connection is timed out.

And step three, the SYN message is transmitted to the service end, and if the protocol stack of the service end is not reformed by the protocol stack, the SYN + ACK response or RST (reset) rejection is responded according to a conventional mode. Otherwise, the server side tries to extract the client process information carried in the message, if the client works in an appointed mode, the message carries the client process information, the server side verifies whether the connection is allowed according to a preset rule, if not, the server side refuses the connection of the returned common RST message, and if so, the server side returns the SYN + ACK message; if the client works in the negotiation mode and the SYN message does not have the client process information, the server sends back the RST message, and adds the client process information request data in the RST message so as to expect the client to resend the SYN message.

The client process information request data attached to the RST message may include information such as selection of an encryption algorithm and key agreement thereof, and the security of the RST message may be ensured by using a common key encryption algorithm during encoding.

Step four, after the client receives the response of the server, according to different situations, the following conditions may be possible: in case one, the server side responds to the SYN + ACK message to confirm connection, and sends an ACK response, and the connection is successfully established; in case two, the server side responds to the common RST connection rejection message, and then returns a connection failure to the application layer; and in the third case, when the server side responds to the RST message with the client process information request data, the connection information and the process information are extracted from the cache, the SYN message is reconstructed according to the requirement in the client process information request data, and the client process information is carried in the message.

Further, in a third case of step four, the method comprises the following steps:

and step C1, extracting the client process information request data from the RST message.

And step C2, restoring the initial connection information from the RST message.

Step C3, using the initial connection information to search the client process information mapped by the initial connection information in the cache.

Step C4, according to the algorithm and the key required in the client process information request data extracted in step C1, the client process information is converted into a byte array by using a packaging algorithm and added to the transport layer load data of the SYN message;

step C5, recalculating the checksum of the TCP header of the SYN message;

step C6, the message length field in the IP header of the SYN message may be adjusted and the checksum of the IP header recalculated.

And step C7, sending the newly constructed SYN message.

And step five, destroying each cache created in the step when the connection is successfully established or fails, so that the client finishes the processing flow and realizes the transmission of client information in the TCP connection stage.

In the specific implementation of the invention, the method of the invention is adopted to process the situations that the client actively carries the process information (three-way handshake) in the agreed mode and the client passively carries the process information (five-way handshake) in the negotiation mode, and the transmission of the client information is realized in the TCP connection stage.

Compared with the prior art, the invention has the beneficial effects that:

the invention provides a method for transmitting client information in TCP connection stage, which realizes fine access control by additionally exchanging the application program information of the client in the handshaking process of TCP, thereby achieving the effect of enhanced network security and providing additional support for quality of service (QoS). The invention is realized by reforming the protocol stack under the premise of being compatible with the prior TCP/IP standard and not influencing the development of upper application, thereby realizing the network access control taking information safety as the target and simultaneously providing a basis for the packet screening taking service guarantee as the target. The invention transmits the detailed information of the client process in the middle section of the TCP connection message, and the detailed information of the client process can be used for the TCP monitoring end to carry out access authorization, and can be widely applied to access control in network security.

Drawings

FIG. 1 is a diagram illustrating an attachment location of a TCP/IP protocol stack according to an embodiment of the present invention;

wherein, the solid line represents the sending process of the message, and the dotted line represents the receiving process of the message; HookTI represents a hanging point for intercepting a TCP connection request at an entry point of a transport layer of a protocol stack; HookTO represents an attachment point for intercepting the transmission of a network packet at an exit point between a transport layer and a network layer; the HookRI denotes a point of suspension that intercepts reception of a transport layer packet at an entry point between the transport layer and the network layer.

FIG. 2 is a block flow diagram of the method of the present invention.

Fig. 3 is a flowchart of a method for delivering client information in a default mode according to an embodiment of the present invention.

Fig. 4 is a flowchart of a method for transmitting client information in negotiation mode according to an embodiment of the present invention.

Detailed Description

The invention will be further described by way of examples, without in any way limiting the scope of the invention, with reference to the accompanying drawings.

The invention provides a method for transmitting client information in TCP connection phase, which realizes fine access control by modifying protocol stacks of both communication sides and additionally exchanging application program information of a client in the handshaking process of TCP, thereby achieving the effect of enhanced network security and providing additional support for quality of service (QoS); fig. 1 illustrates the attachment positions of the TCP/IP protocol stack in the first and second embodiments. FIG. 2 illustrates the overall flow of the process of the present invention.

The protocol stacks of both communication sides are reformed, and in specific implementation, the protocol stacks are directly reformed at a source code level aiming at an open source system, so that the method is effective in developing an autonomous system; the filter and hook technology is that a parallel module is used for intervening a protocol stack, the compatibility is better, and a kernel module does not need to be replaced (flashing). In practical implementation, protocol stacks of two communication parties are mainly reconstructed through a filter and a hook technology.

The following embodiments specifically describe the case where the client actively carries the process information (three-way handshake) and the case where the client passively carries the process information (five-way handshake), respectively; fig. 3 and 4 show the implementation flows of the method of the invention in the first and second embodiments, respectively.

The first embodiment is as follows: the situation that the client actively carries the process information (three-way handshake) in the agreed mode:

in this embodiment, the method for transmitting client information in the TCP connection phase includes the following steps:

step one, hooking a protocol stack driver of a client operating system, intercepting a TCP connection request at an entry point of a protocol stack transmission layer, and recording the TCP connection request as a hooking point TI (HookTI); the transmission of network packets is intercepted at the egress point between the transport layer and the network layer, denoted as the hanging point, to (hookto).

And step two, when the client process tries to initiate TCP connection, the HookTI is hit, the HookTI processing routine starts to collect the process information of the client, the process information can comprise an account number, a name, a hash value, a code signature state and call stack information of a current thread, and the whole process information is marked as PISet.

And step three, caching the process information PISet collected in the step two for the next step or subsequent calling.

And fourthly, after the transmission layer module of the protocol stack completes analysis of the TCP connection request, constructing a SYN message and sending the SYN message to the network layer, namely, the HookTO is hit, and the HookTO processing routine extracts the cached PISet and adds the PISet to the load data of the SYN message.

Further, the fourth step specifically includes:

and step A, extracting the cached PISet information, converting the PISet information into a byte array by using a preset packaging algorithm, and adding the byte array into the transmission layer data of the SYN message.

And step B, recalculating the checksum of the TCP header.

And step C, if necessary, adjusting the message length field in the IP header and recalculating the checksum of the IP header.

And step five, the SYN message is transmitted to a server side, and the server side responds to the standard SYN + ACK message after verifying or ignoring the PISet in the SYN message.

And step six, after receiving the SYN + ACK responded by the server, the client sends an ACK response.

And at this moment, the processing flow of the client is finished, and the information of the client is transmitted in a TCP connection stage.

Example two: the situation that the client passively carries the process information (five-way handshake) in the negotiation mode:

step one, hooking a protocol stack driver of a client operating system, intercepting a TCP connection request at an entry point of a protocol stack transmission layer, and recording the TCP connection request as a hooking point TI (HookTI); intercepting the transmission of network packets at an exit point between a transmission layer and a network layer, and recording the transmission as a hitching point TO (HookTO); the entry point between the transport layer and the network layer intercepts the reception of the transport layer packet, denoted as a hangpoint ri (hookri).

And step three, caching the process information PISet collected in the step two for use when required by the subsequent steps.

And fourthly, after the transmission layer module of the protocol stack completes analysis of the TCP connection request, constructing a SYN message, sending the SYN message to a network layer, namely hitting HookTO, wherein the HookTO processing routine does not modify the message at the moment, but extracts the information related to the connection, and the information is cached and reserved for use.

Further, the fourth step specifically includes:

step A1, the recorded target IP, target port and SYN sequence number of SYN message are cached and recorded as connection information set CISet.

Step a2, for the connection session, a mapping relationship between CISet and PISet is established, and is denoted as CISet- > PISet.

Step a3, a timer CITimer is started, and the relevant set- > set data is destroyed after the connection is overtime.

And step five, the SYN message is transmitted to the server, if the server forcibly requires to verify the PISet of the client, the RST message with specific data PIReq is sent, connection is reset, and the client is required to provide the PISet. The PIReq data may include parameters related to the PISet encapsulation algorithm.

Step six, after receiving the RST message of the server, the client hits a hung point HookRI, a HookTI processing routine extracts PIReq data carried by the HookRI, restores the CISet of the original SYN message from the HookTI processing routine, and constructs a new SYN message after finding out the corresponding PISet.

Further, the sixth step specifically includes:

and step B1, extracting PIReq data from the load data of the RST message.

Step B2, the original CISet, i.e. the source IP, the source port number and the ACK sequence number (minus one), is restored from the IP header and the TCP header of the RST packet.

And step B3, finding the mapped process information PISet by the CISet.

And step B4, constructing a new SYN message, converting the PISet into a byte array according to the packaging algorithm required in the PIReq, and adding the byte array into the transmission layer data of the SYN message.

Step B5, recalculate the checksum of the TCP header.

Step B6, if necessary, adjusts the message length field in the IP header and recalculates the checksum of the IP header.

Step B7, discard the RST message, and do not submit it to the transport layer module, so as to maintain the connection process.

And step B8, destroying the CISet and closing the timer.

And step seven, transmitting the new SYN message to the server, and responding to the standard SYN + ACK message after the server verifies the PISet in the message.

And step eight, after receiving the SYN + ACK responded by the server, the client sends an ACK response.

It is noted that the disclosed embodiments are intended to aid in further understanding of the invention, but those skilled in the art will appreciate that: various substitutions and modifications are possible without departing from the spirit and scope of the invention and appended claims. Therefore, the invention should not be limited to the embodiments disclosed, but the scope of the invention is defined by the appended claims.

Claims

1. A method for transmitting client process information in TCP connection phase, which filters connection request initiated by application layer at the upper port of client transmission layer, filters the sending and receiving of network packet at the interface between the lower end of client transmission layer and network layer, and filters the receiving of network packet at the interface between server transmission layer and network layer by modifying protocol stack of both communication sides; the handshaking process of the TCP is set to comprise an agreed mode and a negotiation mode, and client process information is additionally exchanged in the handshaking process of the TCP, so that fine network access control is realized, and the effect of enhancing network security is achieved; the method comprises the following steps of processing in a TCP connection stage:

step one, when a connection request of a client process reaches a protocol stack, starting to collect client process information and caching the information; the client process information includes: account number, name, hash value, code signature state of the process and call stack information of the current thread;

step two, after the transmission layer module of the protocol stack completes the analysis of the TCP connection request, a SYN message is constructed and sent to the network layer; in an appointed mode, encoding the client process information cached in the step one into a load of a SYN message; in a negotiation mode, extracting connection information in the SYN message, and establishing mapping between the connection information and the client process information extracted in the step one in a cache;

step three, when the SYN message is transmitted to the server, the server tries to extract the client process information carried in the message, and responds according to the condition, and the loopback message comprises a SYN + ACK confirmation connection message, a common RST rejection connection message and a RST message with client process information request data;

step four, the client receives the response message of the server, determines that the two communication parties are successful in connection or failed in connection according to the message, extracts the connection information and the process information from the cache when the message is the RST message with the client process information request data, reconstructs the SYN message according to the requirement in the client process information request data, and carries and sends the client process information in the message;

step five, destroying each cache created in the step if the connection is successful or failed;

thereby enabling the transfer of client process information during the TCP connection phase.

2. The method according to claim 1, wherein said modifying protocol stacks of both communicating parties specifically comprises rewriting TCP/IP protocol stack drivers or using filter or hooking techniques.

3. The method according to claim 1, wherein in the agreed mode, the client and the server assume that the other party can process the client process information carried in the handshake message; in the negotiation mode, the client assumes that the server does not need or cannot process the client process information carried in the handshake message, and the client constructs and sends the handshake message carrying the client process information until the server returns a client process information request.

4. The method according to claim 1, wherein the second step encodes the extracted client process information cached in the first step into the payload of the SYN packet in a default mode; the method specifically comprises the following steps:

a1, extracting the cached client process information, converting the client process information into a byte array by using a predetermined packaging algorithm, and adding the byte array into the transport layer load data of the SYN message;

a2, recalculating the checksum of the TCP header of the SYN message;

a3, adjusting the message length field in the IP header of SYN message, and recalculating the checksum of the IP header;

step two specifically comprises the following processes in the negotiation mode:

b1, extracting the initial connection information contained in the SYN message, including the destination IP address, destination port number, SYN sequence number;

b2, establishing the mapping relation between the initial connection information and the client process information in the cache, so as to reconstruct the SYN message when the server sends back the request;

and B3, creating a timer processing procedure for the mapping relation established in B2, and destroying the initial connection information, the client process information and the mapping data structure from the cache after the connection is overtime.

5. The method for transferring client process information during the TCP connection phase as claimed in claim 4, wherein a hash table is used to store the mapping relationship information of the initial connection information established in the cache to the client process information.

6. The method for transferring client process information during TCP connection phase according to claim 1, wherein in step three, when the SYN message is transmitted to the server:

when the client works in an appointed mode, the message carries client process information, and the server verifies whether connection is allowed according to a preset rule; if not, rejecting connection by returning a common RST message; if the message is allowed, sending back a SYN + ACK message;

when the client works in the negotiation mode, the SYN message has no client process information, the server sends back the RST message, and the RST message is added with client process information request data for reference when the client sends the SYN message again.

7. The method as claimed in claim 6, wherein when the client is operating in the negotiation mode, the additional client process information request data in the RST message may include encryption method and key negotiation information.

8. The method for transmitting client process information at the TCP connection stage according to claim 1, wherein in the fourth step, when the packet is the RST packet with the client process information request data, the client extracts the connection information and the process information from the cache, reconstructs the SYN packet according to the request in the client process information request data, and sends the RST packet with the client process information; the method specifically comprises the following steps:

c1, extracting client process information request data from the RST message;

c2, restoring the initial connection information from the RST message;

c3, searching the mapped client process information in the cache by using the initial connection information;

c4, according to the algorithm and the key in the client process information request data extracted in C1, converting the client process information into a byte array by using a packaging algorithm, and adding the byte array to the transport layer load data of the SYN message;

c5, recalculating the checksum of the TCP header of the SYN message;

c6, adjusting the message length field in the IP header of SYN message, and recalculating the checksum of the IP header;

and C7, sending the newly constructed SYN message.