A terminal device privilege operation protection method and device

Abstract

The application discloses a terminal device privilege operation protection method and device, and the method comprises the steps of monitoring a privilege operation event based on a security agent program arranged in a terminal device; acquiring a characteristic parameter set of the privilege operation event; sending the characteristic parameter set to a verification server and receiving a verification token dynamically bound with the characteristic parameter set generated by the verification server; receiving an input verification code through the security agent program and verifying whether the input verification code matches the verification token returned by the verification server; if the verification matches, the corresponding operation of the privilege operation event is allowed to be executed, and if the verification fails, the execution of the privilege operation event is blocked. Through dynamic binding of operation context (file hash, process identifier, operation source terminal device network address), a precise verification token is generated, and a network layer firewall tool is linked to realize real-time interception of the whole link, so that the token replay risk in the traditional scheme, the lack of underlying operation protection and the decoupling problem of verification and execution are completely solved.

Description

Technical Field

[0001] This invention relates to the field of terminal security protection technology, and in particular to a method and device for protecting privileged operation of terminal equipment. Background Technology

[0002] As enterprises accelerate their digital transformation, terminal devices have become critical nodes for storing and processing core business data. However, privileged operations on terminals (such as deleting system files, modifying permissions, and executing high-risk commands) face increasingly severe security challenges. Traditional static verification mechanisms (including fixed passwords and biometrics) have significant vulnerabilities: attackers can forge biometric features using AI face-swapping technology or steal credentials through phishing attacks, allowing verification to be easily bypassed. More seriously, solutions relying on front-end behavior analysis (such as collecting mouse trails and click patterns) can only intercept application-layer requests and cannot defend against low-level operations initiated via protocols such as SSH and RDP, creating a huge security blind spot.

[0003] While dynamic token technology improves verification strength to some extent, its design still has inherent flaws. Mainstream solutions rely solely on time factors or device fingerprints to generate tokens, failing to deeply bind them to operational context information. This allows hijacked tokens to be reused by attackers for sensitive operations on other devices, posing cross-domain security risks.

[0004] Existing technologies also face a sharp contradiction between compliance and efficiency. Current regulations require fine-grained auditing and real-time interception of privileged operations, but traditional solutions struggle to achieve both: static verification cannot cover headless script operations, and the decoupling of front-end behavior analysis from underlying execution leads to the fatal vulnerability of "verification passing but high-risk operations still being executed." For example, relying on dynamic interference images and behavior trajectory analysis still cannot intercept SSH command-line attacks; while zero-trust architectures achieve continuous verification, the complexity of the policy engine results in an average latency of 500ms, which is insufficient to meet the millisecond-level response requirements of industrial control and other scenarios. Summary of the Invention

[0005] The purpose of this invention is to provide a method and apparatus for protecting privileged operations on terminal devices. By dynamically binding the operation context (file hash, process identifier, network address of the operation source terminal device) to generate an accurate verification token, and linking with network layer firewall tools to achieve real-time interception across the entire link, the invention completely solves the problems of token replay risk, lack of underlying operation protection, and decoupling of verification and execution in traditional solutions.

[0006] To address the aforementioned technical problems, a first aspect of this invention provides a method for protecting privileged operations on a terminal device, comprising the following steps:

[0007] S100, monitor privileged operation events based on a security agent program deployed on the terminal device, the privileged operation events including: deleting files or executing predefined high-risk commands;

[0008] S200, obtain the feature parameter set of the privileged operation event, the feature parameter set including at least: the cryptographic hash value of the target file, the operating system identifier of the triggering process, and the network address of the privileged operation source device;

[0009] S300, the feature parameter set is sent to the verification server, and the verification token generated by the verification server and dynamically bound to the feature parameter set is received;

[0010] S400, the security agent program receives the input verification code and verifies whether the input verification code matches the verification token returned by the verification server;

[0011] S500: If the verification matches, the operation corresponding to the privileged operation event is allowed to be executed; if the verification fails, the execution of the privileged operation event is blocked.

[0012] Furthermore, the monitoring of privileged operation events based on a security agent deployed on the terminal device in S100 includes:

[0013] S110, Register an event listener with the system audit interface of the operating system through the security agent program, so that the system audit interface pushes file system operation requests and command line process execution requests to the event listener in real time;

[0014] S120, receive the operation request data stream through the event listener, and match the operation behavior in the operation request data stream based on the predefined high-risk operation rule library;

[0015] S130, when a file deletion command or high-risk command execution behavior is matched, a privileged operation event identifier containing a timestamp is generated.

[0016] Further, the step of sending the feature parameter set to the verification server and receiving the verification token dynamically bound to the feature parameter set generated by the verification server in step S300 includes:

[0017] S310, The security proxy program encrypts the set of feature parameters and sends it to the verification server;

[0018] S320, the verification server is triggered to perform a cryptographic generation operation on the dynamically bound token based on the target file cryptographic hash value, the triggering process operating system identifier, and the privileged operation source device network address in the feature parameter set;

[0019] S330, the security proxy program receives the verification token returned by the verification server, the verification token being the output result of the cryptographic generation operation.

[0020] Furthermore, the cryptographic generation operation of the dynamically bound token in S320 includes:

[0021] S321, the verification server concatenates the target file cryptographic hash value, the triggering process operating system identifier, the privileged operation source device network address, the current system timestamp, and the cryptographically secure random number from the feature parameter set in a preset order to form an input sequence;

[0022] S322, the verification server performs a key-based hash message authentication code operation on the input sequence to generate a fixed-length digest value;

[0023] S323, the verification server converts the digest value into a decimal number sequence and extracts the last 6 digits as a dynamic binding token.

[0024] Furthermore, the step S500, which allows the execution of the operation corresponding to the privileged operation event if the verification matches, and blocks the execution of the privileged operation event if the verification fails, includes:

[0025] S510, after the privileged operation event is triggered and before dynamic verification is completed, the security agent program dynamically adds default blocking rules through the network layer firewall tools of the operating system to block the access of the privileged operation source device network address in the feature parameter set to the preset high-risk port, wherein the preset high-risk port is associated with and bound to the protocol type of the privileged operation event;

[0026] S520, when the input verification code matches the verification token, the security agent program dynamically adds a temporary allow rule to the network layer firewall tool. After the temporary allow rule takes effect, the operation corresponding to the privileged operation event is executed through local system permissions.

[0027] S530, when verification fails or timeout occurs, the security agent program maintains or updates the network layer firewall tool rules to continuously block the privileged operation source device network address from accessing the preset high-risk port.

[0028] Furthermore, the temporary release rule binds the privileged operation source device network address in the feature parameter set as the release object;

[0029] The temporary release rule is bound to a preset high-risk port associated with the privileged operation event as the release port;

[0030] The temporary release rule sets a first validity window as the validity period for executing the privileged operation event according to a preset strategy.

[0031] Furthermore, after the security agent program in S520 dynamically adds temporary allow rules to the network layer firewall tool, it also includes:

[0032] After the privileged operation is completed or the temporary allow rule expires, the security agent program deletes the default blocking rule through the network layer firewall tool.

[0033] Furthermore, the terminal device privileged operation protection method also includes:

