Network traffic multi-level security protection model, system, method, equipment and medium

Abstract

The invention provides a network flow multi-level security protection model, system, method, equipment and medium. According to the method, a plurality of modularized atomization protection points are constructed through a predefined eBPF program library, and network control capabilities such as matching, speed limiting and state observation are realized. In a system initialization stage, a data plane architecture comprising a plurality of kernel execution layer dispatcher programs is constructed, and persistence of the programs and resource Map is realized through pin operation. The declarative network security policy is received through the SDK module, the policy control module analyzes the declarative network security policy to generate a configuration parameter, and the user mode module loads an eBPF program according to the configuration parameter and mounts the eBPF program to a kernel execution layer. The network flow triggers a protection point according to a path and outputs observation data; and the state aggregation sub-module aggregates the data according to the strategy and feeds information back to the upper-layer application. Therefore, flexible deployment of protection points and strategy dynamic driving can be realized, and the method has good expandability and response capability.

Description

Technical Field

[0001] This invention relates to the field of network traffic security protection technology, and in particular to a multi-layered network traffic security protection model, system, method, device and medium. Background Technology

[0002] With the development of technologies such as cloud computing, containerization, microservices, and edge computing, the complexity of modern network systems is constantly increasing, and the forms of security threats are becoming increasingly diverse. Traditional network security protection solutions often rely on single-point devices or fixed topology deployments, such as firewalls, intrusion detection systems (IDS), or proxy-based gateways. These methods suffer from problems such as rigid deployment, coarse-grained policies, high resource overhead, and poor observability in dynamically changing network environments, making it difficult to meet the high performance, security, and maintainability requirements of cloud-native and distributed architectures.

[0003] To address these issues, kernel-level network security protection methods based on eBPF (extended Berkeley Packet Filter) technology have emerged in recent years. eBPF allows programs to be dynamically loaded into the operating system kernel, enabling fine-grained observation and control of system behavior without compromising kernel stability. eBPF-based network protection schemes can deploy network policy logic at multiple kernel hook points, achieving characteristics such as low latency, high customizability, and real-time feedback, and are gradually becoming an important component of modern network security architectures.

[0004] However, current eBPF network security practices generally suffer from the following shortcomings: (1) lack of a unified policy modeling language, high coupling between policy configuration and loading logic, and insufficient flexibility; (2) difficulty in forming a unified data plane architecture among multiple kernel execution layers (such as LSM, XDP, TC, Cgroup); (3) lack of modularization mechanism for protection logic, which is not conducive to combination and reuse; (4) separation of observation and control links, and lack of policy closed-loop capability.

[0005] Therefore, there is an urgent need for a multi-layered network traffic security architecture with declarative policies, layered execution, modular protection points, and observable states to adapt to the dynamic security protection needs of new network environments. Summary of the Invention

[0006] This invention provides a multi-layered network traffic security protection model, system, method, device, and medium to solve the technical problems in the prior art, such as inflexible network security policy deployment, coarse-grained protection measures, high coupling of execution environment, and lack of state observation and policy closed-loop capabilities.

[0007] In a first aspect, the present invention provides a multi-layered network traffic security protection model, comprising:

[0008] The Socket layer includes an LSM decision-maker deployed at the BPF LSM Hook location, which performs access control during the system call intent phase based on the principal attributes of the process and Cgroup.

[0009] The network driver layer includes an XDP distributor deployed at the XDP Hook location, which is used to intervene and preprocess the traffic when the network driver receives raw data frames.

[0010] The network protocol stack layer includes a TC Ingress dispatcher deployed at the TC Ingress Hook location, a Cgroup Egress dispatcher deployed at the Cgroup Egress Hook location, and a TCEgress dispatcher deployed at the TC Egress Hook location. The TC Ingress dispatcher, Cgroup Egress dispatcher, and TC Egress dispatcher are respectively used to execute stateful network security policies that require deep packet inspection.

[0011] Secondly, the present invention provides a multi-layered network traffic security protection system, comprising: a policy control module, an SDK module, a user-mode policy execution module, and a kernel-mode data processing module;

[0012] The policy control module is used to receive and parse the declarative network security policies issued by the upper layer, and generate configuration parameters corresponding to the declarative network security policies;

[0013] The SDK module is used to issue declarative security policies, to actively query the current status and statistics of the system, and to subscribe to security events and performance metrics in real time.

[0014] The user-mode policy execution module is used to load and unload eBPF programs according to the policy configuration parameters, manage eBPF resources, maintain configuration status, and send control parameters to the kernel-mode data processing module.

[0015] The kernel-mode data processing module includes an LSM decision program deployed at the BPF LSM Hook location, an XDP dispatcher deployed at the XDPHook location, a TC Ingress dispatcher deployed at the TC Ingress Hook location, a Cgroup Egress dispatcher deployed at the CgroupEgress Hook location, and a TC Egress dispatcher deployed at the TC Egress Hook location.

[0016] Furthermore, the kernel-mode data processing module receives the control parameters issued by the user-mode policy execution module through a Map structure, and feeds back the network traffic status and event information to the user mode through a RingBuffer or Map.

[0017] Furthermore, the policy control module includes a policy parsing submodule and a policy generation submodule;

[0018] The policy parsing submodule is used to parse the received declarative network security policy text into recognizable policy elements;

[0019] The policy generation submodule generates configuration parameters corresponding to the policy based on the parsing results and passes them to the user-space policy execution module.

[0020] Furthermore, the SDK module includes a policy distribution interface, a system status query interface, and a security event subscription interface;

[0021] The policy delivery interface is used to transmit the security policy delivered by the user terminal to the user-mode policy execution module.

[0022] The system status query interface is used to query the current working status of the system;

[0023] The security event subscription interface is used to transmit security events or performance metrics generated by the system to the user end.

[0024] Thirdly, this invention provides a multi-layered network traffic security protection method, the method comprising:

[0025] S1. By predefining a set of eBPF program libraries, multiple atomic protection points are constructed. The atomic protection points are modularly designed so that each atomic protection point has at least one network management capability among matching, rate limiting or state observation.

[0026] S2. During the system initialization phase, the user-space policy execution module constructs a persistent data plane architecture. The data plane architecture includes dispatcher programs deployed in multiple kernel execution layers. Each kernel execution layer corresponds to multiple kernel hook points, including but not limited to BPF LSM, XDP, TC Ingress, and Cgroup Egress. The user-space policy execution module constructs an independent program array Map for each kernel execution layer to support pipeline configuration, and performs pin operations on the corresponding eBPF program and Map through the BPF file system to achieve persistence.

