An eBPF-based Payload process detection method and device in a cloud environment
By using eBPF technology to monitor kernel events in the cloud environment, detect reverse connection payloads and monitor their access behavior, the problem of difficult to detect new features and performance losses of payloads in the cloud environment in the existing technology is solved, and efficient container security analysis and cloud platform security guarantees are achieved.
Patent Information
- Application Number
- CN202211642785.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-20
- Publication Date
- 2025-06-03
- Estimated Expiration
- 2042-12-20
AI Technical Summary
Existing detection technologies are difficult to effectively detect new features of payloads in cloud environments, especially in reverse connection payloads, and frequent switching of user states and kernel states leads to performance losses.
Payload process detection method in a cloud environment based on eBPF is adopted, and the switching between user state and kernel state is avoided through eBPF technology, the inet_sock_set_state and syscalls events are monitored, the reverse connection class payload is detected, and its process ID and process group ID are recorded, and its access file behavior is monitored.
It greatly reduces performance losses, can effectively monitor the service container process in the kernel state, detect reverse connection payloads in a targeted manner, ensure the safety of container operation, and improve the security of the cloud computing platform.
Smart Images
Figure CN116389027B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of container virtualization security, and specifically to a method and device for detecting Payload processes in a cloud environment based on eBPF (Extended Berkeley Packet Filter). Background Art
[0002] With the continuous development of cloud computing technology, the cloud service models provided by cloud platforms are becoming more and more diverse. From IaaS, PaaS, SaaS to BaaS, FaaS, from providing basic equipment to providing a specific function, the granularity of resource division is getting finer and finer, which makes the utilization of resources more efficient. Correspondingly, virtualization technology has also developed from the earliest Hypervisor technology to container technology. Compared with the former, container virtualization technology has a smaller footprint and higher resource utilization rate, but its isolation is much worse, so it is more vulnerable to intrusion. Once there are vulnerabilities in the containers on the cloud, attackers may obtain the permissions of the cloud platform through container escape attacks, thereby threatening other resources on the cloud. Therefore, how to detect and locate container anomalies has always been an issue of concern in the industry.
[0003] There are many types of vulnerabilities. In the C language used in the Linux kernel, there are five types of vulnerabilities: pointer overwrite, buffer overflow, memory management error, formatted output, and integer overflow. And the attacks against program vulnerabilities can be roughly divided into four categories: memory corruption, hijacking control flow, stealing information, and non-control data attacks. Although the types of vulnerabilities are different and there are many attack methods, the attack processes for vulnerabilities are generally the same. For example, a certain model describing network attacks - the "network kill chain", which divides network attacks into 7 stages, namely: reconnaissance and tracking, weapon construction, payload delivery, vulnerability exploitation, installation and implantation, command and control, and target achievement. In the vulnerability exploitation stage, attackers develop different attack methods according to the principle of the vulnerability to obtain illegal control permissions; in the installation and implantation stage, attackers implant payload processes on the attacked end to prepare for subsequent control of the attacked end.
[0004] In a cloud environment, the payloads used by attackers have new common characteristics. For example, since the vast majority of servers are in the internal network, the public network IP cannot directly access the server, which makes it difficult to apply forward connection type payloads in the cloud environment, and reverse connection type payloads are more effective in the attack scenarios of the cloud environment.
[0005] Existing detection technologies do not detect according to the new characteristics of payloads in the cloud environment, and due to the frequent switching between user mode and kernel mode during the detection process, a large amount of performance loss is caused. Summary of the Invention
[0006] In view of the new features of payloads in the cloud environment, the present invention proposes a method and device for detecting Payload processes in the cloud environment based on eBPF. Using eBPF technology avoids the switching between the user space and the kernel space, greatly reducing performance loss. At the same time, it detects reverse connection type payloads in the cloud environment and detects attacks from another dimension. The method includes the following steps:
[0007] A method for detecting Payload processes in the cloud environment based on eBPF, including the following steps:
[0008] Step 1: Construct a whitelist to prevent false detection:
[0009] In the cloud environment during normal operation, add service processes that actively initiate connections from the server side to the whitelist; construct a network segment whitelist in the form of IP addresses for the internal network segments;
[0010] Step 2: Detect reverse connection type payloads and record their process IDs and process group IDs;
[0011] Step 3: Monitor the file access behaviors of the process groups where the suspected payload processes are located to facilitate subsequent damage control.
[0012] Further, the specific steps of Step 2 include:
[0013] Step 2.1: Monitor the inet_sock_set_state tracepoint through eBPF packet filtering technology to obtain all sock events in the server;
[0014] Step 2.2: Filter by the name of the process task_struct, and only retain the child processes and descendant processes of the process named containerd-shim. These processes are the service container processes that provide services externally;
[0015] Step 2.3: Judge whether the TCP connection is initiated by the server side according to the input parameters of inet_sock_set_state;
[0016] Step 2.4: Judge whether the process initiated by the server side is in the whitelist. If not, record the process PID in the log, then obtain its task_struct structure, and obtain its process group ID through task_struct->signal->pids[2], and add it to the monitoring list;
[0017] Step 2.5: Locate the pod to which the payload process belongs according to the pod and IP correspondence.
[0018] Further, the specific steps of Step 3 include:
[0019] Step 3.1: Monitor the sys_enter_open and sys_enter_openat tracepoints under syscalls events by using the eBPF packet filtering technology to obtain all file access behaviors on the server side;
[0020] Step 3.2: If the process group ID of the current process is in the monitoring list, record its file access behavior in the log file.
[0021] A Payload process detection device in a cloud environment based on eBPF, including a collection module, a detection module, a positioning module, a tracking module, and an access control algorithm module;
[0022] The collection module: Collect the state changes, source and destination addresses, and source and destination ports of the sock connections of the container processes providing services externally by Kubernetes by registering the inet_sock_set_state tracepoint;
[0023] The detection module: Detect the payload process in the container service process by screening the TCP status flags;
[0024] The positioning module: Responsible for locating the container where the process suspected of being a payload is located;
[0025] The tracking module: Determine the specific service container through the source port and source IP of the forward connection information;
[0026] The access control algorithm module: Match the process information obtained in the probe function with the information in the access policy file; if the match is successful, continue to call the kernel function; if the match is unsuccessful, combine the characteristics of passing parameters and return values through registers and stacks between kernel functions, and modify the passing of parameters and return values between kernel functions, thereby preventing the execution of the kernel function and further preventing malicious operations.
[0027] Compared with the prior art, the beneficial effects of the present invention are as follows: By using the eBPF technology, the present invention analyzes the kernel events at the bottom layer of the system, reduces the security analysis granularity of containers to the kernel event level, and monitors the service container processes in the kernel state at the same time, greatly reducing the performance loss caused by the switching between the kernel state and the user state. At the same time, according to the new characteristics of the payload process in the cloud environment, the present invention specifically detects the reverse connection type payload, ensuring the safe operation of the container and further guaranteeing the security of the cloud computing platform. In addition, the eBPF event types selected in the present invention are all tracepoints, which are static and maintained by kernel personnel. Therefore, this method can run in different versions of the kernel, has good portability and compatibility, and does not require restarting the container during deployment, realizing the flexible feature of plug and play. BRIEF DESCRIPTION OF THE DRAWINGS
[0028] Figure 1 FIG. is the overall architecture diagram of the Payload process detection method based on eBPF in the cloud environment of the present invention.
[0029] Figure 2 FIG. is the flowchart of the Payload process detection method based on eBPF in the cloud environment of the present invention.
[0030] Figure 3 FIG. is the detection effect diagram of the Payload process detection method based on eBPF in the cloud environment of the present invention.
[0031] Figure 4 FIG. is the comparison diagram of performance loss in the single-threaded environment of the Payload process detection method based on eBPF in the cloud environment of the present invention.
[0032] Figure 5 FIG. is the comparison diagram of performance loss in the multi-threaded environment of the Payload process detection method based on eBPF in the cloud environment of the present invention. DETAILED DESCRIPTION OF THE INVENTION
[0033] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0034] A Payload process detection method based on eBPF in the cloud environment includes the following steps:
[0035] Step 1: Construct a whitelist to prevent false detection:
[0036] Step 1.1: In the cloud environment during normal operation, add the service processes that actively initiate connections from the server side to the whitelist, such as some system components in the kube-system namespace, and construct a command whitelist by recording the name of the task_struct structure.
[0037] Step 1.2: Considering that some service requirements may involve communication with other IPs in the enterprise intranet, the network segments of the intranet are constructed into a network segment whitelist in the form of IP addresses.
[0038] Step 2: Detect reverse connection type payloads, record their process IDs and process group IDs, and locate the pod to which the payload belongs:
[0039] Step 2.1: Monitor the inet_sock_set_state tracepoint through eBPF technology to obtain all sock events in the server.
[0040] Step 2.2: By filtering the names of the process task_structs, only keep the child processes and descendant processes of the process named containerd-shim. These processes are the service container processes that provide services externally.
[0041] Step 2.3: Judge whether the TCP connection is initiated by the server side according to the input parameters of inet_sock_set_state; there are 5 connection states for the client, namely: SYN_SENT, ESTABLISHED, FIN_WAIT1, FIN_WAIT2, TIME_WAIT, and there are also 5 connection states for the server side, namely: SYN_RCVD, ESTABLISHED, CLOSE_WAIT, LAST_ACK, CLOSED.
[0042] Step 2.4: Judge whether the process that initiates the connection from the server side is in the whitelist. If not, record the process PID in the log, then obtain its task_struct structure, and obtain its process group ID through task_struct->signal->pids[2], and add it to the monitoring list.
[0043] Step 2.5: Locate the pod to which the payload process belongs according to the correspondence between the pod and the IP.
[0044] Step 3: Monitor the file access behavior of the process group where the suspected payload process is located to facilitate subsequent damage control:
[0045] Step 3.1: Monitor the sys_enter_open and sys_enter_openat tracepoints through eBPF technology to obtain all file access behaviors on the server side.
[0046] Step 3.2: If the process group ID of the current process is in the monitoring list, record its file access behavior in the log file.
[0047] A Payload process detection method based on eBPF in a cloud environment, including a collection module, a detection module, and a tracking module;
[0048] Collection module: By registering the inet_sock_set_state tracepoint, collect the state changes, source and destination addresses, and source and destination ports of the sock connections of the container processes that provide services externally in Kubernetes;
[0049] Detection module: Detect the payload processes in the container service processes by filtering the TCP status flags;
[0050] Location module: Responsible for locating the container where the process suspected of being a payload is located;
[0051] Tracking module: Determine the specific service container through the source port and source IP of the forward connection information.
[0052] The access control algorithm module: By matching the process information obtained in the probe function with the information in the access policy file, if the match is successful, continue to call the kernel function. If the match is unsuccessful, combine the characteristics of passing parameters and return values between kernel functions through registers and the stack, and modify the passing of parameters and return values between kernel functions, thereby preventing the execution of the kernel function and further preventing malicious operations.
[0053] Appendix Figure 1 Figure Figure 1 shows the overall architecture diagram of the Payload process detection method based on eBPF in the cloud environment of the present invention. As shown, the method of the present invention can be used to detect reverse connection type payloads and locate the service containers where they are located. Finally, track the subsequent file access behaviors of the payload process group, so that containers that have been compromised by attackers can be discovered in time. At the same time, according to the records of file access, subsequent damage control can be facilitated. This method consists of four parts: a collection module, a detection module, a location module, and a tracking module. The collection module is responsible for collecting the sock status information of the container processes that provide services externally in Linux and belong to Kubernetes; the detection module is responsible for detecting processes suspected of being payloads; the location module is responsible for locating the containers where the processes suspected of being payloads are located; the tracking module is responsible for tracking the file opening behaviors of abnormal container process groups for damage control. Next, the principle and implementation will be described.
[0054] Appendix Figure 2The flowchart of the working process of the method of the present invention is given. Through the eBPF technology, all connections and file access behaviors of the server are monitored in the kernel state. The working process of the connection monitoring part is as follows: (1) When a tcp connection of a service container process is established, it is judged whether the connection is initiated by the server side. If not, it is executed normally. If so, the next step is carried out; (2) It is judged whether the connection is in the whitelist. If so, it is executed normally. If not, the next step is carried out; (3) The pid of the process is recorded in the log file; (4) Locate the service container where the process is located; (5) Add the pgid of the process to the monitoring list. The working process of the file access behavior monitoring part is as follows: (1) Monitor all file access behaviors of the server. If it is not in the monitoring list, it is executed normally. If so, the next step is carried out; (2) Record the file access behavior in the log file.
[0055] Appendix Figure 3 The running effect of the method of the present invention is given. It can be seen that this method can detect the service container, used port, PID and task_struct structure name where the reverse connection type payload is located. At the same time, it can monitor the files accessed by the payload process group subsequently.
[0056] Appendix Figure 4 The performance consumption of the method of the present invention in a single-threaded environment is given. According to the calculation, in the single-threaded performance scoring test, the item that has the greatest impact on performance by the detection program is System Call Overhead. The average score loss of enabling the detection program is 2.13%, and the total score loss is 2.81%.
[0057] Appendix Figure 5 The performance consumption of the method of the present invention in a multi-threaded environment is given. According to the calculation, in the multi-threaded performance scoring test, the item that has the greatest impact on performance by the detection program is Pipe Throughput. The average score loss of enabling the detection program is 1.07%, and the total score loss is 0.53%.
[0058] From Appendix Figure 4 and Appendix Figure 5 it can be seen that the payload anomaly detection system has a minimal impact on the system performance.
Claims
1. A Payload process detection method in a cloud environment based on eBPF, characterized in that, it includes the following steps: Step 1: Build a whitelist to prevent false detection: In a cloud environment during normal operation, add service processes that actively initiate connections from the server side to the whitelist; build a network segment whitelist for the internal network segment in the form of IP addresses. Step 2: Detect reverse connection type payloads and record their process IDs and process group IDs. Step 3: Monitor the file access behaviors of the process group where the suspected payload process is located for subsequent damage control. The specific content of Step 2 includes: Step 2.1: Monitor the inet_sock_set_state tracepoint through eBPF packet filtering technology to obtain all sock events in the server. Step 2.2: By filtering the names of the process task_struct, only retain the child processes and descendant processes of the process named containerd-shim. These processes are the service container processes that provide services externally. Step 2.3: Judge whether the TCP connection is initiated by the server side according to the input parameters of inet_sock_set_state. Step 2.4: Judge whether the process that initiates the connection from the server side is in the whitelist. If not, record the process PID in the log, then obtain its task_struct structure, and obtain its process group ID through task_struct->signal->pids[2], and add it to the monitoring list. Step 2.5: Locate the pod to which the payload process belongs according to the correspondence between the pod and the IP.
2. The Payload process detection method in a cloud environment based on eBPF according to claim 1, characterized in that, the specific content of Step 3 includes: Step 3.1: Monitor the sys_enter_open and sys_enter_openat tracepoints under the syscalls event through the use of eBPF packet filtering technology to obtain all file access behaviors on the server side. Step 3.2: If the process group ID of the current process is in the monitoring list, record its file access behavior in the log file.
3. A Payload process detection device in a cloud environment based on eBPF that adopts the detection method described in claim 1 or 2, characterized in that, it includes a collection module, a detection module, a location module, a tracking module, and an access control algorithm module; The collection module: By registering the inet_sock_set_state tracepoint, collect the state changes, source and destination addresses, and source and destination ports of the sock connections of the container processes that provide services externally in Kubernetes. The detection module: Detect the payload processes in the container service processes by filtering the TCP status flags. The location module: Responsible for locating the container where the process suspected of being a payload is located. The tracking module: Determine the specific service container through the source port and source IP of the forward connection information. The access control algorithm module: matches the process information obtained in the probe function with the information in the access policy file; if the match is successful, it continues to call by running the kernel function; if the match is unsuccessful, it combines the characteristics of passing parameters and return values through registers and stacks in the kernel function calls, and modifies the passing of parameters and return values between kernel functions, thereby preventing the execution of kernel functions and further preventing malicious operations.