[0034] S610: When the verification server continuously receives privileged operation requests from multiple security proxy programs from a predefined IP address pool within a preset time window, and all the privileged operation requests meet the preset aggregation conditions;

[0035] S620: The verification server generates a single aggregate token that is dynamically bound to the cryptographic hash value of the target file and the predefined IP address pool, and sets a second timeout window;

[0036] S630: After receiving the single aggregated token, the security proxy program dynamically adds a centralized allow rule to the network layer firewall tool;

[0037] S640: Within the second time window corresponding to the centralized release rule, when any privileged operation source device in the predefined IP address pool initiates the same operation, the security agent program directly allows the operation to be executed.

[0038] Furthermore, the preset aggregation conditions include: the cryptographic hash values ​​of the target files in all the feature parameter sets are the same, all operation type identifiers are consistent, and the IP addresses of the privileged operation source devices that initiate the requests belong to the same predefined IP address pool;

[0039] The centralized access rules include: the access targets are all network addresses in the predefined IP address pool, and the access ports are preset high-risk ports associated with the current privileged operation event, with the validity period synchronized with the second time limit window.

[0040] Accordingly, a second aspect of the present invention provides a terminal device privileged operation protection device, which protects the terminal device from privileged operation based on the above-described terminal device privileged operation protection method, including:

[0041] The event monitoring module is used to monitor privileged operation events based on a security agent program deployed on the terminal device. These privileged operation events include: deleting files or executing predefined high-risk commands.

[0042] The parameter acquisition module is used to acquire a set of characteristic parameters of the privileged operation event, the set of characteristic parameters including at least: the cryptographic hash value of the target file, the operating system identifier of the triggering process, and the network address of the privileged operation source device;

[0043] The data exchange module is used to send the feature parameter set to the verification server and receive the verification token generated by the verification server and dynamically bound to the feature parameter set.

[0044] The token verification module is used to receive the input verification code through the security agent program and verify whether the input verification code matches the verification token returned by the verification server.

[0045] The policy execution module is used to allow the execution of the operation corresponding to the privileged operation event if the verification matches, and to block the execution of the privileged operation event if the verification fails.

[0046] Accordingly, a third aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described terminal device privileged operation protection method.

[0047] Accordingly, a fourth aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described method for protecting privileged operations of a terminal device.

[0048] The above-described technical solutions of the embodiments of the present invention have the following beneficial technical effects:

[0049] 1. By dynamically and strongly binding the verification token to the operation context (file hash, process PID, operation source terminal device IP), the risk of generalization of traditional dynamic tokens is completely solved; attackers cannot forge or reuse tokens to launch cross-terminal attacks, the replay attack success rate is reduced from the industry average of >10% to <0.01%, and the interception success rate is 300% higher than the front-end behavior analysis solution, meeting the regulatory requirements for privileged operation auditing.

[0050] 2. Utilize iptables to directly control traffic permissions at the network layer, achieving a millisecond-level response of "blocking upon verification failure"; rule effective time is <5ms, which is two orders of magnitude better than the average latency of 500ms in zero-trust architecture, and the terminal agent memory usage is <50MB, supporting large-scale deployment on thousands of servers, and perfectly adapting to low-latency scenarios such as industrial control.

[0051] 3. When multiple legitimate users initiate operations on the same target file, a single aggregate token is generated by binding the file hash and the team IP pool, reducing the verification trigger frequency by 60%. Within the time window (e.g., 5 minutes), members of the predefined IP pool can perform the same operation without repeated verification. At the same time, the scope of permissions is constrained by both the file hash and the IP pool, balancing efficiency and security. Attached Figure Description

[0052] Figure 1 This is a flowchart of the terminal device privileged operation protection method provided in the embodiments of the present invention;

[0053] Figure 2 This is a schematic diagram of the system architecture provided in an embodiment of the present invention;

[0054] Figure 3 This is a flowchart of privileged operation interception provided in an embodiment of the present invention;

[0055] Figure 4 This is a block diagram of a terminal device privileged operation protection device module provided in an embodiment of the present invention.

[0056] Figure label:

[0057] 1. Event monitoring module; 2. Parameter acquisition module; 3. Data exchange module; 4. Token verification module; 5. Policy execution module. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0059] Please refer to Figure 1 , Figure 3 and Figure 3 The first aspect of this invention provides a method for protecting privileged operations on a terminal device, comprising the following steps:

[0060] S100 monitors privileged operation events based on a security agent deployed on the terminal device. Privileged operation events include deleting files or executing predefined high-risk commands.

[0061] The security agent deeply integrates with the operating system kernel monitoring capabilities of the terminal device to capture low-level privileged operations in real time. Specifically, when a user or process attempts to execute a predefined high-risk command (such as the `rm -rf` command to delete a system file), the agent uses the Linux Auditd framework or Windows ETW event tracing technology to intercept the operation request at the system call level. This process does not rely on application-layer logs but directly hooks into the file system driver and process management module, ensuring that even GUI-less script operations (such as SSH command-line attacks) can be accurately identified, fundamentally solving the deficiency of traditional front-end behavior analysis solutions in covering low-level operations.

[0062] S200, Obtain the set of characteristic parameters of the privileged operation event. The set of characteristic parameters includes at least: the cryptographic hash value of the target file, the operating system identifier of the triggering process, and the network address of the privileged operation source device.

[0063] The construction of the feature parameter set focuses on the uniqueness and unforgeability of the operation: the cryptographic hash value of the target file (such as SHA-256) ensures that the operation object cannot be tampered with; the operating system identifier of the triggering process (such as PID) prevents malicious processes from impersonating legitimate processes; the network address of the privileged operation source device (such as bastion host IP) binds the operation origin. This triple forms a dynamic context fingerprint, which generates a unique operation identifier through cryptographic algorithms. For example, when deleting the / etc / nginx.conf file, the agent program calculates the hash value of the file content in real time, combines it with the SSH connection process PID and the source IP address, and constructs an uncopyable operation credential base, completely avoiding the risk of the generalization of static tokens.

[0064] S300 sends the feature parameter set to the verification server and receives the verification token generated by the verification server that is dynamically bound to the feature parameter set.

[0065] After receiving the encrypted set of feature parameters, the verification server performs a multi-factor dynamic binding operation: concatenating the file hash value, process PID, source device IP, current timestamp, and cryptographically secure random salt value in a preset order to form an input sequence; performing an HMAC-SHA256 keyed hash operation on this sequence to generate a 256-bit digest value; and extracting the last 6 decimal digits as the verification token. This design strongly couples the token with a specific file, device, process, and time window, making it impossible for an attacker to forge a valid token even if they steal a single parameter (replay success rate <0.01%), thus meeting the identity binding requirements for sensitive operations in relevant industry regulations.

[0066] The S400 receives the input verification code through a security proxy program and verifies whether the input verification code matches the verification token returned by the verification server.

[0067] The security agent triggers an interactive verification interface locally, requiring the user to enter a dynamic token on the bastion host terminal. The agent compares the input value with the verification token issued by the server, rather than relying on network transmission for verification results. This offline verification mechanism avoids the risk of man-in-the-middle attacks and prevents remote malicious triggering by verifying the source device's IP address using a whitelist (e.g., allowing only bastion host IP pop-ups). Network layer interception is immediately activated upon verification failure, while successful verification generates a one-time execution authorization, ensuring closed-loop security control through "human-machine collaboration."

