CN113486362B - 服务器的漏洞修复方法、装置和计算机设备 - Google Patents

Abstract

本申请涉及人工智能技术，公开了一种服务器的漏洞修复方法、装置和计算机设备，其中，方法包括：获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称；进而得到漏洞的CVE号；根据漏洞的CVE号查找与CVE号对应的组件更新版号；在yum数据库中下载组件安装包，并利用组件安装包升级漏洞对应的组件；在预设的依赖数据库中查找与组件对应的依赖组件，其中，组件为漏洞对应的组件；向预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用依赖组件安装包升级依赖组件，完成修复。本申请提供的服务器的漏洞修复方法、装置和计算机设备，解决了现有技术中漏洞修复过程繁琐且耗时长的技术问题。

Description

服务器的漏洞修复方法、装置和计算机设备

技术领域

本申请涉及漏洞修复技术领域，特别涉及一种服务器的漏洞修复方法、装置和计算机设备。

背景技术

服务器的插件在设计的过程中会存在一些没有想到的问题，导致插件在运行一段时间后，被测试出有问题，即漏洞。传统的漏洞修复方式是漏洞扫描工具检测出漏洞，然后运维人员登录服务器，通过yum方式或者源码升级到最新的版本。整个过程需要运维人员查询所需要升级的组件对应的解决版本，下载对应的安装文件，然后升级到最新的版本。在此过程中，由于有些漏洞不只是修复组件本身，还需要安装其他组件以解决依赖问题，整个过程繁琐，且耗时长。

发明内容

本申请的主要目的为提供一种服务器的漏洞修复方法、装置和计算机设备，旨在解决现有技术中漏洞修复过程繁琐且耗时长的技术问题。

本申请提出一种服务器的漏洞修复方法，包括：

获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到获取各服务器需要修复的漏洞的名称；

根据所述漏洞的名称得到漏洞的CVE号；

根据所述漏洞的CVE号在CVE数据库中查找与所述CVE号对应的组件更新版号；

根据所述组件更新版号在yum数据库中下载与所述组件更新版号对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件；

在预设的依赖数据库中查找与所述组件对应的依赖组件，其中，所述组件为所述漏洞对应的组件；

向所述预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用所述依赖组件安装包升级所述依赖组件，完成所述漏洞的修复。

进一步地，所述获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称之后，还包括：

判断当前时间是否为用户预设的修复时间；

若所述当前时间不是用户预设的修复时间，则获取用户的修复习惯；其中，所述修复习惯包括修复超过第一设定次数的漏洞、修复时间小于第一设定时间的漏洞；

根据所述修复习惯得到对应的漏洞的名称；

若所述当前时间是用户预设的修复时间，则获取所述用户具有权限的服务器的漏洞的名称。

进一步地，所述获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称之后，还包括：

获取漏洞的历史修复数据，并提取修复超过第二设定次数的漏洞以形成漏洞集合；

获取所述漏洞集合中的所有漏洞的维度；其中，所述维度包括漏洞的类型，以及漏洞所属的服务器；

将出现次数最多维度作为目标维度，并像用户发送选择窗口；

判断用户是否选择所述目标维度；

若否，则接收用户选择的新的修复维度；

获取用户选择的新的修复维度对应的漏洞的名称。

进一步地，所述根据所述漏洞的名称得到漏洞的CVE号之前，还包括：

获取所述漏洞的修复过程的日志并判断是否具有修复失败的记录；

若不具有修复失败的记录，则判断用户是否选择最小升级版本；

若用户未选择最小升级版本，则根据所述漏洞在yum数据库中下载所述漏洞对应的最新组件安装包，并利用所述最新组件安装包升级所述漏洞对应的组件；其中，所述最新组件安装包为能够将所述漏洞对应的组件升级到最新版本的组件安装包；

若用户选择最小升级版本，则执行所述获取所述修复维度对应的漏洞的CVE号的步骤；

若具有修复失败的记录，则判断是否接收到新的修复文档；

若接收到新的修复文档，则对修复文档中进行分词，得到关键词；

根据所述关键词在所述yum数据库中查找并下载对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件；

若未接收到新的修复文档，则暂停修复并在前端显示所述漏洞以及所述漏洞暂停修复的原因。

进一步地，所述根据所述漏洞的CVE号在CVE数据库中查找与所述CVE号对应的组件更新版号之前，还包括：

在第一预设时间段内，向用户发送带有更新或不更新的选项的窗口，以便用户进行选择；其中，所述窗口为对所述CVE数据库的操作指令；

判断是否接收到用户选择更新或不更新的指令；

若未接收到用户的指令，则根据红帽官网对所述CVE数据库进行同步更新；

若接收到用户的指令，则判断所述指令为更新或不更新；

若所述指令为更新，则根据红帽官网对所述CVE数据库进行同步更新；

若所述指令为不更新，则停止更新所述CVE数据库。

进一步地，所述向所述预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用所述依赖组件安装包升级所述依赖组件之后，还包括：

判断所述漏洞是否修复成功；

