Information transmission method, device, medium, electronic equipment and program product for preventing IP counterfeiting

Abstract

The present disclosure relates to an information transmission method, device, medium, electronic device and program product to prevent IP counterfeiting. The information transmission method to prevent IP counterfeiting includes: in response to receiving a first message sent by a client, replacing the source address in the first message with the address of the load balancing device itself, and generating TOA based on the source address in the first message, and using a generation method pre-agreed with the target server to generate a first label corresponding to the destination address in the first message; writing TOA and the first label to the first message obtained after the address replacement to obtain a second message; sending the second message to the target server, so that the target server determines whether the TOA field in the second message is credible based on the first label and the generation method. The scheme disclosed in the present disclosure can solve the problem that the attacking end causes the server to obtain a forged source address by forging the TOA field and label, and ensure the protection effect of the server's security system.

Description

Technical Field

[0001] The present disclosure relates to the field of computer network technology, and in particular to an information transmission method, device, medium, electronic device and program product for preventing IP counterfeiting. Background Art

[0002] Layer 4 load balancing is mainly based on Internet Protocol Address (IP address) and port for load balancing. When the load balancing device receives a request from a client, it will decide which source station (real server, RS) to forward the request to based on the destination address and port in the message and the server selection method set by the device itself. Taking the Transmission Control Protocol (TCP) as an example, when the load balancing device receives the first Synchronize Sequence Numbers (SYN) request from the client, it will select an RS and forward the message to the selected RS. Layer 4 load balancing is mainly used to solve the port limitation and high availability problems of Layer 7 load balancing. It can forward TCP / IP protocol and User Datagram Protocol (UDP).

[0003] At present, when forwarding the client's message, the four-layer load balancing device will perform source network address translation on the message, that is, replace the source address in the message with the address information of the load balancing device itself. In this way, when the backend server receives the message forwarded by the load balancing device, it cannot obtain the real client source address from the message, which will cause the server's Web firewall, anti-crawler system, anti-spam system and other security systems to be unable to analyze and protect the client source address, causing security risks.

[0004] In order for the server to obtain the real client source address, such as Figure 3 As shown in Figure 1, the TCP option address (TOA) is introduced, that is, the load balancing device inserts the source address of the normal client (i.e. Figure 3 The server can easily obtain the real client source address from the TOA field of the received message. However, the attacker (i.e., the malicious client) can construct a malicious TOA field and write a forged source address in the TOA. Since the TOA module of the current load balancing device fails to eliminate malicious TOA, the client source address obtained by the server is actually forged. These forged client source addresses will cause the server's security system to fail, causing security risks. Summary of the invention

[0005] This summary is provided to introduce concepts in a brief form that will be described in detail in the detailed description below. This summary is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0006] In a first aspect, the present disclosure provides an information transmission method for preventing IP counterfeiting, which is applied to a load balancing device, comprising:

[0007] In response to receiving a first message sent by a client, replacing a source address in the first message with an address of the load balancing device itself, generating a TCP option address TOA based on the source address in the first message, and generating a first label corresponding to the destination address in the first message using a generation method pre-agreed with a target server;

[0008] Writing the TOA and the first label into the first message obtained after the address replacement to obtain a second message;

[0009] The second message is sent to the target server, so that the target server determines whether the TOA field in the second message is credible based on the first tag and the generation method.

[0010] In a second aspect, the present disclosure provides an information transmission method for preventing IP counterfeiting, which is applied to a server and includes:

[0011] In response to receiving a target message sent by a client or a load balancing device, if the target message includes both a TCP option address TOA field and a label field, generating a second label corresponding to the destination address in the target message by using a generation method pre-agreed with the load balancing device, wherein the message sent by the load balancing device includes both a TOA field and a label field, and the value of the label field in the message sent by the load balancing device is a label generated by the load balancing device by using the generation method and corresponding to the destination address in the message;

[0012] Determining whether the second TOA field in the target message is credible according to a matching result between the second label and the second label field in the target message;

[0013] If the second TOA field is credible, the second TOA field is parsed to obtain the client source address.

[0014] In a third aspect, the present disclosure provides an information transmission device for preventing IP counterfeiting, which is applied to a load balancing device, including:

[0015] A first generating module, configured to, in response to receiving a first message sent by a client, replace a source address in the first message with an address of the load balancing device itself, generate a TCP option address TOA based on the source address in the first message, and generate a first label corresponding to the destination address in the first message by using a generation method pre-agreed with a target server;

[0016] A writing module, used for writing the TOA and the first label into the first message obtained after the address replacement, to obtain a second message;

[0017] A sending module is used to send the second message to the target server, so that the target server determines whether the TOA field in the second message is credible based on the first tag and the generation method.

[0018] In a fourth aspect, the present disclosure provides an information transmission device for preventing IP counterfeiting, which is applied to a server and includes:

[0019] A second generation module is used for, in response to receiving a target message sent by a client or a load balancing device, if the target message includes both a TCP option address TOA field and a label field, generating a second label corresponding to the destination address in the target message by using a generation method pre-agreed with the load balancing device, wherein the message sent by the load balancing device includes both a TOA field and a label field, and the value of the label field in the message sent by the load balancing device is a label generated by the load balancing device by using the generation method and corresponding to the destination address in the message;

[0020] A first determination module, configured to determine whether a second TOA field in the target message is credible according to a matching result between the second label and a second label field in the target message;

[0021] A parsing module is used to parse the second TOA field to obtain the client source address if the second TOA field is credible.

[0022] In a fifth aspect, the present disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the information transmission method for preventing IP counterfeiting provided in the first aspect of the present disclosure or the steps of the information transmission method for preventing IP counterfeiting provided in the second aspect of the present disclosure.

[0023] In a sixth aspect, the present disclosure provides an electronic device, including:

[0024] a storage device having a computer program stored thereon;

[0025] A processing device is used to execute the computer program in the storage device to implement the steps of the information transmission method for preventing IP counterfeiting provided by the first aspect of the present disclosure or the steps of the information transmission method for preventing IP counterfeiting provided by the second aspect of the present disclosure.

[0026] In the seventh aspect, the present disclosure provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the information transmission method for preventing IP counterfeiting provided in the first aspect of the present disclosure or the steps of the information transmission method for preventing IP counterfeiting provided in the second aspect of the present disclosure.

[0027] In the above technical solution, the message forwarded by the load balancing device to the server contains not only the TOA field but also the label. The label is generated by the load balancing device using a generation method pre-agreed with the server, that is, only the load balancing device and the server know the generation method of the label. Since the attacker does not know the generation method of the label, it is naturally unable to forge the correct label. Therefore, after receiving the message, the server can generate the expected label in the same way as the load balancing device generates the label, and determine whether the TOA field in the received message is credible, that is, whether the source address in the TOA field is forged, based on the match between the expected label and the label field in the received message, thereby solving the problem that the attacker causes the server to obtain a forged source address by forging the TOA field and label, avoiding the problem that the security policy for the client source address on the server is bypassed and the server's security system fails, and ensuring the protection effect of the server's security system. In addition, the attacker cannot collect the labels in the message received by the server from the load balancing device, but can only capture the labels in the message configured by the attacker to test the cloud server. Since the label is associated with the destination address in the message, the label captured by the attacker does not match the label in the message received by the server. In this way, the attacker cannot carry out the attack by replaying the message.

[0028] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale. In the drawings:

[0030] Figure 1 The figure is a schematic diagram of the structure of an IPv4 message according to an exemplary embodiment.

[0031] Figure 2The figure is a schematic diagram of the structure of an IPv6 message according to an exemplary embodiment.

