Containerized service vulnerability detection method, device and server

Abstract

The present application provides a containerized service vulnerability detection method, device and server, which relate to the field of network information security. The method includes: the server obtains the host information of the target host and the process information corresponding to each service to be detected in the target host. The server determines the service type of each service to be detected, the target host listening port of the non-containerized service and the target host proxy port of the containerized service based on the host information, the process information corresponding to each service to be detected and the preset service identification library. The server determines the network address of each service to be detected based on the target host listening port of the non-containerized service, the target host proxy port of the containerized service and the IP address in the host information. The server performs vulnerability detection based on the preset vulnerability detection rule library, the service type and network address of each service to be detected. The method of the present application improves the accuracy and efficiency of vulnerability detection.

Description

Technical Field

[0001] The present application relates to the field of network information security, and in particular to a containerized service vulnerability detection method, device, and server. Background Art

[0002] With the development of computer technology, more and more services in the financial sector are becoming electronic, and the traditional financial industry is gradually shifting towards Fintech (Fintech). However, due to the security requirements of the financial industry, it is usually necessary to periodically perform vulnerability detection on various services to avoid security risks.

[0003] In the prior art, when a service runs directly on a target host, the server can obtain the target host's service to be detected and then, based on the process information corresponding to the service to be detected, identify the service type corresponding to the service to be detected. Based on the service type, the server can determine the vulnerability detection rules associated with the service. The server uses these vulnerability detection rules to verify whether the service has a vulnerability. Accurately identifying the service type in this process can effectively improve vulnerability detection efficiency.

[0004] However, when the service runs in a container, the target host as the host machine will not be able to directly determine the corresponding service type based on the process information of the service to be detected, and will not be able to determine the corresponding vulnerability detection rules for the service to be detected, which may easily lead to low vulnerability detection accuracy. Summary of the Invention

[0005] The present application provides a containerized service vulnerability detection method, device and server to solve the problem that when the service runs in a container, the target host as the host machine will not be able to accurately obtain the target service information, and then identify the service type corresponding to the proxy port number, which easily leads to low vulnerability detection efficiency.

[0006] In a first aspect, the present application provides a containerized service vulnerability detection method, comprising:

[0007] Obtain the host information of the target host and the process information corresponding to each service to be detected in the target host;

[0008] Determine the service type of each service to be detected, the target host listening port of the service to be detected if it is a non-containerized service, and the target host proxy port of the service to be detected if it is a containerized service, based on the host information, the process information corresponding to each service to be detected, and the preset service identification library;

[0009] Determine the network address of each service to be tested based on the target host listening port of the non-containerized service, the target host proxy port of the containerized service, and the IP address in the host information;

[0010] Perform vulnerability detection based on the preset vulnerability detection rule base, the service type and network address of each service to be detected.

[0011] Optionally, based on the host information, the process information corresponding to each service to be detected, and a preset service identification library, the service type of each service to be detected, the target host listening port of the service to be detected when the service to be detected is a non-containerized service, and the target host proxy port of the service to be detected when the service to be detected is a containerized service are determined, specifically including:

[0012] Use the process command or process loading file in the process information of each service to be detected to match the service identifier in the service identifier library to determine the service type corresponding to each service to be detected;

[0013] When the service to be detected is a non-containerized service, the target host listening port of the non-containerized service is obtained from the process information of each non-containerized service;

[0014] When the service to be detected is a containerized service, the target host proxy port of each containerized service is determined according to the process information and host information corresponding to each containerized service.

[0015] Optionally, the process command or process loading file in the process information of each service to be detected is matched with the service identifier in the service identifier library to determine the service type corresponding to each service to be detected, specifically including:

[0016] Traverse the service identifiers in the service identifier library;

[0017] Use the third string corresponding to each service identifier in the service identifier library to match the first string corresponding to the process command of each service to be detected or the second string corresponding to the process loading file to determine whether the third string is included in the first string or the second string;

[0018] When the first character string or the second character string contains the third character string, the service type of the to-be-detected service corresponding to the first character string or the second character string is determined according to the service identifier corresponding to the third character string.

[0019] Optionally, the host information includes at least one network connection information and a network forwarding rule. Determining the target host proxy port of each containerized service based on the process information and host information corresponding to each containerized service specifically includes:

[0020] Determine target network connection information corresponding to each containerized service in a listening state based on the socket file index node number and network connection information in the process information of each containerized service;

[0021] Determine the container listening port corresponding to the containerized service based on the target network connection information;

[0022] According to the network forwarding rules, a port mapping relationship table is constructed between the container and the target host;

[0023] The target host proxy port of each containerized service is determined based on the port mapping relationship table and the container listening port of each containerized service.

[0024] Optionally, the method further includes:

[0025] When the process control group file of the process information of the service to be detected contains the fourth character string, it is determined that the service to be detected is a containerized service; otherwise, it is determined that the service to be detected is a non-containerized service.

[0026] Optionally, vulnerability detection is performed based on a preset vulnerability detection rule base, the service type and network address of each service to be detected, specifically including:

[0027] Obtaining at least one vulnerability detection rule corresponding to each service to be detected from a vulnerability detection rule library according to the service type of each service to be detected;

[0028] Generate a request packet corresponding to each vulnerability detection rule;

[0029] According to the network address of each service to be detected, the request packet of the corresponding vulnerability detection rule is sent to the server and the response packet is received.

[0030] The response packet is parsed, and when the response packet contains the fifth character string preset in the corresponding vulnerability detection rule, it is determined that the service to be detected has a vulnerability corresponding to the vulnerability detection rule.

[0031] Optionally, the method further includes:

[0032] When a vulnerability is detected, the vulnerability is written into a vulnerability list; wherein the vulnerability list includes the vulnerability name and network address corresponding to the vulnerability.

[0033] In a second aspect, the present application provides a containerized service vulnerability detection device, comprising:

[0034] The acquisition module is used to obtain the host information of the target host and the process information corresponding to each service to be detected in the target host;

[0035] The detection module is used to determine the service type of each service to be detected based on the host information, the process information corresponding to each service to be detected and the preset service identification library, the target host listening port of the service to be detected when the service to be detected is a non-containerized service, and the target host proxy port of the service to be detected when the service to be detected is a containerized service; determine the network address of each service to be detected based on the target host listening port of the non-containerized service, the target host proxy port of the containerized service and the IP address in the host information; perform vulnerability detection based on the preset vulnerability detection rule library, the service type and network address of each service to be detected.

[0036] Optionally, the detection module is specifically configured to:

[0037] Use the process command or process loading file in the process information of each service to be detected to match the service identifier in the service identifier library to determine the service type corresponding to each service to be detected;

[0038] When the service to be detected is a non-containerized service, the target host listening port of the non-containerized service is obtained from the process information of each non-containerized service;

[0039] When the service to be detected is a containerized service, the target host proxy port of each containerized service is determined based on the process information and host information corresponding to each containerized service. Optionally, the detection module is specifically used to:

