Intrusion prevention method, management unit, system and storage medium

Through the LSM-BPF technology that loads BPF bytecode in the kernel, the problem that intrusion detection technology cannot block attacks and high operation and maintenance management costs are solved, and efficient security control is achieved in heterogeneous environments.

CN120238322APending Publication Date: 2025-07-01ZTE CORP
View PDF 0 Cites 5 Cited by

Patent Information

Application Number
CN202311847947.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-12-28
Publication Date
2025-07-01

AI Technical Summary

Technical Problem

The existing intrusion detection technology is difficult to achieve immediate blocking of attacks, has a high misjudgment rate, and is costly to deploy and operate and maintain management in heterogeneous environments, so it is unable to adapt to differentiated cyber attack scenarios.

Method used

The LSM-BPF technology is used to load the target BPF bytecode in the kernel, monitor the kernel behavior in real time, block attacks in real time through the Linux security module, and provide unified security control policies, which are suitable for various heterogeneous environments.

Benefits of technology

Realize instant attack blocking, reduce the misjudgment rate, improve the convenience of deployment and maintenance, and adapt to the needs of heterogeneous environments.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120238322A_ABST
    Figure CN120238322A_ABST
Patent Text Reader

Abstract

The invention provides an intrusion prevention method, a management unit, a system and a storage medium, and relates to the field of network security, and the method comprises the steps: collecting context operation data corresponding to a to-be-tracked asset object in a kernel, and carrying out the security management of the context operation data, and obtaining a first target security control strategy corresponding to the to-be-tracked asset object; and mounting a first target BPF byte code corresponding to the first target security control strategy in a Linux security module so as to monitor and defend the target asset object through the Linux security module. Or in response to the security policy configuration request, extracting a second target security control policy from the security policy configuration request; and when the second target security control strategy is activated, mounting a second target BPF byte code corresponding to the second target security control strategy in the Linux security module. Therefore, through the above intrusion prevention method, the embodiment of the invention can immediately block attacks and improve the convenience of maintenance and deployment.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments of the present application relate to, but are not limited to, the field of network security, and in particular, to an intrusion prevention method, a management unit, a system, and a storage medium. Background Art

[0002] With the wide application of cloud computing and virtualization technologies, the increasingly complex structure of distributed systems such as data centers and telecommunications network elements, and the emergence of various new network attack methods, higher requirements are put forward for intrusion detection technologies, including a lower attack misjudgment rate, a faster response speed, and less risk loss. However, in related technologies, most intrusion detection technologies are based on post-event risk mitigation, unable to immediately block attacks and adapt to different environments. Therefore, there is an urgent need for an intrusion prevention method that can immediately block attacks and improve the convenience of maintenance and deployment. Summary of the Invention

[0003] The following is an overview of the subject matter described in detail in this document. This overview is not intended to limit the scope of protection of the claims.

[0004] The embodiments of the present application provide an intrusion prevention method, a management unit, a system, and a storage medium, which can immediately block attacks and improve the convenience of maintenance and deployment.

[0005] In a first aspect, an intrusion prevention method according to an embodiment of the present application includes:

[0006] Collect the context running data corresponding to the asset object to be tracked in the kernel, and perform security management on the context running data to obtain the first target security control policy corresponding to the asset object to be tracked;

[0007] Mount the first target BPF bytecode corresponding to the first target security control policy in the Linux security module to monitor and defend the target asset object through the Linux security module.

[0008] In a second aspect, an intrusion prevention method according to an embodiment of the present application includes:

[0009] In response to a security policy configuration request, extract the second target security control policy from the security policy configuration request;

[0010] Perform policy verification on the second target security control policy to determine whether there is a conflict with the security control policy recorded in a preset storage location;

[0011] When the policy verification passes, save the second target security control policy in the storage location;

[0012] When the second target security control policy is activated, mount the second target BPF bytecode corresponding to the second target security control policy in the Linux security module.

[0013] In a third aspect, an embodiment of the present application further provides an intrusion prevention management unit, including:

[0014] One or more processors;

[0015] A memory storing one or more programs, which when executed by the one or more processors cause the one or more processors to implement:

[0016] The intrusion prevention method according to any one of the first aspects;

[0017] Or,

[0018] The intrusion prevention method according to any one of the second aspects.

[0019] In a fourth aspect, an embodiment of the present application further provides an intrusion prevention management system, including:

[0020] A kernel;

[0021] An intrusion prevention management unit, which monitors and defends the target asset object by executing the method described in the first aspect or the second aspect;

[0022] A management platform, which is used to interact with the intrusion prevention management unit to maintain and manage the intrusion prevention management unit.

[0023] In a fifth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements:

[0024] The intrusion prevention method according to any one of the first aspects;

[0025] Or,

[0026] The intrusion prevention method according to any one of the second aspects.

[0027] In the embodiment of the present application, the target BPF bytecode is loaded through the Linux security module to monitor the behavior of the kernel in real time in the kernel, and then the application behavior can be blocked in time. At the same time, since the target BPF bytecode is applied to the kernel and is independent of the form of the defense load, and the target security control policy is a security control policy at the user side. Therefore, in actual deployment, only the adaptation of the target security control policy at the user level under different platforms needs to be considered, and the deployment and maintenance are simpler. Therefore, compared with the related technologies, the embodiment of the present application can block attacks in time and improve the convenience of maintenance and deployment. Description of the Drawings

[0028] Figure 1 is a typical deployment view of an intrusion detection system (IDS) in the related art;

[0029] Figure 2 is a block diagram of a module of an embodiment of the intrusion prevention management system according to an embodiment of the present application;

[0030] Figure 3 is a block diagram of a module of another embodiment of the intrusion prevention management system according to an embodiment of the present application;

[0031] Figure 4 is a schematic diagram of a scenario where the intrusion prevention method according to an embodiment of the present application is applied;

[0032] Figure 5 is a schematic flowchart of a self-learning scenario of an embodiment of the intrusion prevention method according to an embodiment of the present application;

[0033] Figure 6 is a partial flowchart of step S100 of an embodiment of the intrusion prevention method according to an embodiment of the present application;

[0034] Figure 7 is a schematic diagram of an asset model and access from the perspective of the kernel of the kernel where the intrusion prevention method according to an embodiment of the present application is applied;

[0035] Figure 8 is a schematic diagram of a data structure corresponding to a security management rule of an embodiment of the intrusion prevention method according to an embodiment of the present application;

[0036] Figure 9 is a schematic flowchart of an execution process after a BPF bytecode is mounted on a Linux security module in an embodiment of the intrusion prevention method according to an embodiment of the present application;

[0037] Figure 10 is a schematic diagram of an embodiment of active defense in the intrusion prevention method according to an embodiment of the present application;

[0038] Figure 11 is a schematic flowchart in a configuration scenario of an embodiment of the intrusion prevention method according to an embodiment of the present application;

[0039] Figure 12 is a schematic flowchart of a configuration process of an embodiment of the intrusion prevention method according to an embodiment of the present application;

[0040] Figure 13 is a schematic flowchart of activation and deactivation operations of the intrusion prevention method according to an embodiment of the present application;

[0041] Figure 14 is a schematic block diagram of the hardware structure of the intrusion prevention method according to an embodiment of the present application. Detailed implementation manners

