An eBPF-based kernel-level network traffic real-time anomaly detection method

Abstract

The application relates to the field of Internet of Things intrusion detection, and discloses a kernel-level network flow real-time anomaly detection method based on eBPF, which comprises the following steps: dividing original flow sources according to device identity, service function and communication destination end, and establishing device-specific communication behavior; analyzing access path changes in the current device communication process, and forming an abnormal propagation path; constructing a device-to-device communication dependency relationship according to the correlation between potential risk nodes, and determining a hidden intrusion starting position; establishing a corresponding relationship between attack behavior and device communication state changes according to the determined hidden intrusion starting position, and calculating the development degree of the current intrusion behavior through an incremental anomaly discrimination model; and dynamically adjusting the monitoring range and collection strategy of the eBPF program according to the risk level, increasing kernel event capture types for high-risk devices, and keeping the basic detection state for low-risk devices. The application has the advantage of improving the accuracy of progressive intrusion behavior detection.

Description

Technical Field

[0001] This invention relates to the field of IoT intrusion detection, specifically to a kernel-level network traffic anomaly detection method based on eBPF. Background Technology

[0002] With the development of IoT technology, network intrusion detection methods are increasingly being applied to scenarios such as industrial control networks, smart manufacturing terminals, and edge IoT nodes. Existing detection methods typically judge anomalies based on the number of network connections, packet frequency, and changes in access behavior. However, in scenarios where industrial IoT devices periodically report their status, devices usually send small amounts of status data at fixed time intervals. Attackers exploit these communication patterns by controlling malicious programs to embed abnormal requests within the normal reporting cycle, making the attack traffic highly similar to normal business traffic in terms of packet size and sending frequency. This makes it difficult for traditional traffic detection methods to distinguish between normal status fluctuations and covert attack behavior. Furthermore, in smart manufacturing production line networks where multiple devices operate collaboratively, different sensing terminals have task triggering, status feedback, and device linkage communication relationships. After a node is attacked, its abnormal behavior may only manifest as changes in the communication order between related devices, changes in access direction, or short-term connection anomalies, without immediately forming obvious traffic surges. Existing methods based on single-device traffic characteristic analysis are insufficient to detect such gradual intrusions in a timely manner. In eBPF-based kernel traffic collection scenarios, since detection programs typically focus on individual data packets or single connection states, it is difficult to dynamically judge the fine-grained traffic changes collected in real time on the kernel side in conjunction with the device's long-term communication habits. This can easily lead to insufficient response to low-amplitude, persistent abnormal behaviors.

[0003] Therefore, it is necessary to design a real-time anomaly detection method for kernel-level network traffic based on eBPF to improve the accuracy of progressive intrusion behavior detection. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a real-time anomaly detection method for kernel-level network traffic based on eBPF, which has the advantage of improving the accuracy of progressive intrusion behavior detection and solves the problems mentioned in the background technology.

[0005] To achieve the aforementioned goal of improving the accuracy of progressive intrusion detection, this invention provides the following technical solution: a real-time anomaly detection method for kernel-level network traffic based on eBPF, comprising the following steps:

[0006] Deploy an eBPF detection program in the network processing path of the IoT node kernel to capture information generated by data packets through different processing stages of the protocol stack. Divide the original traffic sources according to device identity, business function and communication destination. Extract the repetitive communication triggering conditions, resource call order and interaction range under normal operation and establish device-specific communication behaviors.

[0007] Based on real-time collected kernel event information, the changes in access paths during the current device communication process are analyzed to identify abnormal behaviors that do not change the data transmission scale but involve access object migration, call relationship expansion, and communication boundary breaches. Operations that deviate from the original communication range of the device are marked as potential risk nodes, and abnormal propagation paths are formed.

[0008] To analyze the relationships between potential risk nodes, we analyze the changes in access permissions, connection directions, and service calls that occur during the attack process as the attack spreads from single-node control to multiple nodes. We construct communication dependencies between devices and use a sparse constraint-based association inference algorithm to separate normal access relationships generated by business linkage from abnormal spread relationships caused by the attack, thereby determining the hidden intrusion starting point.

[0009] Based on the identified hidden intrusion starting point, the kernel call trajectory collected by eBPF is traced back, and the abnormal coupling characteristics generated by the attack behavior in different network layers, process call layers and device interaction layers are extracted. The correspondence between the attack behavior and the changes in device communication state is established, and the development degree of the current intrusion behavior is calculated through an incremental anomaly discrimination model to output the risk level.

[0010] The monitoring scope and collection strategy of the eBPF program are dynamically adjusted according to the risk level. Kernel event capture types are added for high-risk devices, while basic detection status is retained for low-risk devices.

[0011] Preferably, the process of classifying the original traffic source according to device identity, service function, and communication destination is as follows:

[0012] In the Linux kernel network protocol stack of the IoT node, the processing positions corresponding to the data packet entry, forwarding and departure processes are determined. The eBPF detection program is loaded into the network receiving entry, socket state change function and data sending processing interface respectively. The source address, destination address, source port, destination port, protocol type, socket identifier, process identifier and connection state change information generated when the data packet goes through each processing stage are obtained through the kernel probe.

[0013] Based on the correspondence between socket identifiers and process identifiers, network connection records are bound to the business processes that generated the connections, and different communication sources are classified according to device identity information.

[0014] Obtain the business function identifier, communication interface type, and target server information corresponding to each device, and classify data packets with the same business function and facing the same communication destination into the same original traffic source area to form an initial traffic record containing device attributes, network connection, and business access relationship.

[0015] Preferably, the process of establishing device-specific communication behavior is as follows:

[0016] Read historical communication data generated during the normal operation cycle of the device from the initial traffic record, and extract the corresponding trigger events in the process of the device actively initiating connection, receiving control requests and feeding back operating status in chronological order;

[0017] Statistically analyze the target address, service port, calling process, and connection establishment conditions corresponding to each triggering event, and record the resource access order and communication object changes under different business states;

[0018] Based on the communication trigger events that occur repeatedly in multiple operating cycles of the same device, filter the access objects, call paths and interaction scopes that occur more than a preset repetition threshold, and write the access objects, call paths and interaction scopes into the device communication behavior table;

[0019] Based on the access boundaries, call relationships, and connection methods corresponding to different business functions in the device communication behavior table, a unique communication behavior description corresponding to the device identity is formed.

[0020] Preferably, the process for identifying abnormal behaviors that do not change the data transmission scale but involve access object migration, call relationship expansion, and communication boundary breaches is as follows:

[0021] Obtain network connection events, socket change events, and process call events generated by the real-time eBPF detection program, and match the target address, target port, and calling process information in the current communication record with the corresponding records in the device communication behavior table;

[0022] When it is detected that the current communication data volume, data packet length and transmission frequency have not changed significantly, but the target access object has expanded from the original device range to unrecorded objects, the connection corresponding to the newly added access target is extracted and a record is established.

[0023] Analyze the process call relationships and socket association information corresponding to the newly added access target to determine whether the current access generates a new call chain or cross-business function access relationship, and record the communication records that meet the conditions of access object migration, call relationship addition or communication scope expansion as abnormal behavior records.