[0027] S3. The SDK module receives the declarative network security policy submitted by the upper-layer application and sends the declarative network security policy to the policy control module, which parses the policy and generates corresponding configuration parameters.

[0028] S4. The configuration parameters are processed by the user-space policy execution module. The user-space policy execution module loads or unloads the corresponding eBPF program based on the configuration parameters, creates the required resource Map, and mounts the protection point program to the corresponding kernel execution layer according to the execution layer preference information set in the declarative network security policy or the target kernel execution layer automatically inferred by the system.

[0029] S5. During network traffic processing, network traffic passes through the protection pipeline deployed on each kernel execution layer from the inlet to the outlet. The distributor program calls the corresponding atomic protection point program according to the preset logic, executes the matching, rate limiting or observation logic defined in the declarative network security policy, and writes the processing result into the data class Map associated with the protection point.

[0030] S6. The state aggregation submodule in the user-mode policy execution module pulls raw event data from the data class Map and performs aggregation processing based on the observation points defined in the declarative network security policy to generate structured observation intelligence, and feeds it back to the upper-layer application through the SDK module.

[0031] S7. The upper-layer application dynamically adjusts the declarative network security policy based on the feedback observation results, and reissues the updated policy through the SDK module to achieve closed-loop optimization and continuous response of the policy.

[0032] Furthermore, step S1 includes:

[0033] The atomic protection points include host access control protection points for supporting eBPF LSM, network inbound protection points for supporting XDP, link-layer flow control protection points for supporting TC Ingress, and container outbound flow observation protection points for supporting CgroupEgress.

[0034] Furthermore, step S6 includes:

[0035] The state aggregation submodule aggregates the raw event data from multiple atomic protection points according to time windows to generate a structured observation event summary. The observation event summary is identified according to the observation point name defined in the declarative network security policy and fed back to the upper layer application through the SDK module.

[0036] Fourthly, the present invention provides an apparatus comprising: a processor, and a memory communicatively connected to the processor;

[0037] The memory stores computer-executed instructions;

[0038] When the processor executes the computer execution instructions stored in the memory, it is used to implement the multi-layered network traffic security protection method of the third aspect of the invention.

[0039] Fifthly, the present invention provides a medium in which computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the network traffic multi-layer security protection method of the third aspect of the invention.

[0040] This invention provides a multi-layered network traffic security protection model, system, method, device, and medium. The method constructs modular, atomic protection points and deploys distributor programs across multiple kernel execution layers, achieving layered processing and policy-driven management of network traffic at different kernel hook points. Combined with the dynamic distribution and parsing of declarative network security policies, it enhances the flexibility and automation of policy configuration. Furthermore, by integrating a state aggregation submodule to aggregate and feedback observation data, a complete policy closed-loop optimization mechanism is formed. This results in advantages such as strong policy-driven capabilities, flexible execution paths, strong observation capabilities, and high response efficiency, effectively improving dynamic security protection capabilities in network environments. Attached Figure Description

[0041] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0042] Figure 1 This is a schematic diagram of the multi-layered network traffic security protection system provided in Embodiment 2 of the present invention;

[0043] Figure 2 This is a flowchart illustrating the multi-layered network traffic security protection method provided in Embodiment 3 of the present invention;

[0044] Figure 3 This is a schematic diagram of the architecture of the core components of the multi-layered network traffic security protection system provided in Embodiment 4 of the present invention;

[0045] Figure 4 This is a schematic diagram of the device hardware provided in Embodiment 5 of the present invention. Detailed Implementation

[0046] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0047] First, the terms used in this invention will be explained:

[0048] eBPF: Short for Extended Berkeley Packet Filter. It's a technology for running sandboxed programs within the Linux kernel and forms the core technological foundation of this invention.

[0049] SDK stands for Software Development Kit. In this invention, it refers to a unified API interface library provided by upper-layer applications for interaction.

[0050] API stands for Application Programming Interface.

[0051] LSM: The full name of LSM is Linux Security Modules, a kernel security framework. BPF LSM is its programmable modern extension.

[0052] XDP: The full name of the English word is eXpress Data Path, a high-performance eBPF hook point at the network driver layer.

[0053] TC stands for Traffic Control, a network subsystem in the Linux kernel that provides a rich set of eBPF protocol stack hooks.

[0054] YAML: YAML Ain't Markup Language is a human-readable data serialization language used to define the declarative strategy of this invention.

[0055] FD: File Descriptor, in Linux, is used to represent handles to kernel objects such as eBPF programs and Maps.

[0056] PID: Process ID.

[0057] Protection Surface: The highest-level, user-facing logical policy unit. It defines the target (Selector) to be protected and the bidirectional protection rule chain applied to that target through a declarative configuration. In this invention, its role is for upper-layer applications to express their complete security objective intent by defining the "Protection Surface".

[0058] Protection chain / pipeline: In the kernel, a linear processing logic composed of multiple protection points combined in a specific order. It is dynamically defined and orchestrated by the prog_array Map at runtime. In this invention, it serves as the specific execution path for implementing complex, multi-step security policies.

[0059] Protection Point: The most basic, atomic unit of network management and control capabilities. It is a reusable, configurable eBPF program that implements a basic function (such as IP filtering). In this invention, it serves as a "building block" for constructing a chain of protection and is the smallest unit for providing security capabilities.

[0060] Entry Dispatcher: A lightweight eBPF program statically deployed on critical kernel hook points. Its sole responsibility is to direct traffic into the dynamic protection pipeline via tail calls; in this invention, it acts as a static entry point, bridging traffic from fixed kernel hook points to dynamically changing protection logic.

[0061] Tail Call: An eBPF mechanism that allows one eBPF program to completely transfer execution control to another eBPF program; in this invention, it serves as the core technology for "chaining" multiple independent protection point programs together to form a protection chain.

[0062] Object Pinning: Pinning eBPF objects (such as programs and Maps) in the kernel to a file path on the BPF file system, decoupling their lifecycle from the creation process; in this invention, it serves to achieve high availability without interruption of kernel-mode policies when the control plane is restarted or upgraded.

[0063] Full-path layered defense model: The core architectural concept of this invention. By uniformly using eBPF, a collaborative defense-in-depth system is built at the Socket control layer, network driver layer, and network protocol stack layer. In this invention, it defines the deployment layers and working logic of the invention's security capabilities, achieving an optimized balance between performance and functionality.

