Container safety protection method, device, equipment and medium

Abstract

The invention relates to the technical field of safety protection, in particular to a container safety protection method, device and equipment and a medium. According to the method and the device, the eBPF probe is deployed on the operating system kernel where the container is located, the system call required for operating the container is monitored on the operating system kernel through the eBPF probe, and then the system call is filtered, so that the predetermined call with lower risk is filtered out, and only the risk call with higher risk degree is protected; therefore, safety protection of container operation is realized. From the above analysis, the method does not monitor all system calls related to the container, but only monitors risk calls and does not monitor low-risk system calls, so that more resources can be saved to ensure the performance of the container, and the low-risk system calls hardly threaten the operation of the container, so that the method is more efficient. Therefore, low-risk system calling is filtered out, risk calling is monitored, safe operation of the container can be guaranteed, and the computing power and operation stability of the container can be considered.

Description

Technical Field

[0001] This invention relates to the field of safety protection technology, specifically to a container safety protection method, device, equipment, and medium. Background Technology

[0002] Deploying containers on a device and running applications within them, with containers isolated from each other, requires monitoring for attacks on containers during application execution to ensure secure operation. Current technologies monitor all container-related system calls throughout the process to ensure application security. However, this constant monitoring consumes significant system resources, leaving fewer resources available for containers and impacting their computing power and operational stability—essentially reducing container performance.

[0003] In summary, existing security technologies reduce container performance.

[0004] Therefore, existing technologies still need to be improved and enhanced. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a container safety protection method, apparatus, equipment, and medium, which solves the problem that existing safety protection technologies reduce container performance.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a container safety protection method, comprising: Identify system calls related to the container and monitor these system calls using an eBPF probe deployed on the operating system kernel; The system calls are filtered to remove predetermined calls and obtain risky calls, wherein the predetermined calls are system calls with a security risk less than a threshold. Security protection is provided for the risky calls to ensure the safe operation of the container.

[0007] In one implementation, determining the system calls associated with the container includes: obtaining a set of system calls associated with the container; Obtain the execution latency of each call in the system call set; Based on the execution latency corresponding to each call, the system calls corresponding to the container are selected from the system call set.

[0008] In one implementation, based on the execution latency corresponding to each call, the system calls corresponding to the container are filtered from the system call set, including: Obtain the latency threshold; The system call set is filtered to select calls whose execution latency is greater than or equal to the latency threshold, and these calls are designated as the system calls corresponding to the container.

[0009] In one implementation, the system calls associated with the container are determined, including: Obtain the set of system calls associated with the container; Obtain the frequency corresponding to each call in the system call set; Based on the frequency of each call, the system calls corresponding to the container are selected from the system call set.

[0010] In one implementation, the system calls are filtered to remove predetermined calls and obtain risky calls, including...

[0011] Determine the call corresponding to the whitelisted container set in the predetermined call, wherein the security risk corresponding to each container in the whitelisted container set is greater than a threshold; The system calls are filtered, and only the calls corresponding to the whitelist container set are retained to obtain the risk calls corresponding to the risk containers.

[0012] In one implementation, security protection is provided for the risky calls to achieve security protection for the operation of the container, including: Collect data related to the risky call, and obtain process behavior based on the data; Security protection is provided for the process behavior to achieve security protection for the operation of the container.

[0013] In one implementation, security protection is provided for the process behavior to achieve security protection for the operation of the container, including: Based on the process policy library and process context, security protection is provided for the process behavior to achieve security protection for the operation of the container. The process policy library is used to record the rules corresponding to the safe operation of the container.

[0014] In one implementation, security protection for the process behavior is provided based on a process policy library and process context, including: Collect the utilization rate of the processor where the operating system kernel is located; Based on the occupancy rate, the activation of protection instructions is determined, and the process behavior is protected by activating the protection instructions. The protection instructions include protection instructions based on the process policy library and protection instructions based on the process context.

[0015] In one implementation, determining the activation of the protection command based on the occupancy rate includes: When the occupancy rate is less than or equal to the set rate value, protection instructions based on the process policy library and protection instructions based on the process context are activated simultaneously.

[0016] In one implementation, determining the activation of the protection command based on the occupancy rate further includes: When the occupancy rate is greater than the set rate value, protection instructions based on the process policy library are initiated, while protection instructions based on the process context are terminated.

[0017] In one implementation, initiating protection instructions based on the process policy library includes: The microsecond-level protection instructions in the protection instructions based on the process policy library are determined. The microsecond-level protection instructions are used to characterize the security protection detection instructions that the operating system can complete within microseconds. The microsecond-level protection command is initiated.

[0018] In one implementation, security protection is provided for the risky call, which further includes: When an abnormal call is detected during the security protection process, the return value of the risky call is modified.

[0019] In one implementation, modifying the return value of the risk call includes: The return value of the risky call is placed in a per-CPU circular cache, and the return value of the risky call is modified within the per-CPU circular cache.

[0020] In one implementation, security protection is provided for the risky call, which further includes: When an abnormal call is detected during the security protection process, the process behavior caused by the risky call is terminated.

[0021] In one implementation, security protection is provided for the risky call, which further includes: When an abnormal call is detected during the security protection process, the logs generated by the abnormal call are checked. Based on the logs, optimize the security protection strategy.

[0022] In one implementation, based on the logs, the security protection strategy is optimized, including: Extract the topic model from the logs; Based on the aforementioned topic model, the attack pattern is obtained; Based on the attack pattern described, a security protection strategy is derived. Determine the false alarm rate and false negative rate corresponding to the security protection strategy; Based on the false alarm rate and the false negative rate, the security protection strategy is optimized.