[0040] Traverse the service identifiers in the service identifier library;

[0041] Use the third string corresponding to each service identifier in the service identifier library to match the first string corresponding to the process command of each service to be detected or the second string corresponding to the process loading file to determine whether the third string is included in the first string or the second string;

[0042] When the first character string or the second character string contains the third character string, the service type of the to-be-detected service corresponding to the first character string or the second character string is determined according to the service identifier corresponding to the third character string.

[0043] Optionally, the detection module is specifically configured to:

[0044] Determine target network connection information corresponding to each containerized service in a listening state based on the socket file index node number and network connection information in the process information of each containerized service;

[0045] Determine the container listening port corresponding to the containerized service based on the target network connection information;

[0046] According to the network forwarding rules, a port mapping relationship table is constructed between the container and the target host;

[0047] The target host proxy port of each containerized service is determined based on the port mapping relationship table and the container listening port of each containerized service.

[0048] Optionally, the detection module is further configured to:

[0049] When the process control group file of the process information of the service to be detected contains the fourth character string, it is determined that the service to be detected is a containerized service; otherwise, it is determined that the service to be detected is a non-containerized service.

[0050] Optionally, the detection module is specifically configured to:

[0051] Obtaining at least one vulnerability detection rule corresponding to each service to be detected from a vulnerability detection rule library according to the service type of each service to be detected;

[0052] Generate a request packet corresponding to each vulnerability detection rule;

[0053] According to the network address of each service to be detected, the request packet of the corresponding vulnerability detection rule is sent to the server and the response packet is received.

[0054] The response packet is parsed, and when the response packet contains the fifth character string preset in the corresponding vulnerability detection rule, it is determined that the service to be detected has a vulnerability corresponding to the vulnerability detection rule.

[0055] Optionally, the detection module is further configured to:

[0056] When a vulnerability is detected, the vulnerability is written into a vulnerability list; wherein the vulnerability list includes detection rules and network addresses corresponding to the vulnerability.

[0057] In a third aspect, the present application provides a server, comprising: a memory and a processor;

[0058] The memory is used to store a computer program; the processor is used to execute the containerized service vulnerability detection method in the first aspect and any possible design of the first aspect according to the computer program stored in the memory.

[0059] In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When at least one processor of a server executes the computer program, the server executes the containerized service vulnerability detection method in the first aspect and any possible design of the first aspect.

[0060] In a fifth aspect, the present application provides a computer program product, which includes a computer program. When at least one processor of a server executes the computer program, the server executes the containerized service vulnerability detection method in the first aspect and any possible design of the first aspect.

[0061] The containerized service vulnerability detection method, device and server provided by the present application obtain the host information of the target host and the process information corresponding to each service in the target host, wherein the host information may include the IP address of the target host and at least one network connection information; the process information corresponding to each service to be detected and the preset service identification library are used to determine the service type of each service to be detected; the service to be detected can be a containerized service or a non-containerized service; when the service to be detected is a non-containerized service, the port number of the target host listening port corresponding to the service to be detected is directly obtained from the process information of the service to be detected; when the service to be detected is a containerized service, the container listening port of the containerized service in the container and the corresponding target host proxy port are determined according to the process information of the proxy process, the network connection information of the target host and the network forwarding rule of the target host; according to each non-containerized service The method comprises the following steps: determining the network address of each non-containerized service according to the port number of the target host listening port of the containerized service and the IP address of the target host; determining the network address of each containerized service according to the port number of the target host proxy port of each containerized service and the IP address of the target host; determining at least one vulnerability detection rule corresponding to each service to be detected according to the service type of each service to be detected and the pre-set vulnerability detection rule library; sending the generated request packet to the network address corresponding to the service to be detected according to each service to be detected and its corresponding vulnerability detection rule, and obtaining a response packet; determining whether the service to be detected has a vulnerability according to the response packet, thereby completing the execution process of the vulnerability detection, thereby improving the accuracy of judging the service type of the containerized service, improving the accuracy of obtaining the vulnerability detection rules corresponding to the containerized service, and improving the accuracy and efficiency of vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the technical solutions in the present application or the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0063] Figure 1 A schematic diagram of a scenario for containerized service vulnerability detection provided in one embodiment of the present application;

[0064] Figure 2 A flowchart of a containerized service vulnerability detection method provided in one embodiment of the present application;

[0065] Figure 3 A schematic diagram of the structure of a containerized service vulnerability detection device provided in one embodiment of the present application;

[0066] Figure 4 A schematic diagram of the hardware structure of a server provided in one embodiment of the present application. DETAILED DESCRIPTION

[0067] To make the objectives, technical solutions, and advantages of this application more clear, the technical solutions in this application will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0068] In the specification and claims of this application, as well as in the accompanying drawings, the terms "first," "second," "third," "fourth," and the like are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that such terms are interchangeable where appropriate. For example, first information could be referred to as second information, and similarly, second information could be referred to as first information without departing from the scope of this disclosure.

[0069] The word "if" as used herein may be interpreted as "when" or "when" or "in response to determining," depending on the context.

[0070] Furthermore, as used herein, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context indicates otherwise.

[0071] It should be further understood that the terms “comprises” and “includes” indicate the existence of features, steps, operations, elements, components, items, types, and / or groups, but do not preclude the existence, occurrence, or addition of one or more other features, steps, operations, elements, components, items, types, and / or groups.

[0072] The terms "or" and "and / or" as used herein are to be interpreted as inclusive, or mean any one or any combination. Thus, "A, B, or C" or "A, B, and / or C" means "any one of the following: A; B; C; A and B; A and C; B and C; A, B, and C." An exception to this definition occurs only when a combination of elements, functions, steps, or operations are inherently mutually exclusive in some manner.

[0073] With the development of computer technology, more and more services in the financial field are becoming electronic, and the traditional financial industry is gradually transforming into Fintech (Fintech). However, due to the security requirements of the financial industry, it is usually necessary to periodically perform vulnerability detection on various services to avoid security risks. In the existing technology, vulnerability detection usually requires first identifying the service type corresponding to the service to be detected in the target host. Then, the server can select the vulnerability detection rules belonging to the service to be detected based on the service type. The server can use the vulnerability detection rules to verify whether the service to be detected has vulnerabilities. Therefore, the ability to identify service types plays a key role in improving the vulnerability detection rate. In the above process, accurate identification of service types can effectively improve the efficiency of vulnerability detection.

