CN111859399A - 一种基于oval的漏洞检测方法及装置 - Google Patents

Abstract

本发明实施例提供一种基于oval的漏洞检测方法及装置，该方法包括：采集客户端已安装的软件的软件信息；根据所述软件信息确定软件的基本属性，所述基本属性包括：客户端的操作系统版本、操作系统架构、软件的名称和软件的版本；根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞，其中，预定义的所述检测规则包括从补丁定义库提取得到的软件的基本属性与漏洞的对应关系。采用上述方法，可降低客户端的运行压力，增加可检测到的漏洞数量，加快了漏洞检测的速度。

Description

一种基于oval的漏洞检测方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种基于oval的漏洞检测方法及装置。

背景技术

随着互联网的发展，互联网中的信息安全问题也日益突出。其中，通过利用计算机中已安装组件的漏洞，进行网络攻击已成为不法分子谋取私利的重要手段。相应的，为了及时修复漏洞，通常需要利用漏洞检测工具进行扫描，从而发现计算机中存在的漏洞。

现有技术中，MITRE的Oval(开放式漏洞评估语言)以其更新速度快、准确率高、后台信息库全面的优势，逐渐在漏洞检测领域崭露头角。其基于oval的漏洞检测，一般是客户端定时从oval服务器下载oval定义(漏洞定义文件)，在本地解析oval定义，获得组件特征对应的漏洞，进一步对应组件进行检测，最后上报检测结果至服务器。然而，该方法具备较大的局限性，一是oval定义数据库中oval定义中的漏洞较少，且更新较慢。二是该方法要求每个客户端需要具备解析oval定义、提取本地组件特征、根据解析后的oval定义检测本地组件特征并形成检测结果报告的能力。三是大量客户端定时从oval服务器中下载oval定义和上报检测结果将给oval服务器和告警服务器带来较大的连接压力。

因此，现在亟需一种基于oval的漏洞检测方法及装置，用于增加可检测到的漏洞数量，加快漏洞检测速度。

发明内容

本发明实施例提供一种基于oval的漏洞检测方法及装置，用于增加可检测到的漏洞数量，加快漏洞检测速度。

第一方面，本发明实施例提供一种基于oval的漏洞检测方法，该方法包括：

采集客户端已安装的软件的软件信息；根据所述软件信息确定软件的基本属性，所述基本属性包括：客户端的操作系统版本、操作系统架构、软件的名称和软件的版本；根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞，其中，预定义的所述检测规则包括从补丁定义库提取得到的软件的基本属性与漏洞的对应关系。

采用上述方法，通过从补丁定义库中获取定义文件，进而确定至少包括软件的基本属性和漏洞的检测规则。相比于现有技术中在漏洞定义库中获取定义文件，由于漏洞定义库中的定义文件中记录的软件数量、软件种类以及软件对应的漏洞数量都低于补丁定义库，且更新速度慢；本申请从补丁定义库中获取定义文件，可以获得的软件数量、软件种类以及软件对应的漏洞数量要更大更全面，且更新速度更快，因此，使得检测规则中的可检测的漏洞数量更多，更全面。进一步，在检测服务器接收客户端的软件信息后，检测服务器根据软件信息中的各软件的基本属性和检测规则，确定该各软件中存在漏洞的软件。相比于现有技术中在客户端获取定义文件生成检测规则，并对各软件进行漏洞检测来说，本申请通过设置检测服务器获取定义文件，并检测漏洞，实现远程漏洞检测，降低客户端运行压力，减少了对客户端本地服务的影响，加快了漏洞检测的速度。

在一种可能的设计中，预定义的所述检测规则包括第一存储区的检测规则和第二存储的检测规则，根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞,包括：根据所述软件的基本属性从所述第一存储区的检测规则中确定出所述软件对应的漏洞；若从所述第一存储区的检测规则中未确定出所述软件对应的漏洞，则从所述第二存储区的检测规则中确定出所述软件对应的漏洞，并将所述软件的基本属性和所述软件的对应的漏洞的对应关系写入所述第一存储区。

采用上述方法，在检测服务器中设置第一存储区和第二存储区，其中第一存储区的检测规则中存储的是，通过第二存储区的检测规则对待测的软件进行检测后确定出漏洞结果的检测规则。因而，第一存储区的检测规则中存储的软件的基本属性对应漏洞的对应关系的条数远远少于第二存储区的检测规则中存储的检测规则。当对一个软件进行检测时，首先确定第一存储区中是否包含该软件的基本属性和对应漏洞。如此，若第一存储区中刚好存储有该软件的基本属性与该软件的漏洞的对应关系，则可以直接确定该软件对应的漏洞，完成检测，遍历对应关系少，无需在第二存储区中查找比对大量的软件的基本属性与软件的漏洞的对应关系，加快了检测的速度。其中，当第一存储区的检测规则涉及的软件是检测频率高的软件时；对检测频率高的待检测的软件的软件信息进行检测，因为第一存储区已经存储该软件的检测规则，则每次检测都可以直接通过第一存储区的检测规则进行检测，无需多次遍历第二存储区的检测规则。因而，通过设置第一存储区可以有效加快检测。如，由于一个机构中使用软件基本相同，对应软件的漏洞根据第二存储区确定一次后，则将该软件的基本属性和对应漏洞的对应关系存储在第一存储区，该机构中多个相同的基本属性的软件可以在第一存储区中多次获得第一存储区的该基本属性软件和漏洞的对应关系，极大地加快了检测的速度。

