Process detection and daemon method, device and equipment suitable for linux and medium

Abstract

This application discloses a process detection and protection method, apparatus, device, and medium applicable to Linux, applied to a Linux process protection system, and relating to the embedded field. The method includes: if the current list of newly added processes is not empty, iterating through the newly added processes in the list and obtaining the current target process whitelist through whitelist self-learning; sequentially performing first whitelist checks, second whitelist checks, illegal execution path checks, and shell command checks on the newly added processes, and determining whether to issue an illegal process alarm based on the check results; generating a list of processes to be protected based on the list of newly added processes, and protecting the processes based on the list of processes to be protected. Thus, a lightweight integrated process monitoring and protection function can be achieved.

Description

Technical Field

[0001] This invention relates to the field of embedded systems, and in particular to a method, apparatus, device, and medium for process detection and protection suitable for Linux. Background Technology

[0002] With the widespread application of embedded Linux technology in fields such as the Internet of Things, industrial control, and smart terminals, the security of system processes and the stability of critical services have become critical requirements. Ensuring that the system only runs preset legitimate programs, preventing the execution of illegal programs (illegal process identification), and ensuring that critical service processes in the system are always running and can be restarted promptly after abnormal termination (illegal process identification) have also become essential functions that the system must consider implementing.

[0003] Currently, the mainstream technical solution for process protection is to deploy the process protection tool systemd. The general logic of this solution is to configure the system with parameters such as the startup command and running user of the service to be protected, detect the process status through polling or signal listening, and execute a preset restart command when the process terminates. For illegal process monitoring, existing technical solutions involve deploying intrusion detection system services or components. This solution identifies malicious processes based on signature database matching, focusing on monitoring the process names and execution paths of known malicious programs, but lacks self-learning and protection capabilities. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a process detection and protection method suitable for Linux, which achieves lightweight integrated monitoring and protection functions. Process monitoring and protection can be implemented with only simple configuration, without requiring any code to be written for the protected process. The specific solution is as follows: Firstly, this application discloses a process detection and protection method applicable to Linux, including: The current list of newly added processes is checked. If the list of newly added processes is not empty, the newly added processes in the list of newly added processes are traversed based on the parent-child process relationship. The process whitelist self-learning is determined according to the preset self-learning field to obtain the current target process whitelist. The newly added process is sequentially checked against the first whitelist, the second whitelist, the illegal execution path, and the shell command. Based on the results of these checks, it is determined whether to issue an illegal process alert. The first whitelist check checks whether the target parent process of the newly added process is in the target process whitelist. The second whitelist check checks whether the newly added process is in the target process whitelist. A list of processes to be protected is generated based on the newly added process list, and process protection is performed based on the list of processes to be protected.

[0005] Optionally, before detecting the current list of newly added processes, and if the list of newly added processes is not empty, traversing the newly added processes in the list based on parent-child process relationships, and determining whether to perform process whitelist self-learning based on a preset self-learning field to obtain the current target process whitelist, the method further includes: Scan the current set of old processes to see if it is empty, and obtain the corresponding scan results; If the scan result indicates that the current old process set is empty, then it is determined that the system is running for the first time, and the currently detected process is added to the current old process set; If the scan result indicates that the current old process set is not empty, then it is determined that the system is not running for the first time, and the currently detected process is added to the current new process set. Then, it is checked whether the process in the current new process set is in the current old process set. If there is a target process in the current new process set that is not in the current old process set, then the target process is added to the new process list.

[0006] Optionally, the step of detecting the current list of newly added processes, if the list of newly added processes is not empty, involves traversing the newly added processes in the list based on parent-child process relationships, including: Detect the current list of newly added processes and determine whether the list of newly added processes is empty. If the list of newly added processes is not empty, determine the order of the processes in the list of newly added processes. The current head process in the newly added process list is determined according to the process order, and the head process is searched cyclically in the newly added process list to see if there is a corresponding target parent process for the head process; the head process is the first process in the newly added process list, and the target parent process is the ancestor process corresponding to the head process. If the target parent process does not exist in the list of newly added processes, then the head process is removed from the list of newly added processes; If the number of loop searches for the head process is greater than the number of new processes in the new process list, then the new process list is cleared and a loop error is returned. Jump to the step of determining the current head process in the newly added process list according to the process order, until the traversal of the newly added process list is completed.

[0007] Optionally, the step of determining whether to perform process whitelist self-learning based on a preset self-learning field to obtain the current target process whitelist includes: Check if the current self-learning time configuration field is a preset field; If the self-learning time configuration field is different from the preset field, the current self-learning time is recorded and the self-learning end time is calculated. If the self-learning time has reached the self-learning end time, the whitelist of self-learning processes collected during the self-learning period is counted, and the whitelist of self-learning processes is merged with the preset process whitelist to obtain the target process whitelist. If the self-learning time configuration field is the same as the preset field, then self-learning ends.