[0074] When the service to be tested runs directly on the target host, the server can directly obtain the process information of the service to be tested from the target host. Based on this process information, the server can directly determine the service type of the service to be tested. However, when the service to be tested runs in a container, the server can only obtain the proxy process of the containerized service from the target host. This target host is the host machine described below. Containers use virtualization technology to isolate processes, network resources, and other resources within the container from the host machine. This isolation mechanism prevents the host machine from directly accessing the service deployed in the container. To expose the container service to external access, a proxy process can be run on the host machine to map the container port to the host machine. The proxy process's process information does not contain information about the container service. Therefore, the server cannot identify the service type of the service to be tested based on the proxy process information obtained from the host machine. For example, the service to be tested running in the container is a Harbor process. This Harbor process listens on port 8080 in the container. Due to the container's isolation mechanism, port 8080 of the container is inaccessible from the host machine. Therefore, the proxy process on the host maps the container's port 8080 to the host's port 8081. External devices can access the Harbor process in the container through the host's port 8081. The server can only obtain the proxy process's process information from the host. This proxy process's process information does not include the process information related to the Harbor process in the container. Therefore, the server cannot identify the service type of the service to be detected based on the proxy process's process information.

[0075] When the server cannot accurately obtain the service type of the service to be detected running in the container, the vulnerability detection rules used by the server to detect the service to be detected are usually not accurately matched to the service to be detected. As a result, the vulnerability detection accuracy of the service to be detected is likely to be low.

[0076] In response to the above problems, the present application proposes a containerized service vulnerability detection method. In the present application, the server can deploy an information collection module in the target host. The information collection model is used to obtain the process information and network information of the service to be detected in the target host. The server can determine the service type of the service to be detected by matching the process information with a characteristic string (service fingerprint). The characteristic string (service fingerprint) is a string that can identify the service type. For example, a process of a service to be detected listens on port 6379. The process information of the service to be detected includes a process command. The process command is / usr / bin / redis-server. The service fingerprint identification rules pre-set in the server include the string redis-server corresponding to the Redis service. The server determines that the service type corresponding to the service to be detected is the Redis service based on the redis-server string included in the process command. In the above process, the server can accurately identify the service type of the service to be detected running on the target host and the service to be detected running in the container through the service fingerprint. Thereafter, after obtaining the process information and network information of the service to be detected in the container, the server can construct a port mapping relationship between the container and the host machine for the service to be detected running in the container. Based on the port mapping, the server can determine the proxy port on the host machine for the service to be tested running in the container. Furthermore, based on the service type of the service to be tested running in the container and the proxy port, the server can determine the service type corresponding to the proxy process. The server can then use the vulnerability detection rules corresponding to the service type to complete vulnerability detection for the service to be tested running in the container through the proxy process.

[0077] The following specific embodiments are used to describe the technical solution of the present application in detail. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0078] Figure 1 A schematic diagram of a scenario for containerized service vulnerability detection provided by an embodiment of the present application is shown. Figure 1 As shown, the target host can run at least one service. Each service can run in the target host as a service process. For example, in the target host, Service 1, Service 2, and Service 3 can correspond to Service Process 1, Service Process 2, and Service Process 3, respectively. For example, when Service Process 1 is started, external devices can access Service 1 through Service Process 1. When Service Process 1 is shut down, external services will not be able to access Service 1.

[0079] The target host can serve as the host of at least one container. At least one service can also be run in each container. The service running in the container can be run as a service process in the container. For example, the container can include service 4 and service 5. The service 4 and service 5 can correspond to service process 4 and service process 5 running in the container, respectively. Due to the isolation mechanism of the container, external devices cannot directly access the service running in the container. A proxy process for each containerized service can be run in the target host. External devices can access the service in the container through the proxy process. For example, the service process 4 and service process 5 corresponding to the service 4 and service 5 can correspond to proxy process 4 and proxy process 5, respectively.

[0080] In the following embodiments, for the sake of convenience, services running directly on the target host are referred to as non-containerized services, and services running in containers are referred to as containerized services.

[0081] In this application, the containerized service vulnerability detection method described in the following embodiments is executed on a server. Specifically, the execution entity can be a server hardware device, a software application implemented in the server that implements the following embodiments, a computer-readable storage medium installed with the software application that implements the following embodiments, or code that implements the software application that implements the following embodiments.

[0082] Figure 2 A flow chart of a containerized service vulnerability detection method provided by an embodiment of the present application is shown. Figure 1 Based on the embodiment shown, Figure 2 As shown, with the server as the execution subject, the method of this embodiment may include the following steps:

[0083] S101: Obtain host information of a target host and process information corresponding to each service to be detected in the target host.

[0084] In this embodiment, the target host may be provided with an information collection module. The server may obtain the host information of the target host through the information collection module. The host information may include the IP address of the target host. The server may also obtain the process information corresponding to each service in the target host through the information collection module. This process information may constitute a process information list. Each process information may include information such as a process identifier, a process command, a target host listening port, a process control group file, and a process loading file list. For example, for a target host with an IP address of 192.168.1.2, when the process information list includes 5 processes, the process list may be as shown in Table 1 below.

[0085] Table 1

[0086]

[0087]

[0088] The process IDs of the five processes included in the target host are 60431, 46762, 15783, 23546, and 16745, respectively. These five processes correspond to five services to be detected. These five services to be detected can be non-containerized or containerized services. Each process corresponds to a process command. The target host can use this process command to start the corresponding process, thereby enabling the operation of the corresponding service to be detected. When the process corresponds to a non-containerized service, it corresponds to a target host listening port. When the process corresponds to a containerized service, it corresponds to a container listening port and a target host proxy port. Each target host listening port, container listening port, and target host proxy port can each correspond to a port number. As shown in Table 1, the processes with process IDs 60431 and 46762 are containerized processes; therefore, their target host listening ports are empty. The remaining three processes are non-containerized processes. Therefore, the server can directly obtain the port number of the target host listening port corresponding to each process from the target host through the information collection module.

[0089] The host information may also include at least one piece of network connection information. Each piece of network connection information may specifically include the local IP address and local port number, the peer IP address and peer port number, the connection status, the socket file inode number, and the like. For example, for a target host with an IP address of 192.168.1.2, its network connection information may be as shown in Table 2.

[0090] Table 2

[0091] Local IP address and port number Peer IP address and port number Connection Status Socket file inode number 192.168.1.2:3306 0.0.0.0:0000 LISTEN 146956941 0.0.0.0:8080 0.0.0.0:0000 LISTEN 302807426 0.0.0.0:8080 192.168.1.3:59008 ESTABLISHED 302807427

[0092] Among them, LISTEN in the connection status indicates the listening state, and ESTABLISHED indicates the established connection state.

[0093] In one example, after obtaining the host information of the target host and the process information corresponding to each service to be detected in the target host, the server can write the host information and the process information of each service to be detected into the asset information table. The asset information table can be shown in Table 3 below.

[0094] Table 3

[0095]

[0096]

[0097] For example, as shown in Table 3, the asset information table includes the IP address, host listening port, container listening port, host proxy port, and service type. The server can obtain four services to be detected from the target host. The IP addresses of the four services to be detected are all the IP address of the target host.

