Method for deploying a honeypot

Abstract

The application provides a deployment method of a honeypot, comprising the following steps: receiving tunnel data sent by a tunnel server and analyzing the tunnel data to output a target port number, wherein the tunnel data is derived from IP data packets of a public network attack end; querying a MAC mapping table based on the target port number, matching a virtual MAC address, obtaining a first Ethernet frame carrying the virtual MAC address, and forwarding the first Ethernet frame to a honeypot container so that the honeypot container generates a response packet; and returning the response packet to the public network attack end through the tunnel server. The method sets a MAC mapping table and a frame reconstruction operation at the honeypot host layer, ensures that the virtual MAC address is reserved in the Ethernet frame, makes the attack traffic always carry a virtual identity, avoids protocol layer stripping, maintains the original MAC layer context of the response packet generated by the honeypot container when the response packet is returned to the public network, and enhances the geographical camouflage effect.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method for deploying honeypots. Background Technology

[0002] In public network honeypot deployment scenarios, a single physical host needs to virtualize multiple independent nodes to lure attackers. Each honeypot node must have a unique MAC address as its core identity identifier to maintain the authenticity of the disguise. This scenario requires honeypot nodes to maintain the consistency of their virtual identities during public network traffic interactions to prevent attackers from breaking the disguise mechanism due to identity exposure.

[0003] A tunnel proxy is used to forward public network traffic. It uses tunnel encapsulation technology to forward the raw traffic of virtual nodes inside the container to the public network. In this process, the tunnel client performs protocol layer conversion on the raw data packets, strips the raw Ethernet frame header (including the virtual MAC address), encapsulates the application layer data into a new transport layer protocol packet, and re-adds the real MAC address of the physical host at the receiving end.

[0004] This forwarding mechanism, which strips the original MAC address, leads to the loss of virtual identities and the failure of geographic spoofing. Summary of the Invention

[0005] This application provides a method for deploying honeypots to address the problems of lost virtual identities and failed geospoofing.

[0006] Firstly, this application provides a honeypot deployment method applied to the honeypot host layer, comprising:

[0007] Receive tunnel data sent by the tunnel server, parse the tunnel data, and output the target port number. The tunnel data originates from IP packets of the public network attack terminal.

[0008] Based on the target port number, query the MAC mapping table to match the virtual MAC address;

[0009] Acquire a first Ethernet frame, the first Ethernet frame carrying the virtual MAC address;

[0010] Forward the first Ethernet frame to the honeypot container so that the honeypot container generates a response packet;

[0011] The response packet is returned to the public network attacking end through the tunnel server.

[0012] In some feasible embodiments, the method further includes:

[0013] In response to the honeypot container creation command, a virtual MAC address is generated and a local port number is assigned;

[0014] A port binding request is sent to the cloud server, so that the cloud server generates a resource allocation request based on the port binding request; the port binding request includes the local port number;

[0015] The system receives a resource allocation result returned by the cloud server, which is generated based on the resource allocation request; the resource allocation result includes the public target IP address and the target port number.

[0016] Establish a mapping relationship between the target port number and the virtual MAC address, and store it in the MAC mapping table.

[0017] In some feasible embodiments, receiving the resource allocation result returned by the cloud server includes:

[0018] Send a public network resource request to the cloud server so that the cloud server can obtain available public network IPs and target port numbers from the public network IP resource pool through the IP pool manager, and generate resource allocation results based on the public network IPs and target port numbers;

[0019] Receive the resource allocation results sent from the cloud server to the tunnel server.

[0020] In some feasible embodiments, obtaining the first Ethernet frame includes:

[0021] Create virtual network interfaces, and configure multiple virtual network interfaces on a single physical network interface card;

[0022] Parse the tunnel data to obtain the second Ethernet frame, which carries the MAC address of the attacking end;

[0023] The attacker's MAC address in the second Ethernet frame is replaced with a virtual MAC address to generate the first Ethernet frame, wherein the attacker's MAC address is the MAC address of the public network attacker.

[0024] In some feasible embodiments, the method further includes:

[0025] In response to the honeypot container creation command, an isolated honeypot runtime instance is generated in the virtualization environment;

[0026] Bind the virtual network interface to the honeypot instance and configure the virtual MAC address and the corresponding LAN IP address.

[0027] In some feasible embodiments, forwarding the first Ethernet frame to the honeypot container so that the honeypot container generates a response packet includes:

[0028] Forward the first Ethernet frame to the honeypot container;

[0029] The system receives an Ethernet frame returned by the honeypot container. The Ethernet frame includes a MAC header and an IP response packet. The IP response packet contains a response packet whose attacker's IP address is the virtual IP address of the honeypot container and whose destination IP address is the public IP address of the attacker.

[0030] In some feasible embodiments, returning the response packet to the public network attacker via the tunnel server includes:

[0031] Receive the IP response packet;

[0032] The IP response packet is encapsulated into the tunnel protocol data unit of the tunnel server, so that the tunnel protocol data unit forwards the IP response packet to the public network attack terminal.

[0033] Secondly, this application provides a method for deploying a honeypot, applied to a cloud server, including:

[0034] The IP data packets sent by the public network attacker are encapsulated into the tunnel server, so that the honeypot host layer receives the tunnel data sent by the tunnel server, parses the tunnel data, and outputs the target port number; based on the target port number, the MAC mapping table is queried to match the virtual MAC address; and the first Ethernet frame is obtained, wherein the tunnel data originates from the IP data packets of the public network attacker, and the first Ethernet frame carries the virtual MAC address.

[0035] The response packet returned by the honeypot host layer is received and sent to the public network attack terminal.

[0036] In some feasible embodiments, before encapsulating the IP packets sent by the public network attacker into the tunnel server, the process includes:

[0037] Receive IP data packets sent by the public network attack terminal, wherein the destination address of the IP data packets is the public network IP address assigned to the honeypot host;

[0038] Parse the IP data packet to extract the target port number;

[0039] Based on the target port number, query the port mapping table to match the tunnel node identifier;

[0040] Based on the tunnel node identifier, the IP data packets sent by the public network attacker are encapsulated into the tunnel server corresponding to the tunnel node identifier.

[0041] In some feasible embodiments, the method further includes:

[0042] The system receives public network resource request requests sent by the honeypot host layer, and the public network resource request requests are forwarded by the tunnel server.

[0043] In response to the public network resource request, the IP pool manager is invoked to obtain an available public network IP and the target port number from the public network IP resource pool;

[0044] Resource allocation results are generated based on the public IP address and target port number;

[0045] The resource allocation result is sent to the tunnel server, which then forwards it to the honeypot host layer, enabling the honeypot host layer to establish a mapping relationship between the target port number and the virtual MAC address.

[0046] As can be seen from the above technical solutions, this application provides a honeypot deployment method, including: receiving tunnel data sent by a tunnel server, parsing the tunnel data, and outputting a target port number, wherein the tunnel data originates from IP packets of a public network attacking end; based on the target port number, querying a MAC mapping table, matching a virtual MAC address, and then obtaining a first Ethernet frame, the first Ethernet frame carrying the virtual MAC address, forwarding the first Ethernet frame to the honeypot container so that the honeypot container generates a response packet; and returning the response packet to the public network attacking end through the tunnel server. The method sets up a MAC mapping table and frame reconstruction operation at the honeypot host layer to ensure that the virtual MAC address is retained in the Ethernet frame, so that attack traffic always carries a virtual identity, avoiding protocol layer stripping. The response packet generated by the honeypot container maintains the original MAC layer context when returning to the public network, thus enhancing the geographical masquerading effect. Attached Figure Description

[0047] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 A flowchart illustrating the honeypot deployment method provided in this application embodiment;

[0049] Figure 2 This is a schematic diagram illustrating the tunnel data transmission process provided in an embodiment of this application.

[0050] Figure 3 Transmitted timing diagram provided for embodiments of this application;

[0051] Figure 4 This is a schematic diagram of the response packet transmission process provided in an embodiment of this application;

[0052] Figure 5 This is a schematic diagram illustrating the creation of a virtual network interface provided in an embodiment of this application.

[0053] Figure 6This is a schematic diagram of the public IP address flow provided in the embodiments of this application;

[0054] Figure 7 A flowchart illustrating another honeypot deployment method provided in this application embodiment;

[0055] Figure 8 This is a timing diagram illustrating the interaction between the honeypot host layer and the cloud server, as provided in an embodiment of this application. Detailed Implementation

[0056] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0057] When forwarding, tunnel proxies typically convert the protocol layer, removing the virtual MAC address from the original Ethernet frame header and adding the real MAC address of the physical host, thereby exposing the actual deployment location and hardware information of the honeypot.

[0058] This application provides a honeypot deployment method in some embodiments, applied to the honeypot host layer. By setting up a MAC mapping table and frame reconstruction operation at the honeypot host layer, the virtual MAC address is preserved in the Ethernet frame, so that the attack traffic always carries the virtual identity, which can avoid protocol layer stripping. When the response packet generated by the honeypot container returns to the public network, the original MAC layer context is maintained, and the geographical masquerading effect is enhanced.

[0059] The method includes the following steps: Figure 1 As shown, it includes:

[0060] S110: Receives tunnel data sent by the tunnel server, parses the tunnel data, and outputs the target port number.

[0061] like Figure 2 As shown, tunnel data is an encapsulation format used for data transmission between the honeypot host layer and the tunnel (Fast Reverse Proxy, FRP) server. Tunnel data includes IP packets from public network attackers, which are terminal devices that launch malicious probing or attack activities against the honeypot system via the public internet. The IP packets are generated through tunneling protocol conversion, including the tunnel header and the encapsulated original data.

[0062] The tunnel server encapsulates IP packets sent by public network attackers to form a tunnel data packet. For example, when a public network attacker sends a network packet targeting the honeypot system, the cloud server first encapsulates the IP packet into a tunnel protocol unit, forming a tunnel data packet. The tunnel data packet is used to forward public network traffic to the honeypot host layer, avoiding intermediate network interference. In a honeypot deployment environment, tunnel data ensures the integrity and encryption of data packets during transmission.

[0063] For example, the outer IP header source address of the VXLAN tunnel data is the public IP address of the tunnel server, while the inner IP packet retains the original source IP address of the attacking end (such as 192.0.2.5).

[0064] The honeypot host layer obtains encapsulated tunnel data through the tunnel server interface. The FRP server receives public network attack traffic and forwards the data packets to the honeypot host through preset rules, such as port mapping, and performs transport layer protocol conversion to keep the original IP data packet structure unchanged.

[0065] When receiving tunnel data, the network protocol stack at the honeypot host layer processes the tunnel data, ensuring that attack traffic is seamlessly imported into the honeypot container while maintaining the virtual identity at the MAC layer.

[0066] like Figure 3 As shown, the honeypot host layer receives tunnel data packets from the tunnel server. The tunnel server encapsulates the IP data packets from the public network attacker into tunnel protocol units and sends them to the honeypot host layer. During the reception process, the honeypot host layer passes the tunnel data to the FRP client. The FRP client, deployed within the honeypot host layer, analyzes the header structure of the tunnel data and outputs the target port number as a critical route identifier.

[0067] The FRP server is used to receive public network attack packets and is set up on the public cloud edge node. The FRP client receives tunnel data and is set up locally on the honeypot host.

