Information transmission method and apparatus for preventing IP spoofing, medium, electronic device and program product

Abstract

The present disclosure relates to an information transmission method and apparatus for preventing IP spoofing, a medium, an electronic device and a program product. The information transmission method for preventing IP spoofing comprises: in response to receiving a first packet sent by a client, replacing a source address in the first packet with the address of a load balancing device itself, and, generating a TOA on the basis of the source address in the first packet, and, by means of a generation mode pre-agreed with a target server, generating a first label corresponding to a destination address in the first packet; writing the TOA and the first label into the first packet obtained after the address replacement, so as to obtain a second packet; and sending the second packet to the target server, so that the target server determines, on the basis of the first label and the generation mode, whether a TOA field in the second packet is trustworthy. The solution of the present disclosure can solve the problem of a server acquiring a spoofed source address due to an attacker spoofing a TOA field and a label, thereby ensuring the protection effect of security systems of servers.

Description

Information transmission methods, devices, media, electronic equipment, and software products for preventing IP spoofing.

[0001] This application claims priority to Chinese Patent Application No. 202410814361.3, filed on June 21, 2024, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0002] This disclosure relates to an information transmission method, apparatus, medium, electronic device, and program product for preventing IP spoofing. Background Technology

[0003] Layer 4 load balancing primarily relies on Internet Protocol (IP) addresses and ports for load balancing. When a load balancer receives a request from a client, it determines which origin server (real server, RS) to forward the request to based on the destination address and port in the packet, as well as the server selection method configured on the device itself. For example, using Transmission Control Protocol (TCP), when the load balancer receives the first Synchronize Sequence Number (SYN) request from a client, it selects an RS and forwards the packet to that selected RS. Layer 4 load balancing mainly addresses the port limitations and high availability issues of Layer 7 load balancing. It can forward TCP / IP and User Datagram Protocol (UDP) protocols.

[0004] Currently, Layer 4 load balancers perform source network address translation (NRT) on client packets, replacing the source address in the packet with the load balancer's own address information. This prevents the backend server from retrieving the actual client source address from the packet, hindering the server's web firewall, anti-crawler systems, and anti-scraping systems from analyzing and protecting against the client's source address, thus creating a security risk.

[0005] To enable the server to obtain the true client source address, as shown in Figure 3, a TCP option address (TOA) is introduced. The load balancer inserts a TOA field containing the source address of the legitimate client (IP address 1.1.1.1 in Figure 3) into the forwarded packets. The server can easily obtain the true client source address from the TOA field of the received packets. However, an attacker (i.e., a malicious client) can construct a malicious TOA field and write a forged source address into it. Because the TOA module of the current load balancer is not effective at eliminating malicious TOAs, 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, creating a security risk. Summary of the Invention

[0006] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0007] In a first aspect, this disclosure provides an information transmission method for preventing IP spoofing, applied to a load balancing device, comprising:

[0008] In response to receiving the first message sent by the 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. A first tag corresponding to the destination address in the first message is generated using a generation method pre-agreed with the target server.

[0009] Write the TOA and the first tag into the first message obtained after address replacement to obtain the second message;

[0010] The second message is sent to the target server, so that the target server can determine whether the TOA field in the second message is trustworthy based on the first tag and the generation method.

[0011] Secondly, this disclosure provides a method for preventing IP spoofing in information transmission, applied to a server, including:

[0012] In response to receiving a target packet sent by a client or load balancer, if the target packet contains both a TCP Option Address (TOA) field and a label field, a second label corresponding to the destination address in the target packet is generated using a pre-agreed generation method with the load balancer. The packet sent by the load balancer contains both a TOA field and a label field, and the value of the label field in the packet is a label generated by the load balancer using the aforementioned generation method, corresponding to the destination address in the packet.

[0013] Based on the matching result between the second tag and the second tag field in the target message, determine whether the second TOA field in the target message is trustworthy;

[0014] If the second TOA field is reliable, then parse the second TOA field to obtain the client source address.

[0015] Thirdly, this disclosure provides an information transmission device for preventing IP spoofing, applied to load balancing equipment, comprising:

[0016] The first generation module is used to respond to receiving a first message sent by the client, replace the source address in the first message with the 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 tag corresponding to the destination address in the first message using a generation method pre-agreed with the target server.

[0017] The writing module is used to write the TOA and the first tag into the first message obtained after address replacement, so as to obtain the second message;

[0018] The sending module is used to send the second message to the target server, so that the target server can determine whether the TOA field in the second message is trustworthy based on the first tag and the generation method.

[0019] Fourthly, this disclosure provides an information transmission device for preventing IP spoofing, applied to a server, comprising:

[0020] The second generation module is used to respond to receiving a target packet sent by a client or load balancing device. If the target packet contains both a TCP Option Address (TOA) field and a label field, it generates a second label corresponding to the destination address in the target packet using a generation method pre-agreed with the load balancing device. The packet sent by the load balancing device contains both a TOA field and a label field. The value of the label field in the packet 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 packet.

[0021] The first determining module is used to determine whether the second TOA field in the target message is trustworthy based on the matching result between the second tag and the second tag field in the target message;

[0022] The parsing module is used to parse the second TOA field to obtain the client source address if the second TOA field is trustworthy.

[0023] Fifthly, this disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the anti-IP spoofing information transmission method provided in the first aspect of this disclosure or the steps of the anti-IP spoofing information transmission method provided in the second aspect of this disclosure.

[0024] Sixthly, this disclosure provides an electronic device, comprising:

[0025] A storage device on which computer programs are stored;

[0026] A processing device is configured to execute the computer program in the storage device to implement the steps of the information transmission method for preventing IP spoofing provided in the first aspect of this disclosure or the steps of the information transmission method for preventing IP spoofing provided in the second aspect of this disclosure.

[0027] In a seventh aspect, this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the anti-IP spoofing information transmission method provided in the first aspect of this disclosure or the steps of the anti-IP spoofing information transmission method provided in the second aspect of this disclosure.