[0098] S102. Determine the service type of each service to be detected, the target host listening port of the service to be detected when the service to be detected is a non-containerized service, and the target host proxy port of the service to be detected when the service to be detected is a containerized service, based on the host information, the process information corresponding to each service to be detected, and the preset service identification library.

[0099] In this embodiment, after obtaining the process information corresponding to each service to be detected, the server can determine the service type of each service to be detected based on the process information and a preset service identification library. The service identification library may include multiple service types. Each service type may correspond to a service identification. The service identification can be used to uniquely identify a service type. The service identification and the service type can form an identification rule. The service identification is a feature string (service fingerprint). When the process information includes a feature string, it can be determined that the service type of the service to be detected corresponding to the process information is the service type corresponding to the feature string. For example, when the service identification library includes 5 identification rules, the 5 identification rules can be shown in Table 4 below.

[0100] Table 4

[0101] Serial number Service Type Feature string 1 Harbor harbor_core 2 Tomcat org.apache.catalina.startup.Bootstrap 3 SwaggerUI swager-ui 4 Redis redis-server 5 Mysql mysqld

[0102] The sequence number uniquely identifies an identification rule. The service type includes the service types of each service to be detected that may appear on the target host. Each service type uniquely corresponds to a signature string. For example, as shown in Table 1, the first identification rule states that when the signature string harbor_core is present, the corresponding service type is Harbor.

[0103] The service to be detected can be a non-containerized service running on the target host or a containerized service running in a container of the target host. When the service to be detected is a non-containerized service, the server can directly obtain the port number of the target host listening port corresponding to the service to be detected from the process information of the service to be detected. When the service to be detected is a containerized service, the server can only obtain the process information of the proxy process of each service to be detected. Based on the process information of the proxy process, the server can only determine its corresponding proxy port. Therefore, the server needs to determine the container listening port of the containerized service in the container and the corresponding target host proxy port based on the process information of the proxy process, the network connection information of the target host and the network forwarding rules of the target host.

[0104] In one example, the process information may include a process control group file. The server can determine whether the service to be detected is a containerized service by querying the process control group file of the service to be detected to see whether it contains a fourth string. That is, when the process control group file of the service to be detected contains the fourth string, the service to be detected is a containerized service. Otherwise, the service to be detected is a non-containerized service. The fourth string can be "docker" or "kubepods."

[0105] In one example, the specific process of the server determining the service type of each service to be detected, the target host listening port of each non-containerized service, and the target host proxy port of each containerized service may include the following steps:

[0106] Step 1: The server may use the process command or process loading file in the process information of each service to be detected to match the service identifier in the service identifier library to determine the service type corresponding to each service to be detected.

[0107] In this step, the server may first use the process command in the process information to match the service identifier. When the process command includes a service identifier, the server may determine that the service type of the service to be detected corresponding to the process command is the service type corresponding to the service identifier. When the process command does not include a service identifier, the server may use the process loading file to match the service identifier. When the process loading file includes the service identifier, the server may determine that the service type of the service to be detected corresponding to the process loading file is the service type corresponding to the service identifier. The specific steps may include:

[0108] Step 11: Traverse the service identifiers in the service identifier library.

[0109] In this step, the server traverses the service identifiers in the service identifier library. The server may be provided with a pre-loaded service identifier library. The service identifier library may include identification rules for common service types such as Tomcat / Harbor. Each identification rule includes a service type and a service identifier corresponding to the service type. Each service identifier uniquely corresponds to a service type. Each service identifier may be a characteristic string. In the following steps, the string may be referred to using a third string. The server may obtain all service identifiers in the service identifier library by traversing.

[0110] Step 12: Use the third string corresponding to each service identifier in the service identifier library to match the first string corresponding to the process command of each service to be detected or the second string corresponding to the process loading file to determine whether the first string or the second string contains the third string.

[0111] In this step, after obtaining a service to be detected, the server can obtain a process command from the process information of the service to be detected. As shown in Table 1, the process command can be a character string. In the following steps, the character string corresponding to the process command can be named as the first character string. The server can use the first character string corresponding to the process command to match the third character string corresponding to each service identifier in the service identifier library. If the first character string corresponding to the process command contains the third character string corresponding to a certain service identifier, it is determined that the match is successful. For example, as shown in Table 1, the process command corresponding to the process with the process identifier 60431 is / harbor / harbor_core. After matching with the service identifier in the service identifier library, it can be determined that the process command contains the service identifier harbor_core.

[0112] Otherwise, when the first character string corresponding to the process command does not match the third character strings corresponding to all service identifiers in the service identifier library, the server can continue to obtain the process loading file from the process information of the service to be detected. The process loading file may include a second character string. The server can use the second character string corresponding to the process loading file to match the third character string corresponding to each service identifier in the service identifier library. If the second character string corresponding to the process loading file contains the third character string corresponding to a certain service identifier, it is determined that the match is successful. For example, the character string of the process loading file corresponding to the process with process identifier 15783 can be "...springfox-swagger-ui-2.9.2.jar,httpclient-4.5.7.jar..." After matching with the service identifier in the service identifier library, it can be determined that the service identifier swager-ui is contained in the process loading file.

[0113] Otherwise, the server determines that the service to be detected does not match the third character strings corresponding to all service identifiers in the service identifier library.

[0114] Step 13: When the first character string or the second character string contains the third character string, determine the service type of the to-be-detected service corresponding to the first character string or the second character string according to the service identifier corresponding to the third character string.

[0115] In this step, when the first character string or the second character string includes the third character string, the server can determine the corresponding service type based on the third character string. The server can determine that the service type of the service to be detected corresponding to the first character string or the second character string is the service type corresponding to the third character string. For example, when the first character string / harbor / harbor_core corresponding to the process command includes the third character string harbor_core, the server can determine that the service type of the service to be detected corresponding to the process command / harbor / harbor_core is the Harbor service corresponding to the service identifier harbor_core. Based on the service identifier, the server can also determine that the process command meets the identification rule with sequence number 1 in the service identifier library shown in Table 4. For another example, when the second character string "...springfox-swagger-ui-2.9.2.jar,httpclient-4.5.7.jar..." corresponding to the process loading file includes the third character string swager-ui, the server can determine that the service type of the service to be detected corresponding to the process loading file is the SwaggerUI service corresponding to the service identifier swager-ui. According to the service identifier, the server can also determine that the process loading file satisfies the identification rule with sequence number 3 in the service identifier library shown in Table 4.

[0116] In one implementation, the server can determine the corresponding service type based on the process command or process load file in the process information of each service to be detected, and then add the service type to the asset information table. For example, based on the asset information table shown in Table 3, the service types of the four services to be detected can be added to Table 3. The updated Table 3 can be shown as follows.

[0117] Table 3

[0118] IP address Target host listening port Container listening port Target host proxy port Service Type 192.168.1.2 Harbor 192.168.1.2 Mysql 192.168.1.2 SwaggerUI 192.168.1.2 Redis