[0008] Optionally, the step of sequentially performing a first whitelist check, a second whitelist check, an illegal execution path check, and a shell command check on the newly added process, and determining whether to issue an illegal process alert based on the check results, includes: The process sequentially performs checks on the newly added process: a first whitelist check, a second whitelist check, an illegal execution path check, and a shell command check. Based on the check results, it determines whether to issue an illegal process alert, including: The newly added process is subjected to a first whitelist check to determine whether the target parent process of the newly added process exists in the target process whitelist, so as to obtain the first check result; A second whitelist check is performed on the newly added process to determine whether the newly added process exists in the target process whitelist, so as to obtain the second check result; The newly added process is subjected to an illegal execution path check to determine whether the process path of the newly added process is in the preset legal process path whitelist, so as to obtain the third check result; The newly added process is subjected to shell command checks to determine whether the actual execution commands of the newly added process meet the preset command rules, so as to obtain the fourth check result; If any of the first inspection result, the second detection result, the third inspection result, and the fourth inspection result fails the inspection, a corresponding illegal alarm will be issued based on the target inspection result. If the first check result, the second detection result, the third check result, and the fourth check result all pass the check, then jump to the detection of the current newly added process list. If the newly added process list is not empty, then traverse the newly added processes in the newly added process list based on the parent-child process relationship, and determine whether to perform process whitelist self-learning according to the preset self-learning field to obtain the current target process whitelist, so as to perform the next round of process detection.

[0009] Optionally, the step of performing shell command checks on the newly added process to determine whether the actual execution commands of the newly added process meet preset command rules includes: Obtain the parent process name of the target parent process, and determine whether the parent process name is an interpreter name in the preset interpreter list; If the parent process name is an interpreter name in the preset interpreter list, then obtain the preset shell command blacklist and obtain the actual execution command corresponding to the newly added process; The actual executed instruction is checked using a preset function to see if it matches any regular expression in the preset shell instruction blacklist. If the match is successful, a fourth check result is generated indicating that the newly added process failed the shell command check; if the match fails, a fourth check result is generated indicating that the newly added process passed the shell command check.

[0010] Optionally, the step of generating a list of processes to be protected based on the newly added process list, and performing process protection based on the list of processes to be protected, includes: Collect process information of newly added processes in the newly added process list, and determine the processes to be protected in the newly added processes based on the process information; A list of processes to be protected is generated based on the processes to be protected, and the process status information of the processes to be protected in the list is obtained sequentially based on a preset time interval for each process to be protected. If there is a terminated process among the processes to be protected that cannot obtain process status information or whose process start time has changed, then the terminated process is restarted and removed from the list of processes to be protected. If the process status information of the process to be protected is successfully obtained, and the start time of the process to be protected has not changed, then it is determined that the process to be protected is running normally.

[0011] Secondly, this application discloses a process detection and protection device suitable for Linux, applied to a Linux process protection system, including: The whitelist determination module is used to detect the current list of newly added processes. If the list of newly added processes is not empty, the newly added processes in the list of newly added processes are traversed based on the parent-child process relationship, and the process whitelist self-learning is determined according to the preset self-learning field to obtain the current target process whitelist. The detection and alarm module is used to sequentially perform a first whitelist check, a second whitelist check, an illegal execution path check, and a shell command check on the newly added process, and determine whether to issue an illegal process alarm based on the check results; the first whitelist check is to check whether the target parent process of the newly added process is in the target process whitelist; the second whitelist check is to check whether the newly added process is in the target process whitelist. The process protection module is used to generate a list of processes to be protected based on the newly added process list, and to protect the processes based on the list of processes to be protected.

[0012] Thirdly, this application discloses an electronic device, including: Memory, used to store computer programs; A processor for executing the computer program to implement the process detection and protection method applicable to Linux as described above.

[0013] Fourthly, this application discloses a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned process detection and protection method applicable to Linux.

[0014] In this application, the current list of newly added processes can be detected. If the list of newly added processes is not empty, the newly added processes in the list are traversed based on the parent-child process relationship, and a process whitelist self-learning is performed according to a preset self-learning field to obtain the current target process whitelist. The newly added processes are then subjected to a first whitelist check, a second whitelist check, an illegal execution path check, and a shell command check in sequence, and an illegal process alarm is determined based on the check results. The first whitelist check checks whether the target parent process of the newly added process is in the target process whitelist. The second whitelist check checks whether the newly added process is in the target process whitelist. A list of processes to be protected is generated based on the list of newly added processes, and process protection is performed based on the list of processes to be protected.

[0015] Therefore, the method of this application can iterate through the newly added processes in the current list of newly added processes according to the preset parent-child process relationship, and then update the whitelist through self-learning to obtain the target process whitelist. Then, the newly added processes are sequentially checked against the first whitelist, the second whitelist, illegal execution paths, and shell commands, and an illegal process alert is determined based on the check results. The first and second whitelist checks need to be performed based on the target process whitelist. Furthermore, a list of processes to be protected can be generated from the list of newly added processes, and processes can be protected based on this list. In this way, lightweight monitoring and protection functions are integrated, requiring only simple configuration to achieve process monitoring and protection functions, without requiring the protected processes to write any code. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 This application discloses a process detection and protection method applicable to Linux; Figure 2 This is a schematic diagram illustrating the processing sequence of a process detection and protection method for Linux disclosed in this application; Figure 3 This application discloses a flowchart for a newly added process monitoring process; Figure 4 This application discloses a new process traversal flowchart; Figure 5 This application discloses a whitelist self-learning flowchart; Figure 6 This application discloses a flowchart for shell command checking. Figure 7 This application discloses a specific process detection and protection method applicable to Linux; Figure 8 This is a schematic diagram of the overall process protection process disclosed in this application; Figure 9 This is a schematic diagram illustrating the determination of a process guardian list as disclosed in this application; Figure 10 This is a schematic diagram of a specific process protection process disclosed in this application; Figure 11 This is a schematic diagram of an illegal process monitoring process disclosed in this application; Figure 12 This is a schematic diagram of a process detection and protection device for Linux disclosed in this application; Figure 13 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Currently, the mainstream process protection solution is implemented by deploying the process protection tool systemd. The general logic of this solution is to configure the system with parameters such as the startup command and running user of the service to be protected, detect the process status through polling or signal listening, and execute a preset restart command when the process terminates. For illegal process monitoring, existing technical solutions involve deploying intrusion detection system services or components. This solution identifies malicious processes based on signature database matching, focusing on monitoring the process names and execution paths of known malicious programs, but lacks self-learning and protection capabilities.