在一种可能的设计中，所述补丁定义库中包括各定义文件，所述定义文件至少包括各软件的基本属性、各软件对应的补丁以及各软件对应的漏洞；所述方法还包括：确定所述补丁定义库中的定义文件发生变化，则将所述定义文件加载至检测服务器中，并从所述定义文件中提取得到的软件的基本属性与漏洞的对应关系。

采用上述方法，检测服务器从补丁定义库中获取各定义文件，各定义文件中包括各软件的基本属性、各软件对应的补丁以及各软件对应的漏洞，并根据该定义文件生成各软件的基本属性和各软件对应的漏洞的对应关系做检测规则。当定义文件发生变化，检测服务器将变化后的定义文件加载并解析，通过增量更新的方式对检测规则进行更新。保证检测规则的时效性，提高漏洞检测的准确性。

在一种可能的设计中，从所述定义文件中提取得到的软件的基本属性与漏洞的对应关系，包括：解析所述定义文件，得到所述定义文件中的各软件的临时定义规则，所述临时定义规则至少包括软件的基本属性、软件的补丁以及软件的漏洞的对应关系；根据各软件的临时定义规则得到所述定义文件中的各软件的定义规则；所述定义规则至少包括软件的基本属性与软件的漏洞的对应关系；根据所述定义规则更新所述检测规则。

采用上述方法，检测服务器加载定义文件，并对其解析，以获取至少包含软件的基本属性、软件的补丁以及软件的漏洞的对应关系的临时定义规则；进一步得到定义规则，以获取定义文件中各软件的基本属性与对应软件的漏洞的对应关系。最后，根据定义规则以增量更新的方式对检测规则进行更新。保证检测规则的时效性，提高漏洞检测的准确性。

在一种可能的设计中，根据所述定义规则更新所述检测规则，包括：根据所述定义规则更新所述第二存储区中的检测规则，并记录更新的软件的基本属性；根据更新的软件的基本属性，更新所述第一存储区中的检测规则。

采用上述方法，检测服务器在更新检测规则时，对第二存储区的检测规则更新；若第二存储区中发生更新的检测规则所对应的软件，同时存储在第一存储区的中，则需要将第一存储区的该软件对应的检测规则更新。防止由于第一存储区的检测规则未更新，造成检测服务器检测不出该软件对应更新后的检测规则中包含的漏洞；或者，造成检测服务器检测出的该软件的漏洞，为已经修复的漏洞，而降低检测结果准确性的问题。如此，保证漏洞检测的准确性。

在一种可能的设计中，解析所述定义文件，得到所述定义文件中的各软件的临时定义规则，包括：解析所述定义文件，得到所述定义文件中的各软件的漏洞影响值，并生成漏洞影响值大于设定阈值的各软件的临时定义规则；根据各软件的临时定义规则得到所述定义文件中的各软件的定义规则，包括：根据各软件的临时定义规则，得到所述定义文件中漏洞影响值大于设定阈值的各软件的定义规则。

采用上述方法，检测服务器解析获取的定义文件，得到定义文件中的各软件的漏洞影响值，若定义文件中的软件的漏洞影响值小于设定阈值，则检测服务器不予记录。相比于现有技术中只要是oval定义的漏洞都会进行检测、上报，本申请可以过滤掉影响值小，不易被恶意攻击者利用的漏洞。只记录漏洞影响值大于设定阈值的各软件的定义规则。可以加快漏洞检测速度，相应的，减少客户端不必要的警告，增加漏洞检测的效率。

在一种可能的设计中，采集客户端已安装的软件的软件信息，包括：接收客户端已安装的软件的第一软件信息，所述第一软件信息中包括监听端口开启的软件的软件信息和监听端口未开启的软件的软件信息。

采用上述方法，检测服务器接收采集到的第一软件信息，进而通过第一软件信息对软件的漏洞情况进行检测，若该软件存在漏洞则产生报警，增加该软件应用的安全性。

在一种可能的设计中，根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞之后，还包括：根据所述软件对应的漏洞生成第一预警信息，所述第一预警信息为监听端口开启的软件的软件信息和监听端口未开启的软件的预警信息。

采用上述方法，检测服务器根据第一软件信息中的软件基本属性，从检测规则中确定软件对应的漏洞后，生成第一预警信息。如此，可以通过第一预警信息告知用户对该软件进行拦截或修补漏洞，增加软件应用的安全性。

在一种可能的设计中，接收客户端已安装的软件的第二软件信息，所述第二软件信息为监听端口开启的软件的软件信息；根据所述第二软件信息确定监听端口开启的软件以及所述软件对应的漏洞，并生成第二预警信息，所述第二预警信息为监听端口开启的软件的预警信息。

采用上述方法，检测服务器还接收第二软件信息，检测服务器接收第二软件信息的周期小于检测服务器接收第一软件信息的周期。如此，可以对动态的第二软件信息，即客户端已安装的各软件的监听端口开启的软件信息进行监控，增加信息获取的准确性。进一步，若软件的监听端口状态为开启状态，则该软件对应的漏洞危害较大，检测服务器针对开启监听端口的软件生成第二预警信息，使得网页端接收该第二预警信息后，将该第二预警信息优先预警。如此，增加漏洞检测预警的时效性。

