Honeypot cluster trusted network communication method and related device

Abstract

The invention discloses a honeypot cluster trusted network communication method and a related device, and relates to the technical field of information security, and the method comprises the steps: marking a first network data packet accessing a honeypot network to identify whether the first network data packet is trusted; filling the marking result of the first network data packet into a mark field of a skbuff data structure of a Linux kernel network stack; and when the first network data packet enters the stack, making a decision on the first network data packet based on the filling content of the mark field so as to forward the trusted network data packet in the first network data packet to the honeypot network. According to the method and the device, the network data packet can be marked according to whether the network data packet is trusted by the honeypot network, so that the network data packet is decided when the network data packet enters the stack, trusted or untrusted decision processing can be performed on the network data packet while safe and controllable communication of the honeypot cluster is realized, and the security of the honeypot cluster is improved. And the honey pot capture behavior failure caused by data packet counterfeiting is prevented.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a honeypot cluster trusted network communication method and related devices. Background Art

[0002] A honeypot is a computing system running on the Internet that simulates a vulnerable host to provide an easy target for attackers, but does not provide truly valuable services to the outside world. After an attacker invades the honeypot network, the latest attacks and vulnerabilities can be learned to block the attacker.

[0003] At present, the honeypot cluster only controls network traffic through network rules (such as ACL, routing table, iptables), but cannot verify the authenticity of the network data packets themselves. This allows attackers to bypass existing network rules by forging data packets and access the honeypot network, making the honeypot's pre-made capture behavior invalid. Summary of the invention

[0004] In view of the above problems, the present application provides a honeypot cluster trusted network communication method and related devices to achieve the purpose of making trust or non-trust decision processing on network data packets while ensuring safe and controllable communication of the honeypot cluster. The specific scheme is as follows:

[0005] A first aspect of the present application provides a honeypot cluster trusted network communication method, the honeypot cluster trusted network communication method comprising:

[0006] Marking a first network data packet accessing the honeypot network to identify whether the first network data packet is trusted;

[0007] Fill the marking result of the first network data packet into the mark field of the sk_buff data structure of the Linux kernel network stack;

[0008] When the first network data packet is pushed into the stack, a decision is made on the first network data packet based on the filling content of the mark field, so as to forward the trusted network data packet in the first network data packet to the honeypot network.

[0009] In a possible implementation, marking the first network data packet accessing the honeypot network includes:

[0010] Determining whether the first network data packet accesses the honeypot network via a honeypot gateway;

[0011] If not, generating a non-trusted tag for the first network data packet;

[0012] If yes, obtain triplet information of the first network data packet, the triplet information including source IP address, source port and protocol;

[0013] Converting the source IP address of the first network data packet to an internal IP address in the honeypot network;

[0014] A trusted tag for the first network data packet is generated using the internal IP address, the source port and the protocol of the first network data packet.

[0015] In a possible implementation, the making a decision on the first network data packet based on the filling content of the mark field includes:

[0016] Receiving trusted network data packets in the first network data packets and discarding untrusted network data packets;

[0017] Clear the padding content in the mark field of the first network data packet that is received or discarded.

[0018] In a possible implementation, the honeypot cluster trusted network communication method further includes:

[0019] During the communication between the packet sending end and the packet receiving end in the honeypot network, marking the second network data packet to be sent by the packet sending end to identify whether the second network data packet is trusted;

[0020] The marking result of the second network data packet is filled into the vx_flags field of the sk_buff data structure of VXLAN to achieve: the packet sending end stacks and encapsulates the filling content of the vx_flags field with the second network data packet, and sends the stacked encapsulation result to the packet receiving end; the packet receiving end makes a decision on the second network data packet according to the filling content of the vx_flags field, obtains the second network data packet by decapsulation after clearing the filling content of the vx_flags field, and sends the second network data packet to the Linux kernel network stack.

[0021] In a possible implementation, marking the second network data packet to be sent by the packet sending end includes:

[0022] Determine whether the second network data packet belongs to the network data packet forwarded to the honeypot network;

[0023] If not, generating a non-trusted tag for the second network data packet;

