Lightweight attack detection method and device for container host platforms

Abstract

This invention discloses a lightweight attack detection method and apparatus for container host platforms. The method includes: acquiring the monitored function and vulnerability information to be monitored; creating a `vulner_info` structure based on the vulnerability information name, with the corresponding private structure storing the system call parameters to be checked; when the kernel is about to execute the monitored function, calling a callback function to obtain the system call parameter values ​​generated during the execution of the monitored function; passing the address of the private structure to the callback function to allow the callback function to access the private structure; and comparing the system call parameter values ​​with the system call parameters to be checked to obtain the attack detection result of the monitored function. This invention achieves evasion attack detection with relatively low performance overhead.

Description

Technical Field

[0001] This invention relates to the field of computer network security, and is used for attack detection on container host platforms. More specifically, it is a lightweight attack detection method and apparatus for container host platforms. Background Technology

[0002] Container technology is an operating system-level virtualization technology that primarily relies on the resource isolation and abstraction mechanisms provided by the operating system kernel. The Linux kernel's namespace and cgroup mechanisms are the cornerstones of container technology; the former is used to achieve resource isolation, while the latter is mainly used to limit resource usage. Compared to traditional virtualization technologies, container technology has become the preferred choice for current cloud platforms due to its fast startup and high operating efficiency. Processes within a container run in an isolated environment, possessing independent network stacks and file system views, and cannot access information about processes running on the host machine or other containers on the host. The physical resources used by processes within a container can be strictly limited, such as memory, CPU utilization, and I / O throughput.

[0003] Compared to virtual machines, containers offer higher execution efficiency, but virtual machines provide stronger isolation. Although processes within a container run in different namespaces, they still share the same underlying operating system kernel. This shared kernel characteristic makes attacks exploiting Linux kernel vulnerabilities to escape from containers commonplace. The Linux kernel currently contains over 27 million lines of code, with new privilege escalation vulnerabilities disclosed annually. A process within a container can exploit kernel vulnerabilities to escape the container environment and gain complete control of the host machine. The container process constructs the kernel's memory layout by executing specific system calls and triggers the execution of vulnerable functions. After hijacking the kernel's control flow, the container process can execute specific kernel functions to switch the process's namespaces, thus achieving escape. Therefore, the confidentiality and availability of container cloud providers and other tenants are threatened. To detect attacks promptly and reduce the attacker's window of opportunity, it is necessary to install intrusion detection systems on cloud platforms.

[0004] Host-based intrusion detection systems primarily monitor the host's operational status and issue alerts for potential attacks. They typically consist of an event generator, an event analyzer, a response unit, and an event database. The event generator obtains events from the system and sends them to the event analyzer. The event analyzer analyzes the event and sends the event and analysis results to the response unit and the event database. Traffic-based host intrusion detection systems primarily inspect each network packet, judging them according to predefined rules. If an anomaly is detected, an alert is immediately generated or the packet is intercepted. Simultaneously, there are also intrusion detection systems based on host runtime status, which mainly obtain operating system performance metrics for judgment. However, runtime status-based intrusion detection systems require frequent interception of operating system events, which can impose a significant performance overhead on the operating system. Therefore, for container platforms, a lightweight intrusion detection system is more necessary. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes a lightweight attack detection method and apparatus for container host platforms, achieving evasion attack detection with minimal performance overhead. It acquires the execution status of key kernel functions and matches them against predefined rules; a successful match generates an alert.

[0006] To achieve the above objectives, the technical solution of the present invention includes:

[0007] A lightweight attack detection method for container host platforms, the method comprising:

[0008] Obtain information on the monitored functions and the vulnerabilities that need to be monitored;

[0009] Based on the name of the vulnerability information, a corresponding `vulner_info` structure is created. The `vulner_info` structure contains the following data: the name of the vulnerability information, the system call number, the system call parameters of the vulnerability information, the number of system call parameters, a mask, and the address of the corresponding `fops_node` structure. The mask stores the items to be checked in the system call parameters. The `fops_node` structure contains the name of the monitored function and the address of the `ftrace_ops` structure. The `ftrace_ops` structure encapsulates a private structure, and the private structure contains the system call parameters to be checked, obtained based on the mask and the system call parameters.