在一种可能的设计中，通过Kafka集群接收客户端已安装的软件的所述第一软件信息和所述第二软件信息；根据所述第一软件信息和所述第二软件信息对应生成所述第一预警信息和所述第二预警信息，并将所述第一预警信息和所述第二预警信息发送至所述Kafka集群，以使所述网页端从所述Kafka集群获取所述第一预警信息和所述第二预警信息，所述网页端用于将所述第二预警信息优先展示。

采用上述方法，通过Kafka集群可以对第一软件信息和第二软件信息进行管理；Kafka集群可以在接收以及缓存第一软件信息和第二软件信息的同时，向检测服务器发送第一软件信息和第二软件信息；或者，允许检测服务器从Kafka集群获取第一软件信息和第二软件信息。实现检测服务器边消费，Kafka集群边接收，可以分担客户端和检测服务器的处理压力。还可以通过Kafka集群对检测服务器上传的第一预警信息和第二预警信息进行管理；Kafka集群可以在管理第一软件信息和第二软件信息的同时，接收检测服务器上传的第一预警信息和第二预警信息，并等待网页端获取第一预警信息和第二预警信息；进一步分担检测服务器的处理压力。以此，加快检测服务器进行漏洞检测的灵活性和时效性。

第二方面，本发明实施例还提供一种计算设备，包括：存储器，用于存储计算机程序；处理器，用于调用所述存储器中存储的计算机程序，按照获得的程序执行如第一方面的各种可能的设计中所述的方法。

第三方面，本发明实施例还提供一种计算机可读非易失性存储介质，包括计算机可读程序，当计算机读取并执行所述计算机可读程序时，使得计算机执行如第一方面的各种可能的设计中所述的方法。

本发明的这些实现方式或其他实现方式在以下实施例的描述中会更加简明易懂。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种基于oval的漏洞检测方法的架构示意图；

图2为本发明实施例提供的一种基于oval的漏洞检测方法的流程示意图；

图3为本发明实施例提供的一种基于oval的漏洞检测方法的流程示意图；

图4为本发明实施例提供的一种基于oval的漏洞检测装置示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

如图1所示，本发明实施例提供的一种基于oval的漏洞检测方法的架构示意图；其中Kafka集群102中包含至少一个Kafka服务器101。检测服务器集群104中包含至少一个检测服务器103。各客户端106中包含至少一个客户端105。检测服务器103从补丁定义库108中获取定义文件，生成检测规则，并按时更新。客户端105中的代理程序等按周期上报软件信息至Kafka集群102，Kafka集群102接收软件信息，并将该软件信息分发至各检测服务器103，检测服务器103根据本地的检测规则，对该软件信息中的各软件进行漏洞检测，确定检测规则中存在该软件信息中软件的基本属性对应软件的漏洞的对应关系，则生成该软件的预警信息，发送至Kafka集群102。网页端107从Kafka集群102拉取该软件的预警信息并展示，由网页端107将该软件的预警信息依次发送至对应的客户端105，以对运维人员进行提示。这里，提示的方式可以是邮件提醒或者qq、微信推送信息等，具体不做限定。

基于此，本申请实施例提供了一种基于oval的漏洞检测方法的流程，如图2所示，该漏洞检测方法可以由图1中的检测服务器执行，包括：

步骤201、采集客户端已安装的软件的软件信息；

在一实施例中，可以在客户端安装负责软件信息采集的代理程序，代理程序通过软件包管理器，例如，RPM软件包管理器或DEB软件包管理器等提供的一些命令和记录，搜集在该操作系统(例如linux系统)中已安装的各软件、各组件等的软件信息。软件信息可以包括多个软件的基本属性，基本属性包括：软件所在的操作系统版本、操作系统架构、软件的包名、软件的版本(包括epoch(纪元)、version(版本)、release(候选版本))等信息。例如，基本属性vim-common,2:7.2.4.160-1.el7.x86_64,表示软件所在的操作系统版本为centos6，操作系统架构为x86_64、软件的包名为vim-common,软件的版本为vim-common的2:7.2.4160-1.el7版本。检测服务器可以开启相应的检测线程，还可以监控自身是否与Kafka集群成功连接，以及自身内存使用率，若与Kafka集群连接失败或内存使用超过限定值，则会退出当前进程，并重新开启进程，实现对进程的保护，保证检测服务器的正常运行。

步骤202、根据所述软件信息确定软件的基本属性，所述基本属性包括：客户端的操作系统版本、操作系统架构、软件的名称和软件的版本；

此处，客户端安装的操作系统版本，例如，centos6，centos7，操作系统架构，如，X86、X86_64，软件的名称，例如，bind-utils、vim-common、Java-1.7.0-openjdk等，软件的版本，例如，bind-utils的32：9.9.4-29.el7版本；vim-common的2:7.2.4160-1.el7版本；Java-1.7.0-openjdk的1：1.7.0.91-2.6.2.3.el7版本等。

步骤203、根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞，其中，预定义的所述检测规则包括从补丁定义库提取得到的软件的基本属性与漏洞的对应关系。

此处，预定义的检测规则中至少包括软件的基本属性与软件的漏洞的对应关系，例如，所在操作系统版本：centos6、操作系统架构：x86_64、软件名称也即rpm包名：vim-common、软件的版本vim-common的2:7.2.4160-1.el7版本，以上这些信息对应的软件会出现XX配置漏洞和XX逻辑漏洞等。

