Process monitoring method, electronic device, storage medium and computer program product

Abstract

This application provides a process monitoring method, electronic device, storage medium, and computer program product. The method includes: acquiring file access events of a target directory; responding to the file access events, reading a process file system to obtain first runtime information of multiple Linux processes, wherein the process file system is used to provide runtime information of all Linux processes under non-privileged user privileges, and the non-privileged user privileges do not have control permissions in the Linux kernel mode; and generating a process activity log based on the first runtime information of the multiple Linux processes. This application's solution allows for more comprehensive monitoring of process activities in a Linux system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a process monitoring method, electronic device, storage medium, and computer program product. Background Technology

[0002] In the Linux operating system (Linux system or simply Linux system), monitoring and protecting against process (Linux process) activity is a core mechanism for the Linux operating system's security, stability, and efficient operation. With the increasing complexity of network environments, external attackers often use malicious processes (such as mining trojans, backdoor programs, etc.) to manipulate privileges or steal data. These processes often disguise themselves as legitimate services or run covertly as short-lived processes. Meanwhile, some abnormal processes may exhaust system resources (such as prolonged full load of CPU / memory / disk), thus triggering a system collapse. Therefore, monitoring process activity is essential.

[0003] In Linux systems, process monitoring typically relies on monitoring tools. However, these tools are prone to missing some processes, making it difficult to achieve comprehensive protection for the Linux system. Summary of the Invention

[0004] To address the related technical issues, embodiments of this application provide a process monitoring method, an electronic device, a storage medium, and a computer program product.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a process monitoring method, the method comprising: Get file access events in the target directory; In response to the file access event, the process file system is read to obtain the first runtime information of multiple Linux processes. The process file system is used to provide runtime information of all Linux processes under non-privileged user privileges, which do not have control privileges in the Linux kernel mode. Based on the initial runtime information of the multiple Linux processes, a process activity log is generated.

[0006] The method in the above scheme further includes: The process file system is read at preset time intervals to obtain second runtime information of multiple Linux processes; wherein the preset time interval is greater than a first preset duration and less than a second preset duration. The step of generating a process activity log based on the first runtime information of the plurality of Linux processes includes: Based on the first runtime information and the second runtime information, a process activity log is generated.

[0007] In the above scheme, obtaining the file access event of the target directory includes: The Inotify interface is used to listen for file access events in the target directory.

[0008] The method in the above scheme further includes: Identify abnormal behavior events in the process activity log; Generate a notification message for the abnormal behavior event.

[0009] In the above scheme, the abnormal behavior events include short-lived process events; identifying abnormal behavior events in the process activity log includes: For each Linux process recorded in the process activity log, the duration of the Linux process is calculated. If the duration of the Linux process is less than the third preset duration, then a short-term process event corresponding to the Linux process is confirmed to have been identified.

[0010] The method in the above scheme further includes: Determine the control parameters used for process monitoring; When the control parameters include the first parameter, the event information of the file access event is recorded in the process activity log, wherein the first parameter is used to indicate the recording of the event information of the file access event.

[0011] In the above scheme, obtaining the file access event of the target directory includes: When the control parameters include the second parameter, file access events corresponding to each directory level of the target directory are obtained, wherein the second parameter is used to indicate that file access events corresponding to each directory level of the target directory are monitored.

[0012] This application also provides an electronic device, including: a processor and a memory for storing a computer program that can run on the processor, wherein the processor executes the steps of the above method when running the computer program.

[0013] This application also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.

[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0015] The process monitoring method, electronic device, storage medium, and computer program product provided in this application, in response to a file access event in a target directory, read a process file system. This process file system provides runtime information of all Linux processes under non-privileged user privileges. By reading the process file system, runtime information of multiple Linux processes can be obtained even under non-privileged user privileges. Then, using the runtime information of multiple Linux processes, a process activity log is generated, enabling monitoring of Linux process activity. Since malicious processes often involve file access events in the target directory, triggering the collection of Linux process runtime information through file access events in the target directory can reduce the probability of missing Linux process activity, thereby providing more comprehensive monitoring of Linux process activity in the Linux system. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the Linux process activity monitoring scheme provided in the embodiments of this application; Figure 2 This is a flowchart illustrating a process monitoring method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating an application example of a process monitoring method provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of a process monitoring device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the application will now be described in further detail with reference to the accompanying drawings.

[0018] Linux is an open-source Unix-like operating system. It supports multi-user, multi-tasking, multi-threading, and multi-CPU (Central Processing Unit) architectures, and is widely used in various hardware platforms such as servers, embedded devices, and terminals, providing a software runtime environment and underlying support framework for hardware resource management and application execution.

[0019] The core component of the Linux system is called the Linux kernel. The Linux kernel is the low-level interface between the Linux system and the hardware. Essentially, the Linux kernel is a set of executable program code, written primarily in C and supplemented by assembly language. The Linux kernel is the core carrier for enabling multi-tasking concurrency, hardware adaptation, and access control within the Linux system.

[0020] The Linux kernel runs at the highest privilege level, a state known as kernel mode. Programs running in kernel mode have complete control over the Linux system and its hardware resources. Kernel mode is the core runtime domain that ensures the security and stability of the Linux system and is one of the permission boundaries distinguishing Linux kernel operations from user operations. Correspondingly, the virtual memory space where the Linux kernel runs is called kernel space. Kernel space is a dedicated memory space and runtime environment provided for the Linux kernel, accessible and manipulated only by programs running in kernel mode.

