A cloud-native API trapping and tracing method and system
By designing API decoys and dynamic scheduling algorithms in a cloud-native environment, the security vulnerabilities of cloud-native APIs are addressed, enabling efficient API attack detection and tracing, and enhancing the security defense capabilities of the cloud environment.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- INSTITUTE OF INFORMATION ENGINEERING CHINESE ACADEMY OF SCIENCES
- Filing Date
- 2023-03-30
- Publication Date
- 2026-06-30
Smart Images
Figure CN116527321B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer network security and relates to a cloud-native API decoy tracing method and system. It is a cloud-native API attack decoy framework that constructs corresponding API decoys and highly interactive decoy environments according to the characteristics of different cloud service layers. Background Technology
[0002] With the rapid development of emerging technologies such as cloud computing, big data, the Internet of Things, and mobile internet, the demand for APIs (Application Programming Interfaces), as the core channel for connecting services and transmitting data, has increased dramatically, and APIs are ubiquitous. According to Postma's monitoring data, APIs have been fully accepted globally and are showing a continuous growth trend. APIs are becoming an emerging and crucial information infrastructure on the Internet. APIs carry core business logic and sensitive data for enterprises. However, behind the enormous value of APIs lies a significant security risk. Compared to traditional web pages, APIs carry greater data value and are easier to attack. The current imbalance between the growth rate of APIs and the development of API security makes APIs one of the weakest links in enterprise security construction. Summary of the Invention
[0003] To address the aforementioned issues, this invention proposes a cloud-native API decoy tracing method and system, which constructs corresponding API decoys and highly interactive decoy environments based on the characteristics of different cloud service layers.
[0004] To achieve the above objectives, the specific technical solution adopted by the present invention is as follows:
[0005] A method for tracing and capturing source code of cloud-native APIs includes the following steps:
[0006] 1) To address API vulnerabilities in cloud environments involving containers and their orchestration, API decoys were designed for Kubernetes and Docker, including API vulnerabilities in containers and cloud components orchestrated by containers. Kubernetes and Docker are representative cloud-native technologies. Kubernetes is an open-source container orchestration platform that can automatically deploy, manage, and scale containers; Docker is an open-source container engine. Both are widely used in public, private, and hybrid clouds. To address the vulnerability of service account credentials in Kubernetes environments to attackers using them for API server communication, a Service Account credential decoy was designed and placed in the worker node's container environment. To address the possibility of attackers using insecurely configured kubelet components to take over nodes, kubelet configuration was set to allow unauthorized users to issue commands to the worker node's kubelet API; this component then serves as the kubelet decoy. To address the vulnerability of insecure Docker configurations to attackers remotely controlling nodes, the API of the Docker daemon on the worker node was exposed to the public internet as a Docker API decoy to attract attackers. Deploy the application layer API decoys into the honeypot system.
[0007] 2) At the application layer, API security issues in this scenario are related to specific application software. We selected API vulnerabilities with high risk and frequent exploitation, as shown in Table 1. We encapsulated the vulnerable API applications using Docker to construct corresponding highly interactive application-layer API decoys. Finally, we deployed these application-layer API decoys on worker nodes' Kubernetes instances and exposed them to the public internet.
[0008] Table 1 lists application-layer API decoys.
[0009]
[0010] 3) A dynamic scheduling algorithm based on current network traffic is proposed to maximize capture effect while making full use of physical resources. The dynamic scheduling algorithm is implemented by the control node. It comprehensively considers the current and historical access frequencies of each application-layer API decoy, updates the priority of each application-layer API decoy according to a given weight and decay rate, sorts the application-layer API decoys according to their priority, sets the top N application-layer API decoys to the enabled state, and sets the remaining application-layer API decoys to the disabled state. The value of N is set by the system administrator, and cannot exceed the total number of application-layer API decoys. When the scheduler receives information from the redirector, it records it as an access to the corresponding application-layer API decoy. Every certain period of time, the scheduler calculates the current access frequency based on the number of times each application-layer API decoy has been accessed during that period, and then uses the current access frequency as the basis for further calculations. now The highest historical access frequency of the decoy fish decoy weight w and priority decay rate l Calculate the priority of the application layer API decoy. p The formula is as follows:
[0011]
[0012] Among them, the current access frequency of the decoy now Application layer API decoy's highest historical access frequency fish The decoy weight is calculated by the scheduler. w and priority decay rate l All settings are configured by the system administrator. Decoy weight. w This represents the level of importance the system administrator attaches to different vulnerabilities, because... fish It will only increase and be greater than or equal to 0, therefore w The larger, fish When changing p The greater the impact; the lower the attenuation rate l This represents the degree to which the priority decreases as the current access frequency of the decoy decreases; the higher the decay rate, the lower the priority. now When reduced p The greater the impact, the easier it is for the decoy to be shut down by the scheduling algorithm. By default, the weight and priority decay value of each application-layer API decoy are the same, but system administrators can customize the adjustment according to the severity of the vulnerability represented by different application-layer API decoys.
[0013] The pseudocode description of the dynamic scheduling algorithm is as follows:
[0014] Input: User request,
[0015] Output: Decoy status table
[0016] while
[0017] use Perform regular expression matching on the user's request content, and the result is denoted as... result
[0018] if then
[0019]
[0020] if then
[0021]
[0022] end if
[0023] end if
[0024]
[0025]
[0026] end while
[0027] turn up The Middle N Larger values are denoted as p maxt
[0028] while
[0029] if then
[0030]
[0031] else then
[0032]
[0033] end if
[0034] end while
[0035] 4) After an attacker enters the honeypot system and leaves attack logs, the system generates aggregated logs based on the logs from the API Server (control node) and worker nodes in Kubernetes. After obtaining the API Server logs and worker node logs, the system aggregates the logs according to their time relationship, ultimately generating activity log records left by the attacker in the cloud environment's intranet after the intrusion, for subsequent analysis. That is, honeypot administrators can trace the attacker by reviewing the logs.
[0036] The present invention also provides a cloud-native API decoy tracing system, characterized in that it includes an API decoy generation module and a honeypot system, wherein the honeypot system includes a control node and a worker node;
[0037] The API decoy generation module is used to design application-layer API decoys for Kubernetes and application-layer API decoys for Docker, respectively, targeting the API vulnerabilities of containers and orchestrated cloud components involved in the cloud environment; and to deploy the application-layer API decoys to the corresponding worker nodes.
[0038] The control node is used to update the priority of each application layer API decoy based on its current and historical access frequencies; then sort the priorities of each application layer API decoy, and set the top N application layer API decoys with the highest priority values to the enabled state, while setting the remaining application layer API decoys to the disabled state; record the logs generated after the attacker enters the honeypot system, and generate activity log records left by the attacker in the cloud environment intranet after the intrusion based on the logs, so as to trace the attacker.
[0039] Furthermore, the priority ;in, now The current access frequency of the application layer API decoy. fish This represents the highest historical access frequency for an application-layer API decoy. w Weights for application layer API decoys. l This represents the priority decay rate.
[0040] Furthermore, aggregated logs are generated based on the logs of the control node and worker nodes in Kubernetes. Then, the logs are aggregated according to their time relationship to generate activity log records left by the attacker in the cloud environment intranet after the intrusion.
[0041] Furthermore, the API decoys include: addressing the issue that service account credentials in a Kubernetes environment are easily used by attackers for API Server communication, a Service Account credential decoy is designed and placed in the container of the worker node; addressing the issue that the kubelet component, under insecure configuration, is easily used by attackers to take over nodes, a kubelet decoy is obtained by configuring the kubelet to allow unauthorized users to issue commands to the current node's kubelet API; and addressing the issue that insecure Docker configuration can easily lead to attackers remotely controlling nodes, the API of the Docker daemon on the worker node is exposed on the public internet as a Docker API decoy to attract attackers.
[0042] Compared with the prior art, the positive effects of the present invention are as follows:
[0043] An API decoy environment in the cloud is proposed. The system dynamically determines whether to enable or disable the decoy based on the current network traffic trigger frequency of the application-layer API decoy and the decoy's historical information. This allows for the concentration of physical resources on application-layer API decoys of interest to attackers, given limited physical resources. This increases the attacker's chances of gaining access to the internal network and using orchestration-layer decoys for lateral movement. Attached Figure Description
[0044] Figure 1 This is a schematic diagram of the overall architecture of the trapping system of the present invention.
[0045] Figure 2 It refers to the specific workflow of the system. Detailed Implementation
[0046] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, and to make the objectives, features and advantages of the present invention more apparent and understandable, the core technology of the present invention will be further described in detail below with reference to the accompanying drawings and examples.
[0047] like Figure 1 As shown, the system includes an API decoy generation module and a honeypot system. The honeypot system consists of a control node and worker nodes. The worker nodes are only responsible for deploying specific decoys, while the control nodes are responsible for handling attacker requests, dynamically scheduling decoys, and processing logs.
[0048] like Figure 2 As shown, the workflow of the control node includes the following steps:
[0049] Step 110: This module needs to handle the attacker's network requests. After performing feature matching on the attacker's requests, the system will forward the vulnerability number corresponding to the request as a log to the scheduler, then update the system cache to respond to subsequent requests from the attacker, and finally forward the attacker's requests to the application layer API decoy corresponding to the vulnerability number.
[0050] Step 120: This module needs to perform application-layer API decoy scheduling based on the logs from the first module. After obtaining the logs forwarded by the previous module, the priority of each application-layer API decoy is calculated according to the dynamic scheduling algorithm. Finally, the top N decoys with the highest priority are activated, and the other decoys are deactivated.
[0051] Step 130: This module needs to generate aggregated logs based on the API Server logs and worker node logs in Kubernetes. After obtaining the API Server logs and worker node logs, the system aggregates the logs according to their time relationship, ultimately generating activity log records left by the attacker in the cloud environment's intranet after the intrusion; honeypot administrators can then trace the attackers by reviewing these logs.
[0052] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail using examples, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.
Claims
1. A cloud-native API trapping and tracing method, comprising the following steps: 1) To address the API vulnerabilities of containers and orchestrated cloud components in the cloud environment, we designed application-layer API decoys for Kubernetes and Docker respectively, and deployed each application-layer API decoy to the honeypot system. 2) updating the priority of the corresponding application layer API bait according to the current accessed frequency and the historical accessed frequency of each application layer API bait; the priority ; wherein, fnow is the current accessed frequency of the application layer API bait, fhis is the historical highest accessed frequency of the application layer API bait, w is the weight of the application layer API bait, l is the priority decay rate; 3) Sort the priority of each application layer API decoy, and set the top N application layer API decoys with the highest priority values to the open state, and set the remaining application layer API decoys to the closed state. 4) Record the logs generated after the attacker enters the honeypot system, and generate activity logs left by the attacker in the cloud environment intranet after the intrusion based on the logs to trace the attacker.
2. The method according to claim 1, characterized in that, The logs include the logs of the control node and the logs of the worker nodes in Kubernetes.
3. The method according to claim 1 or 2, characterized in that, Aggregated logs are generated based on the logs of the control node and worker nodes in Kubernetes. Then, the logs are aggregated according to their time relationship to generate activity log records left by attackers in the cloud environment intranet after intrusion.
4. The method according to claim 1 or 2, characterized in that, The API lures include: addressing the issue that service account credentials in a Kubernetes environment are easily used by attackers for API server communication, a Service Account credential lure is designed and placed in a container on the worker node; addressing the issue that insecure configurations of the kubelet component can be used by attackers to take over nodes, a kubelet lure is obtained by configuring the kubelet to allow unauthorized users to issue commands to the current node's kubelet API; and addressing the issue that insecure Docker configurations can easily lead to attackers remotely controlling nodes, the API of the Docker daemon on the worker node is exposed to the public internet as a Docker API lure to attract attackers.
5. A cloud-native API trapping and tracing system, characterized in that, It includes an API decoy generation module and a honeypot system, wherein the honeypot system includes a control node and a worker node; The API decoy generation module is used to design application-layer API decoys for Kubernetes and application-layer API decoys for Docker, respectively, targeting the API vulnerabilities of containers and orchestrated cloud components involved in the cloud environment; and to deploy the application-layer API decoys to the corresponding worker nodes. The control node is used to update the priority of each application-layer API decoy based on its current and historical access frequencies; then, it sorts the priorities of each application-layer API decoy, sets the top N application-layer API decoys with the highest priority values to the enabled state, and sets the remaining application-layer API decoys to the disabled state; it records the logs generated after an attacker enters the honeypot system, and generates activity logs left by the attacker in the cloud environment intranet after the intrusion based on the logs to trace the attacker; the priority... ;in, fnow The current access frequency of the application layer API decoy. fhis This represents the highest historical access frequency for an application-layer API decoy. w Weights for application layer API decoys. l This represents the priority decay rate.
6. The API trapping and tracing system according to claim 5, characterized in that, Aggregated logs are generated based on the logs of the control node and worker nodes in Kubernetes. Then, the logs are aggregated according to their time relationship to generate activity log records left by attackers in the cloud environment intranet after intrusion.
7. The API trapping and tracing system according to claim 5, characterized in that, The API lures include: To address the issue that service account credentials in a Kubernetes environment are easily used by attackers for API Server communication, a ServiceAccount credential lure is designed and placed in a container on the worker node; to address the issue that insecure configurations of the kubelet component can be used by attackers to take over nodes, a kubelet lure is obtained by configuring the kubelet to allow unauthorized users to issue commands to the current node's kubelet API; and to address the issue that insecure Docker configurations can easily lead to attackers remotely controlling nodes, the API of the Docker daemon on the worker node is exposed to the public internet as a Docker API lure to attract attackers.