A method and apparatus for handling abnormal behavior of containers

Abstract

This invention provides a method and apparatus for handling abnormal behavior of containers. The method includes: performing anomaly detection on acquired container behavior logs; if abnormal behavior is detected, generating a corresponding decision result based on the abnormal behavior through a set anomaly decision strategy; and performing anomaly handling on the container based on the decision result. This method enables anomaly analysis from the container's behavior, improves the accuracy of security protection, and ensures the confidentiality, integrity, reliability, and availability of information.

Description

Technical Field

[0001] This invention relates to the field of computer technology, particularly to the field of artificial intelligence technology, and especially to a method and apparatus for handling abnormal behavior of containers. Background Technology

[0002] Docker, as a lightweight virtualization solution, has gradually demonstrated significant advantages and gained widespread adoption across various fields. However, it has also exposed numerous security vulnerabilities. Due to its inherent characteristics, Docker suffers from poor isolation and complex security hardening, leading to security issues such as container escape, container and host machine failure, and user data leakage. Most security protection solutions proposed by related technologies are based on single-node Docker deployments, but the more widely used approach is microservice application deployment based on Docker container clusters. Furthermore, current Docker security solutions are mostly attack prevention measures, offering relatively low accuracy and failing to guarantee the confidentiality, integrity, reliability, and availability of information. Summary of the Invention

[0003] One object of the present invention is to provide a method for handling abnormal container behavior, which can perform anomaly analysis on container behavior to improve the accuracy of security protection, thereby ensuring the confidentiality, integrity, reliability, and availability of information. Another object of the present invention is to provide a device for handling abnormal container behavior. A further object of the present invention is to provide a computer-readable medium. A still other object of the present invention is to provide a computer device.

[0004] To achieve the above objectives, this invention discloses a method for handling abnormal behavior of containers, comprising:

[0005] Perform anomaly detection on the acquired container behavior logs;

[0006] If abnormal behavior is detected, a corresponding decision result is generated based on the abnormal behavior according to the set abnormal decision-making strategy;

[0007] The container is handled abnormally based on the decision result.

[0008] Preferably, before performing anomaly detection on the acquired container behavior logs, the method further includes:

[0009] Obtain the container's behavior logs using log collection tools and log extraction commands.

[0010] Preferably, anomaly detection is performed on the acquired container behavior logs, including:

[0011] Anomaly detection model is constructed to detect anomalies in behavior logs and obtain detection results, which include abnormal or normal behavior.

[0012] Preferably, the log extraction command includes at least one of the following: a run log command, an event command, and a history command;

[0013] Obtain container behavior logs using log collection tools and log extraction commands, including:

[0014] Collect behavioral log source data using log collection tools;

[0015] By running log commands, the running logs of each process in the container can be extracted from the behavior log source data;

[0016] System event logs are extracted from behavior log source data using event commands;

[0017] Extract historical version information of a specified image from the behavior log source data using historical commands;

[0018] Generate behavior logs based on runtime logs, system event logs, and historical version information of the specified image.

[0019] Preferably, before performing anomaly detection on the behavior logs using the constructed anomaly detection model and obtaining the detection results, which include either abnormal or normal behavior, the method further includes:

[0020] The acquired sample logs are normalized and concatenated to obtain a sample vector. The sample logs include normal sample logs with normal labels and abnormal sample logs with abnormal labels.

[0021] An anomaly detection model is obtained by training a deep learning model using sample logs.

[0022] Preferably, abnormal behavior includes improper access requests;

[0023] By setting abnormal decision-making strategies, corresponding decision results are generated based on abnormal behavior, including:

[0024] Match the decision policies corresponding to improper access requests from the abnormal decision policies. The decision policies include stop access commands, permission judgment policies and file isolation judgment policies.

[0025] Abnormal behavior is judged by permission judgment strategy and file isolation judgment strategy, and permission results and isolation results are obtained;

[0026] The decision result is generated based on the stop access command, permission results, and isolation results.

[0027] Preferably, abnormal behavior is judged through permission judgment strategy and file isolation judgment strategy to obtain permission result and isolation result, including:

[0028] By using the permission decision policy, the execution permissions of the container to which the abnormal behavior belongs are determined, and the corresponding permission results are obtained.

[0029] By using a file isolation decision strategy, the file type corresponding to the abnormal behavior is determined, and the corresponding isolation result is obtained.

[0030] Preferably, the execution permissions of the container to which the abnormal behavior belongs are determined through a permission decision strategy to obtain the corresponding permission results, including:

[0031] If the container to which the abnormal behavior belongs has priority privileges, the permission decision policy is used to match and determine the permission result to disable the priority privileges.

[0032] Preferably, a file isolation decision strategy is used to determine the file type corresponding to the abnormal behavior and obtain the corresponding isolation result, including:

[0033] If the file type corresponding to the abnormal behavior includes the system kernel, the file isolation judgment policy is used to determine whether the container has been illegally mounted to the kernel folder;

[0034] If so, generate the isolation result of unmounting and isolating the kernel folder.