[0064] Metadata-driven deployment: an automated deployment method. Each protection point is accompanied by a set of "self-describing" metadata, and the control plane parses this metadata to automatically complete all configuration and deployment tasks. In this invention, it enables the system to achieve scalability and maintainability, allowing new capabilities to be added without modifying the core management logic.

[0065] Atomic protection points: In the process of network security protection, atomic protection points refer to the modularization of protection functions, allowing each protection point to focus on performing a specific network security operation (such as traffic matching, traffic rate limiting, state monitoring, etc.). Atomic protection points are designed as independent modules with clearly defined functions, and can be flexibly deployed and configured.

[0066] The eBPF library (extended Berkeley Packet Filter) is a predefined collection of programs used to dynamically load into the operating system kernel to monitor and control network traffic. eBPF technology allows efficient and secure programs to execute within the kernel without modifying the kernel code, supporting flexible network security policies.

[0067] Kernel execution layers: Kernel execution layers refer to the different hook points within the kernel that are used to load and execute protection programs. Each kernel execution layer is associated with a specific operating system kernel hook point (such as BPF LSM, XDP, TC, Cgroup, etc.) and is used to handle different stages of network traffic. These execution layers trigger protection point programs according to predetermined logic during network traffic processing.

[0068] Distributor Program: The distributor program is a program deployed on the kernel execution layer, responsible for receiving network traffic and distributing it to different protection points for processing according to predetermined logic. Based on the characteristics of the network traffic, the distributor determines the type of operation to perform (such as matching, rate limiting, observation, etc.) and feeds back the processing results to subsequent programs.

[0069] BPF LSM: BPF LSM (Linux Security Module) is a kernel hook used to implement security policies. LSMs extend kernel security modules using BPF technology, enabling fine-grained access control, especially at the process and cgroup levels. The role of BPF LSM is to control system calls based on the principal attributes of processes and cgroups.

[0070] Declarative network security policies: Declarative network security policies are a way to describe network security requirements using policy text. Users define network traffic processing rules through a declarative language without specifying concrete execution steps. The system automatically generates and executes corresponding security policies based on these declarative rules.

[0071] User-space policy execution module: This module, deployed in user space, is responsible for generating corresponding configuration parameters based on declarative network security policies issued from the upper layer, and controlling the loading, unloading, and resource management of eBPF programs. This module handles communication between the system kernel layer and the user layer.

[0072] State Aggregation Submodule: This submodule is part of the user-space policy execution module. It is responsible for collecting raw event data from different protection points (such as BPF LSM, XDP, etc.) and aggregating it according to a preset time window to generate structured observation intelligence. The aggregated data can be used to feed back to upper-layer applications to support dynamic adjustments to network security policies.

[0073] Map structure: The Map structure is a container in eBPF used for storing and sharing data. Guardpoint programs use the Map structure to store network traffic status and event information. The Map structure enables efficient data exchange between the kernel and user space, and ensures system persistence and consistency.

[0074] RingBuffer: A RingBuffer is a data structure used for efficient storage and transmission of traffic event data. During network traffic processing, RingBuffer is used to buffer and forward event information, ensuring that data is not lost.

[0075] With the rapid development of information technology, especially the widespread application of technologies such as cloud computing, containerization, and microservices, the dynamism, complexity, and scale of the network environment have reached unprecedented levels. At the same time, network attack methods are becoming increasingly diversified, automated, and intelligent, posing a severe challenge to the inherent network security protection capabilities of operating systems. Existing network security solutions, in addressing these challenges, mainly suffer from one or more of the following shortcomings:

[0076] 1. Traditional kernel protocol stack-based filtering technologies (such as Netfilter / iptables) have performance and scalability bottlenecks.

[0077] Netfilter / iptables, a classic packet filtering framework in the Linux kernel, is mature and widely used. However, its linear matching mechanism based on rule chains suffers from drastic performance degradation under heavy traffic or with a large number of rules, becoming a system bottleneck. Furthermore, its rule definition and management methods are relatively low-level, making efficient integration with modern dynamic policies based on application identity and context difficult. Adding new protocol parsing or matching logic typically requires developing new kernel modules, resulting in insufficient scalability and agility.

[0078] 2. Kernel bypass technologies (such as DPDK) sacrifice system integration and ease of use.

[0079] In pursuit of ultimate performance, kernel bypass technologies like DPDK handle network packets entirely in user space, bypassing the performance overhead of the kernel. However, this approach also brings significant drawbacks: it completely detaches itself from the operating system's kernel ecosystem, making it impossible to utilize the rich context information provided by the kernel (such as Cgroups, namespaces, and socket information), and hindering the implementation of fine-grained security policies tied to containers or specific applications. Furthermore, it requires exclusive CPU cores and hardware resources, making deployment and maintenance complex, and unsuitable as a general-purpose, intrinsic operating system security capability.

[0080] 3. Existing eBPF security applications have limitations and are one-sided.

[0081] While eBPF (Extended Berkeley Packet Filter) technology makes it possible to implement programmable network processing in the kernel, most current security solutions based on eBPF have certain limitations:

[0082] Functionality limitation: Many solutions only utilize a specific mount point of eBPF (such as using only XDP for DDoS protection or only TC for traffic control), failing to integrate the capabilities of eBPF at different kernel levels and lacking in-depth defense.

[0083] Strong coupling between strategy and code: The logic of eBPF programs is usually pre-compiled, and changes to the strategy often require recompiling and loading the program, failing to achieve true runtime dynamic programmability.

[0084] Lack of a unified management and observation plane: Different eBPF application scenarios (such as networking, security, and observation) may require different toolchains and management methods. There is a lack of a unified, policy-oriented control plane to orchestrate and manage eBPF programs deployed on the kernel full path.

[0085] 4. Lack of a unified, two-way, full-path protection model.

[0086] Existing technologies often exhibit asymmetrical control over inbound and outbound traffic, or focus only on the network packets themselves while neglecting the source of network behavior—the system call intent. This makes it impossible to build a unified security protection system that covers the entire lifecycle from "application intent" to "network cable." For example, the ability to efficiently intercept malicious connection behavior at the system call level usually requires technologies such as LSM (Linux Security Module), which are separate from network filtering frameworks, making management and policy coordination difficult.

[0087] In conclusion, there is an urgent need for a new type of network security technology solution that can be deeply integrated into the operating system kernel, uniformly utilize modern kernel technologies such as eBPF, and build a unified security infrastructure that is high-performance, finely detailed, dynamically programmable, and covers the entire bidirectional traffic path to address the security challenges of modern complex network environments.