[0024] Preferably, the process of forming an abnormal propagation path is as follows:

[0025] Extract the device identifier, access target address, process identifier, and connection establishment direction from the abnormal behavior record, and designate the device node and access node that generate the new access relationship as communication nodes respectively;

[0026] Statistically analyze the number of connection establishments, changes in access direction, and the number of associated processes between different communication nodes, and construct a connection relationship table between device nodes and access target nodes;

[0027] Based on the degree of association between newly added nodes and existing communication nodes in the connection relationship table, nodes that appear for the first time and continue to generate access behavior are selected as potential risk nodes.

[0028] Based on the connection sequence and data transmission direction between potentially risky nodes, nodes with continuous access relationships are connected to form an abnormal propagation path that extends from the initial access node to subsequent access nodes.

[0029] Preferably, the process of establishing communication dependencies between devices is as follows:

[0030] Obtain process permission information, network connection direction, and service call records corresponding to potential risk nodes, and associate the process call relationships that result in permission changes within the same device with the access relationships that occur across devices;

[0031] Record the control request direction, data feedback direction, and service call direction between risk nodes respectively, forming a device interaction record that includes the access subject, access object, and called service;

[0032] Based on the repeated call relationships, connection direction consistency, and service dependencies in the device interaction records, a communication dependency table is established between device nodes;

[0033] Based on the direct and indirect access relationships between nodes in the communication dependency table, determine the scope of devices involved in the abnormal access propagation process.

[0034] Preferably, the process of determining the starting location of the hidden intrusion is as follows:

[0035] The device node access relationship in the communication dependency table is converted into an association matrix, and the access frequency, call direction and permission change information between nodes are extracted as association features.

[0036] Sparse constraints are used to compress long-standing device associations with stable business relationships, while retaining abnormal associations that are newly added in a short period of time and have significant connection changes.

[0037] Based on the changes in the in-degree of the nodes, the number of access sources, and the changes in permissions corresponding to the retained abnormal association items, the nodes with different risks are sorted.

[0038] The node that first generates an abnormal association extension and can affect access to multiple device nodes is identified as the starting point of the hidden intrusion.

[0039] Preferably, the process of establishing the correspondence between attack behaviors and changes in device communication states is as follows:

[0040] Based on the device identifier corresponding to the hidden intrusion start location, read the network connection records, socket status records, and process call records cached by the eBPF program.

[0041] The records are associated and arranged according to network connection establishment time, process call order, and device access direction to form a kernel call trajectory.

[0042] The changes in connection targets in the network layer, the changes in access permissions in the process call layer, and the changes in cross-node access in the device interaction layer are extracted separately and combined according to their common occurrence relationships in the same attack process.

[0043] Based on the correspondence between network changes, process changes, and device access changes at different attack stages, attack behavior association features are generated.

[0044] The preferred process for outputting risk levels is as follows:

[0045] Acquire the attack behavior association features formed during historical detection processes, and use the changes in network connections, permissions, and the number of devices spread at different attack stages as discrimination parameters.

[0046] During real-time detection, the current attack behavior characteristics are incrementally compared with historical discrimination parameters to record the number of new attack stages, the change in abnormal access range, and the increase in the number of associated devices.

[0047] Based on the changes of each discrimination parameter within a continuous detection period, an evaluation value for the development of intrusion behavior is generated.

[0048] The risk level of the current device is determined based on the correspondence between the evaluation value of the intrusion behavior and the preset level range.

[0049] Preferably, the process of dynamically adjusting the monitoring scope and data collection strategy of the eBPF program based on the risk level is as follows:

[0050] Read the abnormal access records of the device corresponding to the risk level to obtain the network interface, process identifier, communication target and abnormal propagation path involved in the current device;

[0051] Modify the event collection configuration table in the eBPF program according to the correspondence between risk levels and monitoring objects;

[0052] For high-risk devices, add collection types for socket change events, process call events, and cross-device access events; for low-risk devices, only retain the basic collection fields of packet five-tuple information and connection state change information.

[0053] In subsequent communication testing, the newly collected results will be written into the device communication behavior table, and the event collection range of the corresponding device will be readjusted according to the updated communication behavior changes.

[0054] Compared with existing technologies, this invention provides a kernel-level network traffic anomaly detection method based on eBPF, which has the following advantages:

[0055] This invention deploys an eBPF detection program in the network processing path of an IoT node kernel, enabling fine-grained collection of network protocol stacks, socket states, and process call behavior. This avoids the problem of traditional network traffic detection methods relying solely on external mirrored traffic and failing to detect changes in internal device calls. By segmenting the original traffic source according to device identity, business function, and communication destination, and establishing device-specific communication behaviors, the detection process can identify hidden abnormal accesses by combining the IoT device's own business characteristics, reducing the false alarm rate caused by differences in device type. By analyzing gradual changes such as access object migration, call relationship expansion, and communication boundary breaches, it can detect potential intrusion behaviors even when the attack traffic scale does not change significantly, improving the detection capability against low-frequency, low-volume, and long-term latent attacks. This system constructs communication dependencies between devices and uses a sparse constraint-based association inference algorithm to separate normal business linkages from abnormal propagation relationships, accurately locating the hidden intrusion initiation point and avoiding the attack source location deviation caused by traditional methods that only judge based on the appearance of abnormal nodes. It combines eBPF kernel call trajectory extraction to extract multi-layer abnormal coupling characteristics of the network layer, process layer, and device interaction layer, and uses an incremental anomaly discrimination method to assess the degree of intrusion development, achieving continuous tracking of the attack propagation process. The eBPF event collection scope is dynamically adjusted according to the risk level, so that high-risk devices have richer kernel behavior monitoring capabilities, while low-risk devices maintain a lightweight detection state. This ensures the accuracy of anomaly detection while reducing kernel resource consumption and improving the real-time security protection capability of IoT edge nodes in large-scale device access environments. Attached Figure Description

[0056] Figure 1 This is a schematic diagram of the method of the present invention;

[0057] Figure 2 A flowchart of the risk level steps for this invention is provided. Detailed Implementation

[0058] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0059] Example 1: Please refer to Figure 1 An embodiment of the present invention provides a real-time anomaly detection method for kernel-level network traffic based on eBPF, comprising the following steps:

[0060] S1: Deploy an eBPF detection program in the network processing path of the IoT node kernel to capture information generated by data packets through different processing stages of the protocol stack. Divide the original traffic sources according to device identity, business function and communication destination, extract repetitive communication triggering conditions, resource call order and interaction range under normal operation, and establish device-specific communication behaviors.

[0061] The process of classifying the original traffic source in S1 according to device identity, service function, and communication destination is as follows:

