File status monitoring method and related apparatus

Abstract

The file state monitoring method and related device provided by the embodiments of the present application relate to the field of financial technology or other related fields. The method comprises the following steps: obtaining first file information of a file in a container from a file monitoring device of a host computer, obtaining second file information of the file based on a mapping path of the file in the host computer, performing state monitoring on the file according to the first file information, the second file information and baseline file information extracted when the file is deployed in the container, and outputting first alarm information when the state monitoring result indicates that the file is tampered with. The above method can improve the monitoring reliability and alarm timeliness of the file tampering behavior.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a method and apparatus for monitoring the status of documents. Background Technology

[0002] With the widespread adoption of cloud computing and containerization technologies, the deployment efficiency and resource utilization of data center servers have significantly improved. However, while containerization simplifies operations and maintenance, attackers may exploit vulnerabilities or escape containers to compromise applications within containers and tamper with critical files. Such tampering could lead to system malfunctions, data breaches, or even service interruptions.

[0003] Currently, monitoring of file tampering includes local file monitoring and remote file verification, but these methods sometimes fail to detect tampering. Summary of the Invention

[0004] This application provides a file status monitoring method and related apparatus to reduce the failure rate of file tampering monitoring.

[0005] In a first aspect, embodiments of this application provide a document status monitoring method, including:

[0006] Obtain the first file information of the files inside the container from the host machine's file monitoring device;

[0007] Based on the file's mapping path on the host machine, obtain the file's secondary file information;

[0008] Based on the first file information, the second file information, and the file's baseline file information, the file's status is monitored; the baseline file information is the file information extracted when the file is deployed in the container.

[0009] If the status monitoring result indication file is tampered with, the first alarm message will be output.

[0010] In one possible embodiment, the status monitoring of the file is performed based on the first file information, the second file information, and the file's baseline file information, including:

[0011] Cross-compare the information from the first file, the second file, and the baseline file;

[0012] If any part of the content is inconsistent, the file has been tampered with.

[0013] In one possible embodiment, the method further includes:

[0014] In the event that a file has been tampered with, an instruction message is sent to the file monitoring device;

[0015] If no response is received from the monitoring device within a preset time period, it is determined that a container escape attack has occurred.

[0016] Output the second alarm message; the alarm level of the second alarm message is higher than that of the first alarm message.

[0017] In one possible embodiment, the method further includes:

[0018] If a file is tampered with, the corresponding container will be isolated and rolled back to the previous security version.

[0019] In one possible embodiment, the method further includes:

[0020] In the event that a file has been tampered with, abnormal recovery of the tampered file is performed based on baseline file information.

[0021] In one possible embodiment, the method further includes:

[0022] In the event that a file has been tampered with, a file tampering timeline is generated based on the change records in the first file information and the host machine's process monitoring data.

[0023] Based on the time-series mapping of file tampering, the source of tampering is identified and the network connection of the tampering source is blocked.

[0024] In one possible embodiment, the applications need to be deployed on the host machine as containers;

[0025] And / or,

[0026] All applications must be updated as a complete container image.

[0027] In one possible embodiment, based on the file's mapping path on the host machine, the second file information of the file is obtained, including:

[0028] Based on the mapping path, secondary file information of the file is collected through file system hooks or file scanning tools.

[0029] Secondly, embodiments of this application provide a document status monitoring device, comprising:

[0030] The first acquisition module is used to acquire the first file information of the files in the container from the file monitoring device of the host machine;

[0031] The second acquisition module is used to obtain the second file information of a file based on the file's mapping path on the host machine;

[0032] The monitoring module is used to monitor the status of a file based on the first file information, the second file information, and the file's baseline file information; the baseline file information is the file information extracted when the file is deployed in the container.

[0033] The alarm module is used to output the first alarm message if the status monitoring result indication file is tampered with.

[0034] Thirdly, this application provides an electronic device, including: a memory and a processor;

[0035] The memory is used to store computer instructions; the processor is used to execute the computer instructions stored in the memory to implement the method of any one of the first aspects.

[0036] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the method of any of the first aspects.

[0037] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0038] This application provides a file status monitoring method and related apparatus. The method obtains first file information of a file within a container from a file monitoring device on the host machine, and second file information of the file based on the file's mapping path on the host machine. It then monitors the file's status based on the first file information, the second file information, and baseline file information extracted during container deployment. When the status monitoring results indicate that the file has been tampered with, a first alarm message is output. This method establishes a status verification relationship for files within the same container by combining host-side file information acquisition, direct reading of the mapping path, and deployment baseline information. This allows for cross-verification of file status, reducing reliance on a single container runtime environment or periodic remote verification methods. Consequently, it improves the reliability and timeliness of monitoring and alarms for file tampering behavior in scenarios involving high-privilege control, instantaneous tampering, and container escape. Attached Figure Description