[0042] In order to make the objectives, technical solutions and advantages of the present application more clear and understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0043] It should be noted that although functional modules are divided in the device schematic diagram and the logical sequence is shown in the flowchart, in some cases, the steps shown or described may be executed in a different module division in the device or a different sequence in the flowchart. Terms such as "first" and "second" in the specification, claims and the above-mentioned drawings are used to distinguish similar objects and do not necessarily need to describe a specific order or sequence.

[0044] The flowchart shown in the drawings is only an exemplary illustration, and does not necessarily include all contents and operations / steps, nor does it necessarily need to be executed in the described sequence. For example, some operations / steps can be decomposed, while some operations / steps can be combined or partially combined. Therefore, the actual execution sequence may change according to the actual situation.

[0045] The following is an explanation of the Chinese and English interpretations of technical terms in the embodiments of the present application:

[0046]

[0047]

[0048] It should be understood that with the wide application of cloud computing and virtualization technologies, and the increasing complexity of distributed system architectures such as data centers and telecom network elements, as well as the emergence of various new network attack methods, the industry has put forward higher requirements for intrusion detection technologies, including lower attack misjudgment rates, faster response speeds, and less risk losses. For example, Figure 1 taking the typical deployment view of an intrusion detection system (IDS) in the related technologies as an example, the IDS has the following deficiencies:

[0049] 1. Most mainstream IDSs are mostly based on ex-post risk mitigation and it is difficult to achieve ex-ante prevention and immunity: When the IDS system detects a workload (such as Figure 1When attacks such as workload 1, workload 2, and workload 3 occur in the system, generally, an alarm is first triggered and reported, then manually strictly judged and confirmed, and then risk mitigation measures such as blocking ports, clearing files, and killing processes are taken. Although these measures can be coordinated with SOAR technology to achieve automated response to a certain extent through playbook orchestration, in essence, it is still an after-the-fact remedy approach, which is difficult to recover losses and cannot reduce the occurrence frequency of subsequent security incidents. Since the attack + mitigation method is a flawed processing method, it cannot meet the requirements of many security-critical scenarios, including industrial control scenarios, sensitive pooled data centers, etc.

[0050] 2. Mainstream IDSs determine attacks based on static features and do not consider the runtime security context, resulting in a high false positive rate: Most of the existing mainstream IDS detection technologies are determined by auditing the user plane according to static features and network protocol patterns refined from historical data of known attack types. It is an empirical analysis model that does not comprehensively judge by combining target assets and the runtime security environment, resulting in a high false positive rate.

[0051] 3. Mainstream IDS systems are difficult to adapt to differentiated environments, and the deployment and operation and maintenance management costs are high. Taking the telecommunications system as an example, with the application of cloud computing and virtualization technologies, there will be a situation where systems with very different forms, including virtual machines, containers, k8s, bare metal, etc., coexist for a long time (as Figure 1 shown, in some embodiments, workload 1 can be a virtual machine; workload 2 can be a container). And systems with different forms have different asset management and operation control methods. That is to say, the technical means to be adopted for network attack detection and defense may be different and there are various forms, which will bring great troubles to the integration, operation and maintenance, and management of IDS products and target systems.

[0052] 4. Risk mitigation means are complex and lack a unified security control capability. Traditional risk mitigation and response cover various control means from the application layer to the operating system layer, including killing processes, manually modifying the routing table, alarm prompting for manual processing, etc., which are difficult to classify uniformly. Moreover, for the response and mitigation of the same attack, the solutions of different IDS vendors are not the same, which greatly increases the user's usage cost. Therefore, how to normalize the security control capability, extract the general security control atomic capabilities applicable to various heterogeneous environments, and develop security control policies unified based on this capability baseline, so as to reduce the system complexity and user usage cost, is also an urgent problem to be solved.

[0053] Among them, in application control scenarios in the field of network security such as single-domain security of the core network, enhanced security of campuses and data centers, and various TOB industrial control security scenarios, the problems of post-event risk mitigation and deployment and operation and maintenance management costs are particularly prominent. Therefore, there is an urgent need for an intrusion prevention method that can block attacks while improving the convenience of deployment and maintenance. Based on this, the embodiments of the present application provide an intrusion prevention method, management unit, system, and storage medium, which can block attacks immediately and improve the convenience of maintenance and deployment.

[0054] It can be understood that, as Figure 2 and Figure 3 shown, an intrusion prevention management system provided by an embodiment of the present application includes:

[0055] A kernel 100;

[0056] An intrusion prevention management unit 200, which monitors and defends a target asset object through an intrusion prevention method;

[0057] A management platform 300, which is used to interact with the intrusion prevention management unit to maintain and manage the intrusion prevention management unit 200;

[0058] Among them, in some embodiments, the intrusion prevention method includes: collecting context operation data corresponding to an asset object to be tracked in the kernel, and performing security management on the context operation data to obtain a first target security control policy corresponding to the asset object to be tracked; mounting the first target BPF bytecode corresponding to the first target security control policy in the Linux security module to monitor and defend the target asset object through the Linux security module.

[0059] Among them, in other embodiments, the intrusion prevention method includes: in response to a security policy configuration request, extracting a second target security control policy from the security policy configuration request; performing policy verification on the second target security control policy to determine whether it conflicts with the security control policy recorded in a preset storage location; when the policy verification passes, saving the second target security control policy in the storage location; when the second target security control policy is activated, mounting the second target BPF bytecode corresponding to the second target security control policy in the Linux security module.

[0060] Therefore, the target BPF bytecode is loaded through the Linux security module to monitor the behavior of the kernel in real time in the kernel 100, so as to realize the timely blocking of application behavior. At the same time, since the target BPF bytecode is applied to the kernel 100 and has nothing to do with the form of the defense load, while the target security control policy is a security control policy at the user side. Therefore, during actual deployment, only the adaptation of the target security control policy at the user level under different platforms needs to be considered, and the deployment and maintenance are simpler. Therefore, compared with related technologies, the embodiments of the present application can instantaneously block attacks and improve the convenience of maintenance and deployment.

[0061] It should be understood that both the first target security control policy and the second target security control policy are security control policies at the user side.

[0062] It should be understood that LSM (Linux Security Modules) is a framework in the Linux kernel for supporting various computer security models. LSM has preset a batch of hook points (i.e., hook functions) on the critical path related to Linux kernel security, thus realizing the decoupling of the kernel 100 and the intrusion prevention management unit 200, enabling different security control policies in the intrusion prevention management unit 200 to be freely loaded / unloaded in the kernel, and adding security check functions without modifying the original kernel 100 code. In the past, LSM was mainly used by configuring existing security modules (such as SELinux and AppArmor) or writing one's own kernel modules; after the LSM-BPF mechanism was introduced in Linux 5.7, the security control policy can be dynamically loaded to the LSM mount point in the kernel without configuring or writing kernel modules. Therefore, this ability to be non-intrusive to applications and achieve self-management and control of security context through the kernel is also called kernel introspection.

[0063] It should be understood that the flexible orchestration and dynamic loading of security control policies are realized by using the LSM-BPF technology, so that the security control policy can adapt to constantly changing attack means and at the same time has the immunity to attacks that occur again, solving the problem that traditional IDS can only handle risks out-of-band after the event and cannot actively defend.

[0064] It should be understood that since the Linux security module processes security from the perspective of the operating system (i.e., the kernel 100), and no matter which workload platform works on top of the system kernel 100; and the target asset object and the asset object to be tracked are both asset objects from the kernel perspective. Therefore, many upper-layer implementation differences can be shielded, making the security control policy closer to platformization and applicable to various heterogeneous workloads at the same time.

[0065] In summary, the present application uses the LSM-BPF technology to achieve kernel-level active defense, provides unified security control capabilities, eliminates the problem of poor adaptability of IDS to heterogeneous environments, and thus improves the convenience of deployment and maintenance.

[0066] It should be understood that the management platform 300 can be managed using an existing platform, which is an existing user-oriented security management and maintenance functional entity in the target environment. Its functions either belong to the management entities inherent in the target system, such as the management planes of IAAS and PAAS clusters themselves, the EMS system supporting telecom network elements, or are security management enhancement entities externally deployed by users in the target system, including but not limited to SIEM, SOAR, etc.

[0067] It should be understood that the kernel 100 can be an existing operating system kernel, and the kernel 100 is an entity of the corresponding existing kernel security execution subsystem, such as an operating system kernel supporting LSM-BPF on the workload (i.e., endpoint) where it is located, and is deployed on the same workload as the intrusion prevention management unit.

[0068] It should be understood that in some embodiments, the management platform 300 is responsible for providing functions such as asset management, security policy configuration, and security risk visualization. The intrusion prevention management unit interacts with the intrusion prevention management unit and covers the following functions:

[0069] ① Configuration management of security policies: Transmit the user-defined security control policies to the intrusion prevention management unit for subsequent execution of security filtering and control to manage the intrusion prevention management unit 200.

[0070] ② Alarm of security risks: When the intrusion prevention management unit detects an access request that violates the security policy during the running state of the kernel, the intrusion prevention management unit reports an alarm to the management platform. In some embodiments, the alarm information carries: the context of the violated access request and the specific user-level security control policy violated to maintain the intrusion prevention management unit 200.

[0071] It should be understood that the kernel 100 is responsible for implementing risk blocking and security filtering based on the LSM framework (i.e., Linux Security Module) in combination with the user's BPF bytecode. In some embodiments, the eBPF code of the user's intention is also mounted and executed at the hook position of the kernel 100 to implement security control and tracking of actual access behaviors, and based on the kernel's tracepoint and kprobe framework, in combination with the user's eBPF bytecode, data plane collection and continuous monitoring are completed.

[0072] It should be understood that as Figure 4As shown in the figure, the embodiments of the present application are applicable to the field of network security, and are used for intrusion detection and blocking in scenarios where network attack threats faced by distributed systems such as hosts, servers, and public clouds, private clouds, and hybrid cloud platforms are concerned. Among them, the specific workloads to be protected include but are not limited to physical machines, virtual machines, containers, etc. The operating system (kernel) of the workload must support the kernel security introspection function based on LSM-BPF. The intrusion prevention method of the present application can be used as an enhanced EDR program (Endpoint Detection and Response) and deployed in the workload. Among them, as Figure 4 shown, the infrastructure includes IAAS / PAAS / On-premise.

[0073] It can be understood that, as Figure 3 shown, in some embodiments, the intrusion prevention management unit 200 includes:

[0074] An interface adaptation module 210, which is used to communicate and adapt with the management platform 300;

[0075] A policy processing engine 220, which is used to execute the intrusion prevention method and interact with the management platform 300 through the interface adaptation module 210;

[0076] A policy storage module 230, which is used to store the security control policies processed by the policy processing engine 220 and the BPF bytecodes corresponding to the security control policies.

[0077] It should be understood that the interface adaptation module 210 is responsible for adapting various heterogeneous management platforms 300, shielding the policy processing engine 220 from its different policy configurations and alarm interface operations, and ensuring external interoperability. In some embodiments, a unified user policy model specification (such as security management rules) can be defined to ensure the consistency of policy semantics. And for various mainstream security management environments, corresponding forms of policy operation interfaces are provided, including but not limited to spec, restful api, command line, etc. For example, in the K8S environment, the user-defined security control policy is directly embedded in the k8sCRD as a part of the spec. When the policy configuration is issued, the interface adaptation module 210 needs to call the API interface provided by K8S to read the corresponding policy in the spec. Another example is that mainstream EDR / SOAR performs policy configuration through the restful api interface, and the interface adaptation module 210 also needs to respond to such external systems and implement security policy configuration through restful api calls.

[0078] It should be understood that the policy processing engine 220 is responsible for converting user-level security intentions into BPF bytecodes as needed, mounting them to the kernel for execution, and monitoring the kernel execution, so as to achieve security observation and security control. In some embodiments, the policy processing engine 220 has the following functions:

[0079] ① Self-learning of security control policies: In the deployment phase, the prefabricated BPF bytecodes for tracking are loaded into the Linux security module to take effect (such BPF bytecodes reflect the system assets and security context information concerned by users and are used to assist the self-learning of security control policies). Then, based on the context operation data fed back by the kernel, a security control policy based on the whitelist is generated.

[0080] ② Authorization of rules: The second target security control policy received from the interface adaptation module 210 is combined with the prefabricated "BPF control policy bytecode template" to instantiate the policy parameters, generate the instantiated security control policy code, and store it in the policy storage module 230 for later use.

[0081] ③ Implementation of security control: If the system enables the active defense function, that is, subscribes to relevant security capabilities, the BPF bytecodes corresponding to the security control policies in the policy storage module 230 are mounted to the LSM hook of the kernel 100 (corresponding to the Linux security module) according to the subscribed relevant information, driving the kernel 100 to execute security control.

[0082] ④ Monitoring of security risks: Receive the events captured by the kernel 100 that violate the security policy, associate the events that violate the security policy with the corresponding security control policies, and notify the interface adaptation module 210 to trigger an alarm to the management platform 300.

[0083] It should be understood that the policy storage module 230 is responsible for storing security control policies and the local storage of BPF bytecodes, and providing an access interface to the policy processing engine. In some embodiments, the data stored therein can be classified into the following types:

[0084] ① Security control policies: Such security control policies can be defined and configured by users and issued, or generated by the system through self-learning. They are described using the unified policy specification model of the present invention, reflecting the security intentions at the user level.

[0085] ②BPF control strategy bytecode template: This type of byte code needs to be prefabricated in advance. Corresponding to the "security control strategy metadata model", it is the embodiment of the BPF bytecode for policy model classification. Combining the type and specific parameters of the given security control strategy, the "BPF bytecode" can be instantiated. For example, for security policies of the network type, as long as the security control strategy provides specific connection five-tuple information, the "BPF control rule bytecode" that can be mounted and executed by the kernel 100 can be instantiated:

[0086] ③BPF bytecode: This type of byte code is converted from the security control strategy and has a corresponding relationship. In the system running state, it is mounted and takes effect on the LSM hook, and is used to intercept and filter access control requests according to the policy parameters and conditions in the security control strategy.

[0087] ④BPF tracing strategy bytecode: This type of tracing strategy bytecode needs to be prefabricated in advance and is used for tracing and policy self-learning. It reflects the user's security concerns about access to which types of assets. It is used in the initial deployment stage of the system to automatically learn and generate security control policies based on the whitelist by tracking and observing the actual security operating environment of the system. In some embodiments, the whitelist includes four types of whitelists: process list, file list, network connection five-tuple, and system call relationship. It will be mounted on kernel hooks of types such as tracepoint and kprobe.

[0088] It can be understood that, as shown in Figure 5 In the first aspect, according to an intrusion prevention method of an embodiment of the present application, the method includes the following steps:

[0089] Step S110, collect the context running data corresponding to the asset object to be traced in the kernel, and perform security management on the context running data to obtain the first target security control strategy corresponding to the asset object to be traced;

[0090] Step S120, mount the first target BPF bytecode corresponding to the first target security control strategy in the Linux security module, so as to monitor and defend the target asset object through the Linux security module.

[0091] Therefore, the first target BPF bytecode is loaded through the Linux security module to monitor the behavior of the kernel in real time in the kernel, and then the timely blocking of application behavior can be achieved. At the same time, since the first target BPF bytecode is applied to the kernel and is independent of the form of the defense load, while the first target security control policy is a security control policy for the user side. Therefore, during actual deployment, only the adaptation of the first target security control policy at the user level under different platforms needs to be considered, and the deployment and maintenance are simpler. Therefore, compared with related technologies, the embodiments of the present application can instantaneously block attacks and improve the convenience of maintenance and deployment.

[0092] It should be understood that obtaining the first target security control policy through the context operation data can achieve dynamic tracking of the system, improve the accuracy of detection, and reduce false alarms.

[0093] It should be understood that the collection of context operation data can be based on the existing ebpf framework or through a self-built framework. Regarding this, the embodiments of the present application will not elaborate too much.

[0094] It should be understood that in some embodiments, the first target security control policy can be selected through pre-arranged rules, or the first target security control policy can be determined in combination with the user's intention.

[0095] It can be understood that performing security management on the context operation data to obtain the first target security control policy corresponding to the asset object to be tracked includes:

[0096] Obtain the user's intention and security management rules;

[0097] According to the context operation data and security management rules, obtain the candidate security control policy corresponding to the asset object to be tracked;

[0098] Determine the first target security control policy from the candidate security control policies according to the user's intention.

[0099] It should be understood that the user's intention can be triggered by user configuration or pre-configured. The security management rules are used to make the context operation data form a unified format of the user-side policy. Key operation parameters can be extracted from the context operation data. For example, taking a process as an example, there will be the process's PID, path, etc. At this time, the operation parameters are cleaned, de-duplicated, and normalized to generate the black and white lists of the process in red font, so that the black and white lists can be converted into candidate security control policies for the user side through the security management rules.

[0100] It should be understood that some key data in the context operation data collected by the kernel can be self-learned to obtain the candidate security control policy. The user's intention determines which security control policies are actually used to be issued to the kernel.

[0101] It should be understood that in some embodiments, candidate security control policies are also saved so that they can be selectively activated and deactivated according to actual needs when used later.

[0102] It can be understood that before determining the first target security control policy from the candidate security control policies according to the user intention, the method further includes:

[0103] Obtain a preset BPF control policy bytecode template;

[0104] Perform BPF byte conversion on the candidate security control policies according to the BPF control policy bytecode template to obtain the first BPF bytecode corresponding to the candidate security control policies;

[0105] Store the first BPF bytecode in a preset storage location to match the first target BPF bytecode corresponding to the first target security control policy from the first BPF bytecodes recorded in the storage location.

[0106] It should be understood that by converting the first BPF bytecode in advance, it is possible to avoid real-time conversion when the first target security control policy is activated, and the response speed is faster.

[0107] Exemplarily, as Figure 6 shown, the specific steps of an embodiment of applying step S100 are as follows:

[0108] ① Read the "BPF control policy bytecode template" to generate specific rule bytecodes that can drive the kernel to perform filtering in combination with the instantiated policy parameter values.

[0109] ② The policy processing engine reads the prefabricated "tracking policy bytecode" from the policy storage module. The "tracking policy bytecode" is used for tracking and policy self-learning, reflecting the user's security concerns about access behaviors to which types of assets, as well as the tracking points and collection information that need to be set.

[0110] ③ The policy processing engine mounts the obtained tracking policy bytecode to the eBPF Core in the kernel to make the tracking effective.

[0111] ④ The eBPF Core of the kernel executes the tracking logic defined by the tracking policy bytecode according to the Hook mounted at the corresponding tracking point, monitors the asset objects to be tracked defined therein (such as processes, networks, files), and dynamically extracts their security context parameters. For example, for the discovered process-type assets, according to the metadata model definition, the process name and path, the parent process name and path can be discovered and extracted; for network-type assets, according to the metadata model definition, the five-tuple parameters of the network connection can be discovered and extracted.

[0112] ⑤The kernel reports the asset objects to be tracked and their tracking data (i.e., context running data) discovered to the policy processing engine. The reporting forms include but are not limited to logs, IPC message pipes, etc.

[0113] ⑥The policy processing engine receives the asset objects to be tracked and their context running data (including security attribute parameters and values) tracked and discovered by the kernel, cleans the context running data, matches the security management rules, and forms instantiated security control policy entries of the "whitelist type". For example, for network connection access, a security rule (Rule) is generated for each learned network connection five-tuple, and its filtering action (Action) is "allow".

[0114] ⑦The policy processing engine stores the candidate security control policies generated by self-learning in the policy storage module for subsequent authorized execution.

[0115] ⑧For the newly generated candidate security control policies, the policy processing engine combines the corresponding "BPF control policy bytecode template", generates the corresponding "first BPF bytecode" by providing specific values of the policy parameters therein, and establishes a mapping relationship between the candidate security control policies and the first BPF bytecode.

[0116] ⑨The above "first BPF bytecode" is stored in the policy storage module, and the mapping relationship between it and the candidate security control policies is recorded at the same time.

[0117] ⑩The policy processing engine reports the candidate security control policies generated by self-learning to the management platform through the management interface 1 via the interface adaptation module.

[0118] So far, the system has completed the automatic discovery and learning of security policies. The candidate security control policies are reviewed and edited through the management platform to determine which ones to retain and which ones to discard, and the first target security control policy is determined. At the same time, in some embodiments, the second target security control policy configured manually can also be combined to form a security policy baseline and activated for execution as needed.

[0119] It can be understood that the first target BPF bytecode is obtained through the following steps:

[0120] Obtain the first index information of the first target security control policy;

[0121] Search for the first BPF bytecode that matches the first index information in the first BPF bytecodes recorded in the storage location to obtain the first target BPF bytecode.

[0122] It should be understood that in some embodiments, when the candidate security control policy is uploaded, the relationship between the candidate security control policy and the first BPF bytecode has been established. Therefore, when the management platform selects the first target security control policy, the corresponding index information can be determined. At this time, the first index information of the first target security control policy can be directly sent down for configuration.

[0123] It should be understood that in some embodiments, there are security control policies configured in multiple scenarios. Therefore, after the first target security control policy is determined, the first index information can be cached to form a configuration baseline, so that after the security policy activation request is triggered, the first target BPF bytecode can be mounted in the Linux security module based on the first index information recorded in the configuration baseline. In some other embodiments, the first target control policy can be activated immediately, and the first target BPF bytecode can be found and mounted according to the first index information sent down by the management platform.

[0124] It can be understood that the candidate security control policy includes at least one of a candidate process control policy, a candidate file control policy, and a candidate network access control policy; the context running data includes at least one of process context data, network context data, and file context data; according to the context running data and security management rules, the candidate security control policy corresponding to the asset object to be tracked is obtained; at least including one of the following:

[0125] Performing a user intention conversion operation on the process context data according to the preset security management rules to obtain a candidate process control policy; wherein, the candidate process control policy includes a process security filtering condition and a process filtering action;

[0126] Or,

[0127] Performing a user intention conversion operation on the file context data according to the preset security management rules to obtain a candidate file control policy, and the candidate file control policy includes a file security filtering condition and a file filtering action;

[0128] Or,

[0129] Performing a user intention conversion operation on the network context data according to the preset security management rules to obtain a candidate network access control policy, wherein the candidate network access control policy includes a network security access filtering condition and a network behavior filtering action;

[0130] Among them, the process filtering action, the file filtering action, and the network behavior filtering action are all used to indicate the execution permission of the security control policy; the process security filtering condition, the file security filtering condition, and the network security access filtering condition are all used to indicate the defense behavior.

[0131] It should be understood that as Figure 7As shown, since any type of cyber attack is essentially achieved by accessing target assets (including processes, files (including I / O devices), network data, system calls) through programs running in the operating system environment. Therefore, by leveraging the capabilities of the kernel LSM, for Figure 7 the assets under its jurisdiction shown in

[0132] corresponding security control policies are written and mounted as needed, a unified kernel-level security control capability can be provided, which is both fast and efficient, and also solves the problem of complex risk mitigation means in traditional IDS.

[0133] It should be understood that those skilled in the art can selectively generate the required candidate security control policies according to actual needs, which can be one of the above, any combination of two or three methods. In this regard, the embodiments of the present application do not make any restrictions.

[0134] Exemplarily, if the security defense scenario only involves processes, then candidate process control policies are obtained after performing user intention conversion operations according to security management rules.

[0135] Exemplarily, if the security defense scenario only involves files, then candidate file control policies are obtained after performing user intention conversion operations according to security management rules.

[0136] Exemplarily, if the security defense scenario only involves processes and files, then candidate process control policies and candidate file control policies are obtained after performing user intention conversion operations according to security management rules.

[0137] Exemplarily, if the security defense scenario only involves processes and networks, then candidate process control policies and candidate network access control policies are obtained after performing user intention conversion operations according to security management rules.

[0138] Exemplarily, if the security defense scenario involves processes, files, and networks, then candidate process control policies, candidate file control policies, and candidate network access control policies are obtained after performing user intention conversion operations according to security management rules.

[0139] It should be understood that the security management rules can be set according to the Figure 8 data structure of the security model shown in Figure 8 For example, as shown in Figure 8 a yaml file with a unified template having the data structure shown is set. In this regard, those skilled in the art can selectively set it according to actual needs.

[0140] It is understandable that the execution permissions include permission to allow, permission to block, and permission to audit; the permission to allow means allowing the current access behavior, the permission to block means blocking the current access behavior, and the permission to audit means reporting the violation information of the current access behavior.

[0141] Exemplarily, as Figure 9 shown, taking a functional scenario of a Linux module executing the first target BPF bytecode as an example, where the system is in the working state, and for the access behaviors that occur in real time in the workload, pre-interception filtering is performed according to the loaded and effective security rules, and the violation behaviors that violate the security policy are processed. Prerequisites: The system has the runtime defense switch enabled, and the security policy has been authorized and activated; the specific steps are as follows:

[0142] ① When the access behavior actually occurring on the kernel of the workload triggers the execution of the kernel LSM-BPF hook and hits the security control policy in the LSM-BPF bytecode, it can be divided into three cases for processing according to the returned Action value: allow (Allow), block (Block), and audit (Audit). Among them, if it is "allow", the current access behavior is allowed to pass, and the processing ends.

[0143] ② If it is to block, the current access behavior is blocked, including but not limited to: killing the process, intercepting the network connection, restricting read and write access to files, etc., and then the processing ends.

[0144] ③ If it is "audit", a security violation message is constructed and the policy processing engine is notified. In some embodiments, the security violation message includes the violated rule ID and the information of the violated asset object. The policy processing engine receives the "security violation notice", maps it to the corresponding security control policy through the rule ID (i.e., the first index information) of the BPF bytecode, and constructs an alarm message, which is reported to the management platform through the interface adaptation module. In some embodiments, the alarm content includes: the security control policy identifier, the information of the target asset being violated (file name, process PID, network connection five-tuple, etc.). With this alarm, the user can understand the specific type of the attack that occurred and the asset object being attacked.

[0145] So far, through the BPF bytecode pre-mounted in the kernel LSM, the kernel can respond to attacks in advance as needed without the application being aware; for example, if the Action of the security rule is Block, the attack can be blocked in advance to avoid risk losses.

[0146] It is understandable that the process security filtering conditions include process parameters and regular expression enabling parameters; the file security filtering conditions include file parameters and regular expression enabling parameters; the network security access filtering conditions include network parameters and regular expression enabling parameters.

[0147] It should be understood that the process parameters are used to represent their call relationships. In some embodiments, the process parameters include the parent process path and name, and the current process path and name.

[0148] It should be understood that the file parameters are used to represent the attributes of a file. In some embodiments, the file parameters include the path, name, format, permissions, ownership, and parent directory.

[0149] It should be understood that the network parameters are used to represent network addresses. In some embodiments, the network parameters include the source and destination five-tuples.

[0150] It should be understood that the regular expression enable parameter is used to indicate whether regular expression filtering is supported. When regular expression filtering is supported, during the conversion of security management rules, if the regular expression is satisfied, extraction can be performed; otherwise, extraction of parameters for conversion must be done only in the case of exact matching.

[0151] It can be understood that the assets to be tracked include a first process, a first file, and network behaviors; collecting the context running data corresponding to the assets to be tracked in the kernel includes:

[0152] Performing context collection on the first process to obtain process context data, where the process context data includes at least one of the parent process parameters and the first process parameters of the first process;

[0153] Performing context collection on the first file to obtain file context data, where the file context data includes at least one of the file parameters such as the path, permissions, parent directory, and ownership;

[0154] Performing context collection on the network behavior to obtain network metadata, where the network metadata includes at least one of the network parameters such as the source address five-tuple and the destination address five-tuple.

[0155] It should be understood that the assets to be tracked can be composed of a first process, a first file, and network behaviors, or can be set to one of them. At this time, based on the process context data, a candidate process control policy can be obtained, based on the file context data, a candidate file control policy can be obtained, and based on the network metadata, a candidate network access control policy can be obtained.

[0156] It can be understood that the context running data is collected through the following steps:

[0157] Obtaining the BPF trace policy bytecode of the assets to be tracked;

[0158] Mounting the BPF trace policy bytecode in the corresponding extended Berkeley Packet Filter (eBPF) hook function in the kernel;

[0159] Collect context runtime data through eBPF hook functions.

[0160] It should be understood that eBPF (Extended Berkeley Packet Filter) is a powerful network and performance analysis tool widely used in the Linux kernel. eBPF enables developers to dynamically load, update, and run user-defined code without restarting the kernel or changing the kernel source code. This feature provides extremely high flexibility and performance, making eBPF widely applicable in network and system performance analysis.

[0161] It should be understood that the eBPF mechanism is adopted to enhance kernel security observability, improve the accuracy of perceiving the runtime security situation, and effectively reduce the false alarm rate. Specifically, the eBPF mechanism is used to collect runtime data for target asset objects at numerous tracing and probing points in the kernel, making the security context more deterministic and the data granularity smaller, which can not only improve the detection accuracy but also reduce false alarms.

[0162] Therefore, in the embodiments of the present application, various relevant metadata of the running environment are extracted, combined with the user's security intention, and converted into kernel-level security control rules according to a predefined security policy model, and are loaded and take effect in the kernel through the LSM-BPF mechanism, and the kernel LSM framework executes real-time and accurate multi-gating security control in the kernel running environment. The technical means used include security policy management and kernel-level security observability; among them, security policy management is used to support user-defined security policies, and through the observation of the runtime environment, automatically generate security policies, and support the conversion of user-level security intentions into kernel-level security control rules. Kernel-level security observability is used to effectively identify threats through eBPF-based kernel security observability technology.

[0163] Therefore, the combination of eBPF hook functions and the Linux security module can implement a closed-loop security control mechanism and proactive security defense. Among them, the closed-loop security control mechanism is driven by policies, and the entire process from attack detection to risk elimination can be automated, effectively reducing the cost of manual intervention. Proactive security defense is to uniformly execute security capabilities through the kernel LSM framework, block attacks in a timely manner, and avoid losses in advance.

[0164] Exemplarily, reference can be made to Figure 6 the process shown to obtain the candidate target security control policy in step S100; and after determining the first target security control policy based on the candidate target security control policy, refer to step S200 to mount the first target BPF bytecode of the first target security control policy on the Linux module, so that the Linux module can refer to Figure 9 the process shown to perform proactive security defense.

[0165] Exemplarily, such asFigure 10 As shown in the figure, taking the target asset object as a process as an example, when a process is executed, it will pass through multiple LSM hook functions. When the process hits one of the LSM hook functions and the corresponding filtering action is to block, it can be blocked through deny and the audit log is recorded.

[0166] Understandably, on the second aspect, as Figure 11 shown, according to an intrusion prevention method provided by an embodiment of the present application, the method includes the following steps:

[0167] Step S210, in response to a security policy configuration request, extract a second target security control policy from the security policy configuration request;

[0168] Step S220, perform policy verification on the second target security control policy to determine whether there is a conflict with the security control policy recorded in a preset storage location;

[0169] Step S230, when the policy verification passes, save the second target security control policy in the storage location;

[0170] Step S240, when the second target security control policy is activated, mount the second target BPF bytecode corresponding to the second target security control policy in the Linux security module.

[0171] Therefore, by loading the second target BPF bytecode through the Linux security module to monitor the behavior of the kernel in real time in the kernel, the timely blocking of application behavior can be realized. At the same time, since the second target BPF bytecode is applied to the kernel and has nothing to do with the form of the defense load, while the target security control policy is a security control policy at the user side. Therefore, during actual deployment, only the adaptation of the second target security control policy at the user level under different platforms needs to be considered, and the deployment and maintenance are simpler. Therefore, compared with the related technology, the embodiment of the present application can immediately block attacks and improve the convenience of maintenance and deployment.

[0172] It should be understood that the storage location corresponds to Figure 3 the policy storage module 230 shown in the figure.

[0173] It should be understood that saving the configured second target security control policy can directly operate on the second target security control policy in the storage location during subsequent processing.

[0174] Exemplarily, as Figure 12 shown, in some embodiments, when the system is normally started, the steps of manually configuring the security control policy are as follows:

[0175] ① According to Figure 8The policy structure shown defines the second target security control policy, and then through the management platform's distribution interface adaptation module. The interface adaptation module receives the message, extracts the second target security control policy with reference to step S210, and passes it to the policy processing engine module.

[0176] ② Referring to step S210, as Figure 12 shown, the policy processing engine module performs verification for each second target security control policy, and determines whether there are conflicting or duplicate entries in the policy storage module. If there is a conflict, discard the second target security control policy to be configured, end the processing, otherwise go to step ③.

[0177] ③ Referring to step S220, as Figure 12 shown, the policy processing engine module stores the second target security control policy in the policy storage module.

[0178] At this time, referring to step S240, when the second target security control policy is activated, then execute to mount the second target BPF bytecode in the Linux security module. At this time, the Linux security module can perform active defense with reference to Figure 6 shown.

[0179] It can be understood that in response to a security policy configuration request, the second target security control policy is extracted from the security policy configuration request, including:

[0180] Determine the interface type of the security policy configuration request;

[0181] According to the interface type, parse the configuration security policy parameters from the security policy configuration request;

[0182] According to the preset policy model, generate the second target security control policy corresponding to the configuration security policy parameters.

[0183] It should be understood that by determining the interface type of the management platform where the security policy configuration request comes from, the internal processing platform for security control policies is made, avoiding differences and improving the convenience of deployment.

[0184] It should be understood that for embodiments such as Figure 5 、 Figure 6 , when interacting with the management platform, it also needs to be adapted according to the interface type of the request source.

[0185] It can be understood that when the second target security control policy is activated, mounting the second target BPF bytecode corresponding to the second target security control policy in the Linux security module includes:

[0186] In response to a security policy activation request, parse the second index information of the second target security control policy from the security policy activation request;

[0187] Obtain a second target BPF bytecode that matches the second index information from the BPF bytecodes recorded in the storage location;

[0188] Mount the second target BPF bytecode in the Linux security module.

[0189] Therefore, by separating policy activation and configuration, security control policies for multiple channels can be processed in batches. By storing the second target BPF bytecode corresponding to the second target security control policy in the storage location before activation, an immediate response can be made during activation, resulting in higher processing efficiency.

[0190] It should be understood that the BPF bytecodes recorded in the storage location at least include the second target BPF bytecodes of the second target security control policy configured in the current instance. In some embodiments, the BPF bytecodes recorded in the storage location also include the second target BPF bytecodes corresponding to the second target security control policies configured manually in the past. In some embodiments, the BPF bytecodes recorded in the storage location also include the first BPF bytecodes corresponding to the candidate security control policies obtained through self-learning in step S100. In some embodiments, the BPF bytecodes recorded in the storage location also include preset BPF bytecodes (such as tracing policy bytecodes). In this regard, the embodiments of the present application do not impose any restrictions, and those skilled in the art can make selective restrictions according to actual needs.

[0191] Exemplarily, as Figure 13 shown, taking the activated security control policy as the second target security control policy as an example, the activation steps are as follows:

[0192] ① The user sends a security policy authorization activation request message to the interface adaptation module through the security management platform, which carries the authorized user policy number (i.e., the second index information). After the interface adaptation module verifies the legality, it passes the message to the policy processing engine.

[0193] ② The policy processing engine queries and obtains the corresponding "BPF control rule bytecode" from the policy storage module according to the second index information. If the query fails, the processing is directly terminated. If it is successful, it proceeds to step 003.

[0194] ③ The policy processing engine loads the corresponding second target BPF bytecode onto the corresponding Hook in the kernel LSM to take effect.

[0195] The kernel performs filtering control on the implementation access behavior according to the security control rule logic of the second target BPF bytecode.

[0196] It should be understood that candidate security control policies can be activated with reference to the activation steps of the second target security control policy. In this regard, the embodiments of the present application do not limit which specific security control policies are activated.

[0197] It can be understood that the method further includes:

[0198] In response to a security policy deactivation request, obtain a second BPF bytecode that matches the security policy deactivation request from the BPF bytecodes recorded in the storage location;

[0199] Unload the second BPF bytecode from the Linux security module.

[0200] Exemplarily, as Figure 13 shown, the security control policy deactivation process is as follows:

[0201] ④ The user sends a security policy authorization activation request message to the interface adaptation module through the security management subsystem, which carries the authorized user policy number. After the interface adaptation module verifies the legality, it passes the message to the policy processing engine (policy control and processing engine).

[0202] ⑤ The policy processing engine queries and obtains the corresponding "BPF control rule bytecode" from the policy storage module (policy storage module) according to the user policy ID. If the query fails, the processing ends directly. If it is successful, it proceeds to step 007.

[0203] ⑥ The policy processing engine unloads the corresponding security control rule bytecode from the corresponding Hook in the kernel LSM. The kernel thus customizes the filtering processing of the corresponding security rules.

[0204] It should be understood that if the deactivated one is the first target security control policy, the user policy number corresponds to the first index information. If the deactivated one is the second target security control policy, the user policy number corresponds to the second index information.

[0205] It should be understood that most of the current commercially available solutions in the industry are based on intrusion detection tools and log collection to generate risk alerts. These capabilities are plug-in. After detecting security risks, they are reported to the situation awareness system, which combines the running asset information for correlation analysis. Then, in combination with the work order processing flow and the security orchestration, automation, and response (SOAR) system, manual risk adjudication and extraction are carried out. Then, customized automation scripts are used to trigger security risk elimination actions. The security response is basically IP blocking, killing processes, deleting malicious files, or redirecting to a sandbox. This is a kind of operation and maintenance concept based on doing one's best after the event. Therefore, the current mainstream method in the industry is first of all a post-processing mechanism, which has a certain role in the IT domain. However, in the CT domain, when it comes to core assets and data centers, the workload often carries the business, and security mitigation methods such as IP blocking and killing processes cannot be executed, and risks cannot be eliminated, only the impact can be reduced. The CT domain requires a proactive defense mechanism more. At the same time, its risk collection and intrusion detection judgment are based on experience, and the risk elimination processing is two different technical implementations. Because unrelated security capabilities are adopted, the risk alerts and eliminations often cannot be coordinated, resulting in various mitigation methods for the alerts detected by intrusion detection. And after being processed once, it may recur next time. This leads to the situation that even if SOAR is deployed in actual operation and maintenance, only a small part of the blocks can be processed, and most cannot be processed in time.

[0206] In this application, the collection and processing of relevant security data in the running environment and the security response implementation method are unified on the kernel security enhancement technology stack. At the same time, by using the hook mechanisms of tracepoint, kprobe, and LSM, it is possible to quickly use authorization constraints to prevent recurrence before or after a risk occurs once. At the same time, because problems are discovered and processed in the kernel, the security service capabilities are also greatly enhanced. At the same time, the overall framework of the present invention is compatible with a variety of kernel security enhancement mechanisms. Because it works in the kernel mode, it is not restricted by the deployment platform and can be well compatible with a variety of workload forms.

[0207] In summary, this application supports adding an intrusion prevention unit in all Linux kernel system environments with the eBPF (extended Berkeley Packet Filter) function enabled. This unit controls and processes the coordination of the operating system kernel and user security intentions. After collecting the kernel running context data, it is converted into security control rules according to a predefined security policy model, and then the rules are dynamically loaded into the LSM mount point in the kernel through the LSM-BPF (Linux Security Module based on BPF) mechanism, driving the kernel security module to automatically execute the user's security control intentions. The entire inventive method includes three functions: trusted environment self-learning, security immunity, and risk control, which are jointly completed by the intrusion prevention unit as the security control plane processing entity, the operating system kernel as the security execution plane processing entity, and the management platform inherent in the target system. Among them, the intrusion prevention unit is deployed in the workload of the target system, and the operating system of the workload of the target system needs to have kernel introspection capabilities based on eBPF and LSM.

[0208] It can be understood that, referring to Figure 14 as shown, an embodiment of this application further provides an intrusion prevention management unit, including:

[0209] One or more processors 201;

[0210] A memory 202, on which one or more programs are stored. When the one or more programs are executed by the one or more processors 201, the one or more processors 201 are caused to implement:

[0211] The intrusion prevention method as described in the first aspect above or the intrusion prevention method as described in the second aspect above.

[0212] As a non-transitory network system, the memory 202 can be used to store non-transitory software programs and non-transitory computer-executable programs. In addition, the memory 202 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory 202 may optionally include a memory 202 remotely disposed relative to the processor 201, and these remote memories 202 may be connected to the processor 201 through a network. Examples of the above networks include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0213] The memory 202 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM), etc. The memory 202 can store an operating system and other application programs. When implementing the technical solutions provided in the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 202 and are called by the processor 201 to execute the methods of the embodiments of this application.