[0032] Figure 3 It is a schematic diagram of the process in which the attacker sends a malicious TOA field to the load balancing device in the related technology, allowing the server to obtain a forged source address.

[0033] Figure 4 It is a schematic diagram of the process in the related technology in which the attacker sends a malicious TOA field to the server so that the server obtains a forged source address.

[0034] Figure 5 It is a schematic diagram of the process of alleviating the risk of forged source address in TOA field in the related art.

[0035] Figure 6 The present invention is a flowchart showing an information transmission method applied to a load balancing device according to an exemplary embodiment.

[0036] Figure 7 It is a schematic structural diagram of a variable part according to an exemplary embodiment.

[0037] Figure 8 The present invention is a flowchart showing an information transmission method applied to a load balancing device according to another exemplary embodiment.

[0038] Fig. 9 The invention is a flowchart showing an information transmission method applied to a server according to an exemplary embodiment.

[0039] Fig.10 The invention is a block diagram showing an information transmission device applied to a load balancing device according to an exemplary embodiment.

[0040] Fig.11 The invention is a block diagram showing an information transmission device applied to a server according to an exemplary embodiment.

[0041] Fig.12 The diagram is a schematic structural diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0042] Before introducing the specific embodiments of the present disclosure, the basic concepts involved in the present disclosure are first introduced and explained.

[0043] like Figure 1As shown in the figure, an IPv4 message consists of two parts: a header (i.e., a header) and data. The data is the data that needs to be transmitted by the higher layer, and the header is the control information added to correctly transmit the higher layer data. The first part of the header has a fixed length (i.e., a fixed part), a total of 20 bytes, which is required for all IP datagrams. After the fixed part of the header is an optional field (i.e., a variable part), which has a variable length. That is, the header of an IPv4 message includes a fixed part and a variable part.

[0044] like Figure 2 As shown in the figure, an IPv6 message consists of two parts: the header and the data. The data is the data that needs to be transmitted by the higher layer, and the header is the control information added to correctly transmit the higher layer data. The first part of the header has a fixed length (i.e., the basic header), a total of 20 bytes, which is required for all IP datagrams. The extension header follows the fixed part of the header. That is, the header of an IPv6 message includes the basic header and the extension header (also called the extension header).

[0045] As discussed in the background technology, the attacker can construct a malicious TOA field and write a forged source address in the TOA. Since the TOA module of the current load balancing device fails to eliminate malicious TOA well, the client source address obtained by the server is actually forged. These forged client source addresses will cause the server's security system to fail, causing security risks.

[0046] At present, there are two main scenarios where malicious TOA fields cause source address forgery. Figure 3 As shown in the first scenario, the attacker intentionally adds a forged source address (i.e. Figure 3The attacker fills the other option fields of the variable part to make the total length of the variable part in the whole message greater than 32 bytes. This is because the TCP protocol stack stipulates that the total length of the variable part cannot exceed 40 bytes (i.e., the maximum limit length). In this way, if the current length of the variable part in the message sent by the attacker to the load balancing device is greater than 32 bytes, it means that the remaining length of the variable part is less than 8 bytes, and the length of the TOA field is 8 bytes. Therefore, after the load balancing device receives the message sent by the attacker, since there is no enough space to write the real TOA field (i.e., the TOA field containing the source address of the attacker, which is a legal TOA field), the current general disposal method is to abandon writing the real TOA field and directly forward the TOA field carried by the attacker (illegal TOA field) to the backend server. After the server receives the message sent by the load balancing device, it extracts the source address from the TOA field of the received message, and finally obtains the forged source address of the attacker, rather than the real source address of the attacker.

[0047] The second scenario is that the attacker directly sends a malicious TOA field to the server, allowing the server to obtain a forged source address. Figure 4 As shown in the figure, the server can be accessed by both the load balancing device and the client directly. Therefore, when the server receives a message, if the message does not carry the TOA field, it is considered to be directly accessed by the client. At this time, the client source address can be directly extracted from the current TCP connection; if the message carries the TOA field, it is considered to be accessed by the load balancing device. At this time, the client source address will be extracted from the TOA field. When the attacker intentionally carries a TOA field containing a forged source address in the message, since the server cannot distinguish whether the TOA field is forged, it can only extract the source address from the TOA field, and finally obtains the forged client source address of the attacker.

[0048] In order to mitigate the risk of malicious TOA fields forging source addresses, the first scenario mentioned above is currently achieved by adjusting the writing method of the TOA field. Figure 5As shown, after the load balancing device receives a message from the client, it first detects whether the message contains a TOA field. If the message does not contain a TOA field, the real TOA field is inserted. If the message contains a TOA field, the real TOA field is used to overwrite the original TOA field in the message. Although this method can prevent malicious TOA from being transmitted to the server, the attacker can launch an attack through another mode, that is, the variable part of the attacker's message does not carry any TOA field, but uses various common option fields to fill, so that the current length of the variable part exceeds 32 bytes, so that the load balancing device cannot insert the TOA field, and of course cannot overwrite the TOA field. Finally, the load balancing device can only forward the message that does not contain any TOA field to the server. In this way, the server cannot extract the client source address from the TOA field, so it can only use the TCP connection address as the client source address, and finally use the source address of the load balancing device as the client source address, which also achieves the purpose of the attacker forging the source address, and finally causes the server to be unable to obtain the real source address of the attacker.

[0049] In order to mitigate the risk of malicious TOA fields forging source addresses, for the second scenario above, when the attacker sends a malicious TOA field to the server, the server sets the address whitelist of the load balancing device and only parses the TOA field in the message sent by the load balancing device in the address whitelist. Although this method can avoid the interference of malicious TOA to a certain extent, it is necessary to maintain the address whitelist. If the address of the load balancing device changes last time, the address whitelist needs to be updated synchronously. If the update is not timely, the message sent by the load balancing device may not correctly extract the TOA field, and thus the real client source address cannot be obtained, affecting the protection effect of the server's anti-crawler system, anti-brush system and other security systems.

[0050] In view of this, the present disclosure provides an information transmission method, device, medium, electronic device and program product for preventing IP counterfeiting.

[0051] Before introducing the specific implementation methods of the present disclosure, the application scenarios of the present disclosure are first introduced. In the current software service model, in order to provide large-scale access capabilities, multiple servers are usually deployed to provide services to the outside world. In the current service system, the client sends a message to the load balancing device, the source address in the message is the IP address of the client, and the destination address is the virtual IP (Virtual IP, VIP) address of the load balancing device. The load balancing device selects one from multiple servers as the target server according to its own configured strategy for ensuring load balancing, and converts the received message through the source network address translation (Source Network Address Translation, SNAT) technology. Specifically, the load balancing device modifies the source address in the message received from the client to the IP address of the load balancing device, and sends the modified message to the target server. After the target server accesses the shared database, it generates a response message for the modified message, and sends the response message to the load balancing device based on the source address of the load balancing device; the load balancing device then converts the destination address in the response message to the source address of the client and forwards it to the corresponding client.

[0052] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0053] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0054] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0055] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0056] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0057] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0058] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0059] For example, in response to receiving an active request from a user, a prompt message is sent to the user to clearly prompt the user that the operation requested to be performed will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, application, server, or storage medium that performs the operation of the technical solution of the present disclosure according to the prompt message.

[0060] As an optional but non-limiting implementation, in response to receiving an active request from the user, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. In addition, the pop-up window may also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0061] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that meet the relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0062] At the same time, it is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and relevant provisions.

[0063] Figure 6 FIG. 1 is a flow chart showing an information transmission method applied to a load balancing device according to an exemplary embodiment. Figure 6 As shown, the method may include the following S101 to S103.