[0023] In one implementation, the container runs on an OpenHarmony device.

[0024] Secondly, embodiments of the present invention also provide a container safety protection device, wherein the device comprises the following components: The system call monitoring module is used to determine system calls related to containers and monitor these system calls through eBPF probes deployed on the operating system kernel. The filtering module is used to filter the system calls to filter out predetermined calls and obtain risky calls, wherein the predetermined calls are system calls with a security risk of less than a threshold. The protection module is used to provide security protection for the risky calls, so as to achieve security protection for the operation of the container.

[0025] In one implementation, the system call monitoring module includes: The first data acquisition unit is used to acquire the system call set related to the container; A latency acquisition unit is used to acquire the execution latency of each call in the system call set; The first filtering unit is used to filter out the system calls corresponding to the container from the system call set based on the execution latency corresponding to each call.

[0026] In one implementation, the filtering unit includes: Threshold setting component, used to obtain latency threshold; A filtering component is used to filter out calls whose execution latency is less than the latency threshold from the system call set, and to designate the call as the system call corresponding to the container.

[0027] In one implementation, the system call monitoring module includes: The second data acquisition unit is used to acquire the system call set related to the container; A frequency acquisition unit is used to acquire the frequency corresponding to each call in the system call set; The second filtering unit is used to filter out the system calls corresponding to the container from the system call set based on the frequency of each call.

[0028] In one implementation, the filtering module includes: The whitelist matching unit is used to determine the call corresponding to the whitelist container set in the predetermined call, wherein the security risk corresponding to each container in the whitelist container set is less than a threshold. The filtering unit is used to filter the system calls to filter out the calls corresponding to the whitelist container set and obtain the risk calls corresponding to the risk containers.

[0029] In one implementation, the protection module includes: The process monitoring unit is used to collect data related to the risky call and to obtain process behavior based on the data. The protection unit is used to perform security protection on the process behavior based on the process policy library and process context, so as to realize the security protection of the container operation. The process policy library is used to record the rules corresponding to the safe operation of the container.

[0030] In one implementation, the protection unit includes: The utilization rate statistics component is used to collect the utilization rate of the processor where the operating system kernel is located; A protection instruction activation component is used to determine the activation of protection instructions based on the occupancy rate, and to perform security protection on the process behavior by activating the protection instructions. The protection instructions include protection instructions based on the process policy library and protection instructions based on the process context.

[0031] One implementation also includes: The modification module is used to modify the return value of the risky call when an abnormal call is detected during the security protection process.

[0032] In one implementation, the modification module includes: A buffer modification unit is used to place the return value of the risky call in a per-CPU circular buffer and modify the return value of the risky call within the per-CPU circular buffer.

[0033] One implementation also includes: The termination module is used to terminate the process behavior caused by the risky call when an abnormal call is detected during the security protection process.

[0034] One implementation also includes: The detection module is used to detect the logs generated by the abnormal call when an abnormal call is detected during the security protection process; The optimization module is used to optimize security protection strategies based on the logs.

[0035] In one implementation, the optimization module includes: A topic extraction unit is used to extract topic models from the logs; An attack pattern analysis unit is used to obtain attack patterns based on the topic model. The strategy analysis unit is used to obtain a security protection strategy based on the attack pattern. The false alarm and false alarm statistics unit is used to determine the false alarm rate and false alarm rate corresponding to the security protection strategy. The strategy optimization unit is used to optimize the security protection strategy based on the false alarm rate and the false negative rate.

[0036] Thirdly, embodiments of the present invention also provide a terminal device, wherein the terminal device includes a memory, a processor, and a container security protection program stored in the memory and executable on the processor, wherein when the processor executes the container security protection program, it implements the steps of the container security protection method described above.

[0037] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a container security protection program, which, when executed by a processor, implements the steps of the container security protection method described above.

[0038] Beneficial Effects: This invention deploys an eBPF probe on the operating system kernel where the container resides. The eBPF probe monitors the system calls required for container operation on the operating system kernel, and then filters these system calls, filtering out low-risk pre-defined calls and protecting only high-risk calls, thereby achieving security protection for container operation. As the above analysis shows, this invention does not monitor all container-related system calls, but only high-risk calls, ignoring low-risk ones. This saves more resources for ensuring container performance. Furthermore, since low-risk system calls pose almost no threat to container operation, this invention filters out low-risk system calls while monitoring high-risk calls, ensuring both secure container operation and balancing container computing power and operational stability. Attached Figure Description

[0039] Figure 1 This is an overall flowchart of the present invention; Figure 2 This is a schematic diagram of an adaptive kernel-level intrusion blocking system based on eBPF in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the first method for filtering system calls in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the second method for filtering system calls in an embodiment of the present invention; Figure 5 This is a flowchart illustrating the security protection measures in an embodiment of the present invention; Figure 6A structural diagram of the container safety protection device provided by the present invention; Figure 7 This is a block diagram illustrating the internal structure of a terminal device provided in an embodiment of the present invention. Detailed Implementation

[0040] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments and accompanying drawings. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0041] Research has found that deploying containers on a device, running applications within containers, and isolating these containers from each other are crucial for ensuring secure application operation. During application execution, it's necessary to monitor containers for attacks to guarantee application security. Current technology monitors all container-related system calls throughout the entire process to ensure application security. However, this constant monitoring consumes significant system resources, leaving fewer resources available for containers. This negatively impacts container computing power and operational stability, ultimately reducing container performance.

