A whitelist-based system defense method, device, medium and electronic equipment

Abstract

This application provides a system defense method, apparatus, medium, and electronic device based on a whitelist. The system defense method includes: obtaining a target whitelist policy file based on the attribute information of a file to be processed, wherein the target whitelist policy file is one of multiple whitelist policy files, and the multiple whitelist policy files include at least a system whitelist policy file and a container whitelist policy file; and determining whether the file to be processed is a loadable or executable file based on the target whitelist policy file. The whitelist policy file in this application stores hash values ​​and file paths. When executing or loading a file, the corresponding file can be quickly located through the file path and its hash value compared, improving processing speed. This application is compatible with kernel module files, script files, and files not directly stored in the system (e.g., Docker image files).

Description

Technical Field

[0001] This application relates to the field of system security, and more specifically, the embodiments of this application relate to a system defense method, apparatus, medium, and electronic device based on a whitelist. Background Technology

[0002] With the rapid development of computer technology, various applications are emerging and affecting all aspects of life, thus computer information security is receiving increasing attention. There are many methods for computer system security defense, among which the application of whitelisting technology is one of the most common.

[0003] The whitelist-based system defense methods disclosed in the relevant technologies also have the following defects: they rely heavily on the prelink mechanism when capturing dynamic library files and executable programs; calculating the current hash value by running or loading dynamic library files and executable programs results in low efficiency; allowing or denying execution and loading based solely on the comparison between the current hash value and the original hash value results in poor compatibility, making them incompatible with kernel module files and script files, as well as files in isolated file systems (such as Docker containers).

[0004] Therefore, how to improve the system defense methods of related technologies has become an urgent technical problem to be solved. Summary of the Invention

[0005] The purpose of this application is to provide a system defense method, device, medium, and electronic device based on a whitelist. The whitelist policy file of this application stores hash values ​​and file paths. When executing or loading a file, the corresponding file can be quickly located through the file path and its hash value can be compared to improve processing speed. The embodiments of this application are compatible with kernel module files, script files, and files not directly stored in the system (such as Docker image files).

[0006] In a first aspect, embodiments of this application provide a system defense method based on a whitelist. The system defense method includes: obtaining a target whitelist policy file based on the attribute information of a file to be processed, wherein the target whitelist policy file is one of multiple whitelist policy files, and the multiple whitelist policy files include at least a system whitelist policy file and a container whitelist policy file; and determining whether the file to be processed is a loadable or executable file based on the target whitelist policy file.

[0007] Some embodiments of this application set up multiple types of whitelist policy files, and matched the corresponding whitelist policy file with the attributes of the file to be processed, which can improve the versatility of the technical solution.

[0008] In some embodiments, the attribute information is represented using the namespace of the file to be processed.

[0009] Some embodiments of this application use the namespace of the file to be processed to select the corresponding whitelist policy file for the file to be processed, thereby improving the speed of selecting the target whitelist policy file from multiple whitelist policy files.

[0010] In some embodiments, obtaining the target whitelist policy file based on the attribute information of the file to be processed includes: obtaining the namespace where the file to be processed is located; and obtaining the target whitelist policy file from the plurality of whitelist policy files based on the namespace.

[0011] Some embodiments of this application require first obtaining the namespace of the file to be processed, and then obtaining the target whitelist policy file based on the namespace.

[0012] In some embodiments, the file to be processed is a script file, wherein, before obtaining the namespace where the file to be processed is located, obtaining the target whitelist policy file based on the attribute information of the file to be processed further includes: registering a script interpreter hook to hijack the script interpreter; obtaining the script file name by parsing the parameters of the script interpreter; and obtaining the namespace corresponding to the file to be processed based on the script file name.

[0013] Some embodiments of this application can also provide security protection for script files, thereby improving the versatility of the technical solution.

[0014] In some embodiments, the target whitelist policy file is used to store at least the hash value of the security application and the file path of the security application; wherein, determining whether the file to be processed is a loadable or executable file according to the target whitelist policy file includes: if the file to be processed is found to exist in the target whitelist policy file according to the file path of the file to be processed, then the hash value of the file to be processed is calculated to obtain a matching hash value and the file to be processed is determined to be an executable or loadable file according to the matching hash value; if the file to be processed is not found in the target whitelist policy file according to the file path of the file to be processed, then the execution or loading of the file to be processed is refused.