[0068] The destination port number is a logical port identifier used to identify the honeypot system service. It is obtained by parsing tunnel data and corresponds to a port number in the network transport layer. When receiving tunnel data, the honeypot host layer extracts the destination port number by parsing the header information of the tunnel data packet. In the tunnel data, the destination port number is set in the transport layer header of the inner original IP packet and is extracted after the honeypot host layer decapsulates the tunnel protocol.

[0069] S120: Based on the target port number, query the MAC mapping table to match the virtual MAC address.

[0070] The FRP client is also used to query the MAC mapping table based on the target port number to match the virtual MAC address, and then forward the output to the honeypot container through the virtual network card.

[0071] A MAC address mapping table is a database structure that stores the mapping between target port numbers and virtual MAC addresses. It's a key-value data structure stored in the honeypot host's memory, similar to a hash table or database table. The key in the mapping table is an integer representing the target port number, and the value is a 48-bit virtual MAC address string (e.g., EE:FF:AC:10:00:01). The mapping table is built by the honeypot host during container initialization, establishing the binding relationship between port numbers and virtual MAC addresses to map traffic to the honeypot container.

[0072] A MAC address mapping table can contain multiple entries, each recording a mapping between a local port number and a virtual MAC address. This mapping table can be stored as a hash table or key-value pairs. It is dynamically generated when the honeypot container is created and is used to guide packet forwarding by matching the target port number with the virtual MAC address.

[0073] A virtual MAC address is an access control layer address assigned to a honeypot container. Structurally, a virtual MAC address is a 48-bit hexadecimal value (e.g., 00:1B:44:11:3A:B7). The virtual MAC address is generated by the honeypot host layer in response to the container creation command and is bound to the container instance through a virtual network interface.

[0074] Virtual MAC addresses are used to replace the attacker's MAC address, maintaining the virtual network identity of the honeypot container. For example, when generating virtual MAC addresses, the host layer uses a random algorithm or a predefined address pool to allocate addresses, ensuring uniqueness within the local area network. Setting virtual MAC addresses allows attack traffic to maintain the original MAC layer information at the container level, preventing identity exposure.

[0075] A virtual MAC address is bound to the virtual network interface of the honeypot container, serving as a unique identifier at the data link layer, giving the container a routable network identity within the local area network.

[0076] Based on the target port number, the honeypot host layer queries the MAC mapping table to match the virtual MAC address. The MAC mapping table stores mapping entries generated during the container creation process, with each entry associating a target port number with a corresponding virtual MAC address. During a query, the mapping management module of the honeypot host layer accesses the MAC mapping table database and retrieves a matching entry using the target port number. If a match is found, the virtual MAC address is output as the basis for frame forwarding.

[0077] S130: Acquire the first Ethernet frame.

[0078] The first Ethernet frame is a network link layer data unit used for forwarding to the honeypot container. It carries a virtual MAC address as the destination address and includes fields such as the MAC header and IP packet information. The first Ethernet frame is generated by modifying the frame information in the original tunnel data.

[0079] The first Ethernet frame is used to carry attack traffic to the honeypot container while hiding the real network details. For example, the host layer extracts the source Ethernet frame from the tunnel data, replaces the attacker's MAC address with a virtual MAC address, and forms the first Ethernet frame.

[0080] The honeypot host layer acquires the first Ethernet frame, which is obtained by reconstructing the original tunnel data. Specifically, the source Ethernet frame is parsed from the tunnel data, and the attacker's MAC address is replaced with a virtual MAC address. During the acquisition process, the frame construction module processes the MAC header field of the source Ethernet frame, overwriting the source MAC address value with the virtual MAC address. The generated first Ethernet frame retains the original IP packet content, but the link-layer address has been modified. The reconstruction step gives the packet virtual network routing capabilities while preventing the MAC address from revealing the real host location.

[0081] S140: Forward the first Ethernet frame to the honeypot container so that the honeypot container can generate a response packet.

[0082] After the first Ethernet frame is generated, it is forwarded to the honeypot container. The honeypot container is a virtual running instance used to simulate real service trapping attacks. The honeypot container is an isolated running environment created by the honeypot host layer in the virtualization environment. The honeypot container is used to execute service logic and generate response packets. The response packets include modified IP headers and Ethernet frames.

[0083] For example, after receiving the first Ethernet frame, the honeypot container extracts IP layer data and simulates a service response to generate a new Ethernet frame, in which the destination address is the attacker's IP.

[0084] The honeypot host layer forwards the first Ethernet frame to the honeypot container. For example, the first Ethernet frame is forwarded to the honeypot container through a virtual network interface, which is bound when the container is created, allowing the host layer to directly inject frame data. After receiving the frame, the honeypot container executes preset service logic and generates a response packet.

[0085] The response packet includes a modified Ethernet frame header, where the source IP address is set to the virtual IP address of the honeypot container, and the destination IP address corresponds to the public IP address of the attacker. The honeypot container's response process simulates real system behavior, inducing the attacker to interact further to collect attack information.

[0086] S150: The response packet is returned to the public network attacker via the tunnel server.

[0087] It is understandable that when resource allocation, container instantiation, and network binding are completed, and the tunnel server successfully returns the response packet to the public network attacker, the honeypot system is considered to have reached a usable deployment state.

[0088] After receiving the Ethernet frame response packet output by the honeypot container, the honeypot host layer extracts the IP response packet content and encapsulates it into a tunnel data unit of the tunneling protocol. The tunnel server decapsulates the encapsulated unit into the original IP data packet and forwards it back to the public network attacker. This process maintains the IP layer address unchanged, making the response received by the attacker appear to originate from the original honeypot location.