[0042] To address the aforementioned technical problems, this invention provides a container safety protection method, apparatus, equipment, and medium, which solves the problem that existing safety protection technologies reduce container performance.

[0043] The container security protection method of this embodiment can be applied to terminal devices, which can be terminal products with data processing capabilities, such as computers. In this embodiment, as... Figure 1 As shown, the container safety protection method specifically includes the following steps: S100, Identify system calls related to the container, and monitor the system calls through an eBPF probe deployed on the operating system kernel; S200, the system calls are filtered to remove predetermined calls and obtain risky calls, wherein the predetermined calls are system calls with a security risk less than a threshold; S300 provides security protection for the risky calls to achieve security protection for the operation of the container.

[0044] The security protection method in this embodiment can be used to prevent PLC containers deployed on OpenHarmony from being attacked. PLC is a programmable logic controller, which ensures that the PLC container can obtain exclusive resources on OpenHarmony and avoids the PLC container being preempted by other processes, thereby ensuring the real-time performance and reliability of the control commands of the PLC container.

[0045] The security protection method in this embodiment can also be used to prevent malicious attacks on containers deployed on traffic monitoring equipment. Traffic monitoring equipment includes traffic lights and environmental monitors. When an application within a container on a traffic monitoring device is attacked, it can defend against malicious container escape attacks targeting the MQTT communication link.

[0046] The determination of container-related system calls in step S100 includes two methods: the first method is to filter container-related system calls based on the execution latency of the calls, and the second method is to filter container-related system calls based on the call frequency.

[0047] Among them, such as Figure 3 As shown, the first method includes the following specific steps S101a, S102a, S103a, and S104a: S101a, Obtain the set of system calls associated with the container; S102a, Obtain the execution delay of each call in the system call set; S103a, Obtain the latency threshold; S104a, Select calls from the system call set whose execution latency is greater than or equal to the latency threshold, and use these calls as the system calls corresponding to the container.

[0048] Steps S101a, S102a, S103a, and S104a are as follows: Figure 2 The eBPF probe layer shown monitors network traffic and process lifecycles generated by running containers at the kernel level. Furthermore, it monitors network traffic and process lifecycles dynamically by inserting a monitoring program without modifying the kernel code. By monitoring containers at the kernel level through eBPF probes, the monitoring container is completely isolated from the monitored container, preventing the monitoring container from becoming a target for attacks on the monitored container. This complete isolation ensures the security of the monitored container.

[0049] use This represents the collection of system calls related to the container, which is captured by the following event capture function. Initially remove calls corresponding to low execution latency (using) (Representing calls with low execution latency), filtering out the system calls that need to be monitored, that is, from the system call set. Remove from The remaining calls are those that may pose security risks and require monitoring; these are all the system calls that have been initially screened and need to be monitored. It constitutes a set .

[0050] Event capturing function: .

[0051] In the formula, This indicates a low-latency call. The set constituted Representative call The corresponding execution latency, execution latency refers to the time delay of the call. The time elapsed from initiation (or entering kernel mode) to completion (or exiting kernel mode).

[0052] This represents the set delay threshold, in this embodiment... The value is 50 Based on event capturing functions, from the system call set Filter out execution delay Less than the delay threshold The corresponding call, execution latency The corresponding calls are all high-frequency and harmless calls, which means they do not require monitoring.

[0053] Capture execution latency Less than the delay threshold The corresponding call has the following technical effects: If the single execution delay of the call If the interval is extremely short, it means the call is performed frequently. Frequent calls will accumulate and consume a lot of CPU time, so capturing the execution latency is crucial. Extremely short call, filtering out execution latency Extremely short calls can reduce the pressure on subsequent monitoring. Furthermore, execution latency is low. Extremely short calls are often harmless, such as memory allocation, which has low execution latency. Extremely short calls are harmless calls.

[0054] The eBPF probe runs in the kernel, and frequent triggering can create additional resource overhead. Setting it to 50... The upper limit can ensure monitoring accuracy while avoiding probing all system calls, thus ensuring that the eBPF probe can better detect the system calls that need to be detected.

[0055] like Figure 4 As shown, the second method described above includes the following specific steps S101b, S102b, and S103b: S101b, Obtain the set of system calls associated with the container.

[0056] S102b, Obtain the frequency corresponding to each call in the system call set.

[0057] S103b, Based on the frequency corresponding to each call, filter out the system calls corresponding to the container from the system call set.

[0058] This embodiment filters out the system calls corresponding to the container from the system call set based on the frequency of the same call caused by container operation, that is, it filters out the system calls that need to be monitored. This embodiment selects the less frequent system calls as the system calls that need to be monitored. Frequent calls accumulate and consume a lot of CPU time, so capturing the more frequent calls helps to discover the CPU performance bottleneck of the OpenHarmony device where the container is located. eBPF has very low overhead for intercepting high-frequency calls and can continue to run without affecting business operations.

[0059] Steps S101b, S102b, and S103b are also in the same manner. Figure 2 The eBPF probe layer shown is implemented on the kernel, allowing the eBPF probe layer to detect all system calls related to the container in real time on the kernel.

[0060] The filtering of system calls in step S200 to filter out predetermined calls and obtain risky calls includes the following specific steps: filtering the system calls and retaining only the calls corresponding to the whitelist container set to obtain the risky calls corresponding to the risky containers.

[0061] This embodiment uses the following probe filtering model to select the set from the initial screening above. Remove containers that are not in the whitelist container set. The calls corresponding to the remaining containers after filtering are the final filtered risk calls, which are the system calls that actually need to be monitored.