[0015] Some embodiments of this application first determine whether the file is in the whitelist policy by checking the file path. If it is not, it indicates that the file is a Trojan program. At this time, the system will prohibit the execution or loading of the file. Compared with the relevant technical solutions that directly compare hash values, this significantly improves the processing speed and further enhances the security of the system.

[0016] In some embodiments, determining whether the file to be processed belongs to the executable or loadable file based on the hash value to be matched includes: reading the storage hash value corresponding to the file to be processed from the target whitelist policy file; comparing the hash value to be matched with the storage hash value; if the two are inconsistent, prohibiting the execution or loading of the file to be processed; if the two are consistent, executing or loading the file to be processed.

[0017] Some embodiments of this application compare the hash value of the file to be processed with the hash value stored in the whitelist policy file, which can improve the accuracy of the judgment result.

[0018] In some embodiments, before obtaining the target whitelist policy file based on the attribute information of the file to be processed, the method further includes: scanning the system file directory to filter out a set of target files by means of file headers, wherein the types of files in the target file set include: dynamic library files, executable binary programs, kernel modules and script files; and obtaining multiple types of whitelist policy files based on the target file set.

[0019] Some embodiments of this application identify application whitelist files by judging the file header, thus no longer relying on the prelink mechanism. The whitelist policy generation has low dependency and can be generated on any Linux system.

[0020] In some embodiments, obtaining multiple whitelist policy files based on the target file set includes: calculating the hash value of each target file in the target file set to obtain multiple storage hash values; obtaining the file path corresponding to each target file in the target file set to obtain multiple file paths; and unifying the multiple storage hash values ​​and the multiple file paths as the content of the whitelist policy file.

[0021] Some embodiments of this application require storing hash values ​​and file paths in each whitelist policy file. This allows for a preliminary judgment based on the file path followed by a secondary judgment based on the hash value when performing security authentication on the files to be processed. This improves system security and also increases data processing speed by reducing the number of hash value matching operations.

[0022] In some embodiments, after unifying the plurality of storage hash values ​​and the plurality of file paths as the content of the whitelist policy file, the method further includes: signing the whitelist policy file.

[0023] To further enhance the security of the whitelist policy file, some embodiments of this application also require signing the whitelist policy file.

[0024] In some embodiments, the system file directory includes target items obtained by decompressing files within the image.

[0025] Some embodiments of this application require processing of files within containers when generating various whitelist policy files, thereby improving the versatility of the technical solution.

[0026] In some embodiments, after obtaining multiple whitelist policy files based on the target file set, the method further includes: importing the system whitelist policy and the container whitelist policy file into the user-mode system runtime environment to determine whether the file to be processed belongs to the executable or loadable file based on the system whitelist policy or the container whitelist policy file.

[0027] Some embodiments of this application also require importing multiple types of whitelist policy files into the system so that the imported whitelist policy files can be used to identify file security when the system is running or loading files, thereby improving the system's security.

[0028] In some embodiments, importing the system whitelist policy file in the user-mode system runtime environment includes: automatically calling a whitelist policy import tool to send the system whitelist policy file to the Linux system via netlink communication when the Linux system starts; verifying the system whitelist policy file; and storing the system whitelist policy file in memory if the policy verification is successful.

[0029] Some embodiments of this application provide a method for importing a system whitelist policy file. When importing the file, the file needs to be verified to ensure the legality of the imported file, thereby improving the accuracy and security of subsequent security identification of files to be processed based on the file.

[0030] In some embodiments, importing the container whitelist policy file in the user-mode system runtime environment includes: automatically scanning the container whitelist policy file in the image corresponding to the Docker container when the system starts; verifying the container whitelist policy file; and storing the container whitelist policy file in memory after the policy verification is successful.

[0031] Some embodiments of this application provide a method for importing a container whitelist policy file. When importing the file, the file needs to be verified to ensure the legality of the imported file, thereby improving the accuracy and security of subsequent security identification of files to be processed based on the file.

[0032] In some embodiments, the container whitelist policy file and the system whitelist policy file are stored separately in the memory by determining the namespace.

[0033] Some embodiments of this application store the system whitelist policy file and the container whitelist policy file separately, which can improve the speed of data matching.

