A vulnerability control method and system based on public cloud

Abstract

The present application provides a vulnerability management method and system based on a public cloud, which manages CVE vulnerabilities in a shared cloud scenario through a vulnerability management system. The vulnerability management system improves the response speed by establishing a long connection between the server and the client. For the CVE vulnerabilities to be processed, the server sends the repair plan to a batch of Linux servers, and finally the client feeds back the repair results to the server. This model can greatly improve the management efficiency of the Linux server operating system in the public cloud scenario.

Description

Technical Field

[0001] The present application relates to the technical field of operating system vulnerability repair, and specifically to a vulnerability management method and system based on a public cloud. Background Art

[0002] At present, cloud computing servers represented by CentOS manage Linux operating system vulnerabilities from the operating system itself. Vulnerabilities are fixed through single-machine processing or batch management tools such as Ansible. These vulnerability management methods are based on single-machine batch management. Currently, batch operating system vulnerabilities are managed based on a single-machine model, lacking a unified management entry. Even when using a batch management tool such as Ansible, a new playbook needs to be released for each different CVE vulnerability repair solution. In addition, this single-machine processing mode is very unfriendly to large distributed scenarios such as public clouds in cloud computing. Summary of the invention

[0003] In order to solve the above technical problems, the present invention proposes a vulnerability management method and system based on public cloud, which changes the current CVE management mode of Linux server operating system through a unified management entrance and a unified method, and realizes the unified management of Linux operating system in large-scale distributed scenarios such as public cloud. The technical solutions adopted in this application are as follows:

[0004] A vulnerability control method based on a public cloud, the method comprising:

[0005] Step 1: Obtain CVE vulnerability release information, and the server customizes the corresponding repair script according to the vulnerability release information;

[0006] Step 2: The server sends the repair script to the Linux servers of each client;

[0007] Step 3: The client compares the repairable scenario in the repair script with the current state of the local software to determine whether the current state of the local software meets the repair condition; if so, execute step 4; if not, return and repeat step 1;

[0008] Step 4: The client performs vulnerability repair operations according to the vulnerability repair solution in the repair script and tests the repair results; if the repair is successful, execute step 5; if the repair is unsuccessful, return and repeat step 1;

[0009] Step 5: The client sends a repair success notification message to the server.

[0010] Furthermore, in step 1, a corresponding repair script is customized, including: for a CVE vulnerability to be repaired, the administrator releases a CVE patch to the server side Server, and simultaneously enters the repair script into the server side Server.

[0011] Furthermore, in step 1, a corresponding repair script is customized, including: the server side queries the database side according to the CVE vulnerability release information, and if there is a repair script associated with the CVE vulnerability release information, the associated repair script is used as the customized repair script.

[0012] Furthermore, the repair script includes repairable scenarios and vulnerability repair solutions, and the vulnerability repair solution includes preparation before repair, execution during repair, operation after repair, and testing after repair is completed.

[0013] Furthermore, in step 2, the server sends the repair script by reusing the pre-established long connection between the Linux server and each client.

[0014] Furthermore, in step 4, a vulnerability repair operation is performed, including: preparation before repair, execution during repair, and operation after repair according to the vulnerability repair plan.

[0015] Furthermore, in step 5, after the repair success notification message is fed back, it also includes: the server side associates the repair script obtained from the repair success notification message with the CVE vulnerability release information and stores them in the database side.

[0016] Furthermore, for the two cases where step 1 needs to be repeated, the server will re-customize the repair script and re-execute steps 2 to 5 until the vulnerability is successfully repaired.

[0017] A vulnerability management system based on a public cloud, which is used to execute the above method, is characterized in that: the system includes a server side, a database side and at least one client side, and adopts a master-slave architecture to distinguish the client from the server; a long connection is established between the server side and the client side.

[0018] Furthermore, the database end is used to store repair scripts associated with CVE vulnerability release information.