[0062] In the Linux kernel network protocol stack of IoT nodes, the processing positions corresponding to the data packet entry, forwarding, and departure processes are determined. eBPF detection programs are loaded into the network receive entry point, socket state change function, and data transmission processing interface, respectively. Kernel probes are used to obtain source address, destination address, source port, destination port, protocol type, socket identifier, process identifier, and connection state change information generated when data packets pass through each processing stage. A Linux kernel-based eBPF runtime environment is deployed on the IoT nodes. Based on the kernel network data processing flow, the key processing positions through which data packets pass are determined. The data packet reception stage corresponds to the entry point after the network interface enters the protocol stack; the data forwarding stage corresponds to the routing forwarding and socket association processing position; and the data transmission stage corresponds to the network protocol encapsulation and transmission exit position. Based on the data access characteristics of different processing positions, eBPF programs are mounted in the XDP entry layer, the kprobe kernel function call layer, and the network transmission processing path, respectively. The XDP program obtains basic data packet information before and after entering the kernel, the kprobe program monitors socket creation, connection establishment, state changes, and process call events, and the network transmission path collects communication state information when data leaves the node. During the data collection process, the source address, destination address, source port, destination port, and protocol type are used as basic fields for data packets. Socket identifiers are used to associate the lifecycle of the same network connection, and process identifiers are used to identify the application subject that generates the communication behavior. A complete connection change record is formed by recording the connection creation time, hold time, and closing state. At the same time, the above collection results are written to the eBPF Map cache area, which uses a hash map to store the device connection index relationship and a circular buffer to store the real-time event stream, so that the user-space detection module can read the corresponding kernel traffic information according to the device identifier.

[0063] Based on the correspondence between socket identifiers and process identifiers, network connection records are bound to the business processes that generated the connections, and different communication sources are classified according to device identity information. The cached socket status records and process call records in the eBPF Map are read, and based on the unique association of socket identifiers throughout the network connection lifecycle, the process identifier that created the socket is bound to the corresponding network connection record. When the same process generates multiple network connections, the target address, communication port, and protocol type corresponding to each connection are recorded to form process-level communication records. When multiple processes belong to the same IoT device operating environment, the device affiliation is determined based on device registration information, network interface identifiers, and node authentication information, and the network communication behaviors generated by different processes are merged under the corresponding device number. During the device access network phase, a unique device identity is configured for each IoT node and written into the device index table in the eBPF Map. The process relationship table is queried through the socket identifier, and then the process relationship table is reversed to associate with the device index table. This enables the collected network connection records to form a hierarchical association from "data packet - socket - process - device", thereby avoiding source identification errors caused by address changes or network address translation when dividing device traffic solely based on IP address.

[0064] The system acquires the business function identifier, communication interface type, and target server information for each device. Data packets with the same business function and the same communication destination are grouped into the same original traffic source area, forming an initial traffic record that includes device attributes, network connections, and business access relationships. After completing the device-level communication record association, the system reads the business function identifier, network interface type, and service configuration parameters stored in the device management information table. The business function identifier distinguishes different operational tasks of the device, such as data acquisition, remote control, status reporting, and maintenance management. The communication interface type distinguishes the communication source generated by wireless interfaces, wired interfaces, and industrial field interfaces. The target server information identifies the server, control node, or other IoT terminal accessed by the device. Based on the business function identifier, communication records under the same device are further classified. Data packets with the same business function and the same target server are grouped into the same traffic source area. For data packets with the same business function but different communication destinations, different sub-regions are established based on the target address, service port, and protocol type. For identical business data generated by different communication interfaces, they are stored in isolation based on the interface identifier. Ultimately, an initial traffic record is formed, which includes device identity, business function, communication interface, target server, connection status, and data interaction relationship. Each initial traffic record corresponds to a specific device communication source.

[0065] The process of establishing device-specific communication behavior in S1 is as follows:

[0066] The system reads historical communication data generated during the normal operation cycle of the device from the initial traffic records, and extracts the corresponding trigger events during the device's active connection initiation, control request reception, and status feedback processes in chronological order. After the device completes initial access and enters normal operation, it calls the historical traffic records cached by the eBPF detection program to read network event data corresponding to the device identifier from the kernel network protocol stack. The network event data includes connection creation events, connection release events, data sending events, data receiving events, and process call network interface events. The system sorts various events according to the timestamps generated by kernel events, and aggregates events belonging to the same communication process based on socket identifier, process identifier, and device identifier. A group of events that continuously generate connection establishment, data interaction, and status feedback is divided into a communication trigger process. Furthermore, based on the device's service operation log or preset service cycle, the system marks the active connection request, external control request, and status reporting process to form a historical communication trigger record containing the trigger time, trigger source, communication direction, and corresponding service status.

[0067] The system statistically analyzes the target address, service port, calling process, and connection establishment conditions corresponding to each triggering event, and records the resource access order and communication object changes under different business states. For historical communication trigger records, it reads the data packet 5-tuple information, socket connection parameters, and process call information corresponding to each communication trigger process. The data packet 5-tuple information is used to determine the source address, target address, communication port, and protocol type; the socket connection parameters are used to determine the connection establishment method, hold time, and release status; and the process call information is used to determine the application process that initiated the communication. According to the business state label, the distribution of device access target addresses, service port usage range, and process call order under each business state are statistically analyzed, and the execution path from the triggering event to resource access under the same business state is recorded. When multiple triggering events correspond to the same target address, the same service port, or the same calling process, they are grouped into the same resource access node, and the sequential call relationship between different resource access nodes is recorded to form a resource access relationship table corresponding to the business state.

[0068] Based on the communication trigger events that occur repeatedly in multiple operating cycles of the same device, access objects, call paths, and interaction ranges that occur more than a preset repetition threshold are filtered out, and these access objects, call paths, and interaction ranges are written into the device communication behavior table. Resource access relationship tables generated by the same device in multiple complete operating cycles are obtained, and trigger events with the same device identifier, the same business status, and the same communication destination in different cycles are merged and statistically analyzed. The occurrence count of each access object, call path, and interaction range in different operating cycles is calculated, and the occurrence count is compared with the preset repetition threshold. For access objects whose repetition count exceeds the threshold, their corresponding target address, port information, and protocol type are written into the access object field of the device communication behavior table. For recurring call paths, the corresponding process identifier, call order, and connection establishment conditions are written into the call relationship field. For persistent communication ranges, the corresponding communication interface, associated device, and access direction are written into the interaction range field, thereby forming a device communication behavior table containing stable communication characteristics.

[0069] Based on the access boundaries, call relationships, and connection methods corresponding to different business functions in the device communication behavior table, a unique communication behavior description corresponding to the device identity is formed. The access object field, call relationship field, and interaction scope field corresponding to each business function in the device communication behavior table are read, and an independent communication behavior index is established according to the device identity. The access object field is used to limit the target range that the device can actively access or be accessed; the call relationship field describes the correspondence between the device's internal processes and external communication; and the interaction scope field describes the direction of data exchange between the device and other nodes. Based on the degree of overlap of communication objects, consistency of call paths, and stability of connection methods under different business functions, communication records belonging to the same business function are merged to generate communication behavior entries corresponding to the business function. The communication behavior entries corresponding to each business function are associated and stored according to the device identity, forming a unique communication behavior description that includes device access boundaries, resource call relationships, and communication methods.

[0070] S2: Based on real-time collected kernel event information, analyze the changes in access paths during the current device communication process, identify abnormal behaviors that do not change the data transmission scale but involve access object migration, call relationship expansion, and communication boundary breaches, mark operations that deviate from the original communication range of the device as potential risk nodes, and form abnormal propagation paths.

[0071] The process in S2 to identify anomalous behaviors that do not change the data transmission scale but involve access object migration, call relationship expansion, and communication boundary breaches is as follows:

[0072] The system acquires network connection events, socket change events, and process call events generated by the real-time eBPF detection program. It matches the target address, target port, and calling process information in the current communication record with the corresponding records in the device communication behavior table. During the operation of the IoT node, it continuously reads real-time event data collected by the eBPF detection program through kernel probes. Network connection events are acquired by the eBPF program corresponding to the network protocol stack entry point and sending path, used to record the communication establishment process between the current device and external nodes. Socket change events are acquired by the eBPF program attached to the socket state change function, used to record connection creation, connection persistence, and connection release states. Process call events are acquired by the kernel function call probe, used to record the process identifier, calling interface, and execution time of the process that generated the network access behavior. The above events are associated with socket identifiers, process identifiers, and device identifiers to form the current communication record. The historical access objects, service port ranges, and process call relationships corresponding to the device are read from the device communication behavior table. The target address is matched to determine whether the current access object belongs to the device's existing communication range. The target port is matched to determine whether the current service call is within the recorded business range. The calling process is matched to determine whether the current network request was generated by the original business process, thereby obtaining the correspondence between the current communication behavior and the device's normal communication behavior.

[0073] When the current communication data volume, packet length, and transmission frequency have not changed significantly, but the target access object expands from the original device range to unrecorded objects, the connection establishment record corresponding to the newly added access target is extracted. Based on the number of packets, single packet payload length, and number of connection establishments per unit time in the current communication record, the data interaction characteristics of the current communication process are calculated and compared with the historical communication characteristics under the corresponding business function in the device communication behavior table. When the data transmission scale of the current communication process is within a preset range of change, and the target address does not exist in the access object list stored in the device communication behavior table, it is determined that a new access target has been generated in the current communication. Furthermore, the connection creation time, source port, target port, protocol type, and connection duration corresponding to the newly added access target are read from the socket status record cached by eBPF, and the process information that generated the connection is associated with the socket identifier. Simultaneously, the first appearance location of the newly added access target, the number of consecutive accesses, and changes in the access direction are recorded to form a new access target connection record. Through the above method, anomaly detection is avoided by relying solely on changes in traffic volume, and it is possible to identify situations where attackers use normal business traffic volume to hide new access behavior in IoT devices.

[0074] Analyze the process call relationships and socket association information corresponding to the newly added access target to determine whether the current access generates a new call chain or cross-business function access relationship, and record communication records that meet the conditions of access object migration, call relationship addition, or communication scope expansion as abnormal behavior records; read the process identifier, socket identifier, and business function identifier corresponding to the connection record of the newly added access target, query the process network call trajectory collected by eBPF based on the process identifier, and obtain the historical access objects, call interfaces, and network request order of the process; compare the call path corresponding to the newly added access target with the original call relationship in the device communication behavior table, and mark the communication process as call relationship expansion when it is found that the original business process call does not record the network interface or a new access node is added to the original call order. Further, based on the device business function division results, determine whether the newly added access target belongs to the communication scope corresponding to other business functions. When a process corresponding to one business function accesses the dedicated server of another business function, the behavior is marked as cross-business function access. Finally, based on three conditions—whether the accessed object has migrated, whether a new node has been added to the process call chain, and whether the communication range has exceeded the original boundary—the real-time communication records are classified. Records that meet any of the abnormal conditions are written into the abnormal behavior record table, and the corresponding device identifier, access target, process information, socket status, and abnormal type are saved.

[0075] The process of forming an abnormal propagation path in S2 is as follows:

[0076] The process extracts device identifiers, target access addresses, process identifiers, and connection establishment directions from abnormal behavior records, designating the device node and access node that generate new access relationships as communication nodes. It reads abnormal communication information stored in the abnormal behavior record table, obtaining the device identifier, source device address, target access address, process identifier, socket identifier, and connection direction fields for each abnormal record. The connection direction field distinguishes between three scenarios: a device actively establishing a connection, an external node initiating access to the device, and bidirectional communication between devices. Based on the device identifier, it identifies the IoT node that generated the abnormal communication behavior and designates it as a device communication node. Based on the target access address, it identifies newly added service nodes, control nodes, or other device nodes during the abnormal communication process and designates the corresponding access objects as access nodes. Simultaneously, it uses process identifiers to differentiate abnormal accesses generated by different business processes under the same device. When the same access target is accessed by different processes, the access relationships corresponding to different processes are recorded separately. Through the above methods, the original abnormal communication records are converted into node records containing device node, access node, and process association information.

[0077] The system statistically analyzes the number of connection establishments, access direction changes, and associated processes between different communication nodes to construct a connection relationship table between device nodes and target nodes. For each communication node record, it groups and statistically analyzes the correspondence between device nodes and access nodes, reads the connection event records cached by the eBPF detection program, and obtains the number of connection establishments, connection duration, and connection release status between each group of nodes. Simultaneously, it determines the access direction changes between nodes based on socket state change records, and statistically analyzes the number of times the device actively initiates a connection, passively accepts a connection, and engages in bidirectional interaction. Furthermore, it queries the process identifiers corresponding to the node connections, counts the number of different processes generating this communication relationship, and records the number of associated processes when multiple processes simultaneously access the same target node. The device node number, access node number, number of connections, number of direction changes, and number of associated processes are written into the connection relationship table, where each relationship record represents the actual network interaction relationship between two communication nodes.

[0078] Based on the correlation between newly added nodes and existing communication nodes in the connection relationship table, nodes that appear for the first time and continuously generate access behavior are selected as potential risk nodes. The node creation time, historical access records, and current connection status information in the connection relationship table are read to identify newly added access nodes. The newly added access nodes are matched with the historical communication nodes stored in the device communication behavior table. If the access node does not exist in the original communication range of the device, it is marked as a new communication node. The number of connections, the number of accessed devices, and the number of associated processes generated by the new communication node in a continuous detection period are further counted, and it is determined whether the node is only a one-time access behavior or a continuous communication behavior. When a new node maintains a connected state in multiple detection periods, and the number of connections, the range of associated devices, or the number of process calls exceeds a preset threshold, the node is identified as a potential risk node, and its first appearance time, associated devices, and corresponding access direction are recorded.

[0079] Nodes with consecutive access relationships are sorted according to their connection sequence and data transmission direction, forming an abnormal propagation path that extends from the initial access node to subsequent access nodes. A connection relationship table corresponding to the potential risk nodes is obtained, and the communication relationships between nodes are sorted based on the timestamp of each risk node's connection, data transmission direction, and target access object. The risk node that first exhibits abnormal access behavior and can establish connections with other nodes is identified as the initial access node. Subsequent risk nodes accessed by this node are then searched sequentially according to their connection establishment times. When the connection establishment time of a subsequent node is after the communication end time of the previous node, and the data transmission direction meets the condition of extending from an identified node to a newly added node, the two nodes are included in the same abnormal propagation link. This node association process is repeated until no new risk nodes are added, connecting all consecutive communication nodes according to their access order to form an abnormal propagation path that includes the initial access node, intermediate propagation nodes, and subsequently affected nodes. The abnormal propagation path stores the device identifier, access address, process information, and connection time of each node for subsequent determination of the intrusion propagation source and attack development process.