[0035] Preferably, the decision results include the stop access command, the permission result, and the isolation result. The permission result is to disable priority privileges, and the isolation result is to unmount and isolate the kernel folder.

[0036] Exception handling for containers based on decision results includes:

[0037] In response to the stop access command, stop the container's access request; in response to the permission result, disable the container's priority privileges; in response to the isolation result, unmount the container from the kernel folder and isolate the kernel folder.

[0038] The present invention also discloses a container abnormal behavior handling device, comprising: a log system unit, an abnormal detection unit, an abnormal decision unit, and an abnormal handling unit;

[0039] The logging system unit is used to send the container's behavior logs to the anomaly detection unit;

[0040] The anomaly detection unit is used to detect anomalies in the container's behavior logs; if an anomaly is detected, it is sent to the anomaly decision unit.

[0041] The abnormal decision-making unit is used to generate corresponding decision results based on abnormal behavior according to the set abnormal decision-making strategy, and send the decision results to the abnormal handling unit;

[0042] The exception handling unit is used to handle exceptions to containers based on the decision results.

[0043] The present invention also discloses a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0044] The present invention also discloses a computer device, including a memory and a processor, wherein the memory is used to store information including program instructions, and the processor is used to control the execution of the program instructions, wherein the processor executes the program to implement the method described above.

[0045] The present invention also discloses a computer program product, including a computer program / instructions that, when executed by a processor, implement the method described above.

[0046] This invention performs anomaly detection on the acquired container behavior logs; if anomaly behavior is detected, a corresponding decision result is generated based on the anomaly decision strategy; and the container is anomaly handled based on the decision result. This allows for anomaly analysis from the container behavior, improving the accuracy of security protection and ensuring the confidentiality, integrity, reliability, and availability of information. Attached Figure Description

[0047] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a logical diagram illustrating abnormal behavior handling of a container, provided in an embodiment of the present invention.

[0049] Figure 2 A flowchart of a container abnormal behavior handling method provided in an embodiment of the present invention;

[0050] Figure 3 A flowchart illustrating another method for handling abnormal container behavior provided in an embodiment of the present invention;

[0051] Figure 4 This is a schematic diagram of the structure of a container abnormal behavior processing device provided in an embodiment of the present invention;

[0052] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0053] 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.

[0054] To facilitate understanding of the technical solutions provided in this application, the relevant content of the technical solutions in this application will be explained below. Currently, in power systems, measuring devices such as electricity meters, terminals, and digital instruments all rely on mature operating systems. If they are subject to external technical constraints and restrictions, it will disrupt the current software ecosystem of measuring devices, making it impossible to select a suitable operating system and causing catastrophic problems affecting equipment research and development and application. Therefore, based on the current status of power system terminal equipment, it is necessary to conduct research on key technologies of lightweight embedded operating systems and develop and design an autonomous, secure, and controllable underlying operating system and its basic applications for intelligent measuring devices. The fusion terminal used in this invention is one type of terminal and uses the aforementioned lightweight embedded operating system. This system uses Docker technology for system security isolation, but based on the security issues of Docker itself, a security solution is proposed. The fusion terminal used in this invention is one type of terminal and uses the aforementioned lightweight embedded operating system. This system uses container engine (Docker) technology for system security isolation, but based on the security issues of Docker itself, a security solution is proposed. The smart grid is a digital grid built on integrated, high-speed, and bidirectional communication networks based on modern information technology, covering all aspects of power generation, transmission and transformation, dispatching, distribution, and users. As an emerging cloud platform, Docker breaks away from the traditional virtual machine-based cloud computing model, providing developers with a platform for building, deploying, and running distributed applications, using containers as the basic unit. Addressing the aforementioned security issues with Docker, this invention proposes a solution for recording, analyzing, and making corresponding decisions and actions regarding Docker behavior. When a container malfunctions or is hijacked, it may make inappropriate access requests, frequently access the database, or consume excessive resources, negatively impacting the system. Recording and analyzing various Docker behaviors facilitates early detection and timely handling of anomalies, thereby ensuring the normal operation of the system.

[0055] The following uses a container abnormal behavior handling device as an example to illustrate the implementation process of the container abnormal behavior handling method provided in this embodiment of the invention. It is understood that the execution subject of the container abnormal behavior handling method provided in this embodiment of the invention includes, but is not limited to, a container abnormal behavior handling device.

[0056] Example 1:

[0057] Figure 1 This is a logical diagram illustrating a container abnormal behavior handling method provided in an embodiment of the present invention, such as... Figure 1 As shown, the container behavior of a Docker container is recorded in the logging system. Container behavior includes, but is not limited to, runtime status, file reading, and resource usage. The logging system periodically sends log data to the anomaly detection module. The anomaly detection module detects abnormal behavior based on the log data, including but not limited to improper access requests, frequent database access, and excessive resource consumption. The anomaly detection module sends the detected abnormal behavior to the decision module. The decision module, based on the set anomaly decision policy, obtains a decision result according to the abnormal behavior. The decision result includes, but is not limited to, access control, resource restrictions, and forced container shutdown. The decision module sends the decision result to the processing module. The processing module calls the set processing mechanism to perform anomaly handling operations on the container based on the decision result. The processing mechanism includes, but is not limited to, Linux Security Modules (LSM) hook functions, control groups (Cgroups), and Docker instructions.