[0034] Secondly, some embodiments of this application provide a whitelist-based system defense device, the system defense device comprising: a target whitelist policy file acquisition module, configured to obtain a target whitelist policy file based on the attribute information of the file to be processed, wherein the target whitelist policy file is one of multiple whitelist policy files, the multiple whitelist policy files including at least: a system whitelist policy file and a container whitelist policy file; and a security determination module, configured to determine whether the file to be processed is a loadable or executable file based on the target whitelist policy file.

[0035] Thirdly, some embodiments of this application provide a computer storage medium having a computer program stored thereon, which, when executed by a processor, can implement the methods described in any of the embodiments of the first aspect above.

[0036] Fourthly, some embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement the method described in any of the embodiments of the first aspect above. Attached Figure Description

[0037] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 An architecture diagram of a whitelist-based defense system provided for embodiments of this application;

[0039] Figure 2 One of the flowcharts for a whitelist-based system defense method provided in this application embodiment;

[0040] Figure 3 The second flowchart of the whitelist-based system defense method provided in the embodiments of this application;

[0041] Figure 4A flowchart illustrating the method for generating various whitelist strategy files provided in this application embodiment;

[0042] Figure 5 A flowchart illustrating the method for importing various whitelist strategy files provided in this application embodiment;

[0043] Figure 6 The third flowchart of the whitelist-based system defense method provided in the embodiments of this application;

[0044] Figure 7 A block diagram illustrating the composition of a whitelist-based system defense device provided in this application embodiment;

[0045] Figure 8 This is a schematic diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0046] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0047] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0048] To address the problems identified in the background section, some embodiments of this application identify application whitelist files by judging file headers, thus eliminating reliance on the prelink mechanism. Some embodiments of this application can intercept script interpreters and protect script files. Some embodiments of this application can differentiate whitelist policies based on namespaces (i.e., deploying multiple whitelist policy files, such as system whitelist policy files and container whitelist policy files), further accelerating application whitelist lookup and matching efficiency. In other words, embodiments of this application provide a system defense method with low dependency, strong compatibility, and high efficiency. In some embodiments of this application, this method involves: whitelist policy generation, whitelist policy import, and whitelist file matching.

[0049] Please refer to Figure 1 , Figure 1 The whitelist-based defense system provided in this application includes a server 110, a first terminal 140, a first firewall 130, and a second firewall 120.

[0050] Understandably, in order to improve the security of the first terminal 140, the first firewall 130, and the second firewall 120, multiple whitelist policy files generated by the server 110 can be deployed on these devices.

[0051] It should be noted that, Figure 1 This is merely one application scenario of an embodiment of this application. In other embodiments of this application, the whitelist policy files obtained from some embodiments of this application can be deployed on other devices or systems with security requirements besides terminals or firewalls. In some embodiments of this application, the whitelist policy files can also be generated by the terminal or firewall itself.

[0052] The methods for generating various whitelist strategies, importing various whitelist strategies, and determining the files to be processed based on various whitelist strategy files in some embodiments of this application differ from related technologies.

[0053] The following is combined with Figure 2 This paper exemplifies a method for determining the security of files to be processed based on multiple whitelist policy files, executed by devices such as server 110 or firewall.

[0054] like Figure 2 As shown, this application embodiment provides a system defense method based on a whitelist, the system defense method including:

[0055] S101, obtain the target whitelist policy file based on the attribute information of the file to be processed, wherein the target whitelist policy file is one of multiple whitelist policy files, and the multiple whitelist policy files include at least: a system whitelist policy file and a container whitelist policy file.

[0056] For example, in some embodiments of this application, the attribute information is represented using the namespace of the file to be processed. That is, some embodiments of this application use the namespace of the file to be processed to select the corresponding whitelist policy file for the file to be processed, thereby improving the speed of selecting the target whitelist policy file from multiple whitelist policy files.

[0057] For example, in some embodiments of this application, S101 typically includes: obtaining the namespace where the file to be processed is located; and obtaining the target whitelist policy file from the plurality of whitelist policy files based on the namespace. Some embodiments of this application require first obtaining the namespace of the file to be processed, and then obtaining the target whitelist policy file based on the namespace. It should be noted that, to improve the security of script files, in some embodiments of this application, the file to be processed is a script file. Before obtaining the namespace where the file to be processed is located, S101 typically includes: registering a script interpreter hook to hijack the script interpreter; obtaining the script filename of the script file by parsing the parameters of the script interpreter; and obtaining the namespace corresponding to the file to be processed based on the script filename. Some embodiments of this application can also provide security defenses for script files, improving the versatility of the technical solution.