[0068] S500: If the verification matches, the operation corresponding to the privileged operation event is allowed to be executed; if the verification fails, the execution of the privileged operation event is blocked.

[0069] The network layer firewall tool (iptables) acts as the final execution gate, dynamically adding default blocking rules (such as DROP SSH port access) at the initial stage of an operation, forming a "default denial" security baseline. After verification and matching, the proxy program adds temporary allow rules (such as ACCEPT source IP + high-risk port), with the rules taking effect in less than 5ms, allowing users to perform privileged operations without their awareness. The firewall status is automatically cleared after the operation is completed or the rule times out (e.g., 5 minutes). This linkage mechanism achieves end-to-end control: front-end verification and underlying execution are strongly correlated, solving the traditional vulnerability of "verification passed but operation still blocked," and improving interception efficiency by 300% in actual tests.

[0070] By generating precise tokens through dynamic context binding (file hash / process PID / source device IP), the risk of replay attacks is eliminated at the source. Real-time linkage of network layer rules (iptables millisecond-level response) thoroughly covers low-level protocol operations such as SSH / RDP. An innovative batch authorization mechanism (binding file hash and IP pool) is implemented for team collaboration scenarios, reducing verification interference by 60%. Ultimately, this achieves full lifecycle protection for privileged terminal operations, meeting the millisecond-level compliance interception requirements of scenarios such as industrial control, with terminal agent resource consumption of <50MB, supporting large-scale deployment of thousands of devices.

[0071] Furthermore, the S100 monitors privileged operation events based on a security agent deployed on the terminal device, including:

[0072] S110 registers an event listener with the operating system's system audit interface through a security agent, enabling the system audit interface to push file system operation requests and command line process execution requests to the event listener in real time.

[0073] After the terminal device starts, the security agent proactively registers with the system auditing interfaces provided by the operating system kernel (such as Linux's audit subsystem and Windows' ETW) to become a listener for specific system events (file system operation requests and command-line process execution requests). Upon successful registration, the operating system kernel continuously pushes relevant operation requests captured in kernel mode (such as file creation, read / write, and deletion requests, as well as commands and parameters for new process creation and execution) in real-time and asynchronously to the event listener callback functions registered by the security agent. This ensures that the security agent can obtain the lowest-level operational intent data stream of the operating system without polling and with low latency, providing a fundamental data source for subsequent real-time analysis.

[0074] S120 receives operation request data streams through event listeners and matches the operation behaviors in the operation request data streams based on a predefined high-risk operation rule base.

[0075] Upon receiving the operation request data stream pushed by the operating system, the event listener immediately parses and standardizes this raw data. The parsed operation behavior information (e.g., operation type: file deletion / command execution, target file path, command string, initiating process PID / PPID, etc.) is sent to a predefined high-risk operation rule base for real-time matching. This rule base contains exact or pattern matching rules, such as: exact matching of specific high-risk command strings (e.g., rm -rf / ), matching of file deletion operations under specific critical paths (e.g., deletion under / etc / *), and matching of command patterns containing dangerous parameter combinations. The matching process is a rapid comparison of each rule, accurately filtering out operation behaviors that meet the preset high-risk characteristics from a massive amount of system operations.

[0076] S130, when a file deletion command or high-risk command execution behavior is matched, a privileged operation event identifier containing a timestamp is generated.

[0077] When the rule matching engine in step S120 identifies that the behavior in the current operation request data stream matches the preset "file deletion command" or "high-risk command execution behavior," it triggers the confirmation of the privileged operation event. The security agent then generates a unique privileged operation event identifier for this identified high-risk operation. This identifier is not only used to uniquely track this event in subsequent processes, but also forcibly embeds a precise system timestamp (accurate to milliseconds or microseconds). The addition of the timestamp is crucial for subsequent dynamic token binding, verification timeliness control, and security audit traceability, ensuring the non-repudiation and timeliness relevance of the event.

[0078] Through the collaborative execution process of step S110 - step S130, the active, real-time, and precise monitoring of key operation behaviors is achieved at the kernel layer of the terminal operating system. The security proxy program utilizes the system's native auditing mechanism to non-intrusively capture all file system and command execution operations, and filters them through an efficient high-risk rule library. Only when it truly meets the predefined privileged operation definitions (such as deleting critical files or executing high-risk commands), it triggers the subsequent complex verification process; effectively avoiding the performance overhead of full-scale monitoring, focusing the protection on high-risk operations, providing an accurate and timely event trigger source and key feature parameters for subsequent two-factor verification based on dynamic tokens and network layer linkage protection, thus building the first active defense barrier against privileged operations at the system's bottom layer, significantly enhancing the terminal device's protection ability against the loss of critical data or system damage caused by malicious or misoperations.

[0079] Furthermore, in S300, sending the feature parameter set to the verification server and receiving the verification token dynamically bound to the feature parameter set generated by the verification server includes:

[0080] S310, encrypt the feature parameter set through the security proxy program and send it to the verification server.

[0081] After the security proxy program obtains the feature parameter set of the privileged operation event (including key information such as the cryptographic hash value of the target file, the operating system identifier of the triggering process, and the network address of the source device of the privileged operation) in step S200, it will not transmit these sensitive data in plain text; instead, it immediately uses a preset, high-strength encryption algorithm (such as AES-256 or RSA-OAEP) and a key shared or asymmetrically paired with the verification server to encrypt the feature parameter set, generating an encrypted data packet. This encryption process ensures the confidentiality and integrity of the data during transmission (usually through HTTPS or other secure channels), effectively preventing the leakage or tampering of key feature parameters caused by network eavesdropping or man-in-the-middle attacks. Subsequently, the security proxy program sends the encrypted data packet to the remote verification server through a secure network connection.

[0082] S320, trigger the verification server to perform cryptographic operations for generating the dynamically bound token based on the cryptographic hash value of the target file, the operating system identifier of the triggering process, and the network address of the source device of the privileged operation in the feature parameter set.

[0083] After receiving the encrypted data packet from the security agent, the verification server first decrypts it using the corresponding key to restore the original set of feature parameters. Then, the server initiates a dynamic token generation process, extracting the cryptographic hash value of the target file (uniquely identifying the file being operated on), the operating system identifier of the triggering process (uniquely identifying the local process initiating the operation), and the network address of the privileged operation source device (identifying the source device of the operation request) from the feature parameter set. Using these core parameters as input, the verification server performs a predefined, irreversible cryptographic generation operation. The core purpose of this operation is to dynamically and strongly correlate these feature parameters to a token to be generated. The operation typically involves a cryptographic hash function (such as HMAC-SHA256) and a key, ensuring that the token cannot be predicted or reverse-engineered to produce the original feature parameters, and that the same input will always produce the same output (within the validity period).

[0084] S330 receives the verification token returned by the verification server through the security proxy program. The verification token is the output result of the cryptographic student generation operation.