[0020] To overcome the aforementioned technical problems, this application discloses a process detection and protection method suitable for Linux, which realizes a lightweight integrated monitoring and protection function. It can achieve process monitoring and protection functions with only simple configuration, and process protection can be achieved without writing any code for the protected process.

[0021] See Figure 1 As shown in the figure, this invention discloses a process detection and protection method suitable for Linux, applied to a Linux process protection system, including: Step S11: Detect the current list of newly added processes. If the list of newly added processes is not empty, traverse the newly added processes in the list of newly added processes based on the parent-child process relationship, and determine whether to perform process whitelist self-learning according to the preset self-learning field to obtain the current target process whitelist.

[0022] In this embodiment, as Figure 2 As shown, before detecting the current list of newly added processes, it is necessary to first parse the configuration file, then load the corresponding process whitelist, and then enable the corresponding process detection and process monitoring, as follows. Figure 3The diagram illustrates the process for monitoring newly added processes. It requires scanning whether the current set of old processes is empty to obtain the corresponding scan results. Specifically, it checks whether the current set of old processes (old_proc_pids_) is empty to determine if it's the first run. If it is the first run, the is_init_ flag is set to true, and the container storing new process information, i.e., the list of newly added processes (new_pid_), is cleared. Next, the function attempts to open the Linux system's / proc directory, which provides system process information as a virtual file system. If opening fails, an error code is returned directly; if successfully opened, the function enters the directory traversal phase. During directory traversal, the function first filters hidden files (starting with ".") and system reserved processes (PID (Process Identifier) ​​of 0 or 1). For each valid process directory, different strategies are adopted based on the running mode: In the first case, if the scan results indicate that the current old process set is empty, it is determined that the system is running for the first time, and the currently detected processes are added to the current old process set. Specifically, all process PIDs need to be added to the old_proc_pids_ set, and an information structure TProcInfo is initialized for each process. TProcMonitorGetInfo is called to obtain detailed process information. If the information is obtained successfully and the process name is not in the root process exclusion list root_proc_list_, the process information is stored in new_pid_. This mode is mainly used to build the initial process view.

[0023] In the second scenario, if the scan results indicate that the current old process set is not empty, it is determined that the system is not running for the first time. The currently detected processes are then added to the current new process set, and it is then checked whether the processes in the current new process set are also in the current old process set. Specifically, all process PIDs need to be added to the current new process set `new_proc_pids_`, and it is checked whether they are whitelisted processes (existing in the historical whitelist `old_white_pids_`). If so, they are added to the preset process whitelist `new_white_pids_`. This is essentially a whitelist continuation mechanism; as long as the process still exists, it remains in the whitelist.

[0024] If a target process exists in the current set of new processes that is not in the current set of old processes, then that target process is added to the list of newly added processes. Specifically, for PIDs (i.e., newly added processes) that cannot be found in `old_proc_pids_`, the information structure is initialized, detailed information is obtained, the root process is filtered, and the results are stored in the `new_pid_` container. It's worth noting that while newly added processes in the whitelist are recorded in `new_white_pids_`, they are not automatically added to the list of newly added processes `new_pid_` unless they are indeed newly added processes.

[0025] It should be noted that after the directory traversal is complete, the data needs to be updated. Move semantics are used to replace `old_proc_pids_` with `new_proc_pids_` as the new baseline set, and the temporary set is cleared. Then, the whitelist set is updated in the same way, replacing `old_white_pids_` with `new_white_pids_`, ensuring that the whitelist always reflects the whitelisted processes currently existing in the system. Finally, the directory resources are closed, and the number of newly detected processes is returned.

[0026] This enables efficient incremental process monitoring, identifying new processes by comparing the differences between the process sets from two scans, avoiding the overhead of a full scan. It also supports process filtering and a dynamic whitelist maintenance mechanism, where the whitelist is updated with each scan, retaining only whitelisted processes that still exist in the current system.

[0027] Furthermore, such as Figure 4 The diagram illustrates the traversal process for adding processes. This requires scanning the list of newly added processes. Specifically, it checks the current list and determines if it's empty. If not, it determines the process order within the list. First, it checks if a new process exists; if not, it returns failure. If the list is not empty, it determines the order of the newly added processes. Then, it identifies the current head process in the list based on the process order and iteratively searches for a target parent process for the head process within the list, starting from the first process in the list and tracing upwards through the parent process ID to find the topmost process (the earliest started ancestor process). It's important to note that the head process is the first process in the list, and the target parent process is the ancestor process corresponding to the head process. If the head process doesn't have a target parent process in the list, it's removed. After finding the top process, its complete process information (including PID, name, user, resource usage, etc.) is copied to the output parameters, and then the process is removed from the list to ensure that the next process in the chain is processed in the next call. Finally, a success flag is returned, indicating that valid process information has been obtained.

