A honeypot deployment method, system, device and storage medium

Abstract

The application provides a honeypot deployment method, system, device and storage medium, and belongs to the technical field of system protection. The method comprises the following steps: obtaining characteristic data flow and a source address of an incoming and outgoing data packet, and obtaining a cluster resource state; if the data flow is an abnormal attack behavior, triggering a number of same type alarm triggers based on the attack type and the alarm event of the characteristic data flow and the source address, and combining the attack intensity of the characteristic data flow; obtaining the attack scene type based on the attack intensity and the resource state; when the scene type is low intensity, generating a large number of low interaction honeypot scheduling strategies and an instant recycling life cycle strategy to obtain a honeypot scheduling strategy; when the scene type is medium intensity, generating an attack intensity equilateral medium interaction honeypot scheduling strategy and a delay destruction life cycle strategy to obtain a honeypot scheduling strategy; otherwise, generating a small number of high interaction honeypot scheduling strategies and a long-time reservation life cycle strategy to obtain a honeypot scheduling strategy; and deploying the honeypot based on the honeypot scheduling strategy. The application can improve the honeypot trapping efficiency.

Description

Technical Field

[0001] This invention relates to the field of system protection technology, and in particular to a honeypot deployment method, system, device and storage medium. Background Technology

[0002] The power Internet of Things (IoT) needs to connect terminals and control systems at all stages of power generation, transmission, distribution, and consumption. Therefore, its system involves multiple communication protocols, has a complex hierarchy, and a wide attack surface. If attackers exploit terminal vulnerabilities or protocol flaws to infiltrate the system, it can easily lead to malicious data tampering or device control failure. To address this, honeypots need to be deployed within the system to simulate vulnerable services or systems, enticing attackers to direct their attacks to the honeypot container. This allows for the capture and analysis of attack behaviors and methods, and the collection of threat intelligence.

[0003] Traditional honeypot deployment schemes require each honeypot container copy to exclusively occupy fixed computing, memory, and storage resources, and there is no mechanism for dynamically releasing or reusing honeypot states. This makes it difficult to adapt to the tidal fluctuations of network attacks. Therefore, during peak attack periods, the limited static resources of traditional schemes are easily exhausted, making it impossible to catch new attacks in time. During attack intervals, a large number of resources are not released in time and remain idle for a long time, which greatly reduces the overall system utilization.

[0004] To address the aforementioned issues, existing technologies capture traffic generated during the service process of a target system and extract traffic features to form feature vectors; construct a multi-model fusion attack detection model; identify attacks and attack categories based on the feature vectors and the multi-model fusion attack detection model; detect security vulnerabilities in the target system; assess the security posture of the target system based on the identified attacks and detected security vulnerabilities; determine the optimal dynamic orchestration strategy based on the security posture of the target system and a game theory model; and dynamically deploy honeypots based on the optimal dynamic orchestration strategy. This existing technology can improve honeypot attack response capabilities and enhance attack detection capabilities. However, the existing technology mainly generates orchestration strategies through security posture and game theory models, lacking consideration of the real-time triggering frequency of attacks and the status of cluster resources. It also cannot dynamically match the differentiated honeypot interaction depth and lifecycle according to the attack threat. Therefore, its orchestration strategy is difficult to adapt to the frequent and complex attack threats of the Internet of Things. During the peak of the attack, it is difficult to adjust the interactive honeypots in real time according to the attack intensity, resulting in a large number of concurrent attacks being only shallowly captured or even bypassed. During the attack interval, due to the lack of a recycling mechanism related to the actual attack scenario, the deployed honeypots remain for a long time after the attack subsides, making it impossible to release redundant resources in a timely manner, which greatly reduces the honeypot capture efficiency. Summary of the Invention

[0005] The present invention aims to provide a honeypot deployment method, system, device and storage medium to solve the above-mentioned technical problems, have sufficient trapping capabilities during peak attack periods and release redundant resources in a timely manner during attack intervals, thereby improving honeypot trapping efficiency.

[0006] To address the aforementioned technical problems, this invention provides a honeypot deployment method, comprising the following steps: Obtain the incoming and outgoing data packets and cluster resource status captured by each working node of the target system, and obtain the characteristic data stream and source address based on the incoming and outgoing data packets; If the characteristic data stream is confirmed to be an abnormal attack behavior, then an attack type and alarm event are generated based on the characteristic data stream; The number of times the same type of alarm is triggered is obtained based on the attack type, the alarm event, and the source address, and the attack strength is obtained based on the number of times the same type of alarm is triggered and the characteristic data stream. The attack scenario type is determined based on the attack intensity and the cluster resource status. If the attack scenario is confirmed to be of low intensity, a large-scale low-interaction honeypot scheduling strategy and an immediate recycling lifecycle strategy are generated, and a honeypot scheduling strategy is obtained based on the large-scale low-interaction honeypot scheduling strategy and the immediate recycling lifecycle strategy; otherwise, it is determined whether the attack scenario is of medium intensity. If the attack scenario is confirmed to be of medium intensity, a honeypot scheduling strategy and a delayed destruction lifecycle strategy proportional to the attack intensity are generated, and a honeypot scheduling strategy is obtained based on the attack intensity-proportional medium interaction honeypot scheduling strategy and the delayed destruction lifecycle strategy; otherwise, a small number of high interaction honeypot scheduling strategies and a long retention lifecycle strategy are generated, and a honeypot scheduling strategy is obtained based on the small number of high interaction honeypot scheduling strategies and the long retention lifecycle strategy. Honeypots are deployed on the target system based on the honeypot scheduling strategy.

[0007] When the aforementioned scheme detects abnormal attack behavior in the feature data stream, it generates attack types and alarm events based on the feature data stream. It then uses the attack type, alarm events, and source address to obtain the number of times similar alarms are triggered. This trigger count, combined with the feature data stream, yields the attack intensity, quantifying the current attack activity level. Subsequently, based on the attack intensity and cluster resource status, it obtains the attack scenario type, reflecting the current attack situation and schedulable resources. When the attack scenario type is low-intensity, indicating a relatively small attack threat or an intermittent attack, it generates a large-scale low-interaction honeypot scheduling strategy to indicate the deployment of numerous honeypots with low interaction depth, and also generates an immediate lifecycle recycling strategy to indicate... Immediate recovery is performed on honeypots, allowing them to quickly release their occupied resources after successfully trapping the attackers. If the attack scenario is of medium intensity, a honeypot scheduling strategy proportional to the attack intensity is generated to instruct the deployment of a number of honeypots with moderate interaction depth proportional to the attack intensity. A delayed destruction lifecycle strategy is also generated to instruct the honeypots to be destroyed later, so that they are retained for a period of time after the attack subsides before releasing their resources. Otherwise, if the attack scenario is of high intensity, a small number of high-interaction honeypot scheduling strategies are generated to instruct the deployment of a small number of honeypots with high interaction depth. A long-term retention lifecycle strategy is also generated to instruct the honeypots to be retained for a long time to cope with continuous high-intensity attacks. As can be seen, this solution can generate differentiated honeypot scheduling strategies based on attack intensity and cluster resource status. This allows the number of honeypots deployed, the depth of interaction, and the lifespan to be adjusted according to the attack situation and the availability of schedulable resources. When the attack enters its peak and exhibits high intensity, configuring high-interaction honeypots that are retained for a long time can ensure that the system has sufficient depth trapping capabilities. When the attack is in a low-intensity interval and exhibits low intensity, configuring a large number of low-interaction honeypots that can be reclaimed in a timely manner can release redundant honeypot resources in a timely manner, thereby improving the overall honeypot trapping efficiency.

[0008] Further, the process involves acquiring the incoming and outgoing data packets and cluster resource status captured by each working node of the target system, and obtaining characteristic data streams and source addresses based on the incoming and outgoing data packets. This includes: acquiring the incoming and outgoing data packets captured by each working node of the target system, the number of available CPU cores, the amount of memory remaining, and the network bandwidth occupancy rate; obtaining the percentage of available cluster resources based on the number of available CPU cores, the amount of memory remaining, and the network bandwidth occupancy rate, and using the percentage of available cluster resources as the cluster resource status; and obtaining characteristic data streams and source addresses based on the incoming and outgoing data packets.

[0009] The above scheme captures incoming and outgoing data packets from each working node of the target system, and simultaneously collects the number of available CPU cores, the amount of remaining memory, and the network bandwidth utilization. The number of available CPU cores reflects the current available computing power of the node, the amount of remaining memory reflects the available storage space, and the network bandwidth utilization reflects the network transmission capacity. Based on the combination of the number of available CPU cores, the amount of remaining memory, and the network bandwidth utilization, a cluster available resource ratio is obtained that can accurately quantify the sufficiency of the overall schedulable resources of the current system. This cluster available resource ratio is used as the cluster resource status, so that when the cluster available resources are poor under the same attack intensity, the attack scenario type will be judged as higher intensity. This results in a honeypot scheduling strategy that matches the actual schedulable resource situation of the system. It can reserve key resources for deep trapping when resources are scarce during the peak of the attack, and release redundant honeypots in a timely manner when resources are abundant during the attack interval, thereby improving the overall technical effect of honeypot trapping efficiency.