[0214] The processor 201 can be implemented in ways such as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0215] In some embodiments, the intrusion prevention management unit further includes:

[0216] An input / output interface for implementing information input and output;

[0217] A communication interface for implementing communication interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.);

[0218] A bus for transmitting information between various components of the device (such as the processor 201, the memory 202, the input / output interface, and the communication interface);

[0219] Among them, the processor 201, the memory 202, the input / output interface, and the communication interface can achieve communication connections with each other inside the device through the bus.

[0220] An embodiment of this application further provides a computer-readable storage medium storing computer-executable instructions, and the computer-executable instructions are used to execute and implement:

[0221] An intrusion prevention method as applied to the method in the above first aspect or second aspect.

[0222] An embodiment of this application further provides a computer program product including a computer program or computer instructions. The computer program or computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, so that the computer device executes and implements:

[0223] An intrusion prevention method applied to the method of the first or second aspect described above.

[0224] Therefore, the above embodiments of the present application have the following advantages:

[0225] (1) Solving the difficulties of security defense: In the related art, intrusion mitigation during operation generally involves directly logging in to the endpoint to operate on the intrusion object, such as killing a process or deleting sensitive files. In a cloudified and virtualized environment, there are numerous endpoints, making it difficult to maintain. At the same time, this method is likely to disrupt the normal operation of the system or business. In the present application, by leveraging the LSM BPF capabilities of the kernel, it can be blocked in a timely manner during operation without the need to restart the application or node. This flexibility is not available in traditional LSM or seccomp - like security modules.

