Container escape detection method and device

Abstract

The invention discloses a container escape detection method and device. The method comprises the steps that an eBPF program is configured in a kernel space of a Linux system according to a preset hook; the method comprises the following steps: acquiring system call related information at a preset hook through an eBPF program, forming an attack script and an attack description of a Linux system by using an atomic attack tool provided by an Atomic Red Team test library, and generating a sensitive file list about the attack of the Linux system based on the attack script, the attack description and a cue word by using a large language model; based on the system calling related information and the sensitive file list, container escape detection is carried out according to a container escape detection rule comprising a sensitive file detection rule and a command execution detection rule, and a detection result is obtained; and judging whether a container escape behavior exists or not according to a detection result. According to the method, container escape detection which is wide in coverage, comprehensive in method, excellent in detection accuracy and false alarm rate, efficient and real-time can be achieved.

Description

Technical Field

[0001] The present invention belongs to the field of computer cloud security technology, and specifically relates to a container escape detection method and device. Background Art

[0002] In recent years, with the rapid development of cloud-native technology, Docker container technology has become an important technical cornerstone in the cloud-native environment. Docker provides a new type of virtualization sandbox technology, which enables massive containers to be started in a host to achieve lightweight and isolated services. Compared with traditional virtual machine technology, containers under container technology share an operating system kernel with the host, but are isolated from the host in the namespace of the Linux system. Therefore, container technology also has the characteristics of lightweight and high performance. They enable organizations to expand and develop software solutions in the cloud-native era, allowing developers to focus on writing applications without worrying about dependencies or complex software settings.

[0003] However, although container technology has high efficiency, it also faces more severe security issues. Containers are designed to run untrusted code safely. In order to constrain such untrusted code, containers use kernel isolation and kernel security mechanisms to prevent application vulnerabilities from affecting the container host. For example, if a web server running in a container has a remote code execution (RCE) vulnerability, the vulnerability can only execute code in the container, but not on the host.

[0004] However, due to the current incompleteness of isolation technology, there are some high-severity vulnerabilities that can undermine the isolation and security mechanisms that constrain containers, and attackers may exploit these vulnerabilities to access the host. These attacks directly affect the confidentiality, integrity, and availability of the underlying infrastructure that hosts the container, allowing attackers to use some vulnerabilities to allow the container to break through the isolation restrictions of the host, allowing attackers to execute code on the host from inside the container, and then use the container as a springboard to control the entire host or even directly control an entire cluster. Obviously, once these attacks are successful, they will cause great damage to the entire cluster ecosystem and even directly cause huge losses to many Internet cloud tenants. In response to these vulnerabilities, attacks that artificially allow containers to break through the original isolation restrictions are usually called container escape attacks.

[0005] The existing container escape detection methods, in the industrial and commercial aspects, extract whitelists and blacklists by analyzing the container process system call set and the escape behavior system call set, convert the whitelist and blacklist system calls into system call filtering rules, filter the system call events based on the preprocessed system call filtering rules, and trigger alarms for dangerous system calls; there are also methods to collect the system call behavior of normal containers, and then input them into the model for learning, and then obtain a model that can judge container escapes, and then input the collected container behavior system calls into the model to achieve the purpose of container escape detection. However, in practice, it is found that the false alarm rate of the detection method based only on the whitelist is very high, and the method based on machine learning will also have the problem of significant performance degradation as the environment changes. Secondly, there is also a way to simply use the process working path to determine whether the container has escaped. If the process working path is not the container path, then it is considered that the container escape behavior has occurred. However, for escaped containers that break the container isolation mechanism, it is easy to modify host files and execute code in the container environment, such as the mounting vulnerabilities that have emerged in recent years. Therefore, this method of simply judging the working path also has a small coverage, is not comprehensive enough, and has a low detection rate.

[0006] In the academic field, the method proposed by Michael et al. can limit the behavior of the container by setting the user ID when the container is started, but it is only applicable to containers started by non-super users, and there are still many vulnerabilities that can bypass this solution, which is not general enough for the current environment; although the method proposed by Mashal et al. takes into account the interaction between the container and the host, it does not take into account some normal interactive behaviors and has a high false alarm rate; and the method proposed by Guo et al. roughly limits a system call whitelist for each started container, which is similar to the baseline method described above and has the problems of excessive overhead, extreme cumbersomeness and high false alarm rate.