[0058] Example 2:

[0059] Figure 2 A flowchart of a container abnormal behavior handling method provided in an embodiment of the present invention is shown below. Figure 2 As shown, the method includes:

[0060] Step 101: Perform anomaly detection on the obtained container behavior logs.

[0061] Step 102: If abnormal behavior is detected, generate corresponding decision results based on the abnormal behavior according to the set abnormal decision strategy.

[0062] Step 103: Perform exception handling on the container based on the decision results.

[0063] In the technical solution provided by the embodiments of the present invention, anomaly detection is performed on the acquired container behavior logs; if abnormal behavior is detected, a corresponding decision result is generated based on the abnormal behavior through the set anomaly decision strategy; the container is anomaly handled according to the decision result, which can perform anomaly analysis from the behavior of the container, improve the accuracy of security protection, and thus ensure the confidentiality, integrity, reliability and availability of information.

[0064] Example 3:

[0065] Figure 3 A flowchart of another container abnormal behavior handling method provided by an embodiment of the present invention is shown below. Figure 3 As shown, the method includes:

[0066] Step 201: Obtain the container's behavior logs.

[0067] Specifically, the behavior logs of the container are obtained through log collection tools and log extraction commands.

[0068] In this embodiment of the invention, the logging system provides runtime status information for Docker containers and stores this runtime status information as logs. The runtime status information includes, but is not limited to, runtime information, file read / write records, and resource usage.

[0069] In this embodiment of the invention, the log collection tool is Fluentd, an open-source, general-purpose log collection and distribution system. Fluentd can collect behavioral log source data from multiple data sources and distribute the filtered and processed logs to various storage and processing systems. Specifically, the collection of behavioral log source data is achieved through the Fluentd tool.

[0070] In this embodiment of the invention, the Docker container provides various log extraction commands, including but not limited to the `logs` command, the `events` command, and the `history` command. The `logs` command prints the runtime logs of processes within the container; the `events` command prints real-time system events; and the `history` command prints the historical version information of a specified image, i.e., the command records for each layer of the image that was built. Specifically, the `logs` command extracts the runtime logs of each process within the container from the behavior log source data; the `events` command extracts the system event logs from the behavior log source data; and the `history` command extracts the historical version information of a specified image from the behavior log source data. Based on the runtime logs, system event logs, and the historical version information of the specified image, a behavior log is generated.

[0071] Furthermore, Docker's Cgroup component is used to obtain information such as container access requests and modification records to files and databases, and resource usage during container process execution. This information is then logged to obtain file read records and resource usage status. Together with Docker's runtime logs, system event logs, and historical version information of the specified image, this provides a basis for subsequent anomaly detection. Based on the runtime logs, system event logs, file read records, resource usage status, and historical version information of the specified image, a behavior log is generated, providing comprehensive evidence for subsequent anomaly detection.

[0072] As an alternative, behavior logs can be stored using a database based on distributed file storage (MongoDB) as the backend database.

[0073] Step 202: Perform anomaly detection on the obtained container behavior logs. If anomaly is detected, continue to step 203; if no anomaly is detected, the process ends.

[0074] In this embodiment of the invention, each step is executed by the container abnormal behavior processing device.

[0075] Specifically, an anomaly detection model is constructed to detect anomalies in behavior logs and obtain detection results, which include abnormal or normal behavior.

[0076] In this embodiment of the invention, the acquired sample logs are normalized and concatenated to obtain sample vectors. A deep learning model is then trained using these sample logs to obtain an anomaly detection model. Specifically, sample logs are acquired; these logs are behavioral samples of containers, including normal sample logs and abnormal sample logs. Normal sample logs carry normal labels, while abnormal sample logs carry abnormal labels. The sample logs are normalized to obtain normalized sample logs. The normalized sample logs are then concatenated to obtain sample vectors. These sample vectors are then input into a deep learning model for training, thus constructing the anomaly detection model. As an optional approach, normal sample logs include, but are not limited to, logs of reasonable requests, normal access, and reasonable resource usage. Abnormal sample logs include, but are not limited to, logs of improper access requests, frequent abnormal access, and excessive resource usage. For example, access requests such as accessing files restricted on the host machine or accessing read / write image layers of other containers are considered improper access requests; if a process's memory usage exceeds a certain threshold, it is considered to be using excessive resources.

[0077] Specifically, the behavior logs are input into the anomaly detection model. The anomaly detection model compares existing normal container behavior with abnormal container attack behavior, selects the abnormal fields, normalizes and concatenates the selected abnormal fields to obtain a feature vector, and classifies it through deep learning to determine whether there is abnormal behavior. If so, it outputs the detection result of abnormal container behavior, which includes abnormal behavior; if not, it outputs the detection result of normal container behavior, which includes normal behavior, and no further processing is performed.