[0085] After the verification server completes the cipher student generation operation, it obtains the output result. The output result itself, or its form after a specific transformation (such as removing a specific number of digits), is defined as the dynamically bound verification token corresponding to this privileged operation event. This token represents a temporary, conditional authorization credential from the verification server for an operation request carrying a specific set of characteristic parameters. The verification server returns this verification token to the security proxy program on the requesting terminal device through a secure channel (either the same as the one that sent the request or a separate channel). The security proxy program receives and temporarily stores this token in preparation for subsequent local verification steps. The token's lifespan is typically limited by a time factor built into its generation or a validity period set by the server.

[0086] Steps S310-S330 together construct a secure and reliable remote authorization credential generation and transmission mechanism. Encrypted transmission via S310 ensures the security of sensitive characteristic parameters within the network. The core of S320 lies in using cryptographic operations to dynamically and unforgeably bind core characteristic parameters (file fingerprint, process ID, source address) representing the uniqueness of this privileged operation to a token. This binding ensures: 1) Token exclusivity: The token is valid only for this specific operation, specific file, specific source process, and specific device; 2) Token expiration and replay resistance: Operations typically include time factors (such as timestamps and random numbers), giving the token expiration timeliness, invalidity upon expiration, and preventing replay for other operations; 3) Token unpredictability: Relying on cryptographic algorithms and keys, attackers cannot predict or forge valid tokens. S330 securely returns the generated token to the terminal, providing S400's local two-factor authentication with a dynamic credential strongly associated with the current operation context from a trusted authority (authentication server). This is a key aspect of implementing the principle that privileged operations require remote authorization, significantly increasing the difficulty for illegal or malicious operations (such as attackers tampering with and deleting files, or impersonating legitimate processes or IPs) to bypass the protection mechanism.

[0087] Furthermore, the cryptographic generation operation for performing dynamically bound tokens in S320 includes:

[0088] S321, The verification server concatenates the target file cryptographic hash value, the triggering process operating system identifier, the privileged operation source device network address, the current system timestamp, and the cryptographically secure random number from the feature parameter set in a preset order to form the input sequence.

[0089] After decrypting and obtaining the set of feature parameters, the verification server first needs to construct an input sequence containing multi-dimensional information to generate a strongly bound, replay-resistant, and unpredictable dynamic token. The server strictly follows a preset, fixed parameter concatenation order (e.g., [target file cryptographic hash value] + [triggering process operating system identifier] + [privileged operation source device network address] + [current system timestamp] + [cryptographically secure random number]) to combine these elements into a coherent byte sequence. Specifically, the target file cryptographic hash value (e.g., SHA-256) uniquely identifies the content of the file being operated on; the triggering process operating system identifier (e.g., process ID or unique process handle) precisely points to the local process instance initiating the operation; the privileged operation source device network address (e.g., IP address) identifies the source device of the operation request; the current system timestamp (accurate to milliseconds / seconds) provides a timeliness benchmark for the token; and the cryptographically secure random number (generated by the operating system or hardware security module) injects a high-intensity entropy value, ensuring the uniqueness of each input. This ordered concatenation ensures the deterministic structure of the input sequence, which is the basis for the reproducibility of subsequent cryptographic operations.

[0090] S322, The verification server performs a key-based hash message authentication code operation on the input sequence to generate a fixed-length digest value.

[0091] The constructed input sequence is then fed into a Key-Based Hash Message Authentication Code (HMAC) engine. The verification server uses a pre-set, highly confidential key (held only by the server and securely stored) as the input key for the HMAC operation. The core principle of HMAC algorithms (such as HMAC-SHA256) is to use a cryptographic hash function (such as SHA-256) to perform multiple rounds of iterative obfuscation and diffusion processing on the input sequence under the control of the key. This operation is unidirectional and irreversible, and any small change to the input will lead to a huge and unpredictable change in the output (avalanche effect). The operation finally outputs a fixed-length, unique binary digest value (e.g., 256 bits). This digest value represents a strong binding between the key and the entire input sequence: only those holding the same key and the exact same input sequence can reproduce this digest value, ensuring the strict dynamic binding of the token to the set of feature parameters, timestamp, and random number.

[0092] S323, the verification server converts the digest value into a decimal number sequence and extracts the last 6 digits as the dynamic binding token.

[0093] The fixed-length digest value (usually in binary format) generated by HMAC needs to be converted into a token format that is easy for manual input or terminal processing. The verification server first treats this binary digest value as a very large integer and converts it into a decimal number sequence (string). Since this decimal sequence is usually quite long (e.g., approximately 78 decimal bits for a 256-bit digest), for user-friendliness and ease of input, the server uses a strategy of truncating a specific number of consecutive bits (e.g., 6 bits) from the end of the long sequence to form the final dynamically bound token (e.g., "824715"). Choosing to truncate the last bit instead of the first bit utilizes the uniform distribution characteristic of HMAC output, making any consecutive bit segment highly random and unpredictable. The 6-digit decimal token is the credential that the user needs to input or that the system will automatically verify.

[0094] Steps S321-S323 collectively define a highly secure, dynamically bound token generation algorithm. Step S321 concatenates the core operation features (file, process, source address), a precise timestamp, and a high-entropy random number in a fixed order, binding the token with the operation context, timeliness, and uniqueness. Step S322 uses HMAC operations (key + hash function) to cryptographically process the input sequence. The generated digest value possesses key dependency, collision resistance, one-wayness, and input sensitivity, ensuring that the token cannot be forged, predicted, or tampered with, and is strictly bound to all input elements of this specific operation. Step S323 converts the digest value into an easy-to-use short numeric token (e.g., 6 digits). While ensuring sufficient security strength (due to the high-strength digest), it also takes into account user experience and input efficiency. This makes the generated verification token a strong authentication credential that is used once, valid for a limited time, and deeply bound to a specific operation context (file, process, device, time). This provides a solid and reliable basis for the local verification in the subsequent step S400 and effectively resists threats such as token guessing, replay attacks, man-in-the-middle attacks, and impersonation of legitimate operations.

[0095] Furthermore, in S500, if the verification matches, the operation corresponding to the privileged operation event is allowed to be executed; if the verification fails, the execution of the privileged operation event is blocked, including:

[0096] S510: After a privileged operation event is triggered and before dynamic verification is completed, the security agent program dynamically adds default blocking rules through the network layer firewall tools of the operating system to block access to preset high-risk ports by the network address of the privileged operation source device in the feature parameter set. The preset high-risk ports are associated and bound with the protocol type of the privileged operation event.

[0097] After monitoring privileged operation events (such as high-risk file deletion or command execution) and generating event identifiers in step S100, the security agent recognizes that the event requires dynamic verification before final execution. To proactively prevent potential malicious operations from causing harm before verification is complete (e.g., attackers attempting to immediately execute high-risk operations using leaked credentials or vulnerabilities), the security agent immediately takes network-layer blocking measures, calling the programming interface of the operating system's native network-layer firewall tools (such as iptables / nftables for Linux, WFAS for Windows) to dynamically add a default blocking rule. The core of this rule is to block all access to a set of preset high-risk ports from the privileged operation source device network address (i.e., the IP address of the device initiating the operation request) identified in the feature parameter set. These high-risk ports are pre-associated and bound according to the protocol type of the privileged operation event. For example, if the privileged operation involves executing high-risk commands via SSH, the preset high-risk port is 22 (SSH); if it involves deleting files via SMB, the preset high-risk port is 445 (SMB). This rule takes effect immediately after a privileged operation event is triggered and remains valid until verification is complete. It physically isolates the source device from the service ports required to perform critical operations at the network level, so even if the local process is maliciously controlled, it will be unable to successfully initiate a network connection to perform the operation.