[0088] Based on this, embodiments of the present invention provide a multi-layered network traffic security protection model, system, method, device, and medium to solve the aforementioned technical problems.

[0089] Example 1

[0090] Embodiment 1 of the present invention provides a multi-layered network traffic security protection model, including:

[0091] The Socket layer includes an LSM decision-maker deployed at the BPF LSM Hook location. The LSM decision-maker is used to perform access control during the system call intent phase based on the principal attributes of the process and Cgroup.

[0092] The network driver layer includes an XDP distributor deployed at the XDP Hook location. The XDP distributor is used to intervene and preprocess the traffic when the network driver receives raw data frames.

[0093] The network protocol stack layer includes a TC Ingress dispatcher deployed at the TC Ingress Hook location, a Cgroup Egress dispatcher deployed at the Cgroup Egress Hook location, and a TCEgress dispatcher deployed at the TC Egress Hook location. The TC Ingress dispatcher, Cgroup Egress dispatcher, and TC Egress dispatcher are used to execute stateful network security policies that require deep packet inspection.

[0094] For example, the multi-layered network traffic security protection model provided by this invention can efficiently cope with complex and ever-changing network security threats by deploying multiple protection mechanisms at different layers. Specifically, by deploying protection points with dedicated functions at multiple layers such as the Socket layer, network driver layer, and network protocol stack layer, each protection layer can perform fine-grained control and processing for specific network traffic.

[0095] (1) Flexible and fine-grained traffic processing: By deploying protection programs at different kernel hook points (such as BPF LSM, XDP, TC), customized processing can be performed for different types of traffic. The Socket layer implements access control based on process and Cgroup attributes through the LSM decision program to ensure the security of system calls; the network driver layer quickly intercepts and preprocesses traffic through the XDP dispatcher, improving traffic processing efficiency and security; and the network protocol stack layer performs deep packet inspection through the TC Ingress and Cgroup Egress dispatchers, achieving a higher level of security protection.

[0096] (2) Multi-level security protection: This model effectively solves the problem that a single protection mechanism cannot cover all aspects through the design of layered protection. Different protection points work independently and cooperate with each other, avoiding security protection gaps and enabling multi-dimensional analysis and processing of traffic.

[0097] (3) Efficient data flow and response mechanism: Because the deployment of the distributor program can quickly intervene and execute the predetermined security policy when it receives network traffic, it avoids the traffic delay problem that may exist in traditional protection schemes. In addition, the modular design of multiple protection points makes the system highly scalable and can be flexibly configured and expanded according to different scenario requirements.

[0098] (4) Enhanced security and maintainability: By modularizing network traffic processing into layers, each layer's protection points can be independently optimized and maintained, which not only improves system security but also simplifies operation, maintenance, and upgrade processes. Each protection point can be updated or replaced according to real-time needs, enhancing the flexibility of the entire network protection system.

[0099] Therefore, the multi-layered network traffic security protection model of the present invention can provide an efficient, secure, and scalable network protection mechanism, adapt to different types of network security threats, and ensure the stability and security of system operation.

[0100] Example 2

[0101] Figure 1 This is a schematic diagram of the multi-layered network traffic security protection system provided in Embodiment 2 of the present invention, as shown below. Figure 1As shown, the network traffic multi-layer security protection system 100 provided in Embodiment 2 of the present invention includes: a policy control module 110, an SDK module 120, a user-mode policy execution module 130, and a kernel-mode data processing module 140.

[0102] The policy control module 110 receives and parses declarative network security policies issued from the upper layer, generating configuration parameters corresponding to the declarative network security policies. The policy control module 110 includes a policy parsing submodule and a policy generation submodule. The policy parsing submodule parses the received declarative network security policy text into identifiable policy elements. The policy generation submodule generates configuration parameters corresponding to the policy based on the parsing results and passes them to the user-space policy execution module. Specifically, the policy control module 110, through the built-in policy parsing submodule and policy generation submodule working together, can automatically parse declarative security policy text into structured policy elements, and then convert them into specific executable configuration parameters. This mechanism achieves a seamless transformation of policies from "human-readable" to "system-executable," effectively lowering the policy deployment threshold and improving the correctness and consistency of policy generation.

[0103] SDK module 120 is used to issue declarative security policies, proactively query the system's current status and statistics, and subscribe to security events and performance metrics in real time. The SDK module includes a policy issuance interface, a system status query interface, and a security event subscription interface. The policy issuance interface transmits security policies issued by the user to the user-space policy execution module. The system status query interface queries the system's current operating status. The security event subscription interface transmits security events or performance metrics generated by the system to the user. Specifically, the SDK module not only provides a policy issuance channel but also exposes system status query and security event subscription interfaces, supporting upper-layer applications to monitor the system's operating status in real time and dynamically perceive threat changes. Through a combination of proactive retrieval and passive subscription, this module supports high-frequency, low-latency policy updates, achieving a high degree of adaptability between protection policies and the runtime environment.

[0104] The user-mode policy execution module 130 is used to load and unload eBPF programs according to policy configuration parameters, manage eBPF resources, maintain configuration status, and send control parameters to the kernel-mode data processing module. Specifically, the user-mode policy execution module 130 is responsible for automatically loading and unloading eBPF programs, creating or releasing Map resources, and maintaining the current policy configuration status according to configuration parameters. In particular, the user-mode policy execution module 130 can automatically infer the program mount point based on the target Hook type (such as XDP or TCIngress) set by the policy, which simplifies the complexity of kernel resource management and improves the consistency and correctness of policy deployment.

[0105] The kernel-level data processing module 140 includes an LSM decision program deployed at the BPF LSM hook location, an XDP dispatcher deployed at the XDP hook location, a TC Ingress dispatcher deployed at the TC Ingress hook location, a Cgroup Egress dispatcher deployed at the Cgroup Egress hook location, and a TCEgress dispatcher deployed at the TC Egress hook location. Specifically, the kernel-level data processing module 140 integrates multiple eBPF dispatchers and decision programs, deployed at hook points such as BPF LSM, XDP, TC Ingress, Cgroup Egress, and TC Egress. These hook points cover multiple network paths from process calls to packet entry, protocol stack forwarding, and container exit. Each dispatcher organizes atomic protection points in a pipelined manner, supporting deep packet inspection, stateful flow processing, and container-level flow control, thus constructing a full-path, fine-grained security management system.