[0024] If yes, obtain triplet information of the second network data packet, the triplet information including source IP address, source port and protocol;

[0025] A trusted tag of the second network data packet is generated using the source IP address, source port and protocol of the second network data packet.

[0026] A second aspect of the present application provides a honeypot cluster trusted network communication device, the honeypot cluster trusted network communication device comprising:

[0027] A forwarding marking module, used for marking a first network data packet accessing a honeypot network to identify whether the first network data packet is trusted;

[0028] A forwarding decision module is used to fill the marking result of the first network data packet into the vx_flags field of the sk_buff data structure of the Linux kernel network stack; when the first network data packet is pushed into the stack, a decision is made on the first network data packet based on the filling content of the vx_flags field to forward the trusted network data packets in the first network data packet to the honeypot network.

[0029] In a possible implementation, the honeypot cluster trusted network communication device further includes:

[0030] A communication marking module, used for marking a second network data packet to be sent by the packet sending end during the communication between the packet sending end and the packet receiving end in the honeypot network, so as to identify whether the second network data packet is trusted;

[0031] A communication decision module is used to fill the marking result of the second network data packet into the vx_flags field of the sk_buff data structure of the VXLAN, so as to achieve: the packet sending end stacks and encapsulates the filling content of the vx_flags field with the second network data packet, and sends the stacked encapsulation result to the packet receiving end; the packet receiving end makes a decision on the second network data packet according to the filling content of the vx_flags field, obtains the second network data packet by decapsulation after clearing the filling content of the vx_flags field, and sends the second network data packet to the Linux kernel network stack.

[0032] A third aspect of the present application provides a computer program product, including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements the honeypot cluster trusted network communication method of the first aspect or any implementation of the first aspect.

[0033] A fourth aspect of the present application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0034] The memory is used to store computer programs;

[0035] The processor is used to execute the computer program so that the electronic device can implement the honeypot cluster trusted network communication method of the first aspect or any implementation manner of the first aspect.

[0036] The fifth aspect of the present application provides a computer storage medium, which carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement the honeypot cluster trusted network communication method of the above-mentioned first aspect or any implementation method of the first aspect.

[0037] By means of the above technical solution, the present application provides a honeypot cluster trusted network communication method and related devices, which mark the first network data packet accessing the honeypot network to identify whether the first network data packet is trusted; fill the marking result of the first network data packet into the mark field of the sk_buff data structure of the Linux kernel network stack; when the first network data packet is stacked, a decision is made on the first network data packet based on the filling content of the mark field, so as to forward the trusted network data packet in the first network data packet to the honeypot network. The present application can mark the network data packet belonging to the honeypot traffic with a trusted mark and the network data packet belonging to the unknown traffic with an untrusted mark according to whether it is trusted by the honeypot network, so as to make a decision on the network data packet when it is stacked, so as to achieve the safe and controllable communication of the honeypot cluster while being able to make a trusted or untrusted decision on the network data packet, and prevent forged data packets from causing the capture behavior of the honeypot to fail. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0039] Figure 1 A schematic diagram of a flow chart of a honeypot cluster trusted network communication method provided in an embodiment of the present application;

[0040] Figure 2 A partial flow chart of a honeypot cluster trusted network communication method provided in an embodiment of the present application;

[0041] Figure 3 Another partial flow chart of a honeypot cluster trusted network communication method provided by an embodiment of the present application;

[0042] Figure 4Another schematic diagram of a flow chart of a honeypot cluster trusted network communication method provided by an embodiment of the present application;

[0043] Figure 5 Another partial flow chart of a honeypot cluster trusted network communication method provided by an embodiment of the present application;

[0044] Figure 6 A schematic diagram of a stacked package provided in an embodiment of the present application;

[0045] Figure 7 A schematic diagram of the structure of a honeypot cluster trusted network communication device provided in an embodiment of the present application;

[0046] Figure 8 Another structural schematic diagram of a honeypot cluster trusted network communication device provided by an embodiment of the present application;