检测服务器接收到软件信息后，根据软件信息中的各软件的基本属性确定对应漏洞，如，获取软件信息中的某一软件的基本属性：vim-common,2:7.2.4160-1.el7.x86_64，确定该软件基本信息对应XX配置漏洞和XX逻辑漏洞。补丁定义库中至少存储多个软件基本信息和该多个软件基本信息对应的多个补丁和多个漏洞。由此，可以根据补丁定义库获取检测规则，即软件的基本属性与软件的漏洞的对应关系。

采用上述方法，通过从补丁定义库中获取定义文件，进而确定至少包括软件的基本属性和漏洞的检测规则。相比于现有技术中在漏洞定义库中获取定义文件，由于漏洞定义库中的定义文件中记录的软件数量、软件种类以及软件对应的漏洞数量都低于补丁定义库，且更新速度慢；而从补丁定义库中获取定义文件，可以获得的软件数量、软件种类以及软件对应的漏洞数量要更大更全面，且更新速度更快，因此，使得检测规则中的可检测的漏洞数量更多，更全面。进一步，在检测服务器接收客户端的软件信息后，检测服务器根据软件信息中的各软件的基本属性和检测规则，确定该各软件中存在漏洞的软件。相比于现有技术中在客户端获取定义文件生成检测规则，并对各软件进行漏洞检测来说，本申请通过设置检测服务器获取定义文件，并检测漏洞，实现远程漏洞检测，降低客户端运行压力，减少了对客户端本地服务的影响，加快了漏洞检测的速度。

本申请实施例提供了一种基于oval的漏洞检测方法，预定义的所述检测规则包括第一存储区的检测规则和第二存储的检测规则，根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞,包括：根据所述软件的基本属性从所述第一存储区的检测规则中确定出所述软件对应的漏洞；若从所述第一存储区的检测规则中未确定出所述软件对应的漏洞，则从所述第二存储区的检测规则中确定出所述软件对应的漏洞，并将所述软件的基本属性和所述软件的对应的漏洞的对应关系写入所述第一存储区。

此处，第二存储区的检测规则至少包括：操作系统架构：微处理器执行的计算机语言指令集，例如，X86架构(The X86 architecture)、x86-64(又称x64，64-bit extended，是x86架构的64位拓展)等。操作系统版本：centos6、centos7。软件名称：libldb-devel，操作系统版本：centos6,该软件操作符：pattern match,该软件的操作系统版本：i686\ppc\ppc64\s390\s390x\x86-64,该软件对应的版本区间：less then:0:1.1.13-3.el6-7.1,该软件对应的漏洞：CVE-2015-3223cvss2(5.0/AV:N/AC:L/Au:N/C:N/I:N/A:P)moderate、CVE-2015-5330cvss2(3.5/AV:N/AC:M/Au:S/C:P/I:N/A:N)moderate。软件名称：libldb，操作系统版本：centos6,该软件操作符：pattern match,该软件的操作系统版本：i686\ppc\ppc64\s390\s390x\x86-64,该软件对应的版本区间：less then:0:1.1.13-3.el6-7.1,该软件对应的漏洞：CVE-2015-3223cvss2(5.0/AV:N/AC:L/Au:N/C:N/I:N/A:P)moderate、CVE-2015-5330cvss2(3.5/AV:N/AC:M/Au:S/C:P/I:N/A:N)moderate。软件名称：rpcbind，操作系统版本：centos6,该软件操作符：pattern match,该软件的操作系统版本：i686\ppc64\s390x\x86-64,该软件对应的版本区间：less then:0:0.2.8-11.el6-7,该软件对应的漏洞：CVE-2015-7236cvss2(4.3/AV:N/AC:M/Au:N/C:N/I:N/A:P)moderate。软件名称：lemon，操作系统版本：centos6,该软件操作符：pattern match,该软件的操作系统版本：i686\ppc64\s390x\x86-64,该软件对应的版本区间：less then:0:0.3.6.20-1.el6-7.2,该软件对应的漏洞：CVE-2015-3416cvss2(3.7/AV:L/AC:H/Au:N/C:P/I:P/A:P)moderate。软件名称：sqlite，操作系统版本：centos6,该软件操作符：pattern match,该软件的操作系统版本：i686\ppc\ppc64\s390\s390x\x86-64,该软件对应的版本区间：less then:0:3.6.20-1.el6-7.2,该软件对应的漏洞：CVE-2015-3416cvss2(3.7/AV:L/AC:H/Au:N/C:P/I:P/A:P)moderate。如下表所示：

表1

第一存储区的检测规则可以包括：软件名称：sqlite，操作系统版本：centos6,该软件操作符：pattern match,该软件的操作系统版本：i686\ppc\ppc64\s390\s390x\x86-64,该软件对应的版本：0:3.6.20-1.el6-7.2,该软件对应的漏洞：CVE-2015-3416cvss2(3.7/AV:L/AC:H/Au:N/C:P/I:P/A:P)moderate。如下表所示：

表2