[0028] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0029] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote 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 is a schematic diagram of the structure of an IPv4 message according to an exemplary embodiment;

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

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

[0033] Figure 4 is a schematic diagram of the process in the related technology where the attacker sends a malicious TOA field to the server, allowing the server to obtain a forged source address;

[0034] Figure 5 is a schematic diagram of the process for mitigating the risk of source address forgery in the TOA field in related technologies;

[0035] Figure 6 is a flowchart illustrating an information transmission method applied to a load balancing device according to an exemplary embodiment;

[0036] Figure 7 is a schematic diagram of the structure of a variable part according to an exemplary embodiment;

[0037] Figure 8 is a flowchart illustrating an information transmission method applied to a load balancing device according to another exemplary embodiment;

[0038] Figure 9 is a flowchart illustrating an information transmission method applied to a server according to an exemplary embodiment;

[0039] Figure 10 is a block diagram illustrating an information transmission device applied to a load balancing device according to an exemplary embodiment;

[0040] Figure 11 is a block diagram illustrating an information transmission device applied to a server according to an exemplary embodiment; and

[0041] Figure 12 is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

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

[0043] As shown in Figure 1, an IPv4 packet consists of two parts: a header and data. The data is the information that higher layers need to transmit, while the header contains control information added to ensure the correct transmission of higher-layer data. The first part of the header has a fixed length (fixed portion), totaling 20 bytes, and is mandatory for all IP datagrams. Following the fixed portion are optional fields (variable portion), which have a variable length. In other words, the IPv4 packet header includes both a fixed and a variable portion.

[0044] As shown in Figure 2, an IPv6 packet consists of two parts: a header and data. The data is the information that higher layers need to transmit, while the header contains control information added to ensure the correct transmission of higher-layer data. The first part of the header has a fixed length (the basic header), totaling 20 bytes, and is mandatory for all IP datagrams. Following the fixed part of the header is the extension header. In other words, the IPv6 packet header includes both the basic header and the extension header (also known as the extension header).

[0045] As discussed in the background section, attackers can construct malicious TOA fields and write forged source addresses into them. Since the TOA modules of current load balancing devices fail to effectively eliminate malicious TOA fields, the client source addresses obtained by the server are actually forged. These forged client source addresses will cause the server's security system to fail, resulting in security risks.

[0046] Currently, there are two main scenarios where malicious TOA fields cause source address forgery. As shown in Figure 3, the first scenario involves the attacker intentionally adding a forged source address (i.e., IP address 1.1.1.1 in Figure 3) TOA to the variable portion (including the option field) of the IPv4 header sent to the load balancer. Furthermore, the attacker fills in other option fields in the variable portion to make the total length of the variable portion of the entire packet greater than 32 bytes. This is because the TCP protocol stack stipulates that the total length of the variable portion cannot exceed 40 bytes (i.e., the maximum limit length). Thus, if the current length of the variable portion in the packet sent by the attacker to the load balancer is greater than 32 bytes, it means that the remaining length of the variable portion is less than 8 bytes. The TOA field has a length of 8 bytes. Therefore, after the load balancer receives the packet sent by the attacker, since there is not enough space to write the real TOA field (i.e., the TOA field containing the attacker's source address, which is a legitimate TOA field), the current common practice is to abandon writing the real TOA field and directly forward the TOA field carried by the attacker (the illegitimate TOA field) to the backend server. After receiving a message from the load balancer, the server extracts the source address from the TOA field of the received message, thus obtaining the source address forged by the attacker, rather than the attacker's own real source address.

[0047] The second scenario involves the attacker directly sending a malicious TOA field to the server, allowing the server to obtain a forged source address. As shown in Figure 4, the server can be accessed by both load balancers and clients. Therefore, when the server receives a packet, if the packet does not carry a TOA field, it assumes it is a direct client access and can directly extract the client's source address from the current TCP connection. If the packet carries a TOA field, it assumes it is a load balancer access and will extract the client's source address from the TOA field. When the attacker intentionally includes a TOA field with a forged source address in the packet, the server cannot distinguish whether the TOA field is forged and can only extract the source address from it, ultimately obtaining the forged client source address.

[0048] To mitigate the risk of malicious TOA field forgery of source addresses, the first scenario described above is currently addressed by adjusting the way the TOA field is written. Specifically, as shown in Figure 5, after the load balancer receives a packet from the client, it first checks whether the packet contains a TOA field. If the packet does not contain a TOA field, a real TOA field is inserted. If the packet does contain a TOA field, the real TOA field overwrites the original TOA field in the packet. While this method can prevent malicious TOA (Transmission of Address) messages from being passed to the server, attackers can launch attacks using another method: the variable portion of the attacker's message does not carry any TOA field, but is filled with various common option fields, making the current length of the variable portion exceed 32 bytes. This prevents the load balancer from inserting or overwriting the TOA field. Ultimately, the load balancer can only forward messages without any TOA field to the server. As a result, the server cannot extract the client source address from the TOA field and can only use the address established by the TCP connection as the client source address. In the end, the load balancer's source address is used as the client source address, achieving the attacker's goal of forging the source address and ultimately preventing the server from obtaining the attacker's real source address.

[0049] To mitigate the risk of malicious TOA fields spoofing source addresses, in the second scenario mentioned above, where the attacker sends a malicious TOA field to the server, the server sets up a whitelist of load balancer addresses, only parsing TOA fields from packets sent by load balancers on the whitelist. While this method can mitigate interference from malicious TOA fields to some extent, it requires maintaining the address whitelist. If the load balancer's address changes, the whitelist needs to be updated synchronously. If updates are not timely, packets sent by that load balancer may not correctly extract the TOA field, thus failing to obtain the true client source address and impacting the effectiveness of the server's anti-crawler and anti-scraping security systems.

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

[0051] Before introducing the specific implementation methods of this disclosure, the application scenario of this disclosure will first be described. In current software service models, multiple servers are typically deployed to provide services to the outside world in order to provide large-scale access capabilities. In current service systems, clients send packets to load balancers. The source address in the packet is the client's IP address, and the destination address is the virtual IP (VIP) address of the load balancer. The load balancer selects one of the multiple servers as the target server according to its configured load balancing strategy, and performs source network address translation (SNAT) on the received packet. Specifically, the load balancer modifies the source address in the packet received from the client to its own IP address and sends the modified packet to the target server. After accessing the shared database, the target server generates a response packet for the modified packet and sends the response packet to the load balancer based on the source address of the load balancer. The load balancer then converts the destination address in the response packet to the client's source address and forwards it to the corresponding client.

[0052] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

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

[0054] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based 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". Definitions of other terms will be given in the description below.

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

[0056] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

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

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

[0059] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0060] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

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