[0062] The probe filtering model is as follows:

[0063] In the formula, Represents system call The container to which it belongs Represents a whitelist of containers, when the container Located in the whitelist container collection Inside, the container is monitored via an eBPF probe. The system call.

[0064] The whitelisted containers include busy-me, busybox, nginx, and redis, with busy-me representing the example container name.

[0065] The probe filtering model works as follows: It utilizes eBPF to mount tracepoints and associates them with container contexts via cgroup IDs; a pre-defined whitelist bypasses high-frequency, harmless calls (accounting for 63% of all syscalls), reducing event delivery load by 70%. Specifically, the compiled eBPF bytecode is loaded into the kernel and attached to the syscall tracepoint. When any process initiates a system call, the eBPF program is executed, obtaining the current process's cgroup ID, determining if it belongs to a container that needs monitoring, and checking if the syscall ID is on the whitelist. If not, the event is discarded. For syscalls on the whitelist, the cgroup ID is collected, and the container engine (such as Docker) is queried based on the cgroup ID to obtain the container name, ID, and other context information for security analysis, audit log storage, or real-time alerts.

[0066] eBPF resides on the kernel, filtering at the kernel level to avoid a large number of unnecessary and related [data / processes]. By filtering out secure system calls and containers not on the whitelist, the number of containers that need to be monitored and their corresponding system calls can be reduced, thereby achieving precise monitoring. In other words, the main resources are concentrated on monitoring containers with relatively high security risks and their corresponding system calls.

[0067] Using cgroup IDs allows for more reliable container association, while tracepoints can be used to avoid compatibility issues caused by kernel function changes.

[0068] The system uses a whitelist as a benchmark to determine whether a container is a high-risk container. If it is, the system calls of that container are monitored to ensure the safe operation of the container's application.

[0069] The whitelist in this embodiment can be dynamically updated, that is, the containers in the whitelist are dynamically updated, and then based on the dynamically updated whitelist, it is determined which containers have security risks and need to be monitored. In other words, this embodiment dynamically adjusts the monitored containers.

[0070] This embodiment first removes system calls with low execution latency through an event capture function, and then applies a probe filtering model to the container to which each system call belongs in order to further remove system calls belonging to containers in the whitelist set. The risky calls that need to be monitored are obtained through the event capture function and the probe filtering model.

[0071] Event capturing functions are:

[0072] The probe filtering model is as follows: .

[0073] This embodiment first filters system calls through an event capture function, and then filters the containers to which the system calls belong through a probe filtering model, achieving the following technical effects: After the eBPF probe captures a system call, it calculates the execution latency of that system call. Only when satisfied Only calls that are explicitly flagged will be retained, meaning they are more likely to become objects of subsequent monitoring. Such calls are initially considered to be calls that may be due to performance anomalies.

[0074] By using event capture functions, a large number of short-latency, frequently used system calls that are usually harmless can be directly discarded. Directly discarding system calls means that there is no need to continuously monitor whether system calls are harmful. Discarding a large number of harmless system calls first can reduce the processing burden of subsequent probe filtering models, thereby improving the efficiency of filtering out the final harmful or dangerous calls.

[0075] For system calls that have been filtered and retained by the event capture function, further examine the container context to which these system calls belong. If the container context indicates that the container is in the whitelist set... If the container is inside, then it will be filtered out because of the whitelist set. All containers within the system are harmless and do not require monitoring. Only containers not on the whitelist are reported to the monitoring system. This further eliminates calls from containers on the trusted whitelist, thereby reducing system resources consumed by monitoring system calls and saving more system resources. This allows resource-constrained devices to dedicate more resources to running applications within containers.

[0076] Steps S100 and S200 are used to filter out risky calls that need to be monitored. Risky calls are calls that pose potential dangers. Security protection is provided for these risky calls to monitor whether they are abnormal.

[0077] like Figure 5 As shown, the security protection for the risky call in step S300 includes the following specific steps S301, S302, and S303: S301, Collect data related to the risk call, and obtain process behavior based on the data.

[0078] like Figure 2As shown, process behavior is monitored on the eBPF probe layer, which hooks system calls in kernel mode to capture the name, parameters, return value, timestamp, and process ID of system calls in real time. System calls are aggregated based on their name, parameters, return value, timestamp, and process ID to form process behavior. Aggregation means combining multiple system calls with the same name, parameters, return value, timestamp, and process ID into one system call, and then monitoring the trajectory of this system call to form process behavior.

[0079] S302, collect the utilization rate of the processor where the operating system kernel is located.

[0080] This embodiment does not monitor process behavior in real time at the expense of system resources. Instead, it monitors process behavior only when there are remaining system resources to ensure that the system load can operate normally. In this embodiment, system resources refer to CPU processor utilization, or CPU occupancy. When CPU occupancy is high, the intensity of process behavior detection is appropriately reduced to alleviate the CPU burden. Conversely, when CPU occupancy is low, the intensity of process behavior detection is appropriately increased to improve detection accuracy.

[0081] S303, based on the occupancy rate, determine the activation of the protection instruction, and perform security protection on the process behavior by activating the protection instruction. The protection instruction includes protection instructions based on the process policy library and protection instructions based on the process context.

[0082] In other words, dynamic load adjustment is based on the CPU's dynamic load control instructions.