[0106] For example, the policy execution logic and data path of the multi-layered network traffic security protection system 100 are decoupled. The program arrays of each kernel execution layer are persisted through eBPF file system pin operations, supporting on-demand mounting and hot updates. When new network threat models or policy requirements emerge, new atomic protection points can be dynamically deployed without restarting the system or interrupting business flow, thereby enhancing the system's long-term evolvability and ability to cope with unknown threats.

[0107] Furthermore, kernel-mode programs upload observation data to user-mode via Map or RingBuffer. The state aggregation submodule in the user-mode policy execution module 130 can aggregate and format the data according to the observation points defined in the policy, and feed it back to the upper layer through the SDK module 120. This mechanism provides real-time and reliable visual intelligence support for the upper-layer security operation system, supports state-aware automatic policy optimization, and builds a technical closed loop for automatic policy evolution.

[0108] In some implementations, the kernel-mode data processing module 140 receives control parameters from the user-mode policy execution module 130 via a Map structure, and feeds back network traffic status and event information to user space via RingBuffer or Map. The Map structure is a data storage mechanism provided in eBPF (Extended Berkeley Packet Filter), enabling information sharing between the kernel and user space. Maps can store various types of data, such as network traffic status, event logs, and counters. During operation, the kernel-mode data processing module 140 receives control parameters from the user-mode policy execution module 130 via the Map structure. These control parameters may include security policies, traffic processing rules, or configured network traffic policies. The Map structure allows kernel-mode programs to quickly access these control parameters to perform network traffic processing tasks. Meanwhile, the results processed by the kernel-mode program, such as status information or event data, can also be stored in a Map structure for easy subsequent reading and analysis. RingBuffer is another important memory structure in eBPF, which is used to efficiently cache and transmit traffic data or event information. In this system, the kernel-mode data processing module uses RingBuffer to feed back network traffic status, event information, etc. to the user-mode policy execution module. This data may include real-time network traffic analysis results, security event logs, anomaly detection information, etc.

[0109] Regarding the data flow process: First, from user space to kernel space: The user-space policy execution module 130 first sends control parameters to the kernel-space data processing module 140 by configuring a Map structure. These control parameters may be firewall rules, traffic matching conditions, or other security policies. Second, kernel-space processing and feedback: The kernel-space data processing module 140 processes, analyzes, and protects network traffic based on the control parameters sent from user space. The processed network traffic status, event information, etc., are stored in a Map structure or a RingBuffer. Finally, from kernel space to user space: The user-space policy execution module 130 obtains the latest traffic status and security event data by accessing the Map or RingBuffer. This data can be used to dynamically adjust security policies, generate visualized security reports, or trigger automated responses.

[0110] Example 3

[0111] Figure 2 This is a flowchart illustrating the multi-layered network traffic security protection method provided in Embodiment 3 of the present invention, as shown below. Figure 2 As shown, the method includes:

[0112] S1. By predefining a set of eBPF program libraries, multiple atomic protection points are constructed. The atomic protection points are modularly designed so that each atomic protection point has at least one network management capability among matching, rate limiting or state observation.

[0113] Specifically, in step S1, since the atomic protection points adopt a modular design and are functionally divided into multiple eBPF programs with matching, rate limiting or state observation capabilities, they can provide highly configurable capabilities for subsequent policy combination and protection logic, which is conducive to improving the flexibility and scalability of network security policies and realizing fine-grained, multi-functional network traffic security control.

[0114] S2. During the system initialization phase, the user-space policy execution module constructs a persistent data plane architecture. The data plane architecture includes dispatcher programs deployed in multiple kernel execution layers. Each kernel execution layer corresponds to multiple kernel hook points, including but not limited to BPF LSM, XDP, TC Ingress, and Cgroup Egress. The user-space policy execution module constructs an independent program array Map for each kernel execution layer to support pipeline configuration and performs pin operations on the corresponding eBPF program and Map through the BPF file system to achieve persistence.

[0115] Specifically, in step S2, by deploying the dispatcher program at multiple kernel hook points and building a program array Map to support pipeline configuration, and by achieving persistence through pin operations, the continuity and stability of the protection logic during system restart or operation can be ensured, which is conducive to the deployment of continuous security policies across layers and hooks.

[0116] S3. Receive the declarative network security policy submitted by the upper-layer application through the SDK module, and send the declarative network security policy to the policy control module, which will parse the policy and generate the corresponding configuration parameters.

[0117] Specifically, in step S3, the upper-layer declarative network security policy is received through the SDK module and parsed into configuration parameters. This enables the decoupling of policy and execution, making policy configuration more flexible and automated, which is conducive to supporting dynamic and on-demand network security policy configuration.

[0118] S4. The configuration parameters are handed over to the user-space policy execution module for processing. The user-space policy execution module loads or unloads the corresponding eBPF program based on the configuration parameters, creates the required resource Map, and mounts the protection point program to the corresponding kernel execution layer according to the execution layer preference information set in the declarative network security policy or the target kernel execution layer automatically inferred by the system.

[0119] Specifically, in step S4, by dynamically loading / unloading eBPF programs according to configuration parameters and combining the execution layer preferences in the policy or automatic inference by the system to mount them, it is possible to achieve fine-grained management and flexible scheduling of eBPF programs, which is conducive to improving the adaptability of network traffic processing policies and resource utilization efficiency.

[0120] S5. During network traffic processing, network traffic passes through the protection pipeline deployed on each kernel execution layer from the inlet to the outlet. The distributor program calls the corresponding atomic protection point program according to the preset logic, executes the matching, rate limiting or observation logic defined in the declarative network security policy, and writes the processing result into the data class Map associated with the protection point.

[0121] Specifically, in step S5, network traffic is processed sequentially along the protection pipeline deployed in multiple kernel execution layers, and the dispatcher program calls atomic protection points to perform operations according to the policy. This ensures that traffic is handled by multi-level policies at multiple stages, which helps to improve the coverage depth and accuracy of overall network security protection.

[0122] S6. The state aggregation submodule in the user-mode policy execution module pulls raw event data from the data class Map according to the observation points defined in the declarative network security policy, performs aggregation processing, generates structured observation intelligence, and feeds it back to the upper layer application through the SDK module.

[0123] Specifically, in step S6, by pulling data based on observation points and generating structured observation intelligence to feed back to the upper layer, the upper layer application can grasp the effect of strategy execution and network status in real time, which is beneficial to the accuracy of strategy adjustment and the observability of the system.

[0124] S7. The upper-layer application dynamically adjusts the declarative network security policy based on the feedback observation results, and redeploys the updated policy through the SDK module to achieve closed-loop policy optimization and continuous response.