[0089] For example, the attacker sends an HTTP request packet with the destination address being the public IP address of the honeypot. The cloud server encapsulates this packet into GRE tunnel data. After receiving the tunnel data, the honeypot host layer parses the target port number 80 and queries the MAC mapping table to match the virtual MAC address 00:1A:2B:3C:4D. It extracts an Ethernet frame from the tunnel data, replaces the attacker's MAC address with 00:1A:2B:3C:4D, generates the first Ethernet frame, and forwards it to the honeypot container. The container simulates a web service and generates an HTTP response packet (the source IP is the container's virtual IP, and the destination IP is the attacker's IP). The host layer encapsulates the response packet into the tunnel protocol and returns it to the attacker via the tunnel server. In this process, the attacker believes that the traffic comes from a virtual host in an independent geographical location.

[0090] The method described above reconstructs frames by querying a MAC mapping table and processing them at the local network layer. The honeypot system does not rely on external proxies to rewrite MAC addresses, reducing the risk of security vulnerabilities caused by improper address translation. Traffic received by the honeypot container maintains a complete virtual network identity, preventing attackers from inferring the real physical host or cloud location from the MAC address. This enhances the credibility of the honeypot as a decoy trap and the efficiency of attack data collection. Furthermore, it simplifies the forwarding mechanism, reduces intermediate protocol conversion steps, and the virtual MAC address ensures that all interactions between the attacker and the honeypot occur at the virtual network layer, requiring no additional proxy intervention.

[0091] In some embodiments, the response packet is returned to the public network attacking end via a tunnel server, such as... Figure 4 As shown, it includes the following steps:

[0092] S410: Receive IP response packet;

[0093] S420: Encapsulates the IP response packet into the tunnel protocol data unit of the tunnel server, so that the tunnel protocol data unit forwards the IP response packet to the public network attacking end.

[0094] An IP response packet is a network layer protocol unit encapsulated within an Ethernet frame, consisting of a source IP address, a destination IP address, and a protocol payload. When constructing an IP response packet, the honeypot container sets the virtual IP address bound to the container as the source address and the attacker's public IP address as the destination address.

[0095] In some embodiments, the IP response packet is generated through the following steps:

[0096] Forward the first Ethernet frame to the honeypot container;

[0097] The system receives an Ethernet frame returned by the honeypot container. The Ethernet frame includes a MAC header and an IP response packet. The IP response packet contains a response packet whose attacker's IP address is the virtual IP address of the honeypot container and whose destination IP address is the public IP address of the attacker.

[0098] The first Ethernet frame is generated according to step S130. After the honeypot host layer completes MAC address mapping and frame reconstruction, it sends the first Ethernet frame to the honeypot container. When the honeypot host layer forwards the first Ethernet frame to the honeypot container, it delivers the frame data to the container network protocol stack through the virtual network interface. After receiving the transport layer protocol data unit, the service process inside the container generates response content according to the application layer protocol specification.

[0099] After the honeypot container receives the first Ethernet frame, the container's network protocol stack generates an Ethernet frame. This frame contains a four-layer structure: MAC header, IP response packet, transport layer header, and application layer payload. The source address field in the MAC header is the virtual MAC address bound to the honeypot container, and the destination address is the attacker's MAC address.

[0100] The MAC header is the Layer 2 encapsulation part of an Ethernet frame, consisting of the source MAC address and the destination MAC address. When the container generates a response, the container's network protocol stack fills the source address field with a virtual MAC address and extracts the attacker's MAC address from the received frame, filling it into the destination address field.

[0101] When constructing response data, the container network protocol stack first sets the source address field at the IP layer. The container network protocol stack reads the virtual IP address value from the network interface card configuration and uses it as the source address of the response packet. The destination address is extracted from the IP header of the received packet to obtain the attacker's public IP address, which remains unchanged during transmission. The protocol type identifier and time-to-live (TTL) value at the IP layer are automatically set according to the service type; in this embodiment, no restrictions are imposed. For example, the HTTP service is set to protocol type 6 (TCP) and TTL value 64.

[0102] During the link layer processing phase, the container network protocol stack constructs the MAC header. The source MAC address uses the virtual MAC address bound to the virtual network interface, and the target MAC address is extracted from the attacker's MAC address in the MAC header of the received frame. After the MAC header is generated, the container network protocol stack encapsulates the IP response packet into a complete Ethernet frame structure.

[0103] The response frame is sent to the host layer network subsystem through the virtual network interface. After the host layer obtains the frame, it identifies the target MAC address and uses it as the public network attack address before performing tunnel encapsulation.

[0104] For example, in an SMTP honeypot scenario: the attacker sends an SMTP HELO command to the honeypot container. After parsing the command, the honeypot container generates a "250mail.example.com" response from the SMTP service process. The container's network protocol stack sets the virtual IP address 192.168.10.8 as the source IP, the attacker's IP as the destination IP, uses the virtual MAC address 00:1A:2B:3C:4D:5E for the MAC header source address, and sets the destination address to the source MAC address value of the received frame.

[0105] During tunnel encapsulation, the IP response packet is encapsulated into the tunnel protocol data unit (TMU) of the tunnel server. This TMU then forwards the IP response packet to the attacker on the public network. The TMU is a forwarding unit created by the tunnel server, consisting of an outer tunnel header and inner raw data. The TMU uses the received IP response packet as its payload, adding the control headers required by the tunnel protocol to ensure secure transmission of the response packet over the public network.

[0106] In the tunnel protocol data unit, the tunnel protocol data unit constructs a transport layer header according to the preset tunnel type configuration, sets the source port to a randomly assigned port number, sets the destination port to the tunnel protocol standard port, adds a tunnel protocol identifier header, writes a virtual network identifier in the protocol, and embeds the original IP response packet into the tunnel protocol data unit.