[0083] In the formula, Represents CPU utilization. This represents the total CPU space, which includes both used and unused space. Represents a lightweight rule set, which is... Figure 2 The strategy matches the YAML strategy. This represents the complete rule set, which includes YAML policies and process state machines, where the process state machine is used to analyze process lineage. This represents the selected protection commands. The YAML strategy resides on the rule matching layer, which uses efficient Trie tree keywords to match whether process behavior is abnormal. The process state machine resides on the context association layer, identifying whether there are abnormal behavior chains within the process, including reverse shells.

[0084] when In other words, when CPU utilization is greater than 70%, only processes based on the policy library (process policy library is...) are started. Figure 2 Protection directives based on YAML rules are terminated, while protection directives based on process context are terminated. The process policy library, or lightweight rule set, determines whether a container's system calls are abnormal based solely on the lightweight rule set.

[0085] when Even if only the protection instructions based on the process policy library are activated, it is only the microsecond-level protection instructions of the process policy library that are activated. The microsecond-level protection instructions are the security protection and detection instructions that the operating system can complete within microseconds. In this embodiment, the microsecond-level protection instructions are protection instructions based on string matching.

[0086] Protection instructions based on process policy libraries, that is, judging whether process behavior conforms to predetermined rules based on a pre-defined set of policy rules, in order to determine whether process behavior is abnormal.

[0087] In other words, the degree to which process behavior conforms to the policy rule set is calculated based on the following policy matching function. If the degree of conformity to the policy rule set is low, it indicates that there is a risk of abnormal process behavior; otherwise, there is no risk of abnormality.

[0088] Strategy matching function:

[0089] In the formula, Representative strategy rule set, This represents the features extracted from process behavior. The total number of rules in the strategy rule set. This represents the matching function.

[0090] when In other words, when the CPU utilization is less than or 70%, both process policy library-based protection instructions and process context-based protection instructions are activated. Activating process context-based protection instructions means activating the aforementioned process state machine to analyze process lineage.

[0091] Process lineage analysis is used to analyze the relationship chains between processes to detect the source of an attack and to discover more covert attack chains. However, detecting more covert attack chains requires more computing resources. Therefore, the process lineage analysis protection command is only activated when the CPU utilization is low (meaning that the CPU still has more computing resources available).

[0092] In summary, dynamic load balancing compiles YAML policies into executable rules, switches detection intensity based on system load, performs string matching (microsecond-level response) only when CPU utilization is >70%, and enables process lineage analysis when the load is low; and generates blocking instructions after a rule is hit.

[0093] The following code implements dynamic adjustment of detection intensity: def adjust_monitoring_intensity(): cpu_load = get_system_load() if cpu_load>70%: disable_complex_rules() activate_fastpath() elif cpu_load<30%: enable_ml_detection().

[0094] In another embodiment, the risky call is protected by security measures, and the method further includes modifying the return value of the risky call when an abnormal call is detected during the security protection process.

[0095] In other words, when abnormal process behavior caused by a risky call is detected, it is started. Figure 2 The real-time execution unit places the return value of the risky call in a per-CPU circular buffer, and modifies the return value of the risky call within the per-CPU circular buffer. This embodiment directly modifies the syscall return value through an eBPF map. Using a per-CPU circular buffer avoids lock contention.

[0096] In other words, this embodiment utilizes eBPF map to directly intercept system calls in the kernel and achieves microsecond-level data transmission through a per-CPU ring buffer.

[0097] The resources consumed by using eBPF map for interception are calculated using the following kernel blocking function.

[0098] Kernel blocking function:

[0099] In the formula, This represents a blocking command. Blocking using eBPF map or or The total time consumed within time t. This indicates a rejection. When a system call is detected as not conforming to the security policy, an error code is returned directly to inform the caller that the system call operation has been rejected. This indicates termination; a direct signal is sent to any violations resulting from system calls, causing the violated operation to exit immediately. This not only stopped the current violation but also ended the process that led to it, thus preventing the violation from causing other potential harm. This signifies revocation, meaning the revocation of granted permissions or resources. After revocation, any unauthorized system calls will become invalid due to the lack of necessary authorization.

[0100] and as well as These three blocking instructions complement each other within the eBPF security framework, helping to implement fast, sophisticated, and programmable kernel-level blocking strategies.

[0101] The return value of a risky call blocked by the aforementioned kernel blocking function is copied to a per-CPU circular buffer. This return value is then modified within the per-CPU circular buffer to block the risky call. This embodiment uses a zero-copy approach to copy the return value to the per-CPU circular buffer. Zero-copy is a technique in computer systems that minimizes explicit memory copying between kernel space and user space. It allows data to directly share the same physical memory page between different processes or at different levels, thus saving one or more data copying steps.

[0102] This embodiment uses the following formula to calculate the time required for zero-copy:

[0103] In the formula, This represents the size of the returned data. Represents bandwidth.

[0104] This embodiment achieves policy reading and judgment within microseconds through zero-copy, and then immediately returns an error code at the system call entry point, realizing efficient defense of "intercepting first and then not leaking".

[0105] This embodiment can achieve a size smaller than The internal copying of data to the per-CPU circular cache further demonstrates that the zero-copy approach in this embodiment can achieve efficient interception.

[0106] In another embodiment, security protection is provided for the risky call. When an abnormal call is detected during the security protection process, the logs generated by the abnormal call are detected, and a topic model is extracted from the logs. Based on the topic model, an attack pattern is obtained. Based on the attack pattern, a security protection strategy is obtained. The false positive rate and false negative rate corresponding to the security protection strategy are determined. Based on the false positive rate and the false negative rate, the security protection strategy is optimized.