[0125] Specifically, in step S7, the policy update mechanism driven by observation results, combined with the policy delivery capability of the SDK module, enables continuous policy optimization and dynamic response, which is conducive to building an adaptive network security protection system.

[0126] The multi-layered network traffic security protection method provided by this invention constructs modular atomic protection points and achieves collaborative protection between kernel and user modes based on eBPF technology, forming a complete policy closed-loop optimization system. Specifically, this method first constructs atomic protection points with single functions such as matching, rate limiting, or state observation through a predefined eBPF program library. During the system initialization phase, a persistent data plane architecture covering multiple kernel hook points such as BPF LSM, XDP, TC Ingress, and Cgroup Egress is established. Then, through the reception and parsing of declarative policies, the dynamic loading and precise mounting of policy parameters to specific eBPF programs are achieved. During network traffic processing, a layered policy execution is achieved through a multi-kernel execution layer protection pipeline, and the processing results are transformed into structured observation intelligence through a state aggregation module and fed back to the upper layer, ultimately driving continuous optimization and updating of the policies. This approach achieves three core benefits through four key technical features: modular design, multi-kernel hook point collaboration, declarative policy-driven approach, and observation-feedback closed loop. First, the modular design and multi-kernel layer deployment of atomic protection points significantly improve the flexibility and execution efficiency of the protection system. Second, the use of declarative policies and automated resolution mechanisms greatly reduces the complexity of policy configuration and improves the accuracy and consistency of policy deployment. Third, through state observation and feedback closed loop, an adaptive network security protection system is constructed, enabling the system to continuously optimize and dynamically respond to evolving network threats. The overall solution ensures high performance while achieving refined, intelligent, and adaptive network security protection.

[0127] In some implementations, atomic protection points include host access control protection points for supporting eBPF LSM, network inbound protection points for supporting XDP, link-layer flow control protection points for supporting TC Ingress, and container outbound flow observation protection points for supporting Cgroup Egress.

[0128] Specifically, the atomic protection points include four core protection points: a host access control protection point for eBPF LSM to implement security management of system calls; a network inbound protection point for XDP to provide early packet filtering capabilities; a link-layer flow control protection point for TC Ingress to achieve fine-grained traffic shaping; and a container outbound flow observation protection point for Cgroup Egress specifically for container environment traffic monitoring. First, by customizing protection functions for the characteristics of different kernel hook points, each protection point can maximize its effectiveness at its optimal execution level. Second, it covers the complete protection chain from the network layer to the system call layer, and from the host to the container, achieving full lifecycle management of network traffic. Finally, each protection point maintains functional independence while working collaboratively through policies, ensuring high system performance while providing a flexible and scalable security protection solution for complex network environments.

[0129] In some implementations, the state aggregation submodule aggregates raw event data from multiple atomic protection points according to time windows, generating structured observation event summaries. These summaries are identified based on the observation point names defined in the declarative network security policy and then fed back to the upper-layer application via the SDK module. Specifically, aggregating raw event data from multiple atomic protection points by time windows effectively reduces data redundancy and improves data processing efficiency and readability. The generated structured observation event summaries not only retain key traffic characteristics and security event information but also provide the temporal relationships of events through time windows, aiding upper-layer applications in trend analysis and anomaly detection. Furthermore, identifying the observation event summaries based on the observation point names defined in the declarative network security policy allows upper-layer applications to quickly locate and parse specific event information, facilitating policy adjustments and event responses. Finally, the SDK module feeds this structured data back to the upper-layer application, achieving efficient data transfer from the underlying protection points to the upper-layer application, supporting real-time security situation awareness and dynamic policy optimization.

[0130] Example 4

[0131] To make the objectives, technical solutions, and advantages of this invention clearer, the following will be combined with... Figure 3 The technical solution of the present invention will be described in detail below. The described embodiment four is merely a part of the embodiments of the present invention, and not all of them. Figure 3 This is a schematic diagram of the architecture of the core components of the multi-layered network traffic security protection system provided in Embodiment 4 of the present invention.

[0132] This fourth embodiment uses the example of deploying a protection plane policy named web-server-defense for a protected user-space web application (e.g., an Nginx service running in Cgroup / services / nginx) on a Linux system (kernel version no lower than 6.0) to illustrate the implementation steps of the present invention in detail.

[0133] Step 1: System Initialization and Base Deployment

[0134] 1. After the user-mode control plane starts up, the kernel base manager in the eBPF resource manager begins to work.

[0135] 2. The kernel base manager checks and confirms that the BPF file system is mounted.

[0136] 3. It loads a lightweight ingress dispatcher eBPF program and, according to the present invention's "full-path layered defense model," attaches multiple instances of it to different kernel hook points. This process uses the bpf_link API to ensure robustness.

[0137] (1) An instance is attached to the XDP Hook of the network interface as the entry point of the first layer.

[0138] (2) An instance is attached to the TC Ingress Hook as the ingress entry point for the second layer.

[0139] (3) An instance is attached to the TC Egress Hook as the global outbound entry point for the second layer.

[0140] 4. Simultaneously, configure an independent pipeline entry point for each ingress dispatcher instance: For each dispatcher instance to be deployed, the kernel base manager creates a dedicated, independent Map of type BPF_MAP_TYPE_PROG_ARRAY (e.g., creating xdp_ingress_chain_map for dispatchers deployed on XDP hooks). This Map will serve as the entry point for starting the dynamic protection pipeline for that dispatcher, used for subsequent pipeline orchestration.

[0141] 5. Persisting critical objects for high availability: To ensure system robustness and high availability of the control plane, the kernel base manager uses an object pinning mechanism to persist all critical eBPF objects.

[0142] a. Persistent link relationships (bpf_link): For each 'link object' created by bpf_link_create() that represents the 'link relationship' between the dispatcher program and the kernel hook point, its file descriptor (FD) is fixed to a predetermined path in the BPF file system (e.g., / sys / fs / bpf / kylin_netflow / links / xdp_dispatcher).

[0143] b. Persisting core Maps: Similarly, the file descriptors (FDs) of all core prog_array Maps and other Maps that need to be shared across processes will also be fixed to the corresponding paths.

[0144] The technical advantages of this design are:

[0145] Lifecycle decoupling: By attaching the link object to the file system, its lifecycle is no longer bound to the user-space process that created it. Even if the control plane process restarts or is upgraded, the eBPF programs and policies already attached to the kernel will not be interrupted.

[0146] Seamless takeover: The newly started control plane process can read these predefined paths and reacquire the FDs of existing link and map objects, thereby seamlessly taking over control of the entire kernel data plane, achieving zero-downtime service updates and fault recovery.