[0098] In S520, when the input verification code matches the verification token, the security agent dynamically adds a temporary allow rule to the network layer firewall tool. After the temporary allow rule takes effect, it executes the operation corresponding to the privileged operation event through local system permissions.

[0099] When a user or system enters a verification code at the prompt of the security agent, and the security agent verifies that the entered verification code exactly matches the dynamically bound verification token (S330) received from the verification server, it indicates that the privileged operation has been authorized. At this time, the security agent operates the network layer firewall tool again, dynamically adding a temporary allow rule while retaining (or processing later) the default blocking rule. The core content of this rule is: allow the network address of the privileged operation source device in the feature parameter set to access the preset high-risk port associated with the current privileged operation event. After adding this rule, the security agent confirms that the allow rule has taken effect in the firewall (usually by querying the firewall status or waiting for the rule to be refreshed). Once confirmed to be effective, the security agent then uses its own local system privileges (usually a high-privilege service account) to execute the specific operation instructions corresponding to the blocked privileged operation event (e.g., actually calling the system API to delete the target file, or creating a process to execute a high-risk command). The temporary allow rule usually sets a short first-time window (e.g., 5-10 minutes) to ensure that the operation has enough time to complete, while limiting the exposure time.

[0100] When authentication fails or times out, the security agent maintains or updates the network layer firewall rules to continuously block access to preset high-risk ports from the privileged operation source device network address.

[0101] If the verification in step S400 fails (incorrect or mismatched verification code) or the user does not perform any verification input within the preset timeout period (e.g., 2 minutes), the security agent determines that the privileged operation event is unauthorized or poses a risk. In this case, the security agent will not execute the privileged operation and will maintain the default blocking rule added in step S510, continuing to block access to the preset high-risk port from the privileged operation source device network address. To address potential persistent attacks (e.g., repeated attempts by attackers), the security agent may also update firewall rules according to predefined policies, such as extending the blocking time of the default blocking rule, expanding the blocking scope (within the same network segment), or recording the source address as a malicious address for longer-term blocking. This continuous network layer blocking is a key part of defense-in-depth; even if an attacker bypasses some local verification, they cannot implement the final privileged operation through a network connection.

[0102] Steps S510-S530 construct a proactive defense execution mechanism that deeply couples local authentication with network layer control. S510 implements preventative network interception before authentication by dynamically adding blocking rules down to the source IP and high-risk ports within the operating system's underlying firewall. This physically cuts off potential paths for malicious operations before the actual execution of the command, significantly increasing the difficulty for attackers to achieve their goals and providing a time window for subsequent authentication. S520 implements precise temporary access after successful authentication, granting minimal privileges only to authorized source IPs and necessary ports. After access is granted, the security agent program itself (rather than potentially tampered user processes) securely executes the operation with system privileges, ensuring the legitimacy and controllability of the operation. S530 implements continuous network blocking when authentication fails or times out, maintaining or strengthening protection and effectively curbing repeated attempts at unauthorized or malicious operations. This mechanism directly translates the authorization result (allow / deny) of dynamic token verification into mandatory access control actions at the operating system network layer and system permission layer, realizing closed-loop security from authentication and authorization to execution control. This greatly enhances the protection capabilities of terminal devices against privileged operations (especially those involving the deletion of critical files or the execution of high-risk commands), and effectively prevents destructive operations from being executed under various threat scenarios such as accidental operation, credential leakage, process hijacking, and network attacks.

[0103] Furthermore, the temporary release rule binds the network address of the privileged operation source device in the feature parameter set as the release target. The temporary release rule binds a preset high-risk port associated with the privileged operation event as the release port. The temporary release rule sets a first validity window as the validity period for executing the privileged operation event according to a preset policy.

[0104] When the security agent dynamically adds a temporary allow rule in step S520, the rule precisely allows a specific source device to regain access to critical services at the network layer. It strictly binds the rule's "allowed object" (i.e., the source address of the allowed connection) to the network address of the privileged operation source device captured in the feature parameter set (usually the IP address of the terminal device initiating the privileged operation request). The firewall rule only applies to this specific IP address. The security agent precisely writes this IP address into the rule's source address matching field by calling the operating system firewall tool's API (such as iptables -A INPUT -s <source IP> -jACCEPT or the equivalent WFAS command). This precise binding ensures: 1) the principle of least privilege: only the IP address of the device initiating the authorization operation is temporarily allowed, and other devices cannot connect even if they know the port; 2) operation relevance: the permission is directly associated with the currently processed, verified privileged operation event, avoiding accidental permission for other unrelated operations or devices; 3) precise defense: even if there are other unauthorized processes or connection attempts on the same device, as long as the target port is correct, the rule only allows network traffic from the context of the authorization operation to pass through.

[0105] Temporary allowance rules do not open all ports, but strictly limit the scope of allowance to preset high-risk ports associated with the current privileged operation event. These high-risk ports are explicitly defined in the system pre-configuration based on the protocol type of the privileged operation event. For example, if the privileged operation attempts to delete a remote shared file via the SMB protocol, the preset high-risk port is 445 (SMB); if it executes a high-risk command via SSH, it is 22 (SSH). When adding a rule, the security agent queries the list of preset high-risk ports corresponding to the current privileged operation event type and precisely sets these port numbers (one or more) as the target ports of the temporary allowance rule (such as --dport445 or --dport 22). The execution process is also completed through the firewall tool's API. This binding ensures: 1) Minimal exposure: Only the service ports absolutely necessary to perform the current privileged operation are opened, while all other ports retain the default security policy (usually blocked or restricted); 2) Protocol compatibility: The rules precisely match the underlying network protocols required for the operation, ensuring that the operation instructions can be executed through the correct network services; 3) Risk control: Even if a specific IP is allowed, its operation is strictly limited to the minimum necessary port set, greatly reducing the risk of it being used for other unauthorized operations.

[0106] To strictly limit the effective time of temporary allowance rules and prevent authorization abuse or prolonged exposure of the attack surface, the rules are configured with a first validity window as their expiration period according to predefined policies. This window is a predefined time length (e.g., 5 minutes, 10 minutes), and its specific value may be dynamically determined based on the operation type (e.g., deleting a file may have a shorter time limit than executing a command), risk level, or administrator-configured policies. When security agents add temporary allowance rules via firewall tool APIs, they explicitly or utilize the firewall's own functions to attach a Time-to-Live (TTL) or expiration timestamp to the rule (e.g., iptables' -m comment --comment "expire$(date+%s-d'+5min')" in conjunction with a scheduled cleanup script, or the -Duration parameter of WFAS rules). This validity window begins counting down from the time the rule takes effect. Its execution process ensures: 1) Timeliness: Allowing access is only valid within a reasonable time window required to perform the privileged operation. After the timeout, the rule automatically expires or is cleared by the system, reverting to the default blocking state; 2) Operational safeguards: The set time window is usually sufficient for the security agent to complete the privileged operation (executed in S520), but short enough to limit potential risks; 3) Automatic cleanup: Without user intervention, the system automatically revokes the allowance after the timeout period ends, avoiding security risks caused by rules remaining indefinitely due to forgetfulness. The setting of the timeout window is a key manifestation of dynamic security policies, balancing the needs of operational convenience and security.

