White list application method based on terminal security management system

Abstract

The invention discloses a white list application method based on a terminal security management system, which belongs to the technical field of terminal management, and comprises the following steps: acquiring memory instruction characteristics when an application program runs in a terminal, dynamically associating the memory instruction characteristics with a security handshake protocol certificate fingerprint, and generating a white list strategy library with a protocol verification rule; capturing an attack behavior by using an attack protection module, extracting DNS tunnel characteristics of the attack behavior in communication, generating a self-adaptive interception strategy, and synchronizing the self-adaptive interception strategy to a white list strategy library; analyzing a domain name analysis request initiated by the process, and executing white list matching and protocol compliance verification; network connection behaviors of processes in the terminal are monitored, an encrypted communication behavior graph is constructed, and an attack diffusion link formed by cross-process key transmission is identified; and when an attack diffusion link is identified, DNS tunnel encryption binding is triggered based on a protocol verification rule of a white list policy library, and a transmission behavior of an unauthorized encryption protocol is blocked.

Description

Technical Field

[0001] The present invention relates to the technical field of terminal management, and in particular to a whitelist application method based on a terminal security management system. Background Art

[0002] In traditional solutions, the terminal whitelist relies only on static matching of process features and fails to form a dynamic association with the network protocol layer. This allows attackers to forge process features to bypass terminal detection and use encrypted communications to establish covert channels. Terminal and network protection strategies are updated independently, and real-time collaborative interception based on protocol anomaly features is impossible.

[0003] Existing technologies rely on fixed thresholds and manual rules, lacking adaptive capabilities based on attack chain behavior, resulting in dynamic attack methods easily bypassing traditional detection rules; manual analysis of logs and manual adjustment of rules are required, making it difficult to cope with high-frequency attack scenarios. Summary of the Invention

[0004] In view of the above-mentioned problems, the present invention is proposed.

[0005] Therefore, the technical problem solved by the present invention is: how to solve the problem that dynamic attack means can easily bypass traditional detection rules and manual analysis is difficult to cope with high-frequency attack scenarios.

[0006] To solve the above technical problems, the present invention provides the following technical solutions: a whitelist application method based on a terminal security management system, which includes the following steps: collecting memory instruction features of the application program in the terminal during runtime, dynamically associating them with the fingerprint of the security handshake protocol certificate, and generating a whitelist policy library with protocol verification rules; using an attack protection module to capture attack behaviors, extracting the DNS tunnel features of the attack behaviors in the communication, generating an adaptive interception strategy and synchronizing it to the whitelist policy library; parsing the domain name resolution request initiated by the process, performing whitelist matching and protocol compliance verification; monitoring the network connection behavior of the process in the terminal, constructing an encrypted communication behavior map, and identifying the attack diffusion link formed by cross-process key transfer; when an attack diffusion link is identified, triggering DNS tunnel encryption binding based on the protocol verification rules of the whitelist policy library, blocking the transmission behavior of unauthorized encryption protocols; generating a visual report that integrates the abnormal features of the protocol, implementing network layer traffic isolation for the target address of the attack link, and iteratively updating the tunnel detection threshold of the whitelist policy library.

[0007] As a preferred solution of the whitelist application method based on the terminal security management system described in the present invention, the method comprises: dynamically associating with the security handshake protocol certificate fingerprint to generate a whitelist policy library with protocol verification rules, including: collecting the memory instruction sequence generated when the application is running and extracting the memory instruction features; obtaining the certificate fingerprint during the security handshake protocol negotiation phase, calculating the certificate fingerprint hash value and aligning the timestamp with the memory instruction features; establishing a mapping relationship between memory instruction and certificate fingerprint, and generating a whitelist policy library containing protocol version constraints and certificate chain verification rules.

[0008] As a preferred solution of the whitelist application method based on the terminal security management system described in the present invention, the attack protection module is used to capture attack behavior and extract the DNS tunnel characteristics of the attack behavior in the communication. Specifically, for the malicious process captured by the attack protection module, the domain name hierarchical structure and character entropy value distribution of the process DNS request are extracted as DNS tunnel characteristics.