[0147] Robustness guarantee: The bpf_link mechanism itself ensures that if a control process that is not fixed to a link exits abnormally, the kernel will automatically detach its corresponding eBPF program, preventing the generation of "zombie programs" and greatly improving the stability and security of the system.

[0148] At this point, a stable, empty, instruction-waiting, multi-layered defense framework has been established in the kernel.

[0149] Step 2: Define and distribute the protection surface strategy at the upper level.

[0150] The upper-layer "security application / intelligent decision engine" generates a declarative, structured "protection surface policy" based on security requirements. This policy is defined in YAML format, and its purpose is as follows:

[0151] Selector: Applies to all Cgroups belonging to the web application cluster, as well as sshd processes exposed for operation and maintenance.

[0152] Ingress strategy

[0153] A. Implement overall rate limiting on all inbound traffic at the highest-performing XDP layer to mitigate DDoS attacks.

[0154] B. At the TC layer, perform fine-grained WAF (load detection) and CC attack (concurrency limit) protection on traffic sent to Web ports (80, 443).

[0155] C. Enable a high-security "gateway" for the sshd process at the LSM layer, allowing only connections from specific bastion hosts.

[0156] D. By default, all other inbound traffic that is not explicitly permitted is rejected.

[0157] Egress strategy

[0158] E. Implement zero-trust control, where web application Cgroups are only allowed to access the backend database service.

[0159] F. Efficiently reject all other unknown connection intents outside the sshd process at the LSM layer.

[0160] Observe requirements

[0161] G. Report all attack events blocked by WAF rules in real time.

[0162] H. Periodically analyze the web application's access traffic to the database.

[0163] 2. Upper-layer applications submit policies to the user-space control plane in a declarative manner by calling the apply_policy(yaml_content) interface of the security SDK.

[0164] Step 3: Control Plane Resolution and Kernel Pipeline Configuration

[0165] The user-space control plane parses and deploys the received policies, a process that fully embodies the metadata-driven and intelligent orchestration mechanism of this invention:

[0166] After receiving the prod-web-cluster-defense policy, the policy executor in the policy engine first stores it completely in the configuration and state storage component for persistence.

[0167] It then parses the policy and issues a series of specific, layered orchestration instructions to the kernel pipeline manager in the eBPF resource manager.

[0168] Based on instructions and metadata for each protection point, the kernel pipeline manager begins to precisely build and configure multi-layered protection capabilities within the kernel:

[0169] 3. Configure Layer 1 (XDP) - Inbound High-Performance Preprocessing:

[0170] a. Analysis: The enforcement layer for the rate-limit-entry-traffic rule was identified as XDP.

[0171] b. Deployment: Load the Limiter.Rate protection point program and orchestrate its FD (file descriptor) into the xdp_ingress_chain Map. Simultaneously, write parameters such as the rate of 100,000 pps into its corresponding control class Map.

[0172] Configure the Layer 2 (TC Ingress) inbound depth strategy:

[0173] a. Analysis: The waf-and-cc-defense rule is identified as suitable for execution at the TC layer.

[0174] b. Deployment: Load the two protection point programs, Limiter.Connection and Matcher.Payload, and arrange their file descriptors (FDs) sequentially into the tc_ingress_chain Map to form a pipeline containing two nodes. Simultaneously, write parameters such as the concurrency threshold of 50 and SQL injection signature codes into the corresponding control class Maps.

[0175] c. Configure observations: Register the observation requirement waf_events to the state aggregator and associate it with the RingBuffer used to report WAF events.

[0176] Configure Layer 0 (LSM) - Inbound / Outbound Intent Control:

[0177] a. Analysis: The enforcement layer hint for the allow-ssh-from-bastion and default-deny-egress rules is LSM.

[0178] b. Deployment: Load lightweight eBPF decision-makers such as Matcher.ProcessInfo and Matcher.Ip, and attach them to the two LSM hooks, security_socket_accept and security_socket_connect. Write parameters such as the process name (sshd) and the list of bastion host IPs into its control class Map.

[0179] Configure Tier 2 (Cgroup Egress) - Outbound Application Policy:

[0180] a. Analysis: The allow-connection-to-database rule was identified, and its conditions include Cgroup and IP / port.

[0181] b. Deployment: Arrange the program FDs of the protection points such as Matcher.Cgroup, Matcher.Ip, Matcher.Port and Observer.Flow into the cgroup_egress_chain Map associated with the target Cgroup in logical order.

[0182] C. Configure observations: Register the observation requirement database_access_stats to the status aggregator and associate it with the per-CPU map used to count database traffic.

[0183] Step 4: Kernel-mode full-path traffic processing

[0184] 1. Inbound traffic processing

[0185] When an external request packet arrives at the network interface card (NIC), it first triggers the Layer 1 XDP hook. The XDP dispatcher then directs the packet into the XDP pipeline for DDoS filtering. If the packet is dropped, the process ends.

[0186] If allowed, the data packet enters the protocol stack, triggering the Layer 2 TC Ingress hook. The TC Ingress dispatcher then imports it into the TC pipeline, where it executes complex logic such as WAF payload detection.

[0187] If a connection is established and subsequently accepted() is applied, the LSM Accept hook at level 0 will be triggered, allowing the final connection admission check to be performed.

[0188] Traffic that passes through all checks is ultimately delivered to the Nginx application.

[0189] 2. Outbound traffic processing

[0190] When an Nginx application attempts to initiate a connection, this intent is first captured by the LSM Connect hook at level 0. The LSM decision process performs a fast rejection check; if a prohibition rule is matched, the system call fails immediately.

[0191] If the intent is permitted, the kernel begins constructing the packet and triggers the Layer 2 Cgroup Egress hook. The CgroupEgress dispatcher then imports it into the application-specific outbound pipeline for more granular filtering.

[0192] Ultimately, the data packet flows to the TC Egress hook, executes the global audit policy, and is then sent to the external network.

[0193] Step 5: Status Feedback and Closed Loop

[0194] 1. During the above processing, the Observer-type guard points deployed in each layer of the pipeline, or the rules with MONITOR actions, will continuously write statistical data and security events into the data class Maps&RingBuffer.

[0195] 2. The state aggregator in the strategy engine pulls data from these Maps based on the observer handles defined in the strategy and aggregates it into structured JSON data corresponding to the "prod-web-cluster-defense" strategy context.