[0107] The encapsulated tunnel protocol data unit is passed to the network driver layer of the honeypot host. The network driver sets the key fields of the outer IP header according to the tunnel configuration information. The source IP address is set to the public virtual IP address assigned to the honeypot service by the cloud server, and the destination IP address is set to the public entry address of the tunnel server.

[0108] Upon receiving the tunnel protocol data unit, the tunnel server's tunnel protocol parsing module verifies the legitimacy of the outer IP source address. If the verification is successful, it performs a detuning operation, which involves stripping the outer IP header, transport layer header, and tunnel protocol header to restore the IP response packet. Based on the destination IP address of the response packet, i.e. the attacker's public IP address, it is forwarded to the attacker's public network via the IP routing mechanism.

[0109] In some embodiments, the method further includes:

[0110] In response to the honeypot container creation command, a virtual MAC address is generated and a local port number is assigned;

[0111] A port binding request is sent to the cloud server, so that the cloud server generates a resource allocation request based on the port binding request; the port binding request includes the local port number;

[0112] The system receives a resource allocation result returned by the cloud server, which is generated based on the resource allocation request; the resource allocation result includes the public target IP address and the target port number.

[0113] Establish a mapping relationship between the local port number and the virtual MAC address, and store it in the MAC mapping table.

[0114] The creation command for a honeypot container is a control command that triggers the honeypot instance initialization process, for example, issued by a management platform or automated orchestration system. The creation command includes container runtime parameters, such as image identifier, resource quotas, and security policies. Once the honeypot host layer receives the creation command, it initiates the container initialization process.

[0115] In some embodiments, in response to the honeypot container creation instruction, an isolated honeypot runtime instance is generated in a virtualized environment;

[0116] Bind the virtual network interface to the honeypot instance and configure the virtual MAC address and the corresponding LAN IP address.

[0117] During the implementation of the honeypot system, the trigger host layer receives the creation command and configures its resources. The honeypot host layer initializes the honeypot runtime instance in the virtualization environment, generates a virtual MAC address, and assigns a local port number. The virtual MAC address is created using a random generation algorithm, while the port management module selects an idle port from the available port range and assigns it to the container service.

[0118] The virtual network interface is used to establish a channel between the honeypot instance and the host network, allowing network traffic generated by the honeypot container to be injected into the host through this interface. The LAN IP address is a Layer 3 network identifier assigned to the honeypot container. The LAN IP address enables the honeypot container to communicate within the virtual network while maintaining isolation from the public IP address space.

[0119] In this embodiment, as Figure 5 As shown, the virtual network interface is Macvlan. Macvlan is a network virtualization technology provided by the Linux kernel, which allows multiple virtual network interfaces with independent MAC addresses to be created on a single physical network card. In other words, multiple virtual network interfaces can be set on one physical network card, and each virtual interface behaves as an independent physical network card at the network layer 2, i.e., the data link layer.

[0120] In this system, a single physical network interface card (NIC) acts as the parent interface, while virtual network interfaces with independent MAC addresses serve as child interfaces. The virtual interfaces directly send and receive data frames through the parent interface. When an attacker scans the network, the MAC address of the honeypot container appears as an independent physical device in the switch's MAC address table. The source MAC address of the response packet is the container's virtual MAC address, not the physical NIC's MAC address, thus severing its association with the host machine.

[0121] At the host operating system level, the container engine's network interface is invoked to execute the Macvlan virtual network creation command. This command activates the kernel Macvlan driver module, creating a virtual network partition on the physical network interface card (NIC). When the honeypot container starts, the container runtime performs atomic network configuration operations, creating a device node within the container's namespace and injecting the specified MAC address. A virtual MAC address is generated each time the container is created, filtering ARP request or response packets at the virtual interface layer and enabling reverse path filtering. The Macvlan driver directly writes the virtual MAC address into the Ethernet frame source address field, eliminating the need for address translation on the physical NIC.

[0122] When an Ethernet frame carrying the local virtual MAC address is received, the honeypot container protocol stack parses it and transmits it to the service application. The generated response packet uses the local area network IP as the source address and the virtual MAC as the source link address. The host layer captures the response data through the monitoring interface status and forwards it to the tunnel server for encapsulation and transmission.

[0123] In some implementations, multiple virtual sensing nodes with different IPs in the same network segment are configured on the same host and interact with the corresponding physical honeypot through association policies. Then, based on Linux container virtualization technology, multiple virtual network cards are created so that the physical honeypot returns different MAC addresses to the attacker when interacting with the virtual sensing nodes, thus preventing the attacker from identifying the same physical host.

[0124] However, when physical network interface cards (NICs) forward traffic from virtual containers, they by default write the host machine's MAC address into the Ethernet frame source address field. Attackers can discover by analyzing ARP responses or ICMP error messages that all independent honeypots expose the same physical MAC address. In other words, relying solely on virtualization layer network isolation cannot achieve true geographical masquerading.

[0125] Furthermore, due to the limitations of cloud servers, a single host can only bind 1-2 public IPs. Adding a new public IP requires hardware changes. Because public IP resources are limited and cannot be dynamically expanded, the honeypot network has a narrow exposure surface, resulting in a single geographical area for capturing samples and only being able to obtain localized attack characteristics.

[0126] To solve the above problems, such as Figure 6 As shown, in some embodiments, S610: Send a public network resource request to the cloud server so that the cloud server can obtain available public network IPs and target port numbers from the public network IP resource pool through the IP pool manager, and generate resource allocation results based on the public network IPs and target port numbers;

[0127] S620: Receive the resource allocation result sent from the cloud server to the tunnel server.