[0058] S102, determine whether the file to be processed is a loadable or executable file based on the target whitelist policy file. It is easy to understand that some embodiments of this application set multiple types of whitelist policy files, matching the corresponding whitelist policy file to the attributes of the file to be processed, which can improve the versatility of the technical solution.

[0059] For example, in some embodiments of this application, the target whitelist policy file is used to store at least the hash value of the security application and the file path of the security application; wherein, S102 includes, for example, if it is determined that the file to be processed exists in the target whitelist policy file based on the file path of the file to be processed, then the hash value of the file to be processed is calculated to obtain a matching hash value, and the file to be processed is determined to belong to the executable or loadable file based on the matching hash value. For example, in some embodiments of this application, the step of determining whether the file to be processed belongs to the executable or loadable file based on the matching hash value includes, for example, reading the stored hash value corresponding to the file to be processed from the target whitelist policy file; comparing the matching hash value with the stored hash value, and if the two are inconsistent, prohibiting the execution or loading of the file to be processed, and if the two are consistent, executing or loading the file to be processed. Some embodiments of this application compare the hash value of the file to be processed with the hash value stored in the whitelist policy file to improve the accuracy of the judgment result.

[0060] For example, in some embodiments of this application, the target whitelist policy file is used to store at least the hash value of the security application and the file path of the security application; wherein, S102 includes, for example, if it is determined that the file to be processed does not exist in the target whitelist policy file based on the file path of the file to be processed, then the execution or loading of the file to be processed is refused.

[0061] Some embodiments of this application first determine whether the file is in the whitelist policy by checking the file path. If it is not, it indicates that the file is a Trojan program. At this time, the system will prohibit the execution or loading of the file. Compared with the relevant technical solutions that directly compare hash values, this significantly improves the processing speed and further enhances the security of the system.

[0062] The following is combined with Figure 3 This paper exemplifies a system defense method based on whitelists, specifically referring to the process of matching whitelist files involved in this method.

[0063] The first step is to execute or load the file in user space.

[0064] The second step is to determine whether the file is a script to be interpreted and executed. If so, a script interpreter hook is used to hijack the script interpreter (which means that a script interpreter hook needs to be registered first), and the script file name is obtained by parsing the interpreter parameters to get the corresponding script file name. Otherwise, the third step is executed.

[0065] The third step is namespace determination, which determines the type of whitelist strategy to use based on the namespace where the current file is located.

[0066] The fourth step is to determine if the file exists by checking the file path.

[0067] The system determines whether a file is in the whitelist policy by checking its file path. If it is not, the file is considered a Trojan program, and the system will prevent it from being executed or loaded. If it is, the following steps will be executed.

[0068] The fifth step is to obtain the corresponding storage hash value from the whitelist policy.

[0069] Step 6: Calculate the current hash value of the file.

[0070] The seventh step is to determine whether the stored hash value and the current hash value are equal. If not, the execution or loading of the corresponding file will be refused. If they are equal, the execution or loading of the corresponding file will proceed.

[0071] Steps five through seven above are performed to calculate the current hash value of the file and compare it with the hash value in the policy. If the two are inconsistent, it indicates that the file has been tampered with, and the system will also prohibit the execution or loading of the file.

[0072] The following examples illustrate methods for generating various whitelist policy files.

[0073] In some embodiments of this application, a method for generating various list policy files is included before S101, wherein examples of such methods include:

[0074] The first step is to scan the system file directory and filter the target file set by file header method. The types of files in the target file set include: dynamic library files, executable binary programs, kernel modules and script files.

[0075] To improve the versatility of the technical solution, in some embodiments of this application, the system file directory described in the first step includes target items obtained by decompressing files within the image. Some embodiments of this application also require processing of files within the container when generating various whitelist policy files, further enhancing the versatility of the technical solution.

[0076] The second step is to obtain multiple types of whitelist policy files based on the target file set.

[0077] For example, in some embodiments of this application, the second step of obtaining multiple whitelist policy files based on the target file set includes: calculating the hash value of each target file in the target file set to obtain multiple stored hash values; obtaining the file path corresponding to each target file in the target file set to obtain multiple file paths; and unifying the multiple stored hash values ​​and the multiple file paths as the content of the whitelist policy file. Some embodiments of this application require storing hash values ​​and file paths in each whitelist policy file, so that when performing security authentication on files to be processed, a preliminary judgment can be made first based on the file path, followed by a secondary judgment based on the hash value. This improves system security and also increases data processing speed and hash value matching speed by reducing the number of hash value matching operations.