若所述漏洞修复失败，则将所述漏洞回滚到修复之前的状态并对所述漏洞进行标记；

向所述依赖数据库和yum数据库发送标记修复失败的指令，以对所述漏洞对应的组件安装包和依赖组件安装包进行标记；

当所述漏洞对应的组件安装包和依赖组件安装包被标记超过第三设定次数时，生成对所述组件安装包和依赖组件安装包进行处理的指令，以便用户进行人工处理；

若所述漏洞修复成功，则判断是否接收到所述漏洞对应的服务器发送的应用失败的信号；

若接收到所述漏洞对应的服务器发送的应用失败的信号，则生成是否回滚的指令以供用户选择。

进一步地，所述若所述漏洞修复失败，则将所述漏洞回滚到修复之前的状态之后，还包括：

记录所述漏洞的修复过程的日志和修复结果；其中，当所述修复结果为修复失败时，所述修复结果还包括失败原因；

将所述修复过程的日志和修复结果与所述漏洞的名称进行关联，并存储在redis数据库中；

在第三预设时间段内，删除所述redis数据库中第二设定时间之前存储的漏洞的名称、以及漏洞的名称对应的修复过程的日志和修复结果。

本申请还提供了一种服务器的漏洞修复装置，包括：

获取模块，用于获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称；

CVE号模块，用于根据所述漏洞的名称得到漏洞的CVE号；

第一查找模块，用于根据所述漏洞的CVE号在CVE数据库中查找与所述CVE号对应的组件更新版号；

第一升级模块，用于根据所述组件更新版号在yum数据库中下载与所述组件更新版号对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件；

第二查找模块，用于在预设的依赖数据库中查找与所述组件对应的依赖组件，其中，所述组件为所述漏洞对应的组件；

第二升级模块，用于向所述预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用所述依赖组件安装包升级所述依赖组件，完成所述漏洞的修复。

本申请还提供了一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述方法的步骤。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述方法的步骤。

本申请的有益效果为：通过分析得到各个服务器对应的漏洞的名称，并根据漏洞名称自动得到漏洞的CVE号，进而在CVE数据库中查找与CVE号对应的组件更新版号，在yum数据库中下载对应的组件安装包以对漏洞进行初步修复，并且在预设的依赖数据库中下载与依赖组件对应的依赖组件安装包以对漏洞进行彻底修复。登陆用户只需点击修复按钮，即可完成所有服务器的彻底修复，无需运维人员登陆单个服务器，并手动查找、下载所需要升级的组件对应的解决版本和其他解决依赖问题的组件，节省时间。

附图说明

图1为本申请一实施例的服务器的漏洞修复方法流程示意图。

图2为本申请一实施例的服务器的漏洞修复装置结构示意图。

图3为本申请一实施例的计算机设备内部结构示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

如图1所示，本申请提供了一种服务器的漏洞修复方法，包括：

S1、获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称；

S2、根据所述漏洞的名称得到漏洞的CVE号；

S3、根据所述漏洞的CVE号在CVE数据库中查找与所述CVE号对应的组件更新版号；

S4、根据所述组件更新版号在yum数据库中下载与所述组件更新版号对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件；

S5、在预设的依赖数据库中查找与所述组件对应的依赖组件，其中，所述组件为所述漏洞对应的组件；

S6、向所述预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用所述依赖组件安装包升级所述依赖组件，完成所述漏洞的修复。

