A port scanning detection method, system, electronic device and storage medium

Abstract

The application discloses a port scanning detection method and system, an electronic device and a storage medium. The method comprises the following steps: loading an eBPF program and creating a first eBPF Map for storing a whitelist; hooking a first eBPF program related to a first kernel function of port listening, dynamically constructing the whitelist during port listening; hooking a second eBPF program related to a second kernel function of network connection establishment, extracting a destination port number and querying the whitelist when receiving a network connection request; if the query is not hit, determining an abnormal scanning event, and collecting connection information and reporting to the user state. The application can detect port scanning behavior in real time and accurately in the kernel state with low performance overhead, and the detection mechanism is difficult to bypass, solving the problems of poor real-time performance, high performance overhead and easy bypassing in the prior art.

Description

Technical Field

[0001] This application belongs to the fields of network security and host security technology. Specifically, it relates to an intranet intrusion detection technology based on the Extended Berkeley Packet Filter, and more particularly to a port scan detection method, system, electronic device and storage medium for real-time detection of port scan behavior in lateral movement attacks. Background Technology

[0002] In modern network attack and defense environments, especially in advanced persistent threat (APT) attacks targeting enterprise intranets, attackers typically perform lateral movement after successfully compromising a host to probe the intranet topology, discover vulnerable assets, and ultimately obtain critical data or privileges. Port scanning is the most common and critical initial step in the lateral movement phase. Attackers scan the ports of other hosts on the intranet to discover open network services and find exploitable entry points. Therefore, real-time and accurate detection of port scanning activity is crucial for disrupting the entire attack chain and protecting intranet security.

[0003] However, existing port scanning detection technologies have many limitations, making it difficult to balance real-time performance, performance overhead, detection coverage, and stealth.

[0004] A common approach is based on network traffic analysis. This approach involves configuring port mirroring on switches to copy network traffic to dedicated analysis devices for detection. However, this approach has several drawbacks: it is costly and complex to deploy, requiring modifications to the existing network architecture; with the widespread use of transport layer security protocols, a large amount of network traffic is encrypted, making it impossible for network traffic analysis devices to decrypt, thus significantly reducing their detection capabilities; and alarm localization is not precise enough—while it can detect scanning activity on the network, it is difficult to accurately link it to which specific process on which host initiated or was attacked.

[0005] Another approach is traditional host security proxy technology. This approach installs an agent program on each host, which monitors network connectivity by periodically executing system commands or analyzing system logs. The main drawbacks of this approach are: significant performance overhead, as the agent program needs to frequently poll or read the file system to obtain status information, consuming the host's CPU and memory resources and potentially impacting the performance of normal business operations; significant detection latency, as the polling mechanism typically has a cycle of minutes, allowing attackers to complete a rapid scan between two detection cycles, leading to delayed or even invalid alerts; and the agent program deployed in user space is easily discovered and terminated by attackers with higher privileges, thus bypassing detection.

[0006] In addition, there is traditional honeypot technology. This approach lures attackers by deploying simulated, seemingly vulnerable fake services. The limitations of this approach are: it is primarily for deception and cannot provide direct protection for real business hosts; if attackers directly scan real hosts, the honeypot will be unaware; deploying fully functional honeypots on each host to simulate various services is impractical in terms of resource consumption and maintenance costs; furthermore, the fingerprint characteristics of general-purpose honeypots are easily identified by experienced attackers, thus allowing them to be evaded.

[0007] In summary, existing technologies lack a mechanism capable of penetrating the operating system kernel to monitor and determine network events at the scene of occurrence in a low-overhead, high-efficiency, and comprehensive manner. Therefore, overcoming these shortcomings of existing technologies and providing a real-time, efficient, comprehensive, and difficult-to-bypass port scanning detection solution is a pressing technical problem in the field of host security. Summary of the Invention

[0008] The main objective of this application is to provide a port scanning detection method, system, electronic device, and storage medium to solve the problems of poor real-time performance, high performance overhead, incomplete coverage, and easy bypass in existing port scanning detection schemes.

[0009] To achieve the above objectives, the first aspect of this application provides a port scanning detection method, characterized in that it includes:

[0010] Load and run an eBPF program on the host, the eBPF program including a first eBPF program and a second eBPF program;

[0011] Create the first eBPF Map to store information about legitimate listening ports, and an event reporting channel for communication between kernel mode and user mode;

[0012] The first eBPF program is hooked to the first kernel function associated with the host port listening behavior; when the service process on the host initiates port listening, the first eBPF program is triggered to extract the port number being listened to and store it in the first eBPF Map to dynamically build a whitelist of legal listening ports.