[0047] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] The following describes the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation method section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0049] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0050] The terms "first", "second" etc. in the specification of the application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable in appropriate circumstances, and this is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0051] See also Figure 1 , Figure 1 A flow chart of a trusted network communication method for a honeypot cluster provided in an embodiment of the present application. Figure 1 As shown, a honeypot cluster trusted network communication method provided by an embodiment of the present application may include steps S10 to S30, and these steps are described in detail below.

[0052] S10, marking a first network data packet accessing the honeypot network to identify whether the first network data packet is trusted.

[0053] In the embodiment of the present application, the gateway of the honeypot network can monitor the access of external traffic to the exposed port of the honeypot network. Based on this, the network data packets accessing the honeypot network (i.e., the first network data packets) can be marked, and the network data packets in the first network data packets accessing the exposed port of the honeypot network are regarded as honeypot traffic and marked as trusted, while the network data packets in the first network data packets that are not accessed through the exposed port of the honeypot network are regarded as unknown traffic and marked as untrusted.

[0054] In a possible implementation, the tag can be performed using the triplet information of the network data packet. Figure 2 , Figure 2 A partial flow chart of a honeypot cluster trusted network communication method provided in an embodiment of the present application. Figure 2 As shown, an embodiment of the present application provides a honeypot cluster trusted network communication method, wherein "marking the first network data packet accessing the honeypot network" in step S10 may include steps S101 to S105, and these steps are described in detail below.

[0055] S101, determine whether the first network data packet accesses the honeypot network via the honeypot gateway; if not, execute step S102; if so, execute steps S103 to S105.

[0056] In the embodiment of the present application, for a network data packet in the first network data packet accessed through an exposed port of a honeypot network, it can be determined that it is accessed through the honeypot network.

[0057] S102: Generate an untrusted tag for the first network data packet.

[0058] In an embodiment of the present application, for any network data packet in the first network data packet, if it accesses the honeypot network without going through the honeypot gateway, it is treated as unknown traffic and determined to be untrusted, thereby generating an untrusted tag for the network data packet, which can be a null value.

[0059] S103, obtaining triplet information of the first network data packet, where the triplet information includes a source IP address, a source port, and a protocol.

[0060] In an embodiment of the present application, for any network data packet in the first network data packet, if it accesses the honeypot network through a honeypot gateway, it is treated as honeypot traffic, determined to be trusted, and then the triplet information of the network data packet is obtained, including the source IP address, source port and protocol.

[0061] S104: Convert the source IP address of the first network data packet into an internal IP address in the honeypot network.

[0062] In the embodiment of the present application, for any one of the first network data packets, after obtaining the triplet information of the network data packet, its source IP address can be converted into an internal IP address according to the IP conversion rule of the honeypot network.

[0063] S105, generating a trusted tag of the first network data packet using the internal IP address, the source port and the protocol of the first network data packet.

[0064] In an embodiment of the present application, for any one of the first network data packets, after obtaining its internal IP address in the honeypot network, its trusted mark can be generated using the internal IP address, the source port and the protocol of the network data packet. Specifically, the hash value of the internal IP address, source port and protocol corresponding to the network data packet can be used as a trusted mark through a hash operation.

[0065] S20, filling the marking result of the first network data packet into the mark field of the sk_buff data structure of the Linux kernel network stack.

[0066] In an embodiment of the present application, for any one of the first network data packets, before forwarding it to the honeypot network, the marking result (untrusted mark or trusted mark) of the network data packet can be filled into the mark field of the sk_buff (English full name socket buffer, Chinese name Linux kernel network stack network data packet data structure) structure of the Linux kernel network stack.

[0067] In actual applications, in the Linux Netfilter kernel framework (the full name in Chinese is Linux kernel network packet filtering framework), filling the marking result of the first network data packet into the mark field can be implemented based on the trusted network data packet filtering function registered by the NF_IP_LOCAL_IN hook.

[0068] It should be noted that the sk_buff structure is the core data structure used to describe network data packets in the Linux kernel network stack. The marking result filled into the sk_buff structure will not affect the source data packet. The sk_buff structure is only used for network protocol stack layer processing. After encapsulating the trusted network data packet, it only exists in the local stack stage in the life cycle of the Linux kernel network stack.