[0062] Meanwhile, it is understood 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 related provisions.

[0063] Figure 6 is a flowchart illustrating an information transmission method applied to a load balancing device according to an exemplary embodiment. As shown in Figure 6, the method may include the following steps S101 to S103.

[0064] In S101, in response to receiving the first message sent by the 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. The 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 this disclosure, after receiving the first message sent by the client, the source address of the first message can be translated, that is, the source address in the first message can be modified to the address of the load balancer itself (i.e., the IP address of the load balancer).

[0066] As shown in Figure 7 (taking IPv4 as an example), the variable part of the message sent by the load balancer to the server includes not only the TOA field, but also a label field. 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 trustworthy based on the label field, that is, determine whether the source address in the TOA field of the message is forged.

[0067] As shown in Figure 7, the label field can be divided into three parts: the opcode field, the opsize field, and the data field. The opcode field is 1 byte long and is used to identify the option category, generally distinguishing it from common options. The value of the opcode field identifies the label field category, usually a preset identifier. The opsize field is 1 byte long and represents the length of the entire label field. The data field is 2 bytes long and contains the label data, i.e., the value of the label field.

[0068] After receiving the first packet, the load balancing device can select one of multiple servers as the target server according to its configured load balancing strategy. Then, it can generate a first label corresponding to the destination address in the first packet using a pre-agreed generation method with the target server; simultaneously, it generates a TOA based on the source address in the first packet.

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

[0070] In this disclosure, the second message includes a TOA field, meaning the second message contains only one TOA field. When the first message obtained after address replacement does not contain a TOA field, the first TOA field and the first tag field can be inserted into the first message obtained after address replacement in an insert manner. When the first message obtained after address replacement contains a TOA field, the first TOA field can be written into the first message obtained after address replacement in an overwrite manner, that is, the first TOA field is used to overwrite the original TOA field in the first message obtained after address replacement, and the first tag field is inserted into the first message obtained after address replacement. The first TOA field includes a TOA generated based on the source address in the first message, and the first tag field includes a first tag and a preset identifier for identifying the tag field category. The first tag is the value of the first tag field, specifically the value of the DATA field of the first tag 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 can determine whether the TOA field in the second message is trustworthy based on the first tag and the generation method agreed upon with the load balancing device in advance.

[0072] In this disclosure, after receiving the second message sent by the load balancer, the target server can generate a label corresponding to the destination address in the second message using a pre-agreed generation method with the load balancer. Based on the matching result of the label and the first label, it determines whether the TOA field in the second message is trustworthy. If the TOA field in the second message is trustworthy, it parses the TOA field in the second message to obtain the client source address. If the TOA field in the second message is untrustworthy, it ignores the TOA field, that is, it does not parse the TOA field in the second message.

[0073] In the above technical solution, the packets forwarded by the load balancer to the server contain not only a TOA field but also a label. This label is generated by the load balancer using a pre-agreed method with the server; only the load balancer and the server know the label generation method. Since the attacker is unaware of the label generation method, it cannot forge the correct label. Therefore, upon receiving the packet, the server can generate the desired label using the same method as the load balancer. Based on the match between the desired label and the label field in the received packet, the server determines whether the TOA field in the received packet is trustworthy, i.e., whether the source address in the TOA field is forged. This solves the problem of attackers obtaining a forged source address by forging the TOA field and label, preventing the server's security system from being bypassed due to the client's source address security policy, thus ensuring the effectiveness of the server's security system. In addition, the attacker cannot collect the tags in the packets received by the server from the load balancer. Instead, it can only capture the tags in the packets that the attacker configures the test cloud server. Since the tags are associated with the destination address in the packets, the tags captured by the attacker do not match the tags in the packets received by the server. Thus, the attacker cannot carry out the attack by replaying the packets.

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

[0075] Step (a1): Use the hash mapping method agreed upon with the target server in advance to perform hash mapping on the destination address in the first message to obtain the first hash value.

[0076] In this disclosure, hash mapping methods such as Cyclic Redundancy Check 32 (CRC32) and MD5 Message-Digest Algorithm can be used to hash the destination address in the first message to obtain the first hash value.

[0077] Step (a2): Generate the first label 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), if the length of the first hash value is greater than two bytes, the first two bytes of the first hash value can be truncated and used as the value of the DATA field of the first tag field. If 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. Thus, the first tag can be generated.

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

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

[0081] Step (b2): Use the hash mapping method agreed upon with the target server in advance to perform hash mapping on the first ciphertext to obtain the second hash value.

[0082] Step (b3): ​​Generate the first label 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), if the length of the second hash value is greater than two bytes, the first two bytes of the second hash value can be extracted as the value of the DATA field of the first tag field. If 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. Thus, the first tag can be generated.

[0084] In the above implementation, before hashing the destination address in the first message, the destination address is first encrypted using a pre-agreed salt value with the target server. Then, the encrypted first ciphertext is hashed. This way, even if the attacker guesses the hash mapping method agreed upon by the load balancer and the target server, it is difficult to obtain the agreed salt value, and therefore impossible to forge the correct label. This allows the server to accurately identify whether the source address in the TOA field of the received message is forged based on the label in the received message.