[0078] As an optional approach, the specific abnormal fields selected include: comparing the value of the device field to determine if there are any records of devices accessing the device without permission; if so, the device field is an abnormal field; otherwise, the device field is a normal field; comparing the value of the cpuacct (central processing unit utilization) field to determine if there is any improper resource usage exceeding 90%; if so, the cpuacct field is an abnormal field; otherwise, the cpuacct field is a normal field; comparing the value of the memory field to determine if there are any improper out-of-bounds access records; if so, the memory field is an abnormal field; otherwise, the memory field is a normal field.

[0079] It's worth noting that the fields used for comparison are not limited to the aforementioned `device`, `cpuacct`, and `memory` fields. They can also include block device (`blkio`), CPU (`cpu`), CPU node (`cpuset`), freeze permission (`Freezer`), test (`perf_event`), and network (`net_cls`) fields. Specifically, the `blkio` field controls the input / output of block devices, such as hard drives and USB ports; the `cpu` field controls CPU usage; the `cpuset` field allocates specified CPU and memory nodes; the `cpuacct` field provides statistics on CPU resource usage; the `device` field controls device access permissions; the `memory` field sets memory usage limits and generates reports; the `Freezer` field allows suspending or resuming processes in a cgroup; the `perf_event` field allows the `perf` tool to perform unified performance testing based on cgroup groups; and the `net_cls` field limits network bandwidth.

[0080] Step 203: Generate corresponding decision results based on abnormal behavior by using the set abnormal decision-making strategy.

[0081] In this embodiment of the invention, the abnormal decision-making strategy is set according to actual needs, and this embodiment of the invention does not limit it.

[0082] As an optional approach, abnormal behavior includes improper access requests, and step 203 specifically includes:

[0083] Step 2031: Match the decision policies corresponding to improper access requests from the abnormal decision policies. The decision policies include stop access commands, permission judgment policies and file isolation judgment policies.

[0084] In this embodiment of the invention, corresponding to the abnormal behavior of improper access requests, the abnormal decision-making strategy can be configured with multiple decision strategies, including but not limited to a stop access command, a permission judgment strategy, and a file isolation judgment strategy. The stop access command rejects improper access requests to the container, while the permission judgment strategy and the file isolation strategy require further judgment processing based on the nature and behavior of the container.

[0085] It is worth noting that the decision-making strategy for improper access requests may also include other judgment strategies, which can be configured according to the actual situation. This embodiment of the invention does not limit this.

[0086] Step 2032: Use permission decision-making strategy and file isolation decision-making strategy to make a decision on abnormal behavior and obtain permission results and isolation results.

[0087] Specifically, the execution permissions of the container to which the abnormal behavior belongs are determined through a permission decision policy, resulting in the corresponding permission outcome. For example, it determines whether the execution permission of the container to which the abnormal behavior belongs is the Priority privilege. If the execution permission of the container to which the abnormal behavior belongs is the Priority privilege, the permission decision policy matches and determines the permission to disable the Priority privilege; if the execution permission of the container to which the abnormal behavior belongs is not the Priority privilege, no action is taken.

[0088] It is worth noting that the permission decision strategy can also have other decision conditions, and the embodiments of the present invention do not limit this.

[0089] Specifically, the file isolation decision strategy determines the file type corresponding to the abnormal behavior and obtains the corresponding isolation result. For example, taking an abnormal behavior that includes improper access requests as an example, it determines whether the file type of the file accessed by the improper access request includes the system kernel. If not, it indicates that the file type corresponding to the abnormal behavior does not include the system kernel, and the file isolation decision strategy determines an isolation result of no action. If yes, it indicates that the file type corresponding to the abnormal behavior includes the system kernel, and the file isolation decision strategy matches and determines whether the container is illegally mounted to the kernel folder. If yes, an isolation result of unmounting and isolating the kernel folder is generated; if no, an isolation result of no action is generated.

[0090] It is worth noting that the file isolation strategy can also have other decision conditions, which are not limited in this embodiment of the invention.

[0091] Step 2033: Generate decision results based on the stop access command, permission results, and isolation results.

[0092] It is worth noting that the decision result may also include other results, and the embodiments of the present invention do not limit this.

[0093] As an alternative solution, the abnormal behavior is frequent abnormal access, and step 203 specifically includes:

[0094] Step 3031: Match the decision strategies corresponding to frequent abnormal accesses from the abnormal decision strategies. The decision strategies include access frequency judgment strategy and access constraint judgment strategy.

[0095] In this embodiment of the invention, corresponding to the abnormal behavior of frequent abnormal access, the abnormal decision-making strategy can be configured with multiple decision strategies, including but not limited to the access frequency decision strategy and the access constraint decision strategy. The access frequency decision strategy and the access constraint decision strategy require further decision processing based on the nature and behavior of the container.

[0096] It is worth noting that the decision-making strategy for frequent abnormal accesses may also include other judgment strategies, which can be configured according to the actual situation. This embodiment of the invention does not limit this.