[0119] Step 2: When the service to be detected is a non-containerized service, the server can directly obtain the target host listening port of the non-containerized service from the process information of each non-containerized service.

[0120] In one implementation, the server can add the target host listening port of each non-containerized service to the asset information table. For example, based on the asset information table shown in Table 3, the target host listening ports of the four services to be detected can be added to Table 3. The updated Table 3 can be as follows.

[0121] Table 3

[0122] IP address Target host listening port Container listening port Target host proxy port Service Type 192.168.1.2 null Harbor 192.168.1.2 null Mysql 192.168.1.2 8090 SwaggerUI 192.168.1.2 6379 Redis

[0123] The first and second services to be tested can be containerized services, and their corresponding target host listening ports are empty. The target host listening ports of the third and fourth services to be tested can be 8090 and 6379 respectively.

[0124] Step 3: When the service to be detected is a containerized service, the server can determine the target host proxy port of each containerized service based on the process information and host information corresponding to each containerized service.

[0125] In this step, the host information may include network connection information and network forwarding rules. The server may determine the mapping relationship between the container listening port and the target host proxy port based on the network forwarding rules. The server may also determine the container listening port corresponding to each service to be detected based on the network connection information. The server may determine the target host proxy port corresponding to each service to be detected based on the mapping relationship between the container listening port corresponding to each service to be detected and the container listening port and the target host proxy port. The specific steps may include:

[0126] Step 31: Determine target network connection information corresponding to each containerized service in a listening state based on the socket file index node number and network connection information in the process information of each containerized service.

[0127] In this step, the process information may include the socket file index node number of each containerized service. The at least one network connection information of the target host may be as shown in Table 2. Each network connection information may also include the socket file index node number. The server may match the socket file index node number in the multiple network connection information of the target host according to the socket file index node number in the containerized service, thereby determining the target network connection information corresponding to the containerized service. For example, for the service to be detected with a process identifier of 60431, its socket file index node numbers may be 302807426 and 302807427. The server may query the second and third rows of network connection information in Table 2 based on the two socket file index node numbers. In the two rows of network connection information, the connection status of the network connection information in the second row is the listening state. Therefore, the server may determine that the network connection information in the second row is the target network connection information.

[0128] Step 32: Determine the container listening port number corresponding to the containerized service based on the target network connection information.

[0129] In this step, the network information may also include the local IP address and local port number, the peer IP address and peer port number. The local IP address and local port number are the IP address and port number of the containerized service in the container. The server can determine the port number of the container listening port of the containerized service based on the target network connection information. For example, when the target network connection information is the second row of network connection information in Table 2, the process identifier is 60431, and the port number of the container listening port corresponding to the service to be detected is 8080.

[0130] In one implementation, after determining the container listening port for each containerized service, the server can update the port number in the asset information table. For example, based on the asset information table shown in Table 3, the service types of the four services to be detected can be added to Table 3. The updated Table 3 can be as follows.

[0131] Table 3

[0132] IP address Target host listening port Container listening port Target host proxy port Service Type 192.168.1.2 null 8080 Harbor 192.168.1.2 null 3306 Mysql 192.168.1.2 8090 null SwaggerUI 192.168.1.2 6379 null Redis

[0133] The first and second services to be tested can be containerized services, with corresponding container listening ports 8080 and 3306. The third and fourth services to be tested are non-containerized services and do not have container listening ports. Due to the container isolation mechanism, the container is isolated from the target host's processes, network, and other resources. Therefore, the container's listening port number can overlap with the target host's listening port number.

[0134] Step 33: Build a port mapping relationship table between the container and the target host according to the network forwarding rules.

[0135] In this step, the host information of the target host may also include network forwarding rules. The network forwarding rules can be obtained from the proxy process of the target host. The proxy process is used to map the container listening port of the service process in the container to the proxy port of the proxy process of the target host. When the external device can access the proxy port of the target host, the target host can forward the access request to the container listening port of the container through the proxy process. Through this forwarding, the external device can access the service process in the container. For example, at the target host with an IP address of 192.168.1.2, the network forwarding rules can be as follows:

[0136] 1)-A KUBE-NODEPORTS-p tcp-m comment--comment"app / redis-server"-mtcp--dport 8081-j KUBE-SVC-A

[0137] 2)-A KUBE-SVC-Aj KUBE-SEP-A

[0138] 3)-A KUBE-SEP-Ap tcp-m tcp-j DNAT--to-destination172.21.72.196:8080

[0139] 4)-A KUBE-NODEPORTS-p tcp-m comment--comment"app / mysqld"-mtcp--dport3307-j KUBE-SVC-B

[0140] 5)-A KUBE-SVC-Bj KUBE-SEP-B

[0141] 6)-A KUBE-SEP-Bp tcp-m tcp-j DNAT--to-destination172.21.72.195:3306

[0142] After obtaining the network forwarding rules, the server can also parse the network forwarding rules to determine the port mapping relationship between the container and the target host. The port mapping relationship between the container and the target host is the mapping relationship between the container listening port and the target host proxy port.

[0143] In the above network forwarding rules, the first rule chain has the -A parameter set to kube-nodeports. In this rule chain, the --dport parameter indicates the target host proxy port in the mapping. This target host proxy port can be the forwarding entry point for access requests from external devices. The -j parameter specifies the next rule chain for access requests from external devices. For example, in the above forwarding rule, if an external device accesses port 8081 on the target host, the access request is forwarded to the kube-svc-a rule chain.

[0144] In the network forwarding rules above, the -A parameter in the second and fifth rule chains begins with "KUBE-SVC." In these two rule chains, the -j parameter specifies the next rule chain to which access requests from external devices are forwarded. For example, in the KUBE-SVC-A rule chain, access requests are forwarded to the KUBE-SEP-A rule chain.

[0145] In the above network forwarding rules, the third rule chain has the -A parameter starting with KUBE-SEP. In this rule chain, the --to-destination parameter indicates the ultimate destination to which the external device's access request is forwarded. This ultimate destination is the container's IP address and container listening port for the service the request is seeking to access. For example, in the KUBE-SEP-A rule chain, the access request is ultimately forwarded to port 8080 of the container with IP address 172.21.72.196.

[0146] After parsing the target host's network forwarding rules, the server can obtain the mapping between the container's listening port and the target host's proxy port. The service can organize multiple mappings to create a port mapping table. For example, after parsing the aforementioned network forwarding rules, the mapping table shown in Table 5 can be obtained.

[0147] Table 5

[0148] IP address Container listening port Target host proxy port 192.168.1.2 8080 8081 192.168.1.2 3306 3307

[0149] The IP address is the IP address of the target host.

[0150] Step 34: Determine the target host proxy port of each containerized service based on the port mapping relationship table and the container listening port of each containerized service.