第一存储区的检测规则为检测服务器对软件信息检测后确定的软件信息中的软件的基本属性与漏洞的对应关系。如此，当检测服务器又获取某一个软件信息中的软件的基本属性后，先在第一存储区的检测规则为该软件信息中的软件的基本属性对比检测，若第一存储区的检测规则中没有该软件信息中的软件的基本属性对应的信息，即，包括软件的基本属性和漏洞信息；则检测服务器将通过第二存储区的检测规则为该软件信息中的软件的基本属性进行对比检测。若在第一存储区的检测规则存在该软件信息中的软件的基本属性对应的信息，则可以直接判定该软件信息中的软件的基本属性对应的漏洞。因为第二存储区的检测规则中存储的是直接从补丁定义库提取得到的软件的基本属性与漏洞的对应关系的检测规则，属于规则缓存，例如包含多个软件名称以及版本区间、操作系统版本、架构的多条信息。而第一存储区的检测规则中存储的是经过检测服务器对比检验之后的检测规则，属于结果缓存，例如包含软件名称以及版本区间、操作系统版本、架构的一条信息，是软件信息在经过第二存储区的检测规则检测后的检测结果。如此，先在第一存储区的检测规则中检测，减少根据软件信息在第二存储区的检测规则遍历对应检测规则的时间，加快了检测速度。且由于对于同一个企业来说，或者同一类企业来说，该企业的客户端中所安装的操作系统版本、架构、软件名称、软件版本等，差别较小以至于几乎相同，因此，在对软件信息检测后，并将检测结果存储到第一存储区的检测规则中，后续对该企业的各客户端上报的软件信息进行检测时，极可能通过第一存储区的检测规则中的检测结果即可得出软件信息对应的漏洞，由此，加快检测速度的效果是极其明显的。

本申请实施例提供了一种定义文件获取方法，所述补丁定义库中包括各定义文件，所述定义文件至少包括各软件的基本属性、各软件对应的补丁以及各软件对应的漏洞；所述方法还包括：确定所述补丁定义库中的定义文件发生变化，则将所述定义文件加载至检测服务器中，并从所述定义文件中提取得到的软件的基本属性与漏洞的对应关系。

此处，定义文件可以为每种操作系统版本对应一个定义文件，或者每版本操作系统版本对应一个定义文件，又或者每种系统架构对应一个定义文件，这里对定义文件的具体形式不做限定。下面以每种操作系统版本的每个版本对应一个定义文件为例。则每个定义文件中包含在该操作系统的该版本下，对应的各种软件的各版本对应存在的补丁以及漏洞。检测服务器会定期从补丁定义库获取每个定义文件，确定每种操作系统的每个版本的定义文件是否发生变化。这里可以通过计算定义文件的哈希值或MD5值等方法确定定义文件内容是否发生更新，若有定义文件产生更新，则将该定义文件加载并解析，即，从加载的定义文件中提取得到的软件的基本属性与漏洞的对应关系。

本申请实施例提供了一种定义文件解析方法，从所述定义文件中提取得到的软件的基本属性与漏洞的对应关系，包括：解析所述定义文件，得到所述定义文件中的各软件的临时定义规则，所述临时定义规则至少包括软件的基本属性、软件的补丁以及软件的漏洞的对应关系；根据各软件的临时定义规则得到所述定义文件中的各软件的定义规则；所述定义规则至少包括软件的基本属性与软件的漏洞的对应关系；根据所述定义规则更新所述检测规则。

此处，检测服务器将产生更新的定义文件加载后，解析该定义文件。因为定义可以是由许多标签构成，其中每个definition、test、object、state标签都有唯一id标识，并可通过id建立各对象间的对应关系。

如，解析时逐行遍历定义文件，提取出definition(定义)、platform(操作系统名称和版本)、severity(漏洞影响值)、cve(包括impact、CVE-ID、cvss等漏洞)、criterion(标准)、test(检测)、object(软件名称)、state(软件版本)标签内容，并存储于定义的相对应的definition、test、object、state等结构体中。

首先确定定义文件对应的platform，进一步，通过定义文件中definition结构体中criterion中的test id，查找到对应的test结构体，再进一步，根据test结构体中的object id和state id查找到对应的object结构体和state结构体，如此，获得了软件的名称和版本等基本属性,则可以根据软件的基本属性确定对应的补丁以及漏洞。通常对定义文件进行解析得到各软件的临时定义规则，具体包括某个补丁--多个CVE漏洞--多个test测试项(每个测试项是一个软件rpm包的属性信息)，进一步的，对该临时定义规则进行test测试项的提取、合并，得到某个软件rpm包对应哪些漏洞，例如某个test测试项(某个软件rpm包的属性信息)--多个CVE漏洞，也即得到该软件的名称和版本等基本属性对应的漏洞。上述过程中definition结构体中criterion为空，则代表该定义文件为空。则可以去除该definition。若存在object和state没有对应的漏洞，则去除该object和state。

本申请实施例提供了一种检测规则更新方法，所述检测服务器根据所述定义规则更新所述检测规则，包括：所述检测服务器根据所述定义规则更新所述第二存储区中的检测规则，并记录更新的软件的基本属性；所述检测服务器根据更新的软件的基本属性，更新所述第一存储区中的检测规则。

此处，定义规则至少包括更新的定义规则的内容。当定义文件产生更新后，检测服务器根据定义规则通过增量更新的方式对检测规则进行更新。其中，对检测规则进行更新时，不止对第二存储区中的检测规则进行更新，还需要对第一存储区中的检测规则进行更新。防止第二存储区中的检测规则更新，而第一存储区中的检测规则不更新，以至于下次检测服务器接收第一软件信息后，直接通过第一存储区中的检测规则中未更新的、不准确的定义规则对该第一软件信息进行检测，得到不准确的检测结果。