[0069] S30, when the first network data packet is stacked, a decision is made on the first network data packet based on the filling content of the mark field, so as to forward the trusted network data packet in the first network data packet to the honeypot network.

[0070] In the embodiment of the present application, for any network data packet in the first network data packet, when the network data packet is stacked, it can be determined whether it is trusted based on the filling content of the mark field, so as to decide whether to receive the network data packet or discard the network data packet. In this way, the trusted network data packet in the first network data packet is forwarded to the honeypot network.

[0071] In a possible implementation, a decision can be made on the first network data packet based on the NF_IP_LOCAL_IN hook registration of the trusted network data packet filtering function in the Linux Netfilter framework. Figure 3 , Figure 3 Another partial flow chart of a honeypot cluster trusted network communication method provided by an embodiment of the present application. Figure 3 As shown, an embodiment of the present application provides a honeypot cluster trusted network communication method, wherein "making a decision on the first network data packet based on the filled content of the mark field" in step S30 may include steps S301 to S302, and these steps are described in detail below.

[0072] S301: Receive trusted network data packets in the first network data packets, and discard untrusted network data packets.

[0073] In the embodiment of the present application, the priority level of the trusted network data packet filter function for making a decision on the first network data packet is the first priority decision level in the Linux Netfilter framework, and the honeypot network request from OVS (Open vSwitch in English, multi-layer virtual switch in Chinese) is processed based on the NF_IP_LOCAL_IN hook in the Netfilter framework. Specifically, the decision mechanism of the trusted network data packet filter function is that the trusted network data packet is received (ie, ACCEPT), and the untrusted network data packet is discarded (ie, DROP).

[0074] S302, clear the filling content in the mark field of the first network data packet that is received or discarded.

[0075] In the embodiment of the present application, for any network data packet in the first network data packet, after the trusted network data packet filtering function completes the decision on the network data packet, the filling content in the mark field of the network data packet can be cleared. Specifically, if the network data packet is trusted, the trusted mark in the mark field is cleared immediately after receiving the network data packet; if the network data packet is untrusted, and its untrusted mark is a null value, the process ends after discarding the network data packet without clearing the untrusted mark in the mark field.

[0076] Therefore, the present application performs a trusted decision process when a network data packet is pushed into the stack in the NF_IP_LOCAL_IN hook phase of the Linux Netfilter framework, thereby allowing a real attacker to deceive into the trusted network designed for the honeypot and preventing network data packets from other channels from entering the honeypot network. At the same time, the honeypot network is also strengthened and improved in terms of secure and controllable communication transmission.

[0077] On this basis, the embodiment of the present application also modifies the VXLAN message header format in the VXLAN (English full name Virtual eXtensible Local Area Network, Chinese name Virtual Extensible Local Area Network) tunnel packet sending and receiving process to verify the honeypot network lateral jump traffic and other cluster traffic behaviors. Figure 4 , Figure 4 Another flow chart of a honeypot cluster trusted network communication method provided by an embodiment of the present application. Figure 4 As shown, a honeypot cluster trusted network communication method provided by an embodiment of the present application also includes the following steps:

[0078] S40, during the communication between the packet sending end and the packet receiving end in the honeypot network, marking the second network data packet to be sent by the packet sending end to identify whether the second network data packet is trusted.

[0079] In an embodiment of the present application, the honeypot nodes in the honeypot cluster communicate based on the VXLAN tunnel. For example, when an external network data packet accesses different nodes in the honeypot cluster or a honeypot accesses a honeypot lateral hop traffic, the two honeypot nodes as the packet sending end and the packet receiving end realize the transmission of the network data packet through the VXLAN tunnel.

[0080] For the network data packet to be sent by the packet sending end (ie, the second network data packet), whether it is trusted is determined by judging whether it is a network data packet forwarded by the honeypot network, and thus marked as trusted or untrusted.

[0081] In a possible implementation, the tag can be performed using the triplet information of the network data packet. Figure 5 , Figure 5 Another partial flow chart of a honeypot cluster trusted network communication method provided by an embodiment of the present application. Figure 5 As shown, an embodiment of the present application provides a honeypot cluster trusted network communication method, wherein "marking the second network data packet to be sent by the packet sending end" in step S40 may include steps S401 to S404, and these steps are described in detail below.

