An intelligent threat perception method and system fusing honeynet and honeypot

Abstract

The application provides a kind of intelligent threat perception method and system of fusing honeycomb and honeypot, it is related to threat perception technical field.The method provided by the application comprises: effective threat perception request set is returned to corresponding terminal equipment, at least one is selected from the returned set as a threat perception request to be executed and is re-submitted to server, the first time information and the second time information are calculated for each threat perception request to be executed, the window adaptability is verified according to the comparison result of the first time information and the second time information, according to the first time information and the second time information verification result, the deception capture task corresponding to target network domain coordinates is arranged to the task list selected position of selected honeypot / honeycomb node, and is issued to execute.The application calculates the link ready time and the node exposure time, effectively avoids the data loss problem caused by the delay of acquisition link, and supports automatic rearrangement and fallback strategy, improves the reliability and data integrity of deployment.

Description

Technical Field

[0001] This invention relates to the field of threat perception technology, and in particular to an intelligent threat perception method and system that integrates honeynets and honeypots. Background Technology

[0002] As cyberattack techniques become increasingly complex and covert, traditional passive defense methods based on signature recognition are no longer effective against advanced persistent threats (APTs) and zero-day attacks. To compensate for the shortcomings of traditional defense systems, proactive deception defense technology has gradually been applied. Its core idea is to deploy fake assets and services (i.e., honeypots and honeynets) to lure attackers, thereby obtaining attack intelligence, delaying the attack process, and enriching threat perception data.

[0003] However, existing technologies suffer from the following drawbacks: insufficient decision-making flexibility, typically employing static or semi-static algorithms for task selection and resource allocation, resulting in a closed decision-making process that fails to incorporate the professional judgment of security operators regarding dynamic factors such as real-time threat landscape, business priorities, and resource availability; and imprecise deployment timing management, where nodes are prematurely exposed before the data collection chain is ready, potentially leading to the loss of attack interaction data, compromising the integrity of attack chain evidence, and significantly reducing the effectiveness of subsequent analysis, tracing, and forensics, ultimately lowering the success rate of threat perception and the reliability of the acquired data. Therefore, a solution is urgently needed to address these issues. Summary of the Invention

[0004] The purpose of this invention is to provide an intelligent threat perception method and system that integrates honeynets and honeypots, which can improve the problems of insufficient decision-making flexibility and inaccurate timing management in existing technologies.

[0005] In a first aspect, the present invention provides an intelligent threat perception method that integrates honeynets and honeypots, comprising:

[0006] Receive threat perception and control requests sent by terminal devices; preprocess the threat perception and control requests to obtain a standardized request set;

[0007] For each request in the standardized request set, the availability coverage of its corresponding target honeypot or honeynet node is calculated. If the coverage is valid, the request is marked as a valid threat awareness request and returned to the corresponding terminal device. The terminal device selects at least one of the returned valid threat awareness requests as a threat awareness request to be executed and resubmits it to the server. If the coverage is invalid, the request is marked as an invalid threat awareness request and the reason for failure is recorded.

[0008] The server calculates first-time information and second-time information for the resubmitted threat awareness request; the first-time information represents the earliest time point when the telemetry data of the target honeypot or honeynet node can be collected and implemented, and the second-time information represents the time point when the target honeypot or honeynet node can be exposed to the outside world in the target network domain and is expected to be reached.

[0009] The window adaptability is verified based on the comparison results between the information at the first moment and the information at the second moment; based on the verification results, the deception capture task corresponding to the target network domain coordinates is arranged into the task list of the selected honeypot or honeynet node and sent for execution.

[0010] This invention provides an intelligent threat perception method that integrates honeynets and honeypots. By calculating the readiness time of the data collection link and the exposure time of the node, it forces the data collection to be completed before the node is exposed, effectively avoiding data loss caused by data collection link delays. It also supports automatic reordering and rollback strategies, thereby improving deployment reliability and data integrity.

[0011] Optionally, the threat awareness control request includes the target network domain scope or target asset scope, the type and profile of deception to be enabled, and the decoy nodes to be engaged.

[0012] Optionally, the preprocessing of the threat awareness and control request includes deduplication and signature verification parameter normalization; wherein, the deduplication includes generating a unique hash key based on the key parameters of the threat awareness and control request for deduplication, the key parameters including the target network domain range or target asset range, the deception type master identifier, the core system fingerprint features, and the MD5 digest of the decoy node set; the signature verification is based on an asymmetric encryption algorithm to verify the request signature; the parameter normalization converts the heterogeneous original request parameters into a unified internal data structure.

[0013] Optionally, when calculating the availability coverage area, the following dimensions are comprehensively evaluated: topology reachability, traffic traction or mirroring capability, protocol profile matching degree, resource quota and concurrent usage, and compliance whitelist; when all evaluated dimensions are met, the coverage is determined to be met.

[0014] Optionally, when the terminal device selects at least one of the effective threat perception requests as threat perception requests to be executed, it includes: the terminal device selecting at least one of the effective threat perception requests as threat perception requests to be executed through manual selection or semi-automatic selection based on comprehensive priority; the comprehensive priority is obtained by the server normalizing the threat score, conflict score and window adaptation score to a preset range and then weighting and summing them.

[0015] Optionally, after resubmitting to the server, the server performs convergence control on the resubmitted threat awareness request. The convergence control includes: verifying the identity or authorization of the request source, locking the resource selected by the threat awareness request, and binding the finally confirmed request parameters with the policy execution record.

[0016] Optionally, when calculating the first-moment information and the second-moment information for the threat perception request to be executed, the calculation includes: calculating the first-moment information by comprehensively considering the availability of data pipelines, bandwidth and storage quotas, and the access and resolution readiness of security information and event management systems or data lakes; and calculating the second-moment information by comprehensively considering container or host startup latency, the effective time of border gateway protocols or software-defined networks, the propagation time of the Domain Name System, the fingerprint propagation time, the current scanning heat, and intelligence prediction.

[0017] Optionally, when the information at the first moment is not greater than the information at the second moment, the deception capture task corresponding to the target network domain coordinates is arranged into the task list of the selected honeypot or honeynet node and sent for execution.

[0018] Optionally, the execution includes: locking and isolating resources of the selected honeypot or honeynet node, the resources including IP address, port, certificate, image, and storage volume; configuring the real asset characteristics of the target network domain on the selected honeypot or honeynet node, the real asset characteristics including system fingerprint, service identifier, interaction script, and decoy credentials; deploying and performing health checks on the selected honeypot or honeynet node, including starting the service and deploying probes or proxies to monitor the node status; exposing the selected honeypot or honeynet node to the target network domain and guiding attack traffic to the honeypot based on traffic redirection technology; and transmitting the data collected by the selected honeypot or honeynet node back to the collection domain in real time and triggering corresponding alarm and response processes.