[0009] As a preferred solution of the whitelist application method based on the terminal security management system described in the present invention, wherein: an adaptive interception strategy is generated and synchronized to the whitelist policy library, including: training a generative adversarial network based on historical attack data, and outputting a dynamic entropy value threshold of the DNS tunnel feature; marking domain names whose character entropy value distribution exceeds the dynamic entropy value threshold as high-risk tunnels, and obtaining a domain name blacklist; injecting a forged certificate revocation list into the DNS tunnel of the domain name in the domain name blacklist, inducing the attacking end to trigger a prompt of certificate verification failure as a response camouflage strategy; using the domain name blacklist and the response camouflage strategy to generate adaptive interception rules, and synchronizing them to the whitelist policy library.

[0010] As a preferred solution of the whitelist application method based on the terminal security management system described in the present invention, the dynamic entropy value threshold of the output DNS tunnel feature is specifically obtained by setting the initial entropy value threshold, obtaining a new sample to adjust the initial entropy value threshold, and obtaining a dynamic entropy value threshold.

[0011] As a preferred solution of the whitelist application method based on the terminal security management system described in the present invention, the execution of whitelist matching and protocol compliance verification refers to returning a resolution response of the dynamic port identifier to the domain name that successfully matches, and implementing protocol obfuscation blocking for the domain name that fails to match.

[0012] As a preferred solution of the whitelist application method based on the terminal security management system described in the present invention, wherein: monitoring the network connection behavior of the process in the terminal, and constructing an encrypted communication behavior graph includes: monitoring the negotiation process of the TLS handshake protocol and the custom encryption protocol in the process communication, and extracting the key exchange parameters; constructing a directed graph with the process as the node and the encrypted channel as the edge, marking the edges using the same asymmetric key pair as high-risk links, and obtaining an encrypted communication behavior graph.

[0013] As a preferred solution of the whitelist application method based on the terminal security management system described in the present invention, wherein: identifying the attack diffusion link formed by cross-process key transfer, including: sampling and decrypting the communication content of the high-risk link to obtain the inter-process key transfer status; verifying the protocol compliance of the high-risk link and the whitelist policy library, and combining the inter-process key transfer status to identify the attack diffusion link formed by cross-process key transfer.

[0014] As a preferred solution of the whitelist application method based on the terminal security management system described in the present invention, when an attack diffusion link is identified, the protocol verification rules based on the whitelist policy library trigger the DNS tunnel encryption binding to block the transmission behavior of unauthorized encryption protocols, including: when the attack diffusion link uses an encryption protocol not authorized by the whitelist policy library, forcibly upgrading the TLS protocol version and replacing the session key; for persistent unauthorized encryption protocol attack diffusion links, implementing blocking transmission behavior based on DNS tunnel characteristics.

[0015] As a preferred solution of the whitelist application method based on the terminal security management system described in the present invention, it generates a visual report of the abnormal characteristics of the fusion protocol, implements network layer traffic isolation for the target address of the attack link, and iteratively updates the tunnel detection threshold of the whitelist policy library. The specific steps are as follows: statistically analyze the DNS tunnel entropy value distribution and protocol abnormal characteristics of historical attack links, and construct a time sliding window model; when the attack success rate of the same feature in the window exceeds a preset ratio, update the tunnel detection threshold according to the gradient descent algorithm; synchronize the updated tunnel detection threshold and the associated IP address to the border routing device.

[0016] The beneficial effects of the present invention are as follows: the present invention significantly improves the identification capability of encrypted communication attack links through dynamic correlation verification of terminal memory instruction features and network protocol fingerprints, breaking through the blind spot of process feature and network behavior separation detection in traditional solutions; the DNS tunnel relies on the policy self-evolution mechanism driven by protocol anomaly features to realize closed-loop iterative update of the whitelist rule base, shifting security operation and maintenance from reliance on manual experience to an intelligent decision-making mode, greatly reducing the lag of defense strategies; and finally constructing multiple heterogeneous defense layers covering protocol fingerprint verification, dynamic port obfuscation, and encrypted channel binding, forcing attackers to simultaneously break through terminal behavior verification and network protocol protection to achieve penetration, greatly increasing attack costs and technical barriers. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 A system architecture diagram of a whitelist application method based on a terminal security management system provided in one embodiment of the present invention.