[0226] (2) Achieving system security immunity and implementing security whitelists and blacklists for application behaviors: Through the observability of the security baseline, an allow - list can be constructed to specify which operations are allowed for the application and block all other operations, as well as timely risk blocking of the blacklist, eliminating the loss of security and trust due to the increase in entropy after a period of operation in a virtualized and cloudified environment. This defense in the minimum - privilege manner meets the requirements of zero - trust application isolation: Since the calls and functions throughout the entire lifecycle of the workload are visible, misconfigurations or overly permissive privileges in the workload can be highlighted. Compared with the defects in cloud and virtualization security where a large number of vulnerabilities can be exploited due to improper configurations, the present application obtains deterministic authorization by monitoring and obtaining metadata and converting it into a whitelist.

[0227] (3) Achieving automation of security response processing. By abstracting security control policies, automatically matching security control execution code and mounting it, the security risk mitigation ability can be reduced from hours to minutes.

[0228] The system architecture and application scenarios described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art know that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

[0229] Those of ordinary skill in the art will appreciate that all or some of the steps and systems disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium). As is well known to those of ordinary skill in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by a computer. In addition, it is well known to those of ordinary skill in the art that the communication medium typically includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and can include any information delivery medium.

[0230] Some embodiments of the present application have been described above with reference to the accompanying drawings. This is not intended to limit the scope of the present invention. Any modifications, equivalent replacements, and improvements made by those skilled in the art without departing from the scope and essence of the present invention shall fall within the scope of the claims of the present application.