[0085] The following is a detailed description of the specific implementation method for writing the TOA and the first tag generated based on the source address in the first message obtained after address replacement in S102 above, and obtaining the second message.

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

[0087] In this disclosure, as shown in Figure 8, before writing the first TOA field and the first tag field into the first message obtained after address replacement, the load balancing device first determines whether the first message obtained after address replacement contains a TOA field. This determines whether to write the first TOA field by insertion or by overwriting. If the first message obtained after address replacement does not contain a TOA field, the device can attempt to write the first TOA field by insertion, that is, to attempt to insert the first TOA field and the first tag field into the header of the first message obtained after address replacement to obtain a second message. If the first message obtained after address replacement contains a TOA field, the device can attempt to write the first TOA field by overwriting, that is, to attempt to use the first TOA field to overwrite the original TOA field in the header of the first message obtained after address replacement, and to insert the first tag field into the header obtained after field overwriting to obtain a second message.

[0088] As shown in Figure 8, if the load balancer successfully attempts to insert the first TOA field and the first label field, or if it successfully attempts to overwrite the original TOA field in the header of the first packet obtained after replacing the address with the first TOA field and insert the first label field into the header obtained after the field overwriting, then the load balancer uses the real TOA to return to the origin and carries the label field. That is, the load balancer sends the second packet carrying the first TOA field and the first label field to the target server.

[0089] As shown in Figure 8, if the load balancer fails to write due to option length limitations (i.e., attempts to insert the first TOA field and the first tag field fail), it deletes unnecessary option fields from the first packet obtained after address replacement to free up option space before inserting the first TOA field and the first tag field. Alternatively, if the load balancer attempts to overwrite the original TOA field in the header of the first packet obtained after address replacement with the first TOA field and fails to insert the first tag field into the overwritten header, it deletes unnecessary option fields from the first packet obtained after address replacement to free up option space before overwriting the original TOA field in the header of the first packet obtained after address replacement with the first TOA field and inserting the first tag field. Afterward, the load balancer uses the actual TOA for origin callback, carrying the tag field.

[0090] In this context, optional fields refer to fields that do not affect TCP protocol transmission and control. Among these, the Maximum Segment Size (MSS) field (4 bytes), the SACK-Permitted field (2 bytes), and the Window Scale field (3 bytes) affect TCP transmission and are considered mandatory option fields. These must be transmitted to the server by the load balancer. All other option fields in the variable portion of the header of the first packet obtained after address substitution are considered optional fields.

[0091] The following is a detailed description of the specific implementation method for inserting the first TOA field and the first tag field into the header of the first message obtained after address replacement to obtain the second message.

[0092] Specifically, when the first packet is an IPv4 packet, the first TOA field and the first label field can be inserted into the variable portion of the header of the first packet obtained after address replacement. Since the TCP protocol stack stipulates that the length of the variable portion of an IPv4 packet cannot exceed 40 bytes, before inserting the first TOA field and the first label field into the variable portion of the header of the first packet obtained after address replacement, it is necessary to determine whether the remaining length of the variable portion can meet the insertion condition, that is, whether the remaining length of the variable portion is greater than or equal to the total length of the first TOA field and the first label field. The remaining length is the difference between the maximum limit length of the variable portion (i.e., 40 bytes) and the current length of the variable portion. If the remaining length of the variable portion of the header of the first message obtained after address replacement is greater than or equal to the total length of the first TOA field and the first tag field, the insertion condition is met. In this case, the first TOA field and the first tag field can be directly inserted into the variable portion of the header of the first message obtained after address replacement. However, if the remaining length of the variable portion of the header of the first message obtained after address replacement is less than the total length of the first TOA field and the first tag field, at least some of the non-essential option fields in the variable portion of the header of the first message obtained after address replacement can be deleted so that the remaining length of the variable portion obtained after deleting the fields is greater than or equal to the total length of the first TOA field and the first tag field, thus freeing up space in the variable portion. Then, the first TOA field and the first tag field are inserted into the variable portion obtained after deleting the fields to obtain the second message.

[0093] In this disclosure, all unnecessary option fields in the variable part can be deleted, or some unnecessary 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 address substitution to obtain the second message. Since the extension header of IPv6 messages 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 address substitution to obtain the second message.

[0095] The following is a detailed description of the specific implementation method for inserting the first tag field into the header obtained after the above-mentioned field overwriting.

[0096] When the first packet is an IPv4 packet, the first label field can be inserted into the variable portion of the header obtained after address substitution and field overwriting. Since the TCP protocol stack specifies that the length of the variable portion of an IPv4 packet cannot exceed 40 bytes, before inserting the first label field into the variable portion of the header obtained after field overwriting, it is necessary to determine whether the remaining length of the variable portion satisfies the insertion condition, i.e., whether the remaining length of the variable portion of the header obtained after field overwriting is greater than or equal to the length of the first label field. If the remaining length of the variable portion obtained after 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 portion obtained after field overwriting. However, if the remaining length of the variable portion obtained after address substitution and field overwriting is less than the length of the first label field, at least some non-essential option fields in the variable portion obtained after field overwriting can be deleted to ensure that the remaining length of the variable portion after deleting fields is greater than or equal to the length of the first label field, thus freeing up space in the variable portion. Then, the first label field is inserted into the variable portion obtained after deleting fields to obtain the second packet.

[0097] In this disclosure, all unnecessary option fields in the variable part obtained after field overwriting can be deleted, or some unnecessary 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 label field.

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

[0099] Figure 9 is a flowchart illustrating an information transmission method applied to a server according to an exemplary embodiment. As shown in Figure 9, the method may include the following steps S201 to S203.

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

[0101] In this disclosure, the server can be accessed by both load balancers and clients. Therefore, the target packets it receives may be sent by either the client or the load balancer. The packets sent by the load balancer contain both a TOA field and a tag field. The tag field value in the packets sent by the load balancer is a tag generated by the load balancer using a generation method, corresponding to the destination address in the packet. An attacker can forge both the TOA field and the tag, hoping to bypass the server's security policies.