[0019] Through the embodiments of the present application, the following technical effects can be obtained: CVE vulnerabilities in a shared cloud scenario can be managed through a vulnerability management system. Compared with the existing stand-alone mode, unified management of batches of Linux server operating systems can be achieved. The vulnerability management system improves the response speed by establishing a long connection between the server and the client. For the CVE vulnerabilities to be processed, the server sends the repair plan to the batch of Linux servers, and finally the client feeds back the repair results to the server. This mode can greatly improve the management efficiency of the Linux server operating system in the public cloud scenario. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, 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 paying any creative labor.

[0021] Figure 1 This is a schematic diagram of the deployment environment of the vulnerability control system;

[0022] Figure 2 This is a flowchart of the long connection response mode;

[0023] Figure 3 The figure is a process flow diagram of the vulnerability control method. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0025] In this application, a CVE (Common Vulnerabilities & Exposures) vulnerability management system is used to achieve unified management of batch Linux server operating systems in cloud scenarios. In the CVE vulnerability management system, a long connection is established between the server and the agent of the Linux server to reduce network latency and improve response speed.

[0026] The design and deployment model of vulnerability management system is as follows Figure 1As shown, Server represents the server side, Linux server represents the client side, and also includes a database side (not shown). The vulnerability management system uses a master-slave architecture to distinguish the client from the server. On the database side, a repair script associated with the CVE vulnerability release information is stored.

[0027] The server and the client use a long connection, and the response mode is as follows Figure 2 As shown. A long connection means that multiple data packets can be sent continuously on a connection. If no data packets are sent during the connection, both parties need to send link detection packets. Long connections are mostly used for frequent operations, point-to-point communication, and the number of connections cannot be too large. For example, database connections use long connections. If short connections are used for frequent communication, socket errors will occur, and frequent socket creation is also a waste of resources.

[0028] In the technical solution of the present application, a long link is established between the server and the client to reduce the frequent communication between the two, and the response speed is improved by multiplexing the connection. Usually when we initiate an HTTP request, we need to first complete the TCP three-way handshake, then transmit the data, and finally release the connection. In the case of high-concurrency request connections or when the client makes multiple frequent request operations, unlimited creation will lead to poor performance. By reusing the connection, the connection will not be closed during the timeout idle time, and the same repeated HTTP request will reuse the original connection, reducing the number of handshakes and greatly improving efficiency.

[0029] When there is a vulnerability that needs to be handled, the specific CVE vulnerability repair plan is sent to the Linux server of each client through the server on the server side. Each client repairs the vulnerability according to the received CVE vulnerability repair plan and returns the final repair result to the server side. The process is as shown in the attached figure. Figure 2 The repair script includes information describing the scenarios in which the vulnerability can be repaired and the vulnerability repair plan. The vulnerability repair plan describes in detail how to repair, as well as the operations required before repair, specific repair operations, post-repair operations, and repair tests. The vulnerability management method includes the following steps:

[0030] Step 1: Obtain CVE vulnerability release information, and the server customizes the corresponding repair script according to the vulnerability release information;

[0031] In step 1, the corresponding repair script is customized, including: for a CVE vulnerability to be repaired, the administrator releases the CVE patch to the server, and enters the CVE repair script to the server;

[0032] In step 1, a corresponding repair script is customized, including: the server side queries the database side according to the CVE vulnerability release information, and if there is a repair script associated with the CVE vulnerability release information, the associated repair script is used as the customized repair script.

[0033] The repair script includes repairable scenarios and vulnerability repair solutions, and the vulnerability repair solution includes preparation before repair, execution during repair, operation after repair, and testing after repair completion;

[0034] Step 2: The server sends the repair script to the Linux servers of each client;

[0035] In step 2, the server sends the repair script by reusing the pre-established long connection with the Linux server of each client;

[0036] Step 3: The client compares the repairable scenario in the repair script with the current state of the local software to determine whether the current state of the local software meets the repair condition; if so, execute step 4; if not, return and repeat step 1;