[0010] Furthermore, the step of obtaining the feature data stream and source address based on the incoming and outgoing data packets includes: performing multi-layer parsing to extract the source address and structured features based on the incoming and outgoing data packets; performing batch aggregation based on the structured features to obtain denoised and deduplicated features; and normalizing the denoised and deduplicated features to obtain the feature data stream.

[0011] The above scheme first performs multi-layer parsing on the captured inbound and outbound data packets to extract structured features and source addresses from different protocol layers of the data packets. The source address is used to identify the source of the attack traffic. The extracted structured features are then batch-aggregated to eliminate redundant and noisy data caused by network retransmission, data packet fragmentation, or repeated collection, resulting in denoised and deduplicated features. This reduces the number of similar alarm triggers caused by data duplication. Subsequently, the denoised and deduplicated features are normalized to obtain a feature data stream, which ensures high consistency across the feature dimensions. When this feature data stream is used to generate attack strength and attack scenario types, the obtained attack strength can more accurately reflect the actual attack activity level, thus making the resulting honeypot scheduling strategy more suitable for the actual attack situation and improving the overall honeypot trapping efficiency.

[0012] Furthermore, the step of confirming that the characteristic data stream is an abnormal attack behavior and then generating an attack type and alarm event based on the characteristic data stream includes: acquiring historical normal traffic data and extracting normal traffic features based on the historical normal traffic data; clustering the normal traffic features to generate several normal traffic cluster centers and acquiring the distance between the characteristic data stream and the several normal traffic cluster centers; confirming that the distance exceeds a preset abnormal threshold, then confirming that the characteristic data stream is an abnormal attack behavior and generating an attack type and alarm event based on the characteristic data stream.

[0013] The above scheme first acquires historical normal traffic data to extract normal traffic features. These features are then clustered to generate several normal traffic cluster centers. These cluster centers reflect the distribution of multi-dimensional features of normal traffic. The distance between the obtained feature data stream and these cluster centers measures the degree of deviation between the current feature data stream and the normal traffic features. If this distance exceeds a preset anomaly threshold, it indicates a significant deviation between the current feature data stream and the distribution of all normal traffic clusters, thus confirming that the feature data stream represents an abnormal attack. Therefore, compared to traditional schemes that determine whether a special data stream represents an abnormal attack based on a fixed standard distribution, this scheme can obtain several normal traffic cluster centers adapted to the dynamic changes in the target system's normal traffic based on historical normal traffic data. This results in a more accurate distance measurement of deviation, reducing ineffective honeypot deployments due to misjudgments of abnormal attacks and improving overall honeypot trapping efficiency.

[0014] Further, the step of obtaining the number of similar alarm triggers based on the attack type, the alarm event, and the source address, and obtaining the attack strength based on the number of similar alarm triggers and the feature data stream, includes: performing sliding window processing based on the attack type, the source address, and the alarm event to obtain the number of similar alarm triggers; obtaining the connection frequency and data packet rate from the feature data stream, and generating the frequency of similar attacks based on the number of similar alarm triggers, the connection frequency, and the data packet rate; and obtaining the attack strength based on the frequency of similar attacks.

[0015] The above scheme uses a sliding window approach based on attack type, source address, and alarm events to count similar alarm events within a continuous time window to obtain the number of times the same type of alarm is triggered. From the feature data stream, it obtains the connection frequency reflecting the density of the current attack behavior and the data packet rate reflecting the transmission strength of the current attack behavior. Then, it generates the frequency of similar attacks based on the number of similar alarm triggers, connection frequency, and data packet rate. Subsequently, it obtains the attack strength reflecting the activity level of the attack behavior based on the frequency of similar attacks, so that the resulting honeypot scheduling strategy is adapted to the actual attack situation and improves the honeypot trapping efficiency.

[0016] Furthermore, the honeypot deployment on the target system based on the honeypot scheduling strategy includes: obtaining a matching honeypot image from a preset honeypot strategy library based on the honeypot scheduling strategy; obtaining the honeypot image name, number of replicas, and resource quota corresponding to the matching honeypot image; creating a honeypot container based on the honeypot image name, number of replicas, and resource quota; and deploying the honeypot container on the target system.

[0017] The above scheme is based on a honeypot scheduling strategy. It obtains a matching honeypot image adapted to the current attack scenario from a preset honeypot strategy library. It then acquires the honeypot image name, number of replicas, and resource quota corresponding to this matching image. The number of replicas determines the number of honeypot container instances deployed, and the resource quota determines the upper limit of computing and storage resources available to each honeypot container instance. Based on the honeypot image name, number of replicas, and resource quota, a honeypot container is created and deployed on the target system. During peak attack periods, when the honeypot scheduling strategy instructs the deployment of high-interaction honeypots with a smaller number of replicas, the scheme can match and obtain a matching honeypot image from the honeypot strategy library, creating and deploying honeypot containers with fewer replicas and increased resource quotas, ensuring the system has sufficient trapping capabilities during peak attack periods. During attack intervals, when the honeypot scheduling strategy instructs immediate recycling or delayed destruction, the scheme can match and obtain a matching honeypot image from the honeypot strategy library, creating and deploying honeypot containers with more replicas and reduced resource quotas, allowing redundant resources to be released promptly and improving honeypot trapping efficiency.

[0018] Furthermore, after deploying the honeypot on the target system based on the honeypot scheduling strategy, the process further includes: obtaining the total number of CPU cores used and the total memory usage of the honeypot container; obtaining the cluster resource utilization rate based on the total number of CPU cores used and the total memory usage; obtaining the input commands, uploaded files, and behavioral trajectories captured by the honeypot container; reconstructing the complete attack operation path based on the input commands, uploaded files, and behavioral trajectories; generating threat intelligence based on the complete attack operation path; extracting the attack capture success rate, attack persistence time, and threat intelligence value score from the threat intelligence; and calculating the cluster resource utilization rate and the attack capture success rate based on the attack persistence time and the total memory usage. A reward value is obtained based on the success rate, the attack persistence time, and the threat intelligence value score; clustering accuracy evaluation samples are obtained based on the alarm events, and attack type samples are obtained based on the clustering accuracy evaluation samples; real attack type samples corresponding to the clustering accuracy evaluation samples are obtained, and clustering accuracy is obtained based on the real attack type samples and the attack type samples; if the clustering accuracy and the attack capture success rate are confirmed to meet the preset optimization conditions, then the honeypot strategy library is optimized based on the reward value, the clustering accuracy, and the attack capture success rate to obtain an optimized honeypot strategy library, and the honeypot strategy library is updated based on the optimized honeypot strategy library.

[0019] After the honeypot container is deployed, the above scheme obtains the total number of CPU cores used and the total memory usage of the honeypot container to obtain the cluster resource utilization rate, which quantifies the cluster resource cost consumed by the current honeypot. It also obtains the input commands, uploaded files, and behavioral trajectories captured during the honeypot container's operation to reconstruct the complete attack operation path and generate threat intelligence. From the threat intelligence, it extracts the attack capture success rate, attack dwell time, and threat intelligence value score. The attack capture success rate reflects the proportion of attacks that the honeypot can completely record; the attack dwell time reflects the depth of the attacker's residence in the honeypot; and the threat intelligence value score reflects the usable value of the obtained intelligence. Based on the cluster resource utilization rate, attack capture success rate, attack dwell time, and threat intelligence value score, a reward value is obtained to measure the balance between resource consumption costs and the benefits of capturing intelligence. This solution obtains clustering accuracy evaluation samples based on alarm events, extracts attack type samples from these samples, and obtains the actual attack type samples corresponding to the clustering accuracy evaluation samples. The two are compared to obtain the clustering accuracy rate, which verifies the accuracy of the attack type determination. When the clustering accuracy rate and the attack capture success rate meet the preset optimization conditions, it indicates that the honeypot scheduling strategy obtained this time needs to be optimized and improved. The honeypot strategy library is then optimized based on the reward value, clustering accuracy rate, and attack capture success rate, so that when the honeypot deployment method is executed subsequently, the obtained matching honeypot image is more suitable for the actual working conditions of the target system, thus improving the overall honeypot trapping efficiency.