[0039] Figure 1 Flowchart of the document status monitoring method provided in the embodiments of this application Figure 1 ;

[0040] Figure 2 Flowchart of the document status monitoring method provided in the embodiments of this application Figure 2 ;

[0041] Figure 3 A schematic diagram illustrating the document status monitoring process provided in this application embodiment;

[0042] Figure 4This is a schematic diagram of the document status monitoring device provided in the embodiments of this application;

[0043] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0045] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect, without limiting their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0046] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0047] It should be noted that the document status monitoring method and related apparatus provided in this application can be used in the field of fintech or other related fields, or in any field other than fintech or other related fields. This application does not limit the application field of the provided document status monitoring method and related apparatus.

[0048] With the widespread application of cloud computing and containerization technologies, the deployment efficiency and resource utilization of data center servers have been significantly improved.

[0049] However, while containerization simplifies operations and maintenance, it also introduces new security challenges. Attackers may exploit vulnerabilities, escalate privileges, or escape containers to compromise applications within containers and tamper with critical files (such as configuration files, executables, or log files). Such tampering can lead to system malfunctions, data breaches, or even service interruptions. For example, in scenarios with extremely high data integrity requirements, such as finance, government, or healthcare, attackers may tamper with business logic code or permission configuration files to perform unauthorized operations or bypass security policies.

[0050] Existing methods for monitoring file tampering in containers mainly fall into two categories: in-container monitoring and remote periodic verification. The former typically involves deploying monitoring programs within the container to detect changes in file content, timestamps, or hash values; the latter usually involves an external server periodically obtaining the status of the target file and comparing it with a preset baseline to determine whether the file is abnormal.

[0051] However, in-container monitoring relies on the container's own runtime environment. Once an attacker gains high privileges, they may shut down the monitoring process, modify the monitoring logic, or clear logs, rendering the monitoring results unreliable. Remote periodic verification is limited by the detection cycle. If an attacker tampers with the data and quickly restores it between two verifications, the abnormal behavior may not be detected. In container escape scenarios, related interfaces, communication links, or host-side data may also be interfered with, further reducing monitoring reliability.

[0052] The aforementioned deficiencies can lead to the inability to promptly and accurately identify critical business files after abnormal modifications, resulting in risks such as manipulation of business logic, bypassing of access controls, or distortion of audit logs. Therefore, maintaining the effectiveness of file status monitoring in complex scenarios such as high-privilege control, instantaneous tampering, and container escape has become a pressing technical problem that needs to be solved.

[0053] In view of this, embodiments of this application provide a file status monitoring method and related apparatus. Through a dual isolation mechanism of containerized deployment and host-level monitoring, combined with independent baseline generation and remote cross-validation, a multi-dimensional and multi-level file tampering monitoring system is constructed. This solves the problems of bypassing monitoring programs within containers, missing detection of instantaneous tampering behavior, and monitoring failure in container escape scenarios, thereby improving the reliability of file tampering identification in containerized environments.

[0054] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0055] Figure 1 A flowchart illustrating a document status monitoring method provided in this application embodiment. Figure 1 ,like Figure 1 As shown, it includes:

[0056] S101. Obtain the first file information of the files in the container from the host machine's file monitoring device.

[0057] In some embodiments, the monitoring server in this application can be a monitoring server that monitors containers on a host machine. For example, a standalone remote host can read and pull monitoring data and file status from the host machine.

[0058] The host machine provides the host environment for running containers and hosts file monitoring devices and the host-side storage location for container files.

[0059] The file monitoring device, serving as the primary source of file information, is deployed on the host machine to collect data on the status of files within the container within the host environment.

[0060] The files inside the container are the objects being monitored. These can be application files, configuration files, script files, certificate files, or log files within the container. These types of files have corresponding actual storage locations in the host machine's file system.

[0061] The first file information is file status data collected by the file monitoring device, which may include at least one of the following: file name, file size, file digest value, modification time, creation time, access time, owner, permission bits, inode identifier, link relationship, and file change events.

[0062] The digest value can be any of md5 (Message-Digest Algorithm 5), sha (Secure Hash Algorithm) 1, or sha256 (Secure Hash Algorithm 256).

[0063] In some optional implementations, the file monitoring device may acquire the first file information of the target file by means of event triggering or periodic collection, and write the acquired first file information into the monitoring cache area for subsequent status monitoring process to call.

[0064] In some embodiments, after container deployment is completed, a mapping relationship between container identifiers and file lists can be established, with the file list recording the logical path within the container, the corresponding host machine path identifier, and file type information.