[0013] The second eBPF program hooks to a second kernel function associated with network connection establishment behavior; when the host receives a network connection request, the second eBPF program is triggered to extract the destination port number of the network connection request;

[0014] The second eBPF program uses the destination port number to query the first eBPF Map;

[0015] If no record matching the destination port number is found in the first eBPF Map, the network connection request is determined to be an abnormal scanning event, and the connection information of the abnormal scanning event is collected and sent to the user-space daemon process through the event reporting channel.

[0016] To achieve the above objectives, a second aspect of this application provides a port scanning detection system, characterized in that it comprises:

[0017] The loading unit is used to load and run an eBPF program on the host, the eBPF program including a first eBPF program and a second eBPF program, and to create a first eBPF Map for storing information on legitimate listening ports and an event reporting channel for communication between kernel mode and user mode.

[0018] The whitelist building unit is configured to capture the port number being listened to and store it in the first eBPF Map when the service process on the host initiates port listening, by hooking the first eBPF program to the first kernel function, so as to dynamically build a whitelist of legal listening ports. The first kernel function is associated with the host port listening behavior.

[0019] The real-time detection unit is configured to extract the destination port number of a network connection request when the host receives such a request via the second eBPF program hooked to the second kernel function. The second kernel function is associated with the network connection establishment behavior.

[0020] The scanning determination unit is configured to use the destination port number to query the first eBPF Map. If no matching record is found in the first eBPF Map, the network connection request is determined to be an abnormal scanning event.

[0021] The event reporting unit is configured to collect the connection information of an abnormal scanning event after it is determined to be an abnormal scanning event, and send the connection information to the daemon process in user space through the event reporting channel.

[0022] To achieve the above objectives, a third aspect of this application provides an electronic device, comprising: a memory, a processor, and a computer program stored on the memory, characterized in that the processor executes the computer program to implement the method as described in any of the preceding claims.

[0023] To achieve the above objectives, a fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method described in any of the preceding claims.

[0024] To achieve the above objectives, a fifth aspect of this application provides a computer program product including computer instructions, characterized in that, when the instructions are executed by a processor, they implement the method described in any of the preceding claims.

[0025] Furthermore, this application also provides a distributed port scanning detection system, including multiple host-side detection subsystems and a central analysis platform. The central analysis platform can aggregate abnormal events across the entire network and effectively identify distributed lateral movement attacks by analyzing cross-host access behavior from the same source IP within a short period, thus overcoming the limitations of single-machine defense.

[0026] The technical solution provided in this application utilizes eBPF technology to hook key kernel functions related to port listening and network connection establishment at the operating system kernel level, achieving low-level monitoring of all port access behavior on the host. By hooking kernel functions related to port listening, a dynamically updated whitelist of legitimate listening ports can be automatically and in real time constructed. This whitelist accurately reflects the status of all normal services on the host, requiring no manual configuration. When a network connection request arrives, by querying this whitelist at the trigger point of the kernel function related to connection establishment, normal business access and scanning probes targeting non-listening ports can be distinguished in real time. This event-driven detection mechanism occurs in kernel space, synchronized with the event source, thus achieving zero-latency real-time detection. For events determined to be abnormal scans, reports are made using an efficient kernel-user space communication channel, with minimal impact on host performance throughout the entire process.

[0027] Compared with the prior art, this application has the following beneficial effects:

[0028] The detection logic executes directly on the kernel's network event handling path, enabling event-driven real-time alerts and completely eliminating the minute-level latency of traditional polling schemes. The eBPF program is compiled on the fly into efficient native machine code that runs in the kernel, triggered only when a network event occurs. Its consumption of host CPU and memory resources is negligible, making it suitable for high-load production environments. The monitoring scope covers all host ports, and the whitelist, dynamically generated based on actual listening behavior, ensures accurate capture of probes on any non-listening ports, avoiding false positives and false negatives. The detection mechanism runs entirely in kernel space, remaining transparent to user-space applications and attackers. Attackers find it difficult to discover or disable this monitoring through conventional means, ensuring the robustness of the detection. For legitimate connections accessing normal services, the eBPF program performs only one efficient hash table lookup and returns immediately, without interfering with normal network communication processes, ensuring business stability and seamless operation. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a schematic flowchart of a port scanning detection method provided in an embodiment of this application.

[0031] Figure 2 This is a structural block diagram of a port scanning detection system provided in an embodiment of this application.

[0032] Figure 3 This is a schematic diagram of a system deployment architecture provided in an embodiment of this application.

[0033] Figure 4 This is a schematic diagram of the data flow for whitelist construction and scanning detection provided in an embodiment of this application.