[0020] This invention also provides a honeypot deployment system for implementing a honeypot deployment method as described in any of the preceding claims, comprising: a data acquisition and processing module for acquiring incoming and outgoing data packets and cluster resource status captured by each working node of the target system, and acquiring characteristic data streams and source addresses based on the incoming and outgoing data packets; an attack perception and analysis module for confirming that the characteristic data stream is an abnormal attack behavior, and generating an attack type and alarm event based on the characteristic data stream; an attack strength acquisition module for acquiring the number of similar alarm triggers based on the attack type, the alarm event, and the source address, and obtaining the attack strength based on the number of similar alarm triggers and the characteristic data stream; an attack scenario type acquisition module for obtaining the attack scenario type based on the attack strength and the cluster resource status; and a low-intensity policy confirmation module for confirming that the attack scenario type is low-intensity. If the attack scenario type is determined to be of medium intensity, a large-scale low-interaction honeypot scheduling strategy and an immediate lifecycle recovery strategy are generated, and a honeypot scheduling strategy is obtained based on the large-scale low-interaction honeypot scheduling strategy and the immediate lifecycle recovery strategy. Otherwise, it is determined whether the attack scenario type is medium intensity. If the attack scenario type is confirmed to be medium intensity, a medium-intensity strategy confirmation module generates a medium-interaction honeypot scheduling strategy proportional to the attack intensity and a delayed destruction lifecycle strategy, and obtains a honeypot scheduling strategy based on the medium-interaction honeypot scheduling strategy proportional to the attack intensity and the delayed destruction lifecycle strategy. Otherwise, a small number of high-interaction honeypot scheduling strategies and long-term retention lifecycle strategies are generated, and a honeypot scheduling strategy is obtained based on the small number of high-interaction honeypot scheduling strategies and the long-term retention lifecycle strategy. A honeypot deployment module is used to deploy honeypots on the target system based on the honeypot scheduling strategy.

[0021] The present invention also provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, it implements a honeypot deployment method as described in any of the preceding claims.

[0022] The present invention also provides a computer-readable storage medium, comprising: a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform a honeypot deployment method as described in any of the preceding claims.

[0023] When the aforementioned scheme detects abnormal attack behavior in the feature data stream, it generates attack types and alarm events based on the feature data stream. It then uses the attack type, alarm events, and source address to obtain the number of times similar alarms are triggered. This trigger count, combined with the feature data stream, yields the attack intensity, quantifying the current attack activity level. Subsequently, based on the attack intensity and cluster resource status, it obtains the attack scenario type, reflecting the current attack situation and available resources. When the attack scenario type is low-intensity, it generates a large-scale low-interaction honeypot scheduling strategy to indicate the deployment of numerous honeypots with low interaction depth, and generates an immediate lifecycle recovery strategy to instruct the immediate recovery of honeypots. This allows honeypots to quickly release their occupied resources after successfully trapping an attacker. If the attack scenario is of medium intensity, a honeypot scheduling strategy proportional to the attack intensity is generated to instruct the deployment of a number of honeypots with moderate interaction depth proportional to the attack intensity. A delayed destruction lifecycle strategy is also generated to instruct the honeypots to be destroyed later, so that the honeypots are retained for a period of time after the attack subsides before releasing their resources. Otherwise, if the attack scenario is of high intensity, a honeypot scheduling strategy with a small number of high-interaction honeypots is generated to instruct the deployment of a small number of honeypots with high interaction depth. A long-term retention lifecycle strategy is also generated to instruct the honeypots to be retained for a long time to cope with continuous high-intensity attacks.

[0024] As can be seen, this solution can adapt to honeypot scheduling strategies that vary depending on the attack intensity and cluster resource status. This allows the number of honeypots deployed, the depth of interaction, and the lifespan to be adjusted according to the attack situation and available resources. During peak attack periods, when the attack intensity is high, configuring high-interaction honeypots that are retained for a long time can ensure sufficient depth of trapping capabilities. During attack intervals, when the attack intensity is low, configuring a large number of low-interaction honeypots that can be reclaimed in a timely manner can release redundant honeypot resources, thereby improving the overall honeypot trapping efficiency. Attached Figure Description

[0025] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the embodiments will be briefly described below; the process steps, system modules and text labels in the drawings have been described in corresponding text in the specific embodiments.

[0026] Figure 1 This is a flowchart illustrating the technical implementation of a honeypot deployment method according to an embodiment of the present invention. Figure 2 This is a schematic diagram of a honeypot deployment system architecture provided in an embodiment of the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0029] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0030] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0031] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0032] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0033] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0034] Please see Figure 1 This embodiment provides a honeypot deployment method, including the following steps: Step S1: Obtain the incoming and outgoing data packets and cluster resource status captured by each working node of the target system, and obtain the characteristic data stream and source address based on the incoming and outgoing data packets; Step S2: If the feature data stream is confirmed to be an abnormal attack behavior, then an attack type and alarm event are generated based on the feature data stream; Step S3: Obtain the number of times the same type of alarm is triggered based on the attack type, the alarm event, and the source address, and obtain the attack strength based on the number of times the same type of alarm is triggered and the feature data stream; Step S4: Determine the attack scenario type based on the attack intensity and the cluster resource status; Step S5: If the attack scenario type is confirmed to be low intensity, a large-scale low-interaction honeypot scheduling strategy and an immediate recycling lifecycle strategy are generated, and a honeypot scheduling strategy is obtained based on the large-scale low-interaction honeypot scheduling strategy and the immediate recycling lifecycle strategy; otherwise, it is determined whether the attack scenario type is medium intensity. Step S6: If the attack scenario type is confirmed to be of medium intensity, a honeypot scheduling strategy with equal attack intensity and a delayed destruction lifecycle strategy are generated, and a honeypot scheduling strategy is obtained based on the equal attack intensity and the delayed destruction lifecycle strategy; otherwise, a small number of high-interaction honeypot scheduling strategies and a long-term retention lifecycle strategy are generated, and a honeypot scheduling strategy is obtained based on the small number of high-interaction honeypot scheduling strategies and the long-term retention lifecycle strategy. Step S7: Deploy honeypots on the target system based on the honeypot scheduling strategy.

[0035] In the above embodiments, when the characteristic data stream indicates abnormal attack behavior, attack types and alarm events are generated based on the characteristic data stream. The number of similar alarm triggers is obtained using the attack type, alarm events, and source address. This trigger count is combined with the characteristic data stream to obtain the attack intensity, which quantifies the current attack activity level. Subsequently, based on the attack intensity and cluster resource status, an attack scenario type reflecting the current attack situation and schedulable resources is obtained. When the attack scenario type is low intensity, indicating a relatively small attack threat or an intermittent attack, a large-scale low-interaction honeypot scheduling strategy is generated to indicate the deployment of a large number of honeypots with low interaction depth. An immediate lifecycle recycling strategy is also generated to indicate... The system demonstrates the immediate recycling of honeypots, ensuring they quickly release their resources after successfully trapping the attackers. If the attack scenario is of medium intensity, a honeypot scheduling strategy proportional to the attack intensity is generated to instruct the deployment of a number of honeypots with moderate interaction depth proportional to the attack intensity. A delayed destruction lifecycle strategy is also generated to instruct the honeypots to be destroyed later, allowing them to remain for a period of time after the attack subsides before releasing their resources. Otherwise, if the attack scenario is of high intensity, a small-scale high-interaction honeypot scheduling strategy is generated to instruct the deployment of a small number of honeypots with high interaction depth. A long-term retention lifecycle strategy is also generated to instruct the honeypots to be retained for a long period to cope with continuous high-intensity attacks. As can be seen, this embodiment can generate differentiated honeypot scheduling strategies based on attack intensity and cluster resource status, so that the number of honeypots deployed, interaction depth and life cycle will be adjusted according to the attack situation and the availability of schedulable resources. When the attack enters the peak period and is characterized by high intensity, configuring high-interaction honeypots that are retained for a long time can ensure that the system has sufficient depth trapping capability. When the attack interval is characterized by low intensity, configuring a large number of low-interaction honeypots that can be recycled in time can release redundant honeypot resources in a timely manner, thereby improving the overall honeypot trapping efficiency.

[0036] It should be noted that honeypots are categorized into three types based on their interaction level: low-interaction honeypots, medium-interaction honeypots, and high-interaction honeypots. The interaction type of a honeypot is determined by the service it simulates and the depth of interaction it can provide. The number of CPU cores and the amount of memory are used to characterize the resource quota of the corresponding honeypot instance. To avoid gaps in resource quotas, resource quotas are determined in the order of high, medium, and low: a honeypot with a CPU quota greater than or equal to 1 core or a memory quota greater than or equal to 1GB is identified as a high resource quota; a honeypot that does not meet the high resource quota criteria but has a CPU quota greater than 0.1 cores or a memory quota greater than 128MB is identified as a medium resource quota; and the rest are identified as low resource quotas.

[0037] Among them, low-interaction honeypots, such as Honeytrap, which simulate service port responses and simple protocol handshakes without providing a real operating system or a complete service stack, are recommended to use the low resource quotas mentioned above.

[0038] Among them, the interactive honeypots, such as Cowrie and Conpot, simulate complete application layer protocol interactions and provide pseudo terminals, pseudo file systems, or simulated industrial control equipment responses. The resource quotas mentioned above are recommended.

[0039] Among them, high-interaction honeypots, such as containerized images of a complete operating system, run a real OS and service stack and provide full interactive capabilities, and are recommended to use the high resource quotas mentioned above.