[0010] When the kernel is about to execute the monitored function, it calls the callback function so that the callback function can obtain the system call parameter values ​​generated during the execution of the monitored function;

[0011] The address of the private structure is passed to the callback function so that the callback function can access the private structure;

[0012] The system call parameter value is compared with the system call parameter to be checked to obtain the attack detection result of the monitored function.

[0013] Further, obtaining the corresponding `vulner_info` structure based on the name of the vulnerability information includes:

[0014] Based on the name of the vulnerability information, the vulner_info structure with the name of the vulnerability information is searched in the node of the vulnerability list; wherein each node is a vulner_info structure, and the vulnerability list consists of at least one node;

[0015] If the vulner_info structure corresponding to the vulnerability information is found, the vulner_info structure is set in the monitoring system for the container host platform;

[0016] If no corresponding vulner_info structure is found for the vulnerability information, a vulner_info structure is created based on the vulnerability information, and this vulner_info structure is added to the vulnerability chain list and set in the monitoring system for the container host platform.

[0017] Furthermore, the step of calling a callback function when the kernel is about to execute the monitored function, so that the callback function, in conjunction with the system call number, obtains the system call parameter values ​​generated by the monitored function during execution, includes:

[0018] Obtain the address of the system call table in the kernel;

[0019] Based on the system call number and the address of the system call table, obtain the function name of the kernel function __x64_sys_(sycallname), so that the kernel function __x64_sys_(sycallname) is used as the monitored function, and obtain the system call parameter values ​​generated by the monitored function during execution.

[0020] The callback function obtains the system call parameter value by combining the parameter pt_regs in the kernel function _x64_sys_(sycallname) with the parameter pt_regs in the callback function.

[0021] Furthermore, obtaining the address of the system call table in the kernel includes:

[0022] Register a kprobe structure for the kallsyms_lookup_name function;

[0023] The base address in the kernel of the kallsyms_lookup_name function is obtained from the kprobe structure;

[0024] The address of the system call table is obtained through the base address.

[0025] Further, the step of obtaining the system call number based on the address of the system call table...

[0026] __x64_sys_(sycallname) is the function name of a kernel function, including:

[0027] Calculate the offset based on the system call number;

[0028] Based on the address of the system call table and the offset, the system call address of the monitored function is obtained;

[0029] Based on the system call address, the system call name of the kernel function __x64_sys_(sycallname) is obtained.

[0030] Furthermore, after comparing the system call parameters of the vulnerability information with the system call parameters that the monitored function needs to check during its execution to obtain the attack detection result of the monitored function, the method further includes:

[0031] Register a miscellaneous device in the container host platform and implement a function for reading files;

[0032] If the attack detection result is a function attack, the alarm information or message is converted into a string and the string is added to the tail of the log list; wherein, the log list is created during initialization;

[0033] When reading miscellaneous device files, the head node of the log list is retrieved using the file read operation function, and the information stored in the head node is copied to a specified buffer to obtain the log.

[0034] Furthermore, when reading the miscellaneous device file, after using the function of the file read operation to retrieve the head node of the log list and copy the information stored in the head node to a specified buffer to obtain the log, the method further includes:

[0035] Send the log to a remote server;

[0036] The remote server collects information or issues remote control commands based on the logs.

[0037] Furthermore, the method further includes: managing the vulnerability information to be monitored based on a vulnerability management client; wherein, managing the vulnerability information to be monitored based on a vulnerability management client includes:

[0038] Based on the operation type, an IOCTL code is selected; wherein, the operation type includes: add operation, modify operation, delete operation, and query operation;

[0039] Based on the selected IOCTL code, information is exchanged through the IOCTL system; wherein, the information for the add operation and the modify operation includes: the name of the vulnerability information, the system call number, the system call parameters of the vulnerability information, the number of the system call parameters and the mask; the information for the delete operation includes: the name of the vulnerability information; and the information for the query operation includes: the number of vulnerabilities that have been installed.