[0065] When the file monitoring device acquires the first file information, it can first locate the file list based on the container identifier, and then complete the collection item by item.

[0066] S102. Based on the file's mapping path on the host machine, obtain the file's second file information.

[0067] In some embodiments, the mapping path is used to map files within the container to their actual storage locations on the host machine, enabling the monitoring server to bypass the container's internal operating environment and directly access the target files in the host machine's file system.

[0068] The second file information is the file status information directly extracted based on the mapping path. Its field range corresponds to the first file information, including at least one of the following: file name, file size, file digest value, timestamp, owner, permission bits, inode identifier, and file existence identifier.

[0069] For example, the monitoring server can first obtain the file system mount information or mount relationship of the target container, and then resolve the mapping path on the host machine based on the logical path within the container. After determining the mapping path, the monitoring server directly reads the content and metadata of the file corresponding to that path through the host machine's file system interface to generate second file information.

[0070] In one possible embodiment, the monitoring server calls the system file interface to read stat information, obtains the file size, owner, permission bits, inode identifier and timestamp, then calculates the file digest value according to a predetermined digest algorithm, and encapsulates the result as second file information.

[0071] Optionally, if the file corresponding to the mapped path does not exist, is replaced with another type of object, or the path resolution result is inconsistent with the mapping relationship recorded when the container is deployed, the corresponding exception flag is recorded in the second file information.

[0072] S103. Based on the first file information, the second file information, and the baseline file information of the file, perform status monitoring on the file; the baseline file information is the file information extracted when the file is deployed in the container.

[0073] In some embodiments, baseline file information is used to provide an initial reference state of a file when it is deployed in a container, and may include at least one of the following: filename, logical path within the container, host machine mapping path identifier, file size, file digest value, timestamp, owner, permission bits, inode initial identifier, file type, and version identifier.

[0074] Baseline file information is extracted during the container deployment phase or the business image release phase and stored in a baseline library independent of the container runtime environment. The baseline library can be deployed in a protected area on the host machine, or in a remote configuration library or audit storage.

[0075] Status monitoring is used to analyze the current status of a file by integrating information from the first file, the second file, and the baseline file to determine whether the file status is abnormal or has been tampered with.

[0076] For example, the monitoring server first reads the baseline file information of the corresponding file from the baseline library based on the container identifier and file identifier, and then normalizes the first file information and the second file information into a unified comparison data structure.

[0077] The standardization process includes unifying the time format, normalizing the path format, converting the permission representation, verifying the consistency of the digest algorithm, and filling in null fields. After standardization, the monitoring server compares the three types of file information and generates corresponding status monitoring results based on the comparison results.

[0078] S104. If the status monitoring result indication file is tampered with, output the first alarm message.

[0079] In some embodiments, the first alarm information is used to output the determined file tampering event, and its content includes at least one of alarm identifier, file identifier, container identifier, host identifier, alarm time and tampering determination result, and may also include difference information corresponding to the file status monitoring result.

[0080] The primary target for outputting alarm information can be local audit logs, alarm queues, operations and maintenance consoles, or security management systems.

[0081] For example, after the monitoring server receives the status monitoring results, if it determines that the file has been tampered with, it generates and outputs the first alarm message.

[0082] During alarm log generation, the logical path of the target file, the host machine mapping path, the current file status information, the baseline file information, and the alarm time can be written into a unified data structure, and a unique alarm number can be assigned to the alarm. If the output fails, the monitoring server can write the first alarm information into the local queue to be sent and retry the process.

[0083] This application provides a file status monitoring method. It obtains first file information of a file within a container from a file monitoring device on the host machine, and second file information of the file based on the file's mapping path on the host machine. The method monitors the file's status based on the first file information, the second file information, and baseline file information extracted during container deployment. When the status monitoring results indicate that the file has been tampered with, a first alarm message is output. This method establishes a status verification relationship for files within the same container by combining host-side file information acquisition, direct reading of the mapping path, and deployment baseline information. This allows for cross-verification of file status, reducing reliance on a single container runtime environment or periodic remote verification methods. Consequently, it improves the reliability and timeliness of monitoring and alarms for file tampering behavior in scenarios involving high-privilege control, instantaneous tampering, and container escape.

[0084] Below Figure 1 Based on the embodiments shown, the document status monitoring method provided in this application will be further described.

[0085] Figure 2 A flowchart illustrating a document status monitoring method provided in this application embodiment. Figure 2 ,like Figure 2 As shown, it includes:

[0086] S201. Obtain the first file information of the files in the container from the host machine's file monitoring device.

[0087] S202. Based on the file's mapping path on the host machine, obtain the file's second file information.