[0028] Furthermore, if the number of loop searches for the head process exceeds the number of newly added processes in the new process list, the new process list is cleared, a loop error is returned, and the process jumps to the step of determining the current head process in the new process list based on process order, until the traversal of the new process list is complete. It should be noted that recording the number of newly added processes is to set up a loop prevention mechanism during the tracing process. If the number of loop searches exceeds the number of processes, it indicates that a process loop (an abnormal situation) has been detected, so the entire list is cleared and a failure is returned to prevent the system from entering an infinite loop.

[0029] This ensures that processes are processed in the order they are started, and that if a process's parent or grandparent process is in the process whitelist, the child process is also considered legitimate, thus achieving process lineage monitoring.

[0030] Furthermore, such as Figure 2 As shown, self-learning of the whitelist is also required, specifically, as follows: Figure 5 As shown, after the system starts, it obtains the self-learning time configuration field `self_learn_time`, which represents the time window for self-learning. When the system completes self-learning, it sets `self_learn_time` to 1 and writes it to the configuration file. Therefore, the self-learning function only runs on the first run of the system (if the configured `self_learn_time` is not 0). During system runtime, the `DoSelflearn` function is periodically called to perform self-learning. The list of processes learned by the system is saved to the list `self_learn_list` in real time during the main flow of this invention.

[0031] Specifically, the function first checks if the current self-learning time configuration field is a preset field. Specifically, it checks if the self-learning time configuration field (self_learn_time_) is the preset field 0. If the self-learning time configuration field differs from the preset field, the current self-learning time is recorded, and the self-learning end time is calculated. That is, if it is not 0, the self-learning process begins, relevant variables are initialized, and the current system timestamp is obtained. If this is the first time entering self-learning (start_study_tick_ is 0), the current time is recorded as the self-learning start time. Next, the function calculates the self-learning end time (start time + configured learning duration × 1000) and determines if the current time has reached the self-learning end time. If not, it returns false indicating that self-learning is still in progress; if it has, it enters the self-learning data processing stage.

[0032] If the self-learning time has reached the self-learning end time, the function compiles the whitelist of self-learning processes collected during the self-learning period and merges it with the preset process whitelist to obtain the target process whitelist. That is, at the end of self-learning, the function first retrieves the process whitelist collected during the self-learning period. Then, it reads the existing preset process whitelist in the configuration file and merges the two, ensuring that the original whitelist in the configuration file is not overwritten. Next, the self-learning time is reset to 0, and the self-learning time and the merged complete whitelist in the configuration file are updated through the configuration management interface. Finally, the self-learning end log is recorded, and true is returned.

[0033] In another scenario, if the self-learning time configuration field differs from the preset field, self-learning will end. That is, if the value is 0, it indicates that the self-learning function is not enabled, and the function will directly return true to end the process.

[0034] This enables a time-based automatic learning mechanism that dynamically generates a whitelist by monitoring the normal process behavior of the system over a period of time, merges it with the statically configured whitelist, and finally persists it to the configuration file, providing intelligent filtering rules for the process monitoring system.

[0035] Step S12: Perform a first whitelist check, a second whitelist check, an illegal execution path check, and a shell command check on the newly added process in sequence, and determine whether to issue an illegal process alarm based on the check results; the first whitelist check is to check whether the target parent process of the newly added process is in the target process whitelist; the second whitelist check is to check whether the newly added process is in the target process whitelist.

[0036] In this embodiment, as Figure 2 As shown, the newly added process needs to undergo a first whitelist check, a second whitelist check, an illegal execution path check, and a shell command check. The first whitelist check refers to determining whether the target parent process of the newly added process exists in the target process whitelist and obtaining the corresponding first check result. The second whitelist check refers to determining whether the newly added process itself exists in the target process whitelist and obtaining the corresponding second check result.

[0037] Furthermore, it is necessary to perform illegal execution path checks on newly added processes to determine whether their process paths are in a pre-defined whitelist of legal process paths, thus obtaining the third check result. This involves obtaining the process path of the newly added process and determining if it is in the pre-defined whitelist. If the process path is not in the whitelist, an illegal path alert is issued; if it is, a shell command check is performed on the newly added process. Specifically, at startup, a pre-defined whitelist of legal program execution paths is obtained, then the path of the process to be monitored is obtained and compared with this whitelist. If the detected execution path is not in the whitelist, the corresponding callback function is invoked to issue an alert.