[0019] Figure 2 A dynamic association flow chart of a whitelist application method based on a terminal security management system is provided in one embodiment of the present invention.

[0020] Figure 3 An embodiment of the present invention provides an encrypted communication behavior graph based on a whitelist application method under a terminal security management system.

[0021] Figure 4 An embodiment of the present invention provides a policy iteration process of a whitelist application method based on a terminal security management system. DETAILED DESCRIPTION

[0022] To make the above-mentioned objects, features, and advantages of the present invention more clearly understood, the following detailed description of the specific embodiments of the present invention is given in conjunction with the accompanying drawings. It is obvious that the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary persons in this field without creative work should fall within the scope of protection of the present invention.

[0023] Reference Figures 1 to 4 , is an embodiment of the present invention, which provides a whitelist application method based on a terminal security management system.

[0024] like Figure 1 The following is a system architecture diagram of this method. It includes:

[0025] S1: Collect the runtime memory instruction features of the application in the terminal, dynamically associate them with the fingerprint of the security handshake protocol certificate, and generate a whitelist policy library with protocol verification rules.

[0026] The protocol fingerprint module collects the memory instruction sequence generated when the application is running and extracts the memory instruction features; obtains the certificate fingerprint during the security handshake protocol negotiation phase, calculates the certificate fingerprint hash value and aligns the timestamp with the memory instruction features; establishes a mapping relationship between memory instruction and certificate fingerprint, and generates a whitelist policy library that includes protocol version constraints and certificate chain verification rules.

[0027] Furthermore, memory instruction features are extracted by using the extended Berkeley Packet Filter (eBPF) to mount probes at the operating system kernel layer to capture the instruction sequence of memory pages when the application is running; the number of call instructions triggered per second is counted to obtain the call frequency, and processes with a call frequency lower than a low-risk threshold (such as ≤50 times / second) are filtered out; the instruction ratio of jmp instructions or call instructions in the instruction sequence is analyzed, and processes with an instruction ratio exceeding a high-risk threshold are marked as possible code injection; the instruction byte stream of non-contiguous memory areas is divided into blocks according to fixed bytes, the frequency of occurrence of each byte is counted and the Shannon entropy value is calculated, and static code segments with Shannon entropy values ​​lower than the predetermined Shannon entropy value are discarded.

[0028] It should be noted that the Shannon entropy value is calculated as follows:

[0029]

[0030] Among them, H is the Shannon entropy value, i is the index of the byte value, and p i is the probability of occurrence of byte value i in the data block.

[0031] Furthermore, the certificate fingerprint hash value is calculated and timestamp aligned with the memory instruction feature by capturing TLS messages in a network driver layer such as NDIS (a network driver development framework defined by Microsoft) or WinPcap (a user-mode network traffic capture driver framework implemented based on the Windows NDIS architecture), extracting the public key modulus and signature algorithm identifier of the digital certificate; performing a SHA-256 hash operation on the public key modulus to generate a fixed-bit hexadecimal certificate fingerprint; using a high-precision clock to record the memory instruction feature sampling time and the TLS handshake time, establishing a mapping relationship, and only associating the memory instruction feature sampling time and the TLS handshake time whose time deviation is within the predetermined time.