[0021] In contrast to kernel mode is user mode. User mode is the runtime state where user applications operate with restricted privileges. Programs running in user mode cannot directly access hardware resources or kernel space. The virtual memory space in which user applications run is called user space. User space is a dedicated memory space and runtime environment provided by the Linux system for user-mode applications, accessible and manipulated only by user-mode applications. User space is isolated from and independent of kernel space, effectively isolating user applications from core system components and reducing the probability of user applications accidentally or maliciously damaging the Linux system.

[0022] To ensure the security and stability of Linux systems, the activity of Linux processes is typically monitored. For example, such as... Figure 1 As shown, common Linux process activity monitoring schemes can be broadly categorized into two types: The first type is monitoring schemes implemented in kernel space. For example, these utilize kernel modules (such as the Linux Security Module (LSM)) or the extended Berkeley Packet Filter (eBPF) to monitor and intercept system calls. The second type is monitoring methods implemented in user space. For example, these use monitoring tools such as process status tools (ps) or table of processes tools (top) to query process-related information.

[0023] For the first type of monitoring scheme, the principle of monitoring Linux process activity through kernel modules or eBPF is mainly to insert monitoring logic code into the Linux kernel execution path to capture the parameters, return values, and context information of system calls (i.e., the calling interfaces provided by the Linux kernel) in real time, thereby monitoring system calls. Kernel modules typically intercept calls by directly modifying the system call table (sys_call_table), which is an intrusive monitoring method. eBPF is dynamically mounted to the Linux kernel execution point, such as to the system call entry point or exit point. eBPF does not require modification of the kernel code and is a sandbox program that can run in kernel space. It transmits process-related information obtained during monitoring to user space through the Berkeley Package Map (BPF_MAP) or performance events (perf_event), thereby achieving efficient management of the network status, observability, process tracing, and security of the Linux system.

[0024] The monitoring scheme implemented in kernel mode (i.e., the first type of monitoring scheme mentioned above) has the following main drawbacks: 1. Modifying the system call table using kernel modules to hijack system calls not only easily leads to Linux kernel system crashes and security vulnerabilities, but also requires a significant investment of time and resources to complete version adaptation due to differences in system call tables across different versions, resulting in poor practicality and compatibility of this method.

[0025] 2. While eBPF has significant advantages over kernel modules, it is limited by Linux kernel compatibility and version restrictions, typically only usable on specific or higher versions of the Linux kernel. Furthermore, loading eBPF requires system administration (CAP_SYS_ADMIN, Capability-System-Administration) privileges or superuser privileges (i.e., root privileges), which violates the Linux principle of least privilege. This means that the permissions granted to eBPF exceed the minimum required permissions, posing a security risk.

[0026] 3. Monitoring Linux processes through kernel mode has the drawback of coarse-grained monitoring, making it difficult to directly reflect problems of upper-level custom processes. Furthermore, kernel mode monitoring solutions focus on intercepting system calls, rather than process activity monitoring scenarios, making it difficult to meet the needs for accurate and efficient process activity monitoring.

[0027] For the second type of monitoring scheme, in the user-space runtime environment, the main process monitoring tools for Linux systems are the ps and top tools. Both ps and top tools obtain process-related information by directly reading the process file system (i.e., / proc), thereby enabling the monitoring and querying of process activity.

[0028] The monitoring scheme implemented in user space (i.e., the second type of monitoring scheme mentioned above) has the following main drawbacks: 1. While the ps and top tools are user-space process monitoring tools in Linux systems and have the advantage of being easy to use, the ps tool can only provide a single snapshot of process activity, making it difficult to track and monitor the dynamic changes in process activity and to fully capture the running status of processes.

[0029] 2. Although the top tool can output process-related information in real time, it usually obtains process-related information periodically. This not only consumes a lot of resources, but is also limited by the refresh interval of the top tool, which makes it easy to miss short-lived instantaneous processes. As a result, there are gaps in process activity monitoring, making it difficult to achieve comprehensive and accurate process monitoring.

[0030] Based on this, this application provides a process monitoring scheme. By monitoring file access events in a target directory, and upon detecting such events, the scheme reads the process file system. This process file system provides runtime information for all Linux processes under non-privileged user privileges. Therefore, by reading the process file system, runtime information for multiple Linux processes can be obtained even under non-privileged user privileges. This runtime information is then used to generate a process activity log, enabling monitoring of Linux process activity. Since malicious processes often involve file access events in the target directory, triggering the collection of Linux process runtime information through these events reduces the probability of missing Linux process activity, thus allowing for more comprehensive monitoring of Linux process activity within the Linux system.

[0031] At the same time, it can reduce the impact of process monitoring on Linux kernel compatibility and version dependencies. Since the collection of Linux process runtime information is no longer achieved through high-frequency polling scans, it can also reduce the system resource consumption of process monitoring and reduce its impact on the Linux system.