[0097] Step 3032: Use the access frequency decision strategy and the access constraint decision strategy to make a decision on abnormal behavior and obtain the frequency result and constraint result.

[0098] Specifically, the access frequency judgment strategy is used to judge the logs of abnormal behavior and obtain the frequency result. For example, it determines whether the time period of frequent access is within the pre-marked allowed frequent access time period. If so, no action is taken; otherwise, a frequency result is generated that denies the subsequent access requests of the process.

[0099] Specifically, access constraint decision strategies are used to evaluate logs of abnormal behavior and obtain constraint results. For example, based on the set constraint rules, the importance of the process and its corresponding upstream service are considered to determine whether the constraint rules are met. If yes, a frequency result for allowing access is generated; if not, a frequency result for denying access is generated. Here, the upstream service refers to the process that uses this process as its underlying service.

[0100] It is worth noting that the access frequency decision strategy, access constraint decision strategy, and constraint rules may also have other decision conditions, and the embodiments of the present invention do not limit this.

[0101] Step 3033: Generate decision results based on frequency results and constraint results.

[0102] It is worth noting that the decision result may also include other results, and the embodiments of the present invention do not limit this.

[0103] As an alternative solution, the abnormal behavior is excessive resource consumption. Step 203 specifically includes:

[0104] Step 4031: Match the decision strategy corresponding to excessive resource consumption from the abnormal decision strategies. The decision strategies include system resource judgment strategies.

[0105] In this embodiment of the invention, for abnormal behavior that consumes too many resources, the abnormal decision-making strategy can be configured with a variety of decision-making strategies, including but not limited to system resource judgment strategies, which need to be further judged based on the nature and behavior of the container.

[0106] It is worth noting that the decision-making strategy corresponding to excessive resource consumption may also include other judgment strategies, which can be configured according to the actual situation. This embodiment of the invention does not limit this.

[0107] Step 4032: Use the system resource decision-making strategy to make a decision on abnormal behavior and obtain the resource result.

[0108] Specifically, the system resource judgment strategy is used to judge the logs of abnormal behavior and obtain resource results. For example, the system checks the current CPU and memory usage. If the usage is greater than or equal to a usage threshold, it indicates a risk of a Denial of Service (DOS) attack, and a resource result is generated to reject subsequent process creation requests. If the usage is less than the usage threshold, no action is taken. The usage threshold can be set according to actual needs, and this embodiment of the invention does not limit it.

[0109] Furthermore, the necessity of the created processes is determined, and unnecessary processes are shut down. If the number of unnecessary processes created by a container exceeds a set threshold, the container is either closed or deleted. This threshold can be set according to actual needs, and this embodiment of the invention does not impose any limitations on it.

[0110] It is worth noting that the system resource decision-making strategy may also have other decision-making conditions, and the embodiments of the present invention do not limit this.

[0111] Step 4033: Generate decision results based on resource results.

[0112] It is worth noting that the decision result may also include other results, such as closing or deleting the container, but this embodiment of the invention does not limit this.

[0113] As an alternative, the abnormal behavior involves accessing a shared data volume. Specifically, when analysis of the logs reveals a file access request targeting a file within a shared data volume, the security levels of the requesting container and the data volume container are read and compared. When the two containers are at different security levels, the container with the higher security level can read files from the shared data volume. This allows the higher-security-level container to distribute data downwards; conversely, the lower-security-level container cannot write to files in the higher-security-level container, and vice versa. This helps protect the data in the higher-security-level container from tampering and avoids inconsistencies in its data distribution.

[0114] As an alternative approach, the abnormal behavior involves frequent file creation. Specifically, when analysis of the logs reveals that a container has created a large number of files within a short period, the file sizes are scanned. If a large number of empty files are created, it is determined to be an innode attack. Subsequent file creation requests from that container are stopped, and all empty files are deleted to free up innode folder space. If the files are not empty, it is analyzed whether the container actually needs to create these files, and a decision is made based on the actual situation to whether to restrict subsequent file creation requests from that container.

[0115] Step 204: Perform exception handling on the container based on the decision results.

[0116] In this embodiment of the invention, the decision results include, but are not limited to, Docker commands and business processing results. Docker commands include, but are not limited to, stop access (stop) commands, kill (kill) commands, or delete (rm) commands. Business processing results include, but are not limited to, permission results, isolation results, frequency results, constraint results, and resource results.

[0117] Specifically, exception handling includes executing corresponding Docker commands, task control based on Cgroups, priority allocation, resource statistics, and resource limits; and setting file or directory access permissions based on the Linux Security Modules (LSM) access control framework: the register_security() function is used to register the corresponding security module with the LSM, and access control operations can be performed after the module is successfully loaded.

[0118] In this embodiment of the invention, for containers exhibiting destructive anomalies, such as those containing malicious attack programs that persist despite repeated access control configurations, a deletion command is executed. For resource-intensive containers, such as those exhibiting frequent abnormal access, excessive resource consumption, and frequent file creation, a kill command is executed. For containers with general abnormal access, such as those exhibiting improper access requests and access to shared data volumes, a stop command is executed.