Claims

1. An intrusion prevention method, the method comprising the following steps: Collect context running data corresponding to an asset object to be tracked in the kernel, and perform security management on the context running data to obtain a first target security control policy corresponding to the asset object to be tracked; Mount the first target BPF bytecode corresponding to the first target security control policy in the Linux security module to monitor and defend the target asset object through the Linux security module.

2. The method according to claim 1, characterized in that, Performing security management on the context running data to obtain a first target security control policy corresponding to the asset object to be tracked, including: Obtain user intent and security management rules; According to the context running data and security management rules, obtain a candidate security control policy corresponding to the asset object to be tracked; Determine a first target security control policy from the candidate security control policies according to the user intent.

3. The intrusion prevention method according to claim 2, characterized in that, Before determining the first target security control policy from the candidate security control policies according to the user intent, the method further includes: Obtain a preset BPF control policy bytecode template; According to the BPF control policy bytecode template, perform BPF byte conversion on the candidate security control policy to obtain a first BPF bytecode corresponding to the candidate security control policy; Store the first BPF bytecode in a preset storage location to match the first target BPF bytecode corresponding to the first target security control policy from the first BPF bytecodes recorded in the storage location.

4. The intrusion prevention method according to claim 3, characterized in that, The first target BPF bytecode is obtained through the following steps: Obtain first index information of the first target security control policy; Search for the first BPF bytecode that matches the first index information in the first BPF bytecodes recorded in the storage location to obtain the first target BPF bytecode.