[0019] Secondly, the present invention provides an intelligent threat perception system that integrates honeynets and honeypots, comprising:

[0020] The request processing module is used to receive threat perception and control requests sent by terminal devices; preprocess the threat perception and control requests to obtain a standardized request set;

[0021] The coverage determination module is used to calculate the availability coverage of the corresponding target honeypot or honeynet node for each request in the standardized request set. If the coverage is established, the request is marked as a valid threat awareness request and returned to the corresponding terminal device. The terminal device selects at least one of the returned valid threat awareness requests as a threat awareness request to be executed and resubmits it to the server. If the coverage is not established, the request is marked as an invalid threat awareness request and the reason for failure is recorded.

[0022] The data processing module is used by the server to calculate the first moment information and the second moment information for the resubmitted threat perception request to be executed; the first moment information represents the earliest time point when the telemetry data of the target honeypot or honeynet node can be collected and implemented, and the second moment information represents the time point when the target honeypot or honeynet node can be exposed to the outside world in the target network domain and is expected to be reached.

[0023] The execution and distribution module is used to verify the window adaptability based on the comparison results between the information at the first moment and the information at the second moment; based on the verification results, the deception capture task corresponding to the target network domain coordinates is arranged into the task list of the selected honeypot or honeynet node and distributed for execution. Attached Figure Description

[0024] Figure 1 A flowchart illustrating an intelligent threat perception method integrating honeynets and honeypots, provided as an embodiment of the present invention;

[0025] Figure 2 This is a structural diagram of an intelligent threat perception system that integrates honeynet and honeypot, provided as an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art. The terms "comprising" and similar expressions used herein mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but does not exclude other elements or objects.

[0027] See Figure 1 This invention provides an intelligent threat perception method that integrates honeynets and honeypots, comprising the following steps:

[0028] S1. Receive threat perception and control requests sent by terminal devices; preprocess the threat perception and control requests to obtain a standardized request set;

[0029] S2. For each request in the standardized request set, calculate the availability coverage of its corresponding target honeypot or honeynet node. If the coverage is valid, mark the request as a valid threat awareness request and return it to the corresponding terminal device. The terminal device selects at least one of the returned valid threat awareness requests as a threat awareness request to be executed and resubmits it to the server. If the coverage is invalid, mark the request as an invalid threat awareness request and record the reason for failure.

[0030] S3. The server calculates the first-moment information and the second-moment information for the resubmitted threat perception request to be executed. The first-moment information represents the earliest time point when the telemetry data of the target honeypot or honeynet node can be collected and implemented. The second-moment information represents the time point when the target honeypot or honeynet node can be exposed to the outside world in the target network domain and is expected to be reached.

[0031] S4. Verify the window adaptability based on the comparison results between the information at the first moment and the information at the second moment; based on the verification results, arrange the deception capture task corresponding to the target network domain coordinates into the task list of the selected honeypot or honeynet node and send it down for execution.

[0032] In some embodiments, during step S1, a threat awareness control request is received from a terminal device; when the threat awareness control request is preprocessed to obtain a standardized request set, the server accepts at least one threat awareness control request from the terminal device. After receiving the request, the server performs a preprocessing process including deduplication, signature verification, and parameter normalization to form a standardized request set.

[0033] Specifically, each request must contain at least the following key parameters:

[0034] Target Scope: Defines the deployment boundary for deception defense. This can take the form of a specific IP address range (e.g., 192.168.1.0 / 24), VLAN identifier, specific hostname (e.g., web-server-01), or asset groups divided according to business logic (e.g., core database cluster). If this scope is not explicitly specified in the request, the system can default to covering all monitored assets within the current network topology.

[0035] Spoofing Type and Profile: This specifies the type of spoofing defense to be enabled and its specific characteristics. Types include honeynets (a highly interactive simulation environment used to simulate a complete network subnet) and honeypots (a low- or medium-interaction simulation service, such as a fake SSH service). The profile further defines the simulation details, such as: the specified network protocol (e.g., TCP, UDP) and its port (e.g., 22 / TCP for simulating SSH), protocol version (e.g., TLS 1.2), typical interactive behavior (e.g., an HTTP honeypot returning a "200 OK" response); and the system characteristics of the simulation target, such as the operating system fingerprint (e.g., the TCP / IP stack characteristics of Windows Server 2019), service identifier (e.g., the HTTP service header "Server: Apache / 2.4.41"), hardware information (e.g., the virtual MAC address prefix 00:50:56), and even the list of simulated processes (e.g., the MySQL service process mysqld).

[0036] Decoy Node: Used to specify the node that is expected to carry out the deception task. It can be specified by directly enumerating the specific decoy nodes that have been registered in the network (e.g., the honeypot host with IP 10.0.0.5), or by providing a selection rule and having the system dynamically filter nodes that meet the conditions (e.g., from the decoy pool labeled "Web Server", priority is given to selecting 2 idle nodes that are in the same network segment as the target asset).

[0037] Specifically, the preprocessing process includes:

[0038] Deduplication: To avoid processing requests with identical semantics repeatedly, the system generates a unique hash key (HashKey) for key parameters of the request for deduplication. Specifically, it extracts the target range, deception type main identifier, core system fingerprint features, and summary information of the decoy node set from the request, concatenates these fields into a string, and generates a hash value using a hash algorithm (such as SHA-256). The system queries a time-sensitive deduplication cache (e.g., based on Redis key-value storage with a 5-minute lifespan). If the hash value already exists, the current request is determined to be a duplicate request and discarded; otherwise, the hash value is written to the cache, and the request is allowed to proceed to subsequent processes.

[0039] Signature Verification: To ensure the legitimacy of the request source and the integrity of the transmission process, the system performs digital signature verification on the request based on asymmetric encryption technology. Specifically, the sender's public key identifier (e.g., RSA-PUBKEY-ID:client-001) and digital signature (e.g., Base64 encoded SIG=abc123...) are extracted from the request header. The server queries its local trusted public key store (e.g., a PKI certificate system) based on this identifier to obtain the corresponding public key. Subsequently, the original parameters of the request (excluding the signature field itself) are normalized and sorted (by lexicographical order of field names, e.g., target range first, then spoofing type) and concatenated to form the string to be verified. Finally, the signature is verified using the obtained public key and the specified signature algorithm (e.g., PKCS#1 v1.5 scheme based on RSA and SHA-256). If verification fails, the request is rejected and a security event is recorded; if verification succeeds, the process proceeds to the next step.

[0040] Parameter normalization: To facilitate unified processing by the subsequent strategy engine, the system converts raw request parameters from different terminals and in potentially different formats into a unified standard data structure within the system. This process applies corresponding conversion rules to different fields:

[0041] Target scope normalization: If the input is an IP range (e.g., 10.1.0.0 / 16), it is parsed and validated into the standard CIDR format and its validity is verified (IP validity is checked via inet_pton, and prefixlen is checked to see if it is within the range of 0-32); if the input is a hostname (e.g., db-primary), it is resolved into a specific list of IP addresses (e.g., 192.168.1.10, 192.168.1.11) by querying the internal DNS or configuration management database (CMDB). If the resolution fails, it is marked as an asset to be confirmed and a manual review process is triggered; if no scope is specified, it is filled according to the default policy (e.g., covering all production environment assets).

[0042] Deception Type and Profile Standardization: Map the deception type described in natural language to predefined enumeration values ​​within the system (e.g., honeypot → DECOY_TYPE_HONEYPOT, high-interaction honeynet → DECOY_TYPE_HONEYNET_HIGH_INTERACTION). Verify whether the protocol (e.g., TCP / UDP) is in the supported list (e.g., only TCP / UDP / ICMP are allowed), and the port range must conform to IANA standards (e.g., 1-65535); if a dynamic port is specified, generate a random list of available ports (selecting n free ports by calling the system API get_unused_ports(n)). Standardize the operating system identifier (e.g., Win2019 → OS_WINDOWS_SERVER_2019), and the protocol response template (e.g., the HTTP Server header is uniformly Apache / 2.4.41 (Ubuntu)) must be loaded from a pre-built fingerprint database (e.g., fingerprint_db.json) to ensure consistency with real device characteristics but still distinguishable (e.g., the initial TCP window size of a honeypot is fixed at 8192, while that of a real device may be dynamically adjusted).

[0043] Decoy node normalization: Verify that the directly specified node ID or IP exists in the currently available decoy resource pool (e.g., query the records with an ACTIVE status in the decoy_nodes database table); if the node is offline (status is MAINTENANCE), it is automatically removed and an alarm is recorded. The policy rules (e.g., for idle nodes in the same network segment) are parsed as follows:

[0044] Extract the IP of the target asset (e.g., 192.168.1.10) and calculate its network segment (e.g., 192.168.1.0 / 24); query the nodes in the decoy pool that are in the IDLE state and whose IPs belong to the same network segment (e.g., 192.168.1.20, 192.168.1.21); filter the number according to the policy requirements (e.g., select 2 nodes), and if there are not enough candidates, downgrade to idle nodes across network segments or trigger a capacity expansion notification. The requests processed in the above way are encapsulated into standardized request objects (e.g., JSON structure {target:192.168.1.0 / 24,decoy_type:HONEYPOT,protocol:{tcp:

[22] ,fingerprint:Apache / 2.4.41},decoys:[10.0.0.5,10.0.0.6]}) and stored in the request queue to wait for further scheduling and execution by the policy engine.

[0045] In some embodiments, when calculating the availability coverage in step S2, the following dimensions are comprehensively evaluated: topology reachability, traffic traction or mirroring capability, protocol profile matching degree, resource quota and concurrent usage, and compliance whitelist; when all evaluated dimensions are met, the coverage is determined to be met.

[0046] Specifically, the server is comprehensively evaluated from the following five dimensions:

[0047] Topology Reachability: Evaluate the network connectivity between the target network domain and candidate honeypot / honeynet nodes. This includes querying internal routing tables (such as the BGP / OSPF routing database) to confirm whether the next hop of the target network points to a network area connected to the honeypot node (e.g., if the next hop of the route for target 192.168.1.0 / 24 is 192.168.0.1, and honeypot 10.0.0.5 is located at 10.0.0.0 / 24, it is necessary to check whether there is a route between 192.168.0.0 / 16 and 10.0.0.0 / 24). If no valid route is found, it is marked as unreachable. Extract the access control policies associated with the target network (such as firewall rule sets and security group configurations), and verify whether outbound traffic to the target asset (source IP ∈ target range, destination IP = honeypot IP, destination port = honeypot listening port) is allowed (e.g., rule ALLOW src=192.168.1.0 / 24dst=10.0.0.5 / 32dport=22proto=tcp exists). If an explicit denial rule exists (e.g., DENY src=192.168.1.0 / 24dst=10.0.0.0 / 24), mark it as an ACL block. Query the current policy tables of the core switch and firewall via SNMP / NetFlow to confirm that no intermediate device drops traffic from the target to the honeypot (e.g., an ACL rule only allows HTTP traffic but the honeypot is listening on an SSH port).