[0080] S3: Analyze the relationships between potential risk nodes, analyze the changes in access permissions, connection directions, and service calls caused by the spread from single-node control to multiple nodes during the attack process, construct communication dependencies between devices, and use a sparse constraint-based association inference algorithm to separate normal access relationships generated by business linkage from abnormal spread relationships caused by attacks, and determine the hidden intrusion starting location.

[0081] The process of establishing inter-device communication dependencies in S3 is as follows:

[0082] The system acquires process permission information, network connection direction, and service call records corresponding to potential risk nodes, and associates process call relationships with permission changes within the same device with access relationships across devices. It reads the abnormal propagation path records corresponding to potential risk nodes, and queries the process call events, network connection events, and socket state change events cached by the eBPF detection program based on the node identifier to obtain the process identifier, user permissions, file access permissions, and network interface call permissions that generate abnormal access behavior. The process permission information is obtained by reading the process identity identifier, user group identifier, and permission control information from the kernel task structure, used to determine whether abnormal communication is accompanied by process permission changes. Furthermore, it acquires connection direction information between the corresponding device and external nodes, determines the active access direction and passive response direction based on the source device address and target device address, and reads the service name, call interface, and call count information from the service call records. It associates the call relationships generated by process permission changes within the same device with newly established network access relationships between different devices, forming an initial association record containing "process permission change—network access behavior—external device response."

[0083] The control request direction, data feedback direction, and service call direction between risk nodes are recorded separately to form a device interaction record containing the access subject, access object, and called service. Based on the initial association record, the communication behavior between risk nodes is divided according to the data transmission direction during network connection establishment. The party actively sending control commands is identified as the access subject, and the party receiving control requests and returning data is identified as the access object. Using the data packet direction field and socket send / receive status change information collected by the eBPF program, the source node, target node, request port, and transmission protocol when the control request is generated are recorded. Simultaneously, the data feedback direction, response time, and corresponding service interface when the target node returns status data are recorded. Further, combined with process call records, the business process generating the communication behavior is bound to the corresponding service call action, recording the changes in the target node when the same access subject calls different service interfaces. The device identifier, process identifier, access direction, called service name, and data interaction type are written into the device interaction record table, ensuring that each record reflects the specific access subject, access object, and service dependency relationship between devices.

[0084] Based on the repeated call relationships, connection direction consistency, and service dependencies in the device interaction records, a communication dependency table is established between device nodes. The device node interaction information stored in the device interaction record table is read, and communication records with the same access subject and access object are merged. The number of service calls, the degree of repetition of call interfaces, and the connection direction maintenance between two device nodes are statistically analyzed over multiple detection periods. When there is continuous data exchange in the same direction between two devices and the service call remains stable, the communication relationship is determined as a stable dependency. For cases where the same access subject continuously calls multiple service nodes, the call chain relationship between devices is recorded according to the order of service calls. The device node number, target device number, communication direction, service type, number of calls, and dependency stability are written into the communication dependency table to form a structured communication dependency relationship between device nodes. Each record in the communication dependency table corresponds to the actual business communication relationship between two device nodes, used to distinguish between communication relationships generated by normal business linkages and new access relationships formed by abnormal diffusion.

[0085] Based on the direct and indirect access relationships between nodes in the communication dependency table, the scope of device associations involved in the abnormal access propagation process is determined. The device node relationships in the communication dependency table are read, and based on the existence of direct connection records between devices, the directly accessing devices corresponding to risk nodes are identified as first-level associated devices. Following the service call direction in the communication dependency table, other device nodes accessed by first-level associated devices are queried, and devices with continuous call relationships are identified as second-level and higher associated devices. During the traversal, the access source, access target, and connection path corresponding to each device node are recorded. When a device node exists only in normal business dependencies and no new access relationships appear, it is retained as a background associated node. When a device node simultaneously meets the conditions of new connection generation, change in access direction, and service call expansion, it is included in the abnormal propagation scope. Finally, an abnormal device association scope record is generated based on the direct and indirect access relationships, saving the number of involved devices, propagation level, access path, and corresponding communication dependencies.

[0086] The process of determining the hidden intrusion start location in S3 is as follows:

[0087] The device node access relationships in the communication dependency table are converted into an association matrix, and the access frequency, call direction, and permission change information between nodes are extracted as association features. The device node number, access target number, communication direction, service call type, and dependency information stored in the communication dependency table are read. Using the device node as the row and column index of the association matrix, corresponding association values ​​are set for positions where communication relationships exist between device nodes. The association value is determined by the number of connection establishments, service call counts, and communication duration between device nodes, representing the communication strength between two device nodes. Further, the access frequency, data transmission direction, and process permission change records between each group of device nodes are extracted from the communication dependency table. The access frequency describes the communication activity level between nodes, the call direction distinguishes between control request direction and data feedback direction, and the permission change information indicates whether there is process permission escalation, change of call subject, or expansion of access permissions during communication. The above information is written into the corresponding feature items of the association matrix according to the device node's position, forming an association feature matrix containing device communication relationships and abnormal change information.

[0088] This method utilizes sparse constraints to compress long-standing device associations with stable business relationships, while retaining anomalous associations that are newly added in a short period and show significant connection changes. For the device communication relationships in the association feature matrix, the method acquires the association changes between corresponding device nodes within different detection periods, and performs stability analysis on device associations that are persistent and have relatively low access frequency changes. When a device association appears continuously over multiple normal operating periods, and its communication direction, service invocation, and permission information remain consistent, the association is marked as a stable business association. Furthermore, a sparse constraint processing method is employed to reduce the weight of stable business associations in the association matrix, thereby reducing their impact on the anomalous association analysis process, while retaining associations that appear for the first time, experience a rapid increase in connection counts within a short period, or show a change in access direction. Association change values ​​are generated based on the association's appearance time, connection growth rate, and number of permission changes. Device associations with change values ​​exceeding a preset threshold are retained, while long-term stable associations are compressed, thus reducing the interference of normal device linkage relationships on anomalous diffusion analysis.

[0089] Based on the changes in node in-degree, number of access sources, and permission changes corresponding to the retained abnormal associations, different risk nodes are sorted. Abnormal associations processed with sparse constraints are read, and the source and target device nodes corresponding to each abnormal association are obtained. The changes in the in-degree of the target node in the abnormal communication relationship are statistically analyzed. The node in-degree change indicates the degree of change in the number of new access sources within a short period; the number of access sources reflects whether a device is being accessed by multiple abnormal nodes; and the permission changes determine whether the access process is accompanied by an increase in process privileges or an expansion of the access scope. A risk node evaluation record is established based on these indicators, and the number of new connections, the number of abnormal access sources, and the number of permission changes corresponding to each device node are written into the evaluation record table. Device nodes are sorted according to the changes in the indicators in the evaluation record, prioritizing device nodes with many new access sources, significant permission changes, and rapid growth in abnormal connections, thus forming the risk node ranking result.