[0032] The process monitoring scheme provided in the embodiments of this application will be described below with reference to the accompanying drawings. The process monitoring scheme provided in the embodiments of this application can be applied to any electronic device configured with a Linux system. For example, this process monitoring scheme can be applied to electronic devices such as servers, server operating systems, cloud platforms, personal computers, and terminals. The scheme provided in the embodiments of this application will be described below using an electronic device as the executing entity.

[0033] First, this application provides a process monitoring method. For example... Figure 2 As shown, the process monitoring method includes the following steps: Step 201: The electronic device obtains file access events in the target directory; Step 202: In response to the file access event of the target directory, the electronic device reads the process file system and obtains the first runtime information of multiple Linux processes; Step 203: The electronic device generates a process activity log based on the initial runtime information from multiple Linux distributions.

[0034] In this embodiment, the electronic device is configured with a Linux system. To reduce the impact of process monitoring on other processes (i.e., the monitored processes) in the Linux system, in some implementations, the electronic device executes the process monitoring process corresponding to the process monitoring method in this embodiment through an independent monitoring process. In step 201, the electronic device starts an independent monitoring process, and during the operation of the Linux system on the electronic device, file access events of the target directory are obtained through this monitoring process.

[0035] In this embodiment, file access events in the target directory include file access events corresponding to operations such as creating, deleting, modifying, and querying files or directories within the target directory. For example, a file access event is a file or directory creation event (represented as IN_CREATE) or a modification event (represented as IN_MODIFY). The target directory covers most of the activity scenarios of Linux processes, and file access events in the target directory can be used to comprehensively monitor Linux processes.

[0036] The target directory is a file directory that a Linux process may access during its execution. For example, the target directory includes one or more (one or more can be understood as at least one) of the following: system resource directory (i.e., / usr), temporary file directory (i.e., / tmp), user home directory (i.e., / home), variable data directory (i.e., / var), and optional software directory (i.e., / opt).

[0037] The system resource directory stores the Linux system's core programs. By monitoring file access events in the system resource directory, it's possible to promptly detect whether the Linux system's core programs have been tampered with, and to uncover covert operations performed by modifying basic system commands. Simultaneously, changes to critical configuration files within the system resource directory can be monitored, ensuring the integrity and security of the Linux system's operating environment.

[0038] Temporary directories are used to store temporary files generated by the Linux system and applications during runtime. By monitoring these temporary directories, such as the creation or execution of temporary files, malicious processes with short lifecycles can be detected in a timely manner.

[0039] The user's home directory is a file directory used to store user data. For example, the user's home directory stores the user's personal configuration, documents, application data, and operation records. By detecting file access events in the user's home directory, abnormal behavior events can be monitored, such as monitoring unauthorized user accounts accessing the user's home directory, thereby identifying suspicious files appearing in the user's home directory and discovering that sensitive files (such as private key files, password documents, etc.) in the user's home directory have been read or tampered with.

[0040] The log directory is used to store logs. For example, the log directory stores system logs, service logs, application access logs, etc. By detecting file access events in the log directory, it is possible to monitor whether the log files themselves have been tampered with, and to analyze abnormal behaviors recorded in the log files, thereby achieving log integrity and traceability, and providing a reliable basis for security incident tracing and attack behavior analysis.

[0041] The variable data directory is used to store dynamically changing data generated during the operation of the Linux system. By detecting file access events in the variable data directory, abnormal changes to the variable data can be identified, thereby ensuring the integrity and traceability of the Linux system's operation records.

[0042] An optional software directory is used to store files related to third-party applications. By detecting file access events in the application directory, it is possible to detect whether malicious programs have been injected into the application and whether related application files have been modified, thereby ensuring the normal operation of the application.

[0043] In some implementations, electronic devices monitor file access events in the target directory in a non-polling manner. For example, the monitoring process of the electronic device receives file access events triggered by operations such as the creation, deletion, modification, and querying of files or directories in the target directory. In this way, the electronic device can reduce the consumption of system resources while monitoring the target directory.

[0044] For example, the monitoring process of an electronic device listens for file access events in a target directory through the Inotify interface. This Inotify interface is used to listen for file access events, such as those in the target directory.

[0045] The Inotify interface is a file system monitoring interface provided by the Linux kernel. It provides file access event notifications to the monitoring process in a non-polling manner, allowing the monitoring process to monitor file access events triggered by operations such as creation, deletion, modification, and querying of files or directories in the target directory without periodically checking the target directory. This provides a more comprehensive monitoring of Linux process activity.

[0046] In this embodiment, the electronic device may only acquire file access events corresponding to the main directory (i.e., the first-level directory) of the target directory. That is, the electronic device only acquires file access events triggered by operations such as creation, deletion, modification, and querying of files or directories in the main directory of the target directory. Alternatively, the electronic device may acquire file access events corresponding to all levels of directories in the target directory. That is, the electronic device acquires file access events triggered by operations such as creation, deletion, modification, and querying of files or directories in all levels of directories in the target directory. All levels of directories in the target directory include the main directory and all subdirectories.

[0047] In some implementations, electronic devices can determine whether to obtain file access events corresponding to the main directory of the target directory or to obtain file access events corresponding to all levels of the target directory through process monitoring control parameters.

[0048] For example, the monitoring process of an electronic device reads control parameters used for process monitoring. These control parameters are parameters used to control the process monitoring process. The control parameters include one or more command-line arguments. When the process monitoring control parameters include recursive parameters (i.e., the second parameter), the monitoring process of the electronic device listens for file access events corresponding to various levels of directories in the target directory through the Inotify interface.