[0064] In S101, in response to receiving a first message sent by a client, the source address in the first message is replaced with the address of the load balancing device itself, and a TCP option address TOA is generated based on the source address in the first message, and a first label corresponding to the destination address in the first message is generated using a generation method pre-agreed with the target server.

[0065] In the present disclosure, after receiving the first message sent by the client, the source address of the first message can be converted, that is, the source address in the first message is modified to the address of the load balancing device itself (that is, the IP address of the load balancing device).

[0066] like Figure 7 As shown (taking IPv4 as an example), the variable part of the message sent by the load balancing device to the server includes not only the TOA field, but also the label field, wherein the label field can be generated based on the destination address in the current message. The server can automatically identify whether the TOA field in the received message is credible based on the label field, that is, determine whether the source address in the TOA field in the message is forged.

[0067] like Figure 7 As shown in the figure, the label field can be divided into three parts, namely, the operation code (Opcode) field, the length (Opsize) field and the data (DATA) field. Among them, the length of the Opcode field is 1 byte, which is used to identify the option category, generally distinguished from the common option, and the value of the Opcode field is used to identify the label field category, usually a preset identifier; the length of the Opsize field is 1 byte, which is used to represent the length of the entire label field; the length of the DATA field is 2 bytes, specifically the label (Label) data, that is, the value of the label field.

[0068] After receiving the first message, the load balancing device can select a target server from multiple servers according to the strategy configured by itself to ensure load balancing. After that, the load balancing device can generate a first label corresponding to the destination address in the first message by using the generation method pre-agreed with the target server; and generate a TOA based on the source address in the first message.

[0069] In S102, a TOA and a first label generated based on the source address in the first message are written into the first message obtained after the address replacement to obtain a second message.

[0070] In the present disclosure, the second message includes a TOA field, that is, the second message only includes a TOA field. When the first message obtained after address replacement does not include a TOA field, the first TOA field and the first label field can be written to the first message obtained after address replacement in an insertion manner; when the first message obtained after address replacement includes a TOA field, the first TOA field can be written to the first message obtained after address replacement in an overwriting manner, that is, the original TOA field in the first message obtained after address replacement is overwritten with the first TOA field, and the first label field is written to the first message obtained after address replacement in an insertion manner. Among them, the first TOA field includes a TOA generated based on the source address in the first message, the first label field includes a first label and a preset identifier for identifying the label field category, the first label is the value of the first label field, specifically the value of the DATA field of the first label field, and the preset identifier is the value of the Opcode field.

[0071] In S103, the second message is sent to the target server, so that the target server determines whether the TOA field in the second message is credible based on the first tag and a generation method pre-agreed with the load balancing device.

[0072] In the present disclosure, after receiving the second message sent by the load balancing device, the target server can use the generation method pre-agreed with the load balancing device to generate a label corresponding to the destination address in the second message, and determine whether the TOA field in the second message is credible based on the matching result of the label and the first label, and when the TOA field in the second message is credible, parse the TOA field in the second message to obtain the client source address, and when the TOA field in the second message is not credible, ignore the TOA field, that is, do not parse the TOA field in the second message.

[0073] In the above technical solution, the message forwarded by the load balancing device to the server contains not only the TOA field but also the label. The label is generated by the load balancing device using a generation method pre-agreed with the server, that is, only the load balancing device and the server know the generation method of the label. Since the attacker does not know the generation method of the label, it is naturally unable to forge the correct label. Therefore, after receiving the message, the server can generate the expected label in the same way as the load balancing device generates the label, and determine whether the TOA field in the received message is credible, that is, whether the source address in the TOA field is forged, based on the match between the expected label and the label field in the received message, thereby solving the problem that the attacker causes the server to obtain a forged source address by forging the TOA field and label, avoiding the problem that the security policy for the client source address on the server is bypassed and the server's security system fails, and ensuring the protection effect of the server's security system. In addition, the attacker cannot collect the labels in the message received by the server from the load balancing device, but can only capture the labels in the message configured by the attacker to test the cloud server. Since the label is associated with the destination address in the message, the label captured by the attacker does not match the label in the message received by the server. In this way, the attacker cannot carry out the attack by replaying the message.

[0074] The following is a detailed description of the specific implementation of generating the first label corresponding to the destination address in the first message using the generation method pre-agreed with the target server in S101. Specifically, it can be described in detail through multiple implementations. In one implementation, it can be implemented through the following steps (a1) and (a2).

[0075] Step (a1): performing hash mapping on the destination address in the first message using a hash mapping method pre-agreed with the target server to obtain a first hash value.

[0076] In the present disclosure, a hash mapping method such as Cyclic Redundancy Check 32 (CRC32) and MD5 Message-Digest Algorithm may be used to perform hash mapping on the destination address in the first message to obtain a first hash value.

[0077] Step (a2): Generate a first tag based on the first hash value.

[0078] Since the length of the data field of the tag field is 2 bytes, after obtaining the first hash value corresponding to the destination address in the first message through the above step (a1), when the length of the first hash value is greater than two bytes, the first two bytes of the first hash value can be intercepted as the value of the DATA field of the first tag field. When the length of the first hash value is less than or equal to two bytes, the first hash value can be directly used as the DATA field of the first tag field, thereby generating the first tag.

[0079] In another implementation, the first tag field may be obtained by following the steps (b1) to (b3):

[0080] Step (b1): Encrypt the destination address in the first message using the salt value pre-agreed with the target server to obtain a first ciphertext.

[0081] Step (b2): Perform hash mapping on the first ciphertext using a hash mapping method pre-agreed with the target server to obtain a second hash value.

[0082] Step (b3): ​​Generate a first tag based on the second hash value.

[0083] Since the length of the DATA field of the tag field is 2 bytes, after obtaining the second hash value corresponding to the first ciphertext through the above step (b2), when the length of the second hash value is greater than two bytes, the first two bytes of the second hash value can be intercepted as the value of the DATA field of the first tag field. When the length of the second hash value is less than or equal to two bytes, the second hash value can be directly used as the value of the DATA field of the first tag field, thereby generating the first tag.

[0084] In the above implementation, before performing a hash operation on the destination address in the first message, the destination address is first encrypted using a salt value pre-determined with the target server, and then the first ciphertext obtained after encryption is hash mapped. In this way, even if the attacker guesses the hash mapping method agreed upon by the load balancing device and the target server, it is difficult to obtain the salt value agreed upon by them, and it is also impossible to forge the correct label, so that the server can accurately identify whether the source address in the TOA field in the message is forged based on the label in the received message.

[0085] The following describes in detail a specific implementation of writing the TOA and the first label generated based on the source address in the first message to the first message obtained after the address replacement in the above S102 to obtain the second message.

[0086] Specifically, if the first message obtained after the address replacement does not contain the TOA field, the first TOA field and the first label field are inserted into the header of the first message obtained after the address replacement to obtain the second message; if the first message obtained after the address replacement contains the TOA field, the first TOA field is used to overwrite the TOA field in the header of the first message obtained after the address replacement, and the first label field is inserted into the header obtained after the field overwriting to obtain the second message.

[0087] In this disclosure, Figure 8 As shown, before the load balancing device writes the first TOA field and the first label field into the first message obtained after the address replacement, it first determines whether the first message obtained after the address replacement contains the TOA field, so as to determine whether to write the first TOA field in an insertion manner or in an overwriting manner. When the first message obtained after the address replacement does not contain the TOA field, the first TOA field may be written in an insertion manner, that is, the first TOA field and the first label field may be inserted into the header of the first message obtained after the address replacement to obtain the second message; when the first message obtained after the address replacement contains the TOA field, the first TOA field may be written in an overwriting manner, that is, the first TOA field may be overwritten, that is, the original TOA field in the header of the first message obtained after the address replacement may be overwritten with the first TOA field, and the first label field may be inserted into the header obtained after the field overwriting to obtain the second message.