本申请实施例提供了一种检测规则更新方法，解析所述定义文件，得到所述定义文件中的各软件的临时定义规则，包括：解析所述定义文件，得到所述定义文件中的各软件的漏洞影响值，并生成漏洞影响值大于设定阈值的各软件的临时定义规则；根据各软件的临时定义规则得到所述定义文件中的各软件的定义规则，包括：根据各软件的临时定义规则，得到所述定义文件中漏洞影响值大于设定阈值的各软件的定义规则。

此处，在上述对定义文件的解析过程中，解析出来的定义文件中的原始的文件内容包括软件的基本属性对应的补丁以及漏洞，因此，预先生成一个包含软件与补丁和漏洞的对应关系的临时定义规则，进一步，将临时定义规则中的软件和补丁的对应关系删除，获取软件与漏洞的对应关系。且因为从补丁定义库中获取的定义文件中不止包含补丁定义文件，还可能包含其它信息，因此，要去除非补丁类型的definition，另外，要将漏洞影响值小于设定阈值的漏洞删除，不予检测。因为小于设定阈值的漏洞对客户端不会造成大的安全威胁，若是对该种漏洞也进行检测，并产生预警信息，会产生大量的预警信息，增加客户端的压力，并降低用户的体验感。这里，可以在预先生成临时定义规则时根据漏洞影响值筛选要记录的临时定义规则，也可以在预先生成临时定义规则时不对临时定义规则筛选，而在生成定义规则时根据漏洞影响值筛选要记录的定义规则。

本申请实施例提供了一种基于oval的漏洞检测方法，采集客户端已安装的软件的软件信息，包括：接收客户端已安装的软件的第一软件信息，所述第一软件信息中包括监听端口开启的软件的软件信息和监听端口未开启的软件的软件信息。

也就是说，检测服务器获取客户端已安装的第一软件信息，如此，可以根据第一软件信息中的软件的基本属性和相关的信息，以及检测服务器中的第一存储区的检测规则和第二存储区的检测规则，就可以确定该软件的漏洞，如此，以便后续对该软件进行相应的预警处理等，增加软件应用的安全性。

本申请实施例提供了一种基于oval的漏洞检测方法，根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞之后，还包括：根据所述软件对应的漏洞生成第一预警信息，所述第一预警信息为监听端口开启的软件的软件信息和监听端口未开启的软件的预警信息。此处，当检测服务器根据第一软件信息中的软件的基本属性，以及检测服务器中的预定义的检测规则确定软件对应的漏洞后，可以生成第一预警信息，如此，对该软件的漏洞预警，可以增加软件应用的安全性。

本申请实施例提供了一种检测规则更新方法，还包括：接收客户端已安装的软件的第二软件信息，所述第二软件信息为监听端口开启的软件的软件信息；根据所述第二软件信息确定监听端口开启的软件以及所述软件对应的漏洞，并生成第二预警信息，所述第二预警信息为监听端口开启的软件的预警信息。

也就是说，检测服务器接收监听端口开启和监听端口不开启的第一软件信息，并根据该第一软件信息对软件的漏洞进行检测。但由于监听端口的开启与关闭在一般情况下没有规律可寻，且监听端口开启的软件的漏洞更容易被攻击者利用，危害更大。因此，考虑到监听端口开启的信息需要及时获取以及预警，以防止造成不可挽回的危害。也因此，在比获取第一软件信息的周期的更小周期下，获取第二软件信息，即，获取监听端口开启的软件信息；以此，获取监听端口开启的软件的第二预警信息，进一步对该软件优先预警，以可以更大可能的降低漏洞对攻击者来说的可利用性。提升软件应用的安全性。

本申请实施例提供了一种基于oval的漏洞检测方法，还包括：通过Kafka集群接收客户端已安装的软件的所述第一软件信息和所述第二软件信息；根据所述第一软件信息和所述第二软件信息对应生成所述第一预警信息和所述第二预警信息，并将所述第一预警信息和所述第二预警信息发送至所述Kafka集群，以使所述网页端从所述Kafka集群获取所述第一预警信息和所述第二预警信息，所述网页端用于将所述第二预警信息优先展示。

此处，通过Kafka集群接收客户端的第一软件信息和\或第二软件信息后，再将第一软件信息和\或第二软件信息发送至检测服务器，如此，可以降低检测服务器的存储与接收的压力。Kafka集群还可以等待检测服务器检测完当前第一软件信息和\或第二软件信息后向检测服务器继续分发第一软件信息和\或第二软件信息。或者，当检测服务器检测完当前第一软件信息和\或第二软件信息后向Kafka集群获取第一软件信息和\或第二软件信息。如此，可以使得检测服务器的运行处于最佳状态，提升检测服务器运行速度，以及提升检测服务器的应用性能。另外，检测服务器根据第一软件信息和\或第二软件信息确定的软件的基本属性，从检测规则中确定该软件对应的漏洞后，生成第一预警信息或第二预警信息，并将该第一预警信息或第二预警信息发送至Kafka集群，由网页端从Kafka集群拉取第一预警信息或第二预警信息，网页端再将第一预警信息展示到客户端。如此，检测服务器无需存储其生成的第一预警信息和第二预警信息，同样可以使得检测服务器的运行处于最佳状态，提升检测服务器运行速度，以及提升检测服务器的应用性能。其中，采集客户端的第一软件信息的周期大于采集客户端第二软件信息的周期。例如，客户端的第一软件信息的周期是一周上报一次，客户端的第二软件信息的周期是半小时上报一次。具体采集第一软件信息和第二软件信息的周期可以根据具体需要确定。