[0078] It is understandable that some embodiments of this application identify the application whitelist file by judging the file header when generating the whitelist policy file, thus no longer relying on the prelink mechanism. The whitelist policy generation has low dependency and can be generated on any Linux system.

[0079] To import a more secure whitelist policy file into the system, some embodiments of this application also require signing the generated whitelist policy to obtain the final whitelist policy file. That is, in some embodiments of this application, after unifying the multiple storage hash values ​​and multiple file paths as the content of the whitelist policy file, the method further includes: signing the whitelist policy file.

[0080] The following is combined with Figure 4 This example illustrates the process of generating a whitelist policy file.

[0081] The first step is to call the whitelist policy generation tool.

[0082] Under Linux, a whitelist policy generation tool is used to identify application whitelist files by judging the file header (ELF format files, script files), and then filter out dynamic library files (ELF format files), executable binary programs (ELF format files), kernel modules (ELF format files), and script files.

[0083] The second step is to determine if it is a Docker image file. If it is, extract the files from the image to the system file directory; otherwise, extract various file formats directly from the system file directory. Figure 4 ELF format files or script files.

[0084] It should be noted that the hash values ​​corresponding to the above file types are calculated, and their file paths and hash values ​​are stored together in the whitelist policy file; the whitelist policy file is then signed to prevent malicious tampering. This completes the process. Figure 4 The whitelist strategy is shown. Figure 4 The process also requires replaying the obtained container whitelist policy into the Docker image. In other words, some embodiments of this application can be used to generate whitelist policies for files within a Docker image.

[0085] The following example illustrates the process of importing the generated whitelist policy file.

[0086] In some embodiments of this application, after obtaining multiple whitelist policy files based on the target file set, the method further includes: importing the system whitelist policy and the container whitelist policy file into the user-mode system runtime environment to determine whether the file to be processed belongs to the executable or loadable file category based on the system whitelist policy or the container whitelist policy file. Some embodiments of this application also require importing multiple whitelist policy files into the system so that when the system runs or loads files, the imported whitelist policy files can be used for file security identification, thereby improving system security.

[0087] In some embodiments, importing the system whitelist policy file in the user-mode system runtime environment includes: automatically calling a whitelist policy import tool to send the system whitelist policy file to the Linux system via netlink communication when the Linux system starts; verifying the system whitelist policy file; and storing the system whitelist policy file in memory if the policy verification is successful. Some embodiments of this application provide a method for importing a system whitelist policy file, and the file needs to be verified during import to ensure the legality of the imported file, thereby improving the accuracy and security of subsequent security identification of files to be processed based on the file.

[0088] In some embodiments, importing the container whitelist policy file into the user-space system runtime environment includes: automatically scanning for container whitelist policy files in the image corresponding to the Docker container during system startup; verifying the container whitelist policy file; and storing the container whitelist policy file in memory if the policy verification is successful. Some embodiments of this application provide a method for importing a container whitelist policy file, and the file needs to be verified during import to ensure the legality of the imported file, thereby improving the accuracy and security of subsequent security identification of files to be processed based on the file.

[0089] like Figure 5 As shown in the figure, the method includes the following processing steps.

[0090] Step 1: Import whitelist policy tool

[0091] Since the above scheme generates support for whitelists within Docker containers, the whitelist policies need to be processed separately when imported. To make it easier to distinguish, the above two policies are divided into: system whitelist policy files (policies generated directly from ordinary files stored in the root directory of the system) and container whitelist policy files (policies generated from files inside the Docker image).

[0092] Please refer to Figure 5 The system whitelist policy file import process in some embodiments of this application includes:

[0093] 1) When the Linux system starts, the whitelist policy import tool is automatically invoked to send the whitelist policy to the system via netlink communication.

[0094] 2) After receiving the policy distribution request, the system verifies the signature of the whitelist policy (to prevent the policy from being maliciously tampered with);

[0095] 3) After the policy verification is successful, the corresponding policy is stored in memory.

[0096] Please refer to Figure 5 The container whitelist policy import process in some embodiments of this application includes:

[0097] 1) When a Docker container is created and started, the system automatically scans the whitelist policy in the image;

[0098] 2) Verify the signature of the whitelist policy in the mirror (to prevent the policy from being maliciously tampered with);

