A virus detection method, device, equipment and medium of a file

Abstract

The application discloses a file virus detection method and device, equipment and medium, and relates to the field of computers, including: obtaining a preset configuration file, parsing the preset configuration file to generate a file monitoring rule and an alarm rule; adding an initial target to be detected to a monitoring list, performing virus detection on the initial target to be detected in the monitoring list, triggering a virus alarm according to a first detection result; polling a current target to be detected in the monitoring list according to a first preset period, obtaining a file behavior event of the current target to be detected, and determining a corresponding file path and event type; matching the file path and event type with the alarm rule, if the matching is successful, generating a rule alarm, and determining a current file hash value of the current target to be detected, performing virus detection based on the current file hash value, and triggering a virus alarm based on a second detection result. In this way, the application can unify the configuration of file event capture, virus feature detection and event alarm.

Description

Technical Field

[0001] This invention relates to the field of computers, and in particular to a method, apparatus, device, and medium for detecting viruses in files. Background Technology

[0002] With the widespread application of the Linux operating system in servers, cloud computing, embedded devices, and IoT terminals, real-time file system monitoring has become a key technology for system security and stability assurance. By monitoring file creation, modification, and deletion in real time, potential intrusion attempts can be detected promptly, system performance issues can be diagnosed, and abnormal behavior can be quickly located during security audits.

[0003] Currently, the Linux kernel provides the inotify file system event notification mechanism. Inotify is a high-efficiency kernel event-driven monitoring technology that enables fine-grained, asynchronous monitoring of file and directory creation, modification, deletion, movement, and attribute changes. It integrates with the select / poll / epoll multiplexing framework via file descriptors, making it suitable for high-concurrency security scenarios. Compared to traditional polling monitoring, inotify is kernel event-driven, notifying applications only when events occur, thus significantly reducing CPU usage. Compared to fanotify, which is designed to monitor the entire file system, inotify only "notifies" events, resulting in lower kernel overhead. fanotify offers enhanced security capabilities such as interception and access control, but also has a relatively higher performance overhead. In enterprise applications, the monitoring requirements for file systems are becoming increasingly complex: not only is real-time detection of file changes necessary, but also the generation of differentiated alert events based on file type and event type, and immediate virus scanning upon file changes.

[0004] In summary, how to uniformly configure file event capture, virus signature detection, and event alerts is a problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method, apparatus, device, and medium for file virus detection, which can uniformly configure file event capture, virus signature detection, and event alerting. The specific solution is as follows: Firstly, this application provides a method for detecting viruses in files, applied to a multi-functional file monitoring system, including: Obtain a preset configuration file, parse the preset configuration file to generate corresponding file monitoring rules and alarm rules; the file monitoring rules include initial targets to be detected and file behavior events, the initial targets to be detected include initial files to be detected or initial directories to be detected, and the file behavior events include any one or more of the following: access, modification, deletion, creation, and movement of the files to be detected; During system initialization configuration, the initial target to be detected is added to the monitoring list, virus detection is performed on the initial target to be detected in the monitoring list, and a corresponding virus alarm is triggered based on the first detection result; After system initialization is complete, the current target to be detected in the monitoring list is polled according to the first preset period to obtain the file behavior events of the current target to be detected and to determine the corresponding file path and event type; the current target to be detected during the first poll is the initial target to be detected. The file path and event type are matched with the alarm rules. If the match is successful, a corresponding rule alarm is generated, and the current file hash value corresponding to the current target to be detected is determined. Virus detection is performed based on the current file hash value, and a corresponding virus alarm is triggered based on the second detection result.

[0006] Optionally, the step of obtaining a preset configuration file and parsing the preset configuration file to generate corresponding file monitoring rules and alarm rules includes: Read the monitoring rule configuration items in the preset configuration file, extract the path information and corresponding file behavior events of each target to be monitored from the monitoring rule configuration items, and generate corresponding file monitoring rules; Read the alarm rule configuration items in the preset configuration file, and extract the regular expression, behavior event list and event identifier from the alarm rule configuration items to generate the corresponding alarm rule.

[0007] Optionally, adding the initial target to be detected to the monitoring list, performing virus detection on the initial target in the monitoring list, and triggering a corresponding virus alarm based on the first detection result includes: Determine the type of the target to be monitored; If the target to be monitored is the initial file directory to be monitored, then traverse each entry under the initial file directory to be monitored, obtain the complete path corresponding to each entry, and determine whether the entry is a readable file based on the complete path; If the entry contains a readable file, then the first hash value of the corresponding file is determined, and the first hash value is compared with the virus characteristics in the preset virus database; If the first hash value matches the virus characteristics in the preset virus database, a virus alarm is triggered. If the first hash value does not match the virus characteristics in the preset virus database, the system initialization is determined to be complete. If the target to be monitored is the initial file to be detected, then the second hash value of the initial file to be detected is directly determined, and the second hash value is compared with the virus features in the preset virus database; If the second hash value matches the virus characteristics in the preset virus database, a virus alarm is triggered. If the second hash value does not match the virus characteristics in the preset virus database, the system initialization is considered complete.