[0102] In S202, based on the matching result between the second tag and the second tag field in the target message, it is determined whether the second TOA field in the target message is trustworthy.

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

[0104] If the value of the second tag matches the value of the second tag field in the target message, the second TOA field is determined to be trustworthy, meaning the source address in the second TOA field is not spoofed but a genuine client source address. In this case, the second TOA field can be parsed to obtain the client source address. If the value of the second tag does not match the value of the second tag field in the target message, the second TOA field is determined to be untrustworthy, meaning the source address in the second TOA field is spoofed and not a genuine client source address. In this case, the second TOA field can be ignored, i.e., it is not parsed.

[0105] In the above technical solution, the packets forwarded by the load balancer to the server contain not only a TOA field but also a label. This label is generated by the load balancer using a pre-agreed method with the server; only the load balancer and the server know the label generation method. Since the attacker is unaware of the label generation method, it cannot forge the correct label. Therefore, upon receiving the packet, the server can generate the desired label using the same method as the load balancer. Based on the match between the desired label and the label field in the received packet, the server determines whether the TOA field in the received packet is trustworthy, i.e., whether the source address in the TOA field is forged. This solves the problem of attackers obtaining a forged source address by forging the TOA field and label, preventing the server's security system from being bypassed due to the client's source address security policy, thus ensuring the effectiveness of the server's security system. In addition, the attacker cannot collect the tags in the packets received by the server from the load balancer. Instead, it can only capture the tags in the packets that the attacker configures the test cloud server. Since the tags are associated with the destination address in the packets, the tags captured by the attacker do not match the tags in the packets received by the server. Thus, the attacker cannot carry out the attack by replaying the packets.

[0106] The following is a detailed description of the specific implementation method for generating a second tag corresponding to the destination address in the target message using a pre-agreed generation method with the load balancing device in S201.

[0107] In one implementation, a hash mapping method pre-agreed with the load balancing device can be used to hash the destination address in the target packet to obtain a third hash value; then, a second tag is generated based on the third hash value.

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

[0109] In this disclosure, the server can use a method similar to the one agreed upon with the target server in the above-mentioned generation method to generate a first label corresponding to the destination address in the first message, and use a generation method agreed upon with the load balancing device in the above-mentioned generation method to generate a second label corresponding to the destination address in the target message. This will not be described in detail in this disclosure.

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

[0111] If the target message contains a TOA field but not a label field, then the second TOA field is determined to be untrusted.

[0112] To bypass the server's security policies, attackers can forge both the TOA field and the tag, or they may only forge the TOA field. The packets sent by the load balancer contain both the TOA field and the tag field, while the packets sent directly from the normal client to the server do not contain the TOA field. Thus, when the target packet contains the TOA field but not the tag field, it indicates that the target packet was sent by the attacker. In this case, it can be determined that the second TOA field is untrusted.

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

[0114] If the target message does not contain a TOA field, the source address of the TCP connection used to transmit the target message will be determined as the client's source address.

[0115] In this disclosure, when the target message does not contain a TOA field, it is determined that the target message was sent by the client. In this case, 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 one possible implementation, the above method may further include the following two steps:

[0117] If the target message contains a TOA field but not a label field, then the second TOA field is determined to be untrusted.

[0118] If the target message does not contain a TOA field, the source address of the TCP connection used to transmit the target message will be determined as the client's source address.

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

[0120] If the header of the target message contains a preset identifier used to identify the category of the tag field, then it is determined that the target message contains a tag field;

[0121] The field containing the preset identifier is designated as the second label field.

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

[0123] Figure 10 is a block diagram illustrating an anti-IP spoofing information transmission device applied to a load balancing device according to an exemplary embodiment. As shown in Figure 10, the anti-IP spoofing information transmission device 300 applied to a load balancing device includes:

[0124] The first generation module 301 is used to respond to receiving a first message sent by the client, replace the source address in the first message with the 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 tag corresponding to the destination address in the first message using a generation method pre-agreed with the target server.

[0125] The writing module 302 is used to write the TOA and the first tag into the first message obtained after address replacement to obtain the second message;

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

[0127] In the above technical solution, the packets forwarded by the load balancer to the server contain not only a TOA field but also a label. This label is generated by the load balancer using a pre-agreed method with the server; only the load balancer and the server know the label generation method. Since the attacker is unaware of the label generation method, it cannot forge the correct label. Therefore, upon receiving the packet, the server can generate the desired label using the same method as the load balancer. Based on the match between the desired label and the label field in the received packet, the server determines whether the TOA field in the received packet is trustworthy, i.e., whether the source address in the TOA field is forged. This solves the problem of attackers obtaining a forged source address by forging the TOA field and label, preventing the server's security system from being bypassed due to the client's source address security policy, thus ensuring the effectiveness of the server's security system. In addition, the attacker cannot collect the tags in the packets received by the server from the load balancer. Instead, it can only capture the tags in the packets that the attacker configures the test cloud server. Since the tags are associated with the destination address in the packets, the tags captured by the attacker do not match the tags in the packets received by the server. Thus, the attacker cannot carry out the attack by replaying the packets.

[0128] Optionally, the writing module 302 includes:

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

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

[0131] The first insertion submodule includes:

[0132] The first deletion submodule is configured to delete at least some of the unnecessary option fields in the variable portion if the remaining length of the variable portion of the header is less than the total length of the first TOA field and the first tag field, so that the remaining length of the variable portion after deleting the fields is greater than or equal to the total length, wherein the remaining length is the difference between the maximum limit length of the variable portion and the current length of the variable portion.

[0133] The second insertion submodule is used to insert the first TOA field and the first tag field into the variable part obtained after the deletion field to obtain the second message.

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

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

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

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

[0138] Optionally, the coverage submodule includes:

[0139] The second deletion submodule is configured to delete at least some of the non-essential option fields in the variable portion obtained after field overwriting if the first packet is an IPv4 packet and the remaining length of the header obtained after field overwriting is less than the length of the first label field, so that the remaining length of the variable portion obtained after field overwriting 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 portion and the current length of the variable portion; the third insertion submodule is configured to insert the first label field into the variable portion obtained after field overwriting.

[0140] The fourth insertion submodule is used to insert the first tag field into the extended header of the header obtained after the field is overwritten if the first message is an IPv6 message.

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

[0142] The first mapping submodule is used 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 generation submodule is used to generate the first tag based on the first hash value.

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

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

[0146] The second mapping submodule is used 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 generation submodule is used to generate the first tag based on the second hash value.

[0148] Figure 11 is a block diagram illustrating an anti-IP spoofing information transmission device applied to a server according to an exemplary embodiment. As shown in Figure 11, the anti-IP spoofing information transmission device 400 applied to a server includes:

[0149] The second generation module 401 is used to respond 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, the module generates a second label corresponding to the destination address in the target message using a generation method pre-agreed with the load balancing device. The message sent by the load balancing device contains both a TOA field and a label field. 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] The first determining module 402 is used to determine whether the second TOA field in the target message is trustworthy based on the matching result between the second tag and the second tag field in the target message;

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

[0152] In the above technical solution, the packets forwarded by the load balancer to the server contain not only a TOA field but also a label. This label is generated by the load balancer using a pre-agreed method with the server; only the load balancer and the server know the label generation method. Since the attacker is unaware of the label generation method, it cannot forge the correct label. Therefore, upon receiving the packet, the server can generate the desired label using the same method as the load balancer. Based on the match between the desired label and the label field in the received packet, the server determines whether the TOA field in the received packet is trustworthy, i.e., whether the source address in the TOA field is forged. This solves the problem of attackers obtaining a forged source address by forging the TOA field and label, preventing the server's security system from being bypassed due to the client's source address security policy, thus ensuring the effectiveness of the server's security system. In addition, the attacker cannot collect the tags in the packets received by the server from the load balancer. Instead, it can only capture the tags in the packets that the attacker configures the test cloud server. Since the tags are associated with the destination address in the packets, the tags captured by the attacker do not match the tags in the packets received by the server. Thus, the attacker cannot carry out the attack by replaying the packets.

[0153] Optionally, the first determining module 402 is used to determine that the second TOA field is trustworthy if the second label is consistent with the value of the second label field.

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

[0155] The third mapping submodule is used to perform hash mapping on the destination address in the target packet using a hash mapping method pre-agreed with the load balancing device to obtain a third hash value;

[0156] The third generation submodule is used to generate the second tag based on the third hash value.

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

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

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

[0160] The fourth generation submodule is used to generate the second tag based on the fourth hash value.

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

[0162] The second determining module is configured to determine that the second TOA field is untrustworthy if the target message contains a TOA field but does not contain a tag field; and / or

[0163] The third determining 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 contain a TOA field.

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

[0165] The fourth determining module is used to determine that the target message contains a tag field if the header of the target message contains a preset identifier for identifying the tag field category.

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

[0167] In addition, this disclosure also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the above-described method for preventing IP spoofing in load balancing devices or the above-described method for preventing IP spoofing in servers.

[0168] In addition, this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method for preventing IP spoofing in load balancing devices or the steps of the above-described method for preventing IP spoofing in servers.

[0169] Referring now to FIG12, a schematic diagram of the structure of an electronic device (client or server) 600 suitable for implementing embodiments of the present disclosure is shown. The terminal device in embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. The electronic device shown in FIG12 is merely an example and should not impose any limitation on the functionality and scope of use of embodiments of the present disclosure.

[0170] As shown in Figure 12, the electronic device 600 may include a processing unit (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. The RAM 603 also stores various programs and data required for the operation of the electronic device 600. The processing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0171] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although FIG12 shows electronic device 600 with various devices, 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 alternatively.

[0172] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via 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, it performs the functions defined in the methods of embodiments of this disclosure.

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

[0174] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol), and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0175] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0176] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes one or more of these programs, the electronic device causes the following actions: In response to receiving a first message sent by a client, the electronic device replaces the source address in the first message with the address of the load balancing device itself, generates a TCP Option Address (TOA) based on the source address in the first message, and generates a first tag corresponding to the destination address in the first message using a generation method pre-agreed with the target server; writes the TOA and the first tag into the first message obtained after address replacement to obtain a second message; and sends the second message to the target server so that the target server can determine whether the TOA field in the second message is trustworthy based on the first tag and the generation method.

[0177] Alternatively, the aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: upon receiving a target message sent by a client or load balancer, if the target message simultaneously contains a TCP Option Address (TOA) field and a label field, generate a second label corresponding to the destination address in the target message using a pre-agreed generation method with the load balancer, wherein the message sent by the load balancer simultaneously contains a TOA field and a label field, and the value of the label field in the message sent by the load balancer is a label generated by the load balancer using the generation method and corresponding to the destination address in the message; determine whether the second TOA field in the target message is trustworthy based on the matching result of the second label and the second label field in the target message; if the second TOA field is trustworthy, parse the second TOA field to obtain the client source address.

[0178] Computer program code for performing the operations of this disclosure can 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, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone 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 remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0179] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0180] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The name of a module does not necessarily limit the module itself; for example, the parsing module could also be a module that parses the second TOA field to obtain the client source address if the second TOA field is trustworthy.

[0181] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

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

[0183] According to one or more embodiments of this disclosure, Example 1 provides an information transmission method for preventing IP spoofing, applied to a load balancing device, comprising:

[0184] In response to receiving the first message sent by the 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. A first tag corresponding to the destination address in the first message is generated using a generation method pre-agreed with the target server.

[0185] Write the TOA and the first tag into the first message obtained after address replacement to obtain the second message;

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

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

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

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