[0049] The recursive parameter is used to indicate how to listen for file access events corresponding to each level of the target directory. In this way, the electronic device can recursively traverse the file access events corresponding to all levels of the target directory to achieve full directory-wide file access event listening.

[0050] When the control parameters for process monitoring do not include recursive parameters, the monitoring process of the electronic device listens for file access events corresponding to the main directory of the target directory through the Inotify interface. In this way, the electronic device can monitor file access events in the main directory of the target directory.

[0051] In step 202 above, the electronic device responds to a file access event in the target directory by reading the process file system under non-privileged user privileges. For example, the monitoring process of the electronic device responds to a file access event in the target directory by reading the process file system under non-privileged user privileges to obtain runtime information of multiple Linux processes recorded in the process file system.

[0052] The Process File System (Procfs) is used to provide runtime information about all active processes under non-privileged user privileges. It's a pseudo-filesystem provided by the Linux kernel (mounted in the / proc directory) that dynamically stores runtime information for all Linux processes. Because it's not stored on the physical disk but dynamically generated and maintained by the Linux kernel at runtime, it can also be called a virtual filesystem.

[0053] Non-privileged user privileges (i.e., non-root privileges) do not have control permissions in the Linux system kernel mode. Non-privileged user privileges can be understood as having only basic user-mode operation permissions, lacking kernel-level operation permissions such as directly loading kernel modules or modifying kernel parameters. Constrained by the system's permission isolation mechanism, under non-privileged user privileges, electronic devices can only access the files, directories, and process resources belonging to the user with those privileges; they cannot operate on kernel-level core resources or user resources of other users.

[0054] The Linux kernel provides real-time running status of Linux processes to user-space programs through the process file system, allowing monitoring processes for electronic devices to scan the runtime information of each Linux process in the process file system under non-privileged user privileges.

[0055] Linux process runtime information includes process ID (PID), user ID (UID), command (or command line), command line arguments, environment variables, event types, file paths, time information, source Internet Protocol (IP) address, and destination IP address. By understanding the runtime information of Linux processes, we can understand the real-time running status of Linux processes currently operating on electronic devices, thereby effectively capturing the behavior and activities of Linux processes and providing more comprehensive data for system protection.

[0056] In step 203, after obtaining runtime information from multiple Linux processes, the electronic device generates a process activity log based on this information. The process activity log records runtime information from multiple Linux processes. Through the process activity log, system behavior can be visualized, thereby providing a basis for the security protection of the Linux system.

[0057] The process activity log is stored in text format, achieving lightweight log storage. The process activity log includes multiple log records. Each log record includes a timestamp, event type, and process details for each process. Process details include process ID, user ID, command line, file access path, process start time, process exit time, source IP address, and destination IP address.

[0058] In some implementations, the aforementioned control parameters may also include a file event parameter (i.e., the first parameter). This file event parameter is used to indicate event information for recording file access events in the target directory. For example, the event information includes one or more of the following: event type, timestamp, file name, file access path, process identifier that triggered the file access event, and user identifier (one or more can be understood as at least one).

[0059] When the control parameters include file event parameters, the electronic device records the event information of any file access event detected in the target directory. For example, when the control parameters include file event parameters, in response to any file access event in the target directory, the electronic device records the event information of the file access event in the process activity log for visualization.

[0060] Understandably, whether or not file event parameters are included in the control parameters can be set according to actual application needs, thereby meeting the requirements of different application scenarios. Electronic devices can determine whether to record file access event information through file event parameters. If the control parameters include file event parameters, the electronic device records the file access event information in the process activity log, thus making the process activity log more comprehensive. If the control parameters do not include file event parameters, the electronic device does not record file access event information, thereby reducing system load and saving system resources.

[0061] As described above, control parameters are parameters used to control the process monitoring process. For example, control parameters are used to control the listening process of the Inotify interface. In this embodiment, the command-line parameters carried by the control parameters can be set according to actual application needs, thereby meeting the requirements of different application scenarios. Exemplarily, the control parameters include one or more command-line parameters selected from file event parameters (i.e., the first parameter), recursive parameters, range parameters, interval parameters, and color parameters.

[0062] The file event parameter is used to indicate the event information for recording file access events. For example, the file event parameter is represented as -f. When the control parameters include the file event parameter, the electronic device records the event information for any file access event detected in the target directory.

[0063] The recursive parameter is used to instruct the monitoring of file access events at each level of the target directory. For example, the recursive parameter is represented as -r. When the control parameters include the recursive parameter, the electronic device monitors all file access events in the target directory.

[0064] The range parameter is used to indicate which directories within the target directory should be monitored. For example, the range parameter is represented as -r. When the control parameters include the range parameter, the electronic device monitors file access events in the target directory. The target directory includes one or more directories from the system resource directory, temporary file directory, user home directory, variable data directory, and optional software directory mentioned above.

[0065] The interval parameter indicates the periodic scanning cycle of the process file system. For example, the interval parameter is represented as -i. When the interval parameter is included in the control parameters, the electronic device scans the process file system at preset time intervals.

