Method, system, device and storage medium for monitoring landing of linux full directory file
By using fanotify and cache management, the problem of full file behavior monitoring in Linux systems was solved, enabling efficient, low-cost, and low-memory file monitoring on different distributions, and improving the accuracy and reliability of detection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING JIANGMIN XINKE TECH
- Filing Date
- 2023-03-03
- Publication Date
- 2026-04-28
AI Technical Summary
Existing technologies cannot achieve full monitoring of file behavior in Linux systems, and suffer from problems such as kernel version incompatibility, high maintenance costs, and large memory resource consumption.
Fanotify is used to monitor the file system, record file modification events and manage them using a cache. Combined with a dynamic detection mechanism, these events are pushed to the antivirus engine to extract characteristic behaviors, enabling full-scale directory file monitoring.
It achieves universality across different Linux distributions, improves the accuracy and reliability of detection, reduces memory resource consumption, and reduces maintenance costs.
Smart Images

Figure CN116166626B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of file monitoring technology, and in particular to a method, system, device, and storage medium for monitoring the complete file dumping of Linux directories. Background Technology
[0002] With the rapid development of electronic information technology, terminal security issues have become more prominent. In order to reduce the technical difficulty of security hardening, some security organizations directly use the Linux kernel for protection, but this brings compatibility issues and cannot achieve universality across different Linux distributions. Meanwhile, monitoring solutions based on inotify cannot achieve the goal of full monitoring.
[0003] Traditional solutions rely on kernel file system hook interfaces or simply on inotify detection schemes. Current technologies capture file behavior based on the kernel's "file system hook" interface, and the specific construction method is as follows:
[0004] 1. Install the kernel protection driver, which internally registers the callback interface of the file system Hook;
[0005] 2. When a new file is added locally, the "file system" hook will be invoked, thereby notifying the kernel protection driver;
[0006] 3. The kernel protection driver then notifies the user-space "business layer (file monitoring system)" of the relevant "file events".
[0007] When a new file is added to the system, the file system hook is invoked, and the monitoring system is eventually notified. However, due to incompatibility issues with the kernel driver, this solution lacks general copying capabilities in production environments.
[0008] While the aforementioned document detection method can guarantee user information security to a certain extent, several shortcomings have been found in practical use, preventing it from achieving optimal results. These shortcomings can be summarized as follows:
[0009] 1) Disadvantages of kernel-based hooks: Kernel versions cannot be compatible with all distributions. Each distribution needs to be adapted and compiled, which is not conducive to creating a general solution and has high maintenance costs.
[0010] 2) Traditional inotify-based detection solutions: Due to the limitations of inotify's own technical solutions, it is impossible to achieve the goal of full detection. Even if most directories are detected, the side effect is that memory resources are consumed in large quantities. At the same time, since the number of detections for "same user" is limited, once the number of detections is exhausted by one application, other applications cannot continue to perform detection work (Note: The number of detections can be increased again, but it is not a universal solution and is difficult to implement).
[0011] Therefore, it is evident that the existing document detection methods described above still have inconveniences and shortcomings in use, and urgently need further improvement. Creating a new document detection method has become a pressing goal for the industry. Summary of the Invention
[0012] In view of this, the present disclosure provides a method for monitoring the complete directory file write-to-file in Linux, which at least partially solves the problems existing in the prior art.
[0013] In a first aspect, this disclosure provides a method for monitoring the complete dumping of Linux directory files, the method comprising the following steps:
[0014] Initialize fanotify;
[0015] The file system in the Fanotify monitoring system is used to monitor files.
[0016] When the first write event occurs, fanotify reports the file modification event;
[0017] The path of the file modification event is recorded in the cache, and the timeout period is also recorded.
[0018] According to a specific implementation of an embodiment of this disclosure, the method further includes:
[0019] Determine whether the file modification events in the cache exceed the limit; where,
[0020] When the number of file modification events in the cache does not exceed the limit, the path of the file modification event reported by fanotify is recorded in the cache, and the timeout period is also recorded.
[0021] When the number of file modification events in the cache exceeds the upper limit, the file modification events in the cache are processed.
[0022] According to a specific implementation of this disclosure, processing the file modification event in the cache includes the following steps:
[0023] Periodically traverse the event queue in the cache and retrieve timed-out file modification events;
[0024] The timed-out file modification event is pushed to the antivirus engine to extract valid feature behavior, and the listening to the timed-out file modification event is resumed. At the same time, the timed-out file modification event information is deleted from the cache.
[0025] According to a specific implementation of an embodiment of this disclosure, processing the file modification event in the cache area further includes the following steps:
[0026] Immediately traverse the event queue in the cache and retrieve timed-out file modification events;
[0027] The timed-out file modification event is pushed to the antivirus engine to extract valid feature behavior, and the listening to the timed-out file modification event is resumed. At the same time, the timed-out file modification event information is deleted from the cache.
[0028] According to a specific implementation of an embodiment of this disclosure, the method further includes:
[0029] After a file modification event is reported via Fanotify, the event is temporarily ignored for a preset timeout period.
[0030] According to one specific implementation of the present disclosure, the method is applicable to Linux kernel versions greater than or equal to 2.6.37.
[0031] Secondly, embodiments of this disclosure provide a system for monitoring the complete dumping of Linux directory files, the system comprising:
[0032] The listening module is configured to initialize fanotify; it listens for files based on the file system in the fanotify listening system.
[0033] The reporting module is configured to report file modification events via fanotify when a write event occurs for the first time.
[0034] The caching module is configured to record the path of the file modification event in the cache and record the timeout period.
[0035] According to a specific implementation of an embodiment of this disclosure, the caching module further includes:
[0036] The event handling module is configured to traverse the event queue in the cache and obtain timed-out file modification events; push the timed-out file modification events to the antivirus engine to extract valid feature behaviors, resume listening to the timed-out file modification events, and delete the timed-out file modification event information from the cache.
[0037] Thirdly, embodiments of this disclosure also provide an electronic device, the electronic device comprising:
[0038] At least one processor; and,
[0039] A memory communicatively connected to the at least one processor; wherein,
[0040] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, cause the at least one processor to perform the method for monitoring the full directory files of Linux as described in the first aspect or any implementation thereof.
[0041] Fourthly, embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing computer instructions that, when executed by at least one processor, cause the at least one processor to perform the method for monitoring the finalization of Linux full directory files as described in the first aspect or any implementation thereof.
[0042] Fifthly, embodiments of this disclosure also provide a computer program product, the computer program product including a computing program stored on a non-transitory computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to execute the method for monitoring the finalization of Linux full directory files in the first aspect or any implementation thereof.
[0043] The method for monitoring the final write of all Linux directory files in this embodiment utilizes Fanotify to monitor the Linux file system, and only monitors the "new file" event in the directory. Once a "new file" write is detected, the business layer (file monitoring system) can be notified to detect and scan the file. While possessing the universality of the Linux system, it improves the accuracy and reliability of the detection. Attached Figure Description
[0044] The above is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0045] Figure 1 A flowchart illustrating a method for monitoring the complete dumping of Linux directory files, provided in this embodiment of the disclosure;
[0046] Figure 2 A flowchart illustrating a method for monitoring the complete dumping of Linux directory files, provided in this embodiment of the disclosure;
[0047] Figure 3 A schematic diagram of a system architecture for monitoring the complete dumping of Linux directory files, provided in this embodiment of the disclosure; and
[0048] Figure 4 A schematic diagram of an electronic device provided in an embodiment of this disclosure. Detailed Implementation
[0049] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.
[0050] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.
[0051] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.
[0052] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.
[0053] This invention provides a method for monitoring file write operations across the entire Linux directory. Based on fanotify and incorporating a dynamic detection mechanism algorithm, it addresses the real-time monitoring of file write operations within the file system in proactive Linux defense scenarios. The biggest advantage of this solution is that it does not intrude on the kernel system and achieves high-performance, real-time monitoring of the entire directory. Since the characteristic behavior of file write operations is the creation of files locally and the writing of relevant content into those files, this solution monitors in real-time by detecting write events, and combines this with a dynamic detection mechanism algorithm to improve the accuracy and reliability of the detection.
[0054] Figure 1 This is a schematic diagram illustrating the method flow for monitoring the final write of all directory files in Linux, as provided in an embodiment of this disclosure.
[0055] Figure 2 To and Figure 1 The corresponding flowchart shows the method for monitoring the complete directory file write operation in Linux.
[0056] like Figure 1 As shown, in step S110, fanotify is initialized.
[0057] In step S120, files are monitored based on the file system in the fanotify monitoring system.
[0058] More specifically, based on the fanotify listener system's file system (such as the root file system), it only listens for "file modification" events (or write events).
[0059] Next, proceed to step S130.
[0060] In step S130, when the first write event occurs, fanotify reports the file modification event.
[0061] More specifically, when a "modification event" of a file is first detected, the file contains relatively little content, making it difficult for the AV engine to extract effective "feature behavior". Therefore, the file path can be stored in the cache.
[0062] In this embodiment of the invention, after a file modification event is reported via fanotify, the event is temporarily ignored for a preset timeout period.
[0063] More specifically, fanotify reports a "file modified" event every time a file is written (or a write event is performed). However, this is too repetitive for the business detection layer, which only needs to detect the first instance. Therefore, to prevent repeated reporting of the "modified" event for the file, the event can be "temporarily ignored" with a countdown timer set. The event can then be ignored again after the countdown ends.
[0064] Next, proceed to step S140.
[0065] In step S140, the path of the file modification event is recorded in the cache area, and the timeout period is recorded.
[0066] More specifically, after reporting a file modification event via fanotify, it is necessary to determine whether the file modification event in the cache exceeds the limit.
[0067] Specifically, when the number of file modification events in the cache does not exceed the upper limit, the path of the file modification event reported by fanotify is recorded in the cache, and the timeout period is recorded; when the number of file modification events in the cache exceeds the upper limit, the file modification events in the cache are processed to prevent excessive memory consumption from causing abnormalities in other system services.
[0068] In this embodiment of the invention, processing the file modification event in the cache area includes the following steps:
[0069] Periodically traverse the event queue in the cache and retrieve timed-out file modification events;
[0070] The timed-out file modification event is pushed to the antivirus engine to extract valid feature behavior, and the listening to the timed-out file modification event is resumed. At the same time, the timed-out file modification event information is deleted from the cache.
[0071] In this embodiment of the invention, the method further includes immediately traversing the event queue of the cache area and obtaining timed-out file modification events.
[0072] The timed-out file modification event is pushed to the antivirus engine to extract valid feature behavior, and the listening to the timed-out file modification event is resumed. At the same time, the timed-out file modification event information is deleted from the cache.
[0073] In this embodiment of the invention, the method is applicable to Linux distributions with kernel version 2.6.37 or higher.
[0074] The method for monitoring the landing of all directory files in Linux proposed in this invention is mainly used to detect the intrusion and execution of malicious files. Compared with existing technical solutions, this invention has universality with Linux systems, does not need to worry about distribution compatibility issues, and has also made in-depth optimizations to the detection algorithm to improve detection performance and accuracy.
[0075] Figure 3 The present invention illustrates a system 300 for monitoring the complete directory file persistence of Linux, including a listening module 310, a reporting module 320, and a caching module 330.
[0076] The monitoring module 310 is used to initialize fanotify; it monitors files based on the file system in the fanotify monitoring system.
[0077] The reporting module 320 is used to report file modification events via fanotify when a write event occurs for the first time.
[0078] The caching module 330 is used to record the path of the file modification event in the cache area and record the timeout period.
[0079] In this embodiment of the invention, the cache module 330 further includes:
[0080] The event handling module 3310 is used to traverse the event queue in the cache and obtain timed-out file modification events; push the timed-out file modification events to the antivirus engine to extract valid feature behaviors, resume listening to the timed-out file modification events, and delete the timed-out file modification event information from the cache.
[0081] See Figure 4 This disclosure also provides an electronic device 40, which includes:
[0082] At least one processor; and,
[0083] The memory is communicatively connected to the at least one processor; wherein,
[0084] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method for monitoring the write-to-file of the full Linux directory in the foregoing method embodiments.
[0085] This disclosure also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the method for monitoring the finalization of Linux full directory files in the foregoing method embodiments.
[0086] This disclosure also provides a computer program product, which includes a computing program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions that, when executed by a computer, cause the computer to perform the method for monitoring the finalization of Linux full directory files as described in the foregoing method embodiments.
[0087] The following is for reference. Figure 4 The diagram illustrates a structural schematic of an electronic device 40 suitable for implementing embodiments of the present disclosure. The electronic devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.
[0088] like Figure 4 As shown, electronic device 40 may include a processing unit (e.g., central processing unit, graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from storage device 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of electronic device 40. Processing unit 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.
[0089] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic device 40 to communicate wirelessly or wiredly with other devices to exchange data. Although electronic device 40 with various devices is shown in the figure, it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed alternatively.
[0090] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 409, or installed from a storage device 408, or installed from a ROM 402. When the computer program is executed by a processing device 401, it performs the functions defined in the methods of embodiments of this disclosure.
[0091] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.
[0092] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.
[0093] The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: acquire at least two Internet Protocol (IP) addresses; send a node evaluation request including the at least two IP addresses to a node evaluation device, wherein the node evaluation device selects an IP address from the at least two IP addresses and returns it; and receive the IP address returned by the node evaluation device; wherein the acquired IP address indicates an edge node in a content delivery network.
[0094] Alternatively, the aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: receive a node evaluation request including at least two Internet Protocol (IP) addresses; select an IP address from the at least two IP addresses; and return the selected IP address; wherein the received IP address indicates an edge node in the content delivery network.
[0095] Computer program code for performing the operations of this disclosure can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0097] The units described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a unit does not necessarily limit the unit itself; for example, the first acquisition unit can also be described as "a unit that acquires at least two Internet Protocol addresses".
[0098] It should be understood that the various parts of this disclosure can be implemented in hardware, software, firmware, or a combination thereof.
[0099] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.
Claims
1. A method for monitoring the complete file write-to-directory process in Linux, characterized in that, The method includes the following steps: Initialize fanotify; The file system in the Fanotify monitoring system is used to monitor files. When the first write event occurs, fanotify reports the file modification event; Record the path of the file modification event in the cache and record the timeout period; After a file modification event is reported via fanotify, the event is temporarily ignored for a preset timeout period. Determine whether the file modification events in the cache exceed the limit; where, When the number of file modification events in the cache does not exceed the limit, the path of the file modification event reported by fanotify is recorded in the cache, and the timeout period is also recorded. When the number of file modification events in the cache exceeds the upper limit, the file modification events in the cache are processed, including the following steps: Periodically traverse the event queue in the cache and retrieve timed-out file modification events; The timed-out file modification event is pushed to the antivirus engine to extract valid feature behavior, and the listening to the timed-out file modification event is resumed. At the same time, the timed-out file modification event information is deleted from the cache.
2. The method for monitoring the permanent storage of all directory files in Linux according to claim 1, characterized in that, The process of handling file modification events in the cache area also includes the following steps: Immediately traverse the event queue in the cache and retrieve timed-out file modification events; The timed-out file modification event is pushed to the antivirus engine to extract valid feature behavior, and the listening to the timed-out file modification event is resumed. At the same time, the timed-out file modification event information is deleted from the cache.
3. The method for monitoring the permanent storage of all directory files in Linux according to claim 2, characterized in that, The method described applies to Linux distributions with kernel version 2.6.37 or higher.
4. A system for monitoring the complete dumping of Linux directory files, characterized in that, The system includes: The listening module is configured to initialize fanotify; it listens for files based on the file system in the fanotify listening system. The reporting module is configured to report file modification events via fanotify when a write event occurs for the first time. The caching module is configured to record the path of the file modification event in the cache area and record the timeout period; The caching module also includes: After a file modification event is reported via fanotify, the event is temporarily ignored for a preset timeout period. Determine whether the file modification events in the cache exceed the limit; where, When the number of file modification events in the cache does not exceed the limit, the path of the file modification event reported by fanotify is recorded in the cache, and the timeout period is also recorded. When the number of file modification events in the cache exceeds the upper limit, the file modification events in the cache are processed, including the following steps: Periodically traverse the event queue in the cache and retrieve timed-out file modification events; The timed-out file modification event is pushed to the antivirus engine to extract valid feature behavior, and the listening to the timed-out file modification event is resumed. At the same time, the timed-out file modification event information is deleted from the cache.
5. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, cause the at least one processor to perform the method for monitoring the finalization of all Linux directory files as described in any one of claims 1 to 3.
6. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions that, when executed by at least one processor, cause the at least one processor to perform the method for monitoring the finalization of a full Linux directory file as described in any one of claims 1 to 3.
Citation Information
Patent Citations
Malicious file detection method, device and equipment and readable storage medium
CN114329462A