[0090] The node that first generates an abnormal association expansion and can affect access to multiple device nodes is identified as the hidden intrusion starting point. Based on the risk node ranking results, the abnormal association time, first access time, and subsequent connection expansion path corresponding to the top-ranked nodes are read, and the order of occurrence of abnormal behavior of each risk node is traced back. The device nodes that first show abnormal associations are screened to determine whether the node has established a new access connection before other risk nodes generate abnormal communication. Further, the abnormal propagation path is tracing to see if the node can initiate access to multiple device nodes and whether subsequent nodes are formed by the expansion of this node. When a device node meets the conditions of first generating an abnormal association expansion, the abnormal connection persists, and can affect multiple subsequent device nodes, the node is identified as the hidden intrusion starting point. At the same time, the device identifier, abnormal access object, process call information, and propagation path information corresponding to the starting point are saved.

[0091] S4: Based on the determined hidden intrusion starting location, backtrack the kernel call trajectory collected by eBPF, extract the abnormal coupling characteristics generated by the attack behavior in different network layers, process call layers and device interaction layers, establish the correspondence between the attack behavior and the changes in device communication state, calculate the development degree of the current intrusion behavior through an incremental anomaly discrimination model, and output the risk level.

[0092] The process of establishing the correspondence between attack behaviors and changes in device communication state in S4 is as follows:

[0093] Based on the device identifier corresponding to the hidden intrusion starting point, the network connection records, socket status records, and process call records cached by the eBPF program are read. Based on the device number corresponding to the hidden intrusion starting point, the data cache area maintained by the eBPF detection program in the kernel space is queried, and the network connection records, socket status records, and process call records associated with that device identifier are read. The network connection records include source address, destination address, communication port, protocol type, connection establishment time, and data transmission direction, used to describe the network interaction between the device and external nodes. The socket status records include socket identifier, connection creation status, connection hold status, and connection closure status, used to reconstruct the communication link change process. The process call records include process identifier, process start time, network interface called, and permission information, used to determine the internal execution entity that generated the network access behavior. During the reading process, the device identifier is matched with the index field stored in the eBPF Map to filter kernel events belonging to the same device and the same abnormal propagation path, eliminating irrelevant communication records generated by other business processes, thus obtaining kernel behavior data corresponding to the hidden intrusion location.

[0094] The records are associated and arranged according to network connection establishment time, process call order, and device access direction to form a kernel call trajectory. For the acquired network connection records, socket status records, and process call records, they are sorted according to the kernel timestamp written by the eBPF program when the event occurs. The connection creation event is taken as the starting point of the communication process, and data sending, data receiving, and connection release events are arranged chronologically. Furthermore, multiple events generated within the same network connection's lifecycle are associated based on the socket identifier, and the internal call process of that network connection is associated based on the process identifier. After event merging, the changing relationship between the request initiator and the response end during communication is determined by combining the device access direction field. When the same process first generates a local resource call and then triggers an external connection establishment, or when an external access request further triggers an internal device service call, the corresponding events are connected according to the call order. Finally, a kernel call trajectory containing "process call—connection establishment—data interaction—connection change" is formed, where each trajectory node stores the event type, occurrence time, associated device, and corresponding network behavior information.

[0095] Changes in connection targets at the network layer, access permissions at the process call layer, and cross-node access at the device interaction layer are extracted separately and combined according to their common occurrence relationships within the same attack process. Based on the kernel call trajectory, abnormal change information at different layers is broken down and extracted. At the network layer, changes in target address, target port, and connection direction during continuous communication are read, and the first occurrence of access target, connection direction change, and new service port are used as network state change features. At the process call layer, changes in process access permissions, call interfaces, and execution entities are obtained based on the process call trajectory, and process privilege escalation, call entity changes, and new network call interfaces are used as process state change features. At the device interaction layer, the access relationships between device nodes are read based on the abnormal propagation path, and new device connections, cross-service function access, and access scope expansion are extracted as device interaction change features. Furthermore, the event time ranges and associated device identifiers corresponding to the above three types of change features are matched, and change features occurring in the same abnormal propagation stage and having the same starting device are combined to form a multi-layer communication state change record corresponding to the attack process.

[0096] Based on the correspondence between network changes, process changes, and device access changes corresponding to different attack stages, attack behavior association features are generated. The multi-layered communication state change records are read, and network connection changes, process call changes, and device access changes are divided into stages according to the order of events in each stage of the abnormal propagation process. When a stage is mainly characterized by an increase in new target access, port scanning, or the number of connection establishments, the corresponding change is classified as the network detection stage. When a stage involves a change in the process call subject, an expansion of the permission scope, or abnormal service calls, the corresponding change is classified as the internal control stage. When a stage involves new access relationships between devices and the spread of abnormal connections, the corresponding change is classified as the device propagation stage. For each stage, the corresponding starting device, associated process, target node, connection direction, and state change type are recorded, and attack behavior association records are established according to the connection relationship between stages. Finally, an attack behavior association feature containing attack stages, network change features, process change features, and device access change features is formed, which is used to analyze the current intrusion development status in subsequent incremental anomaly identification processes.

[0097] The process of outputting the risk level in S4 is as follows:

[0098] The attack behavior correlation features generated during historical detection are obtained, and the changes in network connections, permissions, and the number of devices proliferating at different attack stages are used as discrimination parameters. The attack behavior correlation records analyzed in the historical detection database are read to extract the stage division results and corresponding state change information of different types of intrusion behavior during propagation. The attack behavior correlation features include the attack stage, the device from which the abnormal access originates, changes in connection targets, process permission adjustments, and device node propagation. For each attack stage, the number of new network connections, the number of new abnormal target addresses, and the number of times the connection direction changes are counted as network connection changes; the number of times process privilege escalation is performed, the number of times the abnormal caller changes, and the scope of access permission expansion are counted as permission changes; the number of new devices, the propagation level, and the range of affected devices that generate associated access from the initial abnormal node are counted as the number of devices proliferating. These parameters are categorized according to attack stages to form a historical risk discrimination parameter table, where each parameter record corresponds to an attack development state.

[0099] During real-time detection, the current attack behavior's associated features are incrementally compared with historical discrimination parameters, recording the number of new attack stages, changes in abnormal access range, and the increase in associated devices. As the eBPF detection program continues to run, attack behavior associated features generated within the current period are read and matched against the attack stage identifier and historical risk discrimination parameter table. The network connection changes between the current and previous detection periods are compared, and the number of new abnormal access targets, the number of connection direction changes, and the number of new communication relationships are counted to obtain the change in the current abnormal access range. It is analyzed whether the current abnormal behavior has evolved from the original attack stage to a new one; when new network diffusion, access control, or device access behaviors are detected, the new stages are cumulatively recorded. Simultaneously, based on changes in device nodes along the abnormal propagation path, the number of newly participating communication device nodes and the changes in the number of associated devices are counted to obtain the increase in associated devices. This incremental comparison method analyzes only the newly added changes within the current detection period, avoiding redundant calculations of historical stable anomaly information and improving processing efficiency during real-time detection.