[0037] Step 4: The client performs vulnerability repair operations according to the vulnerability repair solution in the repair script and tests the repair results; if the repair is successful, execute step 5; if the repair is unsuccessful, return and repeat step 1;

[0038] In step 4, the vulnerability repair operation is performed, including: preparation before repair, execution during repair, and operation after repair according to the vulnerability repair plan;

[0039] Step 5: The client sends a repair success notification message to the server.

[0040] In step 5, after the repair success notification message is fed back, it also includes: the server side associates the repair script obtained from the repair success notification message with the CVE vulnerability release information and stores them in the database side.

[0041] In the above method, for the two situations where step 1 needs to be repeated, the server side will re-customize the repair script and re-execute steps 2 to 5 until the vulnerability is successfully repaired.

[0042] In summary, the technical solution of this application realizes the unified management of CVE vulnerabilities of batches of Linux server operating systems in cloud scenarios by the vulnerability management system. The vulnerability management system establishes a connection with the client in a long connection mode on the server side, and then formulates a repair script on the server side and sends the specific repair plan to the client agent. The client repairs the vulnerability according to the repair script and feeds back the repair results to the server side. This mode can greatly improve the management efficiency of the Linux server operating system in the public cloud scenario.

[0043] Although the specific implementation methods of the present application are described above, those skilled in the art should understand that these are only examples, and the protection scope of the present application is defined by the appended claims. Those skilled in the art may make various changes or modifications to these implementation methods without departing from the principles and essence of the present application, but these changes and modifications all fall within the protection scope of the present application.

Claims

1. A vulnerability management method based on public cloud, characterized in that: The method includes: Step 1: Obtain CVE vulnerability release information, and the server customizes the corresponding repair script according to the CVE vulnerability release information; Step 2: The server sends the repair script to the Linux servers of each client; Step 3: The client compares the repairable scenario in the repair script with the current state of the local software to determine whether the current state of the local software meets the repair condition; if so, execute step 4; if not, return and repeat step 1; Step 4: The client performs vulnerability repair operations according to the vulnerability repair solution in the repair script and tests the repair results; if the repair is successful, execute step 5; if the repair is unsuccessful, return and repeat step 1; Step 5: The client sends a successful repair notification message to the server. In step 1, the corresponding repair script is customized, including: for a CVE vulnerability to be repaired, the administrator releases the CVE patch to the server, and enters the repair script to the server; In step 1, a corresponding repair script is customized, including: the server side queries the database side according to the CVE vulnerability release information, and if there is a repair script associated with the CVE vulnerability release information, the associated repair script is used as the customized repair script.

2. The method according to claim 1, characterized in that The repair script includes repairable scenarios and vulnerability repair solutions, and the vulnerability repair solution includes preparation before repair, execution during repair, operation after repair, and testing after repair is completed.

3. The method according to claim 1, characterized in that In step 2, the server sends the repair script by reusing the pre-established long connection with the Linux server of each client.

4. The method according to claim 1, characterized in that In step 4, the vulnerability repair operation is performed, including: preparation before repair, execution during repair, and operation after repair according to the vulnerability repair plan.

5. The method according to claim 1, characterized in that In step 5, after the repair success notification message is fed back, it also includes: the server side associates the repair script obtained from the repair success notification message with the CVE vulnerability release information and stores them in the database side.

6. The method according to claim 1, characterized in that For the two cases where step 1 needs to be repeated, the server will re-customize the repair script and re-execute steps 2 to 5 until the vulnerability is successfully repaired.

7. A vulnerability management system based on a public cloud, the system being used to execute the method according to any one of claims 1 to 6, characterized in that: The system includes a server side, a database side and at least one client side, and uses a master-slave architecture to distinguish the client from the server; A long connection is established between the server and the client.

8. The system according to claim 7, characterized in that The database end is used to store repair scripts associated with CVE vulnerability release information.

Images