[0040] In one embodiment, the target system deploys traffic monitoring probes on each node of the Kubernetes cluster and captures incoming and outgoing data packets in real time through eBPF (Extended Berkeley Packet Filter) or mirrored ports, and obtains the cluster resource status of each worker node in real time through the Kubernetes Metrics Server.

[0041] In one embodiment, after obtaining the incoming and outgoing data packets and cluster resource status captured by each working node of the target system, characteristic data streams and source addresses are obtained based on the incoming and outgoing data packets. If the characteristic data stream is determined to be an abnormal attack behavior, an attack type and alarm event are generated based on the characteristic data stream. The number of similar alarm triggers is obtained based on the attack type, the alarm event, and the source address, and the attack intensity is obtained based on the number of similar alarm triggers and the characteristic data stream. The attack intensity can be divided into three levels: low, medium, and high.

[0042] In one embodiment, the attack scenario type is obtained based on the attack intensity and cluster resource status. The attack scenario type can be divided into three categories: low intensity, medium intensity, and high intensity.

[0043] If the attack scenario is of low intensity, indicating a low-intensity attack scenario such as large-scale scanning or port sniffing, a large-scale low-interaction honeypot scheduling strategy and an immediate lifecycle recycling strategy are generated, resulting in a honeypot scheduling strategy. The target system is configured according to this honeypot scheduling strategy, creating a large number of low-interaction honeypot containers, but limiting the creation to a maximum of 100 per instance. A large number of concurrent low-interaction honeypots form a decoy network, consuming the attacker's scanning resources and protecting real assets. An immediate recycling mechanism is employed, triggering immediate scaling down and destroying redundant honeypot instances when attack traffic falls below a preset minimum threshold (e.g., 10 connections / minute) for 5 consecutive minutes, retaining only a small number of basic honeypot containers (e.g., 1-2 basic honeypot containers for continued monitoring).

[0044] As can be seen, when the attack scenario is of low intensity, this embodiment can cope with large-scale, sudden low-intensity attacks such as scanning attacks with extremely low resource cost, achieve adaptive resource consumption peaks and troughs, and avoid the problem of honeypots in traditional solutions occupying resources for a long time even without attacks.

[0045] If the attack scenario is classified as medium-intensity, it indicates a medium-intensity attack scenario such as brute-force attacks or protocol vulnerability detection. The attack intensity is proportional to the honeypot scheduling strategy and the delayed destruction lifecycle strategy to obtain the honeypot scheduling strategy. The target system is configured according to this honeypot scheduling strategy. It matches the service mapping in the honeypot strategy library with the attack target port and creates honeypot containers proportional to the attack intensity. The default ratio of attack intensity to the number of honeypot containers created is 1:5, meaning that one honeypot container is created every 5 attack alerts. This allows for on-demand scaling for medium-intensity threats. A delayed destruction mechanism is also employed: after the attack activity ceases, the honeypot containers remain in operation for a default silent window of 30 minutes to capture potential subsequent probes or variant attacks. After the silent window expires and the attack ceases, the capacity is gradually reduced to the base number.

[0046] As can be seen, when the attack scenario is of medium intensity, this embodiment can respond to medium intensity attacks in a timely manner, and also retain enough time to collect the attacker's subsequent behavior, thereby improving the completeness of the attack chain reconstruction. Furthermore, by scaling the honeypot container proportionally to the attack intensity, it can avoid the situation of over-allocating resources.

[0047] It should be noted that the above attack chain reconstruction is achieved by analyzing the attacker's behavior logs in the honeypot to reconstruct their attack steps, tool usage, and intent, thereby generating high-value threat intelligence.

[0048] If the attack scenario type is high-intensity, it indicates that the current attack is scheduled for high-intensity, high-threat scenarios such as APT penetration and zero-day exploitation. This attack scenario type can only be classified as high-intensity when the cluster resource status reflects that the available cluster resources are greater than 30%. Under this high-intensity attack scenario type, the target system is allowed to create no more than 5 honeypot containers at a time to avoid exhausting cluster resources. At this time, a small number of high-interaction honeypot scheduling policies and long-term retention lifecycle policies are generated to obtain the honeypot scheduling policy. The target system configures itself according to this honeypot scheduling policy and adopts a long-term retention mechanism. After the attack session ends, the honeypot container is not immediately destroyed but retained until the default 24-hour silent window expires to capture subsequent deep attacks such as lateral movement and privilege escalation by the attacker. Resources are automatically reclaimed after the retention period expires, and if a new high-risk attack is detected during the retention period, the silent timer can be reset.

[0049] As can be seen, when the attack scenario is of high intensity, this embodiment can collect high-value threat intelligence to the greatest extent and implement strict resource control to ensure the overall stability of the honeypot cluster.

[0050] The target system in the above embodiment deploys traffic monitoring probes on each worker node of the Kubernetes cluster to capture incoming and outgoing data packets in real time via eBPF or mirrored ports. Simultaneously, it uses the Kubernetes Metrics Server to obtain the number of available CPU cores, remaining memory, and network bandwidth utilization of each worker node in real time, summarizing these data to obtain the cluster resource status. When the characteristic data stream extracted from the incoming and outgoing data packets is determined to be an abnormal attack, the system generates a corresponding attack type and alarm event, and counts the number of similar alarm triggers based on the attack type, alarm event, and source address. This number of similar alarm triggers, combined with indicators such as connection frequency and data packet rate in the characteristic data stream, yields a quantified attack intensity classified into low, medium, and high levels. Subsequently, the attack intensity is combined with the cluster resource status to determine the attack scenario type, which is categorized into low, medium, and high intensity. This attack scenario type determination process considers the severity of the attack threat and the current schedulable resources of the target system, providing an accurate judgment benchmark for subsequent differentiated scheduling.

[0051] The above embodiments configure differentiated honeypot scheduling strategies for the three attack scenarios, including honeypot interaction depth, deployment quantity, and lifecycle policies, so that the investment of honeypot resources matches the attack threat level.

[0052] In determining high-intensity attack scenarios, the above embodiments set a precondition that the available cluster resources are greater than 30%. This constraint ensures that the target system will not consume cluster resources indefinitely when facing high-intensity attacks, but will strictly limit the expansion of the decoy capability to within the target system's tolerance range. Furthermore, when the available cluster resources are below 30%, even if the attack intensity reaches a high level, it will not be classified as a high-intensity attack scenario, thus avoiding the depletion of cluster resources due to excessive deployment of high-interaction honeypots and ensuring the overall stability of the honeypot cluster. It is evident that the above embodiments improve the decoy capability not by piling up resources, but by expanding it under the premise of ensuring stable system operation.

[0053] When the attack scenario is of low intensity, indicating a low-intensity attack such as large-scale scanning or port sniffing, a large-scale low-interaction honeypot scheduling strategy and an immediate lifecycle recycling strategy are generated. In the above embodiment, the target system, according to the honeypot scheduling strategy configuration, will create a large number of low-interaction honeypot containers, with a single creation limit of 100. This large number of concurrent low-interaction honeypots form a decoy network, consuming the attacker's scanning resources and protecting real assets. Furthermore, the low-interaction honeypots only simulate service port responses and simple protocol handshakes, without providing a real operating system or complete service stack; the resource consumption of a single instance does not exceed 0.1 CPU cores or 128MB of memory. The honeypot configuration of the above embodiment, setting up a large number of concurrent low-interaction honeypots to form a decoy network, enables the target system to achieve widespread decoy capture with extremely low resource costs when facing large-scale scanning attacks. Furthermore, the target system continuously monitors attack traffic. When the attack traffic falls below the preset minimum threshold for 5 consecutive minutes, it immediately triggers scaling down, destroys redundant honeypot containers, and retains only a small number of basic honeypot containers to maintain monitoring. This instant recycling mechanism ensures that honeypot resources will not be idle for a long time after the attack subsides, but will be released quickly after the attack traffic is confirmed to have subsided. This achieves adaptive adjustment of resource usage peaks and troughs, avoiding the drawback of traditional solutions where honeypots occupy resources for a long time even without attacks.

[0054] When the attack scenario is classified as medium intensity, it indicates a medium-intensity attack scenario such as brute-force attacks or protocol vulnerability detection. In this case, a honeypot scheduling policy proportional to the attack intensity and a delayed destruction lifecycle policy are generated. Configured according to the generated honeypot scheduling policy, the target system will match the service mapping in the honeypot policy library with the attack target port and create honeypot containers proportionally to the attack intensity. The default ratio is one honeypot container created every five attack alerts, enabling on-demand scaling for medium threats. The medium-intensity honeypot simulates complete application-layer protocol interactions, providing pseudo-terminals, pseudo-file systems, or simulated industrial control equipment responses. A single instance consumes 0.2 to 0.5 CPU cores or 256 to 512 MB of memory. In this embodiment, the proportional scaling mechanism correlates the number of honeypots deployed with the attack activity level; the more active the attack, the more resources are invested in trapping; as the attack subsides, the deployment scale decreases accordingly, achieving a dynamic balance between trapping capability and resource consumption. Furthermore, after the attack activity ceases, the honeypot containers retain their contents for 30 minutes within the default silent window to capture any subsequent probes or variant attacks. Once the silent window expires and the attack ceases, the system gradually shrinks back to its base size. This delayed destruction mechanism ensures sufficient decoy windows to capture subsequent attacks during peak attack periods, improving the completeness of attack chain reconstruction. Furthermore, it releases resources gradually after the attack has completely subsided, preventing prolonged resource occupation.