[0048] Traffic redirection or mirroring capability: Assess whether the current network infrastructure can redirect or replicate attack traffic destined for the target asset to the honeypot node. If the request requires direct traffic redirection (e.g., redirecting an SSH connection from target 192.168.1.10:22 to honeypot 10.0.0.5:22), check if the SDN controller or load balancer supports configuring DNAT rules (e.g., iptables-tnat-APREROUTING-s192.168.1.0 / 24-ptcp--dport22-jDNAT--to-destination10.0.0.5:22). If the current network does not support dynamic DNAT (e.g., traditional firewalls lack this feature), mark it as lacking active redirection capability. If the request allows traffic mirroring analysis (e.g., replicating traffic from the target port to the honeypot's listening port), check if the TAP switch or network probe is configured with mirroring rules (e.g., monitorsession1sourceinterfaceGi0 / 1bothdestinationinterfaceGi0 / 24, where Gi0 / 24 connects to the honeypot). If there are no available mirror ports or insufficient mirror bandwidth (e.g., total mirror traffic has reached 90% of the port limit), then it is marked as insufficient mirroring capacity.

[0049] Protocol profile matching: Evaluate the similarity between the protocol stack, service behavior, and system fingerprint simulated by the honeypot / honeynet node and the typical characteristics of real assets in the target network domain. Compare the protocol interaction logic configured in the honeypot (such as TCP handshake delay, HTTP response time) with the typical characteristics of the target assets (extracted from historical traffic logs or asset profile database). For example, if the average response time of the real SSH service in the target network is 200ms, while the honeypot is configured to be 50ms, the matching degree is reduced; if the HTTPServer header returned by the honeypot is Apache / 2.4.41, while the target assets generally use Nginx / 1.18.0, the profile needs to be adjusted or marked as partially mismatched. Calculate the similarity between the honeypot's system fingerprint parameters (such as TCP window size, initial TTL value) and the target asset fingerprint database (such as the production environment Linux server TTL=64 recorded in the CMDB) (using a predefined weight model, such as TTL weight 30%, window size weight 40%). If the overall similarity is below the threshold (such as <80%), it is marked as profile mismatch.

[0050] Resource Quota and Concurrency Consumption: Assess whether candidate honeypot / honeynet nodes have sufficient remaining resources to meet the current request demand. This includes querying the global resource limits of honeypot nodes (e.g., a maximum of 100 concurrent TCP connections per node, and a maximum monthly traffic of 1TB). If the number of concurrent sessions requested (e.g., 50 SSH connections) exceeds the node's remaining quota (e.g., 45 currently used, 5 remaining), it is marked as insufficient concurrent capacity. Real-time monitoring of the node's current resource utilization (e.g., CPU utilization > 80%, memory remaining < 1GB) is also performed. If the threshold is exceeded (e.g., new sessions are rejected when CPU > 90%), it is marked as resource overload.

[0051] Compliance Whitelist: Verify whether this deception defense deployment and its related configuration comply with the compliance policies and security specifications of the target network domain. Check the target network's compliance policy library (e.g., the financial industry prohibits the deployment of honeypots in the core segment of the production network). If the requested target range (e.g., 10.1.1.0 / 24 is the core database network segment) is marked as prohibiting honeypots, then mark it as compliant and prohibited. Confirm whether the IP / domain name of the honeypot node is in the target network's allowed list (e.g., the target asset's firewall only allows connections from 192.168.1.0 / 24, while the honeypot IP is 10.0.0.5). If it is not in the whitelist, then mark it as not included in the whitelist.

[0052] The server integrates the calculation results from all dimensions and performs a logical AND aggregation judgment. Only when all five dimensions are determined to be true is the availability coverage corresponding to the request considered valid. The request is then marked as a valid threat awareness request and returned to the corresponding end device. The end device selects at least one of the returned valid threat awareness requests as a threat awareness request to be executed and resubmits it to the server. If any dimension is not true, the request is marked as an invalid threat awareness request, and a detailed failure reason report is generated (e.g., Invalid reason: There is an ACL rule DENYsrc=192.168.1.0 / 24dst=10.0.0.0 / 24 between the target network 192.168.1.0 / 24 and the honeypot 10.0.0.5).

[0053] In some embodiments, when the terminal device selects at least one valid threat awareness request as a threat awareness request to be executed in step S2, the server, after completing the coverage domain analysis, returns the set of valid threat awareness requests and its analysis report to the terminal device. The terminal device can display this set through a graphical interface or command-line tool, providing decision support for operators. Operators can select one or more requests from the set as items to be executed using one of the following two main modes:

[0054] Manual selection mode: Operators directly review the detailed parameters of each request (such as target scope, honeypot type, node status) and coverage analysis results, and manually select and confirm. This mode balances automation efficiency with human control and is suitable for routine threat awareness tasks (such as batch deployment of honeypots against external network attacks).

[0055] Semi-automatic selection mode: The server calculates a comprehensive priority for each valid request. End devices display requests according to their scores and can provide recommendations to assist operators in making quick decisions. This mode balances automation efficiency with human control and is suitable for routine threat awareness tasks (such as batch deployment of honeypots against external network attacks). To support semi-automatic selection, the server calculates the priority score using a multi-factor evaluation model. This score is mainly determined by the following three dimensions:

[0056] Risk Score: Assessing the potential attack threat level faced by the target network domain. The server calculates the PriorityScore (PS) for each valid request using a multi-factor weighted model. A higher score indicates that the request should be executed with higher priority. Priority calculation is based on the following core dimensions: Quantifying the potential attack threat level faced by the target network domain (higher score, higher priority). Extracting historical attack event data of the target network domain (e.g., number of scans from external IPs in the past 24 hours, number of vulnerability exploitation attempts), obtaining asset value tags for the network segment from the threat intelligence platform (e.g., core database = high-value testing environment = low-value). Combining the severity of the attack type (e.g., RCE vulnerability exploitation = 5 points, port scanning = 1 point), calculating the real-time threat index of the target network (e.g., ... For example, if a network segment suffers 10 SSH brute-force attacks (weight 3 points) and 5 HTTP vulnerability scans (weight 1 point) in the past hour, and its asset value coefficient is 1.5 (core business), then... ;

[0057] ConflictDegree (CD) score: Measures the degree of overlap and competition between the current request and existing or pending requests in the system in terms of resources (such as honeypot nodes, ports) and policies (the lower the conflict, the higher the priority). It checks whether the target network domain is already covered by other valid requests (e.g., multiple requests all targeting 192.168.1.0 / 24). If overlap exists, it calculates shared conflicts of honeypot nodes (e.g., multiple requests competing for the same honeypot's port resources). It assesses the compatibility of the protocol profile with existing services (e.g., the requested simulated SSH service conflicts with the port of an existing real SSH service on the target network). A conflict degree score is generated by combining all conflict dimensions (e.g., ...). The weights can be configured as resource contention 0.6 and policy overlap 0.4. For example, if a request shares the same honeypot node with two other requests (resource contention weight 0.6 × 2 = 1.2), and the protocol port conflicts with the real service (policy overlap weight 0.4 × 1 = 0.4), then... ;

[0058] Window Fit Score (WF): This assesses the degree to which the planned deployment time window matches the network operation and maintenance status (e.g., peak business periods, planned maintenance periods) and the idle time of honeypot nodes (higher fit score results in less execution interference). Check the maintenance plan of the target network domain (e.g., whether it is during peak business periods, whether there are planned network changes). If the requested deployment time (e.g., immediate effect) conflicts with the maintenance window (e.g., the target network segment will restart its firewall in 30 minutes), the fit score is reduced. Consider the idle time of honeypot nodes (e.g., a node has low CPU utilization at night), prioritizing time windows with ample resources. Generate a window fit score (e.g., ...). Off-peak hours have a weight of 0.5, and idle resources have a weight of 0.5. For example, if a request is scheduled to be deployed at 2 AM (off-peak hours have a weight of 0.5), then... Furthermore, the target honeypot node currently has a CPU idle rate of 70% (resource idle weight). ),but .

[0059] Furthermore, after normalizing the above-mentioned dimensional indicators, the server performs a weighted summation according to preset weights to derive a comprehensive priority, i.e. (Note: Conflict level is an inverse indicator, so 1-CD_normalized is used to increase the priority of low-conflict requests.) Based on manual selection or priority suggestions, the terminal device marks one or more of the finally selected requests as threat-aware requests to be executed, and resubmits them to the server through a secure channel (such as an HTTPS POST request to the / submit-execution endpoint).

[0060] In some embodiments, after the request is resubmitted to the server in step S2, the server performs convergence control on the resubmitted threat awareness request. The convergence control includes: verifying the identity or authorization of the request source, locking the resource selected by the threat awareness request, and binding the finally confirmed request parameters with the policy execution record.

[0061] Specifically, terminal devices are required to carry operator identity credentials (such as an administrator token) or policy system signatures (such as digital signatures for SOC automation policies) to ensure that the execution set is authorized. Selected honeypot nodes, target network domains, and other resources are locked (e.g., through a distributed lock mechanism) to prevent other concurrent requests from repeatedly occupying them (e.g., if request A selects honeypot 10.0.0.5, other requests cannot allocate that node until the lock is released). The finally confirmed request parameters (including honeypot type, decoy node, and target range) are bound to the original standardized request to form an immutable policy execution record (for auditing and backtracking).

[0062] In some embodiments, when the server calculates the first-time information and the second-time information for the resubmitted threat awareness request in step S3, the first-time information (T1) represents the earliest time point at which telemetry data of the target honeypot or honeynet node can be collected and stored. Its calculation comprehensively considers data pipeline availability, bandwidth and storage quotas, and the access and resolution readiness status of the Security Information and Event Management (SIEM) system or data lake. The second-time information (T2) represents the time point at which the target honeypot or honeynet node can be exposed to the outside world in the target network domain and is expected to be reached. Its calculation comprehensively considers container or host startup latency, the effective time of network traffic redirection strategies (such as via SDN or BGP), the propagation time of deceptive network identifiers (such as DNS records), and the probability of discovery based on current scanning popularity and threat intelligence predictions.

[0063] Specifically, determining the first-moment information requires comprehensive consideration of multiple key factors. These factors are interrelated, and problems in any link can affect the timely collection and storage of data. The status of the data transmission pipeline must be checked, including whether the network connection is normal and whether the data transmission protocol is available. For example, if data is transmitted from the honeypot node to the data acquisition server via a specific network protocol (such as TCP), it needs to be ensured that the network protocol is working properly in the current network environment, without network interruptions, port congestion, or other issues. Network connectivity and stability can be tested by periodically sending test packets. If the test packets are successfully transmitted and the response time is within a reasonable range, the data pipeline is considered available in this respect. The bandwidth required for data transmission and the remaining quota of the data storage server must be assessed. The available bandwidth for data transmission in the current network environment can be calculated. Real-time bandwidth usage of the network link can be obtained through network monitoring tools, and then the remaining available bandwidth can be calculated. Simultaneously, the storage space of the data storage server must be checked to determine if there is sufficient space to store the telemetry data to be collected. For example, if each honeypot node is expected to generate 1GB of telemetry data per hour, the storage server has 100GB of remaining space, and other data storage tasks are currently occupying 20GB, then 80GB of space is available for new data storage. The approximate storage availability time can be estimated based on the data generation rate. Confirm that the Security Information and Event Management System (SIEM) or data lake has completed its connection configuration with the honeypot nodes and has the ability to parse the telemetry data generated by the honeypots. Check the SIEM / data lake configuration files to ensure that its communication parameters with the honeypot nodes (such as IP address, port number, data format, etc.) are correct. Simultaneously, test whether the data parsing module can correctly parse various types of data generated by the honeypots. For example, for log data, check whether the parsing module can accurately extract key information (such as timestamp, event type, source IP address, etc.). Only when the SIEM / data lake connection configuration is correct and the parsing module is working properly can the telemetry data be effectively collected and stored. Through a comprehensive evaluation of the above factors, determine the earliest time point T1 at which the telemetry data of the target honeypot / honeycomb node can be collected and stored. For example, if the data pipeline needs 10 minutes for initialization and testing, the storage system needs 5 minutes for quota checks and preparation, and SIEM / data lake access and resolution needs 15 minutes for configuration and testing, then T1 is the sum of these three times, i.e., 30 minutes later.

[0064] Specifically, the calculation of second-moment information needs to consider multiple factors related to the network environment and node startup. If the honeypot / honeynet node is deployed as a container or host, the startup time of the container or host needs to be considered. Different container technologies (such as Docker) or host operating systems require different startup times, which are affected by factors such as hardware performance and system configuration. For example, starting a complex honeypot container on a low-configuration server may take 5 minutes, while on a high-configuration server it may only take 2 minutes. By recording the startup logs of the container or host, its startup time can be accurately measured, thereby determining this time latency. If Border Gateway Protocol (BGP) or Software-Defined Networking (SDN) technology is used to implement traffic redirection, the configuration effectiveness time of these technologies needs to be considered. The propagation and convergence of routing information in the BGP protocol takes a certain amount of time, usually ranging from several minutes to tens of minutes, depending on the network size and the configuration of BGP neighbors. The configuration and distribution of SDN controller policies also take a certain amount of time; from the time the configuration takes effect to the time when traffic can be redirected according to the new policy, there may be a delay of several seconds to several minutes. By monitoring BGP routing update information and the policy execution status of the SDN controller, the effective time of BGP / SDN redirection can be determined. Honeypot nodes need to be accessed via DNS resolution within the target network domain, and their system fingerprints (such as IP address, port, service type, etc.) need to propagate across the network so that attackers can discover and identify them. The propagation time of DNS resolution depends on the DNS server configuration and network caching mechanisms, generally taking anywhere from a few minutes to several hours. The propagation of system fingerprints is affected by network topology and information propagation speed, and may take even longer. The propagation time of DNS / fingerprints can be estimated by simulating DNS queries and network probing. The current scanning heat of the target network domain should be considered, i.e., the frequency and focus of attackers on that domain. If the current network domain is in a period of high scanning heat, attackers may scan that area more frequently, and the honeypot node may be reached earlier. Simultaneously, threat intelligence can be used to predict attacker behavior patterns and attack trends. For example, if historical intelligence indicates that attackers tend to target specific types of services during a certain period, the likelihood of the honeypot node being reached can be predicted based on the simulated service types of the honeypot node. By analyzing network scan logs and threat intelligence data, the current scan activity and intelligence predictions can be assessed, allowing for adjustments to the T2 time. Taking all factors into account, the T2 time point is determined when the target honeypot / honeynet node is exposed to the outside world in the target network domain and is likely to be reached by an adversary. For example, if container startup takes 3 minutes, BGP / SDN redirection takes 8 minutes, DNS / fingerprint propagation takes 30 minutes, and an additional 10 minutes needs to be allowed based on the current scan activity and intelligence predictions, then T2 is the sum of these four times, i.e., 51 minutes later.

[0065] In some embodiments, when verifying the window adaptability in step S4 based on the comparison results of the information at the first time point and the information at the second time point, the server performs the verification according to the numerical relationship between T1 and T2. The core principle is to ensure that data acquisition capability is ready before the decoy node is exposed to the outside world, that is, to meet the timing requirement of "data acquisition first, exposure later". The specific rules are as follows:

[0066] Verification passed: When T1≤T2, the window adaptability verification is passed. This indicates that the data acquisition system is ready before or at least simultaneously with the exposure of the decoy node, ensuring the integrity of the attack interaction data and allowing the task to enter the normal execution process;

[0067] Validation failed: When T1 > T2, the window adaptability validation fails. This means that if executed as originally planned, the data acquisition channel will not be ready when the node is exposed, leading to the loss of early attack data. Furthermore, if the execution window of the current task has a serious resource or timing conflict with the execution windows of other important tasks in the system, it may also cause the validation to fail. When the window adaptability validation fails, the server will trigger an automatic reordering or rollback strategy. The main strategies include:

[0068] Automatic Reordering: The system attempts to automatically adjust task schedules to eliminate conflicts. Common adjustment methods include: postponing the planned exposure time of the decoy node (i.e., T2) to ensure it is later than or equal to T1; optimizing resource allocation and accelerating the initialization process of the data acquisition pipeline, thereby shortening T1 to satisfy the condition T1≤T2;

[0069] Rollback and Feedback: If the timing requirements still cannot be met after automatic reordering, or if conflicts cannot be automatically resolved, the system will execute a rollback strategy, suspending the current deployment process of the task. At the same time, the server will send a detailed rollback reason notification to the terminal device (for example, indicating whether the timing cannot be reconciled or there is a critical resource conflict) so that operators can understand the situation and make subsequent decisions (such as modifying request parameters, selecting other tasks, or waiting for resources to become available).

[0070] In some embodiments, when the spoofing capture task corresponding to the target network domain coordinates is arranged to the task list of the selected honeypot or honeynet node and sent for execution in step S4 based on the verification result, the server arranges the spoofing capture task corresponding to the target network domain coordinates (VLAN / subnet / address range / port / profile) to the specified position in the task list of the selected honeypot / honeynet node according to priority and resource constraints, based on the verification result of the first time information (T1) and the second time information (T2) (ensuring that T1≤T2 to meet the principle of first collection and then exposure), and sends it for execution through multi-stage atomic operation. The execution process includes: locking and isolating resources for the selected honeypot or honeynet nodes, including IP addresses, ports, certificates, images, and storage volumes; configuring the real asset characteristics of the target network domain on the selected honeypot or honeynet nodes, including system fingerprints, service identifiers, interactive scripts, and decoy credentials; deploying and performing health checks on the selected honeypot or honeynet nodes, including starting the service and deploying probes or proxies to monitor node status; exposing the selected honeypot or honeynet nodes to the target network domain and directing attack traffic to the honeypots using traffic redirection technology; and transmitting the data collected by the selected honeypot or honeynet nodes back to the collection domain in real time, triggering corresponding alarm and response processes.

[0071] Specifically, resource locking and isolation: Dedicated resources (IP / port / certificate / image / storage volume) are allocated to honeypot / honeynet nodes to avoid conflicts with other tasks or production services. Dedicated resources are allocated from the honeypot node's available IP pool (e.g., free addresses in 10.0.0.0 / 24) and port range (e.g., 10000-20000 / TCP) based on request parameters (e.g., 22 / TCP, 443 / TCP specified by the target profile). These IPs and ports are marked as dedicated to the spoofing task (status: LOCKED_FOR_DECOY) by calling network control plane APIs (e.g., POST / reserve-ip from the SDN controller or RESERVE_PORT from the firewall), and a lease time is set (e.g., automatic release after the task ends). If the target IP / port is already occupied by other critical services (by querying the CMDB or real-time traffic monitoring), a conflict resolution strategy is triggered (e.g., selecting the nearest free IP within the same subnet, or adjusting the port to a backup range). If the deception task requires simulating HTTPS services (such as forging a bank login page), a dedicated certificate (e.g., CN=fake-bank.com, SAN=10.0.0.5) is allocated from a pre-configured TLS certificate store, and its use is restricted to the current task only via a Key Management System (KMS) (the certificate is bound to the task ID and automatically revoked upon expiration). For containerized honeypots (such as Docker / Kubernetes), a specified version of the emulation image (e.g., honeypot-ssh:2.6.0) is pulled from the image repository and mounted to a separate storage volume on the node (e.g., / var / lib / decoy / volume- <taskid>To avoid sharing data directories with other containers, allocate independent disk volumes (such as LVM logical volumes or cloud storage EBS) for tasks and set read and write permissions (allowing only honeypot processes to access them). If node resources (such as CPU / memory) need to be limited (e.g., no more than 4 cores / 8GB per task), implement isolation through cgroups or Kubernetes resource quotas (resources.limits.cpu:4, resources.limits.memory:8Gi) to prevent resource contention between tasks.

[0072] Specifically, profile rendering and policy injection: Accurately map the real asset characteristics (system fingerprint, service banner, interaction logic) of the target network domain to honeypot nodes, making their behavior highly consistent with real devices (reducing the probability of attacker identification). Based on the system fingerprint in the request parameters (e.g., OS=WindowsServer2019, TCP-Window=8192, HTTP-Server=Apache / 2.4.41), modify the MAC address prefix of the honeypot node (matching common vendors in the enterprise intranet) and TCP / IP stack parameters (e.g., adjusting the initial sequence number (ISN) generation algorithm and TCP retransmission timeout) through the underlying virtualization driver (e.g., QEMU's -devicee1000,mac=00:50:56:XX:XX:XX). For web service honeypots, modify the HTTP response header (e.g., Server:Nginx / 1.18.0 (Ubuntu)), SSL certificate chain (simulating enterprise self-signed certificates), and HTML metadata (e.g., ...<metaname=generatorcontent=WordPress5.9> For specific protocol services (such as SSH and FTP), customize interactive banner information (e.g., displaying "Welcome to Ubuntu 20.04.3LTS (GNU / Linux 5.4.0-88-genericx86_64)" during SSH login). This can be achieved by modifying service configuration files (e.g., the banner in ` / etc / ssh / sshd_config` or dynamically hooking service startup scripts) (e.g., using `LD_PRELOAD` to hijack the `printf` function and output custom content). Inject predefined interactive logic scripts (e.g., simulating database query responses: when an attacker executes `SELECT * FROM users`, it returns 10 forged user records), and distribute decoy credentials (e.g., username admin / password P@ssw0rd123, marked as a low-privilege test account) through secret management tools (e.g., Vault). The script logic runs in a sandbox environment (e.g., the `chroot` directory within a Docker container), restricting its access to the host machine and allowing only the simulation of specific service behavior.

[0073] Specifically, deployment and health checks: Ensure the honeypot node starts and runs normally as expected, and that critical services (such as SSH port listening and HTTP responses) are available. Deploy the rendered honeypot image to the specified IP / port of the target node using container orchestration tools (such as Kubernetes' kubectl apply-fdecoy-pod.yaml) or virtualization platforms (such as VMware vSphere's API to create virtual machines). Deployment configuration includes service startup commands (such as / usr / sbin / sshd -D), environment variables (such as HOLOGRAM_MODE=active), and dependent libraries (such as Python 3.8 for simulating web applications). Deploy a lightweight probe (such as PrometheusExporter or a custom Agent) to continuously monitor the following metrics: check if the SSH port (22 / TCP) is in a LISTEN state (using netstat -tuln|grep22) and if the HTTP service returns 200 OK (using curl -I http: / / localhost:8080). Monitor the existence of critical processes (such as sshd and nginx) by checking their PIDs (using `ps -ef|grepsshd`). If a process crashes, automatically restart it (using the `Restart=always` configuration in systemd). Verify that the probe / agent has successfully connected to the collection domain (e.g., port 10.1.1.100:514 of the SIEM system) by sending test logs (e.g., `{event:healthcheck,status:OK}`) to confirm data reachability. If the health check fails three times consecutively (the threshold is configurable), trigger an alarm (e.g., send a Slack notification to the security team) and mark the task as a deployment failure, automatically rolling back to the previous stable state (e.g., unloading the image and releasing the IP / port).

[0074] Specifically, exposure and traffic redirection take effect: The honeypot node is exposed to the target network domain, and attack traffic is directed to the honeypot via traffic redirection techniques (routing / BGP / SDN / DNS). Through an SDN controller (such as the OpenFlow protocol) or a traditional router (CLI command `iprouteadd 192.168.1.0 / 24 via 10.0.0.5`), specific traffic (such as 22 / TCP, 445 / TCP) from the target network domain (such as 192.168.1.0 / 24) is redirected to the honeypot node (such as 10.0.0.5:22). Firewall ACLs are simultaneously updated (such as `iptables-AFORWARD-s192.168.1.0 / 24-d10.0.0.5-ptcp--dport22-jACCEPT`), allowing legitimate traffic from the target asset to the honeypot while blocking other irrelevant traffic (such as connections to non-target ports). If the target network uses the BGP protocol (such as a data center backbone), a fake route (e.g., 192.168.1.100 / 32via10.0.0.5) is published via BGPSpeaker, making attackers believe that the honeypot IP is the address of a real asset. In an SDN environment, flow table rules are issued by the controller (e.g., flow-modaddmatch=in_port=1,dl_type=0x0800,nw_dst=192.168.1.100actions=output:2) to forward traffic matching the target IP to the honeypot port. If the spoofing task needs to simulate a specific domain name (e.g., fake-login.example.com), a temporary DNS record (fake-login.example.comINA10.0.0.5) is added via a local DNS server (e.g., Bind9), with a short TTL (e.g., 60 seconds) for quick adjustments. Simultaneously, network probing tools (e.g., Scapy sending forged ARP broadcast packets) are used to accelerate the cache updates of the honeypot IP / MAC address by hosts within the target network. The attack data collected by the honeypot nodes is stored in real time to generate alarms and link the detection, tracing and handling processes.

[0075] Specifically, real-time data transmission and alarm linkage: Honeypot nodes transmit raw logs (such as SSH brute-force attempts: Failedpasswordforrootfrom192.168.1.50), network traffic (such as PCAP file fragments), and interactive metadata (such as the tool fingerprint used by the attacker: Hydrav9.1) in real time to the collection domain (such as 10.1.1.100:514 of the SIEM system or the S3 bucket of the data lake) via encrypted channels (such as Syslog or FluentdAgent of TLS 1.3). After the data is persisted, its integrity is ensured through schema validation (such as checking whether the timestamp field is in ISO8601 format). The SIEM system analyzes data based on predefined rules (such as the same IP attempting more than 5 failed login attempts on an SSH port within one minute) or machine learning models (such as abnormal behavior clustering). If it matches attack characteristics, it generates a high-priority alert (such as CVE-2023-1234: SSH brute-force attack, source IP=192.168.1.50) and pushes it to the Security Operations Platform (SOAR) via Webhook. After the alert is triggered, pre-arranged response actions are automatically executed (such as blocking the source IP 192.168.1.50 via SOAR's firewall API, marking the IP as malicious on the threat intelligence platform, and performing correlation analysis on the IP's historical activity records). Simultaneously, the honeypot node continues to record the attacker's subsequent interactions (such as whether they attempt privilege escalation or lateral movement), providing a complete context for subsequent forensics.

[0076] See Figure 2 This invention provides an intelligent threat perception system that integrates honeynets and honeypots, comprising:

[0077] Request processing module 100 is used to receive threat perception and control requests sent by terminal devices; preprocess the threat perception and control requests to obtain a standardized request set;

[0078] The coverage determination module 200 is used to calculate the availability coverage of the corresponding target honeypot or honeynet node for each request in the standardized request set. If the coverage is established, the request is marked as a valid threat perception request and returned to the corresponding terminal device. The terminal device selects at least one of the returned valid threat perception requests as a threat perception request to be executed and resubmits it to the server. If the coverage is not established, the request is marked as an invalid threat perception request and the reason for failure is recorded.

[0079] The data processing module 300 is used by the server to calculate the first moment information and the second moment information for the resubmitted threat perception request to be executed; the first moment information represents the earliest time point when the telemetry data of the target honeypot or honeynet node can be collected and implemented, and the second moment information represents the time point when the target honeypot or honeynet node can be exposed to the outside in the target network domain and is expected to be reached.

[0080] The execution module 400 is used to verify the window adaptability based on the comparison results of the information at the first moment and the information at the second moment; based on the verification results, the deception capture task corresponding to the target network domain coordinates is arranged into the task list of the selected honeypot or honeynet node and executed.

[0081] In summary, the present invention brings the following technical effects and advantages:

[0082] 1. This invention ensures the integrity and reliability of task data from the source by deduplicating requests, verifying signatures, and standardizing parameters during the task reception phase. This effectively eliminates processing errors caused by duplicate submissions, heterogeneous parameters, or illegal requests, laying a solid foundation for subsequent accurate resource matching and strategy execution.

[0083] 2. This invention establishes a multi-dimensional capability coverage model to comprehensively calculate and verify network topology, policy compliance, resource quotas, and profile matching, achieving accurate and forward-looking judgment of task feasibility. This significantly reduces the risk of blindly deploying tasks to unreachable, mismatched, or resource-insufficient nodes, improving the overall deployment success rate and resource utilization efficiency.

[0084] 3. Before task issuance, this invention adds a valid request feedback and execution selection process, enabling task decision-making to undergo a two-stage process of intelligent system screening and manual / strategic reconfirmation. This retains the efficiency of automated initial screening while ensuring that critical threat perception tasks receive priority and prudent decision-making in complex and ever-changing real-world scenarios by returning the valid set and supporting manual intervention or strategy fine-tuning. This avoids the priority mismatch problem that may occur in fully automated mode.

[0085] 4. This invention, by pre-calculating and rigorously verifying the data acquisition readiness time (T1) and the node exposure time (T2), forcibly guarantees the causal sequence of "data acquisition precedes node exposure." This mechanism fundamentally avoids the loss of critical attack data due to acquisition link delays, ensuring the integrity of attack chain evidence. Simultaneously, the accompanying automatic rearrangement and rollback strategies further enhance the system's adaptability and execution reliability in dynamic environments.

[0086] While embodiments of the present invention have been described in detail above, it will be apparent to those skilled in the art that various modifications and variations can be made to these embodiments. However, it should be understood that such modifications and variations fall within the scope and spirit of the invention as set forth in the claims. Furthermore, the invention described herein may have other embodiments and can be implemented or carried out in various ways.< / taskid>

Claims

1. A method for intelligent threat perception that integrates honeynets and honeypots, characterized in that, include: Receive threat awareness and control requests sent by terminal devices; The threat perception and control requests are preprocessed to obtain a standardized request set; For each request in the standardized request set, the availability coverage of its corresponding target honeypot or honeynet node is calculated, including a comprehensive evaluation of the following dimensions: topology reachability, traffic pulling or mirroring capability, protocol profile matching degree, resource quota and concurrency usage, and compliance whitelist; when all evaluated dimensions are met, the coverage is determined to be met; if the coverage is met, the request is marked as a valid threat awareness request and returned to the corresponding terminal device. The terminal device selects at least one of the returned valid threat awareness requests as a threat awareness request to be executed and resubmits it to the server; If the coverage fails, mark the request as an invalid threat awareness request and record the reason for the failure. When a terminal device selects at least one of the effective threat perception requests as threat perception requests to be executed, the process includes: the terminal device selecting at least one of the effective threat perception requests as threat perception requests to be executed through manual selection or semi-automatic selection based on comprehensive priority; the comprehensive priority is obtained by the server normalizing the threat score, conflict score and window adaptation score to a preset range and then weighting and summing them. The server calculates first-moment and second-moment information for resubmitted threat awareness requests, including: calculating the first-moment information by comprehensively considering data pipeline availability, bandwidth and storage quotas, and the access and resolution readiness of security information and event management systems or data lakes; and calculating the second-moment information by comprehensively considering container or host startup latency, border gateway protocol or software-defined network traction activation time, domain name system propagation time, fingerprint propagation time, current scanning popularity, and intelligence prediction. The first-moment information represents the earliest time point when telemetry data of the target honeypot or honeynet node can be collected and deployed, and the second-moment information represents the time point when the target honeypot or honeynet node can be exposed to the outside world in the target network domain and is expected to be reached. The window adaptability is verified based on the comparison results between the information at the first moment and the information at the second moment; based on the verification results, the deception capture task corresponding to the target network domain coordinates is arranged into the task list of the selected honeypot or honeynet node and sent for execution.

2. The method as described in claim 1, characterized in that, The threat awareness and control request includes the target network domain scope or target asset scope, the type and profile of deception to be enabled, and the decoy nodes to be engaged.

3. The method as described in claim 2, characterized in that, The preprocessing of the threat awareness and control request includes deduplication and signature verification parameter normalization. Deduplication involves generating a unique hash key based on key parameters of the threat awareness and control request for deduplication. These key parameters include the target network domain range or target asset range, the deception type master identifier, core system fingerprint features, and the MD5 digest of the decoy node set. Signature verification verifies the request signature based on an asymmetric encryption algorithm. Parameter normalization converts the heterogeneous original request parameters into a unified internal data structure.

4. The method as described in claim 1, characterized in that, After being resubmitted to the server, the server performs convergence control on the resubmitted threat awareness request. The convergence control includes: verifying the identity or authorization of the request source, locking the resource selected by the threat awareness request, and binding the finally confirmed request parameters with the policy execution record.

5. The method as described in claim 1, characterized in that, When the information at the first moment is not greater than the information at the second moment, the deception capture task corresponding to the target network domain coordinates is arranged into the task list of the selected honeypot or honeynet node and sent for execution.

6. The method as described in claim 5, characterized in that, The execution process includes: locking and isolating resources of the selected honeypot or honeynet node, including IP addresses, ports, certificates, images, and storage volumes; configuring the real asset characteristics of the target network domain on the selected honeypot or honeynet node, including system fingerprints, service identifiers, interactive scripts, and decoy credentials; deploying and performing health checks on the selected honeypot or honeynet node, including starting the service and deploying probes or proxies to monitor the node status; exposing the selected honeypot or honeynet node to the target network domain and guiding attack traffic to the honeypot based on traffic redirection technology; and transmitting the data collected by the selected honeypot or honeynet node back to the collection domain in real time and triggering corresponding alarm and response processes.

7. An intelligent threat perception system integrating honeynets and honeypots, characterized in that, include: The request processing module is used to receive threat awareness and control requests sent by terminal devices; The threat perception and control requests are preprocessed to obtain a standardized request set; The coverage determination module is used to calculate the availability coverage of the corresponding target honeypot or honeynet node for each request in the standardized request set, including a comprehensive evaluation of the following dimensions: topology reachability, traffic pulling or mirroring capability, protocol profile matching degree, resource quota and concurrency usage, and compliance whitelist; when all evaluated dimensions are met, the coverage is determined to be met; if the coverage is met, the request is marked as a valid threat awareness request and returned to the corresponding terminal device. The terminal device selects at least one of the returned valid threat awareness requests as a threat awareness request to be executed and resubmits it to the server; If the coverage fails, mark the request as an invalid threat awareness request and record the reason for the failure. When a terminal device selects at least one of the effective threat perception requests as threat perception requests to be executed, the process includes: the terminal device selecting at least one of the effective threat perception requests as threat perception requests to be executed through manual selection or semi-automatic selection based on comprehensive priority; the comprehensive priority is obtained by the server normalizing the threat score, conflict score and window adaptation score to a preset range and then weighting and summing them. The data processing module is used by the server to calculate first-moment and second-moment information for resubmitted threat awareness requests. This includes: calculating the first-moment information by comprehensively considering data pipeline availability, bandwidth and storage quotas, and the access and resolution readiness of security information and event management systems or data lakes; and calculating the second-moment information by comprehensively considering container or host startup latency, the effective time of border gateway protocols or software-defined networks, the propagation time of the Domain Name System, the fingerprint propagation time, the current scanning popularity, and intelligence prediction. The first-moment information represents the earliest time when the telemetry data of the target honeypot or honeynet node can be collected and deployed, and the second-moment information represents the time when the target honeypot or honeynet node can be exposed to the outside world in the target network domain and is expected to be reached. The execution and distribution module is used to verify the window adaptability based on the comparison results between the information at the first moment and the information at the second moment; based on the verification results, the deception capture task corresponding to the target network domain coordinates is arranged into the task list of the selected honeypot or honeynet node and distributed for execution.

Images