[0119] As an optional approach, the decision results include a stop access command, a permission result, and an isolation result. The permission result is to disable priority privileges, and the isolation result is to unmount and isolate the kernel folder. Specifically, in response to the stop access command, the container's access requests are stopped; in response to the permission result, the container's priority privileges are disabled; and in response to the isolation result, the mount between the container and the kernel folder is unmounted, and the kernel folder is isolated.

[0120] This invention addresses existing security issues with Docker, thereby improving system isolation and security. The invention employs a container security architecture design that records, analyzes, and makes corresponding decisions and actions regarding Docker behavior. When a container malfunctions, it may negatively impact the system through improper access requests, frequent database access, or excessive resource consumption. Recording and analyzing various Docker behaviors facilitates early detection and timely handling of anomalies, ensuring normal system operation and improving system isolation and security.

[0121] In the technical solution of the container abnormal behavior handling method provided in this embodiment of the invention, abnormal detection is performed on the acquired container behavior logs; if abnormal behavior is detected, a corresponding decision result is generated based on the abnormal behavior through the set abnormal decision strategy; and abnormal handling is performed on the container based on the decision result. This method can perform abnormal analysis from the container behavior, improve the accuracy of security protection, and thus ensure the confidentiality, integrity, reliability and availability of information.

[0122] Example 4

[0123] Figure 4 This is a schematic diagram of a container abnormal behavior handling device provided in an embodiment of the present invention. This device is used to execute the aforementioned container abnormal behavior handling method, such as... Figure 4 As shown, the device includes: a log system unit 11, an anomaly detection unit 12, an anomaly decision unit 13, and an anomaly processing unit 14.

[0124] The logging system unit 11 is used to send the container's behavior logs to the anomaly detection unit.

[0125] The anomaly detection unit 12 is used to perform anomaly detection on the behavior log of the container; if an abnormal behavior is detected, the abnormal behavior is sent to the anomaly decision unit.

[0126] The abnormal decision unit 13 is used to generate corresponding decision results based on abnormal behavior according to the set abnormal decision strategy, and send the decision results to the abnormal processing unit.

[0127] The exception handling unit 14 is used to handle exceptions to the container based on the decision results.

[0128] In this embodiment of the invention, the device further includes an acquisition unit 15.

[0129] The acquisition unit 15 is used to acquire the container's behavior logs through log collection tools and log extraction commands.

[0130] In this embodiment of the invention, the anomaly detection unit 12 is specifically used to perform anomaly detection on the behavior log through the constructed anomaly detection model, and obtain the detection result, which includes abnormal behavior or normal behavior.

[0131] In this embodiment of the invention, the log extraction command includes at least one of a running log command, an event command, and a history command; the acquisition unit 15 is specifically used to collect behavioral log source data through a log collection tool; extract the running logs of each process in the container from the behavioral log source data through the running log command; extract the system event logs from the behavioral log source data through the event command; extract the historical version information of a specified image from the behavioral log source data through the history command; and generate a behavioral log based on the running logs, system event logs, and the historical version information of the specified image.

[0132] In this embodiment of the invention, the device further includes a splicing unit 16 and a training unit 17.

[0133] The splicing unit 16 is used to normalize and splice the acquired sample logs to obtain a sample vector. The sample logs include normal sample logs carrying normal labels and abnormal sample logs carrying abnormal labels.

[0134] Training unit 17 is used to train the deep learning model using sample logs to obtain an anomaly detection model.

[0135] In this embodiment of the invention, the abnormal behavior includes improper access requests; the abnormal decision unit 13 is specifically used to match the decision strategy corresponding to the improper access request from the abnormal decision strategy, the decision strategy includes a stop access command, a permission judgment strategy and a file isolation judgment strategy; the abnormal behavior is judged by the permission judgment strategy and the file isolation judgment strategy to obtain the permission result and the isolation result; and a decision result is generated based on the stop access command, the permission result and the isolation result.

[0136] In this embodiment of the invention, the anomaly decision unit 13 is specifically used to determine the running permissions of the container to which the abnormal behavior belongs through a permission decision strategy, and obtain the corresponding permission result; and to determine the file type corresponding to the abnormal behavior through a file isolation decision strategy, and obtain the corresponding isolation result.

[0137] In this embodiment of the invention, the anomaly decision unit 13 is specifically used to match the permission result of disabling the priority privilege by means of the permission judgment strategy if the running permission of the container to which the abnormal behavior belongs is a priority privilege.

[0138] In this embodiment of the invention, the anomaly decision unit 13 is specifically used to determine whether the container is illegally mounted to the kernel folder if the file type corresponding to the abnormal behavior includes the system kernel, through the file isolation judgment strategy; if so, generate an isolation result of unmounting and isolating the kernel folder.