[0038] Another step, such as Figure 2 As shown, a shell command check is required, and as follows: Figure 6 As shown, it is necessary to obtain the parent process name of the target parent process and determine whether the parent process name is an interpreter name in the preset interpreter list. If the parent process name is an interpreter name in the preset interpreter list, a preset shell command blacklist is obtained, and the actual execution command corresponding to the newly added process is obtained. A preset function is used to check whether the actual execution command matches each regular expression in the preset shell command blacklist. If the match is successful, a fourth check result is generated indicating that the newly added process failed the shell command check; if the match fails, a fourth check result is generated indicating that the newly added process passed the shell command check. It should be noted that the system loads a configuration file, which contains a preset shell command blacklist list containing regular expressions. During the initialization phase, these configurations are parsed and compiled into regular expression objects and stored in a mapping table for easy subsequent matching. When the system executes a shell command, a monitoring callback is triggered to obtain the actual executed command string. The monitoring program traverses each regular expression in the blacklist mapping table and uses the regex_search function to check whether the command matches. If a match is found, an alert callback function is immediately invoked, the corresponding event ID is set, and a security alert is issued for the abnormal command. If no match is found after iterating through all regular expressions, the command is determined to be a normal command, and the inspection process ends. In this way, flexible command pattern recognition is achieved through regular expression matching, which can effectively detect potential malicious or dangerous shell operations.

[0039] Finally, if any of the first, second, third, or fourth check results fail, a corresponding illegal alarm is triggered based on that target check result. In this case, it indicates that the new process failed all process checks, thus requiring an alarm based on the failed process checks. If all four check results pass, the new process passes, and the next new process in the list needs to be checked. Therefore, the process jumps to the current list of new processes. If the list is not empty, the new processes are traversed based on parent-child process relationships, and a process whitelist self-learning step is performed based on a preset self-learning field to obtain the current target process whitelist for the next round of process checks.

[0040] Step S13: Generate a list of processes to be protected based on the newly added process list, and protect the processes based on the list of processes to be protected.

[0041] In this embodiment, after the system starts, a list of processes to be protected is generated based on the list of newly added processes. Then, processes are protected according to this list. Specifically, process information of newly added processes in the list needs to be collected. The processes to be protected within these newly added processes are then identified based on this information. A list of processes to be protected is generated based on these processes, and the process status information of each process in the list is sequentially retrieved at preset time intervals. If a terminated process cannot obtain process status information, it is restarted and removed from the list. Conversely, if the process status information of a process to be protected is successfully obtained, it is determined whether the startup time of that process has changed. Furthermore, if a target restart process with a changed startup time exists, a process restart alarm is triggered, and the target restart process is removed from the list.

[0042] In this embodiment, the newly added processes in the current list of newly added processes can be traversed according to the preset parent-child process relationship. Then, the whitelist is updated through self-learning to obtain the target process whitelist. If the target parent process of the newly added process is not in the target process whitelist, an illegal execution path check is required for the newly added process. Based on the check results, a shell command check is performed on the newly added process. During the shell command check, it is necessary to determine whether each regular expression in the preset shell command blacklist matches the actual execution command of the newly added process, and to determine whether an illegal process alert is needed based on the matching result. Furthermore, a list of processes to be protected can be generated from the list of newly added processes, and then processes can be protected based on the list of processes to be protected. In this way, a lightweight monitoring and protection function is integrated. Process monitoring and protection functions can be implemented with simple configuration, and process protection can be achieved without the protected process writing any code.

[0043] As can be seen from the foregoing embodiments, this application can also protect processes. Therefore, this embodiment provides a specific explanation of how to protect processes. See also Figure 7 As shown in the figure, this invention discloses a process detection and protection method suitable for Linux, applied to a Linux process protection system, including: Step S21: Collect process information of newly added processes in the newly added process list, and determine the processes to be protected in the newly added processes based on the process information.

[0044] Step S22: Generate a list of processes to be protected based on the processes to be protected, and obtain the process status information of the processes to be protected in the list sequentially based on the preset time interval of the processes to be protected.

[0045] Step S23: If there is a terminated process among the processes to be protected that cannot obtain process status information or whose process start time has changed, then restart the terminated process and remove the terminated process from the list of processes to be protected.

[0046] Step S24: If the process status information of the process to be protected is successfully obtained and the start time of the process to be protected has not changed, then it is determined that the process to be protected is running normally.

[0047] In this embodiment, as Figure 8 As shown, after the system starts, it parses the list of processes to be protected from the configuration file and loads it into the list daemon_exe_path. Then, it runs tasks periodically, namely the process monitoring process and the process protection process. The process monitoring process related to process protection is as follows: Figure 9As shown, when the process detection process detects a newly added process that is to be monitored, it collects the relevant information and inserts it into the daemon_proc_list list of processes to be monitored. The daemon_proc_list list is the core data structure in the process monitoring process. The periodically running process monitoring process is as follows: Figure 10 As shown, the process daemon check process is a timed daemon mechanism. First, the system checks whether the current daemon process time daemon_end_tick has reached the preset time interval, i.e., the preset check time point GetTickCount. If the time has not been reached, the check is skipped.

[0048] When the check time arrives, the program iterates through the list of daemons, checking the status of each protected process. For each daemon, the system attempts to read its status information. If the process status cannot be obtained (i.e., the process does not exist, or the process start time in the status information has changed), the process is determined to have terminated, triggering an alarm and invoking the daemon callback function. Then, based on the saved process information, such as startup parameters, the process is restarted, and then removed from the daemon list. If the process status can be obtained, the program further compares whether the process start time has changed.