[0008] Optionally, the step of polling the current target to be detected in the monitoring list according to a first preset period to obtain the file behavior events of the current target to be detected, and determining the corresponding file path and event type, includes: Create a file listening instance and set the file listening instance to non-blocking mode; Each of the currently monitored targets in the monitoring list is registered to the file listening instance to establish a mapping relationship between the event identifier and the monitored target; The file monitoring instance is polled according to the first preset period. When an event is detected, the corresponding file behavior event is read. The corresponding file information is parsed from the file behavior events, and the corresponding file path and event type are determined based on the file information and the mapping relationship.

[0009] Optionally, the step of matching the file path and event type with the alarm rule, and generating a corresponding rule alarm if the match is successful, includes: Read the current alarm rules from the alarm rule list in a preset order; Match the file path with the regular expression of the current alarm rule; If the match fails, determine whether the current alarm rule meets the preset end-of-queue condition in the alarm rule list; If the preset end-of-queue condition is not met, then continue to read new current alarm rules according to the preset order, and re-execute the step of matching the file path with the regular expression of the current alarm rule; If a match is found, determine whether the event type belongs to the list of behavioral events in the current alarm rule; If the event belongs to the list of behavioral events of the current alarm rule, then obtain the event identifier of the current alarm rule, and generate a rule alarm based on the event identifier and the event type.

[0010] Optionally, determining the current file hash value corresponding to the current target to be detected, performing virus detection based on the current file hash value, and triggering a corresponding virus alarm based on the second detection result includes: Determine the event type of the file behavior event of the current target to be detected; If the event type belongs to the first type of preset event, then the access permission to the current target to be detected is temporarily suspended, the current file hash value corresponding to the current target to be detected is determined, and then the access permission to the current target to be detected is restored; the first type of preset event includes modification, move, creation, move-in or move-out events; If the event type belongs to the second type of preset event, the current file hash value of the current target to be detected is directly determined; the second type of preset event includes access, deletion events or directory-related events; The determined hash value of the current file is compared with the virus signature value in the preset virus database; If the comparison matches, a corresponding virus alert will be generated.

[0011] Optionally, the method further includes: During system operation, the current file hash value corresponding to the current target to be detected is determined according to the second preset period, and virus detection is performed based on the current file hash value. The corresponding virus alarm is triggered according to the third detection result.

[0012] Secondly, this application provides a virus detection device for files, applied to a multi-functional file monitoring system, comprising: The rule generation module is used to obtain a preset configuration file and parse the preset configuration file to generate corresponding file monitoring rules and alarm rules. The file monitoring rules include initial targets to be detected and file behavior events. The initial targets to be detected include initial files to be detected or initial directories to be detected. The file behavior events include any one or more of the following: accessing, modifying, deleting, creating, and moving the files to be detected. The first alarm triggering module is used to add the initial target to be detected to the monitoring list during system initialization configuration, perform virus detection on the initial target to be detected in the monitoring list, and trigger the corresponding virus alarm based on the first detection result; The event detection module is used to poll the current target to be detected in the monitoring list according to a first preset period after the system initialization is completed, so as to obtain the file behavior events of the current target to be detected and determine the corresponding file path and event type; the current target to be detected is the initial target to be detected during the first polling. The second alarm triggering module is used to match the file path and event type with the alarm rules. If the match is successful, a corresponding rule alarm is generated, and the current file hash value corresponding to the current target to be detected is determined. Virus detection is performed based on the current file hash value, and a corresponding virus alarm is triggered based on the second detection result.

[0013] Thirdly, this application provides an electronic device, comprising: Memory is used to store computer programs; A processor for executing the computer program to implement the virus detection method for files as described above.

[0014] Fourthly, this application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the virus detection method for the file described above.

[0015] In summary, this application obtains a preset configuration file, parses the preset configuration file to generate corresponding file monitoring rules and alarm rules; the file monitoring rules include initial targets to be detected and file behavior events. The initial targets to be detected include initial files to be detected or initial directories to be detected. The file behavior events include any one or more of the following: access, modification, deletion, creation, and movement of the files to be detected. During system initialization configuration, the initial targets to be detected are added to the monitoring list, and virus detection is performed on the initial targets to be detected in the monitoring list. Based on the first detection result, a corresponding virus alarm is triggered. After system initialization is completed, the current targets to be detected in the monitoring list are polled according to a first preset period to obtain the file behavior events of the current targets to be detected and to determine the corresponding file path and event type. During the first poll, the current targets to be detected are the initial targets to be detected. The file path and event type are matched with the alarm rules. If the match is successful, a corresponding rule alarm is generated, and the current file hash value corresponding to the current target to be detected is determined. Virus detection is performed based on the current file hash value, and a corresponding virus alarm is triggered based on the second detection result. As shown above, this application generates file monitoring and alerting rules through a preset configuration file. During system initialization, initial targets are added to the monitoring list, and virus detection is performed, triggering alerts based on the results. After initialization, the system polls the targets to be detected in the monitoring list at fixed intervals to obtain file behavior events and path information. When a match is found with the alerting rules, a rule-based alert is generated, and virus detection is performed again based on the current file hash value to trigger the corresponding alert. In this way, monitoring rules can be flexibly defined through the configuration file without modifying the code or restarting the service, facilitating batch deployment and subsequent maintenance. Simultaneously, file monitoring, integrity verification, and virus detection are deeply integrated; after an event is triggered, the MD5 cache is automatically updated and the virus database is matched, resulting in a short detection chain and fast response. Attached Figure Description

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