[0040] A storage medium storing a computer program, wherein the computer program is configured to execute any of the methods described above when run.

[0041] An electronic device is characterized by comprising a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform any of the methods described above.

[0042] Compared with existing technologies, the method proposed in this invention has the following advantages:

[0043] 1. Lightweight: This invention utilizes the native Linux kernel, requiring only the installation of one kernel module to achieve complete monitoring operations;

[0044] 2. Low resource consumption: It only monitors sensitive functions and high-risk system calls, without consuming a lot of system resources, making it especially suitable for mobile platforms;

[0045] 3. Detection rules can be configured at any time: Adding, modifying, and deleting detection rules does not require interrupting the service or restarting the platform. Attached Figure Description

[0046] Figure 1 Overall framework diagram of the present invention.

[0047] Figure 2 A schematic diagram of the vulnerability management module of this invention. Detailed Implementation

[0048] Specific embodiments of the present invention will be described below with reference to the accompanying drawings. It is understood that the embodiments described herein are merely some, not all, of the embodiments of the present invention. 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.

[0049] This invention proposes a lightweight attack detection method for container host platforms. Users can define detection rules to determine which kernel functions need to be monitored. The execution of the kernel functions serves as the event source for the intrusion detection system and is matched against the user-defined rules. If a match is successful, an alarm message is generated.

[0050] like Figure 1 The diagram shows the overall architecture of this method. This method mainly consists of five modules, which run in the user layer and kernel layer respectively.

[0051] Module 1, Vulnerability Management Module. This module runs at the kernel level, maintaining vulnerability-related information, providing a management interface for the user layer, and controlling the execution of the kernel function execution monitoring module. This invention primarily targets Linux kernel vulnerabilities, which are always triggered by system calls. Users can specify the system call number to be monitored and the parameters of this system call. For example... Figure 2 As shown, the data structure for storing vulnerability information is a linked list, with each vulnerability information stored in a node of the vulnerability linked list. Each node stores the vulnerability name, system call number, number of system call parameters, system call parameters, mask (which system calls need to be checked), and the address of the corresponding fops_node_t.

[0052] The process of adding vulnerability information first checks if a vulnerability information node with the same name already exists in the linked list. If it does, an exception is returned; otherwise, a node is created and added to the linked list. Then, the kernel function is called to execute the monitoring module's functionality and enable the corresponding kernel function monitoring.

[0053] For the operation of deleting vulnerability information, first check if the specified vulnerability information node exists in the linked list. If it does, first call the kernel function to execute the monitoring module's function, disable the corresponding kernel function monitoring, and then delete the node from the linked list and release the memory; otherwise, return an exception.

[0054] Users can view or modify vulnerability information at any time. Modifying vulnerability information can be considered as deleting the old vulnerability information and creating a new one. Viewing the number of vulnerability entries involves traversing the linked list and returning the number of nodes. After obtaining the number of vulnerability entries, users can further query all vulnerability information. For this operation, the vulnerability management module will write the specified information to the user-provided buffer.

[0055] Module 2, Kernel Function Execution Monitoring Module. This module runs at the kernel layer, providing an interface to the vulnerability management module and implementing kernel function monitoring functionality. The monitoring function relies on the kernel mechanism ftrace. Function monitoring requires prior registration, specifying the name of the function to be monitored and an ftrace_ops structure.

[0056] The structure of the `ftrace_ops` structure is defined by the Linux kernel. The most important member variable in this structure is the address of the callback function. Since the same `ftrace_ops` structure is required when unloading function monitoring, it needs to be managed. The kernel function execution monitoring module constructs a linked list, encapsulating each `ftrace_ops` structure in a `fops_node` node within the monitoring list. When a new function monitoring needs to be created, a node is created; when a function monitoring needs to be unloaded, the node is removed from the linked list and its memory is released.