[0107] In other words, if a new attack pattern is discovered during each security protection process, the security protection strategy is updated to reflect the new attack pattern. This allows subsequent security protection strategies based on the updated and optimized strategies to provide better protection for containers and ensure the secure operation of applications within containers.

[0108] Logs record system calls. If a container is attacked, the system calls corresponding to the container will change accordingly, and the logs will also record these changes. Therefore, by analyzing the logs, we can obtain the attack pattern, which means that the existing security protection strategy has not blocked the attack. Therefore, we need to calculate the false positive rate and false negative rate of the existing security protection strategy against the attack pattern, and then adjust and optimize the existing security protection strategy based on the false positive rate and false negative rate to protect against more attack patterns.

[0109] This embodiment extracts attack patterns from logs based on the following formula:

[0110] In the formula, This represents the extracted attack pattern. The set representing the attack patterns. , This represents escape-type attacks, which include container escape and sandbox escape. This represents an attack that abuses system resources. This represents a privilege escalation attack. This represents the Latent Dirichlet Distribution algorithm, which is an algorithm for extracting topic models from log text. Representing the Log data for each device.

[0111] This embodiment calculates the loss function by weighting the false positive rate and the false negative rate based on the following formula:

[0112] In the formula, The loss function representing the current security protection strategy is... This represents the current security protection strategy. Represents the false alarm rate. Represents the underreporting rate. This is the weighting coefficient for the false alarm rate. The weighting coefficient for the false positive rate is denoted as . The above formula obtains the loss function by weighting the false positive rate and the false negative rate. Based on the calculated value of the loss function, the security protection strategy is adjusted to reduce the false positive rate and the false negative rate. In this embodiment, the security protection strategy is updated based on the value of the loss function using the following formula.

[0113]

[0114] In the formula, This represents the set of existing security protection strategies. This represents the new set of updated security protection strategies. This represents the learning rate, which is used to control the update step size.

[0115] The above and All in Figure 2 This process takes place in the security hub, specifically by the updated security protection strategy output by the security hub, and then... Figure 2 The coordinated protection decision will distribute the updated security protection strategy to edge devices.

[0116] use This represents the security protection strategy selected by the edge device. The calculation formula is as follows:

[0117] In the formula, Representatives implement security protection strategies Required system resources Represents edge devices (using) The system resources that can be provided by edge devices represent and The Euclidean distance between them is measured using Euclidean distance. and The degree of difference. The formula means finding a security protection strategy that matches the system resources that the edge device can provide, and using the security protection strategy to prevent the containers on the edge device from being attacked.

[0118] pass After selecting a security protection strategy suitable for edge devices, it is necessary to verify whether the selected strategy is truly applicable to edge devices. This embodiment verifies the effectiveness of the security protection strategy using the following formula:

[0119] In the formula, This embodiment requires a value representing the effectiveness assessment. Only security protection strategies with a value greater than 0.98 are effective. This represents the number of strategies that were successfully executed. Represents the total number of strategies. The effective time of the representative strategy, This represents the total time of the monitoring strategy, which includes both the effective and ineffective times of the strategy.

[0120] In another embodiment, when the container is a PLC container, the following technical solution is used to protect the container: Step S1: Initialize the system and load the PLC container to be protected and its key process group information into the egroup whitelist through the policy configuration and management module.

[0121] Step S2: Compile the egroup whitelist filtering logic into eBPF bytecode and load it into the kernel through the user-space eBPF probe module.

[0122] Step S3: When the kernel performs process scheduling or resource allocation, the eBPF probe is triggered. The probe calls a verification function to check whether the current process's group ID exists in the whitelist.

[0123] Step S4: If the group ID of the current process does not exist in the whitelist, then restrict its resource requests according to the policy; if the group ID of the current process exists in the whitelist, then allow it to allocate resources through the standard or enhanced path.

[0124] Step S5: The dynamic policy engine module continuously monitors the system load. Under low load, the default policy is used; when the load exceeds a threshold, the engine generates dynamic adjustment instructions based on a predefined rule set and the current protection policy weight.

[0125] Step S6: The dynamic policy engine will update the adjustment instructions to the filtering and scheduling logic in the eBPF probe module in real time.

[0126] Step S7: Based on the new logic, the eBPF probe prioritizes high-priority PLC processes in subsequent resource allocation to ensure that the passage of critical control commands is not affected under high-load scenarios.

[0127] This embodiment utilizes eBPF technology to execute security policies in kernel mode, avoiding the performance loss caused by frequent switching between user mode and kernel mode in traditional security proxy schemes. It achieves extreme optimization of CPU and other resource usage, and the system's own overhead is much lower than that of traditional schemes (more than 5%), usually controllable to within 1%. It solves the bottleneck problem that OT devices cannot withstand high-overhead security protection.

[0128] This embodiment fundamentally ensures the exclusive access of critical industrial control processes to computing resources through a kernel-level egroup whitelist mechanism, effectively defending against performance interference attacks caused by resource contention from other containers or processes.

[0129] The dynamic strategy engine in this embodiment can intelligently adjust the scheduling strategy according to the real-time status of the system, and automatically provide priority access for critical businesses under high load, thereby improving the resilience and determinism of the industrial control environment.

[0130] The security protection method in this embodiment is designed specifically for OpenHarmony edge computing scenarios. It makes full use of its lightweight and distributed characteristics to provide an "out-of-the-box" security enhancement solution for the containerized PLC transformation in intelligent manufacturing production lines.