[0034] Figure 5 This is a schematic diagram of TCP state transitions for a deceptive response mechanism provided in an embodiment of this application.

[0035] Figure 6 This is a flowchart illustrating an active defense mechanism provided in an embodiment of this application.

[0036] Figure 7 This is a schematic diagram of a UDP port scanning detection process provided in an embodiment of this application.

[0037] Figure 8 This is a hardware structure block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0039] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0040] Example 1

[0041] This embodiment details a port scanning detection method and system. The core idea of ​​this scheme is to use Extended Berkeley Packet Filter (eBPF) technology to achieve real-time monitoring of port activity in kernel space, dynamically generate a whitelist of legitimate service ports, and accurately identify scanning behavior targeting non-listening ports based on this whitelist.

[0042] See Figure 1 The diagram illustrates a flowchart of a port scanning detection method. This method can be applied to... Figure 2 In the system shown, and in Figure 3 It runs under the architecture shown.

[0043] like Figure 3 As shown, the system architecture mainly includes an agent program deployed on host 301 and a backend central analysis platform 302. The agent program on host 301 is divided into two parts: kernel space 303 and user space 304. The core eBPF module runs in kernel space 303, while a daemon process 310 runs in user space 304, responsible for managing the eBPF module and communicating with the central analysis platform 302. Normal business services 311 also run on host 301.

[0044] Specifically, the port scanning detection method includes the following steps:

[0045] Step S101: Initialize loading.

[0046] When host 301 starts or the security agent program starts, the daemon 310 in user space 304 is responsible for loading and running the kernel-mode eBPF program. This eBPF program includes at least a first eBPF program 305 and a second eBPF program 306. Simultaneously, the daemon 310 creates the necessary data structures through eBPF system calls, including a first eBPF Map 307 for storing information about legitimate listening ports and an event reporting channel 308 for efficient communication between kernel and user space.

[0047] In this embodiment, the first eBPF Map 307 is preferably a hash table type, with the key being the port number and the value containing additional information such as the process ID to enable fast lookup. The event reporting channel 308 is preferably an eBPF Ring Buffer, which is an efficient, lock-free ring buffer that supports multiple producers and a single consumer, making it very suitable for asynchronously transmitting event data from kernel space to user space.

[0048] Step S102: Dynamically construct a whitelist of legitimate listening ports.

[0049] The first eBPF program 305 is configured to hook to a first kernel function associated with host port listening behavior. In this embodiment, the first kernel function is preferably the `listen` system call. When any normal business service 311 on host 301 initiates port listening, the kernel will trigger the hooked first eBPF program 305 during the execution of this system call.

[0050] Upon triggering, the first eBPF program 305 extracts key information from the system call parameters or related kernel data structures, primarily the listening port number and the process ID that initiated the call. Subsequently, the first eBPF program 305 stores this port number as the key in the first eBPF Map 307. In this way, whenever a new service starts and listens on the port, or an existing service stops listening, the whitelist is automatically and in real-time updated without any manual intervention, ensuring the accuracy and timeliness of the whitelist.

[0051] Step S103: Real-time detection of network connection requests.

[0052] The second eBPF program 306 is configured to hook to a second kernel function associated with network connection establishment behavior. In this embodiment, the second kernel function is preferably the `accept` system call. When host 301 receives an external network connection request, and the kernel's TCP / IP protocol stack completes the three-way handshake and is ready to hand over the established connection to the upper-layer application for processing, the `accept` system call is triggered, thereby activating the second eBPF program 306.

[0053] After being triggered, the second eBPF program 306 extracts the destination port number of the network connection request from the kernel socket structure corresponding to the connection.

[0054] Step S104: Query the whitelist and determine abnormal scanning events.

[0055] See Figure 4 This shows the data flow of whitelist construction and scanning detection. After obtaining the destination port number, the second eBPF program 306 immediately uses this port number as the key to query the first eBPF Map 307.

[0056] There are two possibilities:

[0057] Scenario A (Query Hit): If a record matching the destination port number is found in the first eBPF Map 307, this indicates that the connection is accessing a port that is currently providing normal service. In this case, the second eBPF program 306 determines the connection as legitimate, performs no further operations, returns directly, allowing the kernel to continue the normal `accept` process, and hands the connection over to the service 311. This process is transparent to normal business operations and has no performance impact.

[0058] Scenario B (Query Miss): If no matching record is found in the first eBPF Map 307, this is highly likely a port scan or probing activity. In this case, the second eBPF program 306 classifies the network connection request as an abnormal scan event.

[0059] Step S105: Collect and report abnormal event information.