[0099] After the policy is verified, the corresponding policy is stored in memory. The container whitelist policy and the system whitelist policy are separated by judging the namespace, thereby improving the efficiency of whitelist lookup and matching.

[0100] It should be noted that, in some embodiments of this application, the container whitelist policy file and the system whitelist policy file are stored separately in memory by determining the namespace. Separating the system whitelist policy file and the container whitelist policy file in some embodiments of this application can improve the speed of data matching.

[0101] The following is combined with Figure 6 This document provides an example of the process of generating a whitelist policy file, importing the whitelist policy file, and matching the whitelist policy file.

[0102] First, in the whitelist processing and generation environment, start the whitelist policy generation tool, use this tool to scan system file destinations, and generate the corresponding whitelist policy file.

[0103] Secondly, the whitelist policy import process is initiated in user space within the system runtime environment. This involves importing the whitelist policies, performing read verification, importing multiple types of whitelist policy files into the system, and then executing or loading these files. This step runs in user space.

[0104] Finally, the whitelist file matching process is initiated in the kernel mode of the system runtime environment. During this process, the file path is used to determine if the file is in the whitelist; otherwise, execution or loading is refused. If the file is in the whitelist, the current hash value of the file is calculated, the corresponding stored hash value in the whitelist policy is obtained, and the stored hash value is compared with the current hash value. If they are equal, loading or execution is allowed; otherwise, execution or loading is refused.

[0105] Please refer to Figure 7 , Figure 7 The present application illustrates a whitelist-based system defense device. It should be understood that this device is similar to the one described above. Figure 2 Corresponding to the method embodiments, it can execute the various steps involved in the above method embodiments. The specific functions of the device can be found in the description above. To avoid repetition, detailed descriptions are appropriately omitted here. The device includes at least one software function module that can be stored in the memory or embedded in the device's operating system in the form of software or firmware. This whitelist-based system defense device includes: a target whitelist policy file acquisition module 101 and a security decision module 102.

[0106] The target whitelist policy file acquisition module 101 is configured to obtain the target whitelist policy file based on the attribute information of the file to be processed. The target whitelist policy file is one of multiple whitelist policy files, which include at least: a system whitelist policy file and a container whitelist policy file.

[0107] The security decision module 102 is configured to determine whether the file to be processed is a loadable or executable file based on the target whitelist policy file.

[0108] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0109] Some embodiments of this application provide a computer storage medium having a computer program stored thereon, which, when executed by a processor, can implement the methods described in any of the above embodiments.

[0110] like Figure 8 As shown, some embodiments of this application provide an electronic device 500, which includes a memory 510, a processor 520, and a computer program stored in the memory 510 and executable on the processor 520. When the processor 520 reads and executes the program via a bus 530, it can implement the methods described in any of the above embodiments.

[0111] Processor 520 can process digital signals and can include various computing architectures. For example, it can be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 520 can be a microprocessor.

[0112] The memory 510 can be used to store instructions executed by the processor 520 or data related to the execution of instructions. These instructions and / or data may include code used to implement some or all of the functions of one or more modules described in the embodiments of this application. The processor 520 of the embodiments of this disclosure can be used to execute the instructions in the memory 510 to implement… Figure 2 The method shown. Memory 510 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memory well known to those skilled in the art.

[0113] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0114] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0115] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0116] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

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

[0118] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A whitelist-based system defense method, characterized by, The system defense methods include: The target whitelist policy file is obtained based on the attribute information of the file to be processed. The target whitelist policy file is one of multiple whitelist policy files, which include at least: a system whitelist policy file and a container whitelist policy file. Determine whether the file to be processed is a loadable or executable file based on the target whitelist policy file; Before obtaining the target whitelist policy file based on the attribute information of the file to be processed, the method further includes: The system file directory is scanned to filter out a set of target files by file headers. The types of files in the target file set include: dynamic library files, executable binary programs, kernel modules, and script files. Multiple whitelist policy files are obtained based on the target file set; After obtaining multiple types of whitelist policy files based on the target file set, the method further includes: Import the system whitelist policy and the container whitelist policy file into the user-mode system runtime environment to determine whether the file to be processed belongs to the executable or loadable file according to the system whitelist policy or the container whitelist policy file; The importing of the system whitelist policy file into the user-mode system runtime environment includes: When the Linux system starts up, the whitelist policy import tool is automatically invoked to send the system whitelist policy file to the Linux system via netlink communication. The system whitelist policy file is verified. If the policy verification is successful, the system whitelist policy file is then stored in memory.