[0066] Color parameters are used to indicate how to mark runtime information or log records of Linux processes with different colors. For example, a color parameter is represented as -c. When color parameters are included in the control parameters, the electronic device outputs runtime information or log records of Linux processes in different colors.

[0067] In this embodiment, the command-line parameters included in the control parameters can be set according to the needs of different process monitoring scenarios. For example, to reduce system load, the control parameters can be set to exclude recursive parameters, so that the electronic device only listens for file access events in the main directory of the target directory. To more comprehensively cover file access events in the target directory, the control parameters can be set to include recursive parameters, so that the electronic device listens for file access events in the entire target directory.

[0068] To more comprehensively collect Linux process activity in a Linux system and reduce the probability of missing some Linux processes, some implementations allow electronic devices to periodically scan the process file system using a polling method, in addition to triggering process file system scans based on file access events. For example, the monitoring process of the electronic device reads the process file system at preset time intervals to obtain runtime information of multiple Linux processes.

[0069] To distinguish between runtime information obtained by reading the process file system in response to file access events and runtime information obtained by periodically scanning the process file system, this paper refers to the runtime information obtained by reading the process file system in response to file access events as the first runtime information, and the runtime information obtained by reading the process file system at preset time intervals as the second runtime information. Electronic devices can generate process activity logs based on the first and second runtime information, thus providing a more comprehensive coverage of all Linux processes.

[0070] The aforementioned preset time interval is the periodic scan cycle of the process file system. In this embodiment, the specific value of the preset time interval can be set according to actual application requirements, and this embodiment does not impose any limitations on this. For example, the preset time interval can be set to 1000 milliseconds, and the electronic device periodically reads the process file system at a 1000-millisecond scan cycle to obtain the second runtime information of multiple Linux processes.

[0071] To reduce the impact of periodic file system scans on system performance, the preset time interval can be set to be greater than a first preset duration and less than a second preset duration. The first and second preset durations can be set according to actual application requirements. For example, the first preset duration can be set to 1000 milliseconds, and the second preset duration can be set to 1024 hours.

[0072] The first preset duration is the lower limit of the preset time interval. By setting the lower limit of the preset time interval, the upper limit of the scanning frequency of the process file system can be controlled, reducing the impact of excessive CPU utilization caused by excessive scanning frequency of the process file system on system performance.

[0073] The second preset duration is the upper limit of the preset time interval. By setting the lower limit of the preset time interval, the lower limit of the scanning frequency of the process file system can be controlled, reducing the occurrence of situations where it is difficult to capture Linux process activity due to the scanning frequency of the process file system being too low.

[0074] In some implementations, after generating a process activity log, the electronic device can perform log event auditing on the log, that is, analyze the process activity log to identify abnormal behavior events. For example, the electronic device can iterate through each log record in the process activity log and determine whether each log record meets preset abnormal conditions. If any log record meets the preset abnormal conditions, the electronic device confirms that an abnormal behavior event has been identified.

[0075] Preset exception conditions can be set according to actual application needs. Different preset exception conditions correspond to different abnormal behavior events. For example, abnormal behavior events include one or more of the following events: sensitive command execution events, short-term process events, high-frequency command events, permission change events, and suspicious IP access events.

[0076] A sensitive command execution event is an event in which a preset command is executed. The preset exception condition for a sensitive command execution event is that the preset command is recorded in the log. The preset command includes any one of the following: Secure Shell (SSH) command, Secure Copy (SCP) command, Substitute User Do (sudo) command, and Substitute User (su) command.

[0077] Electronic devices match the commands executed by Linux processes in their process activity logs with preset commands. If a preset command is matched, it indicates that the log record includes the preset command, and the electronic device confirms that a sensitive command execution event has been identified. By identifying sensitive command execution events, Linux processes executing certain sensitive commands can be discovered, thereby achieving security protection for the Linux system.

[0078] A short-lived process event is an event in which the duration of a Linux process is less than a certain duration (i.e., a third preset duration). The duration of a Linux process is equal to the difference between its exit time and its startup time. The preset exception condition for a short-lived process event is that the duration of the Linux process is less than the third preset duration.

[0079] The electronic device tracks the duration of each Linux process recorded in its process activity log. If the duration of any Linux process is less than a third preset duration, the electronic device identifies a short-lived process event corresponding to that process. By identifying these short-lived process events, transient processes running for short periods in the Linux system (such as password reset tasks) can be discovered, thereby enabling security protection for the Linux system.

[0080] A high-frequency command event is an event in which the same command is executed more than a preset threshold number of times within a unit of time. The preset exception condition for a high-frequency command event is: within a preset unit of time, the number of times a Linux process executes the same command reaches a preset threshold number of times.

[0081] The electronic device counts the number of times each Linux process executes the same command within a preset time period for each Linux process recorded in the process activity log. If the number of times any Linux process executes the same command within the preset time period reaches a preset threshold, the electronic device identifies the high-frequency command event corresponding to that Linux process. By identifying high-frequency command events, Linux processes that execute the same command frequently can be discovered, thereby achieving security protection for the Linux system.

[0082] A permission change event is an event in which user permissions change, such as when a user's permissions change from non-privileged to privileged. The default exception conditions for a permission change event are: the user identifier in the log record changes from a non-privileged user identifier to a privileged user identifier, or the log record includes a default command for permission switching, such as the `sudo` or `su` command.