[0151] In this step, the server has already determined the container listening interface corresponding to each containerized service in step 32 based on the process information of each containerized service and the network connection information of the target host. Based on the container listening interface corresponding to each containerized service, the server can search the port mapping table determined in step 33 to determine the target host proxy port corresponding to each containerized service. For example, for a containerized service with a process identifier of 60431, the port number of its container listening port is 8080. The server can query the port mapping table and find that the target host proxy port corresponding to this container listening port is 8081.

[0152] In one implementation, after determining the target host proxy port corresponding to each containerized service's container listening port, the server can update the corresponding port number in the asset information table. For example, based on the asset information table shown in Table 3, the port numbers of the target host proxy ports of two services to be detected that have container listening ports can be added to Table 3. The updated Table 3 can be as follows.

[0153] Table 3

[0154] IP address Target host listening port Container listening port Target host proxy port Service Type 192.168.1.2 null 8080 8081 Harbor 192.168.1.2 null 3306 3307 Mysql 192.168.1.2 8090 null null SwaggerUI 192.168.1.2 6379 null null Redis

[0155] S103: Determine the network address of each service to be detected based on the target host listening port of the non-containerized service, the target host proxy port of the containerized service, and the IP address in the host information.

[0156] In this embodiment, if the target host listening port exists for the service to be detected, it indicates that the service to be detected is a non-containerized service running on the target host. The server can determine the network address of each non-containerized service based on the port number of the target host listening port of each non-containerized service and the IP address of the target host. For example, for the non-containerized service with a service type of SwaggerUI in Table 3, its network address can be represented as 192.168.1.2:8090.

[0157] If the target host listening port for the service being tested is empty, it indicates that the service being tested is a containerized service running in a container. Therefore, the service being tested has a target host proxy port. The server can determine the network address of each containerized service based on the port number of the target host proxy port of each containerized service and the IP address of the target host. For example, for the containerized service with the service type Harbor in Table 3, its network address can be represented as 192.168.1.2:8081.

[0158] S104: Execute vulnerability detection according to a preset vulnerability detection rule base, the service type and the network address of each service to be detected.

[0159] In this embodiment, the server may store a pre-set vulnerability detection rule base. The vulnerability detection rule base includes multiple vulnerability detection rules. Different vulnerability detection rules can be used to verify whether the services to be detected of different service types have vulnerabilities. For example, the vulnerability detection rule base is shown in Table 6 below.

[0160] Table 6

[0161]

[0162]

[0163] As shown in Table 6, two vulnerability detection rules can be included. The first vulnerability detection rule is used to detect the unauthorized access vulnerability of the Harbor API of the service to be tested, whose service type is Harbor. The second vulnerability detection rule is used to detect the unauthorized access vulnerability of the SwaggerUI of the service to be tested, whose service type is SwaggerUI.

[0164] The server can determine at least one vulnerability detection rule corresponding to each service to be detected based on the service type of each service to be detected and the vulnerability detection rule library. Based on the vulnerability detection rule, the server can generate a request packet to access the service to be detected. The server can send the request packet to the service to be detected based on the network address and receive a response packet. Based on the response packet, the server can determine whether the service to be detected has a vulnerability, thereby completing the vulnerability detection process.

[0165] In one example, the vulnerability detection process may include the following steps:

[0166] Step 1: According to the service type of each service to be detected, at least one vulnerability detection rule corresponding to each service to be detected is obtained from a vulnerability detection rule library.

[0167] In this step, the server can determine the service type of each service to be detected according to the above steps. Based on the service type, the server queries the vulnerability detection rule library for at least one vulnerability detection rule corresponding to the service type. For example, when the service type is Harbor, one vulnerability detection rule can be queried in the vulnerability detection rule library shown in Table 6. The vulnerability detection rule can be shown as the first one in Table 6. In actual use, the vulnerability detection rule library can include more vulnerability detection rules. Among them, each service type can correspond to at least one vulnerability detection rule. Therefore, when the server queries the vulnerability detection rule library according to the service type of the service to be detected, the server can obtain all vulnerability detection rules corresponding to the service type.

[0168] Step 2: Generate a request packet corresponding to each vulnerability detection rule.

[0169] In this step, the server can construct a request packet for triggering the vulnerability based on the request type, API interface, vulnerability signature string, and other information in a vulnerability detection rule. For example, for the first vulnerability detection rule in Table 6, the server can generate a GET request packet based on its request type, API interface, and other information.

[0170] Step 3: According to the network address of each service to be detected, send the request packet of the corresponding vulnerability detection rule and receive the returned response packet.

[0171] In this step, the server can determine the network address corresponding to each service to be detected according to the above step S103. The server can send a constructed request packet to the network address of the target host. For example, for the Harbor service with the network address 192.168.1.2:8081, the server can send a request packet to 192.168.1.2:8081 / api / version to verify whether there is unauthorized access to the Harbor API based on its corresponding vulnerability detection, so as to detect whether the vulnerability exists. The server can also receive a response packet returned by the target host.

[0172] Step 4: Parse the response packet. When the response packet contains the fifth character string preset in the corresponding vulnerability detection rule, determine that the service to be detected has a vulnerability corresponding to the vulnerability detection rule.