[0055] When the attack scenario is classified as high-intensity, it indicates a high-intensity, high-threat attack scenario such as APT penetration or zero-day exploitation. Assuming the cluster's available resources are greater than 30%, a small number of high-interaction honeypot scheduling policies and long-term retention lifecycle policies are generated. Configured according to these generated honeypot scheduling policies, the target system will create no more than 5 high-interaction honeypot containers at a time to avoid exhausting cluster resources. The high-interaction honeypots run a real operating system and service stack, providing full interaction capabilities. Each instance consumes more than 1 CPU core or 1GB of memory. Although the deployment number is strictly limited, each high-interaction honeypot possesses deep interaction capabilities, fully recording the attacker's lateral movement, privilege escalation, and other deep-level behaviors, providing rich raw data for threat intelligence generation. Furthermore, the target system will not immediately destroy the honeypot containers after the attack ends, but will retain them until the default 24-hour silent window expires to fully capture subsequent deep-level attack behaviors. If a new high-risk attack is detected during the retention period, the silent timer can be reset to further extend the observation window, and resources will be automatically reclaimed after the retention period expires. The above-described embodiment employs a strategy of exchanging a small number of high-quality honeypots for deep trapping capabilities and long-term retention for complete attack chain information. This strategy enables the target system to collect high-value threat intelligence to the greatest extent possible under high-intensity attack scenarios. At the same time, through strict control of the maximum number of replicas, it ensures that the honeypot cluster will not affect the overall stability due to excessive resource consumption.

[0056] In summary, the above embodiments ensure sufficient depth of honeypot capture capabilities during the peak of attacks, when they are characterized by high intensity. Simultaneously, threshold constraints on cluster resource status and upper limits on the number of replicas ensure that the expansion of capture capabilities does not jeopardize system stability. When the attack transitions from peak to intermittent periods, the system switches from long-term retention of high-interaction honeypots to delayed destruction of medium-interaction honeypots or immediate recycling of low-interaction honeypots. The honeypot interaction depth decreases progressively, and the deployment quantity is first reduced proportionally and then released in batches, resulting in a gradual decrease in resource consumption. Therefore, the mechanism described in this embodiment, which dynamically adjusts the number of honeypots deployed, their interaction depth, and their lifespan based on the attack situation, allows the target system to concentrate resources to ensure capture depth during peak attack periods and quickly release redundant resources during attack intermittent periods, thereby improving overall honeypot capture efficiency.

[0057] Further, the process involves acquiring the incoming and outgoing data packets and cluster resource status captured by each working node of the target system, and obtaining characteristic data streams and source addresses based on the incoming and outgoing data packets. This includes: acquiring the incoming and outgoing data packets captured by each working node of the target system, the number of available CPU cores, the amount of memory remaining, and the network bandwidth occupancy rate; obtaining the percentage of available cluster resources based on the number of available CPU cores, the amount of memory remaining, and the network bandwidth occupancy rate, and using the percentage of available cluster resources as the cluster resource status; and obtaining characteristic data streams and source addresses based on the incoming and outgoing data packets.

[0058] The above embodiments capture incoming and outgoing data packets from each working node of the target system, and simultaneously collect the number of available CPU cores, remaining memory, and network bandwidth utilization. The number of available CPU cores reflects the current available computing power of the node, the remaining memory reflects the available storage space, and the network bandwidth utilization reflects the network transmission capacity. Based on the comprehensive analysis of the number of available CPU cores, remaining memory, and network bandwidth utilization, a cluster available resource ratio is obtained that can accurately quantify the overall schedulable resource availability of the current system. This cluster available resource ratio is used as the cluster resource status, so that when the cluster available resource ratio is poor under the same attack intensity, the attack scenario type is tended to be classified as higher intensity. This results in a honeypot scheduling strategy that matches the actual schedulable resource situation of the system. It can reserve key resources for deep trapping during peak attack periods when resources are scarce, and release redundant honeypots in a timely manner during attack intervals when resources are abundant, thereby improving the overall technical effect of honeypot trapping efficiency.

[0059] Furthermore, the step of obtaining the feature data stream and source address based on the incoming and outgoing data packets includes: performing multi-layer parsing to extract the source address and structured features based on the incoming and outgoing data packets; performing batch aggregation based on the structured features to obtain denoised and deduplicated features; and normalizing the denoised and deduplicated features to obtain the feature data stream.

[0060] The above embodiments first perform multi-layer parsing on the captured inbound and outbound data packets to extract structured features and source addresses from different protocol layers of the data packets. The source address is used to identify the source of the attack traffic. The extracted structured features are then batch-aggregated to eliminate redundant and noisy data caused by network retransmission, data packet fragmentation, or repeated collection, resulting in denoised and deduplicated features. This reduces the number of similar alarm triggers caused by data duplication. Subsequently, the denoised and deduplicated features are normalized to obtain a feature data stream, which ensures high consistency across the feature dimensions. When this feature data stream is used to generate attack strength and attack scenario types, the obtained attack strength can more accurately reflect the actual attack activity level, thus making the resulting honeypot scheduling strategy more suitable for the actual attack situation and improving the overall honeypot trapping efficiency.

[0061] In one embodiment, the target system deploys traffic monitoring probes on each node of the Kubernetes cluster and captures incoming and outgoing data packets in real time via eBPF or mirrored ports. It also obtains the number of available CPU cores, remaining memory, and network bandwidth utilization of each worker node in real time through the Kubernetes Metrics Server, and summarizes them as the percentage of available cluster resources as the cluster available resource ratio. The cluster available resource ratio is then used as the cluster resource status.

[0062] The above embodiments perform multi-layer parsing on the captured inbound and outbound data packets based on the network layer, transport layer, and application layer, extracting features such as source address, protocol type, port number, data packet size, request frequency, and payload digest, forming a structured feature vector as a structured feature. Each dimension of this structured feature is the feature value to be processed, including protocol type encoding, source address, port number, data packet size, request frequency, and payload digest hash value.

[0063] Subsequently, based on the above structured features, a sliding time window is used to batch aggregate its feature vectors, filtering out duplicate packets and noisy traffic to obtain denoised and deduplicated features; then the denoised and deduplicated features are normalized so that all feature dimensions of the denoised and deduplicated features are in the same dimension and the same order of magnitude, to obtain the feature data stream.

[0064] In one embodiment, the above normalization process specifically involves: for denoising and deduplicating features, such as continuous features that approximately follow a normal distribution, like packet size and request frequency, Z-Score standardization is used to convert them into a standard distribution with a mean of 0 and a standard deviation of 1; for denoising and deduplicating features, such as port numbers with clearly defined value boundaries, Min-Max standardization is used to linearly map them to the [0,1] interval. Furthermore, the comparability evaluation criterion for the normalization results is that the standard deviation of each feature dimension after normalization approaches 1 or the range is 1, to ensure that subsequent processing of feature data will not be biased due to differences in units.

[0065] Furthermore, the step of confirming that the characteristic data stream is an abnormal attack behavior and then generating an attack type and alarm event based on the characteristic data stream includes: acquiring historical normal traffic data and extracting normal traffic features based on the historical normal traffic data; clustering the normal traffic features to generate several normal traffic cluster centers and acquiring the distance between the characteristic data stream and the several normal traffic cluster centers; confirming that the distance exceeds a preset abnormal threshold, then confirming that the characteristic data stream is an abnormal attack behavior and generating an attack type and alarm event based on the characteristic data stream.

[0066] The above embodiment first acquires historical normal traffic data to extract normal traffic features, then clusters these features to generate several normal traffic cluster centers. These cluster centers reflect the distribution of multi-dimensional features of normal traffic, allowing the distance between the obtained feature data stream and these cluster centers to measure the degree of deviation between the current feature data stream and the normal traffic features. In this embodiment, if the distance exceeds a preset anomaly threshold, it indicates a significant deviation between the current feature data stream and the distribution of all normal traffic clusters, thus confirming that the feature data stream represents an abnormal attack. Therefore, compared to traditional methods that determine whether a special data stream represents an abnormal attack based on a fixed standard distribution, this embodiment can obtain several normal traffic cluster centers adapted to the dynamic changes in the target system's normal traffic based on historical normal traffic data. This results in higher accuracy in measuring the degree of deviation, thereby reducing invalid honeypot deployments due to misjudgments of abnormal attacks and improving overall honeypot trapping efficiency.