[0088] like Figure 8 As shown, if the load balancing device attempts to insert the first TOA field and the first label field successfully, or attempts to use the first TOA field to overwrite the original TOA field in the header of the first message obtained after address replacement, and successfully inserts the first label field into the header obtained after field overwriting, the load balancing device uses the real TOA back to the source and carries the label field, that is, the load balancing device sends the second message carrying the first TOA field and the first label field to the target server.

[0089] like Figure 8As shown, if the load balancing device cannot write due to the limited option length, that is, the attempt to insert the first TOA field and the first label field fails, then the non-essential option field in the first message obtained after the address replacement is deleted to free up the option space and then insert the first TOA field and the first label field; or, if the load balancing device attempts to use the first TOA field to overwrite the original TOA field in the header of the first message obtained after the address replacement, and fails to insert the first label field into the header obtained after the field overwriting, then the non-essential option field in the first message obtained after the address replacement is deleted to free up the option space and then use the first TOA field to overwrite the original TOA field in the header of the first message obtained after the address replacement, and insert the first label field. Afterwards, the load balancing device uses the real TOA to return to the source and carries the label field.

[0090] Among them, non-essential option fields refer to fields that do not affect TCP protocol transmission and control. Among them, the Maximum Segment Size (MSS) field (4 bytes), SACK-Permitted field (2 bytes) and Window Scale field (3 bytes) will affect TCP transmission and are necessary option fields. The load balancing device must transmit them to the server. All other option fields in the variable part of the header of the first message obtained after address replacement are non-essential option fields.

[0091] The following describes in detail a specific implementation method of inserting the first TOA field and the first label field into the header of the first message obtained after the address replacement to obtain the second message.

[0092] Specifically, when the first message is an IPv4 message, the first TOA field and the first label field can be inserted into the variable part of the header of the first message obtained after the address replacement. Since the TCP protocol stack stipulates that the length of the variable part of the IPv4 message cannot exceed 40 bytes, before inserting the first TOA field and the first label field into the variable part of the header of the first message obtained after the address replacement, it is necessary to first determine whether the remaining length of the variable part can meet the plug condition, that is, determine whether the remaining length of the variable part is greater than or equal to the total length of the first TOA field and the first label field, wherein the remaining length is the difference between the maximum limit length of the variable part (i.e., 40 bytes) and the current length of the variable part. When the remaining length of the variable part of the header of the first message obtained after the address replacement is greater than or equal to the total length of the first TOA field and the first label field, it is determined that the insertion condition is met. At this time, the first TOA field and the first label field can be directly inserted into the variable part of the header of the first message obtained after the address replacement; and when the remaining length of the variable part of the header of the first message obtained after the address replacement is less than the total length of the first TOA field and the first label field, at least part of the non-essential option fields in the variable part of the header of the first message obtained after the address replacement can be deleted, so that the remaining length of the variable part obtained after deleting the fields is greater than or equal to the total length of the first TOA field and the first label field, that is, space for the variable part is freed up, and then the first TOA field and the first label field are inserted into the variable part obtained after deleting the fields to obtain the second message.

[0093] In the present disclosure, all non-essential option fields in the variable part can be deleted, or some non-essential option fields in the variable part can be deleted, as long as the remaining length of the variable part after deleting the fields is greater than or equal to the total length of the first TOA field and the first label field.

[0094] When the first message is an IPv6 message, the first TOA field and the first label field can be inserted into the extension header of the first message obtained after the address replacement to obtain the second message. Since the extension header of the IPv6 message has no length limit, the first TOA field and the first label field can be directly inserted into the extension header of the first message obtained after the address replacement to obtain the second message.

[0095] The specific implementation method of inserting the first tag field into the header obtained after overwriting the field is described in detail below.

[0096] When the first message is an IPv4 message, the first label field can be inserted into the variable part of the header obtained after the field of the first message obtained after the address replacement is overwritten. Since the TCP protocol stack stipulates that the length of the variable part of the IPv4 message cannot exceed 40 bytes, before inserting the first label field into the variable part of the header obtained after the field overwriting, it is necessary to first determine whether the remaining length of the variable part meets the plug condition, that is, determine whether the remaining length of the variable part of the header obtained after the field overwriting is greater than or equal to the length of the first label field. When the remaining length of the variable part obtained after the field overwriting is greater than or equal to the length of the first label field, the first label field can be directly inserted into the variable part obtained after the field overwriting; and when the remaining length of the variable part obtained after the field overwriting of the first message obtained after the address replacement is less than the length of the first label field, at least part of the non-essential option fields in the variable part obtained after the field overwriting can be deleted, so that the remaining length of the variable part obtained after the field is deleted is greater than or equal to the length of the first label field, that is, the space of the variable part is freed up, and then the first label field is inserted into the variable part obtained after the field is deleted to obtain the second message.

[0097] In the present disclosure, all non-essential option fields in the variable part obtained after field overwriting can be deleted, or some non-essential option fields in the variable part obtained after field overwriting can be deleted, as long as the remaining length of the variable part obtained after deleting the fields is greater than or equal to the length of the first tag field.

[0098] When the first message is an IPv6 message, the first label field can be inserted into the extension header of the header obtained after the fields of the first message obtained after the address replacement are overwritten. Since the extension header of the IPv6 message has no length limit, the first label field can be directly inserted into the extension header of the header obtained after the fields are overwritten to obtain the second message.

[0099] Fig. 9 FIG. 1 is a flow chart showing an information transmission method applied to a server according to an exemplary embodiment. Fig. 9 As shown, the method may include the following S201 to S203.

[0100] In S201, in response to receiving a target message sent by a client or a load balancing device, if the target message contains both a TCP option address TOA field and a label field, a second label corresponding to the destination address in the target message is generated using a generation method pre-agreed with the load balancing device.

[0101] In the present disclosure, the server can be accessed by the load balancing device and can be directly accessed by the client. Therefore, the target message it receives may be sent by the client or the load balancing device. The message sent by the load balancing device contains both the TOA field and the label field. The value of the label field in the message sent by the load balancing device is a label corresponding to the destination address in the message generated by the load balancing device using a generation method. The attacker can forge the TOA field and the label at the same time, hoping to bypass the server's own security policy.

[0102] In S202, it is determined whether the second TOA field in the target message is authentic according to the matching result between the second tag and the second tag field in the target message.

[0103] In S203, if the second TOA field is credible, the second TOA field is parsed to obtain the client source address.

[0104] If the second label is consistent with the value of the second label field in the target message, the second TOA field is determined to be credible, that is, the source address in the second TOA field is determined to be not forged, but the real client source address. At this time, the second TOA field can be parsed to obtain the client source address. If the second label is inconsistent with the value of the second label field in the target message, the second TOA field is determined to be untrustworthy, that is, the source address in the second TOA field is determined to be forged, not the real client source address. At this time, the second TOA field can be ignored, that is, the second TOA field is not parsed.