[0060] Upon identifying an abnormal scanning event, the second eBPF program 306 immediately retrieves detailed connection information about the event from kernel data structures. This information is crucial for subsequent security analysis and includes at least: the attack source IP address, the attack source port number, the destination port number, the transport layer protocol type, and the precise timestamp of the event.

[0061] Subsequently, the second eBPF program 306 calls an eBPF helper function to record the collected connection information as an event and push it to the event reporting channel 308. The daemon process 310 in user space 304 continuously listens to this channel. Once new event data arrives, the daemon process 310 is awakened and reads the event data from the channel. After reading, the daemon process 310 can format the data and send it over the network to the backend central analysis platform 302 for storage, correlation analysis, and alarm display.

[0062] It should be noted that although this embodiment uses the `listen` and `accept` system calls as examples, the first and second kernel functions of this application are not limited to these. In other embodiments, the first kernel function can also be other kernel functions related to port binding and listening, and the second kernel function can also be other functions related to connection establishment or packet reception, as long as they can achieve the purpose of monitoring port listening status and network connection requests.

[0063] Accordingly, this application also provides a port scanning detection system, such as Figure 2 As shown. The system includes:

[0064] Loading unit 201 is used to perform the above step S101, loading the eBPF program on the host and creating an eBPF Map and event reporting channel.

[0065] The whitelist construction unit 202 is implemented by the first eBPF program hooked to the first kernel function, and is used to execute step S102 to dynamically construct a whitelist of legitimate listening ports.

[0066] The real-time detection unit 203, whose function is implemented by the second eBPF program hooked to the second kernel function, is used to execute step S103 to extract the destination port number of the network connection request in real time.

[0067] The scan determination unit 204, whose function is also implemented by the second eBPF program, is used to execute step S104 to determine whether it is an abnormal scan event by querying the whitelist.

[0068] The event reporting unit 205, whose function is also implemented by the second eBPF program and the event reporting channel, is used to execute step S105 to collect and report abnormal event information to the daemon process in user space.

[0069] Example 2

[0070] Based on Example 1, this embodiment introduces a deceptive response mechanism to increase the difficulty and cost of detection for attackers.

[0071] See Figure 5 This diagram illustrates a deceptive response mechanism in TCP state transitions. In traditional network scanning, when a scanner sends a SYN packet to a closed port, the host immediately sends back an RST packet, allowing the scanner to definitively determine that the port is closed.

[0072] In this embodiment of the application, when the second eBPF program determines in step S104 that a TCP connection request is an abnormal scan event, it does not inject any rejection or reset messages into the kernel protocol stack. Instead, it chooses not to intervene, allowing the kernel's TCP / IP protocol stack to complete the three-way handshake normally, causing the connection to enter the `ESTABLISHED` state, as shown below. Figure 5 As shown.

[0073] However, since no user-space service 311 is listening on the destination port and preparing to call `accept()` to accept the connection, the established connection will remain in the kernel's half-connection queue or full-connection queue. The kernel maintains a timeout mechanism for connections waiting for application acceptance. Specifically, for half-connections, the kernel will retry sending SYN-ACK packets a number of times as defined by the `tcp_synack_retries` parameter. If no ACK is received within the specified number of times, the connection fails. For connections that have completed the handshake, if there is no application-layer processing for a long time, they will also be automatically cleaned up by the kernel due to timeout. In this embodiment, the value of the `tcp_synack_retries` kernel parameter can be set between 3 and 8 to balance the deceptive effect and kernel resource consumption.

[0074] This approach confuses scanning tools. From the scanner's perspective, the port appears open, but subsequent application-layer probes consistently time out. This significantly increases the scanning tool's probe time and complexity, making it difficult for them to quickly and accurately determine the port's true status, thus effectively delaying and hindering the attacker's lateral movement.

[0075] In terms of system implementation, this deceptive response mechanism can be implemented by a response control unit 206, whose function is integrated into the second eBPF program and is achieved by controlling its behavior after an anomaly is detected.

[0076] Example 3

[0077] Based on Embodiment 1, this embodiment provides an active defense mechanism to automatically block the attack source IP after detecting continuous scanning behavior.

[0078] See Figure 6 The diagram illustrates the process flow of the proactive defense mechanism. This mechanism introduces two new components: a second eBPF Map for storing the IP addresses of attack sources, and a third eBPF procedure for executing packet dropping.

[0079] The mechanism works as follows:

[0080] Step S601: The daemon process receives and analyzes the abnormal event.

[0081] The user-mode daemon 310 continuously receives abnormal scan events from the kernel. To avoid overreacting to single, potentially accidental, port probes, daemon 310 incorporates a frequency analysis logic.

[0082] Step S602: Determine malicious behavior based on frequency threshold.