[0196] 3. Security applications / intelligent decision engines subscribe to or query this structured data through the SDK. For example, if it detects that the concurrent connection count of a certain IP is consistently abnormal, it will make a decision, generate a new DENY rule, and then reissue it in a second step to dynamically add the attacking IP to the blacklist, forming an automated response loop.

[0197] Through the above embodiment four, the present invention fully demonstrates how to utilize a unified, programmable infrastructure to realize a multi-layered, bidirectional, and intelligent network security protection system.

[0198] Example 5

[0199] Figure 4 This is a schematic diagram of the hardware structure of the device provided in Embodiment 5 of the present invention. Figure 4 A block diagram is shown of an exemplary electronic device 12 suitable for implementing embodiments of the present invention. Figure 4 The electronic device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0200] like Figure 4 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0201] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0202] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0203] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (commonly referred to as a "hard disk drive"). Although Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0204] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0205] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the electronic device 12 / server / computer, and / or with any device that enables the electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. Figure 4 As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 4 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0206] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the multi-layered network traffic security protection method provided in the embodiments of the present invention.

[0207] Example 6

[0208] Embodiment 6 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the multi-layered network traffic security protection method provided in the above embodiments.

[0209] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0210] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0211] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0212] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0213] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A network traffic multi-layer security protection model, characterized in that, Comprise: Socket layer, including LSM decision program deployed in BPF LSM Hook position, said LSM decision program is used for access control in system call intent stage based on process and Cgroup subject attribute; Network driver layer, including XDP distributor deployed in XDP Hook position, said XDP distributor is used for intervening and preprocessing traffic when network driver receives original data frame; Network protocol stack layer, including TC Ingress distributor deployed in TC Ingress Hook position, Cgroup Egress distributor deployed in Cgroup Egress Hook position and TC Egress distributor deployed in TC Egress Hook position, said TC Ingress distributor, Cgroup Egress distributor and TC Egress distributor are used for respectively executing stateful and needing to carry out deep packet inspection network security policy.

2. A network traffic multi-layered security system, comprising: Comprise: Policy control module, SDK module, user state policy execution module and kernel state data processing module; Said policy control module is used for receiving and analyzing declarative network security policy issued by upper layer, and generating configuration parameter corresponding to said declarative network security policy; Said SDK module is used for issuing declarative security policy, for actively inquiring current state and statistical data of system and for real-time subscribing security event and performance index; User state policy execution module is used for loading and unloading eBPF program according to said policy configuration parameter, managing eBPF resource, maintaining configuration state and issuing control parameter to said kernel state data processing module; Kernel state data processing module includes LSM decision program deployed in BPF LSM Hook position, XDP distributor deployed in XDP Hook position, TC Ingress distributor deployed in TC Ingress Hook position, Cgroup Egress distributor deployed in Cgroup Egress Hook position and TC Egress distributor deployed in TC Egress Hook position.

3. The network traffic multi-tiered security system of claim 2, wherein, Said kernel state data processing module receives said control parameter issued by said user state policy execution module through Map structure, and feedbacks network traffic state and event information to user state through RingBuffer or Map.

4. The network traffic multi-tiered security system of claim 2, wherein: Said policy control module includes policy analysis submodule and policy generation submodule; Said policy analysis submodule is used for analyzing received declarative network security policy text into identifiable policy element; Said policy generation submodule generates configuration parameter corresponding to policy according to said analysis result and delivers to user state policy execution module.

5. The network traffic multi-tiered security system of claim 2, wherein: Said SDK module includes policy issuing interface, system state inquiry interface and security event subscription interface; Said policy issuing interface is used for delivering security policy issued by user end to said user state policy execution module; Said system state inquiry interface is used for inquiring current working state of system; The security event subscription interface is used to deliver system-generated security events or performance indicators to the user end.

6. A network traffic multi-layer security protection method, characterized in that, The method comprises the steps of: S1, a set of eBPF libraries are predefined to construct a plurality of atomic protection points, and each of the atomic protection points is modularly designed to have at least one network control capability of matching, rate limiting or state observation; S2, in the system initialization stage, a persistent data plane architecture is constructed by the user state policy execution module, the data plane architecture comprises a distributor program deployed in a plurality of kernel execution layers, the kernel execution layers correspond to a plurality of kernel hook points, the hook points include but are not limited to BPF LSM, XDP, TC Ingress and Cgroup Egress, the user state policy execution module constructs an independent program array Map for each of the kernel execution layers to support pipeline configuration, and pins the corresponding eBPF program and the Map through the BPF file system to realize persistence; S3, the SDK module receives the declarative network security policy submitted by the upper application, and sends the declarative network security policy to the policy control module, the policy control module analyzes the policy and generates corresponding configuration parameters; S4, the configuration parameters are processed by the user state policy execution module, the user state policy execution module loads or unloads the corresponding eBPF program based on the configuration parameters, creates the required resource Map, and according to the execution layer preference information set in the declarative network security policy or the target kernel execution layer automatically inferred by the system, the protection point program is mounted to the corresponding kernel execution layer; S5, in the process of network traffic processing, network traffic passes through the protection pipeline deployed on each kernel execution layer in turn from the entrance to the exit, the distributor program calls the corresponding atomic protection point program according to the preset logic, executes the matching, rate limiting or observation logic defined in the declarative network security policy, and writes the processing result into the data class Map associated with the protection point; S6, the state aggregation submodule in the user state policy execution module pulls the original event data from the data class Map according to the observation point defined in the declarative network security policy and performs aggregation processing to generate structured observation intelligence, and feeds back to the upper application through the SDK module; S7, the upper application dynamically adjusts the declarative network security policy based on the feedback observation result, and reissues the updated policy through the SDK module to realize policy closed-loop optimization and continuous response.

7. The network traffic multi-layered security method of claim 6, wherein, Step S1 comprises: The atomic protection points include host access control protection points for supporting eBPF LSM, network in-stack protection points for supporting XDP, link layer flow control protection points for supporting TC Ingress, and container out-flow observation protection points for supporting Cgroup Egress.

8. The method of claim 6, wherein, Step S6 comprises: The state aggregation submodule aggregates raw event data from multiple atomized guard points according to a time window, generates a structured observation event summary, identifies the observation event summary according to an observation point name defined in the declarative network security policy, and feeds back to an upper-layer application through the SDK module.

9. An apparatus, comprising: Comprise: A processor, and a memory connected with the processor in communication; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory, and is configured to implement the network traffic multi-level security protection method according to any one of claims 6 to 8.

10. A medium characterized by, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the network traffic multi-level security protection method according to any one of claims 6 to 8.

Images