基于上述流程，本申请实施例提供一种基于oval的漏洞检测的方法，图3为本申请实施例提供的一种基于oval的漏洞检测的方法流程示意图，如图3示，包括：

步骤301、检测服务器检测到定义文件有更新，则将更新的定义文件加载并解析，获取临时定义规则，并根据临时定义规则获取更新的后的定义规则，进一步，根据更新后的定义规则，以增量更新的方式更新到第一存储区的检测规则和第二存储区的而检测规则中。

步骤302、通过代理程序每周搜集已安装的各软件信息并生成包含软件的基本属性的第一软件信息，上报至Kafka集群。这里的通过代理程序上报第一软件信息的周期可以是一天、三天、五天、一周、十天等，具体不做限定。

步骤303、Kafka集群接收第一软件信息后，根据检测服务器的检测情况，向检测服务器发送第一软件信息。

步骤304、检测服务器接收第一软件信息后，将第一软件信息中的至少一个软件基本属性与第一存储区的检测规则对比，若没有该软件基本属性对应的检测规则，则与第二存储区的检测规则对比，获取该软件对应的漏洞，并生成第一预警信息。

步骤305、检测服务器将第一预警信息发送至Kafka集群，网页端从Kafka集群拉取该第一预警信息。该第一预警信息在网页端等待客户端将该第一预警信息展示。因为网页端可能在该第一预警信息之前，还可能有大量的第一预警信息需要在客户端展示。因此，可能出现等候展示该第一预警信息的状况。

步骤306、通过该代理程序每半小时搜集已安装的各软件的状态信息并生成包含开启监听端口的软件的基本属性的第二软件信息，上报至Kafka集群。其中，状态信息中至少包括软件的基本属性和监听端口的开启的状态。这里通过代理程序上报第二软件信息的周期可以是半小时、一小时、两小时、六小时等，具体不做限定。

步骤307、Kafka集群接收第二软件信息后，根据检测服务器的检测情况，向检测服务器发送第二软件信息。

步骤308、检测服务器接收第二软件信息后，确定该第二软件信息中包含软件的基本属性对应的监听端口的状态为开启状态，以及该软件的基本属性存在对应的漏洞，则生成该软件的基本属性对应的第二预警信息。

步骤309、检测服务器将第二预警信息发送至Kafka集群，网页端从Kafka集群拉取该第二预警信息，网页端优先展示该第二预警信息。

此处，上述流程步骤并不唯一，例如，步骤306和步骤302可以同时进行，也可以步骤302在步骤306之前进行，具体不做限定。另外，当第一存储区的检测规则和第二存储区的检测规则更新时，检测服务器停止检测工作，防止检测规则更新未完成，使得检测结果不准确。

基于同样的构思，本申请实施例提供一种基于oval的漏洞检测装置，图4为本申请实施例提供的一种基于oval的漏洞检测装置示意图，如图4示，包括：

收发模块401，用于采集客户端已安装的软件的软件信息；

处理模块402，用于根据所述信息确定软件的基本属性，所述基本属性包括：客户端的操作系统版本、操作系统架构、软件的名称和软件的版本；

所述处理模块402还用于，根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞，其中，预定义的所述检测规则包括从补丁定义库提取得到的软件的基本属性与漏洞的对应关系。

在一种可能的设计中，所述处理模块402具体用于：预定义的所述检测规则包括第一存储区的检测规则和第二存储的检测规则，根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞,包括：根据所述软件的基本属性从所述第一存储区的检测规则中确定出所述软件对应的漏洞；若从所述第一存储区的检测规则中未确定出所述软件对应的漏洞，则从所述第二存储区的检测规则中确定出所述软件对应的漏洞，并将所述软件的基本属性和所述软件的对应的漏洞的对应关系写入所述第一存储区。

在一种可能的设计中，所述补丁定义库中包括各定义文件，所述定义文件至少包括各软件的基本属性、各软件对应的补丁以及各软件对应的漏洞；

所述处理模块402具体用于：确定所述补丁定义库中的定义文件发生变化，则将所述定义文件加载至检测服务器中，并从所述定义文件中提取得到的软件的基本属性与漏洞的对应关系。

在一种可能的设计中，所述处理模块402具体用于：解析所述定义文件，得到所述定义文件中的各软件的临时定义规则，所述临时定义规则至少包括软件的基本属性、软件的补丁以及软件的漏洞的对应关系；根据各软件的临时定义规则得到所述定义文件中的各软件的定义规则；所述定义规则至少包括软件的基本属性与软件的漏洞的对应关系；根据所述定义规则更新所述检测规则。

在一种可能的设计中，所述处理模块402具体用于：所述检测服务器根据所述定义规则更新所述第二存储区中的检测规则，并记录更新的软件的基本属性；所述检测服务器根据更新的软件的基本属性，更新所述第一存储区中的检测规则。

在一种可能的设计中，所述处理模块402具体用于：解析所述定义文件，得到所述定义文件中的各软件的漏洞影响值，并生成漏洞影响值大于设定阈值的各软件的临时定义规则；根据各软件的临时定义规则得到所述定义文件中的各软件的定义规则，包括：根据各软件的临时定义规则，得到所述定义文件中漏洞影响值大于设定阈值的各软件的定义规则。

在一种可能的设计中，所述收发模块401具体用于：接收客户端已安装的软件的第一软件信息，所述第一软件信息中包括监听端口开启的软件的软件信息和监听端口未开启的软件的软件信息。