[0083] The daemon process 310 has a preset time window set. and a preset frequency threshold It tracks each attack source IP in memory within a time window. The number of abnormal scanning events initiated internally. When the number of events originating from the same attack source IP address exceeds the frequency threshold. Only then is the IP address identified as a malicious scanning source.

[0084] Specifically, this decision logic can be expressed as:

[0085] In the time window If it comes from the source IP address Count of abnormal scan events If so, a ban will be triggered.

[0086] in, The value range can be adjusted according to the sensitivity of the business scenario, ranging from 5 seconds to 60 seconds; The value range can also be adjusted accordingly, between 10 and 100.

[0087] Step S603: Update the attack source blacklist.

[0088] Once a source IP is determined to be malicious, daemon 310 will write that IP address into the second eBPF Map. This Map serves as a blacklist and can be accessed by other eBPF programs.

[0089] Step S604: Discard the data packet at the network entry path.

[0090] A third eBPF program is loaded and hooked into a very early stage of the host network packet receive path. This hook point is preferably an eXpress Data Path (XDP) entry or a Traffic Control (TC) entry. XDP and TC allow the eBPF program to process network packets before they enter the kernel's main protocol stack, resulting in extremely high performance.

[0091] When a network packet arrives, the third eBPF procedure is triggered. It extracts the source IP address of the packet and queries the second eBPF Map. If the query matches, meaning the source IP of the packet is in the blacklist, the third eBPF procedure immediately returns a drop instruction, and the packet is directly dropped without consuming any subsequent CPU resources. If the query fails, the packet is allowed to enter the protocol stack normally.

[0092] In this way, this application achieves a closed loop from passive detection to proactive defense. The system can automatically identify high-frequency scanning attackers and block their traffic at the network ingress with extremely low performance overhead, effectively protecting the host from further attacks. In system implementation, this function can be implemented by a proactive defense unit 207.

[0093] Example 4

[0094] The detection mechanism of this application is not limited to the TCP protocol, but can also be extended to detect UDP port scans. This embodiment describes in detail the detection scheme for UDP scans.

[0095] See Figure 7 This diagram illustrates the process of UDP port scanning detection. Because UDP is a connectionless protocol, its port scanning detection cannot rely on the `accept` system call. Instead, the detection logic needs to be hooked to kernel functions related to receiving UDP packets.

[0096] Step S701: Load and hook the UDP handler.

[0097] In addition to the existing eBPF program, the system loads and runs a fourth eBPF program. This program is hooked to a third kernel function associated with UDP packet reception behavior. This third kernel function is preferably either the `recvfrom` or `recvmsg` system call. These system calls are triggered when an application receives data from a UDP socket.

[0098] Step S702: Maintain the whitelist of UDP listening ports.

[0099] Similar to TCP, when a service process binds to and is ready to receive data on a UDP port, it can capture the UDP port number by hooking the corresponding kernel function and store it in the first eBPF Map.

[0100] Step S703: Detect UDP scan.

[0101] When a UDP packet arrives at a host, any `recvfrom` or `recvmsg` calls to that port will fail if no application is listening on its destination port, or no application will call them at all. Fourth, when an eBPF program is triggered, it can extract the destination port number of the UDP packet and query the UDP port whitelist.

[0102] Step S704: Judgment and Reporting.

[0103] If the query fails, meaning the destination port of the UDP packet is not in the whitelist, it can be determined as an abnormal scan event targeting the UDP protocol. Subsequently, the fourth eBPF program collects relevant information and reports it to the user-space daemon process through event reporting channel 308.

[0104] This extension enables comprehensive port scanning and detection of both TCP and UDP, the two mainstream transport layer protocols. In system implementation, this function can be implemented by a UDP detection unit 208.