[0057] Whenever the kernel is about to execute a monitored function, a callback function is invoked. For system calls, this invention always retrieves the system call parameters first within the callback function implemented by the kernel function execution monitoring module. One of the parameters of the callback function is `pt_regs`, which stores the state of the registers when the kernel function is called. The value of the `rdi` register, i.e., the kernel function parameters, is parsed from this value. Since the first parameter of the `__x64_sys_(syscallname)` kernel function is `pt_regs`, the system call parameter values ​​can be further obtained. The FTrace mechanism passes the address of the private structure pointed to by `ftrace_ops` as a parameter to the callback function. Therefore, the callback function can access the contents of the private structure. The private structure stores the system call parameters that need to be checked. The callback function can directly access the private structure, retrieve the parameters that need to be verified from the structure, and compare them. If they are the same, an alarm message is generated.

[0058] Module 3, the logging module, runs at the kernel level. First, a miscellaneous device is registered, and then functions for reading files need to be implemented. Logs are stored in a queue data structure implemented as a log linked list. Each time the intrusion detection system generates an alarm or message, it sends it to the logging module as a string. This module creates a node and adds it to the tail of the linked list. When the user layer reads this miscellaneous device file, it takes the head node of the linked list, copies the information stored therein to a user-space specified buffer, and releases the memory after the copy is complete.

[0059] Module 4, the vulnerability management client, runs at the user level. Its main function is to provide users with management rules for vulnerability detection. The vulnerability management client interacts with kernel modules in kernel mode via IOCTL system calls; different IOCTL codes are required for different operations. Users can add, delete, modify, and query vulnerability information through the vulnerability management client. For adding and modifying vulnerabilities, relevant information such as the vulnerability name and the system call parameters to be checked is required. For deleting vulnerabilities, the user needs to provide the vulnerability name. For querying vulnerabilities, the user should first check the number of installed vulnerability information, allocate the corresponding amount of memory space based on the number, and pass the corresponding cache address to kernel mode.

[0060] Module 5, the remote alarm system, runs at the user level. This module reads device files, obtains logs, and then forwards the logs to a remote server. The remote server can collect information or issue remote control commands.

[0061] The operation of a complete system includes the following steps:

[0062] Step 1, Initialization Phase. After loading the kernel modules, initialization occurs first. This includes the following sub-steps: registering miscellaneous devices for the logging module, obtaining the addresses of key functions for the kernel function execution monitoring module, and initializing IOCTL. To monitor system calls, the address of the system call table in the kernel needs to be obtained. Because...

[0063] Since `kallsyms_lookup_name` is not exported, its base address needs to be obtained first. The specific method is as follows: register a `kprobe` structure for the `kallsyms_lookup_name` function, obtain the base address in the function's kernel from the `kprobe` structure, and then obtain the address of the system call table through that address.

[0064] Step 2: User Management of Vulnerability Information. Users manage vulnerability information through the vulnerability management client mentioned above. Exploiting some vulnerabilities requires executing specific system calls with specific parameters. Based on this, a system call signature is generated for the vulnerability and passed to the system. The user constructs such a structure and passes it to the vulnerability management module in kernel mode.

[0065] Step 3, Critical Function Monitoring. When the system is compromised, exploitation attempts will occur. During the exploitation process, critical system calls will be made. When the exploitation process makes a system call, the registered callback function will be executed. The callback function will retrieve information such as the call parameters and the process's running status, and determine whether the parameters are characteristic values. If so, an alarm message will be generated and passed to the logging module in string form.

[0066] Step 4, Alarm Handling. The remote alarm system reads log information from the device file and transmits it to the remote control system. This completes a full alarm process.

[0067] In summary, this invention can monitor the execution of sensitive kernel functions, monitor system calls and their parameters, generate alarm information when sensitive system call parameters are detected, and add or modify detection rules at any time.