[0128] A public network resource request is a request initiated by the honeypot host layer to the cloud server to request public network resources. It includes fields such as the local port number, protocol type, and session token. The public network resource request is constructed by the resource management module of the honeypot host layer and sent through a secure channel during the initial configuration phase of the container. The public network resource request is used to request an access point that can be exposed to the public network for the newly created honeypot container, triggering the cloud public network resource allocation process.

[0129] The IP pool manager is a public IP address resource management module deployed on a cloud server. It may include an address allocation engine and a port status database. After receiving a resource allocation instruction, the public IP address resource management module selects an idle public IP from the available address range of the public IP resource pool, and at the same time allocates an unoccupied target port number from the port resource pool.

[0130] Available public IPs are IP addresses that are idle in the public IP resource pool. The IP addresses are obtained by the IP pool manager through an address filtering operation. The filtering process needs to exclude addresses that have already been assigned and addresses that have entered the cooldown period. Available public IPs can be used as the target access addresses for honeypot services.

[0131] The target port number is a transport layer port identifier assigned by the IP pool manager. It can be located in the high-order port range. The port number allocation implements a port conflict detection mechanism to avoid duplication with already active services. The target port number, combined with an available public IP address, becomes the entry point for attack traffic, thus generating the resource allocation result.

[0132] The resource allocation result contains a set of data including the target public IP address and the target port number. This data is sent from the cloud server to the tunnel server. The tunnel server is used to transmit the resource allocation result between the cloud server and the honeypot host layer. Based on the target port number in the resource allocation result, a mapping relationship with the virtual MAC address is established.

[0133] The virtual MAC address is obtained based on the second Ethernet frame; in some embodiments, a virtual network interface is created.

[0134] Parse the tunnel data to obtain the second Ethernet frame, which carries the MAC address of the attacking end;

[0135] The attacker's MAC address in the second Ethernet frame is replaced with a virtual MAC address to generate the first Ethernet frame, wherein the attacker's MAC address is the MAC address of the public network attacker.

[0136] A virtual network interface (VNIC) is a virtual network endpoint created by the honeypot host layer. Implemented using virtualization technology, the VNIC includes data transmission and reception queues and a protocol processing stack. During the acquisition of the first Ethernet frame, the VNIC acts as a data packet reconstruction platform, receiving the parsed results of the tunnel data and providing frame editing capabilities. The creation of the VNIC is triggered by the network management module at the host layer, and a temporary interface identifier is automatically assigned during its creation.

[0137] Conventional tunnel proxies strip the original link-layer frame header during cross-domain forwarding, resulting in the loss of the container's virtual MAC address. To address this issue, this embodiment first obtains the second Ethernet frame, i.e., the source Ethernet frame, and reconstructs it to obtain the first Ethernet frame. Before the attack traffic reaches the honeypot container, the link-layer virtual identity is restored by performing MAC address replacement, thus preserving the integrity of the upper-layer protocol and converting the hardware identifier of the attack source into a virtual identifier.

[0138] Specifically, the second Ethernet frame is the raw link layer data parsed from the tunnel data, containing the complete MAC header and IP payload. The source MAC address field carried in the second Ethernet frame is the MAC address of the attacking end, which records the hardware identifier of the public network attacking device. During the frame reconstruction process, the second Ethernet frame serves as the basic input data.

[0139] After frame reconstruction, the first Ethernet frame is formed after the source MAC address has been replaced. It retains the upper-layer protocol data of the second Ethernet frame, such as the IP header and TCP payload, and only modifies the link-layer source address field. The first Ethernet frame carries the virtual MAC address as the source address.

[0140] For example, in a scanning attack with the public network attacker's MAC address 00:1C:B3:09:85:15, after the second Ethernet frame arrives through the tunnel, the honeypot host layer replaces the source address with the virtual MAC address 00:1A:2B:3C:4D:5E. The reconstructed first Ethernet frame is forwarded to the honeypot container. When the honeypot container generates a response packet, it uses the virtual MAC address as the source address. After receiving the response, the attacker only observes the virtual MAC address information and cannot trace the real physical device.

[0141] The honeypot host of the described method queries the MAC mapping table based on the target port number, binds the virtual MAC address, and reconstructs the Ethernet frame before forwarding it to the container. This solves the problem of virtual identity loss caused by stripping the original frame header in traditional tunneling solutions. The honeypot container generates a response packet containing a virtual IP based on the real information of the request packet. This response packet is encapsulated into a tunnel protocol unit at the host layer and decapsulated by the cloud tunnel server before being returned to the public network attack end. This ensures that the response packet carries a dynamically allocated public network IP, preventing attackers from using MAC or IP association to trace the source geographically.

[0142] Some embodiments of this application also provide a method for deploying a honeypot on a cloud server, such as... Figure 7 As shown, it includes the following steps:

[0143] S710: Encapsulates the IP data packets sent by the public network attacker into the tunnel server, so that the honeypot host layer receives the tunnel data sent by the tunnel server, parses the tunnel data, outputs the target port number, queries the MAC mapping table based on the target port number to match the virtual MAC address, and obtains the first Ethernet frame.

[0144] The tunnel data originates from IP packets of the public network attack terminal; the first Ethernet frame carries the virtual MAC address. It is understood that the steps executed by the honeypot host layer can be referred to the above embodiments, and will not be repeated in this embodiment.

[0145] like Figure 8 As shown, the cloud server receives the raw IP data packet sent by the public network attacker. The destination IP address is the public virtual address assigned to the honeypot service by the cloud (such as 198.51.100.15). The destination port number at the transport layer identifies the service type of the attack target. The traffic analysis module parses the IP data packet and extracts the destination port number field value.

[0146] The cloud server sends the original IP data packets to the tunnel server, which encapsulates the original IP data packets to generate tunnel data and sends it to the honeypot host layer.