[0082] S401, determine whether the second network data packet belongs to the network data packet forwarded to the honeypot network; if not, execute step S402; if yes, execute steps S403 to S404.

[0083] S402: Generate an untrusted tag for a second network data packet.

[0084] In an embodiment of the present application, if the second network data packet does not belong to the network data packet forwarded to the honeypot network, it is treated as unknown traffic and determined to be untrusted, and then an untrusted tag is generated for the second network data packet, and the untrusted tag can be a null value.

[0085] S403, obtaining triplet information of the second network data packet, where the triplet information includes a source IP address, a source port, and a protocol.

[0086] In an embodiment of the present application, if the second network data packet is a network data packet forwarded to the honeypot network, it is treated as honeypot traffic and determined to be trusted, and then the triplet information of the second network data packet is obtained, including the source IP address, source port and protocol.

[0087] S404: Generate a trusted tag of the second network data packet using the source IP address, source port and protocol of the second network data packet.

[0088] In an embodiment of the present application, the source IP address, source port and hash value of the protocol of the second network data packet can be used as a trusted mark through a hash operation.

[0089] S50, fills the marking result of the second network data packet into the vx_flags field of the sk_buff data structure of VXLAN, so as to achieve: the packet sending end stacks and encapsulates the filling content of the vx_flags field with the second network data packet, and sends the stacked encapsulation result to the packet receiving end; the packet receiving end makes a decision on the second network data packet according to the filling content of the vx_flags field, obtains the second network data packet by decapsulation after clearing the filling content of the vx_flags field, and sends the second network data packet to the Linux kernel network stack.