[0007] Due to the complexity of container escape behavior, the diversity of components involved (involving various container engine components, or various system configurations and system kernels), and the diversity and complexity of the means used by attackers to launch attacks, there is currently no container escape detection solution that can achieve wide coverage, comprehensive methods, excellent detection accuracy and false alarm rate, and high efficiency and real-time. The reason is also due to the complexity of container escape itself. At present, many methods can only focus on some surface behaviors of containers related to container escape, but do not explore the deeper characteristics of container escape. Summary of the invention

[0008] In view of the above, the purpose of the present invention is to provide a container escape detection method and device. According to the principle of container escape itself, by digging out more common characteristics of various runtime container escape vulnerabilities, a container escape detection rule with wider detection coverage and better effect is proposed to detect container escape. The detection performance has an extremely high detection rate and an extremely low false alarm rate, which enables the cloud native environment to develop more safely in the era of the explosion of the number of containers.

[0009] In order to achieve the above-mentioned invention object, the technical solution provided by the present invention is as follows:

[0010] A container escape detection method provided by an embodiment of the present invention comprises the following steps:

[0011] An eBPF program for collecting system call related information in container escape detection is configured in the kernel space of the Linux system according to the preset hook;

[0012] The eBPF program is used to collect information at the preset hook to obtain relevant information about system calls. The atomic attack tool provided by the AtomicRed Team test library is used to form an attack script and attack description for the Linux system. The large language model is used to generate a list of sensitive files related to Linux system attacks based on the attack script, attack description and prompt words.

[0013] Based on the obtained system call related information and sensitive file list, container escape detection is performed according to preset container escape detection rules including sensitive file detection rules and command execution detection rules to obtain detection results;

[0014] Based on the detection results, determine whether there is a container escape behavior. If it is determined that there is a container escape behavior, the process information and file information related to this container escape behavior are packaged and written into the local log and uploaded to the server.

[0015] Preferably, configuring an eBPF program for collecting system call related information in container escape detection in the kernel space of the Linux system according to a preset hook includes:

[0016] Find and locate the eBPF program used to collect system call related information in container escape detection;

[0017] The eBPF program is called and loaded into a specified hook in the kernel space of the Linux system, wherein the hook includes a mount-related hook, a process-related hook, and a file-related hook.

[0018] Preferably, the collecting of information at a preset hook by the eBPF program to obtain the system call related information includes:

[0019] In the current operating system, the preset system calls are monitored by the eBPF program, and the system call related information is collected at the preset hook through the eBPF program, wherein the system call related information includes process related information, file operation related information and directory mounting related information.

[0020] Preferably, the attack script and attack description of the Linux system composed of the atomic attack tool provided by the Atomic Red Team test library include:

[0021] Collect all atomic attack operations and attack scripts about Linux system attacks from the Atomic Red Team test library, combine the attack scripts into attack links and write attack descriptions.

[0022] Preferably, the method of using a large language model to generate a list of sensitive files related to Linux system attacks based on attack scripts, attack descriptions and prompt words includes:

[0023] The attack script and attack description are input into the large language model, and the large language model is guided by customized prompt words to analyze the attack script and attack description and specify the result return format and output content. The list of sensitive files about Linux system attacks generated by the large language model includes potential files on the Linux host that will be further exploited by the attacker to generate attacks.

[0024] Preferably, the sensitive file detection rules include:

[0025] According to the directory mount related information in the system call related information, determine whether the current file operation is an operation within the host or within the container. If it is an operation within the host, the current file operation is considered safe. If it is an operation within the container, further determine whether the current file operation is a write operation; if it is not a write operation, the current file operation is considered safe. If it is a write operation, obtain the process information of the current file operation; determine whether the process of the current file operation is a trusted process. If it is a trusted process, the current file operation is considered safe. If it is an untrusted process, match the files accessed by the current process with the sensitive file list. If the match is successful, it is determined that a container escape has occurred and a container escape alarm is issued.

[0026] Preferably, the command execution detection rules include:

[0027] According to the process-related information and file operation-related information in the system call-related information, the processes and files involved in the host reading files in the container and the container reading and writing files in the host are marked as suspicious processes and suspicious files, and a suspicious process file library is built; according to the directory mounting-related information in the system call-related information, it is determined whether the current process is a process in the host or a process in the container. If it is a process in the host, the current process is considered safe. If it is a process in the container, it is determined whether the current process in the container or its parent process has abnormal behavior. If a command unrelated to the container runtime component is executed, it is considered that abnormal behavior has occurred. The process and file corresponding to the current abnormal behavior are matched with the suspicious process file library. If the match is successful, it is determined that a container escape has occurred and a container escape alarm is issued.

[0028] To achieve the above-mentioned purpose of the invention, an embodiment of the present invention further provides a container escape detection device, which is implemented by the above-mentioned container escape detection method, and includes: a configuration unit, a collection unit, a detection unit, a judgment unit and a processing unit;

[0029] The configuration unit is used to configure an eBPF program for collecting system call related information in container escape detection in the kernel space of the Linux system according to a preset hook;

[0030] The collection unit is used to collect information at a preset hook through an eBPF program to obtain system call related information, use the atomic attack tool provided by the Atomic Red Team test library to form an attack script and attack description of the Linux system, and use a large language model to generate a sensitive file list about the Linux system attack based on the attack script, attack description and prompt words;

[0031] The detection unit is used to perform container escape detection based on the obtained system call related information and sensitive file list according to preset container escape detection rules including sensitive file detection rules and command execution detection rules to obtain a detection result;

[0032] The judging unit is used to judge whether there is a container escape behavior according to the detection result;

[0033] The processing unit is used to package and process process information and file information related to the container escape behavior, write them into a local log, and upload them to the server if it is determined that there is a container escape behavior.

[0034] Preferably, the configuration unit comprises: a positioning subunit and a loading subunit;

[0035] The positioning subunit is used to find and locate the eBPF program used to collect system call related information in container escape detection;

[0036] The loading subunit is used to call the eBPF program and load the eBPF program into a specified hook in the kernel space of the Linux system, wherein the hook includes a mount-related hook, a process-related hook, and a file-related hook.

[0037] Preferably, the detection unit comprises: a container sensing subunit, a sensitive file detection subunit, a suspicious file process marking subunit and an abnormal behavior detection subunit;

[0038] The container perception subunit is used to determine whether the current process or file operation is a process or file operation within the container based on the directory mount related information in the system call related information, and if so, fill in and update the path of the process or the path of the file operation;

[0039] The sensitive file detection subunit is used to further determine whether the current file operation determined as an operation within the container is a write operation; if it is not a write operation, the current file operation is considered safe; if it is a write operation, the process information of the current file operation is obtained; determine whether the process of the current file operation is a trusted process; if it is a trusted process, the current file operation is considered safe; if it is an untrusted process, the file accessed by the current process is matched with the sensitive file list; if the match is successful, it is determined that a container escape behavior has occurred and a container escape alarm is issued;

[0040] The suspicious file process marking subunit is used to mark the processes and files involved in the host reading files in the container and the container reading and writing files in the host as suspicious processes and suspicious files according to the process related information and file operation related information in the system call related information, and to build a suspicious process file library;

[0041] The abnormal behavior detection subunit is used to further determine whether the current process or its parent process has abnormal behavior for the current process determined to be a process within the container. If a command unrelated to the container runtime component is executed, it is considered that abnormal behavior has occurred. The process and file corresponding to the current abnormal behavior are matched with the suspicious process file library. If the match is successful, it is determined that a container escape behavior has occurred and a container escape alarm is issued.

[0042] Compared with the prior art, the present invention has the following beneficial effects:

[0043] The present invention has comprehensively and systematically studied the popular container escape vulnerabilities, extracted features and classified different container escape behaviors according to their respective attack methods, and performed container escape detection by executing sensitive file detection rules and command execution detection rules in parallel, making breakthroughs and progress in the detection of container escapes, making up for the deficiencies of traditional existing detection devices in container escape detection capabilities, and being able to detect container escape attacks more comprehensively. It has a very high detection rate and a very low false alarm rate in detection performance, and has higher comprehensiveness and detection performance than other existing methods. Through further research on container escape behaviors, the present invention further ensures the security and reliability of containers at runtime, enhances the control of threats within cloud native clusters, and ensures the security of cloud native clusters. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0045] Figure 1 is an overall flow chart of a container escape detection method provided by an embodiment of the present invention;