[0139] In this embodiment of the invention, the decision result includes a stop access command, a permission result, and an isolation result. The permission result is to disable priority privileges, and the isolation result is to unmount and isolate the kernel folder. The exception handling unit 14 is specifically used to stop the container's access request in response to the stop access command; disable the container's priority privileges in response to the permission result; and unmount the container from the kernel folder and isolate the kernel folder in response to the isolation result.

[0140] In the solution of this invention embodiment, anomaly detection is performed on the acquired container behavior logs; if abnormal behavior is detected, a corresponding decision result is generated based on the abnormal behavior through the set anomaly decision strategy; the container is anomaly handled according to the decision result, which can perform anomaly analysis from the container behavior, improve the accuracy of security protection, and thus ensure the confidentiality, integrity, reliability and availability of information.

[0141] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer device, specifically, a computer device can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0142] Example 5

[0143] This invention provides a computer device, including a memory and a processor. The memory is used to store information including program instructions, and the processor is used to control the execution of the program instructions. When the program instructions are loaded and executed by the processor, they implement the steps of the above-described container abnormal behavior handling method. For a detailed description, please refer to the above-described container abnormal behavior handling method embodiments.

[0144] The following is for reference. Figure 5 It shows a schematic diagram of the structure of a computer device 600 suitable for implementing the embodiments of this application.

[0145] like Figure 5As shown, the computer device 600 includes a central processing unit (CPU) 601, which can perform various appropriate tasks and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the computer device 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0146] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal feedback (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed in storage section 608 as needed.

[0147] Example 6

[0148] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program including program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611.

[0149] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0150] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0151] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0152] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0153] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0154] It should also be noted that 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 limitation, 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.

[0155] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0156] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0157] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0158] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0159] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A method for handling abnormal behavior of a container, characterized in that, The method includes: Anomaly detection is performed on the acquired container behavior logs, which are generated based on runtime logs, system event logs, file read records, resource usage status, and historical version information of the specified image. If abnormal behavior is detected, a corresponding decision result is generated based on the abnormal behavior according to the set abnormal decision-making strategy, specifically including: If the abnormal behavior is an improper access request, a decision strategy corresponding to the improper access request is matched from the abnormal decision strategy. The decision strategy includes a stop access command, a permission judgment strategy, and a file isolation judgment strategy. The abnormal behavior is judged by the permission judgment strategy and the file isolation judgment strategy to obtain permission results and isolation results. A decision result is generated based on the stop access command, permission results, and isolation results. If the abnormal behavior is due to excessive resource consumption, the decision strategy corresponding to excessive resource consumption is matched from the abnormal decision strategies. The decision strategy includes the system resource judgment strategy. The abnormal behavior is judged by the system resource judgment strategy to obtain the resource result. Based on the resource result, a decision result is generated. If the abnormal behavior is accessing a shared data volume, read and compare the security levels of the access request container and the data volume container. When the two containers are at different security levels, the higher-level container can read files in the shared data volume; the lower-level container cannot write files to the higher-level container, and the higher-level container can write files to the lower-level container. If the abnormal behavior involves frequent file creation, the file size is scanned. If a large number of empty files are created, it is determined to be a node attack. Subsequent file creation requests for the container are stopped, and all empty files are deleted to free up node folder space. If the files are not empty, it is analyzed whether the container actually needs to create these files, and a decision is made on whether to restrict subsequent file creation requests for the container. The container is handled abnormally based on the decision results. The decision results include Docker commands and business processing results. The Docker commands include stop access commands, kill commands, or delete commands. The business processing results include permission results, isolation results, frequency results, constraint results, and resource results. The anomaly detection of the acquired container behavior logs includes: Anomaly detection is performed on the behavior logs using the constructed anomaly detection model to obtain detection results. The detection results include abnormal behavior or normal behavior, specifically including: The behavior logs are input into the anomaly detection model. The anomaly detection model compares existing normal container behavior with abnormal container attack behavior, selects the abnormal fields, normalizes and concatenates the selected abnormal fields to obtain feature vectors, and classifies them through deep learning to determine whether there is abnormal behavior. If so, it outputs the detection result of abnormal container behavior; if not, it outputs the detection result of normal container behavior.

2. The container abnormal behavior handling method according to claim 1, characterized in that, Before performing anomaly detection on the acquired container behavior logs, the following is also included: Obtain the container's behavior logs using log collection tools and log extraction commands.

3. The container abnormal behavior handling method according to claim 2, characterized in that, The log extraction command includes at least one of the following: a run log command, an event command, and a history command; The process of obtaining container behavior logs through log collection tools and log extraction commands includes: Collect behavioral log source data using log collection tools; The runtime logs of each process in the container are extracted from the behavior log source data using the runtime log command. The system event log is extracted from the behavior log source data using the event command; The historical version information of the specified image can be extracted from the behavior log source data using the historical commands. The behavior log is generated based on the running log, system event log, and historical version information of the specified image.

4. The container abnormal behavior handling method according to claim 1, characterized in that, Before performing anomaly detection on the behavior log using the constructed anomaly detection model to obtain detection results, and before the detection results include abnormal behavior or normal behavior, the following steps are also included: The acquired sample logs are normalized and concatenated to obtain a sample vector. The sample logs include normal sample logs carrying normal labels and abnormal sample logs carrying abnormal labels. The deep learning model is trained using the sample logs to obtain an anomaly detection model.