[0105] In the above technical solution, the message forwarded by the load balancing device to the server contains not only the TOA field but also the label. The label is generated by the load balancing device using a generation method pre-agreed with the server, that is, only the load balancing device and the server know the generation method of the label. Since the attacker does not know the generation method of the label, it is naturally unable to forge the correct label. Therefore, after receiving the message, the server can generate the expected label in the same way as the load balancing device generates the label, and determine whether the TOA field in the received message is credible, that is, whether the source address in the TOA field is forged, based on the match between the expected label and the label field in the received message, thereby solving the problem that the attacker causes the server to obtain a forged source address by forging the TOA field and label, avoiding the problem that the security policy for the client source address on the server is bypassed and the server's security system fails, and ensuring the protection effect of the server's security system. In addition, the attacker cannot collect the labels in the message received by the server from the load balancing device, but can only capture the labels in the message configured by the attacker to test the cloud server. Since the label is associated with the destination address in the message, the label captured by the attacker does not match the label in the message received by the server. In this way, the attacker cannot carry out the attack by replaying the message.

[0106] The following describes in detail a specific implementation method of generating the second label corresponding to the destination address in the target message by using the generation method pre-agreed with the load balancing device in S201.

[0107] In one implementation, the destination address in the target message may be hash mapped using a hash mapping method pre-agreed with the load balancing device to obtain a third hash value; and then, the second label may be generated based on the third hash value.

[0108] In another embodiment, the destination address in the target message can be encrypted using a salt value pre-agreed with the load balancing device to obtain a second ciphertext; then, the second ciphertext is hashed using a hash mapping method pre-agreed with the load balancing device to obtain a fourth hash value; finally, based on the fourth hash value, a second label is generated.

[0109] In the present disclosure, the server can use a method similar to the above-mentioned method of using a generation method pre-agreed with the target server to generate a first label corresponding to the destination address in the first message, and use a generation method pre-agreed with the load balancing device to generate a second label corresponding to the destination address in the target message, which is not repeated in this disclosure.

[0110] In a possible implementation manner, the above method may further include the following steps:

[0111] If the target message includes the TOA field but does not include the label field, it is determined that the second TOA field is unreliable.

[0112] In order to bypass the server's own security policy, the attacker can forge the TOA field and the label at the same time, or only the TOA field. The message sent by the load balancing device contains both the TOA field and the label field. The message sent directly by the normal client to the server does not contain the TOA field. In this way, when the target message contains the TOA field but does not contain the label field, it indicates that the target message is sent by the attacker. At this time, it can be determined that the second TOA field is unreliable.

[0113] In a possible implementation manner, the above method may further include the following steps:

[0114] If the target message does not include the TOA field, the source address of the TCP connection used to transmit the target message is determined as the client source address.

[0115] In the present disclosure, when the target message does not contain the TOA field, it is determined that the target message is sent by the client. At this time, the client source address cannot be obtained by parsing the TOA. Therefore, the TCP connection used to transmit the target message can be determined first, and then the source address of the TCP connection can be determined as the client source address.

[0116] In a possible implementation manner, the above method may further include the following two steps:

[0117] If the target message contains the TOA field but does not contain the label field, it is determined that the second TOA field is unreliable;

[0118] If the target message does not include the TOA field, the source address of the TCP connection used to transmit the target message is determined as the client source address.

[0119] In a possible implementation manner, the above method may further include the following steps:

[0120] If it is detected that the header of the target message includes a preset identifier for identifying the type of the label field, it is determined that the target message includes the label field;

[0121] The field where the preset identifier is located is determined as the second label field.

[0122] In the present disclosure, after receiving the target message, the target server determines whether the target message contains a label field by identifying whether the header of the target message contains a preset identifier.

[0123] Fig.10 FIG. 1 is a block diagram of an information transmission device for preventing IP counterfeiting applied to a load balancing device according to an exemplary embodiment. Fig.10As shown, the information transmission device 300 for preventing IP counterfeiting applied to the load balancing device includes:

[0124] The first generating module 301 is used for replacing the source address in the first message with the address of the load balancing device itself in response to receiving the first message sent by the client, generating a TCP option address TOA based on the source address in the first message, and generating a first label corresponding to the destination address in the first message by using a generation method pre-agreed with the target server;

[0125] A writing module 302, configured to write the TOA and the first label into the first message obtained after the address replacement, to obtain a second message;

[0126] The sending module 303 is used to send the second message to the target server, so that the target server determines whether the TOA field in the second message is credible based on the first tag and the generation method.

[0127] In the above technical solution, the message forwarded by the load balancing device to the server contains not only the TOA field but also the label. The label is generated by the load balancing device using a generation method pre-agreed with the server, that is, only the load balancing device and the server know the generation method of the label. Since the attacker does not know the generation method of the label, it is naturally unable to forge the correct label. Therefore, after receiving the message, the server can generate the expected label in the same way as the load balancing device generates the label, and determine whether the TOA field in the received message is credible, that is, whether the source address in the TOA field is forged, based on the match between the expected label and the label field in the received message, thereby solving the problem that the attacker causes the server to obtain a forged source address by forging the TOA field and label, avoiding the problem that the security policy for the client source address on the server is bypassed and the server's security system fails, and ensuring the protection effect of the server's security system. In addition, the attacker cannot collect the labels in the message received by the server from the load balancing device, but can only capture the labels in the message configured by the attacker to test the cloud server. Since the label is associated with the destination address in the message, the label captured by the attacker does not match the label in the message received by the server. In this way, the attacker cannot carry out the attack by replaying the message.

[0128] Optionally, the writing module 302 includes:

[0129] The first insertion submodule is used to insert the first TOA field and the first label field into the header of the first message obtained after the address replacement if the first message obtained after the address replacement does not contain the TOA field, so as to obtain a second message, wherein the first TOA field includes the TOA, and the first label field includes the first label and a preset identifier for identifying the label field category.

[0130] Optionally, the first message is an IPv4 message;

[0131] The first insertion submodule comprises:

[0132] a first deletion submodule, configured to delete at least some of the non-essential option fields in the variable part if the remaining length of the variable part of the header is less than the total length of the first TOA field and the first label field, so that the remaining length of the variable part obtained after deleting the fields is greater than or equal to the total length, wherein the remaining length is a difference between a maximum limit length of the variable part and a current length of the variable part;

[0133] The second inserting submodule is used to insert the first TOA field and the first label field into the variable part obtained after deleting the field to obtain a second message.

[0134] Optionally, the first message is an IPv6 message;

[0135] The first inserting submodule is used to insert the first TOA field and the first label field into the extended header of the header of the first message obtained after the address replacement, so as to obtain a second message.

[0136] Optionally, the writing module 302 further includes:

[0137] The overwriting submodule is used to overwrite the TOA field in the header with the first TOA field if the first message obtained after address replacement contains a TOA field, and insert the first label field into the header obtained after field overwriting to obtain the second message.

[0138] Optionally, the covering submodule includes:

[0139] A second deletion submodule is used for deleting at least some non-essential option fields in the variable part obtained after the field is overwritten if the first message is an IPv4 message and the remaining length of the header obtained after the field is overwritten is less than the length of the first label field, so that the remaining length of the variable part obtained after the field is deleted is greater than or equal to the length of the first label field, wherein the remaining length is the difference between the maximum limit length of the variable part and the current length of the variable part; a third insertion submodule is used for inserting the first label field into the variable part obtained after the field is deleted;

[0140] The fourth insertion submodule is used to insert the first label field into the extension header of the header obtained after overwriting the fields if the first message is an IPv6 message.

[0141] Optionally, the first generating module 301 includes:

[0142] A first mapping submodule, configured to perform hash mapping on the destination address in the first message using a hash mapping method pre-agreed with the target server to obtain a first hash value;

[0143] The first generating submodule is used to generate the first label based on the first Hash value.

[0144] Optionally, the first generating module 301 includes:

[0145] A first encryption submodule, used to encrypt the destination address in the first message using a salt value pre-agreed with the target server to obtain a first ciphertext;