[0046] Figure 2 is a detailed flow chart of a container escape detection method provided by an embodiment of the present invention;

[0047] Figure 3 is a flow chart of executing container escape detection rules to perform container escape detection provided by an embodiment of the present invention;

[0048] Figure 4 is a flow chart of executing sensitive file detection rules provided by an embodiment of the present invention;

[0049] Figure 5 is a flow chart of an execution command execution detection rule provided by an embodiment of the present invention;

[0050] Figure 6 It is a structural schematic diagram of a container escape detection device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0051] To make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific implementation methods described herein are only used to explain the present invention and do not limit the scope of protection of the present invention.

[0052] The inventive concept of the present invention is: in view of the problems in the prior art that the container escape detection method has small coverage, is not comprehensive enough, has low detection accuracy and high false alarm rate, and is cumbersome and time-consuming, the embodiment of the present invention provides a container escape detection method and device, which collects system call related information and builds a sensitive file list, and performs container escape detection according to preset container escape detection rules. It can accurately and efficiently detect container escape behavior in real time based on the principle characteristics of container escape, so that users can discover and locate container escape targets more comprehensively, accurately and quickly, and ensure the runtime security of containers in a cloud-native container environment.

[0053] Figure 1 is an overall flow chart of a container escape detection method provided by an embodiment of the present invention. Figure 2 Detailed flow chart of a container escape detection method provided by an embodiment of the present invention. Figure 1 and Figure 2 As shown, the embodiment provides a container escape detection method, comprising the following steps:

[0054] S1, configures an eBPF program in the kernel space of the Linux system according to a preset hook to collect system call related information in container escape detection.

[0055] Specifically, the eBPF program used to collect system call related information in container escape detection is searched and located, the eBPF program is called and loaded into the specified hook in the kernel space of the Linux system, and then the relevant system call information is obtained at the hook. Among them, the hook includes mount-related hooks, process-related hooks, and file-related hooks.

[0056] In the embodiment, for some preset system call hooks, these hook contents are written to determine the system call kernel parameters that each hook needs to collect, and these hooks at least include: tp / sys_enter_chdir, tp / sys_enter_execve, lsm / file_open, lsm / file_create, lsm / file_rename, lsm / file_link, lsm / file_unlink, etc. The kernel parameters that each hook needs to collect are shown in Table 1 below.

[0057] Table 1 System information fields collected by hooks

[0058]

[0059]

[0060] In the embodiment, compilers such as clang and llvm are used to complete the conversion of eBPF source code to bytecode, the eBPF bytecode file just compiled is located in the user space program, and the API provided by the libbpf library is used to complete the bytecode injection of the eBPF program into the kernel space at a preset hook to achieve the loading of the eBPF program. All kinds of system call information collected by the eBPF program in the kernel space will be transmitted to the user space by means of bpf ringbuf.

[0061] S2, collects information about system calls through the eBPF program at the preset hook, uses the atomic attack tool provided by the Atomic Red Team test library to form an attack script and attack description for the Linux system, and uses the large language model to generate a list of sensitive files related to Linux system attacks based on the attack script, attack description and prompt words.

[0062] Specifically, on the one hand, the preset system calls are monitored by the eBPF program in the current operating system, and the system call related information is collected at the preset hook through the eBPF program, wherein the system call related information includes process related information, file operation related information and directory mount related information. On the other hand, all atomic attack operations and attack scripts related to Linux system attacks are collected from the Atomic Red Team, the attack scripts are combined into attack links and attack descriptions are written, the attack scripts and attack descriptions are input into the large language model, and the large language model is guided by prompts to analyze the attack scripts and attack descriptions and to specify the result return format and output content. The list of sensitive files about Linux system attacks generated by the large language model includes potential files on the Linux host that will be further used by the attacker to generate attacks.

[0063] In the embodiment, the API officially provided by the large language model GPT4 is used. By inputting the Linux atomic attack tool provided by the Atomic Red Team team, organizing it and forming an attack link, a comprehensive attack script for Linux container escape can be obtained, and the attack description is written through these scripts to obtain an original input. The script and attack description of the Linux container escape attack are used as the standard input of GPT4, and some prompt words are added as the basis for GPT4 analysis and determine the format of the output content. The analysis prompt word example is as follows:

[0064] (1) Files whose reading could lead to attackers obtaining important system-related information, thereby launching further attacks, such as / etc / passwd and / etc / shadow;

[0065] (2) Configuration files that, if overwritten, could indirectly cause the system to execute unintended commands, which attackers might exploit for attacks, such as / etc / crontab.

[0066] (3) Output the analysis results in Json format.

[0067] This process can produce a comprehensive, reliable, and representative list of sensitive files that are highly relevant to container escape attacks.

[0068] S3, based on the obtained system call related information and sensitive file list, perform container escape detection according to preset container escape detection rules including sensitive file detection rules and command execution detection rules to obtain a detection result.

[0069] Specifically, based on the obtained system call related information and sensitive file list, a judgment is made on whether a container escape has occurred in this system call according to the preset container escape detection rules to obtain the detection result. Figure 3 The flowchart shown is a flowchart of executing container escape detection rules to perform container escape detection. The container escape detection rules include: sensitive file detection rules and command execution detection rules.

[0070] It should be noted that the container escape detection method of the present invention has a container perception function. Since the container technology itself is isolated in many namespaces, and the chdir system call is used for the process in the container to change the root directory of the container process, many data collection tools are currently affected by the isolation of the namespace and cannot obtain the complete working path of the process in the container or the directory where the file is located. The present invention can determine whether the current namespace belongs to the container or the host from the mount-related hook information captured by the eBPF program, and obtain the directory path of the container on the host based on the information of the chdir system call, and form the complete working path of the process in the container and the directory where the file is located by splicing, which has a container perception function.

[0071] In the embodiment, the present invention has found through sufficient investigation and research that container escape attack angles are diverse and can be roughly divided into three types: (1) escape due to misconfiguration of configuration files, (2) escape caused by Linux kernel vulnerabilities, and (3) escape caused by container runtime vulnerabilities. The vulnerability surface that can be exploited by container escape attacks is very wide, but after studying a large number of examples, it can be found that although the attack surface of container escape is very diverse and the vulnerabilities exploited are endless, the attack point launched after the container escape is traceable. Most attack samples will read or overwrite some sensitive files on the host as a container when using misconfiguration to implement escape attacks. The sensitive file detection rule uses this as the detection basis to check whether the container has the behavior of overwriting some sensitive files of the host, and issue a container escape alarm for such behavior. In the actual environment, in order to provide its own business services, the container also needs to interact with the host to a certain extent. However, this interaction is limited to the container runtime components and will not involve sensitive files on the Linux host. Therefore, the sensitive file library ensures that this method will not falsely report container escapes for normal container runtime components and ensures a high detection rate.

[0072] like Figure 4 The flowchart shown is the process of executing sensitive file detection rules, including:

[0073] (1) Based on the nodename variable in the directory mount related information in the system call related information, that is, the node space where the current process is located, it is determined whether the current file operation is an operation within the host or within the container. If it is an operation within the host, the current file operation is considered safe;

[0074] (2) If it is an operation within the container, the current file operation is further determined to be a write operation. If it is not a write operation, the current file operation is considered safe.

[0075] (3) If it is a write operation, obtain the process information of the current file operation;

[0076] (4) Determine whether the process of the current file operation is a trusted process. If it is a trusted process, the current file operation is considered safe. Trusted processes can be determined and added by the user to filter out some user-defined privileged processes;

[0077] (5) If it is an untrusted process, the file accessed by the current process is matched to see if it belongs to the sensitive file list. If it does, it is determined that a container escape has occurred and a container escape alarm is issued.

[0078] In a cloud-native environment, the purpose of container technology is to separate sandbox applications from the host so as to better develop its own business services. Therefore, a normal container should not access and rewrite some important sensitive files on the host, because these sensitive files can directly or indirectly cause the host to crash or behave abnormally, allowing attackers to launch further attacks.