[0083] The electronic device checks each Linux process recorded in its process activity log to determine whether the process changed its user identity from a non-privileged user to a privileged user, or whether it executed the `sudo` or `su` command. If the process did change its user identity or executed the `sudo` or `su` command, the electronic device has confirmed a permission change event. By identifying permission change events, the device can discover Linux processes involved in permission changes or escalation, thereby enhancing the security of the Linux system.

[0084] Suspicious IP access events refer to events where a Linux process accesses an untrusted IP address. The default anomaly condition for a suspicious IP access event is that the source IP address or destination IP address in the log record is not in the default IP address whitelist (i.e., the set of trusted IP addresses).

[0085] The electronic device checks whether the source or destination IP address accessed by the Linux process in each log record is in a preset IP address whitelist. If any source or destination IP address is not in the preset IP address whitelist, it indicates that the IP address accessed by the Linux process is suspicious, and the electronic device confirms that a suspicious IP access event has been identified. By identifying suspicious IP access events, Linux processes accessing suspicious IP addresses in the Linux system can be discovered, thereby achieving security protection for the Linux system.

[0086] In this embodiment, auditing process activity logs enables effective identification of abnormal behavior events, allowing for targeted handling of these events. In some implementations, after identifying an abnormal behavior event, the electronic device generates a notification message. This notification message can be a color-coded message, text message, sound message, etc.

[0087] For example, after identifying an abnormal behavior event, the electronic device marks the corresponding log record in the process activity log as red, thereby alerting the abnormal behavior event through color difference.

[0088] For example, electronic devices can generate text prompts for abnormal behavior events, which include a summary of the log records of the Linux process corresponding to the abnormal behavior event, thus facilitating the tracing of the Linux process where the abnormal behavior event occurred. For instance, in the case of a permission change event, the electronic device generates a summary of the log records of the Linux process corresponding to the permission change event, thereby tracing the chain of evidence for the permission change.

[0089] In order to promptly handle abnormal behavior events occurring in Linux processes, some implementations can also send alerts about these abnormal behavior events to user account terminals with administrator privileges, thereby reminding administrators to handle them in a timely manner.

[0090] To ensure the adaptability and security of the process monitoring method provided in the embodiments of this application, in some implementations, the process monitoring method is implemented using the Go language.

[0091] The process monitoring method provided in this application embodiment will be further illustrated below through an application example. For example... Figure 3 As shown, this application example includes the following steps: Step 301: The electronic device listens for file access events in the target directory through the Inotify interface.

[0092] The electronic device started the monitoring process with non-privileged user privileges.

[0093] The electronic device employs a monitoring process that recursively listens for file access events in target directories via the Inotify interface. These target directories include / usr, / tmp, / home, / var, and / opt.

[0094] In the example, the monitoring scope can be limited using `-r` and `-d` to reduce system load. Since processes typically access files and directories during runtime (e.g., loading shared libraries, writing logs), this indirectly exposes the process's existence. For example, specifying the target directory after `-r` indicates recursive monitoring of the target directory. Because the `Inotify` interface is a user-space interface provided by the Linux system, monitoring processes running with non-privileged user privileges can also listen for file access events (such as library files being read or temporary files being created) in the target directory through the `Inotify` interface.

[0095] Step 302: In response to a file access event in the target directory, the electronic device scans the process file system.

[0096] After the monitoring process of the electronic device detects a file access event in the target directory through the Inotify interface, it immediately scans the / proc directory of the process file system to obtain runtime information of all currently active processes, such as timestamps, commands, command-line arguments, UIDs, PIDs, event types, and file paths. The file access event triggers the scan of the process file system, serving as an indirect signal for process activity and thus avoiding unnecessary polling of the process file system.

[0097] Step 303: While listening for file access events in the target directory, the electronic device periodically scans the process file system.

[0098] To prevent missing process activity due to missed file access events caused by the Inotify interface, the monitoring process of the electronic device periodically scans the process file system / proc directory while listening for file access events in the target directory through the Inotify interface.

[0099] The scheduled scan period (i.e., the preset time interval) of the process file system can be set using the command-line parameter -i. For example, -i 1000 means scanning the process file system every 1000 milliseconds. Generally, the longer a process runs, the higher the probability of it being captured. However, some short-running, transient processes (such as cron job processes) can be captured through file access events monitored by the Inotify interface, or through scheduled scans.

[0100] Step 304: The electronic device generates a process activity log based on the runtime information obtained from the scan process file system.

[0101] Electronic devices generate process activity logs by capturing runtime information of Linux processes. Monitoring process activity, combined with the collection and storage of these logs, enables visualization of process behavior, supporting security auditing and intrusion detection of abnormal behavior in Linux systems.

[0102] The process monitoring process is divided into log collection and log storage. Log collection begins with the initialization phase of the Inotify interface, which listens on the target directory. For log storage, the electronic device uses a plain text format without database dependency for log persistence. Each log record includes a timestamp, event type, and process details to achieve lightweight storage of process activity logs. When storing process activity logs, logs from different time periods can be fragmented for easier management.