[0088] For example, the monitoring server can collect secondary file information of a file based on the mapped path, using file system hooks or file scanning tools.

[0089] For example, a file scanning tool traverses and reads files under a mapped path according to a preset cycle, and extracts and calculates file content, metadata and checksums to generate second file information. In practical applications, this tool can be implemented by a host-side inspection process, integrity verification module or external auditing program, and this application embodiment does not limit this.

[0090] In the specific implementation, when a file in the container has a mapping path in the host file system, the path is first parsed and a correspondence between the file identifier and the mapping location is established. Then, depending on the deployment mode, file system hooks can be used to collect file status change information in real time, or file scanning tools can be used to periodically obtain the current file status.

[0091] When using file system hooks, the hook module subscribes to events in the mapped directory on the host machine and converts captured file attribute changes into structured information output. When using file scanning tools, the scanning module recursively accesses the target file along the path, reads its size, modification time, access time, permission bits, and content digest, and combines these fields into second file information. This second file information output can then be directly used for subsequent status monitoring and baseline comparison.

[0092] Since the second file information originates directly from the host machine's mapping path, its collection results do not depend on the container's internal runtime environment. File system hooks can instantly capture state changes when files are accessed, while file scanning tools can supplement static file information at fixed intervals; both can form file observation results on the host machine side. When the second file information obtained in this way is jointly compared with the first file information and baseline file information, file tampering identification can be based on reliable data from the host machine's perspective, thereby improving the effectiveness and consistency of file state monitoring.

[0093] S203. Cross-compare the information in the first file, the information in the second file, and the information in the baseline file.

[0094] S204. If there is any inconsistency in the content at any location, the file is determined to have been tampered with.

[0095] In some embodiments, cross-comparison may refer to verifying the field content at corresponding positions in the first file information, the second file information, and the baseline file information item by item. The field content includes at least one or more of the following: file name, file size, file summary value, timestamp, or owner.

[0096] When the contents of the three sets of information are consistent at the same field position, it indicates that the file status at that position matches the baseline status; when any field position is inconsistent, the file status corresponding to that position can be recorded as abnormal, and a tampering judgment result can be formed accordingly.

[0097] For example, during cross-comparison, the three sets of information can be loaded into the same comparison cache and the same attribute field of the same file can be compared synchronously. When any field in the file summary value, size, or timestamp changes and the change result cannot be consistently mapped among the three sets of information, the processing module outputs the judgment result that the file has been tampered with.

[0098] In the above processing, baseline file information is used to provide an initial trusted reference, first file information reflects the status monitored on the host machine, and second file information reflects the actual file status under the mapping path. By comparing these three together, the remaining data sources can still be retained as verification criteria even if a single data source is interfered with, thus establishing tampering determination based on multi-source consistency verification. If the content at any location in the current file is inconsistent with the baseline file information and also inconsistent with the information from another source, it indicates that an unexpected modification has occurred at that location, and the monitoring module confirms that the file has been tampered with. With the above implementation, file status determination no longer relies on information from a single source, but instead forms a consistent conclusion through the joint verification of three sets of file information. Even if some information in the monitored content within the container or in the host machine mapping path is modified, as long as there is inconsistency at any location, tampering determination can be triggered, thereby improving the accuracy and stability of file anomaly identification in containerized environments.

[0099] S205, Output the first alarm message.

[0100] S206. If the file is tampered with, send an instruction message to the file monitoring device; if no response message is received from the file monitoring device within a preset time, it is determined that a container escape attack exists; output a second alarm message.

[0101] The alarm level of the second alarm message is higher than that of the first alarm message.

[0102] In some embodiments, the indication information is used to monitor the server to trigger a connectivity check of the file monitoring device after detecting inconsistencies between the file content, file summary value, or timestamp and the baseline file information, so as to continue to confirm the monitoring link when there are abnormalities in the files within the container.

[0103] The response information can be a confirmation message, a status receipt, or a heartbeat feedback with a timestamp. Its transmission depends on the normal operation of the monitoring process on the host machine and the fact that the communication link between the container and the host machine is not blocked.

[0104] For example, after detecting that a file has been tampered with, an indication message can be sent to the file monitoring device through a pre-established communication channel. The communication channel can be a local socket, message queue, or encrypted network connection. The content sent includes at least the file identifier, the tampering determination result, and the request response identifier.

[0105] If the file monitoring device returns a response within a preset time after receiving an indication, it indicates that the device is still operational. If no response is returned within that time, it means that the attacker has tampered with files within the container and escaped to the host machine, thus compromising the file monitoring device; that is, a container escape attack is currently in progress. The preset time can be configured based on the monitoring cycle, network latency, and host machine load to match the response characteristics of the target container environment.