[0173] In this step, the server can parse the response packet and obtain the string in the response packet. The server can determine the fifth string based on the vulnerability detection rule. For example, as shown in Table 6, the fifth string can be the field corresponding to the vulnerability feature string. Each vulnerability detection rule can uniquely correspond to a fifth string. When the string in the response packet includes the fifth string, the server can determine that the service to be detected has the vulnerability corresponding to the vulnerability detection rule. Otherwise, the server can determine that the service to be detected does not have the vulnerability corresponding to the vulnerability detection rule. For example, the server receives a response packet returned after sending a GET request packet to 192.168.1.2:8081 / api / version. The server can parse the response packet and determine that the string in the response packet is {"version":"v2.0"}. The server can also determine that the fifth string is {"version": according to the vulnerability detection rule corresponding to the first row in Table 6. The server can match the fifth string with the string in the response packet and determine that the string in the response packet includes the fifth string. Therefore, the server can determine that the service to be tested with the network address 192.168.1.2:8081 has a vulnerability in unauthorized access to the Harbor API.

[0174] In one example, after a vulnerability is detected, the server may also write the detected service and its corresponding vulnerability into a vulnerability list. The vulnerability list may be as shown in Table 7 below. The vulnerability list may include the vulnerability name and network address corresponding to the vulnerability. In Table 7, the network address may be divided into two fields: an IP address and a port number. The port number may be the target host's listening port or the target host's proxy port.

[0175] Table 7

[0176] Serial number Vulnerability Name IP address Port number 1 Harbor API unauthorized access 192.168.1.2 8081 2 SwaggerUI unauthorized access 192.168.1.2 8080

[0177] The containerized service vulnerability detection method provided in this application can obtain the host information of the target host and the process information corresponding to each service on the target host. The host information may include the IP address of the target host and at least one network connection information. The server can determine the service type of each service to be detected based on the process information corresponding to each service to be detected and a preset service identification library. The service to be detected can be a containerized service or a non-containerized service. When the service to be detected is a non-containerized service, the server can directly obtain the port number of the target host listening port corresponding to the service to be detected from the process information of the service to be detected. When the service to be detected is a containerized service, the server can determine the container listening port of the containerized service in the container and the corresponding target host proxy port based on the process information of the proxy process, the network connection information of the target host, and the network forwarding rules of the target host. The server can determine the network address of each non-containerized service based on the port number of the target host listening port of each non-containerized service and the IP address of the target host. The server can determine the network address of each containerized service based on the port number of the target host proxy port of each containerized service and the IP address of the target host. The server can determine at least one vulnerability detection rule corresponding to each service to be detected based on the service type of each service to be detected and the pre-set vulnerability detection rule base. The server can send the generated request packet to the network address corresponding to the service to be detected and obtain a response packet based on each service to be detected and its corresponding vulnerability detection rule. The server can determine whether there is a vulnerability in the service to be detected based on the response packet, thereby completing the execution process of the vulnerability detection. In this application, the service type of each service to be detected is determined by the service fingerprint. In this application, the container listening port and the target host proxy port corresponding to the containerized service running in the container are determined by obtaining the network connection information and network forwarding rules of the target host, thereby achieving accurate judgment of the service type of the containerized service, thereby accurately obtaining the vulnerability detection rules corresponding to the containerized service, and improving the accuracy and efficiency of vulnerability detection.

[0178] Based on the above embodiments, this embodiment can determine the container listening port of the containerized service based on the network connection information of the target host and the process information of each service to be detected. In addition, this embodiment can also use the netstat command in the container to obtain the container listening port of the containerized service. However, since containers usually need to be installed minimally, the netstat program may not be installed in many containers. That is, in some containers, it may not be possible to use the natstat command to obtain the container listening port of the containerized service. Therefore, although this replacement method can implement the technical solution of the present application, the technical solution of the present application is more universal than this replacement solution.

[0179] Figure 3 FIG. 1 shows a schematic diagram of a containerized service vulnerability detection device provided by an embodiment of the present application. Figure 3 As shown, the containerized service vulnerability detection device 10 of this embodiment is used to implement the operation corresponding to the server in any of the above method embodiments. The containerized service vulnerability detection device 10 of this embodiment includes:

[0180] The acquisition module 11 is used to acquire the host information of the target host and the process information corresponding to each service to be detected in the target host.

[0181] The detection module 12 is used to determine the service type of each service to be detected based on the host information, the process information corresponding to each service to be detected, and the preset service identification library. When the service to be detected is a non-containerized service, the target host listening port of the service to be detected is the target host proxy ...

[0182] In one example, the detection module 12 is specifically configured to:

[0183] The process command or process loading file in the process information of each service to be detected is used to match the service identifier in the service identifier library to determine the service type corresponding to each service to be detected.

[0184] When the service to be detected is a non-containerized service, the target host listening port of the non-containerized service is obtained from the process information of each non-containerized service.

[0185] When the service to be detected is a containerized service, the target host proxy port of each containerized service is determined based on the process information and host information corresponding to each containerized service. In one example, the detection module 12 is specifically used to:

[0186] Traverse the service IDs in the service ID library.

[0187] The third string corresponding to each service identifier in the service identifier library is matched with the first string corresponding to the process command of each service to be detected or the second string corresponding to the process loading file to determine whether the first string or the second string contains the third string.

[0188] When the first character string or the second character string contains the third character string, the service type of the to-be-detected service corresponding to the first character string or the second character string is determined according to the service identifier corresponding to the third character string.

[0189] In one example, the detection module 12 is specifically configured to:

[0190] According to the socket file index node number and the network connection information in the process information of each containerized service, target network connection information corresponding to each containerized service is determined to be in a listening state.

[0191] Determine the container listening port corresponding to the containerized service based on the target network connection information.

[0192] According to the network forwarding rules, a port mapping relationship table is constructed between the container and the target host.

[0193] The target host proxy port of each containerized service is determined based on the port mapping relationship table and the container listening port of each containerized service.

[0194] In one example, the detection module 12 is further configured to:

[0195] If the process control group file of the process information of the service to be detected contains the fourth character string, the service to be detected is determined to be a containerized service. Otherwise, the service to be detected is determined to be a non-containerized service.

[0196] In one example, the detection module 12 is specifically configured to:

[0197] According to the service type of each service to be detected, at least one vulnerability detection rule corresponding to each service to be detected is obtained from a vulnerability detection rule library.

[0198] Generate a request packet corresponding to each vulnerability detection rule.

[0199] According to the network address of each service to be detected, the corresponding vulnerability detection rule request packet is sent and the returned response packet is received.

[0200] The response packet is parsed, and when the response packet contains the fifth character string preset in the corresponding vulnerability detection rule, it is determined that the service to be detected has a vulnerability corresponding to the vulnerability detection rule.

[0201] In one example, the detection module 12 is further configured to:

[0202] When a vulnerability is detected, it is written into a vulnerability list, which contains the detection rules and network addresses corresponding to the vulnerability.

[0203] The containerized service vulnerability detection device 10 provided in the embodiment of the present application can execute the above method embodiment. Its specific implementation principles and technical effects can be found in the above method embodiment, and this embodiment will not be repeated here.

[0204] Figure 4 FIG1 shows a hardware structure diagram of a server provided in an embodiment of the present application. Figure 4 As shown, the server 20 is used to implement the operations corresponding to the server in any of the above method embodiments. The server 20 of this embodiment may include: a memory 21 and a processor 22.

[0205] Memory 21 is used to store computer programs. Memory 21 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk memory. It may also be a USB flash drive, a mobile hard drive, a read-only memory, a magnetic disk, or an optical disk.

[0206] The processor 22 is used to execute the computer program stored in the memory to implement the containerized service vulnerability detection method in the above embodiment. For details, please refer to the relevant description in the above method embodiment. The processor 22 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or the processor can be any conventional processor, etc. The steps of the method disclosed in the invention can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

[0207] Optionally, the memory 21 may be independent or integrated with the processor 22 .

[0208] When the memory 21 is a device independent of the processor 22, the server 20 may further include a bus 23. The bus 23 is used to connect the memory 21 and the processor 22. The bus 23 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of presentation, the buses in the drawings of this application are not limited to only one bus or one type of bus.

[0209] The server provided in this embodiment can be used to execute the above-mentioned containerized service vulnerability detection method. Its implementation method and technical effects are similar and will not be repeated here in this embodiment.

[0210] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, it is used to implement the methods provided in the various embodiments described above.

[0211] Among them, the computer-readable storage medium can be a computer storage medium or a communication medium. The communication medium includes any medium that facilitates the transmission of a computer program from one place to another. The computer storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer. For example, a computer-readable storage medium is coupled to a processor so that the processor can read information from the computer-readable storage medium and write information to the computer-readable storage medium. Of course, the computer-readable storage medium can also be an integral part of the processor. The processor and the computer-readable storage medium can be located in an application-specific integrated circuit (ASIC). In addition, the ASIC can be located in a user device. Of course, the processor and the computer-readable storage medium can also exist in a communication device as discrete components.

[0212] Specifically, the computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0213] The present application also provides a computer program product, comprising a computer program stored in a computer-readable storage medium. At least one processor of a device can read the computer program from the computer-readable storage medium, and at least one processor executes the computer program so that the device implements the methods provided in the various embodiments described above.