[0067] In one embodiment, normal traffic features are extracted from historical normal traffic data, and the normal traffic features are clustered offline using the standard k-means algorithm to generate initial k normal traffic cluster centers. These k normal traffic cluster centers are then loaded into a dynamic cluster model library in memory.

[0068] Preferably, the k-means algorithm uses an incremental streaming k-means algorithm.

[0069] Subsequently, the above embodiments obtain the feature vector of the feature data stream and the Euclidean distance between it and the center of each normal traffic cluster in memory based on the feature data stream. If the distance is within a preset normal threshold, it indicates that the feature data stream belongs to one of the k normal traffic clusters. Then, the center position of the normal traffic cluster is updated incrementally to realize the real-time update of the dynamic cluster model, which can adapt to the normal drift of the target system's captured traffic.

[0070] If the distance exceeds a preset abnormal threshold, the characteristic data stream is determined to be an abnormal attack behavior. Based on the characteristic distribution of the characteristic data stream, attack types such as scanning, brute-force attacks, vulnerability exploitation, and APT penetration are identified, and a standard structured alarm event containing information such as attack type, source address, target port, and threat level is generated.

[0071] In one embodiment, abnormal data points of the feature data stream that are determined to be abnormal attack behavior can be temporarily cached. When the number of subsequent consecutive abnormal data points of the same type reaches a preset clustering threshold, a new cluster model is established in memory for the new attack type, thereby realizing rapid perception and adaptive learning of new attacks.

[0072] Further, the step of obtaining the number of similar alarm triggers based on the attack type, the alarm event, and the source address, and obtaining the attack strength based on the number of similar alarm triggers and the feature data stream, includes: performing sliding window processing based on the attack type, the source address, and the alarm event to obtain the number of similar alarm triggers; obtaining the connection frequency and data packet rate from the feature data stream, and generating the frequency of similar attacks based on the number of similar alarm triggers, the connection frequency, and the data packet rate; and obtaining the attack strength based on the frequency of similar attacks.

[0073] The above embodiments employ sliding window processing based on attack type, source address, and alarm events to count similar alarm events within a continuous time window, thereby obtaining the number of times similar alarms are triggered. From the feature data stream, the connection frequency reflecting the density of current attack behavior and the data packet rate reflecting the transmission strength of current attack behavior are obtained. Then, based on the number of similar alarm triggers, connection frequency, and data packet rate, the frequency of similar attacks is generated. Subsequently, based on the frequency of similar attacks, the attack strength reflecting the activity level of attack behavior is obtained, making the resulting honeypot scheduling strategy adaptable to the actual attack situation and improving the honeypot trapping efficiency.

[0074] Furthermore, the honeypot deployment on the target system based on the honeypot scheduling strategy includes: obtaining a matching honeypot image from a preset honeypot strategy library based on the honeypot scheduling strategy; obtaining the honeypot image name, number of replicas, and resource quota corresponding to the matching honeypot image; creating a honeypot container based on the honeypot image name, number of replicas, and resource quota; and deploying the honeypot container on the target system.

[0075] The above embodiments, based on honeypot scheduling strategies, obtain matching honeypot images adapted to the current attack scenario from a preset honeypot strategy library. They acquire the honeypot image name, number of replicas, and resource quota corresponding to the matching honeypot image. The number of replicas determines the number of honeypot container instances deployed, and the resource quota determines the upper limit of computing and storage resources available to each honeypot container instance. Honeypot containers are created based on the honeypot image name, number of replicas, and resource quota, and then deployed to the target system. During peak attack periods, when the honeypot scheduling strategy instructs the deployment of high-interaction honeypots with a smaller number of replicas, the above embodiments can match and obtain matching honeypot images from the honeypot strategy library, creating and deploying honeypot containers with fewer replicas and increased resource quotas, ensuring the system has sufficient trapping capabilities during peak attack periods. During attack intervals, when the honeypot scheduling strategy instructs immediate recycling or delayed destruction, it can match and obtain matching honeypot images from the honeypot strategy library, creating and deploying honeypot containers with more replicas and reduced resource quotas, allowing redundant resources to be released promptly and improving honeypot trapping efficiency.

[0076] In one embodiment, the preset honeypot policy library includes multiple preset honeypot policies. Each preset honeypot policy includes policy matching conditions and a honeypot image corresponding to the policy matching conditions. The policy matching conditions include at least one of attack scenario type, honeypot interaction level, and lifecycle policy. The honeypot scheduling policy is matched with the policy matching conditions of each preset honeypot policy, and the honeypot image corresponding to the preset honeypot policy with the highest matching degree is determined as the matched honeypot image.

[0077] In one embodiment, the honeypot policy library is specifically a mapping relationship between attack types such as scanning, brute-force attacks, vulnerability exploitation, and APT penetration, target service ports, and high-risk vulnerability numbers such as CVE numbers, stored in the form of structured data tables, and recommended honeypot images such as Cowrie, Dionaea, and Conpot. The recommended honeypot image records include parameters such as honeypot interaction level, default resource quota, recommended replica number range, and lifecycle policy.

[0078] The honeypot strategy library described in the above embodiments can automatically expand its mapping entries based on the latest vulnerability information pushed by the Threat Intelligence Platform (TIP), or can be manually configured by security operations personnel to add new honeypot templates.

[0079] In one embodiment, based on the obtained honeypot scheduling policy, the honeypot image name, number of replicas, and resource quota corresponding to the matching honeypot image with the highest matching degree are obtained from the preset honeypot policy library. The Kubernetes API is called to pull the specified honeypot image from the central image repository, create the corresponding number of honeypot container Pods, allocate independent network namespaces and service ports to each honeypot container Pod and deploy it on the target system, and create HPA (Horizontal Pod Autoscaler) resource objects and set an elastic scaling policy with attack traffic QPS (Queries Per Second) and CPU utilization as dual indicators.

[0080] In one embodiment, the target system also dynamically configures NetworkPolicy or firewall rules to transparently direct attack traffic to the honeypot container. After the attack ends, traffic is continuously monitored. If the number of attack connections remains below a preset threshold for a period exceeding a preset silent window, scaling down is triggered according to the honeypot scheduling policy. Scaling down gradually destroys the honeypot container and releases computing resources.

[0081] It should be noted that various open-source or self-developed honeypots, such as Cowrie (simulating SSH - Secure Shell), Conpot (simulating industrial control systems), and Dionaea (simulating web vulnerabilities), as well as their runtime dependencies, will be packaged into Docker images and pushed to central image repositories such as Harbor and Docker Hub. When each honeypot is started, it immediately listens on a designated service port, simulates a real service, and interacts with attackers. During operation, each honeypot runs with non-root user privileges and is configured with a read-only root file system and container resource limits to prevent attackers from breaching the honeypot and moving laterally. Furthermore, each honeypot records all interaction details and reports logs and packet capture data in real time to a centralized log center via a container log driver or a sidecar process for subsequent analysis and forensics.

[0082] Furthermore, after deploying the honeypot on the target system based on the honeypot scheduling strategy, the process further includes: obtaining the total number of CPU cores used and the total memory usage of the honeypot container; obtaining the cluster resource utilization rate based on the total number of CPU cores used and the total memory usage; obtaining the input commands, uploaded files, and behavioral trajectories captured by the honeypot container; reconstructing the complete attack operation path based on the input commands, uploaded files, and behavioral trajectories; generating threat intelligence based on the complete attack operation path; extracting the attack capture success rate, attack persistence time, and threat intelligence value score from the threat intelligence; and calculating the cluster resource utilization rate and the attack capture success rate based on the attack persistence time and the total memory usage. A reward value is obtained based on the success rate, the attack persistence time, and the threat intelligence value score; clustering accuracy evaluation samples are obtained based on the alarm events, and attack type samples are obtained based on the clustering accuracy evaluation samples; real attack type samples corresponding to the clustering accuracy evaluation samples are obtained, and clustering accuracy is obtained based on the real attack type samples and the attack type samples; if the clustering accuracy and the attack capture success rate are confirmed to meet the preset optimization conditions, then the honeypot strategy library is optimized based on the reward value, the clustering accuracy, and the attack capture success rate to obtain an optimized honeypot strategy library, and the honeypot strategy library is updated based on the optimized honeypot strategy library.