[0106] After confirming the existence of a container escape attack, the alarm module outputs a second alarm message, which can be reported to the security operations platform, audit system, or alarm center.

[0107] The second alarm information may include the container identifier, file identifier, tampering time, duration of no response, and escape determination result. Its alarm level is set higher than that of the first alarm information, for example, from a normal alarm to a critical alarm or an emergency alarm. In this way, when file tampering is accompanied by a monitoring link failure, the system can treat the event as a higher-risk event and link it to subsequent handling strategies.

[0108] By further verifying the response status of the file monitoring device after the file has been tampered with, and elevating the judgment to container escape attack when there is no response, it is possible to distinguish between simple file anomalies and monitoring link failures. This allows the second alarm information to reflect higher-level security risks and enhances the completeness of file anomaly event identification and alarm accuracy in containerized environments.

[0109] In some embodiments, to enable containers to quickly return to a secure state and reduce the impact on business operations, if files are tampered with, the corresponding containers can be isolated and rolled back to the previous secure version.

[0110] The previous security version refers to the recoverable state record of the container runtime environment, image layer, mounted data or critical configuration when the file status is confirmed to be normal. This state record can be achieved by container snapshots, image backups or versioned storage, which makes it easy to restore to the untouched state after an anomaly is detected.

[0111] Isolation refers to removing a target container from a business network, shared storage, or scheduling orchestration relationship, thereby stopping it from providing services and restricting further writing of business data. For example, isolation can be achieved by disconnecting the network namespace, freezing the process group, canceling service routes, or switching to an isolated namespace; this application does not limit this approach.

[0112] After a file is tampered with, the file monitoring device on the host machine sends the tampering result to the monitoring server. The monitoring server locates the corresponding running instance based on the container identifier and immediately issues an isolation command to the scheduling system or local controller, putting the container into a controlled isolation state. After isolation is completed, the controller calls the version record saved at runtime of the container, reads the previous security version from the security snapshot associated with the current container, and performs rollback operations on the container's file system layer, mounted volume, or configuration items, restoring the container to the state corresponding to that security version.

[0113] In one implementation, the rollback process first clears the confirmed contaminated write layer, and then remounts the data layer corresponding to the previous secure version to ensure that the contents of the restored container file are consistent with the preset baseline.

[0114] In another implementation, version rollback can also be achieved by rebuilding the image and combining it with persistent data playback.

[0115] The above method, upon detecting file anomalies, first severs the connection between the affected container and the external business environment, and then restores it to a verified secure state, preventing the abnormal file from continuing to participate in business processing. Since isolation and rollback are both performed based on container identifiers, version records, and security snapshots, the impact of file tampering can be limited to a single container, allowing the container to quickly return to a usable and trusted running state.

[0116] In some embodiments, to further reduce the impact of tampering on business operations, in the event of file tampering, abnormal recovery of the tampered file can also be performed based on baseline file information.

[0117] Among them, abnormal recovery based on baseline file information refers to extracting the original content or metadata corresponding to the tampered file from the baseline file information after confirming that the file content, attributes or verification results are inconsistent with the baseline file information, and writing it back to the file location corresponding to the host machine mapping path, so that the file status is restored to the baseline state before tampering.

[0118] To achieve this recovery process, a baseline copy saved by the file monitoring device can be called, or a baseline record stored in conjunction with the container image version can be called to match the version to which the current file belongs and read the corresponding baseline content. When the baseline saves both file content and metadata, the main content of the file is recovered first, and then the corresponding permissions, timestamps and verification information are written synchronously, so that the recovered file is consistent with the baseline in logical state.

[0119] For example, when performing abnormal recovery after a file has been tampered with, the system first determines whether the file has been tampered with based on the first file information, the second file information, and the baseline file information. If the determination is successful, a recovery control command is triggered, carrying the identifier of the file to be recovered, the corresponding baseline version number, and the recovery range. Subsequently, the recovery unit in the host machine locates the tampered file based on the identifier and parses the corresponding original file data from the baseline file information, overwriting it into the target file. If the baseline file information only saves difference fragments, the difference fragments are first combined with the base image content to form a complete file before overwriting. In cases of permission changes, timestamp tampering, or hash drift, attribute write-back can be performed simultaneously, ensuring that the recovered file returns to its state at the time of container deployment in both content and attributes. After recovery, the recovery unit can recalculate the file checksum and compare it with the baseline value. If the comparison matches, a recovery completion status message is output to the monitoring server.

[0120] By building anomaly recovery directly on baseline file information, the original content, metadata, and verification status of the tampered file can be backfilled into the target file, thereby restoring the tampered file to a controllable initial state and providing a consistent data foundation for subsequent file status verification.