[0017] Figure 1 This is a flowchart of a virus detection method for documents disclosed in this application; Figure 2 This application discloses a specific flowchart for initializing the FileMonitor monitoring engine; Figure 3This application discloses a specific method for adding information to be monitored to the FileMonitor engine graph; Figure 4 This application discloses a specific flowchart of a startup file monitoring engine; Figure 5 This application discloses a specific polling function call graph; Figure 6 This application discloses a specific event callback function execution flowchart; Figure 7 This application discloses a specific flowchart for document virus scanning; Figure 8 This application discloses a specific flowchart of document monitoring and virus scanning. Figure 9 This application discloses a specific method for virus detection of documents. Figure 10 This is a schematic diagram illustrating a specific preset virus database loading method disclosed in this application; Figure 11 This is a schematic diagram of the structure of a virus detection device for documents disclosed in this application; Figure 12 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

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

[0019] Currently, the Linux kernel provides the inotify file system event notification mechanism. Inotify is a high-efficiency kernel event-driven monitoring technology that can perform fine-grained, asynchronous monitoring of file and directory creation, modification, deletion, movement, and attribute changes. It integrates with the select / poll / epoll multiplexing framework through file descriptors, making it suitable for high-concurrency security scenarios. Compared to traditional polling monitoring, inotify is kernel event-driven, notifying applications only when events occur, thus significantly reducing CPU usage. Compared to fanotify, which is designed to monitor the entire file system, inotify only "notifies" events, resulting in lower kernel overhead. fanotify has security capabilities such as interception and access control, offering stronger functionality but also relatively higher performance overhead. In enterprise-level application scenarios, the monitoring requirements for file systems are becoming increasingly complex: not only is real-time detection of file changes necessary, but also the generation of differentiated alert events based on file type and event type, and immediate virus scanning upon file changes. To address these technical issues, this application discloses a file virus detection method, apparatus, device, and medium that can uniformly configure file event capture, virus signature detection, and event alerts.

[0020] See Figure 1 As shown, this invention discloses a method for detecting viruses in files, applied to a multi-functional file monitoring system, which may specifically include: Step S11: Obtain a preset configuration file and parse the preset configuration file to generate corresponding file monitoring rules and alarm rules; the file monitoring rules include initial targets to be detected and file behavior events. The initial targets to be detected include initial files to be detected or initial directories to be detected. The file behavior events include any one or more of the following: accessing, modifying, deleting, creating, and moving the files to be detected.