[0100] Based on the changes in each discrimination parameter within a continuous detection period, an intrusion behavior development evaluation value is generated. The system reads and analyzes the network connection changes, permission changes, number of devices proliferating, and number of new attack phases stored over multiple consecutive detection periods. The development status of the intrusion behavior is determined based on the changing trends of each parameter within the time frame. The continuous detection period is divided into fixed-length analysis windows, and the discrimination parameters for each period within the window are statistically analyzed to calculate whether the abnormal access range continues to expand, whether the number of associated devices continues to increase, and whether permission changes are repeated. When the same device continuously generates new access relationships, permission changes, and device proliferation behavior across multiple detection periods, the corresponding development evaluation result is improved; when abnormal parameters appear only in a single period and subsequently return to normal communication range, the corresponding evaluation result is reduced. An intrusion behavior development evaluation value is generated based on the changes in each discrimination parameter, where this evaluation value represents the degree to which the current abnormal behavior has developed from a single point of abnormality to a continuous propagation state.

[0101] Based on the correspondence between the intrusion behavior development evaluation value and the preset level range, the risk level of the current device is determined. Risk level classification rules are established in advance based on the range of intrusion characteristic changes corresponding to different development stages in historical attack behavior samples, dividing the intrusion behavior development evaluation value into multiple risk ranges. During real-time detection, the currently calculated intrusion behavior development evaluation value is compared with the preset risk ranges. When the evaluation value is in the low-risk range, it indicates that the current device only has local abnormal access behavior, and the device is marked as low-risk. When the evaluation value enters the medium-risk range, it indicates that the abnormal access relationship has expanded or there has been a change in permissions, and the device is marked as medium-risk. When the evaluation value exceeds the high-risk threshold, it indicates that the abnormal behavior has formed a cross-device propagation trend, and the device is marked as high-risk. The risk level results are bound to the corresponding device identifier, abnormal propagation path, and attack behavior association characteristics to achieve dynamic detection for different risk states.

[0102] S5: Dynamically adjust the monitoring scope and collection strategy of the eBPF program according to the risk level, add kernel event capture types for high-risk devices, and retain the basic detection status for low-risk devices.

[0103] The process of dynamically adjusting the monitoring scope and data collection strategy of the eBPF program based on the risk level in S5 is as follows:

[0104] The system reads abnormal access records of devices corresponding to risk levels to obtain the network interfaces, process identifiers, communication targets, and abnormal propagation paths involved in the current device. Based on the real-time generated risk level results, it queries the associated data of the corresponding device identifier in the abnormal behavior record table to read the abnormal access records generated by the device within the current detection period. These abnormal access records include the device network interface number, source and target address information, communication port, socket identifier, process identifier, and abnormal propagation path node information. Through the index relationship between the device identifier and the eBPF event cache area, it further obtains the network interface type currently used by the device, the application process that generated the abnormal connection, and the access target node information. Simultaneously, it reads the connection order, access direction, and number of associated devices between the device and other nodes along the abnormal propagation path to determine the monitoring scope of the current risk device. The above information is archived according to device number to form a device risk status record table, where each record corresponds to a risk device, and stores the network interfaces, process objects, and communication target ranges that require key monitoring for that device.

[0105] Based on the correspondence between risk levels and monitored objects, the event collection configuration table in the eBPF program is modified. A configuration relationship table between risk levels and eBPF event collection types is pre-established, where the configuration relationship table stores the monitoring object range, event type, and collection frequency parameters corresponding to different risk levels. After reading the current device risk level, the corresponding configuration rules are queried according to the device risk level to determine the kernel event collection items that need to be enabled or disabled. A configuration update command is sent to the eBPF program running in the kernel space through the user-space control program, writing the new collection parameters into the event configuration table in the eBPF Map. The event configuration table includes device identifier, monitoring interface, process filtering conditions, socket event type, and data sampling level. When the device risk level changes, the user-space control program updates the corresponding configuration items according to the latest risk results, enabling the eBPF program to dynamically load monitoring rules according to different device states without recompiling or redeploying the kernel detection program.

[0106] For high-risk devices, additional collection types are added, including socket change events, process call events, and cross-device access events. For low-risk devices, only basic collection fields such as packet 5-tuple information and connection status change information are retained. Differentiated data collection is performed on devices with different risk levels according to the risk level rules in the event collection configuration table. For high-risk devices, the eBPF program additionally enables socket status tracking, process network call tracking, and inter-device access relationship tracking. Socket status tracking captures connection creation, connection migration, and abnormal closure behaviors; process call tracking records the process identifier, call interface, and permission change information of the process that generates network access behavior; and device access tracking obtains newly added connection relationships between device nodes. For low-risk devices, unnecessary event collection is disabled, retaining only packet 5-tuple fields, connection establishment time, connection release status, and basic communication direction information to reduce kernel event processing overhead. During execution, the eBPF program matches the current communication object based on the device identifier in the configuration table. When a network event is detected from a high-risk device, the full collection logic is invoked; when a communication event is detected from a low-risk device, only basic traffic records are written, thus achieving dynamic allocation of monitoring resources under different risk levels.

[0107] During subsequent communication detection, newly collected results are written into the device communication behavior table, and the event collection scope of the corresponding device is readjusted based on the updated communication behavior changes. After the eBPF collection strategy adjustment is completed, new communication events generated by each device are continuously received, and the newly collected results are written into the device communication behavior table according to device identifier, business function, and communication target. For high-risk devices, new records include process call paths, socket change processes, and cross-device access relationships to supplement the basis for anomaly propagation analysis. For low-risk devices, new records mainly include access objects, connection status, and data transmission characteristics to maintain basic communication status. Further comparisons are made between the updated device communication behavior and the original communication behavior table. When a device risk level decreases and new communication behavior returns to a stable range, the corresponding event collection level is reduced, and advanced event tracking is decreased. When new access targets, permission changes, or device diffusion relationships reappear, the risk level of the corresponding device is increased, and the eBPF monitoring scope is expanded again. By continuously updating the association between the device communication behavior table and the event collection configuration table, the detection strategy can be dynamically adjusted according to changes in device communication status.

[0108] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0109] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A real-time anomaly detection method for kernel-level network traffic based on eBPF, characterized in that, Includes the following steps: Deploy an eBPF detection program in the network processing path of the IoT node kernel to capture information generated by data packets through different processing stages of the protocol stack. Divide the original traffic sources according to device identity, business function and communication destination. Extract the repetitive communication triggering conditions, resource call order and interaction range under normal operation and establish device-specific communication behaviors. Based on real-time collected kernel event information, the changes in access paths during the current device communication process are analyzed to identify abnormal behaviors that do not change the data transmission scale but involve access object migration, call relationship expansion, and communication boundary breaches. Operations that deviate from the original communication range of the device are marked as potential risk nodes, and abnormal propagation paths are formed. To analyze the relationships between potential risk nodes, we analyze the changes in access permissions, connection directions, and service calls that occur during the attack process as the attack spreads from single-node control to multiple nodes. We construct communication dependencies between devices and use a sparse constraint-based association inference algorithm to separate normal access relationships generated by business linkage from abnormal spread relationships caused by the attack, thereby determining the hidden intrusion starting point. Based on the identified hidden intrusion starting point, the kernel call trajectory collected by eBPF is traced back, and the abnormal coupling characteristics generated by the attack behavior in different network layers, process call layers and device interaction layers are extracted. The correspondence between the attack behavior and the changes in device communication state is established, and the development degree of the current intrusion behavior is calculated through an incremental anomaly discrimination model to output the risk level. The monitoring scope and collection strategy of the eBPF program are dynamically adjusted according to the risk level. Kernel event capture types are added for high-risk devices, while basic detection status is retained for low-risk devices.