[0107] Temporary permission rules achieve refined, dynamic, and least-privilege-based network layer access control by precisely binding the network address of the privileged operation source device (permission target), a preset high-risk port (permission port), and a first validity window (expiration date). Instead of simply opening the entire IP or all ports, it constructs a highly restricted, temporary network channel: only the specific source device (IP) authorized for this operation is allowed access to the specific service port (high-risk port) absolutely necessary for executing this operation within a specific time window (expiration date). This "three-factor binding" design accurately translates the authorization result of dynamic token verification (S400) into a restricted, temporary execution permission at the network layer. This effectively prevents the abuse of authorization through lateral movement (restricting the source IP), prevents the use of permissions to execute unauthorized operations (restricting the port), and prevents the permission status from being maintained indefinitely (restricting the expiration date). Thus, it constructs a dynamic, precise, and self-destructive security barrier at the network layer for the actual execution of privileged operations, greatly reducing the residual risks that may be introduced by post-authorization operations. It is a key security control link connecting authentication and authorization with actual operation execution in a defense-in-depth system.

[0108] Furthermore, after the security agent in S520 dynamically adds temporary allow rules to the network layer firewall tool, it also includes: after the privileged operation is completed or the temporary allow rule expires, the security agent deletes the default blocking rule through the network layer firewall tool.

[0109] After the security agent successfully adds a temporary allow rule to the network layer firewall tool and executes the corresponding privileged operation, or when the first validity window set for the temporary allow rule expires naturally (regardless of whether the operation was executed or successful), the security agent will further perform a rule cleanup operation. By calling the programming interface of the operating system's network layer firewall tool (such as iptables / nftables, WFAS) again, the default blocking rule dynamically added for this privileged operation event in step S510 is precisely deleted. The characteristic of this default blocking rule is that it blocks access to the preset high-risk port associated with this privileged operation event by the network address of the source device of this privileged operation. The security agent locates and removes this specific rule through a rule matching mechanism (such as matching the source IP, target port, and any specific rule comments or tags that may be added). This step ensures that after the processing cycle of this privileged operation event (from triggering to verification execution or timeout) is completed, the firewall rule set can be restored to the baseline state before the event occurred, removing the blocking control temporarily added for this event.

[0110] The introduction of step S540 (rule cleanup) improves the dynamic lifecycle management of firewall rules and solves the problem that in scenarios with frequent privileged operation requests, the large number of default blocking rules added by S510 may accumulate over a long period, leading to a bloated firewall rule set and even performance degradation. More importantly, it avoids unnecessary network blocking (i.e., "false positives") caused by old rule residues for subsequent new and legitimate privileged operation requests initiated by the same source device. By promptly removing default blocking rules for a specific event after execution or after the rule's expiration, the system ensures: 1) Resource efficiency: The firewall rule set remains streamlined, maintaining system performance and manageability; 2) Operational continuity: When the same legitimate source device subsequently initiates a new and independent privileged operation request, the complete monitoring-verification-control process will be retried, and its initial network state will not be incorrectly blocked by residual rules from the previous event, ensuring the smoothness of legitimate operations; 3) State clarity: The firewall state always reflects the currently effective security policy, avoiding policy confusion or unpredictable access control behavior caused by historical rules. This step, together with the dynamic addition of S510 and the dynamic adjustment of S520 / S530, constitutes a closed-loop, self-cleaning network layer access control mechanism, which is an important guarantee for the efficient and accurate implementation of dynamic security policies on terminal devices.

[0111] Furthermore, the methods for protecting privileged operations on terminal devices also include:

[0112] S610: When the verification server continuously receives privileged operation requests from multiple security proxy programs from a predefined IP address pool within a preset time window, and all privileged operation requests meet the preset aggregation conditions.

[0113] The verification server continuously monitors privileged operation requests received from security agents on various terminal devices. When the server receives multiple privileged operation requests (exceeding a threshold number) consecutively within a preset, relatively short time window (e.g., 30 seconds or 1 minute), and analysis reveals that all these requests meet preset aggregation conditions, the aggregation token mechanism is triggered. The preset aggregation conditions include three key elements: 1) The cryptographic hash values ​​of the target files contained in the feature parameter sets of all requests are identical, meaning all operations target the same file on the disk (or files with the same content); 2) The operation type identifiers (e.g., "file deletion" or a specific high-risk command ID) of all requests are completely identical; 3) The network addresses (IP addresses) of all privileged operation source devices that initiate the requests belong to the same predefined IP address pool (e.g., the maintenance network segment 10.1.1.0 / 24 or a specific server cluster IP list). This concentrated burst of requests performing the same operation on the same file, originating from a trusted IP address pool, usually indicates automated maintenance tasks (e.g., batch updates or cleanups) rather than a single manual operation or malicious attack.

[0114] S620: Verify that the server generates a single aggregate token that is dynamically bound to the target file's cryptographic hash value and a predefined IP address pool, and set a second expiration window.

[0115] Once the conditions of step S610 are met, the verification server no longer generates independent tokens for each individual request, but instead performs aggregate authorization. The server uses a cryptographic mechanism similar to that used to generate a single token (possibly with simplified or modified input) to generate a single aggregate token. The core binding elements of this token are: the cryptographic hash value of the target file (identifying the file being operated on) and a predefined pool of IP addresses (identifying a set of source devices authorized to perform this operation). Simultaneously, the server sets a relatively long second validity window for this aggregate token (e.g., 10-30 minutes, much longer than the first validity window for a single token) to accommodate the execution time that batch operations may require. After generating this aggregate token, the verification server pushes or broadcasts it to all security agents from the predefined IP address pool that have initiated eligible requests within the preset time window (or notifies relevant management nodes to issue it).

[0116] S630: After receiving a single aggregate token, the security agent dynamically adds centralized allow rules to the network layer firewall tool.

[0117] When a security proxy (typically when its owning device IP belongs to the predefined IP address pool and its request meets the aggregation conditions) receives a single aggregation token from the verification server, it understands that a specific operation (type) targeting that particular file (hash value) has been granted bulk authorization within the IP address pool of its own device. At this point, the security proxy no longer waits for or needs to locally input verification codes for subsequent requests for the same operation (S400). Instead, it immediately activates the local network layer firewall to dynamically add a centralized allow rule, permitting the entire predefined IP address pool (as the allowed target, such as the source IP range 10.1.1.0 / 24) to access the preset high-risk port (as the allowed port) associated with the current privileged operation event (i.e., the specific operation type targeting that particular file hash). The validity period of the centralized allow rule is strictly synchronized with the second expiration window of the aggregation token.

[0118] S640: Within the second time window corresponding to the centralized allow rule, when any privileged operation source device in the predefined IP address pool initiates the same operation, the security agent program directly allows the operation to be executed.