[0021] In this embodiment, a preset configuration file is obtained through a set configuration path. This configuration file is typically in text format, such as JSON (JavaScript Object Notation), YAML (YAML Ain't Markup Language), or a custom format. Parsing the configuration file mainly involves extracting file monitoring rules and alarm rules.

[0022] It's important to understand that the monitoring rule configuration items in the preset configuration file are read. From these items, the path information and corresponding file behavior events of each target to be monitored are extracted to generate corresponding file monitoring rules. Specifically, the "Monitoring Rule" configuration node is read, and each monitoring rule is parsed iteratively. For each rule, the path of the target to be monitored (e.g., / home / user / test.log) is extracted, and the type of the target to be monitored (file or directory) is determined. The file behavior event types monitored by this rule are extracted, such as "access," "modify," "delete," "create," and "move." The data type can be a list or bitmap, stored in a structure or dictionary, to construct an initial list of monitoring rules. For example, this list can be maintained as a structure or object array, with each element containing information such as path, target type, and event type set, for subsequent use by the monitoring engine.

[0023] Understandably, the alarm rule configuration items in the preset configuration file are read, and regular expressions, a list of behavior events, and event identifiers are extracted from these items to generate the corresponding alarm rules. Specifically, the configuration nodes of the alarm rules are read, each alarm rule is parsed in a loop, and the regular expressions defined in the rules, such as / tmp / , are extracted. The `.exe` file describes the set of files targeted by the rule. It extracts a list of behavioral events that the alert rule is interested in, such as triggering alerts only for "delete" and "modify" actions. It also extracts and stores the event identifier corresponding to the alert rule. id This field is used for the unique location and management of subsequent alarm information; the overall generated alarm rule structure contains the above triples, which are finally summarized into a queryable data structure, such as an array, linked list or hash table.

[0024] In addition, if a configuration file parsing error occurs, an error log will be output and system initialization will be stopped to ensure the validity of the configuration file.

[0025] Step S12: During system initialization configuration, add the initial target to be detected to the monitoring list, perform virus detection on the initial target to be detected in the monitoring list, and trigger the corresponding virus alarm based on the first detection result.

[0026] In this embodiment, during system initialization configuration, a file monitoring instance needs to be created and set to non-blocking mode. Each currently monitored target in the monitoring list is registered to the file monitoring instance to establish a mapping relationship between the event identifier and the monitored target. Specifically, as follows... Figure 2As shown, the Linux inotify mechanism is used to create a listening instance and set it to non-blocking mode to ensure timely response and minimal resource consumption. All targets to be monitored are registered to the listening instance according to the monitoring list. The inotify_add_watch function is used to set the monitoring mask, i.e., the event type set, for files or directories respectively, and the returned monitoring handle (wd) is recorded. A mapping table between wd and the target to be monitored is constructed to facilitate quick location of the file or directory that generated the event when an event is received. Then, two cache queues, watch_file_arr and watch_dir_arr, are created to store the information of the files and directories to be monitored, respectively.

[0027] Then, the loading and virus detection process for the target to be monitored begins. The type of the target to be monitored needs to be determined. If the target to be monitored is the initial directory of files to be detected, then each entry in the initial directory of files to be detected is traversed to obtain the complete path corresponding to each entry, and based on the complete path, it is determined whether the file under the entry is readable. If the file under the entry is readable, then the first hash value of the corresponding file is determined, and the first hash value is compared with the virus features in the preset virus database. If the first hash value matches the virus features in the preset virus database, a virus alarm is triggered. If the first hash value does not match the virus features in the preset virus database, then system initialization is considered complete. If the target to be monitored is the initial file to be detected, then the second hash value of the initial file to be detected is directly determined, and the second hash value is compared with the virus features in the preset virus database. If the second hash value matches the virus features in the preset virus database, a virus alarm is triggered. If the second hash value does not match the virus features in the preset virus database, then system initialization is considered complete.

[0028] Specifically, all initial targets to be detected extracted from the configuration file are added to the monitoring list sequentially. For each target, it is first determined whether it is a file or a directory. If it is a directory, it is retrieved from `watch_dir_arr` and checked using `watch_dir_map` to see if it has already been added. If not, `inotify_add_watch` is called to register it for monitoring. Upon successful registration, the mapping relationship between the monitoring handle (wd) and the monitoring item is saved, and the directory mapping table is updated. This process continues until all directory items have been processed. Then, all directory items under the current directory are traversed. For each ordinary readable file, its MD5 value is calculated and compared with the pre-loaded virus database signature values ​​in memory. If a file's hash value is found to be completely consistent with the virus database, a virus alert is immediately triggered, relevant information is reported, and detailed log entries are recorded. If no file matches the virus database signature, the current object is considered safe, and the loading of the monitoring list continues. If the monitored object is a regular file, first check if its directory has been monitored, then check if the file itself has been added. If not added, call inotify_add_watch to register and save the handle mapping and file mapping table until all file entries have been processed. Then calculate the hash value of the file to be detected and compare it with the virus database. Once a file's hash value is found to be completely consistent with the virus database, a virus alarm is immediately triggered, relevant information is reported and recorded in detail logs.

[0029] Step S13: After the system initialization is completed, poll the current target to be detected in the monitoring list according to the first preset period to obtain the file behavior events of the current target to be detected and determine the corresponding file path and event type; the current target to be detected is the initial target to be detected during the first poll.

[0030] In this embodiment, after the function to add monitoring items is started, such as Figure 3 As shown, it receives information about the target to be detected, including path, directory, file name, type, and event mask, encapsulates it into a file_watch_t structure, and then adds the structure to the corresponding cache queue watch_file_arr or watch_dir_arr according to the type of the target to be detected.

[0031] Once the monitoring rules and targets are loaded, the file monitoring engine will monitor all registered monitoring events of the targets to be detected in the monitoring list through Linux's inotify mechanism. It will poll the listening instances according to the first preset period. When an event is detected, it will read the corresponding file behavior event. It will parse the corresponding file information from the file behavior event and determine the corresponding file path and event type based on the file information and the mapping relationship.

[0032] Specifically, such as Figure 4 As shown, when monitoring directories, the process first iterates through the list of directories to be monitored (watch_dir_arr). For each directory entry, its directory name fw.dir_name is used as the key to check whether the directory has already been added in the directory mapping table watch_dir_map. If it has not been added, the inotify add_watch interface is called to register the directory with the kernel monitoring system. After successful monitoring addition, the returned monitoring index ID is obtained, saved in the detection item (fw.wd_id), and a mapping relationship is established between this index and the directory object. In addition, the directory entry is maintained in watches_dir_map. The process iterates through all directories to be monitored one by one until all directory entries have been added.

[0033] The file monitoring process involves iterating through the list of files to be monitored (watch_file_arr). After obtaining the file name (fw) for each file to be monitored, its directory name and filename are concatenated to obtain the complete path, which serves as the key. First, the file is searched in watch_file_map using fw.dir_name to determine if the directory containing the file is already monitored. Then, watch_dir_map is checked to confirm if the file has been added. If neither has been added, the notify.add_watch interface is called to register the file path with kernel monitoring. Upon successful addition, the monitoring index ID is obtained and stored in fw.wd_id. Simultaneously, a mapping is established between this monitoring ID and the file object (watch_file_map[wd_id] = fw). This approach not only accurately locates each monitored file but also efficiently responds to changes in the underlying file system.

[0034] Subsequently, while monitoring all files or directories, start such as Figure 5 The polling process shown first adds the inotify object to the select polling list and sets a timeout, then calls select to listen for events. If select fails or times out, the current polling ends. If readable events exist, the inotify_event event list is read, each event is processed in a loop, and the listener handle is periodically polled. The corresponding monitoring item is found by monitoring the handle (wd) to determine if there are file behavior events. If an event is generated, the inotify_event event queue is read in batches, and the target path and event type that triggered the event are parsed out. The specific file or directory is located through the mapping table.

[0035] Step S14: Match the file path and event type with the alarm rule. If the match is successful, generate the corresponding rule alarm, determine the current file hash value corresponding to the current target to be detected, perform virus detection based on the current file hash value, and trigger the corresponding virus alarm based on the second detection result.

[0036] In this embodiment, the current alarm rule is read from the alarm rule list according to a preset order; the file path is matched with the regular expression of the current alarm rule; if the match fails, it is determined whether the current alarm rule meets a preset end-of-queue condition in the alarm rule list; if the preset end-of-queue condition is not met, new current alarm rules are read according to the preset order, and the step of matching the file path with the regular expression of the current alarm rule is re-executed; if the match is successful, it is determined whether the event type belongs to the behavior event list of the current alarm rule; if it belongs to the behavior event list of the current alarm rule, the event identifier of the current alarm rule is obtained, and a rule alarm is generated according to the event identifier and the event type.

[0037] Specifically, when the FileMonitor file monitoring engine detects an event occurring in a monitored item, it calls the callback function registered during initialization to capture the event. For example... Figure 6 As shown, the alarm rule queue is traversed sequentially through the callback function. For each alarm rule, the current file path is first matched using the regular expression in the rule. If the match fails, the condition at the end of the queue is checked. If the last rule is not found, the next rule is continued. If the match still fails after finding the last rule, no alarm is generated for this event, and only a normal log is recorded. If the match is successful, it is further determined whether the event type is in the event list of the rule. If the determination is also successful, the event identifier corresponding to the rule is obtained, and the downstream alarm reporting module is called to generate a rule-based alarm.

[0038] In this embodiment, the event type of the file behavior event of the current target to be detected is determined; if the event type belongs to the first type of preset event, the access permission to the current target to be detected is temporarily suspended, the current file hash value corresponding to the current target to be detected is determined, and then the access permission to the current target to be detected is restored; the first type of preset event includes modification, move, creation, move-in, or move-out events; if the event type belongs to the second type of preset event, the current file hash value of the current target to be detected is directly determined; the second type of preset event includes access, deletion events, or directory-related events; the determined current file hash value is compared with the virus feature value in the preset virus database; if the comparison is consistent, a corresponding virus alarm is generated.

[0039] Specifically, once an alarm rule is successfully matched, the corresponding alarm ID is obtained, and the type of the triggering event is determined. If the event type is a modification, move, creation, move-in, or move-out event, it is first checked whether the file is in the FileMonitor monitoring list. If so, access event monitoring for that file is temporarily removed, and then the file's MD5 value is calculated. After the calculation is complete, access event monitoring is restored. If the event type is an access, deletion, or directory-related event, the file's MD5 value is calculated directly. After the MD5 calculation is completed, the MatchVirusDB function is called to match the virus database. If a virus signature is matched, an alarm is triggered directly for the virus file. Subsequently, a standardized alarm message is constructed based on the matched rule event ID and event type. Finally, the alarm message is generated and processed, completing the entire event callback process.

[0040] It is important to know that, such as Figure 7 As shown, after the MatchVirusDB virus matching function starts, it first receives the MD5 value, file path, and triggering file behavior event of the file to be detected. It performs double validity checks on the MD5 to exclude null values ​​and invalid data in non-standard formats. If the checks pass, it performs a high-speed search operation on the virus database hash set in memory. If the corresponding MD5 feature value is found, the file is determined to be a virus file, and the virus log is automatically recorded, alarm information is encapsulated, and alarm reporting is completed. If no match is found, the file is determined to be a safe file, and the matching result is finally returned, completing the complete virus detection process.

[0041] As can be seen from the above, if Figure 8 As shown, this embodiment generates file monitoring and alarm rules through a preset configuration file. During system initialization, initial targets are added to the monitoring list, and virus detection is performed, triggering alarms based on the results. After initialization, the targets to be detected in the monitoring list are polled at fixed intervals to obtain file behavior events and path information. When a match is found with the alarm rules, a rule alarm is generated, and virus detection is performed again based on the current file hash value to trigger the corresponding alarm. In this way, monitoring rules can be flexibly defined through configuration files without modifying code or restarting the service, facilitating batch deployment and subsequent maintenance. At the same time, file monitoring, integrity verification, and virus detection are deeply integrated. After an event is triggered, the MD5 cache is automatically updated and the virus database is matched, resulting in a short detection chain and fast response.

[0042] See Figure 9 As shown, this invention discloses a method for detecting viruses in files, applied to a multi-functional file monitoring system, which may specifically include: Step S21: Obtain a preset configuration file and parse the preset configuration file to generate corresponding file monitoring rules and alarm rules; the file monitoring rules include initial targets to be detected and file behavior events. The initial targets to be detected include initial files to be detected or initial directories to be detected. The file behavior events include any one or more of the following: accessing, modifying, deleting, creating, and moving the files to be detected.

[0043] The specific implementation process of step S21 can be found in the relevant content disclosed in the foregoing embodiments, and will not be repeated here.

[0044] Step S22: During system initialization configuration, add the initial target to be detected to the monitoring list, perform virus detection on the initial target to be detected in the monitoring list, and trigger the corresponding virus alarm based on the first detection result.

[0045] In this embodiment, as Figure 10 As shown, during system initialization configuration, the storage path of the virus database file (from file_monitor to virus_db_path) is parsed from the configuration file, and then the virus database file is opened. If the file fails to open, a log is recorded and loading is terminated. If the file opens successfully, the MD5 signature values ​​in the file are read line by line. After filtering invalid data and removing duplicate values, all valid virus MD5 signature values ​​are stored in the memory hash set. Finally, the file is closed to release resources, completing the memory loading of the virus database and providing a data foundation for subsequent high-speed virus matching.

[0046] Step S23: During system operation, the current file hash value corresponding to the current target to be detected is determined according to the second preset period, and virus detection is performed based on the current file hash value. The corresponding virus alarm is triggered according to the third detection result.

[0047] In this embodiment, while triggering virus detection through rule-based alerts, a separate virus scanning queue is established in the system. All targets to be monitored are included in this queue during the initialization phase, and newly added or modified files are dynamically added to the queue during operation. The queue is periodically polled at set time intervals. Each time, a target to be detected is retrieved from the queue, its type is determined, and if it is a file, its hash value is directly calculated and compared with virus signature values ​​in a preset virus database. If it is a directory, each file entry in the directory is traversed, its hash value is calculated one by one, and a comparison is performed. Once a file's hash value matches a signature value in the virus database, a virus alert is immediately triggered, and the file's path, hash value, and detection time are recorded.

[0048] As can be seen from the above, by using the virus scanning queue, the periodic scanning path can cover those files that have been stored silently for a long time and have not generated any file system events, ensuring that even if the virus database is updated during system operation, previously unidentified virus files can still be found through periodic scanning.

[0049] See Figure 11 As shown, this embodiment of the invention discloses a virus detection device for files, applied to a multi-functional file monitoring system, comprising: The rule generation module 11 is used to obtain a preset configuration file and parse the preset configuration file to generate corresponding file monitoring rules and alarm rules. The file monitoring rules include initial targets to be detected and file behavior events. The initial targets to be detected include initial files to be detected or initial directories to be detected. The file behavior events include any one or more of the following: accessing, modifying, deleting, creating, and moving the files to be detected. The first alarm triggering module 12 is used to add the initial target to be detected to the monitoring list during system initialization configuration, perform virus detection on the initial target to be detected in the monitoring list, and trigger the corresponding virus alarm based on the first detection result; Event detection module 13 is used to poll the current target to be detected in the monitoring list according to a first preset period after the system initialization is completed, so as to obtain the file behavior events of the current target to be detected and determine the corresponding file path and event type; the current target to be detected is the initial target to be detected during the first polling. The second alarm triggering module 14 is used to match the file path and event type with the alarm rules. If the match is successful, a corresponding rule alarm is generated, and the current file hash value corresponding to the current target to be detected is determined. Virus detection is performed based on the current file hash value, and a corresponding virus alarm is triggered based on the second detection result.

[0050] As shown above, this application generates file monitoring and alerting rules through a preset configuration file. During system initialization, initial targets are added to the monitoring list, and virus detection is performed, triggering alerts based on the results. After initialization, the system polls the targets to be detected in the monitoring list at fixed intervals to obtain file behavior events and path information. When a match is found with the alerting rules, a rule-based alert is generated, and virus detection is performed again based on the current file hash value to trigger the corresponding alert. In this way, monitoring rules can be flexibly defined through the configuration file without modifying the code or restarting the service, facilitating batch deployment and subsequent maintenance. Simultaneously, file monitoring, integrity verification, and virus detection are deeply integrated; after an event is triggered, the MD5 cache is automatically updated and the virus database is matched, resulting in a short detection chain and fast response.

[0051] In some specific implementations, the rule generation module 11 may specifically include: The first rule generation unit is used to read the monitoring rule configuration items in the preset configuration file, extract the path information and corresponding file behavior events of each target to be monitored from the monitoring rule configuration items, and generate corresponding file monitoring rules. The second rule generation unit is used to read the alarm rule configuration items in the preset configuration file, extract regular expressions, behavior event lists and event identifiers from the alarm rule configuration items, and generate the corresponding alarm rules.

[0052] In some specific implementations, the first alarm triggering module 12 may specifically include: The first type determination unit is used to determine the type of the target to be monitored; The file judgment unit is used to, if the target to be monitored is the initial file directory to be detected, traverse each entry under the initial file directory to be detected, obtain the complete path corresponding to each entry, and determine whether the entry is a readable file based on the complete path; The first feature comparison unit is used to determine the first hash value of the corresponding file if the entry is a readable file, and compare the first hash value with the virus features in the preset virus database. The first virus alarm unit is used to trigger a virus alarm if the first hash value matches the virus characteristics in the preset virus database. The first initialization completion unit is used to determine that the system initialization is complete if the first hash value does not match the virus characteristics in the preset virus database. The second feature comparison unit is used to directly determine the second hash value of the initial file to be detected if the target to be monitored is the initial file to be detected, and compare the second hash value with the virus features in the preset virus database. The second virus alarm unit is used to trigger a virus alarm if the second hash value matches the virus characteristics in the preset virus database. The second initialization completion unit is used to determine that the system initialization is complete if the second hash value does not match the virus characteristics in the preset virus database.

[0053] In some specific implementations, the event detection module 13 may specifically include: An instance creation unit is used to create a file listening instance and set the file listening instance to non-blocking mode; A relationship establishment unit is used to register each of the currently monitored targets in the monitoring list to the file listening instance, so as to establish a mapping relationship between the event identifier and the monitored target; The event reading unit is used to poll the file monitoring instance according to a first preset period, and read the corresponding file behavior event when an event is detected. The path and type determination unit is used to parse the corresponding file information from the file behavior event, and determine the corresponding file path and event type based on the file information and the mapping relationship.

[0054] In some specific implementations, the second alarm triggering module 14 may specifically include: The rule reading unit is used to read the current alarm rule from the alarm rule list according to a preset order; The first rule matching unit is used to match the file path with the regular expression of the current alarm rule; The first rule determination unit is used to determine whether the current alarm rule meets the preset end-of-line condition in the alarm rule list if the matching fails. The second rule matching unit is used to continue reading new current alarm rules according to a preset order if the preset end-of-queue condition is not met, and to re-execute the step of matching the file path with the regular expression of the current alarm rule. The second rule determination unit is used to determine whether the event type belongs to the list of behavioral events of the current alarm rule if a match is successful. The rule alarm generation unit is used to obtain the event identifier of the current alarm rule if the event belongs to the list of behavioral events of the current alarm rule, and generate a rule alarm based on the event identifier and the event type.

[0055] In some specific implementations, the second alarm triggering module 14 may specifically include: The second type determination unit is used to determine the event type of the file behavior event of the current target to be detected; The first hash value determination unit is used to temporarily suspend access to the current target to be detected if the event type belongs to a first type of preset event, determine the current file hash value corresponding to the current target to be detected, and then restore access to the current target to be detected; the first type of preset event includes modification, move, creation, move-in or move-out events; The second hash value determination unit is used to directly determine the current file hash value of the current target to be detected if the event type belongs to the second type of preset event; the second type of preset event includes access, deletion events or directory-related events; The third feature comparison unit is used to compare the determined hash value of the current file with the virus feature value in the preset virus database; The third virus alarm unit is used to generate a corresponding virus alarm if the comparison is consistent.

[0056] In some specific embodiments, the virus detection device for the document may further include: The virus alarm module is used to determine the current file hash value corresponding to the current target to be detected according to a second preset period during system operation, perform virus detection based on the current file hash value, and trigger a corresponding virus alarm based on the third detection result.

[0057] Furthermore, embodiments of this application also disclose an electronic device, Figure 12 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the virus detection method for files disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

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

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

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

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

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

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

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

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

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

Claims

1. A method for detecting viruses in files, characterized in that, Applications include: [List of applications] A preset configuration file is obtained and parsed to generate corresponding file monitoring rules and alarm rules. The file monitoring rules include initial targets to be monitored and file behavior events. The initial targets to be monitored include initial files to be monitored or initial directories to be monitored. The file behavior events include any one or more of the following: accessing, modifying, deleting, creating, and moving the files to be monitored. The alarm rules include regular expressions, a list of behavior events, and event identifiers. The regular expressions are used to describe the set of files under each file path that the alarm rule targets. The event identifiers are used for the location and management of alarm information. The list of behavior events includes each of the file behavior events. During system initialization configuration, the initial target to be detected is added to the monitoring list, virus detection is performed on the initial target to be detected in the monitoring list, and a corresponding virus alarm is triggered based on the first detection result; After system initialization is complete, the current target to be detected in the monitoring list is polled according to the first preset period to obtain the file behavior events of the current target to be detected and to determine the corresponding file path and event type; the current target to be detected during the first poll is the initial target to be detected. The file path and event type are matched with the alarm rules. If the match is successful, a corresponding rule alarm is generated, and the current file hash value corresponding to the current target to be detected is determined. Virus detection is performed based on the current file hash value, and a corresponding virus alarm is triggered based on the second detection result.

2. The virus detection method for documents according to claim 1, characterized in that, The process of obtaining a preset configuration file and parsing the preset configuration file to generate corresponding file monitoring rules and alarm rules includes: Read the monitoring rule configuration items in the preset configuration file, extract the path information and corresponding file behavior events of each target to be monitored from the monitoring rule configuration items, and generate corresponding file monitoring rules; Read the alarm rule configuration items in the preset configuration file, and extract the regular expression, behavior event list and event identifier from the alarm rule configuration items to generate the corresponding alarm rule.

3. The virus detection method for documents according to claim 2, characterized in that, The steps of adding the initial target to be detected to the monitoring list, performing virus detection on the initial target in the monitoring list, and triggering a corresponding virus alarm based on the first detection result include: Determine the type of the target to be monitored; If the target to be monitored is the initial file directory to be monitored, then traverse each entry under the initial file directory to be monitored, obtain the complete path corresponding to each entry, and determine whether the entry is a readable file based on the complete path; If the entry contains a readable file, then the first hash value of the corresponding file is determined, and the first hash value is compared with the virus characteristics in the preset virus database; If the first hash value matches the virus characteristics in the preset virus database, a virus alarm is triggered. If the first hash value does not match the virus characteristics in the preset virus database, the system initialization is determined to be complete. If the target to be monitored is the initial file to be detected, then the second hash value of the initial file to be detected is directly determined, and the second hash value is compared with the virus features in the preset virus database; If the second hash value matches the virus characteristics in the preset virus database, a virus alarm is triggered. If the second hash value does not match the virus characteristics in the preset virus database, the system initialization is considered complete.

4. The virus detection method for documents according to claim 3, characterized in that, The step of polling the current target to be detected in the monitoring list according to a first preset period to obtain the file behavior events of the current target to be detected, and determining the corresponding file path and event type, includes: Create a file listening instance and set the file listening instance to non-blocking mode; Each of the targets to be monitored in the monitoring list is registered to the file listening instance to establish a mapping relationship between the event identifier and the target to be monitored; The file monitoring instance is polled according to the first preset period. When an event is detected, the corresponding file behavior event is read. The corresponding file information is parsed from the file behavior events, and the corresponding file path and event type are determined based on the file information and the mapping relationship.

5. The virus detection method for documents according to claim 4, characterized in that, The step involves matching the file path and event type with the alarm rule. If a match is found, a corresponding rule alarm is generated, including: Read the current alarm rules from the alarm rule list in a preset order; Match the file path with the regular expression of the current alarm rule; If the match fails, determine whether the current alarm rule meets the preset end-of-queue condition in the alarm rule list; If the preset end-of-queue condition is not met, then continue to read new current alarm rules according to the preset order, and re-execute the step of matching the file path with the regular expression of the current alarm rule; If a match is found, determine whether the event type belongs to the list of behavioral events in the current alarm rule; If the event belongs to the list of behavioral events of the current alarm rule, then obtain the event identifier of the current alarm rule, and generate a rule alarm based on the event identifier and the event type.

6. The virus detection method for documents according to claim 5, characterized in that, The steps include determining the current file hash value corresponding to the current target to be detected, performing virus detection based on the current file hash value, and triggering a corresponding virus alarm based on the second detection result, including: Determine the event type of the file behavior event of the current target to be detected; If the event type belongs to the first type of preset event, then the access permission to the current target to be detected is temporarily suspended, the current file hash value corresponding to the current target to be detected is determined, and then the access permission to the current target to be detected is restored; the first type of preset event includes modification, move, creation, move-in or move-out events; If the event type belongs to the second type of preset event, the current file hash value of the current target to be detected is directly determined; the second type of preset event includes access, deletion events or directory-related events; The determined hash value of the current file is compared with the virus signature value in the preset virus database; If the comparison matches, a corresponding virus alert will be generated.

7. The virus detection method for documents according to any one of claims 1 to 6, characterized in that, Also includes: During system operation, the current file hash value corresponding to the current target to be detected is determined according to the second preset period, and virus detection is performed based on the current file hash value. The corresponding virus alarm is triggered according to the third detection result.

8. A virus detection device for documents, characterized in that, Applications include: [List of applications] The rule generation module is used to obtain a preset configuration file and parse the preset configuration file to generate corresponding file monitoring rules and alarm rules. The file monitoring rules include initial targets to be detected and file behavior events. The initial targets to be detected include initial files to be detected or initial directories to be detected. The file behavior events include any one or more of the following: accessing, modifying, deleting, creating, and moving the files to be detected. The alarm rules include regular expressions, a list of behavior events, and event identifiers. The regular expressions are used to describe the set of files under each file path that the alarm rule targets. The event identifiers are used for the location and management of alarm information. The list of behavior events includes each of the file behavior events. The first alarm triggering module is used to add the initial target to be detected to the monitoring list during system initialization configuration, perform virus detection on the initial target to be detected in the monitoring list, and trigger the corresponding virus alarm based on the first detection result; The event detection module is used to poll the current target to be detected in the monitoring list according to a first preset period after the system initialization is completed, so as to obtain the file behavior events of the current target to be detected and determine the corresponding file path and event type; the current target to be detected is the initial target to be detected during the first polling. The second alarm triggering module is used to match the file path and event type with the alarm rules. If the match is successful, a corresponding rule alarm is generated, and the current file hash value corresponding to the current target to be detected is determined. Virus detection is performed based on the current file hash value, and a corresponding virus alarm is triggered based on the second detection result.

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

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer program is executed by a processor, it implements the virus detection method for files as described in any one of claims 1 to 7.

Images