[0032] Furthermore, a mapping relationship between memory instruction and certificate fingerprint is established, and a whitelist policy library containing protocol version constraints and certificate chain verification rules is generated. This means that if the AES-NI instruction set is detected in the memory instruction (verified by the CPUID flag), the TLS protocol version number is required to be higher than the minimum security requirement version number, and weak encryption suites are disabled; for processes using self-signed certificates, the call frequency is required to be less than or equal to the high-risk threshold (preferably 100 times / second, used to exclude highly active malicious processes); the issuer chain of the process digital signature certificate includes a preset trusted root certificate (such as GlobalSign root CA); a key-value pair database (such as Redis) is used as the whitelist policy library, the key is the process SHA-256 hash value, and the value is a protocol rule set in JSON format, which contains certificate fingerprints, protocol version constraints and associated memory instruction thresholds.

[0033] It should be noted that this step builds a verifiable whitelist policy library by quantifying the dynamic association between memory behavior characteristics and network protocol fingerprints, providing precise rule support for subsequent real-time interception.

[0034] S2: Use the attack protection module to capture attack behaviors, extract the DNS (Domain Name Server) tunnel characteristics of attack behaviors in communication, generate adaptive interception strategies and synchronize them to the whitelist strategy library.

[0035] Specifically, the threat interception module extracts the domain name hierarchical structure and character entropy distribution of the malicious process captured by the attack protection module as the DNS tunnel feature; trains a generative adversarial network based on historical attack data to output the dynamic entropy threshold of the DNS tunnel feature; marks the domain name whose character entropy distribution exceeds the dynamic entropy threshold as a high-risk tunnel, and obtains a domain name blacklist; uses the domain name blacklist and the response masquerade strategy to generate adaptive interception rules and synchronize them to the whitelist policy library; the response masquerade strategy refers to injecting a forged certificate revocation list into the DNS tunnel to induce the attack end to trigger a certificate verification failure.