2. The system defense method of claim 1, wherein, The attribute information is represented using the namespace of the file to be processed.

3. The system defense method of claim 1, wherein, The step of obtaining the target whitelist policy file based on the attribute information of the file to be processed includes: Obtain the namespace where the file to be processed is located; The target whitelist policy file is obtained from the plurality of whitelist policy files based on the namespace.

4. The system defense method of claim 3, wherein, The file to be processed is a script file, wherein, Before obtaining the namespace where the file to be processed is located, the step of obtaining the target whitelist policy file based on the attribute information of the file to be processed further includes: Register a script interpreter hook to hijack the script interpreter; The script file name is obtained by parsing the parameters of the script interpreter; The namespace corresponding to the file to be processed is obtained based on the script file name.

5. The system defense method according to any one of claims 1-4, characterized in that, The target whitelist policy file is used to store at least the hash value of the security application and the file path of the security application; in, The step of determining whether the file to be processed is a loadable or executable file based on the target whitelist policy file includes: If the file to be processed is found to exist in the target whitelist policy file based on the file path of the file to be processed, then the hash value of the file to be processed is calculated to obtain the hash value to be matched, and the file to be processed is determined to be an executable or loadable file based on the hash value to be matched. If the file to be processed is determined not to exist in the target whitelist policy file based on the file path of the file to be processed, then the execution or loading of the file to be processed is refused.

6. The system defense method of claim 5, wherein, The step of determining whether the file to be processed belongs to the executable or loadable file based on the hash value to be matched includes: Read the storage hash value corresponding to the file to be processed from the target whitelist policy file; The hash value to be matched is compared with the stored hash value. If the two do not match, the execution or loading of the file to be processed is prohibited. If the two match, the file to be processed is executed or loaded.

7. The system defense method of claim 6, wherein, The process of obtaining multiple whitelist policy files based on the target file set includes: Calculate the hash value of each target file in the target file set to obtain multiple storage hash values; Obtain the file path corresponding to each target file in the target file set to obtain multiple file paths; The multiple storage hash values ​​and the multiple file paths are unified as the content of the whitelist policy file.

8. The system defense method of claim 7, wherein, After unifying the multiple storage hash values ​​and the multiple file paths into the content of the whitelist policy file, the method further includes: signing the whitelist policy file.

9. The system defense method of claim 8, wherein, The system file directory includes target items obtained by decompressing files within the image.

10. The system defense method of claim 6, wherein, The importation of the container whitelist policy file into the user-space system runtime environment includes: Automatically scan the container whitelist policy file in the corresponding Docker container image when the system starts up; The container whitelist policy file is verified. If the policy verification is successful, the container whitelist policy file is then stored in memory.

11. The system defense method of claim 10, wherein, The container whitelist policy file and the system whitelist policy file are stored separately in memory by determining the namespace.

12. A whitelist-based system defense apparatus characterized by comprising: The system defense device includes: The target whitelist policy file acquisition module is configured to obtain the target whitelist policy file based on the attribute information of the file to be processed. The target whitelist policy file is one of multiple whitelist policy files, which include at least: a system whitelist policy file and a container whitelist policy file. The security decision module is configured to determine whether the file to be processed is a loadable or executable file based on the target whitelist policy file. The target whitelist policy file acquisition module is specifically configured as follows: The system file directory is scanned to filter out a set of target files by file headers. The types of files in the target file set include: dynamic library files, executable binary programs, kernel modules, and script files. Multiple whitelist policy files are obtained based on the target file set; The security decision module is specifically configured as follows: Import the system whitelist policy and the container whitelist policy file into the user-mode system runtime environment to determine whether the file to be processed belongs to the executable or loadable file according to the system whitelist policy or the container whitelist policy file; The security decision module is specifically configured as follows: When the Linux system starts up, the whitelist policy import tool is automatically invoked to send the system whitelist policy file to the Linux system via netlink communication. The system whitelist policy file is verified. If the policy verification is successful, the system whitelist policy file is then stored in memory.

13. A computer storage medium having stored thereon a computer program, characterized in that When the program is executed by a processor, it can implement the method described in any one of claims 1-11.

14. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein, When the processor executes the program, it can implement the method as described in any one of claims 1-11.

Images