[0131] In summary, this invention deploys an eBPF probe on the operating system kernel where the container resides. This eBPF probe monitors the system calls required for container operation within the kernel, and then filters these system calls, eliminating low-risk, pre-defined calls and protecting only high-risk calls. This achieves security protection for container operation. As the above analysis shows, this invention does not monitor all container-related system calls, but only high-risk calls, excluding low-risk ones. This saves more resources for ensuring container performance. Furthermore, since low-risk system calls pose little threat to container operation, this invention filters out low-risk system calls while monitoring high-risk calls, ensuring both secure container operation and balancing container computing power and operational stability.

[0132] In addition, this invention utilizes a pre-screening model of the eBPF probe layer. It reduces event handling load by 70% and continuously protects containers from attacks using only 0.3% of CPU resources.

[0133] The adaptive rule set switching mode on the strategy engine of this invention can ensure system stability under extreme conditions and maintain the accuracy of application execution within the container during peak CPU usage.

[0134] The gradient optimization strategy of the security hub in this invention reduces the false alarm rate to 0.07%. Even if the security protection strategy is deployed on 100,000 edge devices, the time required to update the security protection strategy is only 11 minutes, which is far less than the 8 hours required by the prior art.

[0135] This embodiment also provides a container safety protection device, such as... Figure 6 As shown, the device comprises the following components: System call monitoring module 01 is used to determine system calls related to containers and monitor the system calls through an eBPF probe, which is deployed on the operating system kernel; The filtering module 02 is used to filter the system calls to filter out predetermined calls and obtain risky calls, wherein the predetermined calls are system calls whose security risk is less than a threshold. Protection module 03 is used to provide security protection for the risky calls, so as to achieve security protection for the operation of the container.

[0136] In one implementation, the system call monitoring module includes: The first data acquisition unit is used to acquire the system call set related to the container; A latency acquisition unit is used to acquire the execution latency of each call in the system call set; The first filtering unit is used to filter out the system calls corresponding to the container from the system call set based on the execution latency corresponding to each call.

[0137] In one implementation, the filtering unit includes: Threshold setting component, used to obtain latency threshold; A filtering component is used to filter out calls whose execution latency is less than the latency threshold from the system call set, and to designate the call as the system call corresponding to the container.

[0138] In one implementation, the system call monitoring module includes: The second data acquisition unit is used to acquire the system call set related to the container; A frequency acquisition unit is used to acquire the frequency corresponding to each call in the system call set; The second filtering unit is used to filter out the system calls corresponding to the container from the system call set based on the frequency of each call.

[0139] In one implementation, the filtering module includes: The whitelist matching unit is used to determine the call corresponding to the whitelist container set in the predetermined call, wherein the security risk corresponding to each container in the whitelist container set is less than a threshold. The filtering unit is used to filter the system calls to filter out the calls corresponding to the whitelist container set and obtain the risk calls corresponding to the risk containers.

[0140] In one implementation, the protection module includes: The process monitoring unit is used to collect data related to the risky call and to obtain process behavior based on the data. The protection unit is used to perform security protection on the process behavior based on the process policy library and process context, so as to realize the security protection of the container operation. The process policy library is used to record the rules corresponding to the safe operation of the container.

[0141] In one implementation, the protection unit includes: The utilization rate statistics component is used to collect the utilization rate of the processor where the operating system kernel is located; A protection instruction activation component is used to determine the activation of protection instructions based on the occupancy rate, and to perform security protection on the process behavior by activating the protection instructions. The protection instructions include protection instructions based on the process policy library and protection instructions based on the process context.

[0142] One implementation also includes: The modification module is used to modify the return value of the risky call when an abnormal call is detected during the security protection process.

[0143] In one implementation, the modification module includes: A buffer modification unit is used to place the return value of the risky call in a per-CPU circular buffer and modify the return value of the risky call within the per-CPU circular buffer.

[0144] One implementation also includes: The termination module is used to terminate the process behavior caused by the risky call when an abnormal call is detected during the security protection process.

[0145] One implementation also includes: The detection module is used to detect the logs generated by the abnormal call when an abnormal call is detected during the security protection process; The optimization module is used to optimize security protection strategies based on the logs.

[0146] In one implementation, the optimization module includes: A topic extraction unit is used to extract topic models from the logs; An attack pattern analysis unit is used to obtain attack patterns based on the topic model. The strategy analysis unit is used to obtain a security protection strategy based on the attack pattern. The false alarm and false alarm statistics unit is used to determine the false alarm rate and false alarm rate corresponding to the security protection strategy. The strategy optimization unit is used to optimize the security protection strategy based on the false alarm rate and the false negative rate.

[0147] Based on the above embodiments, the present invention also provides a terminal device, the principle block diagram of which can be as follows: Figure 7 As shown, the terminal device includes a processor, memory, network interface, and display screen connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a container security protection method. The display screen of the terminal device can be a liquid crystal display (LCD) or an e-ink display.

[0148] Those skilled in the art will understand that Figure 7 The schematic diagram shown is only a partial structural diagram related to the present invention and does not constitute a limitation on the terminal device to which the present invention is applied. The specific terminal device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0149] In one embodiment, a terminal device is provided, comprising a memory, a processor, and a container security protection program stored in the memory and executable on the processor. When the processor executes the container security protection program, it implements the following operation instructions: Identify system calls related to the container and monitor these system calls using an eBPF probe deployed on the operating system kernel; The system calls are filtered to remove predetermined calls and obtain risky calls, wherein the predetermined calls are system calls with a security risk less than a threshold. Security protection is provided for the risky calls to ensure the safe operation of the container.