在一种可能的设计中，所述处理模块402还用于：根据所述软件对应的漏洞生成第一预警信息，所述第一预警信息为监听端口开启的软件的软件信息和监听端口未开启的软件的预警信息。

在一种可能的设计中，所述处理模块402还用于：接收客户端已安装的软件的第二软件信息，所述第二软件信息为监听端口开启的软件的软件信息；根据所述第二软件信息确定监听端口开启的软件以及所述软件对应的漏洞，并生成第二预警信息，所述第二预警信息为监听端口开启的软件的预警信息。

在一种可能的设计中，所述处理模块402还用于：通过Kafka集群接收客户端已安装的软件的所述第一软件信息和所述第二软件信息；根据所述第一软件信息和所述第二软件信息对应生成所述第一预警信息和所述第二预警信息，并将所述第一预警信息和所述第二预警信息发送至所述Kafka集群，以使所述网页端从所述Kafka集群获取所述第一预警信息和所述第二预警信息，所述网页端用于将所述第二预警信息优先展示。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (12)

1.一种基于oval的漏洞检测方法，由检测服务器执行所述方法，其特征在于，所述方法包括：

采集客户端已安装的软件的软件信息；

根据所述软件信息确定所述软件的基本属性，所述基本属性包括：客户端的操作系统版本、操作系统架构、软件的名称和软件的版本；

根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞，其中，预定义的所述检测规则包括从补丁定义库提取得到的软件的基本属性与漏洞的对应关系。

2.如权利要求1所述的方法，其特征在于，预定义的所述检测规则包括第一存储区的检测规则和第二存储的检测规则，根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞,包括：

根据所述软件的基本属性从所述第一存储区的检测规则中确定出所述软件对应的漏洞；

若从所述第一存储区的检测规则中未确定出所述软件对应的漏洞，则从所述第二存储区的检测规则中确定出所述软件对应的漏洞，并将所述软件的基本属性和所述软件的对应的漏洞的对应关系写入所述第一存储区。

3.如权利要求2所述的方法，其特征在于，所述补丁定义库中包括各定义文件，所述定义文件至少包括各软件的基本属性、各软件对应的补丁以及各软件对应的漏洞；所述方法还包括：

确定所述补丁定义库中的定义文件发生变化，则将所述定义文件加载至检测服务器中，并从所述定义文件中提取得到的软件的基本属性与漏洞的对应关系。

4.如权利要求3所述的方法，其特征在于，从所述定义文件中提取得到的软件的基本属性与漏洞的对应关系，包括：

解析所述定义文件，得到所述定义文件中的各软件的临时定义规则，所述临时定义规则至少包括软件的基本属性、软件的补丁以及软件的漏洞的对应关系；

根据各软件的临时定义规则得到所述定义文件中的各软件的定义规则；所述定义规则至少包括软件的基本属性与软件的漏洞的对应关系；

根据所述定义规则更新所述检测规则。

5.如权利要求4所述的方法，其特征在于，根据所述定义规则更新所述检测规则，包括：

所述检测服务器根据所述定义规则更新所述第二存储区中的检测规则，并记录更新的软件的基本属性；

根据所述更新的软件的基本属性，更新所述第一存储区中的检测规则。

6.如权利要求4所述的方法，其特征在于，解析所述定义文件，得到所述定义文件中的各软件的临时定义规则，包括：

解析所述定义文件，得到所述定义文件中的各软件的漏洞影响值，并生成漏洞影响值大于设定阈值的各软件的临时定义规则；

根据各软件的临时定义规则得到所述定义文件中的各软件的定义规则，包括：

根据各软件的临时定义规则，得到所述定义文件中漏洞影响值大于设定阈值的各软件的定义规则。

7.如权利要求1-6任一所述的方法，其特征在于，采集客户端已安装的软件的软件信息，包括：

接收客户端已安装的软件的第一软件信息，所述第一软件信息中包括监听端口开启的软件的软件信息和监听端口未开启的软件的软件信息。

8.如权利要求7所述的方法，其特征在于，根据所述基本属性与预定义的检测规则，确定所述软件对应的漏洞之后，还包括：

根据所述软件对应的漏洞生成第一预警信息，所述第一预警信息为监听端口开启的软件的软件信息和监听端口未开启的软件的预警信息。

9.如权利要求8所述的方法，其特征在于，还包括：

接收客户端已安装的软件的第二软件信息，所述第二软件信息为监听端口开启的软件的软件信息；

根据所述第二软件信息确定监听端口开启的软件以及所述软件对应的漏洞，并生成第二预警信息，所述第二预警信息为监听端口开启的软件的预警信息。

10.如权利要求9所述的方法，其特征在于，还包括：通过Kafka集群接收客户端已安装的软件的所述第一软件信息和所述第二软件信息；

根据所述第一软件信息和所述第二软件信息对应生成所述第一预警信息和所述第二预警信息，并将所述第一预警信息和所述第二预警信息发送至所述Kafka集群，以使所述网页端从所述Kafka集群获取所述第一预警信息和所述第二预警信息，所述网页端用于将所述第二预警信息优先展示。

11.一种计算机可读存储介质，其特征在于，所述存储介质存储有程序，当所述程序在计算机上运行时，使得计算机实现执行权利要求1至10中任一项所述的方法。

12.一种计算机设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于调用所述存储器中存储的计算机程序，按照获得的程序执行如权利要求1至10任一权利要求所述的方法。

Images