[0214] An embodiment of the present application also provides a chip, which includes a memory and a processor, the memory is used to store computer programs, and the processor is used to call and run the computer programs from the memory, so that a device equipped with the chip executes the methods in various possible implementation modes as described above.

[0215] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules is only a logical function division. In actual implementation, there may be other division methods, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0216] The modules may be physically separate, for example, installed in different locations on a single device, or installed on different devices, or distributed across multiple network units, or distributed across multiple processors. The modules may also be integrated, for example, installed in the same device, or integrated into a set of codes. The modules may exist in the form of hardware, or in the form of software, or may be implemented in the form of software plus hardware. The present application may select some or all of the modules according to actual needs to achieve the purpose of the present embodiment.

[0217] When each module is implemented as an integrated module in the form of a software function module, it can be stored in a computer-readable storage medium. The above-mentioned software function module is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform some steps of the methods of each embodiment of the present application.

[0218] It should be understood that, although the various steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they may be performed in other orders. Moreover, at least a portion of the steps in the figure may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily performed at the same time, but may be performed at different times, and their execution order is not necessarily sequential, but may be performed in turn or alternately with other steps or at least a portion of sub-steps or stages of other steps.

[0219] Finally, it should be noted that the above embodiments are intended only 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 aforementioned embodiments, those skilled in the art will appreciate that they may modify the technical solutions described in the aforementioned embodiments or replace some or all of the technical features therein with equivalents. However, such modifications or replacements do not deviate from the essence of the corresponding technical solutions within the scope of the various embodiments of this application.

Claims

1. A containerized service vulnerability detection method, characterized in that: The method comprises: Obtaining host information of a target host and process information corresponding to each service to be detected in the target host; the host information includes at least one network connection information and a network forwarding rule; Determine the service type of each service to be detected based on the host information, the process information corresponding to each service to be detected, and a preset service identification library, and when the service to be detected is a non-containerized service, the target host listening port of the service to be detected; When the service to be detected is a containerized service, the target network connection information corresponding to each containerized service is determined to be in a listening state according to the socket file index node number and the network connection information in the process information of each containerized service; the container listening port corresponding to the containerized service is determined according to the target network connection information; according to the network forwarding rule, a port mapping relationship table between the container and the target host is constructed; according to the port mapping relationship table and the container listening port of each containerized service, the target host proxy port of each containerized service is determined; Determine the network address of each of the services to be detected based on the target host listening port of the non-containerized service, the target host proxy port of the containerized service, and the IP address in the host information; Vulnerability detection is performed according to a preset vulnerability detection rule library, the service type and the network address of each service to be detected.

2. The method according to claim 1, characterized in that The determining, based on the host information, the process information corresponding to each of the services to be detected, and a preset service identification library, of the service type of each of the services to be detected, and the target host listening port of the service to be detected when the service to be detected is a non-containerized service, specifically includes: Matching the process command or process loading file in the process information of each service to be detected with the service identifier in the service identifier library to determine the service type corresponding to each service to be detected; When the service to be detected is a non-containerized service, the target host listening port of the non-containerized service is obtained from the process information of each non-containerized service.

3. The method according to claim 2, characterized in that The matching of the process command or process loading file in the process information of each service to be detected with the service identifier in the service identifier library to determine the service type corresponding to each service to be detected specifically includes: Traversing the service identifiers in the service identifier library; Matching the third string corresponding to each service identifier in the service identifier library with the first string corresponding to the process command of each service to be detected or the second string corresponding to the process loading file, and determining whether the first string or the second string contains the third string; When the first character string or the second character string contains the third character string, the service type of the to-be-detected service corresponding to the first character string or the second character string is determined according to the service identifier corresponding to the third character string.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: When the process control group file of the process information of the service to be detected contains a fourth character string, it is determined that the service to be detected is a containerized service; otherwise, it is determined that the service to be detected is a non-containerized service.

5. The method according to any one of claims 1 to 3, characterized in that The performing vulnerability detection according to the preset vulnerability detection rule base, the service type and the network address of each service to be detected specifically includes: Obtaining, from the vulnerability detection rule library, at least one vulnerability detection rule corresponding to each of the services to be detected according to the service type of each of the services to be detected; Generate a request packet corresponding to each vulnerability detection rule; According to the network address of each service to be detected, the request packet of the corresponding vulnerability detection rule is sent to the upstream server, and a returned response packet is received; The response packet is parsed, and when the response packet contains a fifth character string preset in the corresponding vulnerability detection rule, it is determined that the service to be detected has a vulnerability corresponding to the vulnerability detection rule.

6. The method according to any one of claims 1 to 3, characterized in that The method further comprises: When a vulnerability is detected, the vulnerability is written into a vulnerability list; wherein the vulnerability list includes the vulnerability name and the network address corresponding to the vulnerability.

7. A containerized service vulnerability detection device, characterized in that: The device comprises: An acquisition module, configured to acquire host information of a target host and process information corresponding to each service to be detected in the target host; the host information includes at least one network connection information and a network forwarding rule; A detection module is configured to determine, based on the host information, the process information corresponding to each service to be detected, and a preset service identification library, the service type of each service to be detected; when the service to be detected is a non-containerized service, the target host listening port of the service to be detected; and when the service to be detected is a containerized service, determine, based on the socket file index node number in the process information of each containerized service and the network connection information, the target network connection information of each containerized service with the connection state corresponding to the containerized service being in the listening state; determine, based on the target network connection information, the container listening port corresponding to the containerized service; construct, based on the network forwarding rule, a port mapping relationship table between the container and the target host; determine, based on the port mapping relationship table and the container listening port of each containerized service, the target host proxy port of each containerized service; determine, based on the target host listening port of the non-containerized service, the target host proxy port of the containerized service, and the IP address in the host information, the network address of each service to be detected; and perform vulnerability detection based on a preset vulnerability detection rule library, the service type of each service to be detected, and the network address.

8. A server, characterized in that: The server includes: a memory and a processor; the memory is used to store a computer program; the processor is used to implement the containerized service vulnerability detection method according to any one of claims 1 to 6 according to the computer program stored in the memory.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, is used to implement the containerized service vulnerability detection method according to any one of claims 1 to 6.

Images