[0103] Whether a process logs file access events can be monitored can be configured using the command-line parameter `-f`, thereby reducing redundancy in the process activity log and lowering system resource overhead. For example, when the control parameter includes `-f`, the electronic device prints file access events to standard output, that is, it records the file access event information in the process activity log.

[0104] Step 305: The electronic device identifies abnormal behavior events in the process activity log.

[0105] Auditing process activity logs on electronic devices can identify abnormal behavior events from the following aspects: 1) File access events trigger process file system scans. Combined with timed process file system scans, capture short-term process events triggered by short-term processes such as cron task processes, for example, short-term process events triggered by password reset script execution processes; 2) Detect suspicious IP access events, such as suspicious IP access events where the source IP address or destination IP address is not in the whitelist; 3) Identify sensitive command execution events and permission change events, such as identifying sensitive commands like ssh and scp, and permission change commands like sudo and su, to trace the evidence chain of permission changes; 4) Extract abnormal behavior events such as high-frequency command events. For example, automatically parse process activity logs using scripting languages ​​such as Python / shell, and extract high-frequency command events and other abnormal behavior events from the process activity logs where the number of times the same command is executed within a preset unit of time reaches a preset threshold.

[0106] When any abnormal behavior event is detected, the electronic device generates a prompt message and marks the abnormal log. For example, different colors are used to mark the log records or abnormal commands corresponding to the abnormal behavior event.

[0107] The ability to mark abnormal behavior events with different colors can be configured via the command-line parameter -c. For example, when the control parameter includes -c, the electronic device prints commands in different colors. Red indicates abnormal commands, and green indicates non-abnormal commands.

[0108] This application example combines file system event listening with process scanning to build an "event-triggered + on-demand scanning" workflow. It provides an efficient and convenient method for monitoring process activity in Linux systems without requiring root privileges. This method is independent of the Linux kernel version, unaffected by kernel compatibility limitations, simple and quick to deploy and use, requires no modifications to the underlying system, and possesses good versatility and ease of use.

[0109] Compared to existing process monitoring tools such as ps and top, this application example runs as an independent process (i.e., the monitoring process), isolated from the monitored process. This avoids interference with the monitored process and eliminates the risk of process malfunctions that may arise with existing monitoring tools. Furthermore, by triggering file access events combined with periodic polling of the process file system, it achieves comprehensive capture of all processes in the Linux system (including transient processes), resolving the technical pain point of existing tools' difficulty in capturing transient processes.

[0110] In this application example, even without relying on root privileges, it can efficiently capture complete information about all active processes in the Linux system, enabling ordinary users to perform high-privilege system monitoring tasks. This effectively avoids system security risks caused by the abuse of root privileges and significantly reduces the security risks of system operation.

[0111] In addition, this method is simple in design and lightweight in architecture, consumes little system resources during operation, and will not have a significant impact on the overall performance of the Linux system even if it runs continuously for a long time. It is suitable for resource-constrained environments and application scenarios requiring continuous monitoring.

[0112] Meanwhile, this method establishes a standardized log collection and auditing process, enables traceability of process activity monitoring, and tracks and displays the creation, destruction, and command execution processes of processes, thereby enhancing system security protection capabilities.

[0113] To implement the memory migration method provided in this application embodiment, this application embodiment also provides a process monitoring device, such as... Figure 4 As shown, the process monitoring device includes: Module 41 is used to obtain file access events in the target directory; The reading module 42 is used to read the process file system in response to the file access event to obtain the first runtime information of multiple Linux processes. The process file system is used to provide runtime information of all Linux processes under non-privileged user privileges, and the non-privileged user privileges do not have control privileges in the Linux kernel mode. The generation module 43 is used to generate process activity logs based on the first runtime information of the multiple Linux processes.

[0114] In some alternative implementations, the reading module 42 is further configured to: The process file system is read at preset time intervals to obtain second runtime information of multiple Linux processes; wherein the preset time interval is greater than a first preset duration and less than a second preset duration. The generation module 43 is specifically used for: Based on the first runtime information and the second runtime information, a process activity log is generated.

[0115] In some optional implementations, the acquisition module 41 is specifically used for: The Inotify interface is used to listen for file access events in the target directory.

[0116] In some alternative implementations, the generation module 43 is further configured to: Identify abnormal behavior events in the process activity log; Generate a notification message for the abnormal behavior event.

[0117] In some optional implementations, the abnormal behavior event includes a short-lived process event; the generation module 43 is specifically used for: For each Linux process recorded in the process activity log, the duration of the Linux process is calculated. If the duration of the Linux process is less than the third preset duration, then a short-term process event corresponding to the Linux process is confirmed to have been identified.

[0118] In some alternative implementations, the generation module 43 is further configured to: Determine the control parameters used for process monitoring; When the control parameters include the first parameter, the event information of the file access event is recorded in the process activity log, wherein the first parameter is used to indicate the recording of the event information of the file access event.

[0119] In some optional implementations, the acquisition module 41 is specifically used for: When the control parameters include the second parameter, file access events corresponding to each directory level of the target directory are obtained, wherein the second parameter is used to indicate that file access events corresponding to each directory level of the target directory are monitored.

[0120] It should be noted that the process monitoring device provided in this application embodiment is only illustrated by the above-described division of program modules. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the process monitoring device and process monitoring method provided in this application embodiment belong to the same concept, and their specific implementation process can be found in the method embodiment, which will not be repeated here.