[0150] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0151] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A container safety protection method, characterized in that, include: Identify system calls related to the container and monitor these system calls using an eBPF probe deployed on the operating system kernel; The system calls are filtered to remove predetermined calls and obtain risky calls, wherein the predetermined calls are system calls with a security risk less than a threshold. Security protection is provided for the risky calls to ensure the safe operation of the container.

2. The container safety protection method as described in claim 1, characterized in that, Determining the system calls associated with the container includes: obtaining a set of system calls associated with the container; Obtain the execution latency of each call in the system call set; Based on the execution latency corresponding to each call, the system calls corresponding to the container are selected from the system call set.

3. The container safety protection method as described in claim 2, characterized in that, Based on the execution latency corresponding to each call, the system calls corresponding to the container are filtered from the system call set, including: Obtain the latency threshold; The system call set is filtered to select calls whose execution latency is greater than or equal to the latency threshold, and these calls are designated as the system calls corresponding to the container.

4. The container safety protection method as described in claim 1, characterized in that, Identify the system calls associated with the container, including: Obtain the set of system calls associated with the container; Obtain the frequency corresponding to each call in the system call set; Based on the frequency of each call, the system calls corresponding to the container are selected from the system call set.

5. The container safety protection method as described in claim 1, characterized in that, The system calls are filtered to remove predetermined calls and obtain risky calls, including those mentioned above. Determine the call corresponding to the whitelisted container set in the predetermined call, wherein the security risk corresponding to each container in the whitelisted container set is greater than a threshold; The system calls are filtered, and only the calls corresponding to the whitelist container set are retained to obtain the risk calls corresponding to the risk containers.

6. The container safety protection method as described in claim 1, characterized in that, To provide security protection for the risky calls and thus ensure the security of the container's operation, the following measures are taken: Collect data related to the risky call, and obtain process behavior based on the data; Security protection is provided for the process behavior to achieve security protection for the operation of the container.

7. The container safety protection method as described in claim 6, characterized in that, To provide security protection for the process behavior and thus ensure the safe operation of the container, the following measures are taken: Based on the process policy library and process context, security protection is provided for the process behavior to achieve security protection for the operation of the container. The process policy library is used to record the rules corresponding to the safe operation of the container.

8. The container safety protection method as described in claim 7, characterized in that, Based on the process policy library and process context, security protection is provided for the process behavior, including: Collect the utilization rate of the processor where the operating system kernel is located; Based on the occupancy rate, the activation of protection instructions is determined, and the process behavior is protected by activating the protection instructions. The protection instructions include protection instructions based on the process policy library and protection instructions based on the process context.

9. The container safety protection method as described in claim 8, characterized in that, Based on the occupancy rate, the activation of the protection command is determined, including: When the occupancy rate is less than or equal to the set rate value, protection instructions based on the process policy library and protection instructions based on the process context are activated simultaneously.

10. The container safety protection method as described in claim 9, characterized in that, Based on the aforementioned occupancy rate, determining the activation of the protection command also includes: When the occupancy rate is greater than the set rate value, protection instructions based on the process policy library are initiated, while protection instructions based on the process context are terminated.

11. The container safety protection method as described in claim 9, characterized in that, Initiate protection commands based on the aforementioned process policy library, including: The microsecond-level protection instructions in the protection instructions based on the process policy library are determined. The microsecond-level protection instructions are used to characterize the security protection detection instructions that the operating system can complete within microseconds. The microsecond-level protection command is initiated.

12. The container safety protection method as described in claim 1, characterized in that, Security protection is provided for the aforementioned risky calls, which then includes: When an abnormal call is detected during the security protection process, the return value of the risky call is modified.

13. The container safety protection method as described in claim 12, characterized in that, Modify the return value of the risk call, including: The return value of the risky call is placed in a per-CPU circular cache, and the return value of the risky call is modified within the per-CPU circular cache.

14. The container safety protection method as described in claim 1, characterized in that, Security protection is provided for the aforementioned risky calls, which then includes: When an abnormal call is detected during the security protection process, the process behavior caused by the risky call is terminated.

15. The container safety protection method as described in claim 1, characterized in that, Security protection is provided for the aforementioned risky calls, which then includes: When an abnormal call is detected during the security protection process, the logs generated by the abnormal call are checked. Based on the logs, optimize the security protection strategy.

16. The container safety protection method as described in claim 15, characterized in that, Based on the logs, optimize the security protection strategy, including: Extract the topic model from the logs; Based on the aforementioned topic model, the attack pattern is obtained; Based on the attack pattern described, a security protection strategy is derived. Determine the false alarm rate and false negative rate corresponding to the security protection strategy; Based on the false alarm rate and the false negative rate, the security protection strategy is optimized.

17. The container safety protection method according to any one of claims 1-16, characterized in that, The container runs on an OpenHarmony device.

18. A container safety protection device, characterized in that, The device comprises the following components: The system call monitoring module is used to determine system calls related to containers and monitor these system calls through eBPF probes deployed on the operating system kernel. The filtering module is used to filter the system calls to filter out predetermined calls and obtain risky calls, wherein the predetermined calls are system calls with a security risk of less than a threshold. The protection module is used to provide security protection for the risky calls, so as to achieve security protection for the operation of the container.

19. A terminal device, characterized in that, The terminal device includes a memory, a processor, and a container security protection program stored in the memory and executable on the processor. When the processor executes the container security protection program, it implements the steps of the container security protection method as described in any one of claims 1-17.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a container security protection program, which, when executed by a processor, implements the steps of the container security protection method as described in any one of claims 1-17.

Images