[0079] In the embodiment, based on the vulnerability attack research of a large number of escape attacks in advance, the present invention also found that the container escape behavior itself is bound to be accompanied by cross-layer abnormal behavior between the host and the container. For example, CVE-2019-5736, that is, because the container obtained the file handle of the container engine component runc on the host, and then modified and overwrote the host file in the container space, which eventually led to the escape attack. Another example is CVE-2019-14271, that is, because the host mistakenly loaded the dangerous file in the container space, which led to the escape. The original intention of the sandbox technology is to prevent possible interactions between the host and the container by establishing a command space and a new root directory, so the restriction and monitoring of the interaction between the host and the container is the top priority. Based on this discovery, the present invention proposes command execution detection rules, including the following two major criteria: monitoring all behaviors of the host reading files in the container, and monitoring all behaviors of the container reading and writing host files. For the processes and files involved in the above-mentioned behaviors, the present invention will mark them as suspicious, because these processes and files are likely to have become part of the container escape attack.

[0080] like Figure 5 The flowchart shown is the execution command execution detection rule, including:

[0081] (1) Based on the process-related information and file operation-related information in the system call-related information, the processes and files involved in the host reading files in the container (performing host execution container file detection) and the container reading and writing files in the host (performing container write host file detection) are marked as suspicious processes and suspicious files, and a suspicious process file library is constructed;

[0082] (2) Based on the nodename variable in the directory mount related information in the system call related information, determine whether the current process is a process in the host or a process in the container. If it is a process in the host, the current process is considered safe;

[0083] (3) If it is a process in the container, determine whether the current process or its parent process in the container has abnormal behavior. If a command unrelated to the container runtime component is executed, it is considered that abnormal behavior has occurred (execution process abnormal behavior detection);

[0084] (4) The process and file corresponding to the current abnormal behavior are matched to see whether they belong to the processes and files in the suspicious process file library. If they match, it is determined that a container escape has occurred and a container escape alarm is issued.

[0085] S4: Determine whether there is a container escape behavior based on the detection results. If it is determined that there is a container escape behavior, package the process information and file information related to this container escape behavior, write it into the local log, and upload it to the server.

[0086] Specifically, according to the detection results, if a container escape occurs, the relevant process and file information of this escape event will be sorted and packaged, written into the log, and the alarm will be sent to the server for user operation. The user space program packages the local log and sends it to the server every time an event occurs.

[0087] The container escape detection method provided in the above embodiment also includes: minimizing the storage and fast searching of sensitive files, and fast storing and searching of suspicious processes and files based on Bloom filters, so as to achieve more real-time and efficient container escape detection.

[0088] In summary, the container escape detection method provided by the embodiment of the present invention targets the principle characteristics of container escape, and performs accurate and efficient real-time container escape detection by executing sensitive file detection rules and command execution detection rules in parallel, which makes up for the deficiencies of traditional existing detection devices in container escape detection capabilities, and can detect container escape attacks more comprehensively. It has an extremely high detection rate and an extremely low false alarm rate in detection performance, and has higher comprehensiveness and detection performance than other existing methods, so that users can promptly and quickly discover and locate container escape targets, and ensure the runtime security of containers in a cloud-native container environment.

[0089] Based on the same inventive concept, Figure 6 As shown, the embodiment of the present invention further provides a container escape detection device 600 , including: a configuration unit 610 , a collection unit 620 , a detection unit 630 , a judgment unit 640 and a processing unit 650 .

[0090] The configuration unit 610 is used to configure an eBPF program for collecting system call related information in container escape detection in the kernel space of the Linux system according to a preset hook.

[0091] The collection unit 620 is used to collect information at a preset hook through the eBPF program to obtain system call related information, use the atomic attack tool provided by the Atomic Red Team test library to form an attack script and attack description of the Linux system, and use the large language model to generate a sensitive file list about the Linux system attack based on the attack script, attack description and prompt words.

[0092] The detection unit 630 is used to perform container escape detection based on the obtained system call related information and sensitive file list and according to preset container escape detection rules including sensitive file detection rules and command execution detection rules to obtain a detection result.

[0093] The judging unit 640 is used to judge whether there is any container escape behavior according to the detection result.

[0094] The processing unit 650 is used to package the process information and file information related to the container escape behavior, write them into the local log, and upload them to the server if it is determined that the container escape behavior exists.

[0095] The configuration unit 610 includes: a positioning subunit 611 and a loading subunit 612;

[0096] The positioning subunit is used to find and locate the eBPF program used to collect system call related information in container escape detection;

[0097] The loading subunit 612 is used to call the eBPF program and load the eBPF program into a specified hook in the kernel space of the Linux system, wherein the hook includes a mount-related hook, a process-related hook, and a file-related hook.