[0090] In the embodiment of the present application, the marking result (untrusted tag or trusted tag) of the second network data packet is filled into the vx_flags field (in the sk_buff structure of the VXLAN.

[0091] The packet sender stacks and encapsulates the fill content of the vx_flags field with the second network data packet, and then sends it through the VXLAN tunnel UDP protocol. Figure 6 , Figure 6 A schematic diagram of a stacked package provided in an embodiment of the present application. Figure 6 As shown in the figure, stacked encapsulation is to encapsulate the Ethernet header message (i.e. Figure 6 Ethernet Header in), IP header message (i.e. Figure 6 IP Header in), UDP header message (i.e. Figure 6 UDP Header in), VXLAN header message (i.e. Figure 6 The VXLANHeader in the VXLAN header) and the original messages of the second network data packet are stacked in sequence, and the vx_flags field is the first 24 bits of the reserved field in the VXLAN header message.

[0092] The packet receiving end determines whether the second network data packet is trusted according to the filling content of the vx_flags field, and decides whether to receive the second network data packet or discard the second network data packet, and then clears the filling content in the vx_flags field of the second network data packet, decapsulates the original message of the second network data packet from the stacked encapsulation result, and sends the original message of the second network data packet to the next layer of the Linux kernel network stack.

[0093] Specifically, when clearing the filling content in the vx_flags field of the second network data packet, if the second network data packet is trusted, the trusted flag in the vx_flags field of the second network data packet is cleared at the packet receiving end; if the second network data packet is untrusted, its untrusted flag is a null value and does not need to be cleared.

[0094] Therefore, the embodiment of the present application realizes that the honeypot network encapsulates trusted header information through the VXLAN tunnel when accessing cross-node honeypot communications, effectively increasing the isolation, security, and reliability of the honeypot network in the cluster environment. Even if packet capture is used in the honeypot network, it is impossible to distinguish the difference from other network messages. Under the principle of security and trust, the sameness and consistency of the honeypot network and the real network are restored.

[0095] A honeypot cluster trusted network communication method provided by an embodiment of the present application is introduced above. A device for executing the honeypot cluster trusted network communication method is introduced below.

[0096] See also Figure 7 , Figure 7 This is a schematic diagram of the structure of a honeypot cluster trusted network communication device provided in an embodiment of the present application. Figure 7 As shown, a honeypot cluster trusted network communication device provided by an embodiment of the present application includes:

[0097] The forwarding marking module 10 is used to mark the first network data packet accessing the honeypot network to identify whether the first network data packet is trusted;

[0098] The forwarding decision module 20 is used to fill the marking result of the first network data packet into the mark field of the sk_buff data structure of the Linux kernel network stack; when the first network data packet is pushed into the stack, a decision is made on the first network data packet based on the filling content of the mark field to forward the trusted network data packets in the first network data packet to the honeypot network.

[0099] In a possible implementation, the forwarding marking module 10 is specifically configured to:

[0100] Determine whether the first network data packet accesses the honeypot network via the honeypot gateway; if not, generate a non-trusted mark for the first network data packet; if so, obtain the ternary information of the first network data packet, the ternary information including the source IP address, source port and protocol; convert the source IP address of the first network data packet into an internal IP address in the honeypot network; use the internal IP address, the source port and protocol of the first network data packet to generate a trusted mark for the first network data packet.

[0101] In a possible implementation, the forwarding decision module 20 for making a decision on the first network data packet based on the filling content of the mark field is specifically configured to:

[0102] The trusted network data packets in the first network data packets are received, and the untrusted network data packets are discarded; and the filling content in the mark field of the received or discarded first network data packets is cleared.

[0103] See also Figure 8 , Figure 8 Another structural diagram of a honeypot cluster trusted network communication device provided by an embodiment of the present application. Figure 8 As shown, in a possible implementation, the above-mentioned honeypot cluster trusted network communication device further includes:

[0104] The communication marking module 30 is used to mark the second network data packet to be sent by the packet sending end during the communication between the packet sending end and the packet receiving end in the honeypot network, so as to identify whether the second network data packet is trusted;

[0105] The communication decision module 40 is used to fill the marking result of the second network data packet into the vx_flags field of the sk_buff data structure of the VXLAN, so as to achieve: the packet sending end stacks and encapsulates the filling content of the vx_flags field with the second network data packet, and sends the stacked encapsulation result to the packet receiving end; the packet receiving end makes a decision on the second network data packet according to the filling content of the vx_flags field, obtains the second network data packet by decapsulation after clearing the filling content of the vx_flags field, and sends the second network data packet to the Linux kernel network stack.

[0106] In a possible implementation, the communication marking module 30 for marking the second network data packet to be sent by the packet sending end is specifically used for:

[0107] Determine whether the second network data packet belongs to the network data packet forwarded to the honeypot network; if not, generate a non-trusted mark for the second network data packet; if so, obtain the ternary information of the second network data packet, the ternary information includes the source IP address, source port and protocol; use the source IP address, source port and protocol of the second network data packet to generate a trusted mark for the second network data packet.

[0108] It should be noted that the detailed functions of each module in the embodiment of the present application can be found in the corresponding public part of the above-mentioned honeypot cluster trusted network communication method embodiment, and will not be repeated here.

[0109] The present application also provides an electronic device in an embodiment. Fig. 9 , Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device in the embodiment of the present application may include but is not limited to fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Fig. 9 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0110] like Fig. 9 As shown, the electronic device may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage device 908 to a random access memory (RAM) 903. When the electronic device is powered on, various programs and data required for the operation of the electronic device are also stored in the RAM 903. The processing device 901, the ROM 902, and the RAM 903 are connected to each other via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0111] Typically, the following devices may be connected to the I / O interface 905: an input device 906 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 907 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 908 including, for example, a memory card, a hard disk, etc.; and a communication device 909. The communication device 909 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although Fig. 9 An electronic device having various devices is shown, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0112] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any of the honeypot cluster trusted network communication methods provided in the embodiments of the present application.

[0113] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the honeypot cluster trusted network communication methods provided in the embodiments of the present application.

[0114] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0115] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a ROM, a RAM, a disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, a training device, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0116] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0117] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a training device, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, training device, or data center. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

Claims