[0146] A second mapping submodule, configured to perform hash mapping on the first ciphertext using a hash mapping method pre-agreed with the target server to obtain a second hash value;

[0147] The second generating submodule is used to generate the first label based on the second Hash value.

[0148] Fig.11 FIG. 1 is a block diagram of an information transmission device for preventing IP counterfeiting applied to a server according to an exemplary embodiment. Fig.11 As shown, the information transmission device 400 for preventing IP counterfeiting applied to the server includes:

[0149] The second generation module 401 is used for generating a second label corresponding to the destination address in the target message by using a generation method pre-agreed with the load balancing device in response to receiving a target message sent by a client or a load balancing device, if the target message includes both a TCP option address TOA field and a label field, wherein the message sent by the load balancing device includes both a TOA field and a label field, and the value of the label field in the message sent by the load balancing device is a label generated by the load balancing device using the generation method and corresponding to the destination address in the message;

[0150] A first determination module 402, configured to determine whether a second TOA field in the target message is credible according to a matching result between the second label and a second label field in the target message;

[0151] The parsing module 403 is configured to parse the second TOA field to obtain a client source address if the second TOA field is credible.

[0152] In the above technical solution, the message forwarded by the load balancing device to the server contains not only the TOA field but also the label. The label is generated by the load balancing device using a generation method pre-agreed with the server, that is, only the load balancing device and the server know the generation method of the label. Since the attacker does not know the generation method of the label, it is naturally unable to forge the correct label. Therefore, after receiving the message, the server can generate the expected label in the same way as the load balancing device generates the label, and determine whether the TOA field in the received message is credible, that is, whether the source address in the TOA field is forged, based on the match between the expected label and the label field in the received message, thereby solving the problem that the attacker causes the server to obtain a forged source address by forging the TOA field and label, avoiding the problem that the security policy for the client source address on the server is bypassed and the server's security system fails, and ensuring the protection effect of the server's security system. In addition, the attacker cannot collect the labels in the message received by the server from the load balancing device, but can only capture the labels in the message configured by the attacker to test the cloud server. Since the label is associated with the destination address in the message, the label captured by the attacker does not match the label in the message received by the server. In this way, the attacker cannot carry out the attack by replaying the message.

[0153] Optionally, the first determination module 402 is configured to determine that the second TOA field is credible if the second tag is consistent with a value of the second tag field.

[0154] Optionally, the second generating module 401 includes:

[0155] A third mapping submodule, configured to perform hash mapping on the destination address in the target message using a hash mapping method pre-agreed with the load balancing device to obtain a third hash value;

[0156] The third generating submodule is used to generate the second label based on the third Hash value.

[0157] Optionally, the second generating module 401 includes:

[0158] A second encryption submodule, used to encrypt the destination address in the target message using a salt value pre-agreed with the load balancing device to obtain a second ciphertext;

[0159] a fourth mapping submodule, configured to perform hash mapping on the second ciphertext by using a hash mapping method pre-agreed with the load balancing device to obtain a fourth hash value;

[0160] The fourth generating submodule is used to generate the second label based on the fourth Hash value.

[0161] Optionally, the information transmission device 400 for preventing IP counterfeiting applied to the server further includes:

[0162] a second determination module, configured to determine that the second TOA field is unreliable if the target message includes a TOA field but does not include a label field; and / or

[0163] The third determination module is used to determine the source address of the TCP connection used to transmit the target message as the client source address if the target message does not include the TOA field.

[0164] Optionally, the information transmission device 400 for preventing IP counterfeiting applied to the server further includes:

[0165] a fourth determination module, configured to determine that the target message includes a label field if it is detected that the header of the target message includes a preset identifier for identifying a type of the label field;

[0166] The fifth determining module is used to determine the field where the preset identifier is located as the second tag field.

[0167] In addition, the present disclosure also provides a computer-readable medium on which a computer program is stored. When the program is executed by a processing device, the steps of the above-mentioned information transmission method for preventing IP counterfeiting applied to a load balancing device provided by the present disclosure or the steps of the above-mentioned information transmission method for preventing IP counterfeiting applied to a server provided by the present disclosure are implemented.

[0168] In addition, the present disclosure also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the above-mentioned information transmission method for preventing IP counterfeiting applied to a load balancing device provided by the present disclosure or the steps of the above-mentioned information transmission method for preventing IP counterfeiting applied to a server provided by the present disclosure.

[0169] Reference below Fig.12 , which shows a schematic diagram of the structure of an electronic device (client or server) 600 suitable for implementing the embodiment of the present disclosure. The terminal device in the embodiment of the present disclosure may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig.12 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0170] like Fig.12 As shown, the electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the electronic device 600 are also stored. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0171] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. Although Fig.12 The electronic device 600 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0172] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0173] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0174] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0175] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0176] The above-mentioned computer-readable medium carries one or more programs. When the above-mentioned one or more programs are executed by the electronic device, the electronic device: in response to receiving a first message sent by a client, replaces the source address in the first message with the address of the load balancing device itself, and generates a TCP option address TOA based on the source address in the first message, and uses a generation method pre-agreed with a target server to generate a first label corresponding to the destination address in the first message; writes the TOA and the first label to the first message obtained after the address replacement to obtain a second message; and sends the second message to the target server, so that the target server determines whether the TOA field in the second message is credible based on the first label and the generation method.

[0177] Alternatively, the computer-readable medium carries one or more programs, and when the one or more programs are executed by the electronic device, the electronic device: in response to receiving a target message sent by a client or a load balancing device, if the target message contains both a TCP option address TOA field and a label field, then generate a second label corresponding to the destination address in the target message using a generation method pre-agreed with the load balancing device, wherein the message sent by the load balancing device contains both a TOA field and a label field, and the value of the label field in the message sent by the load balancing device is a label generated by the load balancing device using the generation method and corresponding to the destination address in the message; determine whether the second TOA field in the target message is credible based on a matching result between the second label and the second label field in the target message; if the second TOA field is credible, parse the second TOA field to obtain the client source address.

[0178] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including, but not limited to, object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0179] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0180] The modules described in the embodiments of the present disclosure may be implemented by software or hardware. The name of the module does not limit the module itself in some cases. For example, the parsing module may also parse the second TOA field to obtain the client source address if the second TOA field is credible.

[0181] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0182] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0183] According to one or more embodiments of the present disclosure, Example 1 provides an information transmission method for preventing IP forgery, which is applied to a load balancing device, including:

[0184] In response to receiving a first message sent by a client, replacing a source address in the first message with an address of the load balancing device itself, generating a TCP option address TOA based on the source address in the first message, and generating a first label corresponding to the destination address in the first message using a generation method pre-agreed with a target server;

[0185] Writing the TOA and the first label into the first message obtained after the address replacement to obtain a second message;

[0186] The second message is sent to the target server, so that the target server determines whether the TOA field in the second message is credible based on the first tag and the generation method.

[0187] According to one or more embodiments of the present disclosure, Example 2 provides the method of Example 1, wherein the step of writing the TOA and the first label into the first message obtained after address replacement to obtain the second message includes:

[0188] If the first message obtained after the address replacement does not contain the TOA field, the first TOA field and the first label field are inserted into the header of the first message obtained after the address replacement to obtain a second message, wherein the first TOA field includes the TOA, and the first label field includes the first label and a preset identifier for identifying the label field category.

[0189] According to one or more embodiments of the present disclosure, Example 3 provides the method of Example 2, wherein the first message is an IPv4 message;

[0190] The inserting the first TOA field and the first label field into the header of the first message obtained after the address replacement to obtain the second message includes:

[0191] If the remaining length of the variable part of the header is less than the total length of the first TOA field and the first label field, delete at least some of the non-essential option fields in the variable part so that the remaining length of the variable part obtained after deleting the fields is greater than or equal to the total length, wherein the remaining length is a difference between the maximum limit length of the variable part and the current length of the variable part;

[0192] The first TOA field and the first label field are inserted into the variable part obtained after the field is deleted to obtain a second message.

[0193] According to one or more embodiments of the present disclosure, Example 4 provides the method of Example 2, wherein the first message is an IPv6 message;

[0194] The inserting the first TOA field and the first label field into the header of the first message obtained after the address replacement to obtain the second message includes:

[0195] The first TOA field and the first label field are inserted into the extended header of the header of the first message obtained after the address replacement to obtain a second message.

[0196] According to one or more embodiments of the present disclosure, Example 5 provides the method of Example 2, wherein the step of writing the first TOA field and the first label field to the first message obtained after address replacement to obtain a second message further includes:

[0197] If the first message obtained after address replacement contains a TOA field, the first TOA field is used to overwrite the TOA field in the header, and the first label field is inserted into the header obtained after field overwriting to obtain the second message.

[0198] According to one or more embodiments of the present disclosure, Example 6 provides the method of Example 5, wherein inserting the first tag field into the header obtained after the field overwriting includes:

[0199] If the first message is an IPv4 message and the remaining length of the header obtained after the fields are overwritten is less than the length of the first label field, then deleting at least some of the non-essential option fields in the variable part obtained after the fields are overwritten, so that the remaining length of the variable part obtained after the fields are deleted is greater than or equal to the length of the first label field, wherein the remaining length is the difference between the maximum limit length of the variable part and the current length of the variable part; inserting the first label field into the variable part obtained after the fields are deleted;

[0200] If the first message is an IPv6 message, the first label field is inserted into the extension header of the header obtained after overwriting the fields.

[0201] According to one or more embodiments of the present disclosure, Example 7 provides the method described in any one of Examples 1-6, wherein the step of generating a first label corresponding to the destination address in the first message by using a generation method pre-agreed with the target server includes:

[0202] Performing hash mapping on the destination address in the first message using a hash mapping method pre-agreed with the target server to obtain a first hash value;

[0203] Based on the first hash value, the first tag is generated.

[0204] According to one or more embodiments of the present disclosure, Example 8 provides the method described in any one of Examples 1-6, wherein the step of generating a first label corresponding to the destination address in the first message by using a generation method pre-agreed with the target server includes:

[0205] Encrypting the destination address in the first message using a salt value pre-agreed with the target server to obtain a first ciphertext;

[0206] Performing hash mapping on the first ciphertext using a hash mapping method pre-agreed with the target server to obtain a second hash value;

[0207] Based on the second hash value, the first tag is generated.

[0208] According to one or more embodiments of the present disclosure, Example 9 provides an information transmission method for preventing IP forgery, which is applied to a server and includes:

[0209] In response to receiving a target message sent by a client or a load balancing device, if the target message includes both a TCP option address TOA field and a label field, generating a second label corresponding to the destination address in the target message by using a generation method pre-agreed with the load balancing device, wherein the message sent by the load balancing device includes both a TOA field and a label field, and the value of the label field in the message sent by the load balancing device is a label generated by the load balancing device by using the generation method and corresponding to the destination address in the message;

[0210] Determining whether the second TOA field in the target message is credible according to a matching result between the second label and the second label field in the target message;

[0211] If the second TOA field is credible, the second TOA field is parsed to obtain the client source address.

[0212] According to one or more embodiments of the present disclosure, Example 10 provides the method of Example 9, wherein determining whether the second TOA field in the target message is credible according to a matching result between the second label and the value of the second label field in the target message includes:

[0213] If the second tag is consistent with the value of the second tag field, it is determined that the second TOA field is credible.

[0214] According to one or more embodiments of the present disclosure, Example 11 provides the method of Example 9, wherein the step of generating a second label corresponding to the destination address in the target message by using a generation method pre-agreed with the load balancing device includes:

[0215] Performing hash mapping on the destination address in the target message using a hash mapping method pre-agreed with the load balancing device to obtain a third hash value;

[0216] Based on the third hash value, the second tag is generated.

[0217] According to one or more embodiments of the present disclosure, Example 12 provides the method of Example 9, wherein the step of generating a second label corresponding to the destination address in the target message by using a generation method pre-agreed with the load balancing device includes:

[0218] Encrypting the destination address in the target message using a salt value pre-agreed with the load balancing device to obtain a second ciphertext;

[0219] Performing hash mapping on the second ciphertext using a hash mapping method pre-agreed with the load balancing device to obtain a fourth hash value;

[0220] Based on the fourth Hash value, the second tag is generated.

[0221] According to one or more embodiments of the present disclosure, Example 13 provides the method of any one of Examples 9-12, wherein the method further includes:

[0222] If the target message includes a TOA field but does not include a label field, determining that the second TOA field is unreliable; and / or

[0223] If the target message does not include a TOA field, the source address of the TCP connection used to transmit the target message is determined as the client source address.

[0224] According to one or more embodiments of the present disclosure, Example 14 provides the method of any one of Examples 9-12, wherein the method further includes:

[0225] If it is detected that the header of the target message includes a preset identifier for identifying the type of the label field, it is determined that the target message includes a label field;

[0226] The field where the preset identifier is located is determined as the second tag field.

[0227] According to one or more embodiments of the present disclosure, Example 15 provides an information transmission device for preventing IP counterfeiting, which is applied to a load balancing device, including:

[0228] A first generating module, configured to, in response to receiving a first message sent by a client, replace a source address in the first message with an address of the load balancing device itself, generate a TCP option address TOA based on the source address in the first message, and generate a first label corresponding to the destination address in the first message by using a generation method pre-agreed with a target server;

[0229] A writing module, used for writing the TOA and the first label into the first message obtained after the address replacement, to obtain a second message;

[0230] A sending module is used to send the second message to the target server, so that the target server determines whether the TOA field in the second message is credible based on the first tag and the generation method.

[0231] According to one or more embodiments of the present disclosure, Example 16 provides an information transmission device for preventing IP counterfeiting, which is applied to a server and includes:

[0232] A second generation module is used for, in response to receiving a target message sent by a client or a load balancing device, if the target message includes both a TCP option address TOA field and a label field, generating a second label corresponding to the destination address in the target message by using a generation method pre-agreed with the load balancing device, wherein the message sent by the load balancing device includes both a TOA field and a label field, and the value of the label field in the message sent by the load balancing device is a label generated by the load balancing device by using the generation method and corresponding to the destination address in the message;

[0233] A first determination module, configured to determine whether a second TOA field in the target message is credible according to a matching result between the second label and a second label field in the target message;

[0234] A parsing module is used to parse the second TOA field to obtain the client source address if the second TOA field is credible.

[0235] According to one or more embodiments of the present disclosure, Example 17 provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the information transmission method for preventing IP counterfeiting described in any one of Examples 1-14.

[0236] According to one or more embodiments of the present disclosure, Example 18 provides an electronic device, including:

[0237] a storage device having a computer program stored thereon;

[0238] A processing device is used to execute the computer program in the storage device to implement the steps of the information transmission method for preventing IP counterfeiting in any one of Examples 1-14.

[0239] According to one or more embodiments of the present disclosure, Example 19 provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the information transmission method for preventing IP counterfeiting described in any one of Examples 1-14.

[0240] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.

[0241] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0242] Although the subject matter has been described in language specific to structural features and / or method logic actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims. Regarding the device in the above embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Claims