[0147] In some embodiments, before encapsulating the IP packets sent by the public network attacker into the tunnel server, the process includes:

[0148] Receive IP data packets sent by the public network attack terminal, wherein the destination address of the IP data packets is the public network IP address assigned to the honeypot host;

[0149] Parse the IP data packet to extract the target port number;

[0150] Based on the target port number, query the port mapping table to match the tunnel node identifier;

[0151] Based on the tunnel node identifier, the IP data packets sent by the public network attacker are encapsulated into the tunnel server corresponding to the tunnel node identifier.

[0152] The IP packets sent by the public network attacker are the raw network layer protocol data units of the internet attack host. The header contains the source IP address (the attacker's public IP address), the destination IP address (the public virtual IP address assigned to the honeypot service by the cloud), the transport layer protocol type, and the destination port number. The IP packets are transmitted to the cloud access point through the routing protocol.

[0153] The public network access point of the cloud server receives IP data packets sent by the attacker. When the data packet enters the preset honeypot service IP segment, it triggers protocol parsing, reads the destination address field of the IP header, verifies that the address belongs to the allocated service address pool, disassembles the header, and extracts the destination port number field value. In one implementation, the position of a specific field in the transport layer header is located by offset calculation, and then the integer value obtained is the target port number.

[0154] Using the target port number as the query key, the distributed port mapping table is accessed. For example, the query operation locates the database node storing the port mapping relationship through a sharding routing algorithm, obtains the corresponding tunnel node identifier and associated parameters, and performs dynamic tunnel node allocation if the port number is not registered or has expired.

[0155] The tunnel server is located based on the tunnel node identifier. After the connection is established, a triple encapsulation operation is performed. The first layer is to add a tunnel protocol header (such as setting the VNI identifier in the VXLAN header), the second layer is to build a transport layer header (the UDP destination port is fixed to the protocol standard port), and the third layer is to set the outer IP header (the source address is the cloud exit IP, and the destination address is the tunnel server's physical IP).

[0156] After encapsulation, the data is sent to the tunnel server via the physical network interface. Upon receiving the data, the tunnel server verifies that the outer destination address matches the local instance. After decryption and protocol verification, the data is forwarded to the associated honeypot host through a preset tunnel channel, thus completing the directed transmission of public network traffic to the private network.

[0157] For example, the attacker sends a TCP packet with a destination IP of 198.51.100.15 (destination port = 55000). The cloud extracts port number 55000, queries the port mapping table to obtain the tunnel node identifier "eu-central-1-node07", encapsulates it with VXLAN data, where the outer destination IP is 52.25.33.7 (the tunnel server's physical address), VNI is 2001, and the inner encapsulates the original attack packet. The tunnel server matches the VNI and forwards it to the associated honeypot host.

[0158] In some embodiments, an IP pool manager is provided in the cloud server. The IP pool manager realizes multi-node status synchronization through the Raft protocol. The management unit maintains a bitmap index database of public IP addresses. Each IP address is associated with a status label, such as active, idle, faulty, geographical coordinates and recent active timestamp. The IP pool manager filters available IP addresses based on the least recently used algorithm.

[0159] The IP manager obtains IP addresses from the public IP resource pool, which is a collection of virtualized resources in the cloud and stored in a sharded cluster of a distributed key-value database. Each IP address in the public IP resource pool is bound to data including the Autonomous System Number, BGP route priority, available port range, and health check status. The resource pool maintains IP availability through a testing process, and faulty addresses are automatically isolated to the repair queue.

[0160] A non-faulty address is a usable public IP address. A usable public IP address is an address that meets the conditions selected by the IP pool manager according to the resource allocation policy. The conditions include that the address can be marked as idle and that the test process has been passed. This address can be stored in a different format than the non-usable public IP address. For example, the usable public IP address can be stored in the first format and the non-usable public IP address can be stored in the second format. This can improve the retrieval speed when retrieving the usable public IP address.

[0161] In some embodiments, a public network resource request sent by the honeypot host layer is received, and the public network resource request is forwarded by the tunnel server;

[0162] In response to the public network resource request, the IP pool manager is invoked to obtain an available public network IP and the target port number from the public network IP resource pool;

[0163] Resource allocation results are generated based on the public IP address and target port number;

[0164] The resource allocation result is sent to the tunnel server, which then forwards it to the honeypot host layer, enabling the honeypot host layer to establish a mapping relationship between the target port number and the virtual MAC address.

[0165] The steps can be found in steps S410-S420 of the above embodiment.

[0166] Unlike the embodiments described above, for the extraction of available public IPs from the IP pool manager, during the resource allocation process of the IP pool manager, available public IPs and unavailable public IPs are stored using a differentiated storage structure to achieve fast retrieval. Available public IPs are stored in a first data structure composed of contiguous memory blocks, which organizes IP addresses and their associated metadata in array form. Each IP entry is stored in a fixed-length format.

[0167] For example, the first four bytes are the IP address value in network byte order, the next four bytes store the compressed geographic coordinates, and the last eight bytes record the timestamp of the last health check.

[0168] Unavailable public IP addresses are stored in a second data structure based on a linked list, with the storage format including a fault type flag field and an isolation expiration timestamp.

[0169] When the IP pool manager performs address allocation operations, it skips the second data structure and directly accesses the memory starting address of the first data structure. For example, it locates the entry point of a contiguous memory block using pointer arithmetic and scans active entries in order of least recently used algorithm. Upon finding a usable IP that meets the criteria, it updates the entry's status to marked as allocated and simultaneously disconnects the connection pointer to the metadata area. Memory access efficiency can be improved by setting the data type format to avoid traversing the resource pool data.

[0170] After resource allocation is completed, the second data structure is scanned asynchronously. When an IP address that has completed its isolation period passes the test process, it is removed from the linked list, reformatted, and inserted into the end of a continuous memory block in the first data structure, thereby realizing the dynamic recycling of the resource pool.

[0171] S720: Receives the response packet returned by the honeypot host layer and sends it to the public network attacker.

[0172] The cloud server receives the response traffic returned by the honeypot host layer, which is the data encapsulated in the tunnel. It then parses and restores the original response packet using the tunnel protocol, and routes the response packet to the public network attacker's source address. The encapsulation process is detailed in steps S610-S620 and will not be elaborated here. When the honeypot host layer parses the tunnel data, the restored original IP data packet has a completely identical data structure to the data sent by the attacker.

[0173] Similar parts between the embodiments provided in this application can be referred to mutually. The specific implementation methods provided above are only a few examples under the overall concept of this application and do not constitute a limitation on the scope of protection of this application. For those skilled in the art, any other implementation methods extended from the solution of this application without creative effort shall fall within the scope of protection of this application.

Claims

1. A method for deploying a honeypot, characterized in that, Applied to the honeypot host layer, including: Receive tunnel data sent by the tunnel server, parse the tunnel data, and output the target port number. The tunnel data originates from IP packets of the public network attack terminal. Based on the target port number, query the MAC mapping table to match the virtual MAC address; Acquire a first Ethernet frame, the first Ethernet frame carrying the virtual MAC address; Forward the first Ethernet frame to the honeypot container so that the honeypot container generates a response packet; The response packet is returned to the public network attacking end through the tunnel server.

2. The honeypot deployment method according to claim 1, characterized in that, The method further includes: In response to the honeypot container creation command, a virtual MAC address is generated and a local port number is assigned; A port binding request is sent to the cloud server, so that the cloud server generates a resource allocation request based on the port binding request; the port binding request includes the local port number; The system receives a resource allocation result returned by the cloud server, which is generated based on the resource allocation request; the resource allocation result includes the target public IP address and the target port number. Establish a mapping relationship between the target port number and the virtual MAC address, and store it in the MAC mapping table.

3. The honeypot deployment method according to claim 2, characterized in that, The receipt of the resource allocation result returned by the cloud server includes: Send a public network resource request to the cloud server so that the cloud server can obtain available public network IPs and target port numbers from the public network IP resource pool through the IP pool manager, and generate resource allocation results based on the public network IPs and target port numbers; Receive the resource allocation results sent from the cloud server to the tunnel server.

4. The honeypot deployment method according to claim 1, characterized in that, The acquisition of the first Ethernet frame includes: Create virtual network interfaces, and configure multiple virtual network interfaces on a single physical network interface card; Parse the tunnel data to obtain a second Ethernet frame, which carries the MAC address of the attacking end. The attacker's MAC address in the second Ethernet frame is replaced with a virtual MAC address to generate the first Ethernet frame, wherein the attacker's MAC address is the MAC address of the public network attacker.

5. The honeypot deployment method according to claim 4, characterized in that, The method further includes: In response to the honeypot container creation command, an isolated honeypot runtime instance is generated in the virtualization environment; Bind the virtual network interface to the honeypot instance and configure the virtual MAC address and the corresponding LAN IP address.

6. The method for deploying honeypots according to claim 2, characterized in that, The forwarding of the first Ethernet frame to the honeypot container, so that the honeypot container generates a response packet, includes: Forward the first Ethernet frame to the honeypot container; The system receives an Ethernet frame returned by the honeypot container. The Ethernet frame includes a MAC header and an IP response packet. The IP response packet contains a response packet whose attacker's IP address is the virtual IP address of the honeypot container and whose destination IP address is the public IP address of the attacker.

7. The method for deploying honeypots according to claim 6, characterized in that, The step of returning the response packet to the public network attacking end through the tunnel server includes: Receive the IP response packet; The IP response packet is encapsulated into the tunnel protocol data unit of the tunnel server, so that the tunnel protocol data unit forwards the IP response packet to the public network attack terminal.

8. A method for deploying a honeypot, characterized in that, Applications in cloud servers, including: The IP data packets sent by the public network attacker are encapsulated into the tunnel server, so that the honeypot host layer receives the tunnel data sent by the tunnel server, parses the tunnel data, and outputs the target port number; based on the target port number, the MAC mapping table is queried to match the virtual MAC address; and the first Ethernet frame is obtained, wherein the tunnel data originates from the IP data packets of the public network attacker, and the first Ethernet frame carries the virtual MAC address. The response packet returned by the honeypot host layer is received and sent to the public network attack terminal.

9. The method for deploying honeypots according to claim 8, characterized in that, Before encapsulating the IP data packets sent by the public network attacker into the tunnel server, the process includes: Receive IP data packets sent by the public network attack terminal, wherein the destination address of the IP data packets is the public network IP address assigned to the honeypot host; Parse the IP data packet to extract the target port number; Based on the target port number, query the port mapping table to match the tunnel node identifier; Based on the tunnel node identifier, the IP data packets sent by the public network attacker are encapsulated into the tunnel server corresponding to the tunnel node identifier.

10. The method for deploying honeypots according to claim 8, characterized in that, The method further includes: The system receives public network resource request requests sent by the honeypot host layer, and the public network resource request requests are forwarded by the tunnel server. In response to the public network resource request, the IP pool manager is invoked to obtain an available public network IP and the target port number from the public network IP resource pool; Resource allocation results are generated based on the public IP address and target port number; The resource allocation result is sent to the tunnel server, which then forwards it to the honeypot host layer, enabling the honeypot host layer to establish a mapping relationship between the target port number and the virtual MAC address.

Images