5. The intrusion prevention method according to claim 2, characterized in that The candidate security control policy includes at least one of a candidate process control policy, a candidate file control policy, and a candidate network access control policy; the context running data includes at least one of process context data, network context data, and file context data; obtaining the candidate security control policy corresponding to the asset object to be tracked according to the context running data and security management rules; at least includes one of the following: Perform a user intent conversion operation on the process context data according to a preset security management rule to obtain a candidate process control policy; wherein, the candidate process control policy includes a process security filtering condition and a process filtering action; Or, Perform a user intent conversion operation on the file context data according to a preset security management rule to obtain a candidate file control policy, and the candidate file control policy includes a file security filtering condition and a file filtering action; Or, Perform a user intent conversion operation on the network context data according to a preset security management rule to obtain a candidate network access control policy, wherein the candidate network access control policy includes a network security access filtering condition and a network behavior filtering action; Among them, the process filtering action, the file filtering action, and the network behavior filtering action are all used to indicate the execution permissions of the security control policy; the process security filtering condition, the file security filtering condition, and the network security access filtering condition are all used to indicate the defense behavior.

6. The intrusion prevention method according to claim 5, characterized in that, The execution permissions include permission to allow, permission to block, and permission to audit; the permission to allow means releasing the current access behavior, the permission to block means blocking the current access behavior, and the permission to audit means reporting the violation information of the current access behavior.