[0121] In some embodiments, if a file is tampered with, a file tampering timeline can be generated based on the change records in the first file information and the host machine's process monitoring data; based on the file tampering timeline, a tampering source tracing analysis can be performed to determine the tampering source and block the network connection of the tampering source.

[0122] The change records in the first file information are used to characterize the content changes, timestamp changes, attribute changes, and corresponding triggering events that occurred during the monitoring period. The host machine's process monitoring data is used to characterize the startup, exit, parent-child process relationships, system call access records, and network session records of each process on the host machine. The file tampering time sequence graph is used to reconstruct the correspondence between file state changes and process behavior.

[0123] For example, upon detecting file tampering, the system first extracts the most recent and historical change records from the first file information. Then, it collects process monitoring data adjacent to the file change time from the host machine and aligns them according to a unified time base. Subsequently, the file change event, the process identifier that initiated the change, the parent-child relationship of the processes, the access path, and the network communication target are written into the graph node and edge relationships to form an association structure that reflects "when the file was modified by which process and in what way". This graph can be implemented using a directed graph or a timestamped association graph. Nodes represent file change events, process events, and network events, while edges represent event sequence relationships, call relationships, or causal relationships.

[0124] Based on the generated file tampering timeline, the earliest abnormal change node is backtracked and analyzed. Combined with the process chain, network connection subject and access path that are directly related to it, the tampering source most likely to cause tampering is determined.

[0125] The source of tampering can manifest as a host process, a corresponding process within a container, an external host address, or the network connection it establishes. After tracing the source, the network connection corresponding to the tampering source is blocked. This blocking can be accomplished through host firewall rules, container network policies, or connection table clearing mechanisms, thereby cutting off its ability to continue communicating externally or receiving control commands.

[0126] The above method, by jointly associating file change records with host process monitoring data, can reconstruct the transmission chain after a file has been tampered with, and promptly sever the communication channel once the source of the tampering is identified, making it difficult for subsequent attacks to continue. This improves the accuracy of locating the source of tampering and enhances the ability to handle persistent tampering.

[0127] In some embodiments, applications must be deployed as containers on the host machine.

[0128] In some embodiments, applications on the host machine need to be updated as a complete container image.

[0129] In this context, the application, as the carrier of business functions, is limited to being encapsulated in a container and running on the host machine. The container, as the deployment carrier of the application, incorporates the application and its runtime dependencies into the same image environment, enabling the application to form a controllable and isolated running unit on the host machine side.

[0130] A full container image is used to replace the version of an application. Its update method corresponds to replacing the old image entirely with the new image, rather than making partial hot modifications or individual overwrites to files inside the container.

[0131] In some embodiments, during deployment, the application generates a base image by the image building module, and packages the business code, runtime environment, configuration dependencies and startup scripts into a unified image and distributes it to the host machine. The container engine on the host machine then completes the image pulling, instance creation and container startup, so that the application is deployed on the host machine in the form of a container.

[0132] Correspondingly, when a business version is upgraded, the update module directly obtains the complete container image of the new version, and performs image replacement after image verification, signature comparison, and version number registration. The old container instance stops running, and the new container instance is recreated based on the complete container image, ensuring that the update process is completed on a whole-image basis. To facilitate version tracking, the image version number, release time, and release identifier can be written into the image list and associated with the host machine record during the update. In practical applications, other models of this recording component can also be selected, and this embodiment does not limit this.

[0133] During operation, containerized deployment fixes the application's runtime boundary within the container instance hosted on the host machine. Full container image updates ensure that version changes always correspond to a recognizable and verifiable overall image replacement, thus maintaining consistency between the runtime environment and baseline source upon which file status monitoring relies. Consequently, file information obtained from the host machine, file information within the container, and baseline file information can be mapped to the same image version and the same deployment entity, facilitating subsequent consistency comparisons and tamper detection. With this implementation, the application's deployment and update methods are limited to containerization and full image replacement, maintaining a clear correspondence between the runtime environment, file content, and version status, and providing a more stable data source for file monitoring results based on host machine mapping paths.

[0134] The following is combined Figure 3 The document status monitoring method provided in this application embodiment will be illustrated with a specific example.

[0135] For example, a financial institution's trading system is deployed in a Kubernetes container cluster, with container image version 1.0. An attacker exploits a vulnerability within the container to gain root privileges, tamper with the trading logic file ` / app / transaction_logic.py`, and attempt to clear the container's log files.

[0136] In this scenario, refer to Figure 3 The document status monitoring method provided in this application embodiment may include the following steps:

[0137] Step 1: Container solidification deployment and baseline generation.

[0138] Specifically, in this step, when the trading system container image is released, the container management database (D001) extracts the metadata of key files in the image (such as the MD5 value of / app / transaction_logic.py: cad20b1c0c1c23e..., file size: 1048576, creation time: 2025-01-01 00:01:56, etc.) and stores it in JSON format as baseline data.

[0139] For example, the baseline record of the file / app / transaction_logic.py is:

[0140] {

[0141] "Mirror version": "1.0",

[0142] Filename: " / app / transaction_logic.py",

[0143] File size: 1048576

[0144] "file md5": "cad20b1c0c1c23e...",

[0145] Creation Time: 2025-01-01 00:01:56

[0146] File owner: "appuser"

[0147] }

[0148] This step ensures that the baseline data is generated independently and cannot be tampered with, providing a reliable reference for subsequent tamper detection.

[0149] Step 2: Real-time monitoring at the host layer.

[0150] Specifically, in this step, a container information collection device (D003) is deployed at the host layer to scan the mapping paths of files within the container on the host machine in real time:

[0151] For example: / var / lib / containerID / overlay2 / <container layerID> / merged / app / transaction_logic.py.

[0152] When an attacker tampers with ` / app / transaction_logic.py`, D003 detects a change in the MD5 value of files in the host machine's path and generates log entries in a specific directory (such as ` / var / log / container ID_audit / `).

[0153] 2025-03-15 14:30:45, File path: / app / transaction_logic.py, Old MD5: cad20b1c0c1c23e..., New MD5: 1a2b3c4d5e6f7890...

[0154] This step mitigates the risk of attackers compromising the monitoring program within the container by monitoring the host machine path in real time, ensuring that any tampering is recorded.

[0155] Step 3: Remote cross-validation and alarm triggering

[0156] Specifically, in this step, the remote file monitoring server (D002) periodically retrieves data from the host machine via a one-way communication link, including:

[0157] Information 1: File change log recorded in D003 (as shown in the log entries above).

[0158] Information 2: Current file status on the host machine (obtained through real-time scanning or API calls).

[0159] D002 cross-validates Information 1, Information 2, and the baseline data from D001. If the MD5 value of / app / transaction_logic.py does not match the baseline, the file tampering warning device (D004) is invoked to send an alarm to the operations and maintenance personnel. For example, the alarm information includes:

[0160] Evidence of file tampering: MD5 mismatch event.

[0161] Container escape risk: If D003 does not respond (e.g., an attacker compromises the monitoring program), a high-level alarm will be triggered simultaneously.

[0162] This step addresses the issue of missed detection of momentary tampering through a dual verification mechanism (D003 log + host file status), and ensures that attackers cannot forge the D003 log through remote verification.

[0163] Step 4: Automated Response and Recovery

[0164] Specifically, in this step, if file tampering is detected, the automated response module (an extended function of D002) performs the following operations:

[0165] Container isolation and rollback: Isolate the affected containers and roll back to the most recent security version (based on the D001 baseline version history).

[0166] File recovery and repair: Extract the original version of / app / transaction_logic.py from D001, overwrite the abnormal file on the host machine, and repair file permissions and signatures.

[0167] Attack tracing and blocking: By combining the D003 change log and host process monitoring data, the attack source (such as the attacker's IP address) can be located, and related network connections can be automatically blocked.

[0168] In this example, the attacker tampered with the transaction logic file and deleted the logs within the container. However, because the host-level real-time monitoring (D003) recorded the file MD5 changes, the remote verification server (D002) detected the tampering through cross-validation and triggered an alarm. The automated response module isolated the container and restored the file, ultimately preventing the attacker from further damaging the system. This solution achieves unbypassable detection and rapid recovery of file tampering within the container through the synergy of container-based hardened deployment, host-level monitoring, dual authentication, and automated response.

[0169] Based on the above embodiments, this application also provides a file status monitoring device.

[0170] Figure 4 This is a schematic diagram of the structure of the document status monitoring device 40 provided in the embodiments of this application, as shown below. Figure 4 As shown, it includes:

[0171] The first acquisition module 401 is used to acquire first file information of files in the container from the file monitoring device of the host machine;

[0172] The second acquisition module 402 is used to acquire the second file information of a file based on the file's mapping path on the host machine;

[0173] The monitoring module 403 is used to monitor the status of a file based on the first file information, the second file information, and the file's baseline file information; the baseline file information is the file information extracted when the file is deployed in the container.

[0174] The alarm module 404 is used to output the first alarm message if the status monitoring result indication file is tampered with.

[0175] The file status monitoring device provided in this application embodiment can execute the file status monitoring method shown in any of the above embodiments. Its implementation and technical effects are similar, and will not be described again here.

[0176] This application also provides an electronic device.

[0177] Figure 5 This is a schematic diagram of the structure of the electronic device 50 provided in the embodiments of this application, such as... Figure 5 As shown, the electronic device may include: a transceiver 501, a processor 502, and a memory 503.

[0178] Processor 502 executes computer execution instructions stored in memory, causing processor 502 to perform the scheme in the above embodiments. Processor 502 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0179] The memory 503 is connected to the processor 502 via the system bus and completes communication between them. The memory 503 is used to store computer program instructions.