[0049] If a process runs normally and its startup time remains unchanged, it remains in the daemon list. Restarted processes are then reinserted into the core data structure `daemon_proc_list` by the aforementioned process monitoring process. In this way, after all processes have been checked, the system updates the next check time, forming a periodic daemon loop. This avoids frequent checks that consume system resources while ensuring that critical processes are promptly recovered in the event of abnormal termination.

[0050] In this embodiment, process information of newly added processes in the new process list is collected, and the processes to be protected among the newly added processes are determined based on the process information. Then, a list of processes to be protected is generated based on these processes, and the process status information of the processes in the list is obtained sequentially based on a preset time interval. If a process is terminated and its process status information cannot be obtained or its start time has changed, the terminated process is restarted and removed from the list of processes to be protected. If the process status information of a process to be protected is successfully obtained and its start time has not changed, it is determined that the process to be protected is running normally. In this way, after all processes have been checked, the system updates the next check time, forming a periodic protection loop. This avoids frequent checks that consume system resources and ensures that critical processes can be recovered in a timely manner in the event of abnormal termination.

[0051] As can be seen from the foregoing embodiments, the method of this application requires checking for illegal execution paths and shell commands in the process. These are both security checks. Therefore, this embodiment provides a detailed explanation of how to perform these security checks. See also Figure 11 The diagram shows the illegal process monitoring process.

[0052] This process involves multi-layered security verification for each acquired process to determine its suspiciousness. First, it checks if the process is in self-learning mode; if so, the process name is recorded in the learning list and the check is skipped. Next, it verifies if the process is a child process of the monitoring program itself to avoid false positives. For non-self-learning processes, the parent process information is first obtained and a whitelist inheritance check is performed. If the parent process is in the whitelist, the current process is automatically marked as safe, requiring no further checks. If the whitelist inheritance fails, a series of security checks are performed, including checking if the process path is invalid, if the parent process is an interpreter, if the shell script parameters are safe, and if the process itself is an interpreter. Finally, it checks if the process is in the whitelist. If all checks pass and no anomalies are found, the next process is processed; if an anomaly is found, the corresponding callback function is called for reporting. This entire process ensures multi-dimensional assessment of process security and supports the whitelist inheritance mechanism, reducing false positives.

[0053] It should be noted that the illegal path check process is as follows: at startup, a pre-set whitelist of legal program execution paths is obtained, then the path of the process to be monitored is obtained, and then compared with the pre-set whitelist of legal paths. If the program's execution path is detected to be outside the pre-set whitelist of legal program execution paths, the corresponding callback function is called to issue an alarm.

[0054] See Figure 12 As shown in the figure, this invention discloses a process detection and protection device suitable for Linux, applied to a Linux process protection system, comprising: The whitelist determination module 11 is used to detect the current list of newly added processes. If the list of newly added processes is not empty, the newly added processes in the list of newly added processes are traversed based on the parent-child process relationship, and the process whitelist self-learning is determined according to the preset self-learning field to obtain the current target process whitelist. The detection and alarm module is used to sequentially perform a first whitelist check, a second whitelist check, an illegal execution path check, and a shell command check on the newly added process, and determine whether to issue an illegal process alarm based on the check results; the first whitelist check is to check whether the target parent process of the newly added process is in the target process whitelist; the second whitelist check is to check whether the newly added process is in the target process whitelist. The process protection module 13 is used to generate a list of processes to be protected based on the newly added process list, and to protect the processes based on the list of processes to be protected.

[0055] In this embodiment, newly added processes in the current list of newly added processes can be traversed according to a preset parent-child process relationship. Then, the whitelist is updated through self-learning to obtain the target process whitelist. Next, the newly added processes are sequentially checked against the first whitelist, the second whitelist, illegal execution paths, and shell commands. Based on the check results, it is determined whether to issue an illegal process alert. The first and second whitelist checks are performed based on the target process whitelist. Furthermore, a list of processes to be protected can be generated from the list of newly added processes, and processes can be protected based on this list. This achieves a lightweight integration of monitoring and protection functions, requiring only simple configuration to implement process monitoring and protection without requiring any code to be written by the protected processes.

[0056] In some embodiments, the process detection and protection device suitable for Linux may further include: The set scanning unit is used to scan whether the current set of old processes is empty in order to obtain the corresponding scan results; An old process addition unit is used to determine that the system is running for the first time if the scan result indicates that the current old process set is empty, and to add the currently detected process to the current old process set. The new process addition unit is used to determine that the system is not running for the first time if the scan result indicates that the current old process set is not empty, and to add the currently detected process to the current new process set, and then check whether the process in the current new process set is in the current old process set. The process list adding unit is used to add the target process to the new process list if there is a target process in the current new process set that is not in the current old process set.

[0057] In some embodiments, the whitelist determination module 11 may specifically include: The process order determination unit is used to detect the current list of newly added processes and determine whether the list of newly added processes is empty. If the list of newly added processes is not empty, the process order in the list of newly added processes is determined. The parent process lookup unit is used to determine the current head process in the newly added process list according to the process order, and to search in a loop for whether the head process has a corresponding target parent process in the newly added process list based on the parent-child process relationship; the head process is the first process in the newly added process list, and the target parent process is the ancestor process corresponding to the head process; The first process removal unit is used to remove the head process from the new process list if the target parent process does not exist in the new process list. An error return unit is configured to clear the new process list and return a loop error if the number of loop searches for the head process is greater than the number of new processes in the new process list. The step jump unit is used to jump to the step of determining the current head process in the new process list according to the process order, until the traversal of the new process list is completed.