7. The intrusion prevention method according to claim 5, characterized in that The process security filtering condition includes process parameters and a regular expression enabling parameter; the file security filtering condition includes file parameters and a regular expression enabling parameter; the network security access filtering condition includes network parameters and a regular expression enabling parameter.

8. The intrusion prevention method according to claim 1, characterized in that, The asset object to be tracked includes a first process, a first file, and network behavior. Collecting the context running data corresponding to the asset object to be tracked in the collection kernel includes: Performing context collection on the first process to obtain process context data, where the process context data includes at least one of the parent process parameters and the first process parameters of the first process. Performing context collection on the first file to obtain file context data, where the file context data includes at least one of the path, permissions, parent directory, and ownership of the file. Performing context collection on the network behavior to obtain network metadata, where the network metadata includes at least one of the source address five-tuple and the destination address five-tuple of the network parameters.

9. The method according to claim 1, characterized in that, The context running data is collected through the following steps: Obtaining the BPF tracing policy bytecode of the asset object to be tracked. Mounting the BPF tracing policy bytecode in the corresponding extended Berkeley Packet Filter (ebpf) hook function in the kernel. Collecting the context running data through the ebpf hook function.

10. An intrusion prevention method, the method includes the following steps: In response to a security policy configuration request, extracting a second target security control policy from the security policy configuration request. Performing policy verification on the second target security control policy to determine whether there is a conflict with the security control policy recorded in a preset storage location. When the policy verification passes, saving the second target security control policy in the storage location. When the second target security control policy is activated, mounting the second target BPF bytecode corresponding to the second target security control policy in the Linux security module.

11. The intrusion prevention method according to claim 10, characterized in that, The step of, in response to a security policy configuration request, extracting a second target security control policy from the security policy configuration request includes: Determining the interface type of the security policy configuration request. According to the interface type, parsing the configured security policy parameters from the security policy configuration request. Generating a second target security control policy corresponding to the configured security policy parameters according to a preset policy model.

12. The intrusion prevention method according to claim 10, wherein The step of, when the second target security control policy is activated, mounting the second target BPF bytecode corresponding to the second target security control policy in the Linux security module includes: In response to a security policy activation request, second index information of the second target security control policy is parsed from the security policy activation request; Second target BPF bytecode that matches the second index information is obtained from the BPF bytecode recorded in the storage location; The second target BPF bytecode is mounted in the Linux security module.

13. The intrusion prevention method according to claim 10, wherein The method further includes: In response to a security policy deactivation request, second BPF bytecode that matches the security policy deactivation request is obtained from the BPF bytecode recorded in the storage location; The second BPF bytecode is unmounted from the Linux security module.

14. An intrusion prevention management unit, comprising: One or more processors; A memory having stored thereon one or more programs, which when executed by the one or more processors cause the one or more processors to implement: The intrusion prevention method according to any one of claims 1-9; or, The intrusion prevention method according to any one of claims 10-13.

15. An intrusion prevention management system, comprising: A kernel; An intrusion prevention management unit, which performs monitoring and defense processing on a target asset object by executing the method according to claim 1 or 10; A management platform, which is used to interact with the intrusion prevention management unit to maintain and manage the intrusion prevention management unit.

16. The intrusion prevention management system according to claim 15, wherein The intrusion prevention management unit includes: An interface adaptation module, which is used to perform communication adaptation with the management platform; A policy processing engine, which is used to execute the method according to claim 1 or 10 and interact with the management platform through the interface adaptation module; A policy storage module, which is used to store the security control policy processed by the policy processing engine and the BPF bytecode corresponding to the security control policy.

17. A computer-readable storage medium having stored thereon a computer program, which when executed by a processor implements: The intrusion prevention method according to any one of claims 1-9; Or, The intrusion prevention method according to any one of claims 10-13.

Citation Information

Cited By

  • Server-free dynamic management and control method based on extended Berkley packet filter

    CN120750627A

  • TCP connection filtering method and device, equipment and storage medium

    CN121887460A

  • A TCP connection filtering method, device, equipment and storage medium

    CN121887460B

  • Security detection method, security loading method, device, storage medium and program product

    CN121902141A

  • Security detection method, security loading method, device, storage medium, and program product

    CN121902141B