[0036] Furthermore, the DNS tunnel feature is extracted by capturing the DNS request of the malicious process through HookAPI (such as Win32's DnsQuery_A) to implement DNS request interception; extracting the domain name hierarchy structure and character entropy value distribution in the request message; counting the number of subdomains, marking requests with a subdomain number higher than a preset number as suspicious requests to obtain the domain name hierarchy; calculating the Shannon entropy value of the alphanumeric mixed characters in the domain name, setting the entropy value threshold, and determining the domain name with a Shannon entropy value higher than the entropy value threshold as a potential DGA generation, completing the character entropy value calculation.

[0037] Furthermore, the generator of the generative adversarial network uses a fully connected network, taking as input the node feature vectors of the encrypted behavior graph and outputting simulated Shannon entropy values. The discriminator of the generative adversarial network uses a CNN structure, taking as input both real and simulated Shannon entropy values ​​and outputting a probability value of authenticity. The activation function uses LeakyReLU, and the optimizer uses Adam. Simulated DGA domain names are constructed (e.g., using a Markov chain model to generate random strings) and output a set of simulated domain names. The generative adversarial network is trained based on historical attack data, outputting the coefficient of influence of attack samples on the entropy threshold.

[0038] Furthermore, the dynamic entropy threshold of the output DNS tunnel feature refers to setting an initial entropy threshold, adjusting the initial entropy threshold with a new sample (such as increasing the entropy threshold when the entropy value of the attack sample increases), and obtaining a dynamic entropy threshold.

[0039] Furthermore, the domain name blacklist is obtained by marking the domain names whose Shannon entropy values ​​exceed the dynamic entropy value threshold as high-risk tunnel domain names, generating a domain name blacklist and storing it in the Redis database (the key is the domain name hash value and the value is the interception strategy), thereby completing the high-risk domain name marking.

[0040] Furthermore, the response camouflage strategy is to point the high-risk domain name resolution result to the local address, limit the cache validity time, and construct a false record response; insert a pseudo-random padding field in the DNS response message to interfere with the attacker's data parsing and realize noise injection; for domain names that trigger the dynamic entropy value threshold multiple times in a row, add them to the permanent interception list and synchronize them to the local policy cache of all terminals.

[0041] It should be noted that this step uses dynamic threshold and response camouflage technology to achieve real-time detection of DNS covert tunnels and precise interception at the protocol layer, effectively countering variant DGA attacks.

[0042] S3: The domain name resolution request initiated by the resolution process performs whitelist matching and protocol compliance verification.

[0043] Specifically, the protocol verification module returns a resolution response of a dynamic port identifier to a successfully matched domain name, and implements protocol obfuscation blocking for a domain name that fails to match.

[0044] Furthermore, an interception point is set in the terminal's operating system network stack to capture the domain name resolution request initiated by the process, such as using a network packet capture tool (such as WinPcap) to obtain the DNS query message; the full domain name is extracted from the domain name resolution request and the domain name string is resolved; the identifier of the initiating process, such as the process ID (PID), is recorded for the captured domain name resolution request and associated with the corresponding request timestamp; the resolved domain name string is matched with the verification rules in the whitelist policy library to check whether the domain name string complies with the preset verification rules; if the match is successful, it is marked as a legitimate request; if the captured domain name is not found in the whitelist policy library, it is marked as a match failure. For the successfully matched domain name, further verification is performed to verify whether the memory instruction characteristics of the initiating process are consistent with the records in the whitelist policy library and protocol compliance verification is performed to check whether the network communication complies with the protocol rules in the whitelist policy library. For example, verification is performed to verify that the process initiating the request uses the TLS1.2 protocol and that the certificate fingerprint is consistent with the hash value stored in the whitelist policy library. If the verification is successful, a resolution response of the dynamic port identifier is returned, and the port number is randomly generated; for domain names that fail to match or are not protocol-compliant, the unauthorized TLS1.0 protocol is used, protocol obfuscation is implemented, and subsequent communications are interrupted.

[0045] It should be noted that matching the captured domain name refers to comparing the domain name string with the verification rules in the whitelist policy library to check whether the domain name string meets the preset verification rules; if it meets the preset verification rules, the match is successful; if it does not meet the preset verification rules, the match fails.

[0046] It should also be noted that this step implements real-time inspection of the process network behavior by parsing domain name resolution requests, performing whitelist matching and protocol compliance verification, ensuring that only compliant domain name requests receive normal resolution responses and unauthorized requests are effectively blocked.

[0047] S4: Monitor the network connection behavior of processes in the terminal, build an encrypted communication behavior map, and identify the attack diffusion links formed by cross-process key transfer.

[0048] Specifically, the behavioral analysis module monitors the negotiation process between the TLS handshake protocol and the custom encryption protocol in process communication, and extracts key exchange parameters; constructs a directed graph with processes as nodes and encrypted channels as edges, marks edges using the same asymmetric key pairs as high-risk links, and obtains an encrypted communication behavior graph; performs sample decryption on the communication content of high-risk links to obtain the inter-process key transfer status; verifies the protocol compliance of high-risk links with the whitelist policy library, and combines the inter-process key transfer status to identify the attack diffusion links formed by cross-process key transfer.

[0049] Furthermore, key exchange parameters are extracted by mounting a probe at the kernel layer of the terminal's operating system to capture the network connection behavior of processes in the terminal. For example, this involves using the Extended Berkeley Packet Filter (eBPF) to monitor the establishment of network sockets. Network communication events for each process are recorded, including the source process identifier, destination IP address, and port number. The cryptographic protocols involved in these network communication events are analyzed, for example, by capturing the ClientHello and ServerHello messages of the TLS handshake protocol to extract key exchange parameters, such as the Diffie-Hellman public key value or the RSA public key modulus.

[0050] Furthermore, the encrypted communication behavior graph is obtained based on the monitored network connection behavior, and a directed graph with processes as nodes and encrypted channels as edges is constructed; for example, if process A and process B establish a connection through TLS communication, nodes "A1" and "B1" are added to the encrypted communication behavior graph, and the encrypted channel between the two is represented by an edge; each edge is marked with the encryption protocol parameters used, such as TLS1.2 and the hash value of the key exchange parameters; and the out-degree and in-degree of each node in the encrypted communication behavior graph are counted.

[0051] Furthermore, the attack diffusion links formed by cross-process key transfer are identified by analyzing the edges in the encrypted communication behavior graph to identify connections using the same asymmetric key pair, such as process A and process B, and process B and process C sharing the same RSA public key modulus (n value). These edges are marked as high-risk links, indicating that cross-process key transfer behavior may exist. The communication content of high-risk links is sampled and decrypted, such as decrypting the byte data of the TLS session and extracting plaintext features. The sampling results are verified against the protocol compliance rules in the whitelist policy library, such as verifying whether the encryption suite authorized by the whitelist policy library is used. If unauthorized protocols or abnormal key transfers are found, the existence of an attack diffusion link is confirmed.

[0052] It should be noted that this step accurately locates the attack spread link by monitoring network connection behavior, building an encrypted communication behavior map and identifying cross-process key transfer, providing a basis for subsequent blocking measures.

[0053] S5: When an attack diffusion link is identified, the protocol verification rules based on the whitelist policy library trigger DNS tunnel encryption binding to block the transmission of unauthorized encryption protocols.

[0054] Specifically, when the attack diffusion link uses an encryption protocol that is not authorized by the whitelist policy library, the encryption binding module forces the upgrade of the TLS protocol version and replaces the session key; for the continuous unauthorized encryption protocol attack diffusion link, the transmission blocking behavior based on the DNS tunnel characteristics is implemented.

[0055] Furthermore, forced upgrades to the TLS protocol version and replacement of session keys are achieved through real-time monitoring of high-risk links identified in the encrypted communication behavior graph. For example, if an unauthorized encryption protocol (such as TLS 1.0) is detected between process A and process B, the protocol parameters of the high-risk link are compared with the verification rules in the whitelist policy library. For example, the whitelist policy library requires a minimum TLS protocol version of 1.2 and only allows specific encryption suites (such as key exchange algorithms, authentication algorithms, symmetric encryption algorithms, and hash algorithms). If the protocol version or suite used by the link does not meet the requirements, it is determined to be an unauthorized encryption protocol. For detected unauthorized encryption protocol links, the DNS tunnel encryption binding mechanism is triggered. For example, the TLS protocol version is forcibly upgraded from 1.0 to 1.2, and the session key is replaced with a new randomly generated symmetric key (such as a 256-bit AES key). A forged certificate revocation list (CRL) is injected into the DNS tunnel, for example, by constructing a CRL message containing the target certificate serial number to induce the receiving end to fail certificate verification. The bound communication is re-verified to ensure compliance with the rules of the whitelist policy library, such as checking whether the new session key matches the authorized suite.

[0056] Furthermore, blocking transmissions based on DNS tunnel characteristics involves blocking connections that continue to use weak encryption algorithms or have incomplete encryption binding. For example, if a link is detected to still use an obsolete encryption algorithm, protocol downgrade blocking is performed based on traffic characteristics analysis (such as packet length distribution), terminating the TCP connection. Blocking actions are logged, such as recording the source process ID, destination IP address, and blocking timestamp. This ensures that all transmissions using unauthorized encryption protocols are completely blocked.

[0057] It should be noted that this step ensures that terminal network communications comply with the verification rules of the whitelist policy library and prevents malicious transmission by detecting attack diffusion links, triggering DNS tunnel encryption binding and blocking unauthorized protocols.

[0058] S6: Generate a visual report of the abnormal characteristics of the fusion protocol, implement network layer traffic isolation for the target address of the attack link, and iteratively update the tunnel detection threshold of the whitelist policy library.

[0059] Specifically, the policy iteration module counts the DNS tunnel entropy distribution and protocol anomaly characteristics of historical attack links to build a time sliding window model; when the attack success rate of the same characteristics in the window exceeds the preset ratio, the tunnel detection threshold is updated according to the gradient descent algorithm; the updated tunnel detection threshold and the associated IP address are synchronized to the border routing device.

[0060] Furthermore, statistics on the DNS tunnel entropy distribution and protocol anomaly characteristics of historical attack links are collected. For example, the researchers analyze captured high-risk DNS requests and calculate the mean and standard deviation of their entropy values. The researchers also extract the frequency of unauthorized TLS versions or weak cipher suites to determine the proportion of anomalous protocols. The researchers then present the entropy distribution in a bar chart and the proportion of anomalous protocols in a pie chart, annotating the target IP addresses of the attack links to generate a visual report. Network-layer traffic isolation is then implemented for the target addresses identified in the visual report. For example, the target IP addresses are added to the access control list (ACL) of the border router, prohibiting inbound and outbound communication between the target IP addresses and the endpoint. Isolation rules are then set based on traffic characteristics to ensure that only malicious traffic is affected. For example, a drop rule can be configured on the router to drop packets from the target IP address and record the time the isolation takes effect. The effectiveness of the isolation can be verified, for example, by confirming that the target address is unreachable through a ping test.

[0061] Furthermore, the time sliding window model is constructed based on the statistical protocol anomaly features. The attack success rate of the same protocol anomaly features within the window is calculated by constructing the time sliding window model. The expression is:

[0062]

[0063] Among them, S k is the attack success rate of the kth time window, k is the index of the time window, e is the index of the protocol abnormality feature, and w e is the weight of the e-th protocol anomaly feature, and δ(e) is whether the protocol anomaly feature leads to a successful attack (1 = success, 0 = failure).

[0064] When the attack success rate is higher than the abnormal protocol ratio in the visualization report, the gradient descent algorithm is used to update the tunnel detection threshold; the updated tunnel detection threshold and the associated IP address are synchronized to the whitelist policy library and pushed to the border routing device to ensure that the network layer policy is globally effective.

[0065] It should be noted that the preset ratio is the ratio of abnormal protocols in the visualization report.

[0066] It should also be noted that this step achieves adaptive optimization of the whitelist policy library and effective containment of attack links by generating a visual report of the abnormal characteristics of the fusion protocol, implementing network layer traffic isolation, and iteratively updating the tunnel detection threshold.

[0067] In summary, the present invention significantly improves the identification ability of encrypted communication attack links through dynamic correlation verification of terminal memory instruction features and network protocol fingerprints, breaking through the blind spot of process features and network behavior separation detection in traditional solutions; the DNS tunnel relies on the policy self-evolution mechanism driven by protocol anomaly features to realize closed-loop iterative update of the whitelist rule base, shifting security operation and maintenance from reliance on manual experience to an intelligent decision-making mode, greatly reducing the lag of defense strategies; and finally constructing multiple heterogeneous defense layers covering protocol fingerprint verification, dynamic port obfuscation, and encrypted channel binding, forcing attackers to simultaneously break through terminal behavior verification and network protocol protection to achieve penetration, greatly increasing the attack cost and technical threshold.

[0068] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention, which should all be included in the scope of the claims of the present invention.

Claims

1. A whitelist application method based on a terminal security management system, characterized by: include, Collect the memory instruction features of the application runtime in the terminal, dynamically associate them with the fingerprint of the security handshake protocol certificate, and generate a whitelist policy library with protocol verification rules; Use the attack protection module to capture attack behaviors, extract the DNS tunnel characteristics of attack behaviors in communication, generate adaptive interception strategies and synchronize them to the whitelist strategy library; The domain name resolution request initiated by the resolution process performs whitelist matching and protocol compliance verification; Monitor the network connection behavior of processes in the terminal, build an encrypted communication behavior map, and identify attack diffusion links formed by cross-process key transfer; When an attack propagation link is identified, protocol verification rules based on the whitelist policy library trigger DNS tunnel encryption binding to block the transmission of unauthorized encryption protocols. Generate a visual report of the abnormal characteristics of the fusion protocol, implement network layer traffic isolation for the target address of the attack link, and iteratively update the tunnel detection threshold of the whitelist policy library.

2. A whitelist application method based on a terminal security management system according to claim 1, characterized in that: Dynamically associate with the security handshake protocol certificate fingerprint to generate a whitelist policy library with protocol verification rules, including: Collect memory instruction sequences generated when the application is running and extract memory instruction features; Obtain the certificate fingerprint during the security handshake protocol negotiation phase, calculate the certificate fingerprint hash value, and align the timestamp with the memory instruction feature; Establish a mapping relationship between memory instructions and certificate fingerprints, and generate a whitelist policy library that includes protocol version constraints and certificate chain verification rules.

3. A whitelist application method based on a terminal security management system according to claim 2, characterized in that: The attack protection module is used to capture attack behaviors and extract the DNS tunnel characteristics of attack behaviors in communications. Specifically, for malicious processes captured by the attack protection module, the domain name hierarchical structure and character entropy value distribution of the process DNS request are extracted as DNS tunnel characteristics.

4. A whitelist application method based on a terminal security management system according to claim 3, characterized in that: Generate an adaptive interception policy and synchronize it to the whitelist policy library, including: Generate adversarial networks based on historical attack data and output dynamic entropy thresholds for DNS tunnel features. Domain names whose character entropy value distribution exceeds the dynamic entropy value threshold are marked as high-risk tunnels, and a domain name blacklist is obtained; Injecting a forged certificate revocation list into the DNS tunnel of a domain name on the domain blacklist to trick the attacker into triggering a prompt indicating that the certificate verification failed as a response to the camouflage strategy; Use domain name blacklists and response masquerading strategies to generate adaptive interception rules and synchronize them to the whitelist policy library.

5. A whitelist application method based on a terminal security management system according to claim 4, characterized in that: Specifically, the dynamic entropy value threshold of the output DNS tunnel feature is obtained by setting an initial entropy value threshold, obtaining a new sample, adjusting the initial entropy value threshold, and obtaining a dynamic entropy value threshold.

6. A whitelist application method based on a terminal security management system according to claim 5, characterized in that: Performing whitelist matching and protocol compliance verification means returning a resolution response with a dynamic port identifier for successfully matched domain names, and implementing protocol obfuscation blocking for unmatched domain names.

7. A whitelist application method based on a terminal security management system according to claim 6, characterized in that: Monitor the network connection behavior of processes in the terminal and build an encrypted communication behavior map, including: Monitor the negotiation process between the TLS handshake protocol and the custom encryption protocol in process communication and extract key exchange parameters; A directed graph with processes as nodes and encrypted channels as edges is constructed, and edges using the same asymmetric key pairs are marked as high-risk links to obtain an encrypted communication behavior graph.

8. A whitelist application method based on a terminal security management system according to claim 7, characterized in that: Identify the attack propagation links formed by cross-process key transfer. The specific steps are as follows: Decrypt the communication content of high-risk links to obtain the inter-process key transfer status; Verify the protocol compliance of high-risk links and the whitelist policy library, and combine the inter-process key transfer status to identify the attack spread links formed by cross-process key transfer.

9. A whitelist application method based on a terminal security management system according to claim 7, characterized in that: When an attack propagation link is identified, protocol verification rules based on the whitelist policy library trigger DNS tunnel encryption binding to block the transmission of unauthorized encryption protocols, including: When the attack propagation link uses an encryption protocol not authorized by the whitelist policy library, the TLS protocol version is forcibly upgraded and the session key is replaced; For persistent unauthorized encryption protocol attacks spreading through links, blocking transmission based on DNS tunnel characteristics is implemented.

10. A whitelist application method based on a terminal security management system according to claim 7, characterized in that: Generates a visual report of protocol anomaly characteristics, implements network-layer traffic isolation for the target address of the attack link, and iteratively updates the tunnel detection threshold of the whitelist policy library, including: The DNS tunnel entropy distribution and protocol anomaly characteristics of historical attack links are statistically analyzed to construct a time sliding window model. When the attack success rate of the same feature in the window exceeds the preset ratio, the tunnel detection threshold is updated according to the gradient descent algorithm; Synchronize the updated tunnel detection threshold and associated IP address to the border routing device.

Images