[0083] In the above embodiments, after the honeypot container is deployed, the total number of CPU cores used and the total memory usage of the honeypot container are obtained to obtain the cluster resource utilization rate, which quantifies the cluster resource cost consumed by the current honeypot. Furthermore, the input commands, uploaded files, and behavioral trajectories captured during the honeypot container's operation are obtained to reconstruct the complete attack operation path and generate threat intelligence. From the threat intelligence, attack capture success rate, attack dwell time, and threat intelligence value score are extracted. The attack capture success rate reflects the proportion of attacks that the honeypot can completely record; the attack dwell time reflects the depth of the attacker's residence in the honeypot; and the threat intelligence value score reflects the usable value of the obtained intelligence. Based on the cluster resource utilization rate, attack capture success rate, attack dwell time, and threat intelligence value score, a reward value is obtained to measure the balance between resource consumption costs and the benefits of capturing intelligence. This embodiment obtains cluster accuracy evaluation samples based on alarm events, extracts attack type samples from them, and obtains the actual attack type samples corresponding to the cluster accuracy evaluation samples. The two are compared to obtain the cluster accuracy rate to verify the accuracy of the attack type determination. When the cluster accuracy rate and the attack capture success rate meet the preset optimization conditions, it indicates that the honeypot scheduling strategy obtained this time needs to be optimized and improved. The honeypot strategy library is then optimized based on the reward value, cluster accuracy rate, and attack capture success rate, so that when the honeypot deployment method is executed subsequently, the obtained matching honeypot image is more suitable for the actual working conditions of the target system, thus improving the overall honeypot trapping efficiency.

[0084] In one embodiment, after the target system deploys a honeypot according to a honeypot scheduling strategy and the honeypot starts, it begins to simulate real service interactions with the attacker, capturing input commands, uploaded files, and behavioral trajectories. The raw logs generated from these input commands, uploaded files, and behavioral trajectories are parsed and feature extracted to obtain behavioral events containing timestamps, session identifiers, behavior types, and operation objects. The behavioral events are grouped according to the session identifiers and sorted by timestamps. Based on the temporal relationship between behavioral events within the same group, and the correlation between input commands, uploaded files, and behavioral trajectories, directed associations are established between the behavioral events to obtain a directed behavioral event graph. Starting from the initial behavioral event, the graph is traversed sequentially along the directed associations to the final behavioral event to obtain the complete attack operation path. Threat intelligence, including attack stages, tool characteristics, and behavioral patterns, is generated based on the complete attack operation path. In this embodiment, the process of grouping, sorting, associating, and traversing behavioral events to reconstruct the complete attack operation path is called attack chain reconstruction processing.

[0085] Furthermore, through the Kubernetes Metrics Server, the total number of CPU cores used and the total memory usage of all honeypot containers are obtained. The CPU usage ratio is obtained based on the total number of CPU cores used and the total number of CPU cores in the cluster, and the memory usage ratio is obtained based on the total memory usage and the total amount of memory. The above CPU usage ratio and memory usage ratio can be weighted by default 0.5, and the weighted average is used to obtain the percentage of cluster resources currently occupied by the honeypot system, which is the cluster resource utilization rate. The value of the cluster resource utilization rate directly reflects the resource cost of maintaining the current honeypot defense. The higher the cost rate, the heavier the penalty, thereby prompting us to save resources as much as possible while ensuring the trapping effect.

[0086] In one embodiment, the attack capture success rate, attack dwell time, and threat intelligence value score are extracted from the threat intelligence. Specifically, the attack capture success rate is obtained by the ratio of the number of events in which the honeypot successfully records the complete attack chain to the total number of alarm events. The attack dwell time is obtained by the duration of the attacker's interaction in the honeypot. The threat intelligence value score is obtained by the security analyst's manual annotation of the intelligence quality, and its score ranges from 1 to 10.

[0087] In one embodiment, the attack duration is normalized to obtain a normalized value of the attack duration, and the threat intelligence value score is normalized to obtain a normalized value of the threat intelligence value score.

[0088] The reward value is then calculated based on the cluster resource utilization rate, the attack capture success rate, the normalized value of the attack dwell time, and the normalized value of the threat intelligence value score. The reward value is obtained using the following formula: Reward value R = w1 × Attack capture success rate + w2 × Normalized value of attack dwell time + w3 × Normalized value of threat intelligence value score - w4 × Cluster resource utilization rate, where w1 is the weight parameter corresponding to the attack capture success rate, w2 is the weight parameter corresponding to the normalized value of the attack dwell time, w3 is the weight parameter corresponding to the normalized value of the threat intelligence value score, and w4 is the weight parameter corresponding to the cluster resource utilization rate. The weight parameters w1, w2, w3, and w4 corresponding to the cluster resource utilization rate can all be adjusted according to actual attack and defense needs.

[0089] In one embodiment, clustering accuracy evaluation samples are obtained based on the aforementioned alarm events. The attack type corresponding to each clustering enhancement evaluation sample is taken as the attack type sample, and the real attack type corresponding to each clustering accuracy evaluation sample is taken as the real attack type sample. Based on the comparison between the real attack type sample and the attack type sample, the proportion of the number of samples with accurate attack type classification to the total number of sampled clustering accuracy evaluation samples is determined, and the clustering accuracy rate is obtained.

[0090] In one embodiment, it is confirmed that the clustering accuracy and the attack capture success rate meet preset optimization conditions. Specifically, the preset optimization conditions are: if the clustering accuracy is lower than 90% or the attack capture success rate is lower than 80%. When the preset optimization conditions are met, it is determined that the scheduling strategy of the current honeypot strategy library needs further optimization. Parameters such as the matching weight of the honeypot strategy library, the attack intensity level classification threshold, the default ratio of honeypots at each interaction level, and the lifecycle silent window duration are adjusted using a reinforcement learning model.

[0091] Furthermore, the completion criteria for optimizing the honeypot strategy library are: each cycle is 24 hours, and within two consecutive evaluation cycles, the clustering accuracy recovers to over 90% and the attack capture success rate recovers to over 80%, or the reward value no longer increases significantly.

[0092] In one embodiment, the reinforcement learning optimization honeypot policy library can be implemented using a deep Q-network algorithm. Historical state transition samples are stored using an experience replay mechanism, the Q-value loss function is calculated periodically, and the neural network parameters are updated through gradient descent, enabling the system to gradually learn the optimal scheduling strategy.

[0093] Please see Figure 2 This embodiment also provides a honeypot deployment system for implementing any of the above honeypot deployment methods, including: The data acquisition and processing module is used to acquire the incoming and outgoing data packets and cluster resource status captured by each working node of the target system, and to acquire the characteristic data stream and source address based on the incoming and outgoing data packets; The attack perception and analysis module is used to confirm that the feature data stream is an abnormal attack behavior, and then generate an attack type and alarm event based on the feature data stream; The attack strength acquisition module is used to obtain the number of times the same type of alarm is triggered based on the attack type, the alarm event, and the source address, and to obtain the attack strength based on the number of times the same type of alarm is triggered and the feature data stream; An attack scenario type acquisition module is used to obtain the attack scenario type based on the attack intensity and the cluster resource status. The low-intensity strategy confirmation module is used to confirm that the attack scenario type is low-intensity, and then generate a large-scale low-interaction honeypot scheduling strategy and an immediate recycling lifecycle strategy, and obtain a honeypot scheduling strategy based on the large-scale low-interaction honeypot scheduling strategy and the immediate recycling lifecycle strategy; otherwise, it determines whether the attack scenario type is medium-intensity. The medium-to-high intensity strategy confirmation module confirms that the attack scenario type is medium intensity. If it does, it generates a medium-interaction honeypot scheduling strategy proportional to the attack intensity and a delayed destruction lifecycle strategy. Based on the medium-interaction honeypot scheduling strategy proportional to the attack intensity and the delayed destruction lifecycle strategy, it obtains a honeypot scheduling strategy. Otherwise, it generates a small number of high-interaction honeypot scheduling strategies and a long-term retention lifecycle strategy. Based on the small number of high-interaction honeypot scheduling strategies and the long-term retention lifecycle strategy, it obtains a honeypot scheduling strategy. The honeypot deployment module is used to deploy honeypots on the target system based on the honeypot scheduling strategy.

[0094] It is understood that the above system item embodiments correspond to the method item embodiments of the present invention, and can implement the honeypot deployment method provided by any of the above method item embodiments of the present invention.

[0095] It should be noted that the system embodiments described above are merely illustrative, and some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0096] The present invention also provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, it implements any of the honeypot deployment methods described above.

[0097] The terminal device may be a desktop computer, laptop, handheld computer, or cloud server, etc. The terminal device may include, but is not limited to, a processor and a memory.

[0098] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the terminal device, connecting all parts of the terminal device via various interfaces and lines.

[0099] The present invention also provides a computer-readable storage medium, comprising: a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform any of the honeypot deployment methods described above.

[0100] In the above embodiments, when the feature data stream indicates abnormal attack behavior, attack types and alarm events are generated based on the feature data stream. The number of similar alarm triggers is obtained using the attack type, alarm events, and source address. This number of triggers is combined with the feature data stream to obtain the attack intensity, which quantifies the current attack activity level. Subsequently, based on the attack intensity and cluster resource status, an attack scenario type reflecting the current attack situation and schedulable resources is obtained. When the attack scenario type is low intensity, a large-scale low-interaction honeypot scheduling strategy is generated to indicate the deployment of a large number of honeypots with low interaction depth, and an immediate recycling lifecycle strategy is generated to indicate the immediate recycling of honeypots. This allows honeypots to quickly release their occupied resources after successfully trapping an attacker. If the attack scenario is of medium intensity, a honeypot scheduling strategy proportional to the attack intensity is generated to instruct the deployment of a number of honeypots with moderate interaction depth proportional to the attack intensity. A delayed destruction lifecycle strategy is also generated to instruct the honeypots to be destroyed later, so that the honeypots are retained for a period of time after the attack subsides before releasing their resources. Otherwise, if the attack scenario is of high intensity, a honeypot scheduling strategy with a small number of high-interaction honeypots is generated to instruct the deployment of a small number of honeypots with high interaction depth. A long-term retention lifecycle strategy is also generated to instruct the honeypots to be retained for a long time to cope with continuous high-intensity attacks.