[0058] In some embodiments, the whitelist determination module 11 may specifically include: The field check unit is used to check whether the current self-learning time configuration field is a preset field; The time calculation unit is used to record the current self-learning time and calculate the self-learning end time if the self-learning time configuration field is different from the preset field. The whitelist merging unit is used to, if the self-learning time has reached the self-learning end time, count the self-learning process whitelist collected during the self-learning period, and merge the self-learning process whitelist with the preset process whitelist to obtain the target process whitelist. The self-learning termination unit is used to terminate self-learning if the self-learning time configuration field is the same as the preset field.

[0059] In some embodiments, the detection alarm module 12 may specifically include: The first detection submodule is used to perform a first whitelist check on the newly added process to determine whether the target parent process of the newly added process exists in the target process whitelist, so as to obtain the first check result; The second detection submodule is used to perform a second whitelist check on the newly added process to determine whether the newly added process exists in the target process whitelist, so as to obtain the second check result; The third detection submodule is used to check the newly added process for illegal execution paths, in order to determine whether the process path of the newly added process is in the preset legal process path whitelist, so as to obtain the third check result. The fourth detection submodule is used to perform shell command checks on the newly added process to determine whether the actual execution commands of the newly added process meet the preset command rules, so as to obtain the fourth check result; The alarm submodule is used to issue a corresponding illegal alarm based on the target inspection result if there is a target inspection result that fails the inspection among the first inspection result, the second detection result, the third inspection result, and the fourth inspection result. The detection loop submodule is used to jump to the detection of the current newly added process list if the first check result, the second check result, the third check result, and the fourth check result all pass the check. If the newly added process list is not empty, the newly added processes in the newly added process list are traversed based on the parent-child process relationship, and a process whitelist self-learning is performed according to a preset self-learning field to obtain the current target process whitelist for the next round of process detection.

[0060] In some embodiments, the fourth detection submodule may specifically include: The process name determination unit is used to obtain the parent process name of the target parent process and determine whether the parent process name is an interpreter name in the preset interpreter list. The instruction acquisition unit is used to acquire a preset shell instruction blacklist if the parent process name is an interpreter name in the preset interpreter list, and to acquire the actual execution instruction corresponding to the newly added process. An expression matching unit is used to check whether the actual executed instruction matches each regular expression in the preset shell instruction blacklist using a preset function. The detection result generation unit is used to generate a fourth check result indicating that the newly added process failed the shell command check if the match is successful, and to generate a fourth check result indicating that the newly added process passed the shell command check if the match fails.

[0061] In some embodiments, the process guardian module 13 may specifically include: The process to be protected unit is used to collect process information of newly added processes in the newly added process list, and determine the process to be protected in the newly added processes based on the process information. The status information acquisition unit is used to generate a list of processes to be protected based on the processes to be protected, and to sequentially acquire the process status information of the processes to be protected in the list of processes to be protected based on a preset process time interval. The second process removal unit is used to restart the terminated process and remove it from the list of processes to be protected if there is a terminated process in the process to be protected that cannot obtain process status information or whose process start time has changed. The startup time determination unit is used to determine that the process to be protected is running normally if the process status information of the process to be protected is successfully obtained and the startup time of the process to be protected has not changed.

[0062] Furthermore, embodiments of this application also disclose an electronic device, Figure 13This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0063] Figure 13 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the process detection and protection method for Linux disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0064] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0065] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0066] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the process detection and protection method for Linux disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0067] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned process detection and protection method applicable to Linux. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0068] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0069] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0070] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0071] Finally, 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.

[0072] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A process detection and protection method suitable for Linux, characterized in that, Used in Linux process daemons, including: The current list of newly added processes is checked. If the list of newly added processes is not empty, the newly added processes in the list of newly added processes are traversed based on the parent-child process relationship. The process whitelist self-learning is determined according to the preset self-learning field to obtain the current target process whitelist. The newly added process is sequentially checked against the first whitelist, the second whitelist, the illegal execution path, and the shell command. Based on the results of these checks, it is determined whether to issue an illegal process alert. The first whitelist check checks whether the target parent process of the newly added process is in the target process whitelist. The second whitelist check checks whether the newly added process is in the target process whitelist. A list of processes to be protected is generated based on the newly added process list, and process protection is performed based on the list of processes to be protected.

2. The process detection and protection method for Linux according to claim 1, characterized in that, Before detecting the current list of newly added processes, and if the list of newly added processes is not empty, traversing the newly added processes in the list based on parent-child process relationships, and determining whether to perform process whitelist self-learning based on a preset self-learning field to obtain the current target process whitelist, the process further includes: Scan the current set of old processes to see if it is empty, and obtain the corresponding scan results; If the scan result indicates that the current old process set is empty, then it is determined that the system is running for the first time, and the currently detected process is added to the current old process set; If the scan result indicates that the current old process set is not empty, then it is determined that the system is not running for the first time, and the currently detected process is added to the current new process set. Then, it is checked whether the process in the current new process set is in the current old process set. If there is a target process in the current new process set that is not in the current old process set, then the target process is added to the new process list.