2. The real-time anomaly detection method for kernel-level network traffic based on eBPF according to claim 1, characterized in that, The process of classifying the source of raw traffic according to device identity, service function, and communication destination is as follows: In the Linux kernel network protocol stack of the IoT node, the processing positions corresponding to the data packet entry, forwarding and departure processes are determined. The eBPF detection program is loaded into the network receiving entry, socket state change function and data sending processing interface respectively. The source address, destination address, source port, destination port, protocol type, socket identifier, process identifier and connection state change information generated when the data packet goes through each processing stage are obtained through the kernel probe. Based on the correspondence between socket identifiers and process identifiers, network connection records are bound to the business processes that generated the connections, and different communication sources are classified according to device identity information. Obtain the business function identifier, communication interface type, and target server information corresponding to each device, and classify data packets with the same business function and facing the same communication destination into the same original traffic source area to form an initial traffic record containing device attributes, network connection, and business access relationship.

3. The real-time anomaly detection method for kernel-level network traffic based on eBPF according to claim 1, characterized in that, The process of establishing device-specific communication behavior is as follows: Read historical communication data generated during the normal operation cycle of the device from the initial traffic record, and extract the corresponding trigger events in the process of the device actively initiating connection, receiving control requests and feeding back operating status in chronological order; Statistically analyze the target address, service port, calling process, and connection establishment conditions corresponding to each triggering event, and record the resource access order and communication object changes under different business states; Based on the communication trigger events that occur repeatedly in multiple operating cycles of the same device, filter the access objects, call paths and interaction scopes that occur more than a preset repetition threshold, and write the access objects, call paths and interaction scopes into the device communication behavior table; Based on the access boundaries, call relationships, and connection methods corresponding to different business functions in the device communication behavior table, a unique communication behavior description corresponding to the device identity is formed.

4. The real-time anomaly detection method for kernel-level network traffic based on eBPF according to claim 1, characterized in that, The process of identifying anomalous behaviors that do not change the data transmission scale but involve access object migration, call relationship expansion, and communication boundary breaches is as follows: Obtain network connection events, socket change events, and process call events generated by the real-time eBPF detection program, and match the target address, target port, and calling process information in the current communication record with the corresponding records in the device communication behavior table; When it is detected that the current communication data volume, data packet length and transmission frequency have not changed significantly, but the target access object has expanded from the original device range to unrecorded objects, the connection corresponding to the newly added access target is extracted and a record is established. Analyze the process call relationships and socket association information corresponding to the newly added access target to determine whether the current access generates a new call chain or cross-business function access relationship, and record the communication records that meet the conditions of access object migration, call relationship addition or communication scope expansion as abnormal behavior records.

5. The real-time anomaly detection method for kernel-level network traffic based on eBPF according to claim 1, characterized in that, The process of forming an abnormal propagation path is as follows: Extract the device identifier, access target address, process identifier, and connection establishment direction from the abnormal behavior record, and designate the device node and access node that generate the new access relationship as communication nodes respectively; Statistically analyze the number of connection establishments, changes in access direction, and the number of associated processes between different communication nodes, and construct a connection relationship table between device nodes and access target nodes; Based on the degree of association between newly added nodes and existing communication nodes in the connection relationship table, nodes that appear for the first time and continue to generate access behavior are selected as potential risk nodes. Based on the connection sequence and data transmission direction between potentially risky nodes, nodes with continuous access relationships are connected to form an abnormal propagation path that extends from the initial access node to subsequent access nodes.

6. The real-time anomaly detection method for kernel-level network traffic based on eBPF according to claim 1, characterized in that, The process of establishing communication dependencies between devices is as follows: Obtain process permission information, network connection direction, and service call records corresponding to potential risk nodes, and associate the process call relationships that result in permission changes within the same device with the access relationships that occur across devices; Record the control request direction, data feedback direction, and service call direction between risk nodes respectively, forming a device interaction record that includes the access subject, access object, and called service; Based on the repeated call relationships, connection direction consistency, and service dependencies in the device interaction records, a communication dependency table is established between device nodes; Based on the direct and indirect access relationships between nodes in the communication dependency table, determine the scope of devices involved in the abnormal access propagation process.

7. The real-time anomaly detection method for kernel-level network traffic based on eBPF according to claim 1, characterized in that, The process of determining the hidden intrusion starting location is as follows: The device node access relationship in the communication dependency table is converted into an association matrix, and the access frequency, call direction and permission change information between nodes are extracted as association features. Sparse constraints are used to compress long-standing device associations with stable business relationships, while retaining abnormal associations that are newly added in a short period of time and have significant connection changes. Based on the changes in the in-degree of the nodes, the number of access sources, and the changes in permissions corresponding to the retained abnormal association items, the nodes with different risks are sorted. The node that first generates an abnormal association extension and can affect access to multiple device nodes is identified as the starting point of the hidden intrusion.

8. The real-time anomaly detection method for kernel-level network traffic based on eBPF according to claim 1, characterized in that, The process of establishing the correspondence between attack behaviors and changes in device communication states is as follows: Based on the device identifier corresponding to the hidden intrusion start location, read the network connection records, socket status records, and process call records cached by the eBPF program. The records are associated and arranged according to network connection establishment time, process call order, and device access direction to form a kernel call trajectory. The changes in connection targets in the network layer, the changes in access permissions in the process call layer, and the changes in cross-node access in the device interaction layer are extracted separately and combined according to their common occurrence relationships in the same attack process. Based on the correspondence between network changes, process changes, and device access changes at different attack stages, attack behavior association features are generated.

9. The real-time anomaly detection method for kernel-level network traffic based on eBPF according to claim 1, characterized in that, The process of outputting the risk level is as follows: Acquire the attack behavior association features formed during historical detection processes, and use the changes in network connections, permissions, and the number of devices spread at different attack stages as discrimination parameters. During real-time detection, the current attack behavior characteristics are incrementally compared with historical discrimination parameters to record the number of new attack stages, the change in abnormal access range, and the increase in the number of associated devices. Based on the changes of each discrimination parameter within a continuous detection period, an evaluation value for the development of intrusion behavior is generated. The risk level of the current device is determined based on the correspondence between the evaluation value of the intrusion behavior and the preset level range.

10. A real-time anomaly detection method for kernel-level network traffic based on eBPF according to claim 1, characterized in that... The process of dynamically adjusting the monitoring scope and data collection strategy of the eBPF program based on the risk level is as follows: Read the abnormal access records of the device corresponding to the risk level to obtain the network interface, process identifier, communication target and abnormal propagation path involved in the current device; Modify the event collection configuration table in the eBPF program according to the correspondence between risk levels and monitoring objects; For high-risk devices, add collection types for socket change events, process call events, and cross-device access events; for low-risk devices, only retain the basic collection fields of packet five-tuple information and connection state change information. In subsequent communication testing, the newly collected results will be written into the device communication behavior table, and the event collection range of the corresponding device will be readjusted according to the updated communication behavior changes.

Images