Host micro honeypot implementation method and system based on eBPF mechanism and related products
By using the kernel-level user service port awareness module and the application-level port malicious scanning decoy module of the eBPF mechanism, conflicting decoy port listening is identified and avoided, solving the problem of port conflicts affecting user services in host honeypots and achieving transparent and flexible detection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-28
- Publication Date
- 2026-04-03
AI Technical Summary
In existing host-based honeypot detection methods, the decoy port and the user's service port are prone to conflict, affecting the normal operation of the user's services.
The system employs a kernel-level user service port awareness module and an application-level port malicious scanning decoy module based on the eBPF mechanism. By intercepting kernel-level listening interface functions, it identifies target service port information and determines conflict-free decoy ports among multiple service ports for listening, thus achieving transparent and flexible micro-honeypot detection.
It resolves the conflict between decoy ports and user service ports, ensuring the normal operation of user services, and achieves efficient detection of malicious port scanning behavior.
Smart Images
Figure CN121792115A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the technical field of port listening, specifically relating to a host micro honeypot implementation method, system, and related products based on the eBPF mechanism; wherein, the related products may include a host micro honeypot implementation device based on the eBPF mechanism, an electronic device, and a computer-readable storage medium. Background Technology
[0002] Host-based honeypots primarily detect malicious port scanning behavior, with lower resource consumption and risk, making them suitable for deployment and execution on user hosts.
[0003] The main existing detection method for malicious port scanning is to install application-layer software on the host to listen to the decoy port, analyze the data packets sent by the scanning software, and report the analyzed malicious scanning events to the security operations platform. However, this method has the problem of conflict between the listening port of the honeypot and the port used by the user's own business. Summary of the Invention
[0004] In view of the above problems, a host-based honeypot implementation method, system, and related products based on the eBPF mechanism are proposed to overcome or at least partially solve the above problems, including: A host-based honeypot implementation method based on the eBPF mechanism is applied to the kernel layer of the host. The kernel layer deploys a kernel-level user service port awareness module, and the application layer of the host deploys an application-level port malicious scanning decoy module. The method includes: The application layer port malicious scanning decoy module receives the target service port information reported by the kernel layer user service port awareness module; the target service port information is determined by the kernel layer user service port awareness module based on the target structure corresponding to the intercepted listening interface function in the kernel layer. Based on the target service port information, a decoy port to be monitored is determined from multiple service ports, and monitoring is performed on the decoy port to be monitored.
[0005] In some embodiments, determining the decoy port to be monitored from multiple service ports based on the target service port information includes: Based on the target service port information, determine the target port and determine whether there is a listening conflict on the target port; When there is a listening conflict at the target port, the decoy port to be monitored is determined from other ports; When there is no listening conflict on the target port, the target port is used as the decoy port to be monitored.
[0006] In some embodiments, after determining the decoy port to be monitored, the method further includes: Send feedback information to the kernel layer user service port awareness module; The kernel-level user service port awareness module is used to return the listening interface function based on the feedback information.
[0007] In some embodiments, the host includes a user service cloud host and a user non-service cloud host. The kernel layer of the user service cloud host is equipped with a kernel-layer user service port awareness module, and the application layer of the user service cloud host is equipped with an application-layer port malicious scanning decoy module. The user non-service cloud host is equipped with a malicious behavior alarm management backend. The method further includes: The malicious behavior alarm management backend reports malicious scanning behavior alarm events to the malicious behavior alarm management backend; the malicious behavior alarm management backend is used to send scanning event handling instructions to the application layer port malicious scanning decoy module based on the malicious scanning behavior alarm events; In response to the scan event handling command, the decoy port to be monitored is processed.
[0008] This application embodiment also provides a host-based honeypot implementation method based on the eBPF mechanism, applied to the kernel layer of the host, wherein the kernel layer deploys a kernel layer user service port awareness module, and the application layer of the host deploys an application layer port malicious scanning decoy module; the method includes: The kernel-layer user service port awareness module intercepts the listening interface function in the kernel layer and determines the target service port information based on the target structure corresponding to the listening interface function. The target service port information is sent to the application layer port malicious scanning decoy module; the application layer port malicious scanning decoy module is used to release conflicting ports according to the target service port information; Return to the listening interface function.
[0009] This application embodiment also provides a host-based honeypot implementation system based on the eBPF mechanism. The system includes a host, the kernel layer of which is deployed with a kernel layer user service port awareness module, and the application layer of which is deployed with an application layer port malicious scanning decoy module. The kernel-layer user service port awareness module is used to intercept the listening interface function in the kernel layer and determine the target service port information based on the target structure corresponding to the listening interface function. The application layer port malicious scanning decoy module is used to receive target service port information reported by the kernel layer user service port awareness module; based on the target service port information, it determines the decoy port to be monitored from multiple service ports, and monitors the decoy port to be monitored.
[0010] In some embodiments, the host includes a user business cloud host and a user non-business cloud host. The kernel layer of the user business cloud host is equipped with a kernel layer user business port awareness module, and the application layer of the user business cloud host is equipped with an application layer port malicious scanning decoy module. The user non-business cloud host is equipped with a malicious behavior alarm management backend. The application layer port malicious scanning decoy module is also used to report malicious scanning behavior alarm events to the malicious behavior alarm management backend; The malicious behavior alarm management backend is used to send a scanning event handling instruction to the application layer port malicious scanning decoy module based on the malicious scanning behavior alarm event; The application layer port malicious scanning decoy module is also used to process the decoy port to be monitored in response to the scanning event handling instruction.
[0011] This application embodiment also provides a host-based honeypot implementation device based on the eBPF mechanism, applied to the kernel layer of the host. The kernel layer deploys a kernel-level user service port awareness module, and the application layer of the host deploys an application-level port malicious scanning decoy module. The device includes: The receiving module is used by the application layer port malicious scanning decoy module to receive the target service port information reported by the kernel layer user service port awareness module; the target service port information is determined by the kernel layer user service port awareness module based on the target structure corresponding to the intercepted listening interface function in the kernel layer. The monitoring module is used to determine the decoy port to be monitored from multiple service ports based on the target service port information, and to monitor the decoy port to be monitored.
[0012] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described host honeypot implementation method based on the eBPF mechanism.
[0013] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described host honeypot implementation method based on the eBPF mechanism.
[0014] The embodiments of this application have the following advantages: In this embodiment, the application-layer port malicious scanning decoy module receives target service port information reported by the kernel-layer user service port awareness module. The target service port information is determined by the kernel-layer user service port awareness module based on the target structure corresponding to the intercepted listening interface function in the kernel layer. Based on the target service port information, the decoy port to be monitored is determined from multiple service ports, and monitoring is performed on the decoy port. This embodiment, based on the Linux kernel eBPF mechanism, implements a more transparent and flexible method for detecting security penetration events using micro-honeypots, solving the problem of conflicts between decoy ports and user service ports in port micro-honeypot technology, which affects the normal operation of user services. Attached Figure Description
[0015] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating the steps of a host-based honeypot implementation method based on the eBPF mechanism according to an embodiment of this application. Figure 2 This is a flowchart illustrating another method for implementing a host honeypot based on the eBPF mechanism according to an embodiment of this application. Figure 3 This is a flowchart illustrating the steps of another host-based honeypot implementation method based on the eBPF mechanism in this application embodiment; Figure 4 This is a schematic diagram of the structure of a host micro honeypot implementation system based on an embodiment of the eBPF mechanism in this application; Figure 5 This is a data interaction diagram of a host-based honeypot implementation system based on the eBPF mechanism, according to an embodiment of this application. Figure 6 This is a schematic diagram of data interaction in another host-based honeypot implementation system based on the eBPF mechanism, according to an embodiment of this application. Figure 7 This is a schematic diagram of a host micro honeypot implementation device based on the eBPF mechanism according to an embodiment of this application; Figure 8 This is a schematic diagram of another host micro honeypot implementation device based on the eBPF mechanism in an embodiment of this application. Detailed Implementation
[0016] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0017] Micro honeypots are small honeypot technologies in the network security field that adapt to the needs of lightweight and granular protection. They are often deployed in a modular and distributed manner, and their core purpose is to accurately capture attack behaviors and collect targeted threat intelligence. Compared with traditional honeypots, micro honeypots mainly detect malicious port scanning behavior, with lower resource overhead and risk, making them suitable for deployment and execution on user hosts. In practical applications, the ability to detect user business ports only takes effect after successful port listening. However, listening itself cannot succeed when there is a conflict. Based on this, this application proposes a host micro honeypot implementation method based on the eBPF mechanism. It can implement a more transparent and flexible micro honeypot listening and detection technique for security penetration events based on the Linux kernel eBPF mechanism, solving the problem of conflict between decoy ports and user business ports in port micro honeypot technology, which affects the normal operation of user services.
[0018] In some embodiments of this application, reference may be made to Figure 1 , Figure 1 The flowchart illustrates the steps of a host honeypot implementation method based on the eBPF mechanism according to an embodiment of this application.
[0019] like Figure 1 As shown, the host-based honeypot implementation method based on the eBPF mechanism may include the following steps: Step 101: The application layer port malicious scanning decoy module receives the target service port information reported by the kernel layer user service port awareness module; the target service port information is determined by the kernel layer user service port awareness module based on the target structure corresponding to the intercepted listening interface function in the kernel layer.
[0020] In this embodiment, eBPF (extended BerkeleyPacketFilter) can refer to a virtual machine technology running in the Linux kernel. It first appeared in the Linux kernel in 2014 and has matured after several iterations. It provides a flexible and secure way to extend kernel functionality.
[0021] The Linux kernel is modular, which allows code to be dynamically inserted into or removed from the kernel at runtime. This kernel code is compiled together into a single binary file, known as the Linux kernel module.
[0022] In some embodiments, the host may include a kernel layer and an application layer; wherein, the kernel layer of the host may deploy a kernel layer user service port awareness module through the eBPF mechanism; the user layer may deploy an application layer port malicious scanning decoy module, which can be used by the honeypot process to detect malicious port scanning behavior.
[0023] In practical applications, the kernel-layer user service port awareness module deployed at the kernel layer is mainly responsible for sensing the port listening of the user's own service and triggering the adjustment of the port listened to by the honeypot to avoid the user service port, thereby avoiding the impact on the user service.
[0024] Specifically, the kernel-level user service port awareness module deployed at the kernel layer can intercept listening interface functions in the kernel layer; for example, the kernel-level user service port awareness module deployed at the kernel layer can intercept system calls of the listening interface functions of sockets in the kernel layer through the eBPF mechanism, that is, the kernel system network listening interface, such as intercepting the inet_listen() function in the kernel.
[0025] Then, the kernel-level user service port awareness module can identify the target structure corresponding to the listening interface function to obtain the target service port information, that is, the port information currently used as a user service port. For example, this could be the port identifier of these ports; however, this embodiment does not limit this.
[0026] After obtaining the target service port information, the kernel-level user service port awareness module can transmit it to the application-level port malicious scanning decoy module through application-layer and kernel-layer communication channels such as netlink.
[0027] Step 102: Based on the target service port information, determine the decoy port to be monitored from multiple service ports, and monitor the decoy port to be monitored.
[0028] After receiving the target service port information, the application layer port malicious scanning decoy module can determine the port that is not currently conducting user services from multiple service ports based on the target service port information, and identify it as the decoy port to be monitored.
[0029] After identifying the decoy port to be monitored, the honeypot process can be triggered to detect malicious port scanning behavior on the decoy port to be monitored. This application embodiment does not limit this.
[0030] In this embodiment, the application-layer port malicious scanning decoy module receives target service port information reported by the kernel-layer user service port awareness module. The target service port information is determined by the kernel-layer user service port awareness module based on the target structure corresponding to the intercepted listening interface function in the kernel layer. Based on the target service port information, the decoy port to be monitored is determined from multiple service ports, and monitoring is performed on the decoy port. This embodiment, based on the Linux kernel eBPF mechanism, implements a more transparent and flexible method for detecting security penetration events using micro-honeypots, solving the problem of conflicts between decoy ports and user service ports in port micro-honeypot technology, which affects the normal operation of user services.
[0031] Reference Figure 2 The diagram illustrates another implementation method for a host honeypot based on the eBPF mechanism according to an embodiment of this application, which may include the following steps: Step 201: The application layer port malicious scanning decoy module receives the target service port information reported by the kernel layer user service port awareness module.
[0032] In some embodiments, the kernel-layer user service port awareness module deployed at the kernel layer is mainly responsible for sensing the port listening of the user's own service and triggering the adjustment of the port listened to by the honeypot to avoid the user service port, thereby avoiding the impact on the user service.
[0033] Specifically, the kernel-level user service port awareness module deployed in the kernel layer can intercept listening interface functions in the kernel layer.
[0034] Then, the kernel-level user service port awareness module can identify the target structure corresponding to the listening interface function to obtain the target service port information.
[0035] After obtaining the target service port information, the kernel-level user service port awareness module can transmit it to the application-level port malicious scanning decoy module through application-layer and kernel-layer communication channels such as netlink.
[0036] Step 202: Based on the target service port information, determine the target port and check whether there is a listening conflict on the target port.
[0037] After receiving the target service port information, the application layer port malicious scanning decoy module can determine the port that is not currently conducting user services from multiple service ports based on the target service port information, and identify it as the decoy port to be monitored.
[0038] In some embodiments, after receiving the target service port information, the application layer port malicious scanning decoy module can first identify the target service port information to determine the corresponding target port; then, the application layer port malicious scanning decoy module can determine whether there is a listening conflict for the target port corresponding to the target service port information based on the current port that needs to be used as a decoy port; that is, whether the target port is the port that needs to be used as a decoy port.
[0039] Step 203: When there is a listening conflict on the target port, determine the decoy port to be listened to from other ports.
[0040] For example, if the target port is the port that needs to be used as a decoy port, it can be determined that the target port has a listening conflict. In this case, in order to avoid affecting the normal operation of user services, the decoy port to be listened to can be determined from other ports that do not have listening conflicts.
[0041] Step 204: When there is no listening conflict on the target port, use the target port as the decoy port to be listened to.
[0042] Conversely, if the target port is not the port that needs to be used as the decoy port, it can be determined that there is no listening conflict on the target port; in this case, the target port can be directly used as the decoy port to be listened to.
[0043] Step 205: Monitor the decoy port to be monitored.
[0044] After identifying the decoy port to be monitored, the honeypot process can be triggered to detect malicious port scanning behavior on the decoy port to be monitored. This application embodiment does not limit this.
[0045] In some embodiments of this application, after determining the decoy port to be monitored, the above method may further include the following steps: Feedback information is sent to the kernel-level user service port awareness module; the kernel-level user service port awareness module is used to return a listening interface function based on the feedback information.
[0046] In some embodiments, after the application layer port malicious scanning decoy module determines the decoy port to be monitored and completes the monitoring of the decoy port, it can send feedback information to the kernel layer user service port awareness module to indicate that the monitoring has been completed.
[0047] After receiving feedback information, the kernel-level user service port awareness module can return the intercepted listening interface function, so that the user service process can listen to the required service port normally without being aware of it.
[0048] In some embodiments of this application, the host includes a user business cloud host and a user non-business cloud host. The kernel layer of the user business cloud host is equipped with a kernel layer user business port awareness module, and the application layer of the user business cloud host is equipped with an application layer port malicious scanning decoy module. The user non-business cloud host is equipped with a malicious behavior alarm management backend. Based on this, the above method may further include the following steps: Report malicious scanning behavior alarm events to the malicious behavior alarm management backend; the malicious behavior alarm management backend is used to send scanning event handling instructions to the application layer port malicious scanning decoy module based on the malicious scanning behavior alarm events; in response to the scanning event handling instructions, process the decoy port to be monitored.
[0049] In some embodiments, the host may include user business cloud hosts and user non-business cloud hosts; wherein, user business cloud hosts are used to directly host the enterprise's productive business and are the infrastructure supporting the enterprise's core operations. User non-business cloud hosts are used for non-productive scenarios such as business assistance, testing, and management, and do not directly participate in the external services of core business.
[0050] In this embodiment, the kernel-layer user service port awareness module and the application-layer port malicious scanning decoy module can be deployed in the user service cloud host, and the user non-service cloud host can be deployed with a malicious behavior alarm management backend.
[0051] The malicious behavior alert management backend is responsible for collecting port malicious scanning behavior alert events reported by the application-layer port malicious scanning decoy module, determining the attack source address, and notifying users of the alerts. Users can then take appropriate action based on the relevant information. Malicious scanning behavior alert events refer to the process of detecting unauthorized probing and scanning behavior of external or internal entities on target hosts, ports, services, vulnerabilities, etc., and triggering an alert.
[0052] The malicious behavior alarm management backend can also issue scanning event handling instructions to the application layer port malicious scanning decoy module for processing. The scanning event handling instructions can refer to the handling instructions generated for malicious scanning behavior alarm events, and can include actions to be performed, such as configuring firewall policies to block the network, etc., which are not limited in this embodiment.
[0053] In this embodiment, the application-layer port malicious scanning decoy module receives target service port information reported by the kernel-layer user service port awareness module; based on the target service port information, it determines the target port and judges whether the target port has a listening conflict; when the target port has a listening conflict, it determines the decoy port to be monitored from other ports; when the target port does not have a listening conflict, it uses the target port as the decoy port to be monitored; and it monitors the decoy port to be monitored. This embodiment can use the Linux kernel eBPF mechanism to detect the service port that the user is about to monitor (but has not yet been monitored) in real time, so that the user service can complete the monitoring of the conflicting port normally without being aware of it. In addition, through communication and interaction between the kernel and application layers, the ability to automatically release the decoy port of the honeypot and relisten on other ports is realized.
[0054] The above mainly describes the implementation method of host micro-honeypot based on the eBPF mechanism from the perspective of the application layer port malicious scanning decoy module. To further clarify this application, the following describes the implementation method of host micro-honeypot based on the eBPF mechanism from the perspective of the kernel layer user service port awareness module: Reference Figure 3 The diagram illustrates a flowchart of another host honeypot implementation method based on the eBPF mechanism according to an embodiment of this application, which may include the following steps: Step 301: The kernel-level user service port awareness module intercepts the listening interface function in the kernel layer and determines the target service port information based on the target structure corresponding to the listening interface function.
[0055] In this embodiment of the application, the kernel layer user service port awareness module deployed in the kernel layer is mainly responsible for sensing the port listening of the user's own service and triggering the adjustment of the port listened to by the honeypot to avoid the user service port, thereby avoiding the impact on the user service.
[0056] Specifically, the kernel-level user service port awareness module deployed in the kernel layer can intercept listening interface functions in the kernel layer.
[0057] Then, the kernel-level user service port awareness module can identify the target structure corresponding to the listening interface function to obtain the target service port information.
[0058] After obtaining the target service port information, the kernel-level user service port awareness module can transmit it to the application-level port malicious scanning decoy module through application-layer and kernel-layer communication channels such as netlink.
[0059] Step 302: Send the target service port information to the application layer port malicious scanning decoy module; the application layer port malicious scanning decoy module is used to release conflicting ports based on the target service port information.
[0060] After receiving the target service port information, the application layer port malicious scanning decoy module can determine the port that is not currently conducting user services from multiple service ports based on the target service port information, and identify it as the decoy port to be monitored.
[0061] In some embodiments, after receiving the target service port information, the application layer port malicious scanning decoy module can first identify the target service port information to determine the corresponding target port; then, the application layer port malicious scanning decoy module can determine whether there is a listening conflict for the target port corresponding to the target service port information based on the current port that needs to be used as a decoy port; that is, whether the target port is the port that needs to be used as a decoy port.
[0062] If the target port is the port that needs to be used as the decoy port, it can be determined that the target port has a listening conflict. In this case, in order to avoid affecting the normal operation of user services, the decoy port to be listened to can be determined from other ports that do not have listening conflicts.
[0063] Conversely, if the target port is not the port that needs to be used as the decoy port, it can be determined that there is no listening conflict on the target port; in this case, the target port can be directly used as the decoy port to be listened to.
[0064] After identifying the decoy port to be monitored, the honeypot process can be triggered to detect malicious port scanning behavior on the decoy port to be monitored. This application embodiment does not limit this.
[0065] Step 303: Return to the listening interface function.
[0066] In some embodiments, after the application layer port malicious scanning decoy module determines the decoy port to be monitored and completes the monitoring of the decoy port, it can send feedback information to the kernel layer user service port awareness module to indicate that the monitoring has been completed.
[0067] After receiving feedback information, the kernel-level user service port awareness module can return the intercepted listening interface function, so that the user service process can listen to the required service port normally without being aware of it.
[0068] In this embodiment, the kernel-layer user service port awareness module intercepts the listening interface function in the kernel layer and determines the target service port information based on the target structure corresponding to the listening interface function; the target service port information is sent to the application-layer port malicious scanning decoy module; the application-layer port malicious scanning decoy module is used to release the conflicting port based on the target service port information; and returns the listening interface function. This embodiment can utilize the Linux kernel eBPF mechanism to detect in real time the service port that the user is about to listen to (but has not yet been listened to), allowing the user service to complete the listening to the conflicting port normally without being aware of it. In addition, through communication and interaction between the kernel and application layers, the ability to automatically release the decoy port of the honeypot and relisten on other ports is realized.
[0069] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.
[0070] Based on the above method, this application also provides a host-based honeypot implementation system based on the eBPF mechanism. For details, please refer to... Figure 4 , Figure 4 This paper illustrates a schematic diagram of a host micro honeypot implementation system based on an embodiment of the eBPF mechanism of this application; as shown... Figure 4 As shown, the host micro honeypot implementation system of this eBPF mechanism can include a host, the kernel layer of which is equipped with a kernel layer user service port awareness module 410, and the application layer of which is equipped with an application layer port malicious scanning decoy module 420. The kernel-level user service port awareness module 410 is used to intercept the listening interface function in the kernel layer and determine the target service port information based on the target structure corresponding to the listening interface function. The application layer port malicious scanning decoy module 420 is used to receive target service port information reported by the kernel layer user service port awareness module 410; based on the target service port information, it determines the decoy port to be monitored from multiple service ports, and monitors the decoy port to be monitored.
[0071] In this embodiment, the kernel layer user service port awareness module 410 deployed in the kernel layer is mainly responsible for sensing the port listening of the user's own service and triggering the adjustment of the port being listened to by the honeypot to avoid the user service port, thereby avoiding the impact on the user service.
[0072] Specifically, the kernel-level user service port awareness module 410, deployed in the kernel layer, can intercept listening interface functions in the kernel layer.
[0073] Then, the kernel-level user service port awareness module 410 can identify the target structure corresponding to the listening interface function to obtain the target service port information.
[0074] After obtaining the target service port information, the kernel-level user service port awareness module 410 can transmit it to the application-level port malicious scanning decoy module 420 through application-level and kernel-level communication channels such as netlink.
[0075] After receiving the target service port information, the application layer port malicious scanning decoy module 420 can determine the port that is not currently conducting user services from multiple service ports based on the target service port information, and identify it as the decoy port to be monitored.
[0076] In some embodiments, after receiving the target service port information, the application layer port malicious scanning decoy module 420 can first identify the target service port information to determine the corresponding target port; then, the application layer port malicious scanning decoy module 420 can determine whether there is a listening conflict for the target port corresponding to the target service port information based on the current port that needs to be used as a decoy port; that is, whether the target port is the port that needs to be used as a decoy port.
[0077] If the target port is the port that needs to be used as the decoy port, it can be determined that the target port has a listening conflict. In this case, in order to avoid affecting the normal operation of user services, the decoy port to be listened to can be determined from other ports that do not have listening conflicts.
[0078] Conversely, if the target port is not the port that needs to be used as the decoy port, it can be determined that there is no listening conflict on the target port; in this case, the target port can be directly used as the decoy port to be listened to.
[0079] After identifying the decoy port to be monitored, the honeypot process can be triggered to detect malicious port scanning behavior on the decoy port to be monitored. This application embodiment does not limit this.
[0080] In some embodiments, after determining the decoy port to be monitored and completing the monitoring of the decoy port, the application layer port malicious scanning decoy module 420 can send feedback information to the kernel layer user service port awareness module 410 to indicate that the monitoring has been completed.
[0081] After receiving feedback information, the kernel-level user service port awareness module 410 can return the intercepted listening interface function, so that the user service process can listen to the required service port normally without being aware of it.
[0082] In some embodiments of this application, the host includes a user business cloud host and a user non-business cloud host. The kernel layer of the user business cloud host is equipped with a kernel layer user business port awareness module 410, and the application layer of the user business cloud host is equipped with an application layer port malicious scanning decoy module 420. The user non-business cloud host is equipped with a malicious behavior alarm management backend. The application layer port malicious scanning decoy module 420 is also used to report malicious scanning behavior alarm events to the malicious behavior alarm management backend; The malicious behavior alarm management backend is used to send scanning event handling instructions to the malicious scanning decoy module 420 at the application layer port based on malicious scanning behavior alarm events; The application layer port malicious scanning decoy module 420 is also used to process the decoy port to be monitored in response to scanning event handling instructions.
[0083] In this embodiment, the host may include a user business cloud host and a user non-business cloud host. The user business cloud host is used to directly host the enterprise's productive business and is the infrastructure supporting the enterprise's core operations. The user non-business cloud host is used for non-productive scenarios such as business assistance, testing, and management, and does not directly participate in external services for core business.
[0084] In this embodiment, the kernel-layer user service port awareness module 410 and the application-layer port malicious scanning decoy module 420 can be deployed in the user service cloud host, and the user non-service cloud host can be deployed with a malicious behavior alarm management backend.
[0085] The malicious behavior alarm management backend is responsible for collecting port malicious scanning behavior alarm events reported by the application layer port malicious scanning decoy module 420, determining the attack source address, and notifying users of the alarms. Users can then take appropriate action based on the relevant information. A malicious scanning behavior alarm event refers to the process of detecting unauthorized probing and scanning behavior of external or internal entities on target hosts, ports, services, vulnerabilities, etc., and triggering an alarm.
[0086] The malicious behavior alarm management backend can also issue scanning event handling instructions to the application layer port malicious scanning decoy module 420 for handling. The scanning event handling instructions can refer to the handling instructions generated for malicious scanning behavior alarm events, and can include actions to be performed, such as configuring firewall policies to block the network, etc., which are not limited in this embodiment.
[0087] In this embodiment, the host's kernel layer deploys a kernel layer user service port awareness module 410, and the host's application layer deploys an application layer port malicious scanning decoy module 420. The kernel layer user service port awareness module 410 intercepts listening interface functions in the kernel layer and determines the target service port information based on the target structure corresponding to the listening interface function. The application layer port malicious scanning decoy module 420 receives the target service port information reported by the kernel layer user service port awareness module 410; based on the target service port information, it determines the decoy port to be monitored from multiple service ports and monitors the decoy port to be monitored. This embodiment can utilize the Linux kernel eBPF mechanism to detect in real time the service ports that the user is about to monitor (but has not yet been monitored), allowing the user service to complete the monitoring of conflicting ports normally without being aware of it. In addition, through communication and interaction between the kernel and application layers, the ability to automatically release the decoy port of the honeypot and relisten on other ports is realized.
[0088] Reference Figure 5 This diagram illustrates a data interaction schematic of a host-based honeypot implementation system based on the eBPF mechanism, according to an embodiment of this application; see reference. Figure 6 This diagram illustrates another data interaction schematic of a host honeypot implementation system based on the eBPF mechanism, according to an embodiment of this application.
[0089] The system includes user business cloud hosts and user non-business cloud hosts. The kernel layer of the user business cloud host is equipped with a kernel layer user business port awareness module, and the application layer of the user business cloud host is equipped with an application layer port malicious scanning decoy module. The user non-business cloud host is equipped with a malicious behavior alarm management backend.
[0090] 1) Application-layer port malicious scanning decoy module: This module creates a socket at the application layer to listen for incoming malicious scanning behavior based on a preset list of TCP / UDP decoy ports, and sends malicious scanning behavior alarm events to the malicious behavior alarm management backend. 2) Kernel layer user service port awareness module: This module is mainly responsible for sensing the port listening of the user's own business, reporting the target business port information to the application layer port malicious scanning decoy module, and adjusting the listening port of the honeypot to avoid the user's business port and avoid interfering with the user's business. The implementation method is as follows: The first step is to load the kernel-level user service port awareness module, which uses the eBPF mechanism to intercept system calls of the socket listening interface function in the kernel, i.e., the kernel system network listening interface. For example, it intercepts the inet_listen() function in the kernel and obtains user service port information from the input parameter sock structure. The second step is to send the user's business port information to the application layer port malicious scanning decoy module through the application layer and kernel layer unified information channels such as netlink. The third step involves the application layer port malicious scanning decoy module releasing the conflicting port (using the Close method) and re-listening to another decoy port according to preset rules (using the Listen method). After completion, feedback is sent to the kernel layer user service port awareness module. Fourth step: The kernel layer user service port awareness module returns the inet_listen function intercepted by the hook (at this time it is still in the interception state), so that the user service process can listen to the required service port normally without being aware of it; 3) Malicious Behavior Alarm Management Backend: The malicious behavior alarm management backend is responsible for collecting malicious scanning behavior alarm events reported by the application layer port malicious scanning decoy module, determining the attack source address, and notifying the user of the alarm. The user can then take action based on the relevant information.
[0091] The malicious behavior alarm management backend issues scanning event handling instructions to the application layer port malicious scanning decoy module for handling, such as configuring firewall policies to block the network.
[0092] Specific examples: Step 1: Deploy the malicious behavior alarm management backend on the user's non-business cloud host; Step 2: Deploy the application layer port malicious scanning decoy module and the kernel layer user business port awareness module in the user business cloud host. The application layer port malicious scanning decoy module will automatically connect to the malicious behavior alarm management backend after startup. Step 3: In the malicious behavior alarm management backend, check the working status of the application layer port malicious scanning decoy module and the reported malicious scanning behavior alarm events, and take appropriate action. This application embodiment intercepts network listening system calls through the Linux kernel eBPF mechanism, and detects in real time the business ports that the user is about to listen to (but have not yet listened to), so that the user's business can complete the listening to the conflicting ports normally without being aware of it; in addition, through the communication interaction between the kernel and the application layer, it realizes the ability to automatically release the honeypot decoy port and relisten to other ports.
[0093] Based on the application-layer decoy port listening capability, it enables the detection and discovery of malicious port scanning behavior; based on the kernel eBPF mechanism, it enables the perception and interception of socket listening events, realizing automated and transparent avoidance of business ports, so as to avoid affecting the normal use of user services.
[0094] Reference Figure 7 This diagram illustrates a host-based honeypot implementation device based on the eBPF mechanism, according to an embodiment of this application. It is applied to the host's kernel layer, which includes a kernel-level user service port awareness module, and an application-level port malicious scanning decoy module deployed at the host's application layer. The device may include the following modules: The receiving module 701 is used by the application layer port malicious scanning decoy module to receive the target service port information reported by the kernel layer user service port awareness module; the target service port information is determined by the kernel layer user service port awareness module based on the target structure corresponding to the intercepted listening interface function in the kernel layer. The monitoring module 702 is used to determine the decoy port to be monitored from multiple service ports based on the target service port information, and to monitor the decoy port to be monitored.
[0095] In one optional embodiment of this application, the monitoring module 702 is used to determine the target port based on the target service port information and to determine whether there is a monitoring conflict on the target port; when there is a monitoring conflict on the target port, the decoy port to be monitored is determined from other ports; when there is no monitoring conflict on the target port, the target port is used as the decoy port to be monitored.
[0096] In an optional embodiment of this application, the listening module 702 is further configured to send feedback information to the kernel layer user service port awareness module after determining the decoy port to be monitored; the kernel layer user service port awareness module is configured to return a listening interface function based on the feedback information.
[0097] In one optional embodiment of this application, the host includes a user business cloud host and a user non-business cloud host. The kernel layer of the user business cloud host is equipped with a kernel layer user business port awareness module, and the application layer of the user business cloud host is equipped with an application layer port malicious scanning decoy module. The user non-business cloud host is equipped with a malicious behavior alarm management backend and a listening module 702, which is also used to report malicious scanning behavior alarm events to the malicious behavior alarm management backend. The malicious behavior alarm management backend is used to send a scanning event handling instruction to the application layer port malicious scanning decoy module according to the malicious scanning behavior alarm event. In response to the scanning event handling instruction, the decoy port to be monitored is processed.
[0098] In this embodiment, the application-layer port malicious scanning decoy module receives target service port information reported by the kernel-layer user service port awareness module. The target service port information is determined by the kernel-layer user service port awareness module based on the target structure corresponding to the intercepted listening interface function in the kernel layer. Based on the target service port information, the decoy port to be monitored is determined from multiple service ports, and monitoring is performed on the decoy port. This embodiment, based on the Linux kernel eBPF mechanism, implements a more transparent and flexible method for detecting security penetration events using micro-honeypots, solving the problem of conflicts between decoy ports and user service ports in port micro-honeypot technology, which affects the normal operation of user services.
[0099] Reference Figure 8 This diagram illustrates another structural schematic of a host-based honeypot implementation device based on the eBPF mechanism, applied to the kernel layer of a host. The kernel layer deploys a kernel-level user service port awareness module, and the host's application layer deploys an application-level port malicious scanning decoy module. The device may include the following modules: The interception module 801 is used by the kernel layer user service port awareness module to intercept the listening interface function in the kernel layer and determine the target service port information based on the target structure corresponding to the listening interface function. The sending module 802 is used to send the target service port information to the application layer port malicious scanning decoy module; the application layer port malicious scanning decoy module is used to release conflicting ports according to the target service port information. The returned module is used to return the listening interface function.
[0100] In this embodiment, the kernel-layer user service port awareness module intercepts the listening interface function in the kernel layer and determines the target service port information based on the target structure corresponding to the listening interface function; the target service port information is sent to the application-layer port malicious scanning decoy module; the application-layer port malicious scanning decoy module is used to release the conflicting port based on the target service port information; and returns the listening interface function. This embodiment can utilize the Linux kernel eBPF mechanism to detect in real time the service port that the user is about to listen to (but has not yet been listened to), allowing the user service to complete the listening to the conflicting port normally without being aware of it. In addition, through communication and interaction between the kernel and application layers, the ability to automatically release the decoy port of the honeypot and relisten on other ports is realized.
[0101] This application also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the above-described host honeypot implementation method based on the eBPF mechanism.
[0102] This application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements the above-described host honeypot implementation method based on the eBPF mechanism.
[0103] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.
[0104] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.
[0105] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0106] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0107] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0108] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0109] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.
[0110] Finally, 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 terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.
[0111] The above provides a detailed description of the host micro honeypot implementation method, system, and related products based on the eBPF mechanism. Specific examples are used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A method for implementing a host-based honeypot based on the eBPF mechanism, characterized in that, The method is applied to the kernel layer of the host, wherein the kernel layer is equipped with a kernel layer user service port awareness module, and the application layer of the host is equipped with an application layer port malicious scanning decoy module; the method includes: The application layer port malicious scanning decoy module receives the target service port information reported by the kernel layer user service port awareness module; the target service port information is determined by the kernel layer user service port awareness module based on the target structure corresponding to the intercepted listening interface function in the kernel layer. Based on the target service port information, a decoy port to be monitored is determined from multiple service ports, and monitoring is performed on the decoy port to be monitored.
2. The method according to claim 1, characterized in that, The step of determining the decoy port to be monitored from multiple service ports based on the target service port information includes: Based on the target service port information, determine the target port and determine whether there is a listening conflict on the target port; When there is a listening conflict at the target port, the decoy port to be monitored is determined from other ports; When there is no listening conflict on the target port, the target port is used as the decoy port to be monitored.
3. The method according to claim 1, characterized in that, After determining the decoy port to be monitored, the method further includes: Send feedback information to the kernel layer user service port awareness module; The kernel-level user service port awareness module is used to return the listening interface function based on the feedback information.
4. The method according to claim 1, characterized in that, The host includes a user business cloud host and a user non-business cloud host. The kernel layer of the user business cloud host is equipped with a kernel layer user business port awareness module, and the application layer of the user business cloud host is equipped with an application layer port malicious scanning decoy module. The user's non-business cloud host has a malicious behavior alarm management backend deployed, and the method further includes: The malicious behavior alarm management backend reports malicious scanning behavior alarm events to the malicious behavior alarm management backend; the malicious behavior alarm management backend is used to send scanning event handling instructions to the application layer port malicious scanning decoy module based on the malicious scanning behavior alarm events; In response to the scan event handling command, the decoy port to be monitored is processed.
5. A method for implementing a host-based honeypot based on the eBPF mechanism, characterized in that, The method is applied to the kernel layer of the host, wherein the kernel layer is equipped with a kernel layer user service port awareness module, and the application layer of the host is equipped with an application layer port malicious scanning decoy module; the method includes: The kernel-layer user service port awareness module intercepts the listening interface function in the kernel layer and determines the target service port information based on the target structure corresponding to the listening interface function. The target service port information is sent to the application layer port malicious scanning decoy module; the application layer port malicious scanning decoy module is used to release conflicting ports according to the target service port information; Return to the listening interface function.
6. A host-based honeypot implementation system based on the eBPF mechanism, characterized in that, The system includes a host, the kernel layer of which is equipped with a kernel layer user service port awareness module, and the application layer of which is equipped with an application layer port malicious scanning decoy module. The kernel-layer user service port awareness module is used to intercept the listening interface function in the kernel layer and determine the target service port information based on the target structure corresponding to the listening interface function. The application layer port malicious scanning decoy module is used to receive target service port information reported by the kernel layer user service port awareness module; based on the target service port information, it determines the decoy port to be monitored from multiple service ports, and monitors the decoy port to be monitored.
7. The system according to claim 6, characterized in that, The host includes a user business cloud host and a user non-business cloud host. The kernel layer of the user business cloud host is equipped with a kernel layer user business port awareness module, and the application layer of the user business cloud host is equipped with an application layer port malicious scanning decoy module. The user non-business cloud host is equipped with a malicious behavior alarm management backend. The application layer port malicious scanning decoy module is also used to report malicious scanning behavior alarm events to the malicious behavior alarm management backend; The malicious behavior alarm management backend is used to send a scanning event handling instruction to the application layer port malicious scanning decoy module based on the malicious scanning behavior alarm event; The application layer port malicious scanning decoy module is also used to process the decoy port to be monitored in response to the scanning event handling instruction.
8. A host-based honeypot implementation device based on the eBPF mechanism, characterized in that, The device is applied to the kernel layer of the host, wherein a kernel layer user service port awareness module is deployed in the kernel layer, and an application layer port malicious scanning decoy module is deployed in the application layer of the host; the device includes: The receiving module is used by the application layer port malicious scanning decoy module to receive the target service port information reported by the kernel layer user service port awareness module; the target service port information is determined by the kernel layer user service port awareness module based on the target structure corresponding to the intercepted listening interface function in the kernel layer. The monitoring module is used to determine the decoy port to be monitored from multiple service ports based on the target service port information, and to monitor the decoy port to be monitored.
9. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein when the computer program is executed by the processor, it implements the host micro honeypot implementation method based on the eBPF mechanism as described in any one of claims 1 to 5.
10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the host micro honeypot implementation method based on the eBPF mechanism as described in any one of claims 1 to 5.