[0068] Although the specific details, implementation algorithms, and accompanying drawings of the present invention have been disclosed for illustrative purposes to aid in understanding and implementing the invention, those skilled in the art will understand that various substitutions, variations, and modifications are possible without departing from the spirit and scope of the invention and the appended claims. The invention should not be limited to the content disclosed in the preferred embodiments and accompanying drawings; the scope of protection claimed by the invention is defined by the claims.

Claims

1. A lightweight attack detection method for container host platforms, characterized in that, The method comprises: obtaining a monitored function and vulnerability information to be monitored; creating a corresponding vulner_info structure of the vulnerability information according to the name of the vulnerability information; wherein the data in the vulner_info structure includes the name of the vulnerability information, a system call number, system call parameters of the vulnerability information, the number of the system call parameters, a mask, and the address of a corresponding fops_node structure created, the mask saves the to-be-checked items of the system call parameters, the data in the fops_node structure includes the name of the monitored function and the address of a ftrace_ops structure, the ftrace_ops structure encapsulates a private structure, and the data in the private structure includes the system call parameters to be checked based on the mask and the system call parameters; when the kernel is about to execute the monitored function, a callback function is called to make the callback function obtain the system call parameter values generated in the execution process of the monitored function, including: obtaining the parameter pt_regs of the callback function, wherein the parameter pt_regs saves the state of the register when the kernel function is called; based on the parameter pt_regs, the value of the rdi register is parsed, wherein the value of the rdi register corresponds to the parameter of the kernel function; in the case that the kernel function is a __x64_sys_(sycallname) kernel function, the system call parameter value is obtained according to the parameter pt_regs of the __x64_sys_(sycallname) kernel function; the address of the private structure is passed to the callback function to make the callback function access the private structure to obtain the system call parameters to be checked; the system call parameter values are compared with the system call parameters to be checked to obtain the attack detection result of the monitored function.

2. The method of claim 1, wherein, The method comprises: according to the name of the vulnerability information, searching for the vulner_info structure of the name of the vulnerability information in the nodes of a vulnerability linked list; wherein each node is a vulner_info structure, and the vulnerability linked list is composed of at least one node; in the case that the vulner_info structure corresponding to the vulnerability information is found, the vulner_info structure is set in the monitoring system for the container host platform; in the case that the vulner_info structure corresponding to the vulnerability information is not found, a vulner_info structure is created based on the vulnerability information, the vulner_info structure is added to the vulnerability linked list, and the vulner_info structure is set in the monitoring system for the container host platform.

3. The method of claim 1, wherein, The comparing the system call parameter value with the system call parameter to be checked to obtain the attack detection result of the monitored function further comprises: registering a miscellaneous device in the container-oriented host platform, and implementing a read file operation function; in the case of a function attack, converting an alarm information or a message into a string based on the attack detection result, and adding the string to the tail of a log linked list; wherein the log linked list is created when initialized; when reading the miscellaneous device file, using the read file operation function to remove the head node of the log linked list, and copying information saved in the head node to a designated buffer to obtain a log.

4. The method of claim 3, wherein, The method further comprises: sending the log to a remote server; the remote server collects information or issues a remote control instruction based on the log.

5. The method of claim 1, wherein, The method further comprises: managing the vulnerability information to be monitored based on a vulnerability management client; wherein the management of the vulnerability information to be monitored based on the vulnerability management client comprises: selecting an IOCTL code based on an operation type; wherein the operation type comprises: an addition operation, a modification operation, a deletion operation, and a query operation; interacting information through an IOCTL system according to the selected IOCTL code; wherein the information of the addition operation and the modification operation comprises: the name of the vulnerability information, a system call number, the system call parameter of the vulnerability information, the number of the system call parameters, and a mask, the information of the deletion operation comprises: the name of the vulnerability information, and the information of the query operation comprises: the number of installed vulnerability information.

6. A storage medium having stored therein a computer program, wherein, The computer program is configured to execute the method of any one of claims 1-5 when running.

7. An electronic device, comprising: The computer program is configured to execute the method of any one of claims 1-5 when running. The computer program is configured to execute the method of any one of claims 1-5 when running.

Images