[0121] Based on the hardware implementation of the above program modules, and in order to implement the method provided in the embodiments of this application, the embodiments of this application also provide an electronic device, such as... Figure 5 As shown, the electronic device includes: The communication interface 501 enables information exchange with other devices (such as terminals); The processor 502 is connected to the communication interface 501 to enable information interaction with other devices and to execute the methods provided by one or more of the above-mentioned technical solutions when running a computer program; The computer program is stored in memory 503.

[0122] Specifically, the processor 502 is used for: Get file access events in the target directory; In response to the file access event, the process file system is read to obtain the first runtime information of multiple Linux processes. The process file system is used to provide runtime information of all Linux processes under non-privileged user privileges, which do not have control privileges in the Linux kernel mode. Based on the initial runtime information of the multiple Linux processes, a process activity log is generated.

[0123] In some alternative implementations, the processor 502 is further configured to: The process file system is read at preset time intervals to obtain second runtime information of multiple Linux processes; wherein the preset time interval is greater than a first preset duration and less than a second preset duration. Based on the first runtime information and the second runtime information, a process activity log is generated.

[0124] In some alternative implementations, the processor 502 is specifically used for: The Inotify interface is used to listen for file access events in the target directory.

[0125] In some alternative implementations, the processor 502 is further configured to: Identify abnormal behavior events in the process activity log; Generate a notification message for the abnormal behavior event.

[0126] In some optional implementations, the abnormal behavior event includes a short-lived process event; the processor 502 is specifically used for: For each Linux process recorded in the process activity log, the duration of the Linux process is calculated. If the duration of the Linux process is less than the third preset duration, then a short-term process event corresponding to the Linux process is confirmed to have been identified.

[0127] In some alternative implementations, the processor 502 is further configured to: Determine the control parameters used for process monitoring; When the control parameters include the first parameter, the event information of the file access event is recorded in the process activity log, wherein the first parameter is used to indicate the recording of the event information of the file access event.

[0128] In some alternative implementations, the processor 502 is further configured to: When the control parameters include the second parameter, file access events corresponding to each directory level of the target directory are obtained, wherein the second parameter is used to indicate that file access events corresponding to each directory level of the target directory are monitored.

[0129] It should be noted that the specific processing procedures of the processor 502 and the communication interface 501 can be understood by referring to the above method.

[0130] Of course, in practical applications, the various components in an electronic device are coupled together through a bus system 504. It can be understood that the bus system 504 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 504 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in... Figure 5 The general designated all buses as Bus System 504.

[0131] The memory 503 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0132] The methods disclosed in the embodiments of this application can be applied to the processor 502, or implemented by the processor 502. For example, the processor 502 is the main processor, including a central processing unit and a memory controller. The processor 502 can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor 502 or by instructions in the form of software. The processor 502 can be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor 502 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in a storage medium, which is located in the memory 503. The processor 502 reads the information in the memory 503 and combines its hardware to complete the steps of the aforementioned method.

[0133] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0134] It is understood that the memory 503 in this embodiment can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0135] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 503 storing a computer program, which can be executed by a processor 502 of an electronic device to complete the steps described in the foregoing method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0136] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by a processor 502 of an electronic device to perform the steps described in the foregoing method.

[0137] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0138] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0139] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A process monitoring method characterized by, The method includes: Get file access events in the target directory; In response to the file access event, the process file system is read to obtain the first runtime information of multiple Linux processes. The process file system is used to provide runtime information of all Linux processes under non-privileged user privileges, which do not have control privileges in the Linux kernel mode. Based on the initial runtime information of the multiple Linux processes, a process activity log is generated.

2. The method of claim 1, wherein, The method further includes: The process file system is read at preset time intervals to obtain second runtime information of multiple Linux processes; wherein the preset time interval is greater than a first preset duration and less than a second preset duration. The step of generating a process activity log based on the first runtime information of the plurality of Linux processes includes: Based on the first runtime information and the second runtime information, a process activity log is generated.

3. The method according to claim 1, characterized in that, The file access event for obtaining the target directory includes: The Inotify interface is used to listen for file access events in the target directory.

4. The method according to claim 1, characterized in that, The method further includes: Identify abnormal behavior events in the process activity log; Generate a notification message for the abnormal behavior event.

5. The method according to claim 4, characterized in that, The abnormal behavior events include short-lived process events; identifying abnormal behavior events in the process activity log includes: For each Linux process recorded in the process activity log, the duration of the Linux process is calculated. If the duration of the Linux process is less than the third preset duration, then a short-term process event corresponding to the Linux process is confirmed to have been identified.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Determine the control parameters used for process monitoring; When the control parameters include the first parameter, the event information of the file access event is recorded in the process activity log, wherein the first parameter is used to indicate the recording of the event information of the file access event.

7. The method according to claim 6, characterized in that, The file access event for obtaining the target directory includes: When the control parameters include the second parameter, file access events corresponding to each directory level of the target directory are obtained, wherein the second parameter is used to indicate that file access events corresponding to each directory level of the target directory are monitored.

8. An electronic device, characterized in that, include: Processor and memory used to store computer programs that can run on the processor; When the processor is used to run a computer program, it executes the steps of the method according to any one of claims 1 to 7.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images