本申请实施例可以基于人工智能技术对相关的数据进行获取和处理。其中，人工智能(Artificial Intelligence，AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用***。

如上述步骤S1所述，本方案提供一种漏洞修复平台，对接入的所有的linux服务器进行漏洞扫描，该扫描包括定时扫描和实时扫描，并将扫描结果中需要修复的漏洞进行展示，以便用户进行选择。定时扫描由管理人员设置扫描时间，在到达管理人员设置的扫描时间时，对所有的linux服务器进行漏洞扫描。或接入的所有linux服务器向漏洞修复平台发送安全漏洞信息，所述安全漏洞信息包括所述服务器中发生漏洞的漏洞组件和漏洞风险等级。漏洞风险等级根据安全漏洞危害及影响范围来衡量。例如，现阶段业界一般将漏洞划分为低、中、高和紧急四个漏洞风险等级。这里漏洞危害及影响范围会依次提升，响应的修复要求会依次提升。对所述安全漏洞信息进行语法分析和语义分析，句法分析和语义分析为基于人工智能技术的分析方法，从所述安全漏洞信息中提取安全关键信息，所述安全关键信息包括漏洞名称、类型等。从而在用户登陆漏洞修复平台，并点击修复指令后，漏洞修复平台对需要修复的漏洞进行修复。

如上述步骤S2-S3所述，当用户选择修复维度后，得到选择的修复维度下的漏洞的名称，进而能够通过漏洞的名称获取这些漏洞的CVE号(Common VulnerabilitiesExposures，通用漏洞披露，漏洞的CVE号与漏洞名称关联)。根据得到的漏洞的CVE号在CVE数据库中查找与CVE号对应的更新版号；CVE数据库中主要是存储CVE号，CVE号与组件的对应关系，并记录漏洞名称和对应组件的最小更新版号，为组件的最小升级依赖库，且CVE数据库通过用户手动点击进行更新，或设置定时更新，CVE数据库的更新为从红帽官方同步更新。

如上述步骤S4所述，根据从CVE数据库中获得的组件更新版号，在yum(Yellow dogUpdater,Modified，前端软件包管理器)数据库中下载与组件更新版号对应的组件安装包，在下载组件安装包之前，可以先判断该组件安装包被标记的次数(当组件安装包对应的漏洞多次修复失败时，组件安装包会被标记)，当被标记的次数超过了一定次数时，该组件安装包可能修复会导致修复失败，此时可以暂停下载，并在前端向用户展示暂停的原因，等待用户进行人工处理。yum数据库主要是提供完整的组件安装包，与CVE数据库相同的是，yum数据库通过用户手动点击进行更新，或设置定时更新，yum数据库的更新为从红帽官方同步组件安装包，以在yum数据库中加入新增的组件安装包。在下载到与组件更新版号对应的组件安装包后，利用组件安装包升级漏洞对应的组件，升级到组件安装包对应版本，完成对应漏洞的初步修复。

如上述步骤S5-S6所述，修复漏洞的过程是通过yum命令升级，yum命令本身会自动安装升级漏洞组件所需依赖组件，而某些组件漏洞除了需要升级组件本身还需要升级其他关联组件，而这些组件又不是当前组件的强依赖，yum命令升级时并不会升级这些组件；例如，linux内核本地提权(脏牛)漏洞(CVE-2016-5195)，根据CVE号查询CVE数据库发现只需要升级perf组件，但升级完成以后漏洞扫描还是存在perf组件漏洞，此时还需要升级python-perf组件才能完成该漏洞彻底修复。因此，本方案预设一个依赖数据库，在该数据库中存储与yum数据库的组件安装包对应的依赖组件名称，以及对应依赖组件的安装包(组件漏洞需要额外升级的非强依赖组件，例如前述perf组件的非强依赖组件python-perf)，通过在预设的依赖数据库中查找并下载与所述依赖组件对应的依赖组件安装包，完成对应漏洞的彻底修复。例如，在升级perf组件后，在预设的依赖数据库中下载python-perf组件安装包，对python-perf组件进行升级，完成漏洞的彻底修复，无需运维人员手动进行二次修复，方便快捷，节省时间。

在一个实施例中，所述获取各服务器需要修复的漏洞的名称之前，还包括：

S011、获取用户的登陆信息；

S012、根据所述用户的登陆信息确定所述用户的权限，得到所述用户具有权限的所有服务器。

如上述步骤S011-S012所述，在接收用户点击修复的指令的步骤之前，还需要获取用户的信息，在用户登陆漏洞修复平台后，得到用户的信息(账号、用户名等信息)，根据用户的信息可以确定用户的权限，即用户在漏洞修复平台上能够看到哪些linux服务器，或能看到哪些漏洞，或能够对哪些漏洞或linux服务器进行操作等。当得到用户的权限后，获取用户权限下的所有linux服务器，以便后续对漏洞进行自动修复。

在一个实施例中，所述获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称之后，还包括：

S013、判断当前时间是否为用户预设的修复时间；

S014、若所述当前时间不是用户预设的修复时间，则获取用户的修复习惯；其中，所述修复习惯包括修复超过第一设定次数的漏洞、修复时间小于第一设定时间的漏洞；

S015、根据所述修复习惯得到对应的漏洞的名称；

S016、若所述当前时间是用户预设的修复时间，则获取所述用户具有权限的服务器的漏洞的名称。

如上述步骤S013-S016所述，在得到登陆用户具有权限的所有linux服务器之后，还需要确定当前是否为用户预设的修复时间(预设的修复时间通常设置为linux服务器不常使用的时间段，根据用户需要具体设置，在此不做限定)，若当前时间不是用户预设的修复时间，则获取用户的修复***台自动获取当前时间登陆用户修复习惯得到对应的linux服务器的漏洞，直接对这些漏洞进行自动修复操作，无需用户进行点击，快速进行修复。若当前时间是用户预设的修复时间，则获取所述用户具有权限的服务器的漏洞的名称，在linux服务器不常使用的时间段对漏洞进行修复，节省用户点击修复耗费的时间和等待的时间。

在一个实施例中，所述获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称之后，还包括：

S021、获取漏洞的历史修复数据，并提取修复超过第二设定次数的漏洞以形成漏洞集合；

S022、获取所述漏洞集合中的所有漏洞的维度；其中，所述维度包括漏洞的类型，以及漏洞所属的服务器；

S023、将出现次数最多维度作为目标维度，并像用户发送选择窗口；

S024、判断用户是否选择所述目标维度；

S025、若否，则接收用户选择的新的修复维度；

S026、获取用户选择的新的修复维度对应的漏洞的名称。

如上述步骤S021-S024所述，获取漏洞的历史修复数据，并提取修复超过第二设定次数的漏洞以形成漏洞集合，漏洞集合中的这些漏洞为经常需要进行修复的漏洞，若每次都需要用户进行点击，会带来不必要的麻烦，因而获取漏洞集合中的漏洞的维度，每个漏洞对应两个维度(对应的linux服务器和漏洞的类型)，将出现次数最多的维度作为目标维度，如漏洞集合中大多数漏洞对应的服务器为1号linux服务器，则1号linux服务器为对应的目标维度，或大多数漏洞的类型为同一类型，则该类型为目标维度。像用户发送选择窗口，若用户选择了新的修复维度，则根据用户选择进行修复，若用户未进行选择，则按照目标维度进行修复。修复维度包括***维度、实例维度和漏洞类型等，选择***维度即对应的是对哪些linux服务器的漏洞进行修复，应理解，Linux服务器的漏洞修复其实就是更新软件包版本，而漏洞修复后如果想恢复回原来的包版本，可以通过回滚任务实现。选择实例维度即对应的是具体选择哪几个漏洞进行修复，选择漏洞类型(组件名例如openssh、bash等)对应的是对哪些类型的漏洞进行修复，用户选择修复维度可以快速的对想要修复的漏洞进行批量修复，无需用户逐一选择进行修复。修复维度不仅包括如上所述的三个维度，还包括其他能够将漏洞分类的维度，在此不做限定。

如上述步骤S025-S026所述，在用户选择新的修复维度之前，还需要判断用户是否对新的修复维度进行选择，可以在选择新的修复维度的窗口设置对应的选择时间，在选择时间内，若用户还没有对新的修复维度进行选择，则表示用户未对新的修复维度进行选择，此时，则获取所有用户具有权限的linux服务器的漏洞，并得到漏洞的CVE号，进而根据漏洞的CVE号在CVE数据库中查找与CVE号对应的组件更新版号，根据组件更新版号在yum数据库中下载对应的组件安装包以对漏洞进行初步修复，并且在预设的依赖数据库中下载与依赖组件对应的依赖组件安装包以对漏洞进行彻底修复。当用户在选择时间内对新的修复维度进行选择，则根据用户选择的新的修复维度对修复维度对应的漏洞进行修复操作。

在一个实施例中，所述根据所述漏洞的名称得到漏洞的CVE号之前，还包括：

S031、获取所述漏洞的修复过程的日志并判断是否具有修复失败的记录；

S032、若不具有修复失败的记录，则判断用户是否选择最小升级版本；

S033、若用户未选择最小升级版本，则根据所述漏洞在yum数据库中下载所述漏洞对应的最新组件安装包，并利用所述最新组件安装包升级所述漏洞对应的组件；其中，所述最新组件安装包为能够将所述漏洞对应的组件升级到最新版本的组件安装包；

S034、若用户选择最小升级版本，则执行所述获取所述修复维度对应的漏洞的CVE号的步骤；

S035、若具有修复失败的记录，则判断是否接收到新的修复文档；

S036、若接收到新的修复文档，则对修复文档中进行分词，得到关键词；

S037、根据所述关键词在所述yum数据库中查找并下载对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件；

S038、若未接收到新的修复文档，则暂停修复并在前端显示所述漏洞以及所述漏洞暂停修复的原因。

如上述步骤S031-S034所述，若漏洞多次修复失败，则需要进行人工处理，而不必一直进行自动修复，会浪费修复时间，同时非常繁琐。因此，在获取所述修复维度对应的漏洞的CVE号的步骤之前，还需要获取所述漏洞的修复过程的日志并判断是否具有修复失败的记录(可以设置具有预设次数的修复失败记录)；当不具有修复失败的记录时，表明该漏洞的修复成功率较高，进而判断用户是否选择最小升级版本，因为在修复漏洞过程中，升级操作版本跨度越大带来的风险也随之升高，因此需要用户进行选择是否升级到最新版本。与选择修复维度相同的是，可以在选择最小升级版本的窗口(用户选择是或者否)设置对应的选择时间，在选择时间内，若用户没有对最小升级版本进行选择，则默认用户选择需要最小升级版本。若在选择时间内，用户选择了否(即不选择最小升级版本)，则在yum数据库中下载与需要修复的漏洞对应的最新组件安装包(最新组件安装包能够将漏洞对应的组件升级到最新版本)，利用最新组件安装包升级需要修复的漏洞对应的组件，完成初步修复；还可以在预设的依赖数据库中下载对应的依赖组件安装包以对漏洞进行彻底修复。若用户在选择时间内未进行选择或用户选择了最小升级版本，则获取所述修复维度对应的漏洞的CVE号，对漏洞对应的组件进行最小升级版本的升级，根据漏洞的CVE号在CVE数据库中查找与CVE号对应的组件更新版号，根据组件更新版号在yum数据库中下载对应的组件安装包以对漏洞进行初步修复，并且在预设的数据库中下载对应的依赖组件安装包以对漏洞进行彻底修复。

如上述步骤S035-S038所述，当修复过程的日志具有修复失败的记录，判断是否接收到新的修复文档(可以设置超过预设次数时判断是否接收到新的修复文档)；当接收到新的修复文档时，对修复文档中进行分词，分词是基于人工只能技术中自然语言处理的分词方法，最终得到关键词，多个关键词中具有组件安装包名称中的部分词语，因而可以根据关键词在所述yum数据库中查找并下载对应的组件安装包，并利用组件安装包升级所述漏洞对应的组件；若未接收到新的修复文档，则暂停修复并在前端显示所述漏洞以及所述漏洞暂停修复的原因，暂停修复的原因包括修复失败次数，未接收到新的修复文档、或接收到新的修复文档但查找不到对应的组件安装包等。

在一个实施例中，所述根据所述漏洞的CVE号在CVE数据库中查找与所述CVE号对应的组件更新版号之前，还包括：

S041、在第一预设时间段内，向用户发送带有更新或不更新的选项的窗口，以便用户进行选择；其中，所述窗口为对所述CVE数据库的操作指令；

S042、判断是否接收到用户选择更新或不更新的指令；

S043、若未接收到用户的指令，则根据红帽官网对所述CVE数据库进行同步更新；

S044、若接收到用户的指令，则判断所述指令为更新或不更新；

S045、若所述指令为更新，则根据红帽官网对所述CVE数据库进行同步更新；

S046、若所述指令为不更新，则停止更新所述CVE数据库。

如上述步骤S041-S046所述，第一预设时间段为每天、每周、或每月的固定时间段。例如，设置第一预设时间段为每天中午12:00-14:00，在此时间段内，判断是否接收到用户对CVE数据库更新的指令，若未接收到，则默认用户选择更新CVE数据库，进而根据红帽官网对所述CVE数据库进行同步更新。若接收到用户的指令，则需要判断该指令为更新还是不更新，若用户选择更新，则根据红帽官网对所述CVE数据库进行同步更新；若用户选择不更新，表示当前时间内，用户可能有其他操作，或正在修复漏洞，不想在此时对CVE数据库进行更新。因此，需要停止更新CVE数据库，等待在下一个第一预设时间段内进行再次判定是否更新。

在一个实施例中，所述根据所述组件更新版号在yum数据库中下载与所述组件更新版号对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件之前，还包括：

S051、在第二预设时间段内，向用户发送带有更新或不更新的选项的窗口，以便用户进行选择；其中，所述窗口为对所述yum数据库的操作指令；

S052、判断是否接收到用户选择更新或不更新的指令；

S053、若未接收到用户的指令，则根据红帽官网对所述yum数据库进行同步更新；

S054、若接收到用户的指令，则判断所述指令为更新或不更新；

S055、若所述指令为更新，则根据红帽官网对所述yum数据库进行同步更新；

S056、若所述指令为不更新，则停止更新所述yum数据库。

如上述步骤S051-S056所述，第二预设时间段为每天、每周、或每月的固定时间段。例如，设置第二预设时间段为每天下午18:00-20:00，在此时间段内，判断是否接收到用户对yum数据库更新的指令，若未接收到，则默认用户选择更新yum数据库，进而根据红帽官网对所述yum数据库进行同步更新。若接收到用户的指令，则需要判断该指令为更新还是不更新，若用户选择更新，则根据红帽官网对所述yum数据库进行同步更新；若用户选择不更新，表示当前时间内，用户可能有其他操作，或正在修复漏洞，不想在此时对yum数据库进行更新。因此，需要停止更新yum数据库，等待在下一个第二预设时间段内进行再次判定是否更新。

在一个实施例中，所述向所述预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用所述依赖组件安装包升级所述依赖组件之后，还包括：

S8、判断所述漏洞是否修复成功；

S9、若所述漏洞修复失败，则将所述漏洞回滚到修复之前的状态并对所述漏洞进行标记；

S10、向所述依赖数据库和yum数据库发送标记修复失败的指令，以对所述漏洞对应的组件安装包和依赖组件安装包进行标记；

S11、当所述漏洞对应的组件安装包和依赖组件安装包被标记超过第三设定次数时，生成对所述组件安装包和依赖组件安装包进行处理的指令，以便用户进行人工处理；

S12、若所述漏洞修复成功，则判断是否接收到所述漏洞对应的服务器发送的应用失败的信号；

S13、若接收到所述漏洞对应的服务器发送的应用失败的信号，则生成是否回滚的指令以供用户选择。

如上述步骤S8-S11所述，当完成漏洞的彻底修复之后，需要判断漏洞是否修复成功，当漏洞修复失败时，漏洞修复平台自动将漏洞回滚到修复之前的状态并对漏洞进行标记，必要时还可以在前端向用户进行展示，以便用户进行后续处理；同时，向依赖数据库和yum数据库发送标记修复失败的指令，以对漏洞对应的组件安装包和依赖组件安装包进行标记，当标记超过了设定次数时，表明该组件安装包和依赖组件安装包多次导致漏洞修复失败，是具有问题的安装包，需要进行删除或更改等操作，因此生成对组件安装包和依赖组件安装包进行处理的指令，以便用户进行人工处理；同时，该标记还可以帮助用户查看数据库中的安装包的总体情况，或在每次下载安装包时，通过标记次数预判该安装包是否会直接导致漏洞修复失败，能够节省修复时间和用户排查时间。当漏洞修复成功时，仅表明漏洞对应的组件升级成功，而漏洞对应的服务器不一定能够应用成功。因此，在漏洞修复成功时，还需要判断是否接收到漏洞对应的服务器发送的应用失败的信号，若接收到，则表示当前漏洞对应的组件升级的版本不能被服务器所应用，生成是否回滚的指令供用户选择，若用户选择回滚，则将漏洞回滚到修复之前的状态；若用户选择不会滚，表示用户可能想要进行其他升级操作，漏洞修复平台不对已修复的漏洞进行回滚。

在一个实施例中，所述若所述漏洞修复失败，则将所述漏洞回滚到修复之前的状态之后，还包括：

S12、记录所述漏洞的修复过程的日志和修复结果；其中，当所述修复结果为修复失败时，所述修复结果还包括失败原因；

S13、将所述修复过程的日志和修复结果与所述漏洞的名称进行关联，并存储在redis数据库中；

S14、在第三预设时间段内，删除所述redis数据库中第二设定时间之前存储的漏洞的名称、以及漏洞的名称对应的修复过程的日志和修复结果。

如上述步骤S12所述，漏洞的修复过程的日志包括漏洞的名称、CVE号、组件更新版号、组件名称、组件安装包、依赖组件名称、依赖组件安装包、最新组件安装包中的多种不同组合，当修复结果为修复失败时，还包括失败原因，例如更新版号查找失败、组件升级失败、依赖组件升级失败等。通过记录漏洞的修复过程的日志和修复结果，用户能够及时查看到漏洞修复过程的日志出现的问题，以便及时解决。

如上述步骤S13-S14所述，将修复过程的日志和修复结果与漏洞的名称关联作，并记录修复的时间，以此作为一条记录存储在redis数据库中，以便redis数据库存储漏洞修复的历史记录，方便用户进行回溯。同时，当有些历史记录存在时间过长后，可能会变为无用的数据，因此，为了防止redis数据库中无用的数据过多，在第三预设时间段内(例如每天凌晨1:00-2:00)，对redis数据库中存储的数据进行删除，在删除时，可以设定删除三天前，或五天前的历史记录，以减少redis数据库的存储量，便于新的数据存入redis数据库。

如图2所示，本申请还提供了一种服务器的漏洞修复装置，包括：

获取模块1，用于获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称；

CVE号模块2，用于根据所述漏洞的名称得到漏洞的CVE号；

第一查找模块3，用于根据所述漏洞的CVE号在CVE数据库中查找与所述CVE号对应的组件更新版号；

第一升级模块4，用于根据所述组件更新版号在yum数据库中下载与所述组件更新版号对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件；

第二查找模块5，用于在预设的依赖数据库中查找与所述组件对应的依赖组件，其中，所述组件为所述漏洞对应的组件；

第二升级模块6，用于向所述预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用所述依赖组件安装包升级所述依赖组件，完成所述漏洞的修复。

在一个实施例中，还包括：

登陆信息获取模块，用于获取用户的登陆信息；

用户权限确定模块，用于根据所述用户的登陆信息确定所述用户的权限，得到所述用户具有权限的所有服务器。

在一个实施例中，还包括：

修复时间判断模块，用于判断当前时间是否为用户预设的修复时间；

指令接收模块，用于在所述当前时间不是用户预设的修复时间时，获取用户的修复习惯；其中，所述修复习惯包括修复超过第一设定次数的漏洞、修复时间小于第一设定时间的漏洞；

名称获取模块，用于根据所述修复习惯得到对应的漏洞的名称；

所有服务器漏洞名称获取模块，用于在所述当前时间是用户预设的修复时间时，获取所述用户具有权限的服务器的漏洞的名称。

在一个实施例中，还包括：

漏洞集合模块，用于获取漏洞的历史修复数据，并提取修复超过第二设定次数的漏洞以形成漏洞集合；

维度模块，用于获取所述漏洞集合中的所有漏洞的维度；其中，所述维度包括漏洞的类型，以及漏洞所属的服务器；

发送模块，用于将出现次数最多维度作为目标维度，并像用户发送选择窗口；

判断模块，用于判断用户是否选择所述目标维度；

漏洞名称获取模块，用于在用户不对修复维度进行选择时，接收用户选择的新的修复维度；

修复维度漏洞名称获取模块，用于获取用户选择的修复维度对应的新的漏洞的名称。

在一个实施例中，还包括：

获取所述漏洞的修复过程的日志并判断是否具有修复失败的记录；

最小升级版本判断模块，用于在不具有修复失败的记录时，判断用户是否选择最小升级版本；

最新下载模块，用于在用户不选择最小升级版本时，根据所述漏洞在yum数据库中下载所述漏洞对应的最新组件安装包，并利用所述最新组件安装包升级所述漏洞对应的组件；其中，所述最新组件安装包为能够将所述漏洞对应的组件升级到最新版本的组件安装包；

执行模块，用于在用户选择最小升级版本时，执行所述获取所述修复维度对应的漏洞的CVE号的步骤；

修复文档模块，用于在具有修复失败的记录时，判断是否接收到新的修复文档；

分词模块，用于在接收到新的修复文档时，对修复文档中进行分词，得到关键词；

查找模块，用于根据所述关键词在所述yum数据库中查找并下载对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件；

暂停模块，用于在未接收到新的修复文档时，暂停修复并在前端显示所述漏洞以及所述漏洞暂停修复的原因。

在一个实施例中，还包括：

CVE数据库更新模块，用于在第一预设时间段内，向用户发送带有更新或不更新的选项的窗口，以便用户进行选择；其中，所述窗口为对所述CVE数据库的操作指令；

第一更新指令模块，用于判断是否接收到用户选择更新或不更新的指令；

第一同步更新模块，用于在未接收到用户的指令时，根据红帽官网对所述CVE数据库进行同步更新；

第一更新或不更新模块，用于在接收到用户的指令时，判断所述指令为更新或不更新；

第二同步更新模块，用于在所述指令为更新时，根据红帽官网对所述CVE数据库进行同步更新；

第一停止更新模块，用于在所述指令为不更新时，停止更新所述CVE数据库。

在一个实施例中，还包括：

yum数据库更新模块，用于在第二预设时间段内，向用户发送带有更新或不更新的选项的窗口，以便用户进行选择；其中，所述窗口为对所述yum数据库的操作指令；

第二更新指令模块，用于判断是否接收到用户选择更新或不更新的指令；

第三同步更新模块，用于在未接收到用户的指令时，根据红帽官网对所述yum数据库进行同步更新；

第二更新或不更新模块，用于在接收到用户的指令时，判断所述指令为更新或不更新；

第四同步更新模块，用于在所述指令为更新时，根据红帽官网对所述yum数据库进行同步更新；

第二停止更新模块，用于在所述指令为不更新时，停止更新所述yum数据库。

在一个实施例中，还包括：

修复成功判断模块，用于判断所述漏洞是否修复成功并对所述漏洞进行标记；

标记指令模块，用于向所述依赖数据库和yum数据库发送标记修复失败的指令，以对所述漏洞对应的组件安装包和依赖组件安装包进行标记；

人工处理模块，用于当所述漏洞对应的组件安装包和依赖组件安装包被标记超过第三设定次数时，生成对所述组件安装包和依赖组件安装包进行处理的指令，以便用户进行人工处理；

回滚模块，用于在所述漏洞修复失败时，将所述漏洞回滚到修复之前的状态；

信号接收模块，用于在所述漏洞修复成功时，判断是否接收到所述漏洞对应的服务器发送的应用失败的信号；

回滚选择模块，用于在接收到所述漏洞对应的服务器发送的应用失败的信号时，生成是否回滚的指令以供用户选择。

在一个实施例中，还包括：

记录模块，用于记录所述漏洞的修复过程的日志和修复结果；其中，当所述修复结果为修复失败时，所述修复结果还包括失败原因；

关联模块，用于将所述修复过程的日志和修复结果与所述漏洞的名称进行关联，并存储在redis数据库中；

删除模块，用于在第三预设时间段内，删除所述redis数据库中第二设定时间之前存储的漏洞的名称、以及漏洞的名称对应的修复过程的日志和修复结果。

上述各单元、模块均是用于对应执行上述服务器的漏洞修复方法中的各个步骤，其具体实现方式参照上述方法实施例所述，在此不再进行赘述。

如图3所示，本申请还提供了一种计算机设备，该计算机设备可以是服务器，其内部结构可以如图3所示。该计算机设备包括通过***总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设计的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作***、计算机程序和数据库。该内存器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的数据库用于存储服务器的漏洞修复方法的过程需要的所有数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现服务器的漏洞修复方法。

本领域技术人员可以理解，图3中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定。

本申请一实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意一个服务器的漏洞修复方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储与一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的和实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可以包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM通过多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双速据率SDRAM(SSRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。

以上所述仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (8)

1.一种服务器的漏洞修复方法，其特征在于，包括：

获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称；

根据所述漏洞的名称得到漏洞的CVE号；

根据所述漏洞的CVE号在CVE数据库中查找与所述CVE号对应的组件更新版号；

根据所述组件更新版号在yum数据库中下载与所述组件更新版号对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件；

在预设的依赖数据库中查找与所述组件对应的依赖组件，其中，所述组件为所述漏洞对应的组件；

向所述预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用所述依赖组件安装包升级所述依赖组件，完成所述漏洞的修复；

其中，在所述依赖数据库中存储与yum数据库的组件安装包对应的依赖组件名称，以及对应的依赖组件的安装包，所述安装包为组件漏洞需要额外升级的非强依赖组件；

所述获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称之后，还包括：

获取漏洞的历史修复数据，并提取修复超过第二设定次数的漏洞以形成漏洞集合；

获取所述漏洞集合中的所有漏洞的维度；其中，所述维度包括漏洞的类型，以及漏洞所属的服务器；

将出现次数最多维度作为目标维度，并像用户发送选择窗口；

判断用户是否选择所述目标维度；

若否，则接收用户选择的新的修复维度；

获取用户选择的新的修复维度对应的漏洞的名称。

2.根据权利要求1所述的服务器的漏洞修复方法，其特征在于，所述获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称之后，还包括：

判断当前时间是否为用户预设的修复时间；

若所述当前时间不是用户预设的修复时间，则获取用户的修复习惯；其中，所述修复习惯包括修复超过第一设定次数的漏洞、修复时间小于第一设定时间的漏洞；

根据所述修复习惯得到对应的漏洞的名称；

若所述当前时间是用户预设的修复时间，则获取所述用户具有权限的服务器的漏洞的名称。

3.根据权利要求1所述的服务器的漏洞修复方法，其特征在于，所述根据所述漏洞的CVE号在CVE数据库中查找与所述CVE号对应的组件更新版号之前，还包括：

在第一预设时间段内，向用户发送带有更新或不更新的选项的窗口，以便用户进行选择；其中，所述窗口为对所述CVE数据库的操作指令；

判断是否接收到用户选择更新或不更新的指令；

若未接收到用户的指令，则根据红帽官网对所述CVE数据库进行同步更新；

若接收到用户的指令，则判断所述指令为更新或不更新；

若所述指令为更新，则根据红帽官网对所述CVE数据库进行同步更新；

若所述指令为不更新，则停止更新所述CVE数据库。

4.根据权利要求1所述的服务器的漏洞修复方法，其特征在于，所述向所述预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用所述依赖组件安装包升级所述依赖组件之后，还包括：

判断所述漏洞是否修复成功；

若所述漏洞修复失败，则将所述漏洞回滚到修复之前的状态并对所述漏洞进行标记；

向所述依赖数据库和yum数据库发送标记修复失败的指令，以对所述漏洞对应的组件安装包和依赖组件安装包进行标记；

当所述漏洞对应的组件安装包和依赖组件安装包被标记超过第三设定次数时，生成对所述组件安装包和依赖组件安装包进行处理的指令，以便用户进行人工处理；

若所述漏洞修复成功，则判断是否接收到所述漏洞对应的服务器发送的应用失败的信号；

若接收到所述漏洞对应的服务器发送的应用失败的信号，则生成是否回滚的指令以供用户选择。

5.根据权利要求4所述的服务器的漏洞修复方法，其特征在于，所述若所述漏洞修复失败，则将所述漏洞回滚到修复之前的状态之后，还包括：

记录所述漏洞的修复过程的日志和修复结果；其中，当所述修复结果为修复失败时，所述修复结果还包括失败原因；

将所述修复过程的日志和修复结果与所述漏洞的名称进行关联，并存储在redis数据库中；

在第三预设时间段内，删除所述redis数据库中第二设定时间之前存储的漏洞的名称、以及漏洞的名称对应的修复过程的日志和修复结果。

6.一种服务器的漏洞修复装置，其特征在于，包括：

获取模块，用于获取各服务器的安全漏洞信息，并基于所述安全漏洞信息进行语义分析/语法分析得到各服务器需要修复的漏洞的名称；

CVE号模块，用于根据所述漏洞的名称得到漏洞的CVE号；

第一查找模块，用于根据所述漏洞的CVE号在CVE数据库中查找与所述CVE号对应的组件更新版号；

第一升级模块，用于根据所述组件更新版号在yum数据库中下载与所述组件更新版号对应的组件安装包，并利用所述组件安装包升级所述漏洞对应的组件；

第二查找模块，用于在预设的依赖数据库中查找与所述组件对应的依赖组件，其中，所述组件为所述漏洞对应的组件；

第二升级模块，用于向所述预设的依赖数据库发送下载请求以下载依赖组件安装包，并利用所述依赖组件安装包升级所述依赖组件，完成所述漏洞的修复；

其中，在所述依赖数据库中存储与yum数据库的组件安装包对应的依赖组件名称，以及对应的依赖组件的安装包，所述安装包为组件漏洞需要额外升级的非强依赖组件；

漏洞集合模块，用于获取漏洞的历史修复数据，并提取修复超过第二设定次数的漏洞以形成漏洞集合；

维度模块，用于获取所述漏洞集合中的所有漏洞的维度；其中，所述维度包括漏洞的类型，以及漏洞所属的服务器；

发送模块，用于将出现次数最多维度作为目标维度，并像用户发送选择窗口；

判断模块，用于判断用户是否选择所述目标维度；

漏洞名称获取模块，用于在用户不对修复维度进行选择时，接收用户选择的新的修复维度；

修复维度漏洞名称获取模块，用于获取用户选择的修复维度对应的新的漏洞的名称。

7.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至5中任一项所述方法的步骤。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至5中任一项所述的方法的步骤。