[0119] After the centralized allowance rule added in step S630 takes effect, as long as the rule is within its second validity window, any privileged operation source device in the predefined IP address pool (i.e., any terminal within the IP pool) will directly allow access if its security agent detects a privileged operation event of the same type targeting the same target file's cryptographic hash value (i.e., the same file) (such as attempting to delete the file again or executing the same high-risk command). This achieves the following: 1) The security agent no longer triggers the remote token request and local verification process of S300-S400; 2) The security agent directly uses local system privileges to execute the operation command corresponding to the privileged operation (such as deleting the file or executing the command). This allowance greatly improves the efficiency of batch operations, and the execution of the allowed operation is still protected by the network layer centralized allowance rule (only authorized IP pools are allowed to access necessary ports).

[0120] Steps S610-S640 collectively construct an efficient aggregated authorization and execution mechanism for batch, homogeneous privileged operation scenarios. Through S610's intelligent identification (same file, same operation, same IP pool), the verification server can distinguish between automated maintenance tasks and sporadic operations or attacks. S620's aggregated token generation extends the authorization scope from a single device to the entire trusted IP address pool and sets a reasonably extended validity window (second validity window) for batch operations, significantly reducing the number of frequent interactions and verifications. S630's centralized allowance rules implement a unified allowance policy for the authorized IP pool at the endpoint firewall level, opening network channels for batch operations. S640's direct allowance logic, under the premise of authorized IP pool, same file, and same operation, completely bypasses the verification process for a single operation (S300-S400), achieving automated operation execution. The core value of this mechanism lies in its ability to significantly optimize the user experience and execution efficiency of legitimate, high-frequency batch operation and maintenance operations (such as configuration updates or log cleanup on large-scale servers) while maintaining strict security controls (authorization is still based on file fingerprints and operation types, network access is still precisely restricted to high-risk ports and authorized IP pools, and has a clear time limit). It avoids the latency and operational burden caused by massive single verifications. At the same time, through the predefined and centralized authorization of IP address pools, it ensures the controllability and auditability of batch operations, which is a key innovation that balances security and efficiency.

[0121] Furthermore, the preset aggregation conditions include: the cryptographic hash values ​​of the target files in all feature parameter sets are the same, all operation type identifiers are consistent, and the IP addresses of the privileged operation source devices that initiate the requests belong to the same predefined IP address pool.

[0122] The core basis for the verification server to determine whether the aggregation token mechanism (S610) has been triggered is the preset aggregation conditions, which include three strict elements that must be met simultaneously. First, the cryptographic hash values ​​of the target files in all feature parameter sets must be completely identical. Multiple privileged operation requests received within a preset time window must all target the same file (or multiple copies with identical content) on the disk. The uniqueness and collision resistance of the cryptographic hash value (such as SHA-256) ensure the precise object consistency of the operation. Second, all operation type identifiers must be completely identical, meaning that all requested operations belong to the same predefined high-risk operation category (e.g., all are "file deletion," or all execute the same specific high-risk command, such as rm -rf / critical / dir). The operation type identifier is usually a predefined enumeration value or string constant used to precisely distinguish different privileged operations. Finally, all privileged operation source device IP addresses initiating requests must belong to the same predefined IP address pool. This IP address pool is a logically related group of trusted devices pre-configured by the administrator (such as server IP segments belonging to the same maintenance VLAN, like 10.0.1.0 / 24, or a list of IPs for a specific application cluster). The verification server confirms the attribution by checking whether the request source IP falls within a predefined CIDR block or matches a predefined IP list. Only when all three conditions (same file hash, same operation type, same predefined IP pool) are met for multiple requests within a preset time window does the server determine that these requests represent a legitimate, homogeneous operation flow requiring batch processing (such as automated maintenance scripts executing the same cleanup task on multiple servers), thus satisfying the aggregation condition and triggering S620.

[0123] The centralized allow rules include: allowing access to all network addresses in the predefined IP address pool, allowing access to preset high-risk ports associated with the current privileged operation event, and allowing access to ports with a validity period synchronized with the second time limit window.

[0124] When a security agent dynamically adds a centralized allow rule based on a single aggregated token received, the rule has three key attributes that directly determine the network access control policy under bulk authorization. First, the allowed target is the entire network address pool of predefined IP addresses. This means the rule no longer targets a single source IP, but expands the allowance to all IP addresses contained in the entire predefined IP address pool that triggered the aggregation condition (e.g., the entire network segment 10.0.1.0 / 24 or all IPs in the list). When adding the rule, the security agent uses the CIDR representation of the entire address pool or the IP list as the source address matching field of the firewall rule (e.g., -s 10.0.1.0 / 24), allowing connections from any IP within the pool that meet the port conditions, thus adapting to the dispersed source IP characteristics of bulk operations. Second, the allowed port is a preset high-risk port associated with the current privileged operation event. Despite being bulk authorization, the target port range of the rule remains precise and minimized. The security agent queries and binds the corresponding preset high-risk ports (e.g., SSH operation bound to port 22, SMB operation bound to port 445) based on the privileged operation event type that triggered the aggregation mechanism (the operation type identifier is unified in the aggregation conditions), and sets these ports as the target ports of the rules (e.g., --dport 22), ensuring that even with batch permission, only the ports necessary to execute the specific operation are opened. Third, the validity period is synchronized with the second expiration window. The validity period of the centralized permission rule is not independent, but strictly bound to the second expiration window (S620) set by the verification server for the aggregation token. When adding a rule, the security agent uses the firewall tool's API to set a time-to-live (TTL) or expiration time point for the rule, the value of which is equal to the duration of the second expiration window issued by the server (or the expiration timestamp calculated by the server). For example, if the server sets the aggregation token validity period to 15 minutes, the added centralized permission rule will also automatically expire after 15 minutes, ensuring that batch authorization has a clear and controllable time boundary, and automatically revoking permission after timeout.

[0125] Accordingly, please refer to Figure 4 A second aspect of the present invention provides a terminal device privileged operation protection device, which protects a terminal device from privileged operation based on the above-described terminal device privileged operation protection method, including:

[0126] Event monitoring module 1 is used to monitor privileged operation events based on a security agent program deployed on the terminal device. Privileged operation events include: deleting files or executing predefined high-risk commands.

[0127] The parameter acquisition module 2 is used to acquire the set of characteristic parameters of the privileged operation event. The set of characteristic parameters includes at least: the cryptographic hash value of the target file, the operating system identifier of the triggering process, and the network address of the privileged operation source device.

[0128] Data exchange module 3 is used to send the feature parameter set to the verification server and receive the verification token generated by the verification server and dynamically bound to the feature parameter set;

[0129] Token verification module 4 is used to receive the input verification code through the security agent program and verify whether the input verification code matches the verification token returned by the verification server.

[0130] Policy execution module 5 is used to allow the execution of the operation corresponding to the privileged operation event if the verification matches, and to block the execution of the privileged operation event if the verification fails.

[0131] Accordingly, a third aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described terminal device privileged operation protection method.

[0132] Accordingly, a fourth aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described method for protecting privileged operations of a terminal device.

[0133] The embodiments of the present invention aim to protect a method and apparatus for privileged operation protection of terminal devices, and have the following effects:

[0134] 1. By dynamically and strongly binding the verification token to the operation context (file hash, process PID, operation source terminal device IP), the risk of generalization of traditional dynamic tokens is completely solved; attackers cannot forge or reuse tokens to launch cross-terminal attacks, the replay attack success rate is reduced from the industry average of >10% to <0.01%, and the interception success rate is 300% higher than the front-end behavior analysis solution, meeting the regulatory requirements for privileged operation auditing.

[0135] 2. Utilize iptables to directly control traffic permissions at the network layer, achieving a millisecond-level response of "blocking upon verification failure"; rule effective time is <5ms, which is two orders of magnitude better than the average latency of 500ms in zero-trust architecture, and the terminal agent memory usage is <50MB, supporting large-scale deployment on thousands of servers, and perfectly adapting to low-latency scenarios such as industrial control.

[0136] 3. When multiple legitimate users initiate operations on the same target file, a single aggregate token is generated by binding the file hash and the team IP pool, reducing the verification trigger frequency by 60%. Within the time window (e.g., 5 minutes), members of the predefined IP pool can perform the same operation without repeated verification. At the same time, the scope of permissions is constrained by both the file hash and the IP pool, balancing efficiency and security.

[0137] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0138] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0139] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0140] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0141] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for protecting privileged operation of a terminal device, characterized in that, Includes the following steps: S100, monitor privileged operation events based on a security agent program deployed on the terminal device, the privileged operation events including: deleting files or executing predefined high-risk commands; S200, obtain the feature parameter set of the privileged operation event, the feature parameter set including at least: the cryptographic hash value of the target file, the operating system identifier of the triggering process, and the network address of the privileged operation source device; S300, the feature parameter set is sent to the verification server, and the verification token generated by the verification server and dynamically bound to the feature parameter set is received; S400, the security agent program receives the input verification code and verifies whether the input verification code matches the verification token returned by the verification server; S500: If the verification matches, the operation corresponding to the privileged operation event is allowed to be executed; if the verification fails, the execution of the privileged operation event is blocked. The step S300, which involves sending the feature parameter set to the verification server and receiving the verification token generated by the verification server and dynamically bound to the feature parameter set, includes: S310, The security proxy program encrypts the set of feature parameters and sends it to the verification server; S320, the verification server is triggered to perform a cryptographic generation operation on the dynamically bound token based on the target file cryptographic hash value, the triggering process operating system identifier, and the privileged operation source device network address in the feature parameter set; S330, the security proxy program receives the verification token returned by the verification server, the verification token being the output result of the cryptographic student generation operation; The cryptographic student generation operation for dynamically bound tokens in S320 includes: S321, the verification server concatenates the target file cryptographic hash value, the triggering process operating system identifier, the privileged operation source device network address, the current system timestamp, and the cryptographically secure random number from the feature parameter set in a preset order to form an input sequence; S322, the verification server performs a key-based hash message authentication code operation on the input sequence to generate a fixed-length digest value; S323, the verification server converts the digest value into a decimal number sequence and extracts the last 6 digits as a dynamic binding token.

2. The terminal device privileged operation protection method according to claim 1, characterized in that, The monitoring of privileged operation events based on a security agent deployed on the terminal device in S100 includes: S110, Register an event listener with the system audit interface of the operating system through the security agent program, so that the system audit interface pushes file system operation requests and command line process execution requests to the event listener in real time; S120, receive the operation request data stream through the event listener, and match the operation behavior in the operation request data stream based on the predefined high-risk operation rule library; S130, when a file deletion command or high-risk command execution behavior is matched, a privileged operation event identifier containing a timestamp is generated.

3. The terminal device privileged operation protection method according to claim 1, characterized in that, The statement in S500 that if the verification matches, the operation corresponding to the privileged operation event is allowed to be executed; if the verification fails, the execution of the privileged operation event is blocked, includes: S510, after the privileged operation event is triggered and before dynamic verification is completed, the security agent program dynamically adds default blocking rules through the network layer firewall tools of the operating system to block the access of the privileged operation source device network address in the feature parameter set to the preset high-risk port, wherein the preset high-risk port is associated with and bound to the protocol type of the privileged operation event; S520, when the input verification code matches the verification token, the security agent program dynamically adds a temporary allow rule to the network layer firewall tool. After the temporary allow rule takes effect, the operation corresponding to the privileged operation event is executed through local system permissions. S530, when verification fails or timeout occurs, the security agent program maintains or updates the network layer firewall tool rules to continuously block the privileged operation source device network address from accessing the preset high-risk port.

4. The terminal device privileged operation protection method according to claim 3, characterized in that, The temporary release rule binds the privileged operation source device network address in the feature parameter set as the release object; The temporary release rule is bound to a preset high-risk port associated with the privileged operation event as the release port; The temporary release rule sets a first validity window as the validity period for executing the privileged operation event according to a preset strategy.

5. The terminal device privileged operation protection method according to claim 3, characterized in that, After the security agent program in S520 dynamically adds temporary allow rules to the network layer firewall tool, it also includes: After the privileged operation is completed or the temporary allow rule expires, the security agent program deletes the default blocking rule through the network layer firewall tool.

6. The terminal device privileged operation protection method according to any one of claims 1-5, characterized in that, Also includes: S610: When the verification server continuously receives privileged operation requests from multiple security proxy programs from a predefined IP address pool within a preset time window, and all the privileged operation requests meet the preset aggregation conditions; S620: The verification server generates a single aggregate token that is dynamically bound to the cryptographic hash value of the target file and the predefined IP address pool, and sets a second timeout window; S630: After receiving the single aggregated token, the security proxy program dynamically adds a centralized allow rule to the network layer firewall tool; S640: Within the second time window corresponding to the centralized release rule, when any privileged operation source device in the predefined IP address pool initiates the same operation, the security agent program directly allows the operation to be executed.

7. The terminal device privileged operation protection method according to claim 6, characterized in that, The preset aggregation conditions include: the cryptographic hash values ​​of the target files in all the feature parameter sets are the same, all operation type identifiers are consistent, and the IP addresses of the privileged operation source devices that initiate the requests belong to the same predefined IP address pool. The centralized access rules include: the access targets are all network addresses in the predefined IP address pool, and the access ports are preset high-risk ports associated with the current privileged operation event, with the validity period synchronized with the second time limit window.

8. A terminal device privileged operation protection device, characterized in that, The method for protecting privileged operations of a terminal device based on any one of claims 1-7 includes: The event monitoring module is used to monitor privileged operation events based on a security agent program deployed on the terminal device. These privileged operation events include: deleting files or executing predefined high-risk commands. The parameter acquisition module is used to acquire a set of characteristic parameters of the privileged operation event, the set of characteristic parameters including at least: the cryptographic hash value of the target file, the operating system identifier of the triggering process, and the network address of the privileged operation source device; The data exchange module is used to send the feature parameter set to the verification server and receive the verification token generated by the verification server and dynamically bound to the feature parameter set. The token verification module is used to receive the input verification code through the security agent program and verify whether the input verification code matches the verification token returned by the verification server. The policy execution module is used to allow the execution of the operation corresponding to the privileged operation event if the verification matches, and to block the execution of the privileged operation event if the verification fails.

Images