1. A method for transmitting information to prevent IP counterfeiting, characterized in that: Applicable to load balancing devices, including: In response to receiving a first message sent by a client, replacing a source address in the first message with the address of the load balancing device itself, generating a TCP option address TOA based on the source address, and generating a first label corresponding to the destination address in the first message using a generation method pre-agreed with a target server; Writing the TOA and the first label into the first message obtained after the address replacement to obtain a second message; The second message is sent to the target server, so that the target server generates a label corresponding to the destination address in the second message by using the generation method, and determines whether the TOA field in the second message is credible based on the matching result between the label corresponding to the destination address in the second message and the first label.

2. The method according to claim 1, characterized in that The step of writing the TOA and the first label into the first message obtained after the address replacement to obtain a second message includes: If the first message obtained after the address replacement does not contain the TOA field, the first TOA field and the first label field are inserted into the header of the first message obtained after the address replacement to obtain a second message, wherein the first TOA field includes the TOA, and the first label field includes the first label and a preset identifier for identifying the label field category.

3. The method according to claim 2, characterized in that The first message is an IPv4 message; The inserting the first TOA field and the first label field into the header of the first message obtained after the address replacement to obtain the second message includes: If the remaining length of the variable part of the header is less than the total length of the first TOA field and the first label field, delete at least some of the non-essential option fields in the variable part so that the remaining length of the variable part obtained after deleting the fields is greater than or equal to the total length, wherein the remaining length is a difference between the maximum limit length of the variable part and the current length of the variable part; The first TOA field and the first label field are inserted into the variable part obtained after the fields are deleted to obtain a second message.

4. The method according to claim 2, characterized in that: The first message is an IPv6 message; The inserting the first TOA field and the first label field into the header of the first message obtained after the address replacement to obtain the second message includes: The first TOA field and the first label field are inserted into the extended header of the header of the first message obtained after the address replacement to obtain a second message.

5. The method according to claim 2, characterized in that: Writing the first TOA field and the first label field into the first message obtained after the address replacement to obtain a second message further includes: If the first message obtained after address replacement contains a TOA field, the first TOA field is used to overwrite the TOA field in the header, and the first label field is inserted into the header obtained after field overwriting to obtain the second message.

6. The method according to claim 5, characterized in that The inserting the first tag field into the header obtained after overwriting the fields comprises: If the first message is an IPv4 message and the remaining length of the header obtained after the fields are overwritten is less than the length of the first label field, then deleting at least some of the non-essential option fields in the variable part obtained after the fields are overwritten, so that the remaining length of the variable part obtained after the fields are deleted is greater than or equal to the length of the first label field, wherein the remaining length is the difference between the maximum limit length of the variable part and the current length of the variable part; inserting the first label field into the variable part obtained after the fields are deleted; If the first message is an IPv6 message, the first label field is inserted into the extension header of the header obtained after overwriting the fields.

7. The method according to any one of claims 1 to 6, characterized in that The step of generating a first label corresponding to the destination address in the first message by using a generation method pre-agreed with the target server includes: Performing hash mapping on the destination address in the first message using a hash mapping method pre-agreed with the target server to obtain a first hash value; Based on the first hash value, the first tag is generated.

8. The method according to any one of claims 1 to 6, characterized in that The step of generating a first label corresponding to the destination address in the first message by using a generation method pre-agreed with the target server includes: Encrypting the destination address in the first message using a salt value pre-agreed with the target server to obtain a first ciphertext; Performing hash mapping on the first ciphertext using a hash mapping method pre-agreed with the target server to obtain a second hash value; Based on the second hash value, the first tag is generated.

9. An information transmission method for preventing IP counterfeiting, characterized in that: Applicable to servers, including: In response to receiving a target message sent by a client or a load balancing device, if the target message includes both a TCP option address TOA field and a label field, generating a second label corresponding to the destination address in the target message by using a generation method pre-agreed with the load balancing device, wherein the message sent by the load balancing device includes both a TOA field and a label field, and the value of the label field in the message sent by the load balancing device is a label generated by the load balancing device by using the generation method and corresponding to the destination address in the message; Determining whether the second TOA field in the target message is credible according to a matching result between the second label and the second label field in the target message; If the second TOA field is credible, the second TOA field is parsed to determine the source address in the second TOA field as the client source address.

10. The method according to claim 9, characterized in that The determining, according to a matching result between the second label and a value of the second label field in the target message, whether the second TOA field in the target message is credible includes: If the second tag is consistent with the value of the second tag field, it is determined that the second TOA field is credible.

11. The method according to claim 9, characterized in that The generating a second label corresponding to the destination address in the target message by using a generating method pre-agreed with the load balancing device includes: Performing hash mapping on the destination address in the target message using a hash mapping method pre-agreed with the load balancing device to obtain a third hash value; Based on the third hash value, the second tag is generated.

12. The method according to claim 9, characterized in that The generating a second label corresponding to the destination address in the target message by using a generating method pre-agreed with the load balancing device includes: Encrypting the destination address in the target message using a salt value pre-agreed with the load balancing device to obtain a second ciphertext; Performing hash mapping on the second ciphertext using a hash mapping method pre-agreed with the load balancing device to obtain a fourth hash value; Based on the fourth Hash value, the second tag is generated.

13. The method according to any one of claims 9 to 12, characterized in that: The method further comprises: If the target message includes a TOA field but does not include a label field, determining that the second TOA field is unreliable; and / or If the target message does not include a TOA field, the source address of the TCP connection used to transmit the target message is determined as the client source address.

14. The method according to any one of claims 9 to 12, characterized in that: The method further comprises: If it is detected that the header of the target message includes a preset identifier for identifying the type of the label field, it is determined that the target message includes a label field; The field where the preset identifier is located is determined as the second tag field.

15. An information transmission device for preventing IP counterfeiting, characterized in that: Applicable to load balancing devices, including: A first generating module, configured to, in response to receiving a first message sent by a client, replace a source address in the first message with an address of the load balancing device itself, generate a TCP option address TOA based on the source address in the first message, and generate a first label corresponding to the destination address in the first message by using a generation method pre-agreed with a target server; A writing module, used for writing the TOA and the first label into the first message obtained after the address replacement, to obtain a second message; A sending module is used to send the second message to the target server, so that the target server uses the generation method to generate a label corresponding to the destination address in the second message, and determines whether the TOA field in the second message is credible based on the matching result between the label corresponding to the destination address in the second message and the first label.

16. An information transmission device for preventing IP counterfeiting, characterized in that: Applicable to servers, including: A second generation module is used for, in response to receiving a target message sent by a client or a load balancing device, if the target message includes both a TCP option address TOA field and a label field, generating a second label corresponding to the destination address in the target message by using a generation method pre-agreed with the load balancing device, wherein the message sent by the load balancing device includes both a TOA field and a label field, and the value of the label field in the message sent by the load balancing device is a label generated by the load balancing device by using the generation method and corresponding to the destination address in the message; A first determination module, configured to determine whether a second TOA field in the target message is credible according to a matching result between the second label and a second label field in the target message; A parsing module is used to parse the second TOA field if the second TOA field is credible, so as to determine the source address in the second TOA field as the client source address.

17. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processing device, the steps of the information transmission method for preventing IP counterfeiting described in any one of claims 1 to 14 are implemented.

18. An electronic device, characterized in that: include: a storage device having a computer program stored thereon; A processing device is used to execute the computer program in the storage device to implement the steps of the information transmission method for preventing IP counterfeiting according to any one of claims 1 to 14.

19. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the information transmission method for preventing IP counterfeiting according to any one of claims 1 to 14 are implemented.

Images