[0105] Furthermore, there are alternatives to some of the technical details in this application. For example, besides the `kprobe `accept` system call, the second kernel function could be replaced by hooking the lower-level `tcp_v4_rcv` kernel function, or the more stable `sock:inet_sock_set_state` tracepoint could be used. Making the judgment at `tcp_v4_rcv` allows for the detection of connection intent upon receiving a SYN packet, earlier but with more complex logic. Making the judgment at the `sock:inet_sock_set_state` tracepoint when the TCP state changes to `TCP_ESTABLISHED` achieves a similar effect, and the tracepoint is less affected by kernel version upgrades, resulting in better stability.

[0106] Example 5

[0107] This embodiment focuses on the user-space daemon's subsequent processing of abnormal scanning events, especially event aggregation and deduplication, in order to reduce alarm redundancy and extract high-value security information.

[0108] In actual scanning attacks, attackers typically probe a large number of ports or multiple hosts within a short period of time, generating a massive amount of raw anomaly scan events. Directly reporting all raw events would put enormous pressure on the central analysis platform 302 and generate a large number of duplicate alerts, which is detrimental to the analysis by security operations personnel.

[0109] To address this issue, the user-space daemon 310 performs aggregation and deduplication processing before reporting events to the central analysis platform 302. The specific implementation is as follows:

[0110] Daemon 310 maintains an event cache in its memory. It constructs a triplet based on the source IP address, destination port number, and protocol type in the connection information of each anomaly scan event, and uses this triplet as a unique key.

[0111] For each received raw event, daemon 310 first queries the event cache based on its triple:

[0112] 1. If the key does not exist in the cache, it means this is the first occurrence of this type of event. Daemon 310 will create a new entry in the cache, record the triplet, the timestamp of its first occurrence, and initialize the event counter to 1.

[0113] 2. If the key already exists in the cache, it indicates a duplicate event. Daemon 310 will not report it immediately, but will only increment the event counter corresponding to the entry and update the timestamp of the last occurrence.

[0114] Daemon process 310 sets the trigger conditions for alarm generation, for example:

[0115] - Frequency threshold: When the count value of an event counter reaches a preset reporting threshold for the first time, an aggregated alarm log is generated.

[0116] - Time period: Alternatively, when an event occurs more than a preset reporting period after it first appears, an aggregate alarm will be generated regardless of its count value.

[0117] The generated aggregated alarm logs contain key information such as source IP, destination port range, protocol, number of scans, and start and end times. In this way, hundreds or even thousands of raw events can be aggregated into a single high-confidence alarm, significantly improving the signal-to-noise ratio and analytical value of the alarm. In system implementation, this function can be implemented by an event processing unit 209 located in user space.

[0118] Example 6

[0119] The method and system of this application can be implemented on an electronic device. See also Figure 8 The diagram shows a hardware structure block diagram of the electronic device 800.

[0120] The electronic device 800 can be a server, a personal computer, a virtual machine, or any other computing device. It includes one or more processors 801, memory 802, and one or more network interfaces 803. These components communicate via a bus system 804 or other forms of connection mechanism.

[0121] The processor 801 is the computing core of the electronic device 800, and can be a central processing unit, a graphics processing unit, or an application-specific integrated circuit, etc.

[0122] Memory 802 is used to store data and computer programs. It can be volatile memory and / or non-volatile memory. The computer programs stored in memory 802, when executed by processor 801, enable electronic device 800 to implement the port scanning detection method described in the foregoing embodiments. For example, the code of user-mode daemon process 310 and the bytecode of eBPF program are both stored in memory 802.

[0123] Network interface 803 is used by electronic device 800 to communicate with other devices or networks. Network connection requests received by the host and abnormal events reported are transmitted through network interface 803.

[0124] Those skilled in the art will understand that Figure 8 This is merely one example of an electronic device 800 and does not constitute a limitation of this application. Actual electronic devices may include more or fewer components than those shown in the figure, or may have different component configurations.

[0125] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the port scanning detection method described in any of the foregoing embodiments. The computer-readable storage medium can be any electronic, magnetic, optical, or other physical device capable of storing program code, such as random access memory, read-only memory, EPROM, flash drive, hard disk, etc.

[0126] This application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the port scanning detection method described in any of the foregoing embodiments.

[0127] Example 7

[0128] For large-scale distributed network environments, this application also provides a distributed port scanning detection system. This system consists of multiple "host-side detection subsystems" (i.e., host agents in the aforementioned embodiments) deployed on various service hosts within the network, and a "central analysis platform" deployed at the management end.

[0129] In actual operation, although the detection subsystem on a single host can detect scanning behavior targeting itself, it often fails to see the full picture of "low-frequency slow scans" or "distributed scans". For example, an attacker may scan only one port on host A and only one port on host B, which is easily overlooked from a single-machine perspective.

[0130] To address this issue, the central analysis platform in this embodiment is configured to receive abnormal events reported by all host-side detection subsystems. The platform maintains a global sliding time window (e.g., 5 minutes). The platform aggregates and analyzes events from different hosts based on the "source IP address" as the primary key.

[0131] The specific logic for association and aggregation is as follows:

[0132] If the central analysis platform receives abnormal connection requests (i.e., access to non-listening ports) from the same source IP address (e.g., 192.168.1.100) targeting at least N (e.g., N greater than or equal to 3) different hosts within a preset time window, the central analysis platform will determine that the source IP address is performing "lateral movement scanning" or "distributed probing" even if the source IP only initiates a probe to each host once.

[0133] After the determination, the central analysis platform can issue a global blocking command, notifying all host-side detection subsystems within the network to add the malicious source IP to their respective local blacklists (refer to the second eBPF Map in Implementation Example 3), thereby achieving the joint prevention and control effect of "one-point discovery, network-wide blocking".

[0134] In summary, this application utilizes eBPF technology in kernel mode to construct a dynamic, real-time, low-overhead, and difficult-to-avoid port scanning detection system. It can not only accurately detect scanning behavior but also effectively enhance the host's security capabilities through advanced features such as deceptive responses and proactive defense.

[0135] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A port scanning detection method, characterized in that, include: Load and run an extended Berkeley Packet Filter (eBPF) program on the host, the eBPF program comprising a first eBPF program and a second eBPF program; Create the first eBPF Map to store information about legitimate listening ports, and an event reporting channel for communication between kernel mode and user mode; The first eBPF program is hooked to the first kernel function associated with the host port listening behavior; when the service process on the host initiates port listening, the first eBPF program is triggered to extract the port number being listened to and store it in the first eBPFMap, and dynamically construct a whitelist of legal listening ports. The second eBPF program is hooked to a second kernel function associated with network connection establishment behavior; when the host receives a network connection request, the second eBPF program is triggered to extract the destination port number of the network connection request; Use the destination port number to query the first eBPF Map; If no record matching the destination port number is found in the first eBPF Map, the network connection request is determined to be an abnormal scanning event, and the connection information of the abnormal scanning event is collected and sent to the user-space daemon process through the event reporting channel.

2. The method according to claim 1, characterized in that, The first kernel function is the `listen` system call; optionally, the second kernel function is the `accept` system call; optionally, the second kernel function is replaced by the `tcp_v4_rcv` kernel function or the `sock:inet_sock_set_state` tracepoint; optionally, the connection information includes at least: the attack source IP address, the attack source port number, the destination port number, the transport layer protocol type, and the timestamp of the event; optionally, the event reporting channel is an eBPF Ring Buffer or an eBPF Perf Buffer.

3. The method according to claim 1, characterized in that, After determining that the event is an abnormal scan, the process further includes executing a deceptive response mechanism. This mechanism causes the network connection request for a non-listening port to be disconnected after completing the Transmission Control Protocol (TCP) three-way handshake due to a timeout while waiting for application layer processing. Optionally, the deceptive response mechanism specifically involves: after the second eBPF program determines that the event is an abnormal scan, not injecting any rejection or reset messages into the kernel protocol stack, allowing the network connection request to time out in the kernel's half-connection queue due to exceeding the number of retries defined by the kernel parameter `tcp_synack_retries`; the value of the kernel parameter `tcp_synack_retries` ranges from 3 to 8.

4. The method according to claim 1, characterized in that, Also includes: Create a second eBPF Map to store the IP addresses of the attack sources; After determining that it is an abnormal scanning event, the attack source IP address in the connection information is stored in the second eBPFMap to construct an attack source blacklist; Load and run a third eBPF program, which is hooked to the host’s network packet receiving path; according to the second eBPF Map, discard all subsequent network packets whose source IP address is in the attack source blacklist. Optionally, the network data packet receiving path is either the eXpress Data Path entry point or the Traffic Control entry point; Optionally, the step of storing the attack source IP address into the second eBPF Map includes: Set preset time window and preset frequency threshold ; In the time window Within this context, when the number of abnormal scanning events received by the daemon from the same attack source IP address exceeds the frequency threshold... Only then is the IP address of the attack source written into the second eBPF Map, wherein the... The value range is from 5 seconds to 60 seconds. The value range is from 10 to 100.

5. The method according to claim 1, characterized in that, The method is also used to detect UDP port scans, and further includes: Load and run a fourth eBPF program, which is hooked to a third kernel function associated with UDP packet reception behavior; When the fourth eBPF procedure is triggered, the destination port number of the UDP packet is extracted, and the first eBPFMap is queried; If the query fails, it is determined to be an abnormal scan event for the UDP protocol, and reported through the event reporting channel. Optionally, the third kernel function is either the `recvfrom` system call or the `recvmsg` system call.

6. The method according to claim 1, characterized in that, After receiving the connection information, the daemon process also includes steps of aggregating and deduplicating abnormal scanning events; Optionally, the aggregation and deduplication process includes: the daemon process uses a triplet consisting of the source IP address, destination port number, and protocol type of the connection information as a unique key to maintain an event counter and a first occurrence timestamp in memory; for subsequent abnormal scan events received, if the triplet already exists, the event counter is incremented and the last occurrence timestamp is updated; an aggregated alarm log is generated only when the count value reaches a preset reporting threshold for the first time or when the time since the first occurrence exceeds a preset reporting period.

7. A port scanning detection system, characterized in that, include: The loading unit is used to load and run an eBPF program on the host, the eBPF program including a first eBPF program and a second eBPF program, and to create a first eBPF Map for storing information on legitimate listening ports and an event reporting channel for communication between kernel mode and user mode. The whitelist building unit is configured to capture the port number being listened to and store it in the first eBPF Map when the service process on the host initiates port listening, by hooking the first eBPF program to the first kernel function, so as to dynamically build a whitelist of legal listening ports. The first kernel function is associated with the host port listening behavior. The real-time detection unit is configured to extract the destination port number of a network connection request when the host receives such a request via the second eBPF program hooked to the second kernel function. The second kernel function is associated with the network connection establishment behavior. The scanning determination unit is configured to use the destination port number to query the first eBPF Map. If no matching record is found in the first eBPF Map, the network connection request is determined to be an abnormal scanning event. The event reporting unit is configured to collect the connection information of an abnormal scanning event after it is determined to be an abnormal scanning event, and send the connection information to the user-space daemon process through the event reporting channel; optionally, the first kernel function is the `listen` system call and the second kernel function is the `accept` system call; Optionally, the connection information includes at least: the attack source IP address, the attack source port number, the destination port number, the transport layer protocol type, and the timestamp of the event. Optionally, the system further includes a response control unit configured to execute a deceptive response mechanism after determining that an abnormal scanning event has occurred, causing the network connection request to be disconnected due to a timeout while waiting for application layer processing after completing the three-way handshake of the Transmission Control Protocol (TCP). Optionally, the deceptive response mechanism specifically involves: after the second eBPF program determines that an abnormal scanning event has occurred, not injecting any rejection or reset messages into the kernel protocol stack, allowing the network connection request to time out in the kernel's half-connection queue due to exceeding the number of retries defined by the kernel parameter `tcp_synack_retries`. Optionally, the event reporting channel is an eBPF Ring Buffer or an eBPF Perf. Buffer; Optionally, the system further includes an event processing unit located in user space, configured to aggregate and deduplicate the received abnormal scanning events; Optionally, the event processing unit is specifically configured to: maintain an event counter and a first occurrence timestamp in memory based on a triplet consisting of the source IP address, destination port number, and protocol type of the connection information as a unique key; for subsequent abnormal scanning events received, if the triplet already exists, only the count value of the event counter is incremented and the last occurrence timestamp is updated, and an aggregated alarm log is generated only when the count value first reaches a preset reporting threshold or the time since the first occurrence exceeds a preset reporting period.

8. The system according to claim 7, characterized in that, Also includes: The active defense unit is configured to create a second eBPF Map for storing the IP addresses of attack sources. After determining that it is an abnormal scanning event, the attack source IP address in the connection information is stored in the second eBPF Map to construct an attack source blacklist; And a third eBPF program, hooked to the host network packet receiving path, discards all subsequent network packets whose source IP addresses are in the attack source blacklist according to the second eBPFMap; optionally, the network packet receiving path is a Fast Data Path (XDP) ingress or a Flow Control (TC) ingress; optionally, the proactive defense unit is further configured to: Set preset time window and preset frequency threshold ; In the time window Within this context, when the number of abnormal scanning events received by the daemon from the same attack source IP address exceeds the frequency threshold... Only then is the IP address of the attack source written into the second eBPF Map.

9. The system according to claim 7, characterized in that, The system is also used to detect UDP port scans, and includes: The UDP detection unit is configured to extract the destination port number of a received UDP packet by hooking to a fourth eBPF program that is associated with a third kernel function related to UDP packet reception behavior, query the first eBPF Map, and if the query does not find a match, it is determined to be an abnormal scanning event for the UDP protocol and reported.

10. A distributed port scanning detection system, characterized in that, include: Multiple host subsystems deployed on different hosts are configured to use eBPF programs to capture abnormal connection requests to non-listening ports in real time and report abnormal events. A central analysis platform is communicatively connected to the multiple host subsystems and configured to receive the abnormal events and perform correlation aggregation of abnormal events from different host subsystems based on the source IP address. If the central analysis platform receives abnormal connection requests from the same source IP address to multiple different hosts within a preset time window, it determines that the source IP address is performing a lateral movement scan.

11. An electronic device, comprising: A memory, a processor, and a computer program stored on the memory, characterized in that the processor executes the computer program to implement the method as described in any one of claims 1 to 6.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

13. A computer program product comprising computer instructions, characterized in that, When the instructions are executed by the processor, they implement the method as described in any one of claims 1 to 6.

Images