3. The process detection and protection method for Linux according to claim 1, characterized in that, The process involves detecting the current list of newly added processes. If the list is not empty, the newly added processes in the list are traversed based on parent-child process relationships, including: Detect the current list of newly added processes and determine whether the list of newly added processes is empty. If the list of newly added processes is not empty, determine the order of the processes in the list of newly added processes. The current head process in the newly added process list is determined according to the process order, and the head process is searched cyclically in the newly added process list to see if there is a corresponding target parent process for the head process; the head process is the first process in the newly added process list, and the target parent process is the ancestor process corresponding to the head process. If the target parent process does not exist in the list of newly added processes, then the head process is removed from the list of newly added processes; If the number of loop searches for the head process is greater than the number of new processes in the new process list, then the new process list is cleared and a loop error is returned. Jump to the step of determining the current head process in the newly added process list according to the process order, until the traversal of the newly added process list is completed.

4. The process detection and protection method for Linux according to claim 1, characterized in that, The step of determining whether to perform process whitelist self-learning based on preset self-learning fields to obtain the current target process whitelist includes: Check if the current self-learning time configuration field is a preset field; If the self-learning time configuration field is different from the preset field, the current self-learning time is recorded and the self-learning end time is calculated. If the self-learning time has reached the self-learning end time, the whitelist of self-learning processes collected during the self-learning period is counted, and the whitelist of self-learning processes is merged with the preset process whitelist to obtain the target process whitelist. If the self-learning time configuration field is the same as the preset field, then self-learning ends.

5. The process detection and protection method for Linux according to claim 1, characterized in that, The process sequentially performs checks on the newly added process: a first whitelist check, a second whitelist check, an illegal execution path check, and a shell command check. Based on the check results, it determines whether to issue an illegal process alert, including: The newly added process is subjected to a first whitelist check to determine whether the target parent process of the newly added process exists in the target process whitelist, so as to obtain the first check result; A second whitelist check is performed on the newly added process to determine whether the newly added process exists in the target process whitelist, so as to obtain the second check result; The newly added process is subjected to an illegal execution path check to determine whether the process path of the newly added process is in the preset legal process path whitelist, so as to obtain the third check result; The newly added process is subjected to shell command checks to determine whether the actual execution commands of the newly added process meet the preset command rules, so as to obtain the fourth check result; If any of the first inspection result, the second detection result, the third inspection result, and the fourth inspection result fails the inspection, a corresponding illegal alarm will be issued based on the target inspection result. If the first check result, the second detection result, the third check result, and the fourth check result all pass the check, then jump to the detection of the current newly added process list. If the newly added process list is not empty, then traverse the newly added processes in the newly added process list based on the parent-child process relationship, and determine whether to perform process whitelist self-learning according to the preset self-learning field to obtain the current target process whitelist, so as to perform the next round of process detection.

6. The process detection and protection method for Linux according to claim 5, characterized in that, The step of performing shell command checks on the newly added process to determine whether the actual execution commands of the newly added process meet the preset command rules includes: Obtain the parent process name of the target parent process, and determine whether the parent process name is an interpreter name in the preset interpreter list; If the parent process name is an interpreter name in the preset interpreter list, then obtain the preset shell command blacklist and obtain the actual execution command corresponding to the newly added process; The actual executed instruction is checked using a preset function to see if it matches any regular expression in the preset shell instruction blacklist. If the match is successful, a fourth check result is generated indicating that the newly added process failed the shell command check; if the match fails, a fourth check result is generated indicating that the newly added process passed the shell command check.

7. The process detection and protection method applicable to Linux according to any one of claims 1 to 6, characterized in that, The step of generating a list of processes to be protected based on the newly added process list, and protecting the processes based on the list of processes to be protected, includes: Collect process information of newly added processes in the newly added process list, and determine the processes to be protected in the newly added processes based on the process information; A list of processes to be protected is generated based on the processes to be protected, and the process status information of the processes to be protected in the list is obtained sequentially based on a preset time interval for each process to be protected. If there is a terminated process among the processes to be protected that cannot obtain process status information or whose process start time has changed, then the terminated process is restarted and removed from the list of processes to be protected. If the process status information of the process to be protected is successfully obtained, and the start time of the process to be protected has not changed, then it is determined that the process to be protected is running normally.

8. A process detection and protection device suitable for Linux, characterized in that, Used in Linux process daemons, including: The whitelist determination module is used to detect the current list of newly added processes. If the list of newly added processes is not empty, the newly added processes in the list of newly added processes are traversed based on the parent-child process relationship, and the process whitelist self-learning is determined according to the preset self-learning field to obtain the current target process whitelist. The detection and alarm module is used to sequentially perform a first whitelist check, a second whitelist check, an illegal execution path check, and a shell command check on the newly added process, and determine whether to issue an illegal process alarm based on the check results; the first whitelist check is to check whether the target parent process of the newly added process is in the target process whitelist; the second whitelist check is to check whether the newly added process is in the target process whitelist. The process protection module is used to generate a list of processes to be protected based on the newly added process list, and to protect the processes based on the list of processes to be protected.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the process detection and protection method for Linux as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs, wherein the computer programs, when executed by a processor, implement the process detection and protection method applicable to Linux as described in any one of claims 1 to 7.

Images