[0098] The detection unit 630 includes: a container sensing subunit 631, a sensitive file detection subunit 632, a suspicious file process marking subunit 633 and an abnormal behavior detection subunit 634;

[0099] The container perception subunit 631 is used to determine whether the current process or file operation is a process or file operation in the container according to the directory mounting related information in the system call related information, and if so, fill in and update the path of the process or the path of the file operation;

[0100] The sensitive file detection subunit 632 is used to further determine whether the current file operation determined as an operation within the container is a write operation; if it is not a write operation, the current file operation is considered safe; if it is a write operation, the process information of the current file operation is obtained; determine whether the process of the current file operation is a trusted process; if it is a trusted process, the current file operation is considered safe; if it is an untrusted process, the file accessed by the current process is matched with the sensitive file list; if the match is successful, it is determined that a container escape behavior has occurred and a container escape alarm is issued;

[0101] The suspicious file process marking subunit 633 is used to mark the processes and files involved in the host reading files in the container and the container reading and writing files in the host as suspicious processes and suspicious files according to the process related information and file operation related information in the system call related information, and to build a suspicious process file library;

[0102] The abnormal behavior detection subunit 634 is used to further determine whether the current process or its parent process has abnormal behavior for the current process determined to be a process within the container. If a command unrelated to the container runtime component is executed, it is considered that abnormal behavior has occurred. The process and file corresponding to the current abnormal behavior are matched with the suspicious process file library. If the match is successful, it is determined that a container escape has occurred and a container escape alarm is issued.

[0103] It should be noted that the container escape detection device provided in the above embodiment and the container escape detection method belong to the same inventive concept, and the specific implementation process thereof is detailed in the embodiment of the container escape detection method, which will not be repeated here.

[0104] The specific implementation methods described above provide a detailed description of the technical solutions and beneficial effects of the present invention. It should be understood that the above is only the most preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, supplements and equivalent substitutions made within the scope of the principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A container escape detection method, characterized in that: The following steps are involved: An eBPF program for collecting system call related information in container escape detection is configured in the kernel space of the Linux system according to the preset hook; The eBPF program is used to collect information at the preset hook to obtain the relevant information of the system call. The atomic attack tool provided by the Atomic RedTeam test library is used to form the attack script and attack description of the Linux system. The large language model is used to generate a list of sensitive files related to the Linux system attack based on the attack script, attack description and prompt words. Based on the obtained system call related information and sensitive file list, container escape detection is performed according to preset container escape detection rules including sensitive file detection rules and command execution detection rules to obtain detection results; Based on the detection results, determine whether there is a container escape behavior. If it is determined that there is a container escape behavior, the process information and file information related to this container escape behavior are packaged and written into the local log and uploaded to the server.

2. The container escape detection method according to claim 1, characterized in that: The eBPF program for collecting system call related information in container escape detection is configured in the kernel space of the Linux system according to the preset hook, including: Find and locate the eBPF program used to collect system call related information in container escape detection; The eBPF program is called and loaded into a specified hook in the kernel space of the Linux system, wherein the hook includes a mount-related hook, a process-related hook, and a file-related hook.

3. The container escape detection method according to claim 1, characterized in that: The information collected by the eBPF program at the preset hook to obtain the system call related information includes: In the current operating system, the preset system calls are monitored by the eBPF program, and the system call related information is collected at the preset hook through the eBPF program, wherein the system call related information includes process related information, file operation related information and directory mounting related information.

4. The container escape detection method according to claim 1, characterized in that: The attack script and attack instructions for the Linux system are composed of the atomic attack tools provided by the Atomic Red Team test library, including: Collect all atomic attack operations and attack scripts about Linux system attacks from the Atomic Red Team test library, combine the attack scripts into attack links and write attack descriptions.

5. The container escape detection method according to claim 1, characterized in that: The method of using a large language model to generate a list of sensitive files related to Linux system attacks based on attack scripts, attack descriptions, and prompt words includes: The attack script and attack description are input into the large language model, and the large language model is guided by customized prompt words to analyze the attack script and attack description and specify the result return format and output content. The list of sensitive files about Linux system attacks generated by the large language model includes potential files on the Linux host that will be further exploited by the attacker to generate attacks.

