[0028] The core idea of the present invention is to construct a Widows terminal security guarantee system based on an automatic whitelist, and the whitelist that the system relies on is automatically generated by the system by scanning the local hard disk during installation. After the system is successfully started, it captures the operation of the startup process of the kernel, and verifies whether the executable program that the process to be started depends on is completely consistent with the whitelist record, otherwise the startup operation is terminated; the privileged user can modify the whitelist through the remote or local management module. list information, but cannot directly modify or delete the whitelist file; in addition, the end user cannot force stop the system, and can only uninstall the system in safe mode after entering the correct PIN code (ie system ID number); new installation The system can continue to process the security alarm information left by the previous system.
[0029] like figure 1 As shown, it is a schematic structural diagram of the Windows terminal security guarantee system based on the automatic whitelist according to the present invention, including a whitelist protection client module M1 and a whitelist protection server module M2. The whitelist protection client module M1 is used to implement whitelist-based Windows terminal security protection, and the whitelist protection server module M2 is used for privileged users to change the whitelist content of the whitelist protection client module M1 and process the alarms submitted by them. information.
[0030] The whitelist protection client module M1 is deployed on the windows terminal to be protected, and is internally composed of a whitelist module M10, a detection module M11, a dynamic link library module M12, and a client module M14.
[0031] The client module M14 in the whitelist protection client module M1 communicates with the server module M20 in the whitelist protection server module M2 to realize information exchange between modules. After the module M14 is started, it will be automatically registered with the module M20, and after the registration is successful, the local alarm information will be reported to the module M20, and at the same time, the configuration information of the module M20 will be received.
[0032]The whitelist module M10 is composed of a whitelist automatic generation module M101 and a whitelist maintenance module 102, wherein the whitelist automatic generation module M101 is used to scan the local hard disk of the current terminal and retrieve all executable files, including files with extensions .exe, . dll files, .sys files, .bat files, .com files, .cmd files, .scr files, .ocx files, and .acm files. For each executable file scanned, after obtaining the file name with absolute path, file size, creation date, modification date and attribute content, combine the file size, creation date, modification date and attribute content into a string, and then Through the MD5 algorithm, calculate the MD5 value of the string (ie "file MD5 value"); calculate the MD5 value of the file content (read length is not greater than 4M bytes) (ie "content MD5 value"), and put the file with absolute path. The file name, file MD5 value, and content MD5 value are added to the whitelist file as the feature vector of the executable file. After the local disk is processed, the MD5 value of the content of the whitelist file is calculated and appended to the end of the file; finally, the content of the whitelist file is encrypted (for example, implemented by directly calling the DES algorithm), and saved to the system32 directory, and at the same time, It is attached to the system32\drivers directory in the form of a stream file, and is used to initialize the whitelist when the normal format whitelist file is damaged. The generated whitelist file will be used by the whitelist driver module M11; the whitelist maintenance module 102 is used to protect all files involved in the whitelist protection client module M1, including whitelist files, driver files, and dynamic link libraries. For files and application files, their short file names are hard-coded by the driver code, and their absolute paths are obtained by calling the kernel function to obtain the current system directory of Windows. Block end users from changing these files through the system of the present invention; at the same time, receive the whitelist maintenance instruction of the detection module M11, update the content of the whitelist; and process the whitelist query of the detection module M11.
[0033] The detection module M11 is loaded together with the windows kernel, and is used to perform whitelist verification on each process to be executed in the windows kernel mode, and block the processes in the non-whitelist table. Use the whitelist file provided by the module M10 to verify the startup request operation of each process in the kernel. If the execution file attribute associated with the process is exactly the same as the whitelist record, the process will be started; otherwise, the startup operation will be terminated directly and submitted " "Illegal startup attempt" event is sent to the whitelist dynamic link library module M12, receives the whitelist maintenance instruction of the dynamic link library module M12, updates the content of the whitelist in the cache area, and submits the whitelist module M10 to update the whitelist file.
[0034] The dynamic link library module M12 is used to initialize the driver service, receive the event notification of the detection module M11 and the whitelist module 10, and submit it to the client module M14; receive the control command issued by the client module M14, and transfer it to the detection module M11 .
[0035] The client module M14 is used for application layer control, receives the control instructions of the management end module M20, and transfers the instructions to the detection module M11 through the dynamic link library module M12; receives the events reported by the detection module M12 and the whitelist module M10, and converts them into The standard alarm information is submitted to the management-end module M20; when the communication with the management-end module M20 fails, the alarm information is saved in the system32\temp directory as a stream file. After the communication is restored, the content of the alarm file is read and submitted. to the management side module M20.
[0036] The whitelist protection server module M2 can be co-located with the whitelist protection client module M1, or it can be deployed separately on the protected host in the enterprise/institution. This module contains only one management end module M20. The management end module M20 is configured to receive the registration and alarm request of the client module M14, and instruct the client module M1 to query the content of the whitelist, temporarily shut down or restart the protection of the whitelist, and change the content of the whitelist.
[0037] The client module M14 in the whitelist protection client module M1 and the management module M20 of the whitelist protection server module M2 form an application layer module M0.
[0038] The detection module M11 of the whitelist protection client module M1 is not allowed to be uninstalled in a non-secure mode, and when uninstalling, the uninstallation is allowed only when the input PIN code is consistent with the preset PIN code.
[0039] like figure 2 As shown, it is a flowchart of the Windows terminal security guarantee method based on automatic whitelist according to the present invention, including:
[0040] Step S1: Install the terminal security system; on the Windows terminal to be protected, after the basic application software system has been installed, install the whitelist terminal security system, including installing drivers, dynamic link libraries and applications.
[0041] Specifically, during the installation process, the IP address, port number, and secure communication parameters of the server system need to be set. By default, the IP address of the server system is 127.0.0.1, the port number is 5056, and the secure communication parameters are: symmetric encryption is used, and the shared key is the name of the terminal machine. The PKI method can be selected during installation, but the server system is required to provide self-signed authentication services.
[0042] After the installation is complete, the terminal security system requires the computer to be restarted.
[0043] Step S2: Automatically generate a whitelist; on the Windows terminal to be protected, after all necessary application software systems have been installed, scan the local hard disk with a scanning tool to automatically collect information on all executable files (including files with an extension of .exe) , .dll files, .sys files, .bat files, .com files, .cmd files, .scr files, .ocx files, and .acm files), and convert the file name with absolute path, file MD5 value (based on file size) , file creation date, file modification date, and file attribute content are combined together, and the MD5 value is calculated by the MD5 algorithm), and the MD5 value of the file content (based on the value of the first 4M bytes of the file content, the MD5 value is calculated by the MD5 algorithm) and saved to the whitelist in the file. After all executable files are processed, calculate the MD5 value of the content of the current whitelist file (calculated directly by the MD5 algorithm), append the calculated MD5 to the end of the whitelist file, and then encrypt the whitelist file with the DES algorithm (The key is composed of the PIN code and the terminal MAC address reserved inside the executable program), and saved in the system32 directory;
[0044] In order to deal with the violent destruction of the whitelist file or hardware damage, the encrypted whitelist file needs to be saved to the system32\driver32 directory as a stream file at the same time.
[0045] Step S3: Start the monitoring service; after the terminal machine is restarted, the Windows terminal security system based on the automatic whitelist is automatically started, and only the processes specified in the whitelist can be run on the controlled terminal.
[0046] The terminal security assurance system based on the automatic whitelist uses the self-protection mechanism of files, processes, and services in the kernel mode (in this implementation, the filtering protection method is adopted), and the terminal user cannot forcibly stop the monitoring service, nor can it modify the internal monitoring system. files, including driver files, dynamic link library files, whitelist files, and executable files.
[0047] Step S4: monitor and maintain; through the server, change the content of the whitelist on the controlled terminal, further restrict the terminal authority, or allow the terminal to use new application software.
[0048] like image 3 shown, yes figure 1 The internal flowchart of the whitelist driver in the monitoring service described in step S3, the driver is loaded with the Windows kernel, and its internal processing includes:
[0049] Step S1: Create a device and initialize the distribution routine; this driver is a virtual device, and the virtual device name and link device name still need to be established; only four types of IRP (I/O request package) request examples of creation, shutdown, cleanup and device control are processed. Procedure.
[0050] Step S2: Verify whether the content of the whitelist file in the system32 directory is correct; first verify whether the file exists; then use the DES algorithm to decrypt the file content (the key is composed of the PIN code and the terminal MAC address reserved in the executable program), and verify the MD5 Whether the value is correct (implemented by directly comparing the MD5 value calculated using the MD5 algorithm with the MD5 value appended at the end of the file, which is located in the last line of the whitelisted file). If there is an error in the verification, go to S3, otherwise, construct a legal whitelist with the content of the obtained whitelist file; go to S4;
[0051] Step S3: Initialize the minimum whitelist; read the content of the streaming whitelist file from the system32\driver32 directory, decrypt it with the DES algorithm, use the MD5 algorithm to calculate the MD5 value, and compare the MD5 attached to the file with the calculated MD5 value. , verify whether the file is correct, if it is correct, construct a legal whitelist based on the content of the file, and transfer to S4; otherwise, if the whitelist is empty, transfer to S4;
[0052] Step S4: set the filter flag; start the filter switch, go to S5;
[0053] Step S5: setting an event notification handle; setting an event notification handle when communicating with the dynamic link library, for submitting an event alarm, by default, all event notification handles are empty;
[0054] After this step is performed, the driver enters the working state. On the one hand, it detects the control information from the application program, and transfers to S10; on the other hand, it detects the process startup operation of the kernel, and transfers to S6;
[0055] Step S6: capture process startup; hook the Windows kernel startup process function in a "hook" mode, if a startup request is detected, go to S7, otherwise, continue to detect;
[0056] Step S7: whitelist verification; extract the executable file name of the process to be started, retrieve the whitelist, if it does not exist, the verification is abnormal, go to S8 (the abnormal status flag is "illegal"); otherwise, read the size of the executable file , creation date, modification date and attribute content, use the MD5 algorithm to calculate the MD5 value, and test whether the MD5 value of the file is equal to the corresponding file in the whitelist. Change"); otherwise, read the first 4M bytes of the execution file, use the MD5 algorithm to calculate its MD5 value, and compare it with the MD5 value of the file content of the corresponding file in the whitelist, if not, it is a verification exception, go to S8 ( The abnormal status is marked as "file content has been changed"), otherwise the verification is passed, go to S9;
[0057] Step S8: trigger event notification; according to different abnormal conditions of verification, generate different event notifications (illegal, file is changed, file content is changed); this detection is over, go to S6, and continue the next detection;
[0058] Step S9: start the process normally; call the kernel process start function of Windows to start the process; after the current detection, go to S6.
[0059] Step S10: test whether the whitelist update instruction is received, if received, go to S11, otherwise, continue the test;
[0060] Step S11: Parse the instruction content, extract the whitelist information, and according to the operation type, if it is newly added, save the whitelist information in the cache area, otherwise, delete the whitelist record from the cache area; go to S12;
[0061] Step S12: Update the local whitelist file; notify the whitelist maintenance module M102 of the whitelist module M10 to update the whitelist file, this time the whitelist update process is over, go to S10 to process the next change instruction.
[0062]The whitelist maintenance module M102 first calculates the MD5 value of the whitelist information in the shared buffer area (calculated directly by the MD5 algorithm), and encrypts the joint information composed of the whitelist information and the MD5 value (using the DES algorithm, using fixed key encryption, the key It consists of the PIN code and the terminal MAC address); then the encrypted information is written into the existing whitelist file in the system32 directory by overwriting; finally, the flow file in the system32\driver32 directory is overwritten.
[0063] like Figure 4 shown, for figure 1 The processing flow chart inside the file protection driver used for the file protection described in the step S3, this file protection driver is also automatically loaded with Windows startup, including the following steps:
[0064] Step S1: create a device and initialize a distribution routine; the driver is a virtual device driver, which belongs to the top-level driver of the file system; the driver handles the IRP request routines of creation, closing, cleaning, device control, reading, and writing;
[0065] Step S2: Test whether it is an IRP request to create, read or write, if so, go to S3, otherwise, go to S5;
[0066] Step S3: verifying whether the file to be operated is a file that needs to be protected; extracting the target file name, and retrieving the set of file names to be protected preset in the driver, if it does not exist, go to S5, otherwise, go to S4;
[0067] Step S4: verifying whether the process name is legal; extracting the process name of the operation file, and retrieving the set of process names built in the driver and allowing the operation of such files (this set is written to death by the driver code, and can only be described in the present invention. Terminal security system application), if it does not exist, go to S6, otherwise, go to S5.
[0068] Step S5: The IRP request is passed down, and the normal IRP stack processing is continued. At this point, the processing of the IRP request is completed, and then transfer to S2 to continue processing the next IRP;
[0069] Step S6: Block the IPR packet; directly complete the IRP request, and write an exception log; at this point, the IRP request processing ends, and the process goes to S2.
[0070] like Figure 5 shown, as figure 1 The flow chart between the application layer module, the dynamic link library module and the driving module (ie the detection module) in the system shown includes three major processes, namely: the forced initialization process, the event reporting process and the whitelist control process. They are described as follows:
[0071] The forced initialization process is initiated by the client module of the application layer module, including:
[0072] Step S01: initialize the application environment; after the client module is started, automatically initialize its operating environment, including dependency file detection, operating parameter setting, etc., and trigger step S02 by calling the interface of the dynamic link library module, and go to S06 by itself;
[0073] Step S02: the dynamic link library module stops the whitelisted driver module according to the initialization request of the client module, and starts the whitelisted driver module service again, thereby triggering step S03, and turning to S04 by itself;
[0074] Step S03: The driver module starts up again, including creating a device and initializing the distribution routine, which is specifically as follows: image 3 described in step S1;
[0075] Step S04: the dynamic link library module sets an event driver for processing the event reported by the driver module; triggering step S05 by calling the IOCTRL interface of the driver module;
[0076] Step S05: the driver uses the instruction of the dynamic link library module to set the event handle, so that the event can be reported normally;
[0077] Step S06: The client module uses the interface of the dynamic link library module to load a callback function for processing the event reported by the dynamic link library module, thereby triggering step S07. The callback function here is mainly used to normalize the alarm events from the driver module, and finally write the local log or report it to the management module;
[0078] Step S07: The dynamic link library module registers different processing functions for different driver modules and different events according to the calling request of the client module, which is implemented by an array of function pointers in this implementation.
[0079] At this point, the initialization process ends.
[0080] The event reporting process is initiated by the driver module, including:
[0081] Step S11: When the driver module detects an abnormality, it generates an abnormal event notification, including the event type (illegal, file modified, file content modified), file name, time, etc., and calls the event handle saved in the initialization process to initiate an event notification , turn to S12;
[0082] Step S12: After the dynamic link library module captures the event, it parses the event content, and calls the callback function saved in the initialization process to process the event; go to step S13;
[0083] Step S13: after the client module of the application layer module receives the event; records the event log and reports it to the management end module of the application layer module; after the management end module receives the event alarm, it simply inserts the XML file (stand-alone mode) or In the database (enterprise mode), and print this alarm content in the monitoring window.
[0084] When the client module finds that the management module is unavailable, such as detecting a communication abnormality or registration failure, it appends the event log to the flow file in the system32\temp directory. And the flow file is regularly detected. Once the management end is found to be available, the content of the flow file is submitted to the management end module; once the submission is successful, the flow file is cleared.
[0085] At this point, the event reporting process ends.
[0086] The whitelist control process is initiated by the management-side module of the application layer module, including:
[0087] Step S21: Modify the whitelist; on the whitelist maintenance interface of the management end module, the user can add and/or delete whitelist records; the management end module wraps the user request into a control request package and sends it to the client module; the client After parsing the control command and verifying that the command comes from the legal management terminal, reconstruct the internal command, submit it to the dynamic link library module, and go to S22;
[0088] The verification includes verifying whether the signature information of the command, the IP address of the management terminal that initiates the command and other information are legal; the reconstructing the internal command, after extracting the whitelist record and operation type, directly calls the interface of the dynamic link library module.
[0089] Step S22: After the dynamic link library module receives the whitelist update instruction, it also parses out the whitelist record content (file name, file MD5 value, file content MD5 value) and operation type, and calls the driver's IOCTRL interface to control the driver module update Whitelist information, go to S23;
[0090] Step S23: After the driver module receives the IOCTRL, it sequentially executes the following steps: image 3 As shown in steps S11 and S12, the content update of the whitelist is completed.
[0091] At this point, the whitelist control process ends.
[0092] The Windows terminal security system based on the automatic white list of the present invention can be uninstalled after entering the security mode when the user no longer needs it, but the PIN code of the system software must be known in advance. Its process is described as follows:
[0093] Step 1: Start the uninstallation; the user can start the uninstallation by activating the automatic "uninstall.exe" tool of the client system;
[0094] Step 2: The driver module detects whether it is in safe mode, if not, it directly refuses to start the uninstall.exe process and ends; otherwise, go to 3:
[0095] Step 3: Prompt the user to enter the PIN code; after getting the user to enter the PIN code, go to 4:
[0096] Step 4: Compare whether the input PIN code is consistent with the pre-stored PIN code. If they are different, end the uninstallation; otherwise, go to 5:
[0097] Step 5: Allow the driver module to be uninstalled, record the uninstallation information including time, current version, and operator information to the stream file on system32\tmp; and perform environment cleanup, including terminating services, ending processes, and deleting files and registry entries. Complete the uninstall and end.
[0098] The above description is only a preferred embodiment of the present invention, but the protection scope of the present invention is not limited to this. Substitutions should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.