[0180] Transceiver 501 can perform the functions of receiving and sending data and instructions.

[0181] Optionally, the electronic device 50 may also include a communication interface to communicate and interact with external or internal devices, such as client devices (e.g., mobile phones, tablets). In specific implementations, if the communication interface, memory 503, and processor 502 are implemented independently, they can be interconnected via a bus to complete communication with each other.

[0182] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0183] Optionally, in a specific implementation, if the communication interface, memory 503, and processor 502 are integrated on a single chip, then the communication interface, memory 503, and processor 502 can communicate through an internal interface.

[0184] This application also provides a chip for executing instructions, which is used to execute the technical solutions of the methods described in the above embodiments.

[0185] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the technical solution of the above method embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0186] In one possible implementation, a computer-readable medium may include random access memory (RAM), read-only memory (ROM), compact discread-only memory (CD-ROM) or other optical disc storage, disk storage or other magnetic storage devices, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, Digital Versatile Discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0187] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the technical solution of the above method embodiments. Its implementation principle and technical effects are similar, and will not be repeated here.

[0188] In the specific implementation of the aforementioned terminal device or server, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0189] Those skilled in the art will understand that all or part of the steps in any of the above method embodiments can be implemented by hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium, and when the program is executed, all or part of the steps in the above method embodiments are performed.

[0190] If the technical solution of this application is implemented in software form and sold or used as a product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of this application can be embodied in the form of a software product, which is stored in a storage medium and includes a computer program or several instructions. This computer software product enables a computer device (which may be a personal computer, server, network device, or similar electronic device) to execute all or part of the steps of the methods in the embodiments of this application.

[0191] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0192] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0193] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0194] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0195] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0196] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0197] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0198] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for monitoring file status, characterized in that, include: Obtain the first file information of the files inside the container from the host machine's file monitoring device; Based on the file's mapping path on the host machine, obtain the file's second file information; Based on the first file information, the second file information, and the baseline file information of the file, the status of the file is monitored; the baseline file information is the file information extracted when the file is deployed in the container. If the status monitoring results indicate that the file has been tampered with, then the first alarm message is output.

2. The method according to claim 1, characterized in that, The step of monitoring the status of the file based on the first file information, the second file information, and the baseline file information of the file includes: Cross-compare the first file information, the second file information, and the baseline file information; If any part of the content is inconsistent, the file is determined to have been tampered with.

3. The method according to claim 2, characterized in that, The method further includes: If the file is tampered with, an indication message is sent to the file monitoring device; If no response is received from the monitoring device within a preset time period, it is determined that a container escape attack has occurred. Output a second alarm message; the alarm level of the second alarm message is higher than that of the first alarm message.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: If the file is tampered with, the corresponding container will be isolated and rolled back to the previous security version.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: In the event that the file has been tampered with, the tampered file is restored based on the baseline file information.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: If the file is tampered with, a file tampering time sequence diagram is generated based on the change records in the first file information and the process monitoring data of the host machine; Based on the time-series map of the file tampering, a tampering source analysis is performed to determine the tampering source and block the network connection of the tampering source.

7. The method according to any one of claims 1-3, characterized in that, All applications must be deployed on the host machine as containers; And / or, All applications must be updated as a complete container image.

8. The method according to claim 1, characterized in that, The step of obtaining the second file information of the file based on the mapping path of the file on the host machine includes: Based on the mapping path, the second file information of the file is collected through file system hooks or file scanning tools.

9. A document status monitoring device, characterized in that, include: The first acquisition module is used to acquire the first file information of the files in the container from the file monitoring device of the host machine; The second acquisition module is used to acquire the second file information of the file based on the mapping path of the file on the host machine; The monitoring module is used to monitor the status of the file based on the first file information, the second file information, and the baseline file information of the file; the baseline file information is the file information extracted when the file is deployed in the container. The alarm module is used to output a first alarm message if the status monitoring result indicates that the file has been tampered with.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the method of any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, It stores a computer program, which is executed by a processor to implement the method of any one of claims 1-8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a controller, implements the method of any one of claims 1-8.

Images