5. The container abnormal behavior handling method according to claim 1, characterized in that, The process of judging the abnormal behavior through the permission judgment strategy and the file isolation judgment strategy to obtain permission results and isolation results includes: The permission decision strategy is used to determine the running permissions of the container to which the abnormal behavior belongs, and the corresponding permission result is obtained. The file isolation decision strategy is used to determine the file type corresponding to the abnormal behavior and obtain the corresponding isolation result.

6. The container abnormal behavior handling method according to claim 5, characterized in that, The step of determining the execution permissions of the container to which the abnormal behavior belongs through the permission determination strategy, and obtaining the corresponding permission result, includes: If the container to which the abnormal behavior belongs has priority privileges, the permission decision policy is used to match and determine the permission result to disable the priority privileges.

7. The container abnormal behavior handling method according to claim 5, characterized in that, The step of using the file isolation decision strategy to determine the file type corresponding to the abnormal behavior and obtain the corresponding isolation result includes: If the file type corresponding to the abnormal behavior includes the system kernel, the file isolation judgment policy is used to determine whether the container is illegally mounted to the kernel folder; If so, generate the isolation result of unmounting and isolating the kernel folder.

8. The container abnormal behavior handling method according to claim 1, characterized in that, The decision results include a stop access command, permission results, and isolation results. The permission results are to disable priority privileges, and the isolation results are to unmount and isolate the kernel folder. The step of handling the container's anomalies based on the decision result includes: In response to the stop access command, the access request of the container is stopped; in response to the permission result, the priority privilege of the container is disabled; in response to the isolation result, the mount between the container and the kernel folder is removed, and the kernel folder is isolated.

9. A container abnormal behavior handling device, characterized in that, The device includes: a log system unit, an anomaly detection unit, an anomaly decision-making unit, and an anomaly processing unit; The logging system unit is used to send the container's behavior logs to the anomaly detection unit; The anomaly detection unit is used to detect anomalies in the container's behavior logs; if an anomaly is detected, the anomaly is sent to the anomaly decision unit. The behavior logs are generated based on the running logs, system event logs, file read records, resource usage status, and historical version information of the specified image. The abnormal decision unit is used to generate corresponding decision results based on abnormal behavior according to the set abnormal decision strategy, and send the decision results to the abnormal processing unit; The exception handling unit is used to perform exception handling on the container according to the decision result. The decision result includes Docker commands and business processing results. The Docker commands include stop access commands, kill commands, or delete commands. The business processing results include permission results, isolation results, frequency results, constraint results, and resource results. The anomaly detection unit is specifically used to perform anomaly detection on the behavior log through the constructed anomaly detection model, and obtain the detection result, which includes abnormal behavior or normal behavior. The anomaly detection unit is specifically used to input behavior logs into the anomaly detection model. The anomaly detection model compares existing normal container behavior with abnormal container attack behavior, selects abnormal fields, normalizes and concatenates the selected abnormal fields to obtain feature vectors, classifies them through deep learning, and determines whether there is abnormal behavior. If so, it outputs the detection result of abnormal container behavior; if not, it outputs the detection result of normal container behavior. The anomaly decision unit is specifically used to match the decision strategy corresponding to the improper access request from the anomaly decision strategy if the abnormal behavior is an improper access request. The decision strategy includes a stop access command, a permission judgment strategy, and a file isolation judgment strategy. The abnormal behavior is judged by the permission judgment strategy and the file isolation judgment strategy to obtain permission results and isolation results. A decision result is generated based on the stop access command, permission results, and isolation results. If the abnormal behavior is due to excessive resource consumption, the decision strategy corresponding to excessive resource consumption is matched from the abnormal decision strategies. The decision strategy includes the system resource judgment strategy. The abnormal behavior is judged by the system resource judgment strategy to obtain the resource result. Based on the resource result, a decision result is generated. If the abnormal behavior is accessing a shared data volume, read and compare the security levels of the access request container and the data volume container. When the two containers are at different security levels, the higher-level container can read files in the shared data volume; the lower-level container cannot write files to the higher-level container, and the higher-level container can write files to the lower-level container. If the abnormal behavior involves frequent file creation, the file size is scanned. If a large number of empty files are created, it is determined to be a node attack. Subsequent file creation requests for the container are stopped, and all empty files are deleted to free up node folder space. If the files are not empty, it is analyzed whether the container actually needs to create these files, and a decision is made on whether to restrict subsequent file creation requests for the container.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the container abnormal behavior handling method as described in any one of claims 1 to 8.

11. A computer device comprising a memory and a processor, the memory for storing information including program instructions, and the processor for controlling the execution of the program instructions, characterized in that, When the program instructions are loaded and executed by the processor, they implement the container abnormal behavior handling method according to any one of claims 1 to 8.

12. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the container abnormal behavior handling method according to any one of claims 1 to 8.

Images