[0190] The insertion of a first TOA field and a first tag field into the header of the first message obtained after address replacement yields a second message, including:

[0191] If the remaining length of the variable portion of the header is less than the total length of the first TOA field and the first label field, then at least some of the unnecessary option fields in the variable portion are deleted, so that the remaining length of the variable portion after deleting the fields is greater than or equal to the total length, wherein the remaining length is the difference between the maximum limit length of the variable portion and the current length of the variable portion;

[0192] The first TOA field and the first tag field are inserted into the variable portion obtained after deleting the fields to obtain the second message.

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

[0194] The insertion of a first TOA field and a first tag field into the header of the first message obtained after address replacement yields a second message, including:

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

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

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

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

[0199] If the first packet is an IPv4 packet and the remaining length of the header obtained after field overwriting is less than the length of the first label field, then at least some of the non-essential option fields in the variable portion obtained after field overwriting are deleted, so that the remaining length of the variable portion obtained after deleting the fields 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 portion and the current length of the variable portion; the first label field is then inserted into the variable portion obtained after deleting the fields.

[0200] If the first message is an IPv6 message, then the first tag field is inserted into the extended header of the header obtained after the field is overwritten.

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

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

[0203] The first tag is generated based on the first hash value.

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

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

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

[0207] The first tag is generated based on the second hash value.

[0208] According to one or more embodiments of this disclosure, Example 9 provides an information transmission method for preventing IP spoofing, applied to a server, including:

[0209] In response to receiving a target packet sent by a client or load balancer, if the target packet contains both a TCP Option Address (TOA) field and a label field, a second label corresponding to the destination address in the target packet is generated using a pre-agreed generation method with the load balancer. The packet sent by the load balancer contains both a TOA field and a label field, and the value of the label field in the packet is a label generated by the load balancer using the aforementioned generation method, corresponding to the destination address in the packet.

[0210] Based on the matching result between the second tag and the second tag field in the target message, determine whether the second TOA field in the target message is trustworthy;

[0211] If the second TOA field is reliable, then parse the second TOA field to obtain the client source address.

[0212] According to one or more embodiments of this disclosure, Example 10 provides the method of Example 9, wherein determining whether the second TOA field in the target message is trustworthy based on the matching result of the second tag and the value of the second tag field in the target message includes:

[0213] If the value of the second label matches the value of the second label field, then the second TOA field is determined to be trustworthy.

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

[0215] The destination address in the target packet is hashed using a hash mapping method pre-agreed with the load balancing device to obtain a third hash value;

[0216] The second tag is generated based on the third hash value.

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

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

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

[0220] The second tag is generated based on the fourth hash value.

[0221] According to one or more embodiments of this disclosure, Example 13 provides a method as described in any one of Examples 9-12, the method further comprising:

[0222] If the target message contains a TOA field but not a label field, then the second TOA field is determined to be untrustworthy; and / or

[0223] If the target message does not contain a TOA field, then 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 this disclosure, Example 14 provides a method as described in any one of Examples 9-12, the method further comprising:

[0225] If the header of the target message is detected to contain a preset identifier for identifying the category of the tag field, then it is determined that the target message contains a tag field;

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

[0227] According to one or more embodiments of this disclosure, Example 15 provides an anti-IP spoofing information transmission device applied to a load balancing device, comprising:

[0228] The first generation module is used to respond to receiving a first message sent by the client, replace the source address in the first message with the 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 tag corresponding to the destination address in the first message using a generation method pre-agreed with the target server.

[0229] The writing module is used to write the TOA and the first tag into the first message obtained after address replacement, so as to obtain the second message;

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

[0231] According to one or more embodiments of this disclosure, Example 16 provides an information transmission device for preventing IP spoofing, applied to a server, comprising:

[0232] The second generation module is used to respond to receiving a target packet sent by a client or load balancing device. If the target packet contains both a TCP Option Address (TOA) field and a label field, it generates a second label corresponding to the destination address in the target packet using a generation method pre-agreed with the load balancing device. The packet sent by the load balancing device contains both a TOA field and a label field. The value of the label field in the packet 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 packet.

[0233] The first determining module is used to determine whether the second TOA field in the target message is trustworthy based on the matching result between the second tag and the second tag field in the target message;

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

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

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

[0237] A storage device on which computer programs are stored;

[0238] A processing device for executing the computer program in the storage device to implement the steps of the information transmission method for preventing IP spoofing as described in any 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 that, when executed by a processor, implements the steps of the anti-IP spoofing information transmission method described in any one of Examples 1-14.

[0240] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0241] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0242] Although the subject matter has been described using language specific to structural features and / or methodological logic, 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. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims. Regarding the apparatus in the above embodiments, the specific manner in which the various modules perform their operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.

Claims

1. An IP anti-forgery information transmission method applied to a load balancing device, the method comprising: replacing a source address in a first packet with an address of the load balancing device itself in response to receiving the first packet sent by a client, generating a TCP option address (TOA) based on the source address, and generating a first label corresponding to a destination address in the first packet by using a generation manner agreed with a target server in advance; writing the TOA and the first label to the first packet after address replacement to obtain a second packet; sending the second packet to the target server to determine whether a TOA field in the second packet is trustworthy based on the first label and the generation manner.

2. The method of claim 1, wherein, The writing of the TOA and the first label to the first packet after address replacement to obtain a second packet comprises: if the first packet after address replacement does not contain a TOA field, inserting a first TOA field and a first label field into a header of the first packet after address replacement to obtain a second packet, wherein the first TOA field comprises the TOA, and the first label field comprises the first label and a preset identifier for identifying a label field category.

3. The method of claim 2, wherein, The first packet is an IPv4 packet. The inserting of the first TOA field and the first label field into the header of the first packet after address replacement to obtain a second packet comprises: if a remaining length of a variable part of the header is less than a total length of the first TOA field and the first label field, deleting at least part of unnecessary option fields in the variable part to make a remaining length of the variable part after deletion 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; inserting the first TOA field and the first label field into the variable part after deletion to obtain a second packet.