6. The container escape detection method according to claim 3, characterized in that: Sensitive file detection rules include: According to the directory mount related information in the system call related information, determine whether the current file operation is an operation within the host or within the container. If it is an operation within the host, the current file operation is considered safe. If it is an operation within the container, further determine whether the current file operation is a write operation; if it is not a write operation, the current file operation is considered safe. If it is a write operation, obtain the process information of the current file operation; determine whether the process of the current file operation is a trusted process. If it is a trusted process, the current file operation is considered safe. If it is an untrusted process, match the files accessed by the current process with the sensitive file list. If the match is successful, it is determined that a container escape has occurred and a container escape alarm is issued.

7. The container escape detection method according to claim 3, characterized in that: Command execution detection rules include: According to the process-related information and file operation-related information in the system call-related information, the processes and files involved in the host reading files in the container and the container reading and writing files in the host are marked as suspicious processes and suspicious files, and a suspicious process file library is built; according to the directory mounting-related information in the system call-related information, it is determined whether the current process is a process in the host or a process in the container. If it is a process in the host, the current process is considered safe. If it is a process in the container, it is determined whether the current process in the container or its parent process has abnormal behavior. If a command unrelated to the container runtime component is executed, it is considered that abnormal behavior has occurred. The process and file corresponding to the current abnormal behavior are matched with the suspicious process file library. If the match is successful, it is determined that a container escape has occurred and a container escape alarm is issued.

8. A container escape detection device, implemented by the container escape detection method according to any one of claims 1 to 7, characterized in that: include: Configuration unit, collection unit, detection unit, judgment unit and processing unit; The configuration unit is used to configure an eBPF program for collecting system call related information in container escape detection in the kernel space of the Linux system according to a preset hook; The collection unit is used to collect information at a preset hook through an eBPF program to obtain system call related information, use the atomic attack tool provided by the Atomic Red Team test library to form an attack script and attack description of the Linux system, and use a large language model to generate a sensitive file list about the Linux system attack based on the attack script, attack description and prompt words; The detection unit is used to perform container escape detection based on the obtained system call related information and sensitive file list according to preset container escape detection rules including sensitive file detection rules and command execution detection rules to obtain a detection result; The judging unit is used to judge whether there is a container escape behavior according to the detection result; The processing unit is used to package and process process information and file information related to the container escape behavior, write them into a local log, and upload them to the server if it is determined that there is a container escape behavior.

9. The container escape detection device according to claim 8, characterized in that: The configuration unit includes: a positioning subunit and a loading subunit; The positioning subunit is used to find and locate the eBPF program used to collect system call related information in container escape detection; The loading subunit is used to call the eBPF program and load the eBPF program into a specified hook in the kernel space of the Linux system, wherein the hook includes a mount-related hook, a process-related hook, and a file-related hook.

10. The container escape detection device according to claim 8, characterized in that: The detection unit includes: a container sensing subunit, a sensitive file detection subunit, a suspicious file process marking subunit and an abnormal behavior detection subunit; The container perception subunit is used to determine whether the current process or file operation is a process or file operation within the container based on the directory mount related information in the system call related information, and if so, fill in and update the path of the process or the path of the file operation; The sensitive file detection subunit is used to further determine whether the current file operation determined as an operation within the container is a write operation; if it is not a write operation, the current file operation is considered safe; if it is a write operation, the process information of the current file operation is obtained; determine whether the process of the current file operation is a trusted process; if it is a trusted process, the current file operation is considered safe; if it is an untrusted process, the file accessed by the current process is matched with the sensitive file list; if the match is successful, it is determined that a container escape behavior has occurred and a container escape alarm is issued; The suspicious file process marking subunit is used to mark the processes and files involved in the host reading files in the container and the container reading and writing files in the host as suspicious processes and suspicious files according to the process related information and file operation related information in the system call related information, and to build a suspicious process file library; The abnormal behavior detection subunit is used to further determine whether the current process or its parent process has abnormal behavior for the current process determined to be a process within the container. If a command unrelated to the container runtime component is executed, it is considered that abnormal behavior has occurred. The process and file corresponding to the current abnormal behavior are matched with the suspicious process file library. If the match is successful, it is determined that a container escape behavior has occurred and a container escape alarm is issued.

Images