1. A trusted network communication method for a honeypot cluster, characterized in that: The honeypot cluster trusted network communication method comprises: Marking a first network data packet accessing the honeypot network to identify whether the first network data packet is trusted; Fill the marking result of the first network data packet into the mark field of the sk_buff data structure of the Linux kernel network stack; When the first network data packet is pushed into the stack, a decision is made on the first network data packet based on the filling content of the mark field, so as to forward the trusted network data packet in the first network data packet to the honeypot network.

2. The honeypot cluster trusted network communication method according to claim 1, characterized in that: The marking of the first network data packet accessing the honeypot network includes: Determining whether the first network data packet accesses the honeypot network via a honeypot gateway; If not, generating a non-trusted tag for the first network data packet; If yes, obtain triplet information of the first network data packet, the triplet information including source IP address, source port and protocol; Converting the source IP address of the first network data packet to an internal IP address in the honeypot network; A trusted tag for the first network data packet is generated using the internal IP address, the source port and the protocol of the first network data packet.

3. The honeypot cluster trusted network communication method according to claim 1, characterized in that: The making a decision on the first network data packet based on the filling content of the mark field includes: Receiving trusted network data packets in the first network data packets and discarding untrusted network data packets; Clear the padding content in the mark field of the first network data packet that is received or discarded.

4. The honeypot cluster trusted network communication method according to claim 1, characterized in that: The honeypot cluster trusted network communication method further includes: During the communication between the packet sending end and the packet receiving end in the honeypot network, marking the second network data packet to be sent by the packet sending end to identify whether the second network data packet is trusted; The marking result of the second network data packet is filled into the vx_flags field of the sk_buff data structure of VXLAN to achieve: the packet sending end stacks and encapsulates the filling content of the vx_flags field with the second network data packet, and sends the stacked encapsulation result to the packet receiving end; the packet receiving end makes a decision on the second network data packet according to the filling content of the vx_flags field, obtains the second network data packet by decapsulation after clearing the filling content of the vx_flags field, and sends the second network data packet to the Linux kernel network stack.

5. The honeypot cluster trusted network communication method according to claim 4, characterized in that: The marking of the second network data packet to be sent by the packet sending end includes: Determine whether the second network data packet belongs to the network data packet forwarded to the honeypot network; If not, generating a non-trusted tag for the second network data packet; If yes, obtain triplet information of the second network data packet, the triplet information including source IP address, source port and protocol; A trusted tag of the second network data packet is generated using the source IP address, source port and protocol of the second network data packet.

6. A honeypot cluster trusted network communication device, characterized in that: The honeypot cluster trusted network communication device comprises: A forwarding marking module, used for marking a first network data packet accessing a honeypot network to identify whether the first network data packet is trusted; A forwarding decision module is used to fill the marking result of the first network data packet into the mark field of the sk_buff data structure of the Linux kernel network stack; when the first network data packet is pushed into the stack, a decision is made on the first network data packet based on the filling content of the mark field to forward the trusted network data packets in the first network data packet to the honeypot network.

7. The honeypot cluster trusted network communication device according to claim 6, characterized in that: The honeypot cluster trusted network communication device also includes: A communication marking module, used for marking a second network data packet to be sent by the packet sending end during the communication between the packet sending end and the packet receiving end in the honeypot network, so as to identify whether the second network data packet is trusted; A communication decision module is used to fill the marking result of the second network data packet into the vx_flags field of the sk_buff data structure of the VXLAN, so as to achieve: the packet sending end stacks and encapsulates the filling content of the vx_flags field with the second network data packet, and sends the stacked encapsulation result to the packet receiving end; the packet receiving end makes a decision on the second network data packet according to the filling content of the vx_flags field, obtains the second network data packet by decapsulation after clearing the filling content of the vx_flags field, and sends the second network data packet to the Linux kernel network stack.

8. A computer program product, characterized in that The method comprises computer-readable instructions, and when the computer-readable instructions are executed on an electronic device, the electronic device implements the honeypot cluster trusted network communication method according to any one of claims 1 to 5.

9. An electronic device, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the electronic device can implement the honeypot cluster trusted network communication method according to any one of claims 1 to 5.

10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the honeypot cluster trusted network communication method as described in any one of claims 1 to 5.

Images