4. The method of claim 2, wherein, The first packet is an IPv6 packet. The inserting of the first TOA field and the first label field into the header of the first packet after address replacement to obtain a second packet comprises: inserting the first TOA field and the first label field into an extension header of the header of the first packet after address replacement to obtain a second packet.

5. The method of claim 2, wherein, The writing of the first TOA field and the first label field to the first packet after address replacement to obtain a second packet further comprises: if the first packet after address replacement contains a TOA field, covering the TOA field in the header with the first TOA field, and inserting the first label field into the header after field covering to obtain the second packet.

6. The method of claim 5, wherein, The inserting of the first label field into the header after field covering comprises: If the first packet is an IPv4 packet, and a remaining length of the header obtained after the field covering is less than a length of the first label field, at least part of unnecessary option fields in a variable part obtained after the field covering is deleted, so that a remaining length of the variable part obtained after the deleting is greater than or equal to the length of the first label field, wherein the remaining length is a difference between a maximum limit length of the variable part and a current length of the variable part; and the first label field is inserted into the variable part obtained after the deleting; If the first packet is an IPv6 packet, the first label field is inserted into an extension header of the header obtained after the field covering.

7. The method of any one of claims 1-6, wherein, The first label corresponding to the destination address in the first packet is generated by using a generation manner agreed with the target server in advance, and the generation manner comprises: The destination address in the first packet is hashed by using a hash mapping manner agreed with the target server in advance, to obtain a first hash value; The first label is generated based on the first hash value.

8. The method of any one of claims 1-6, wherein, The first label corresponding to the destination address in the first packet is generated by using a generation manner agreed with the target server in advance, and the generation manner comprises: The destination address in the first packet is encrypted by using a salt value agreed with the target server in advance, to obtain first ciphertext; The first ciphertext is hashed by using a hash mapping manner agreed with the target server in advance, to obtain a second hash value; The first label is generated based on the second hash value.

9. An information transmission method for preventing IP forgery, applied to a server, and the method comprises: In response to receiving a target packet sent by a client or a load balancing device, if the target packet contains a TCP option address (TOA) field and a label field at the same time, a second label corresponding to a destination address in the target packet is generated by using a generation manner agreed with the load balancing device in advance, wherein the load balancing device sends a packet containing a TOA field and a label field at the same time, and a value of the label field in the packet sent by the load balancing device is a label corresponding to the destination address in the packet, which is generated by the load balancing device by using the generation manner; Whether a second TOA field in the target packet is credible is determined according to a matching result of the second label and a value of a second label field in the target packet; If the second TOA field is credible, the second TOA field is parsed to obtain a client source address.

10. The method of claim 9, wherein, Whether the second TOA field is credible is determined according to the matching result of the second label and the value of the second label field in the target packet, and the method comprises: If the second label is consistent with the value of the second label field, it is determined that the second TOA field is credible.

11. The method of claim 9 or 10, wherein, The second label corresponding to the destination address in the target packet is generated by using a generation manner agreed with the load balancing device in advance, and the generation manner comprises: The destination address in the target packet is hashed by using a hash mapping manner agreed with the load balancing device in advance, to obtain a third hash value; generate the second label based on the third hash value.

12. The method of claim 9 or 10, wherein, The generating the second label corresponding to the destination address in the target packet by using the generating method agreed in advance with the load balancing device comprises: encrypting the destination address in the target packet by using a salt value agreed in advance with the load balancing device to obtain second ciphertext; hash mapping the second ciphertext by using a hash mapping method agreed in advance with the load balancing device to obtain a fourth hash value; generating the second label based on the fourth hash value.

13. The method according to any one of claims 9-12, further comprising: if the target packet contains a TOA field and does not contain a label field, determining that the second TOA field is not trusted; and / or if the target packet does not contain a TOA field, determining the source address of the TCP connection used to transmit the target packet as the client source address.

14. The method according to any one of claims 9-13, further comprising: if it is detected that the header of the target packet contains a preset identifier used to identify the category of the label field, determining that the target packet contains a label field; determining the field in which the preset identifier is located as the second label field.

15. An information transmission device for preventing IP forgery, applied to a load balancing device, the information transmission device comprising: a first generating module configured to, in response to receiving a first packet sent by a client, replace the source address in the first packet with the address of the load balancing device itself, generate a TCP option address (TOA) based on the source address in the first packet, and generate a first label corresponding to the destination address in the first packet by using a generating method agreed in advance with a target server; a writing module configured to write the TOA and the first label to the first packet obtained after the address replacement to obtain a second packet; a sending module configured to send the second packet to the target server, so that the target server determines whether the TOA field in the second packet is trusted based on the first label and the generating method.

16. An information transmission device for preventing IP forgery, applied to a server, the information transmission device comprising: a second generating module configured to, in response to receiving a target packet sent by a client or a load balancing device, if the target packet contains a TCP option address (TOA) field and a label field at the same time, generate a second label corresponding to the destination address in the target packet by using a generating method agreed in advance with the load balancing device, wherein the packet sent by the load balancing device contains a TOA field and a label field at the same time, and the value of the label field in the packet sent by the load balancing device is a label corresponding to the destination address in the packet, which is generated by the load balancing device by using the generating method; a first determining module configured to determine whether the second TOA field in the target packet is trusted according to the matching result of the second label and the second label field in the target packet. A parsing module configured to parse the second TOA field to obtain a client source address if the second TOA field is trusted.

17. A computer readable medium storing a computer program, wherein, The computer program is executed by the processing device to implement the anti-IP spoofing information transmission method in any one of claims 1-14. 18.An electronic device comprising: a storage device storing a computer program; a processing device configured to execute the computer program in the storage device to implement the anti-IP spoofing information transmission method in any one of claims 1-14.

19. A computer program product comprising a computer program, wherein, The computer program is executed by the processing device to implement the anti-IP spoofing information transmission method in any one of claims 1-14.

Images