[0101] As can be seen, this embodiment can adapt to honeypot scheduling strategies that generate differences based on attack intensity and cluster resource status. This allows the number of honeypots deployed, the depth of interaction, and the lifecycle to be adjusted according to the attack situation and the availability of schedulable resources. During peak attack periods when the attack intensity is high, configuring high-interaction honeypots that are retained for a long time can easily ensure sufficient depth of trapping capabilities. During attack intervals when the attack intensity is low, configuring a large number of low-interaction honeypots that can be reclaimed in a timely manner can release redundant honeypot resources in a timely manner, thereby improving the overall honeypot trapping efficiency.

[0102] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A honeypot deployment method, characterized in that, Includes the following steps: Obtain the incoming and outgoing data packets and cluster resource status captured by each working node of the target system, and obtain the characteristic data stream and source address based on the incoming and outgoing data packets; If the characteristic data stream is confirmed to be an abnormal attack behavior, then an attack type and alarm event are generated based on the characteristic data stream; The number of times the same type of alarm is triggered is obtained based on the attack type, the alarm event, and the source address, and the attack strength is obtained based on the number of times the same type of alarm is triggered and the characteristic data stream. The attack scenario type is determined based on the attack intensity and the cluster resource status. If the attack scenario is confirmed to be of low intensity, a large-scale low-interaction honeypot scheduling strategy and an immediate recycling lifecycle strategy are generated, and a honeypot scheduling strategy is obtained based on the large-scale low-interaction honeypot scheduling strategy and the immediate recycling lifecycle strategy; otherwise, it is determined whether the attack scenario is of medium intensity. If the attack scenario is confirmed to be of medium intensity, a honeypot scheduling strategy and a delayed destruction lifecycle strategy proportional to the attack intensity are generated, and a honeypot scheduling strategy is obtained based on the attack intensity-proportional medium interaction honeypot scheduling strategy and the delayed destruction lifecycle strategy; otherwise, a small number of high interaction honeypot scheduling strategies and a long retention lifecycle strategy are generated, and a honeypot scheduling strategy is obtained based on the small number of high interaction honeypot scheduling strategies and the long retention lifecycle strategy. Honeypots are deployed on the target system based on the honeypot scheduling strategy.

2. The honeypot deployment method as described in claim 1, characterized in that, The process of acquiring the incoming and outgoing data packets and cluster resource status captured by each working node of the target system, and obtaining the characteristic data stream and source address based on the incoming and outgoing data packets, includes: Obtain the incoming and outgoing data packets, available CPU cores, remaining memory, and network bandwidth occupancy captured by each working node of the target system; The available cluster resource percentage is obtained based on the number of available CPU cores, the remaining memory, and the network bandwidth occupancy, and the available cluster resource percentage is used as the cluster resource status. Based on the incoming and outgoing data packets, obtain the characteristic data stream and source address.

3. The honeypot deployment method as described in claim 2, characterized in that, The step of obtaining the characteristic data stream and source address based on the incoming and outgoing data packets includes: Based on the incoming and outgoing data packets, multi-level parsing is performed to extract source addresses and structured features; Based on the structured features, batch aggregation is performed to obtain denoised and deduplicated features, and the denoised and deduplicated features are normalized to obtain a feature data stream.

4. A honeypot deployment method as described in any one of claims 1 to 3, characterized in that, If the characteristic data stream is confirmed to be an abnormal attack behavior, then an attack type and alarm event are generated based on the characteristic data stream, including: Obtain historical normal traffic data, and extract normal traffic features based on the historical normal traffic data; Cluster the normal traffic features to generate several normal traffic cluster centers, and obtain the distance between the feature data stream and several normal traffic cluster centers; If the distance exceeds a preset abnormal threshold, the feature data stream is confirmed to be an abnormal attack behavior, and an attack type and alarm event are generated based on the feature data stream.

5. A honeypot deployment method as described in claim 4, characterized in that, The step of obtaining the number of similar alarm triggers based on the attack type, the alarm event, and the source address, and obtaining the attack strength based on the number of similar alarm triggers and the characteristic data stream, includes: A sliding window process is used based on the attack type, the source address, and the alarm event to obtain the number of times the same type of alarm is triggered. The connection frequency and data packet rate are obtained from the characteristic data stream, and the frequency of similar attacks is generated based on the number of similar alarm triggers, the connection frequency and the data packet rate. The attack strength is determined based on the frequency of similar attacks.

6. A honeypot deployment method as described in claim 1, characterized in that, The honeypot deployment on the target system based on the honeypot scheduling strategy includes: Based on the honeypot scheduling strategy, a matching honeypot image is obtained from a preset honeypot strategy library; Obtain the honeypot image name, number of replicas, and resource quota corresponding to the matched honeypot image; Create a honeypot container based on the honeypot image name, number of replicas, and resource quota; Deploy the honeypot container on the target system.

7. A honeypot deployment method as described in claim 6, characterized in that, After the honeypot is deployed on the target system based on the honeypot scheduling strategy, the process also includes: Obtain the total number of CPU cores used and the total memory usage of the honeypot container, and calculate the cluster resource utilization rate based on the total number of CPU cores used and the total memory usage; Obtain the input commands, uploaded files, and behavioral trajectories captured by the honeypot container; Based on the input command, the uploaded file, and the behavioral trajectory, the complete attack operation path is reconstructed, and threat intelligence is generated based on the complete attack operation path; The attack capture success rate, attack persistence time, and threat intelligence value score are extracted from the threat intelligence, and a reward value is obtained based on the cluster resource utilization rate, the attack capture success rate, the attack persistence time, and the threat intelligence value score. Based on the alarm events, obtain clustering accuracy evaluation samples, and based on the clustering accuracy evaluation samples, obtain attack type samples; Obtain the actual attack type samples corresponding to the clustering accuracy evaluation samples, and obtain the clustering accuracy based on the actual attack type samples and the attack type samples; If the clustering accuracy and the attack capture success rate are confirmed to meet the preset optimization conditions, then the honeypot strategy library is optimized based on the reward value, the clustering accuracy and the attack capture success rate to obtain an optimized honeypot strategy library, and the honeypot strategy library is updated based on the optimized honeypot strategy library.

8. A honeypot deployment system, characterized in that, A honeypot deployment method as described in any one of claims 1 to 7, comprising: The data acquisition and processing module is used to acquire the incoming and outgoing data packets and cluster resource status captured by each working node of the target system, and to acquire the characteristic data stream and source address based on the incoming and outgoing data packets; The attack perception and analysis module is used to confirm that the feature data stream is an abnormal attack behavior, and then generate an attack type and alarm event based on the feature data stream; The attack strength acquisition module is used to obtain the number of times the same type of alarm is triggered based on the attack type, the alarm event, and the source address, and to obtain the attack strength based on the number of times the same type of alarm is triggered and the feature data stream; An attack scenario type acquisition module is used to obtain the attack scenario type based on the attack intensity and the cluster resource status. The low-intensity strategy confirmation module is used to confirm that the attack scenario type is low-intensity, and then generate a large-scale low-interaction honeypot scheduling strategy and an immediate recycling lifecycle strategy, and obtain a honeypot scheduling strategy based on the large-scale low-interaction honeypot scheduling strategy and the immediate recycling lifecycle strategy; otherwise, it determines whether the attack scenario type is medium-intensity. The medium-to-high intensity strategy confirmation module confirms that the attack scenario type is medium intensity. If it does, it generates a medium-interaction honeypot scheduling strategy proportional to the attack intensity and a delayed destruction lifecycle strategy. Based on the medium-interaction honeypot scheduling strategy proportional to the attack intensity and the delayed destruction lifecycle strategy, it obtains a honeypot scheduling strategy. Otherwise, it generates a small number of high-interaction honeypot scheduling strategies and a long-term retention lifecycle strategy. Based on the small number of high-interaction honeypot scheduling strategies and the long-term retention lifecycle strategy, it obtains a honeypot scheduling strategy. The honeypot deployment module is used to deploy honeypots on the target system based on the honeypot scheduling strategy.

9. A terminal device, characterized in that, The device includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, it implements a honeypot deployment method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, include: A stored computer program, wherein, when the computer program is executed, it controls the device containing the computer-readable storage medium to perform a honeypot deployment method as described in any one of claims 1 to 7.

Images