CN113992452A

CN113992452A - 一种网络安全赛事平台漏洞修复检测方法与系统

Info

Publication number: CN113992452A
Application number: CN202111626963.9A
Authority: CN
Inventors: 黄云; 孙展飞; 王航; 陈子昂; 金正阳; 唐海均; 谢峥; 高庆官
Original assignee: Nanjing Cyber Peace Technology Co Ltd
Current assignee: Nanjing Cyber Peace Technology Co Ltd
Priority date: 2021-12-29
Filing date: 2021-12-29
Publication date: 2022-01-28
Anticipated expiration: 2041-12-29
Also published as: CN113992452B

Abstract

本发明公开了一种网络安全赛事平台漏洞修复检测方法与系统。本发明在平台创建靶场时，根据靶场网络拓扑分配Checker容器并隐藏容器，其中一个Checker容器对应多个靶标，Checker容器能够访问相同虚拟网络中的靶标，并连接平台服务器；平台向Checker容器下发检测指令前，先同步最新脚本再下发指令；Checker容器收到平台下发的检测指令后，载入对应的脚本并执行，把具体的检测方式以及需要的附件下发到靶标进行检测工作，待检测结束后回传结果，并将获取的结果上报给平台。本发明中容器根据靶场网络拓扑分配，且与靶标解耦，部署简单、易于维护；并且保证了容器安全、检测结果的准确性，保证了比赛公平有序。

Description

一种网络安全赛事平台漏洞修复检测方法与系统

技术领域

本发明涉及一种网络安全赛事平台漏洞修复检测方法与系统，属于网络安全、计算机软件领域。

背景技术

近年来，我国网络安全产业取得积极进展，特别是随着5G、大数据、人工智能、车联网、工业互联网、物联网等新技术新业务新模式快速发展，网络安全、数据安全等技术、产品和服务蓬勃发展。过去十年间，我国网络安全产业资本化进程明显加快，目前市场发展已迈入稳健增长期。目前我国每年网络安全相关专业毕业生只有2万多人，而行业的缺口已经高达50万至100万人，网络安全行业人才供需矛盾正急剧凸显，实战型、实用型等人才非常急缺。

网络安全行业的人才供需严重失衡，所以培养一批该领域的人才成为了当务之急。无论是企业还是学校，培养网络安全人才都需要建设实训基地和网络靶场，在学习理论的基础上进行实战，加深对有关知识的理解与灵活运用。

随着网络安全人才的日益增多，网络安全比赛（下文简称比赛）也越来越受大家的关注与参与。比赛的本质在于对安全问题的修复，赛事正常举办的前提是网络安全比赛平台（下文简称平台）的正常运行。但由于此类比赛的特殊性，使得平台更加容易受到攻击，因此需要一种有效的检测方案，在不被攻击的前提下，对靶场中网络安全漏洞（下文简称赛题）的修复情况进行实时可靠的检测并反馈，用以评判各参赛方的比赛进度与最终名次。

目前已有的平台对于安全问题修复的检测，通常是将检测的代码或程序放在靶场中的靶机上或者是靶场网络中，如图1所示，存在以下缺点：1、当靶场拓扑变得越来越复杂的时候，检测程序的维护成本会成倍增长。只有几个靶标（靶场中的一个节点，或者是一台机器）的时候还能凑合，靶标增加到几十上百个，对维护人员来说就是一场灾难。2、检测程序与靶机强耦合，无法在比赛过程中动态改变检测程序的逻辑。如果非得改变，就需要逐一登录到靶标进行修改，这是一个顾此失彼的过程。3、检测程序暴露在靶场中，随时都有被篡改的可能。参与比赛的用户，都是有网络攻防相关知识的人才，由于比赛需要，靶场环境对参赛者是开放的，这也就决定了靶场环境不是一个绝对安全的地方。参赛者只要通过一定的技术手段，就能拿到检测代码并修改检测结果。

发明内容

发明目的：针对上述现有技术存在的问题，本发明目的在于提供一种网络安全赛事平台漏洞修复检测方法与系统，以尽可能的完善检测机制，保证比赛能够公平有序正常的进行，并且易于维护，部署简单。

技术方案：为实现上述发明目的，本发明采用如下技术方案：

一种网络安全赛事平台漏洞修复检测方法，包括如下步骤：

平台在创建靶场时，根据靶场网络拓扑分配Checker容器，一个Checker容器对应多个靶标，Checker容器能够访问相同虚拟网络中的靶标，并连接平台服务器；所述Checker容器在靶场网络拓扑中隐藏，对参赛者不可见；

平台向Checker容器下发检测指令前，先判断本地脚本与容器内脚本是否相同，若不相同则更新容器内脚本；然后向Checker容器下发检测指令；

Checker容器收到平台下发的检测指令后，载入对应的脚本并执行，把具体的检测方式以及需要的附件下发到靶标进行检测工作，待检测结束后回传结果，并将获取的结果上报给平台。

作为优选，根据靶场网络拓扑分配Checker容器时，为每个独立的虚拟网络创建一个容器，用于检测该网络中的所有靶标。

作为优选，所述Checker容器内的程序使用gRPC框架开发，gRPC客户端给平台调用，gRPC服务端在容器内部运行，与靶标交互。

作为优选，所述gRPC客户端和gRPC服务端之间的消息采用ProtoBuf协议进行编码。

作为优选，平台通过Celery异步调度gRPC客户端的接口，采用Redis作为Celery的消息中间件和结果存储后端，先把检测任务存储在Redis中，然后按照配置的消费速度下发到Checker容器，容器接收到任务后去靶标上检测指定漏洞的修复情况，并将结果上报，结果最终存在Redis中供平台消费使用。

作为优选，所述gRPC客户端对平台提供查询MD5、上传文件、执行脚本和日志查询接口；调用执行脚本接口时，至少要指定靶标的IP地址。

作为优选，平台通过查询容器内已存在的脚本的MD5值，并与本地脚本MD5值相比较，如果不一样则更新容器内的脚本。

作为优选，所述平台服务器不直连靶场网络，通过Checker容器检测解题进度；所述Checker容器通过VPN连接平台服务器。

基于相同的发明构思，本发明提供的一种网络安全赛事平台漏洞修复检测系统，包括：

Checker容器部署模块，用于根据靶场网络拓扑分配Checker容器，一个Checker容器对应多个靶标，Checker容器能够访问相同虚拟网络中的靶标，并连接平台服务器；所述Checker容器在靶场网络拓扑中隐藏，对参赛者不可见；

检测任务下发模块，用于平台向Checker容器下发检测指令前，先判断本地脚本与容器内脚本是否相同，若不相同则更新容器内脚本；然后向Checker容器下发检测指令；

以及，检测任务执行模块，用于Checker容器收到平台下发的检测指令后，载入对应的脚本并执行，把具体的检测方式以及需要的附件下发到靶标进行检测工作，待检测结束后回传结果，并将获取的结果上报给平台。

基于相同的发明构思，本发明提供的一种网络安全赛事平台系统，包括平台服务器，以及承载靶场环境的计算节点设备；所述平台服务器及计算节点设备均包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述平台服务器的计算机程序被加载至处理器时实现所述的网络安全赛事平台漏洞修复检测方法中的平台执行的步骤；所述计算节点设备的计算机程序被加载至处理器时实现所述的网络安全赛事平台漏洞修复检测方法中的Checker容器执行的步骤。

有益效果：本发明提供的网络安全赛事平台漏洞修复检测方案是一种基于docker容器的解决方案，在靶场中启动独立容器来执行有关检测与反馈的工作。与现有技术相比，本发明具有如下优点：首先，容器不再与靶标一一对应，而是根据靶场网络拓扑分配，简化拓扑，易于维护；其次，容器与靶标进行解耦，平台可以随时替换检测脚本实时生效，并能在同一时间应用于所有靶标；最后，在动态分配容器时，将其在靶场网络的拓扑中隐藏，对参赛者不可见，这样保证了容器的安全，也即保证了检测结果的准确性。同时该容器内部的程序使用gRPC框架开发，基于ProtoBuf序列化协议，能够提供高性能高可用的服务，支持众多开发语言，可移植性强，部署简单，适用于各种复杂的网络靶场环境。

附图说明

图1为现有网络安全漏洞修复检测方案示意图。

图2为本发明实施例中基于容器的网络安全漏洞修复检测方案示意图。

图3为本发明实施例中的Checker容器动态分配示例图。

图4为本发明实施例中检测任务异步调度的整体流程图。

具体实施方式

下面将结合附图和具体实施例，对本发明的技术方案进行清楚、完整的描述。

网络安全比赛通常涉及两个主体，即主办方和参赛方，主办方举办比赛，提供基础设施和靶场环境。参赛方参与比赛，找到靶场中的漏洞并修复，最终按照得分排名分胜负。比赛开始前，主办方需要为参赛方在OpenStack上部署靶场环境，并在靶场中设置若干的安全漏洞，也即比赛题目。参赛方在比赛开始后，方可通过跳板机进入到靶场中进行比赛。在比赛过程中，需要对漏洞修复情况进行实时可靠的检测并反馈。为实现这一目的，本发明在创建靶场时，根据靶场网络拓扑动态分配Checker容器，Checker容器与靶标采用一对多模式，以简化部署与运维；在实现检测时，平台将最新脚本同步到Checker容器；容器收到检测指令后，连接指定靶标进行检测工作，并将获取的结果上报给平台。

如图2所示，本发明在独立于靶场的网络环境中，部署用于检测漏洞修复情况的Checker容器。Checker一方面与靶场在相同的VLAN上，能够访问靶标；另一方面通过VPN连接平台服务器，把检测结果推送给平台，用于平台大屏展示和实时监控各参赛者的解题情况。在比赛过程中，参赛方只能看到和访问靶场中的靶标，Checker容器对参赛方完全透明，且不可访问，这样就能保证检测程序不会受到攻击和破坏。

Checker容器连接靶场和平台服务器，起到了承上启下的作用，一方面需要检测解题进度，另一方面也保证了平台的安全。如果没有该容器，为了检测参赛者的解题进度，平台服务器就不得不直连靶场网络，只要互联，就存在被参赛者攻击的可能。与此同时，Checker容器的动态分配减少了维护人员的工作量，而且支持随时随地的更新替换检测脚本，实时生效，能够适应各种复杂的场景。

下面详细介绍本发明实施例提供的一种网络安全赛事平台漏洞修复检测方法的实施细节，主要包括容器分配和容器内部实现两个主要部分。

Checker容器分配：

平台在创建靶场的时候，根据靶场网络拓扑动态计算出该靶场所需的Checker容器数量和位置。通常一个Checker容器对应多个靶标，Checker容器能够访问相同虚拟网络中的靶标，并连接平台服务器。以图3所示的靶场拓扑为例，图中有三个网络，由路由器01、路由器02、路由器03连接起来组成一个完整的拓扑。容器的分配原理是为每一个独立的网络创建一个容器，用于检测该网络中的所有靶标，例如检测容器01检测靶标05～07，检测容器02检测靶标01、靶标04，检测容器03检测靶标01～03。靶标01之所以会被两个容器检测，是因为靶标01归属于两个网络，这个计算过程由平台算法自动完成，无需人为干预。然后就是容器的实例化，并把容器挂载到相应的网络下，使得容器能够正常访问靶标和平台服务器。在展示给参赛方的拓扑中删除Checker容器，参赛方感知不到容器的存在。并且容器会根据不同的检测方案，仅开放必须的端口，即使容器被发现，也无法连接上，充分保证了其安全性。

Checker容器内部实现：

Checker容器内的程序是基于gRPC框架开发的，需支持修改检测脚本和执行检测任务。图4示意了整体设计，检测任务始于平台，途径Celery异步调度，将任务交给容器并下发到靶标。在靶场中检测漏洞修复情况是一个异步耗时任务，所以本实施例中平台通过Celery进行调度。考虑到大型赛事下的高并发对系统带来的压力，防止Checker容器失去响应，本实施例中采用Redis作为Celery的消息中间件和结果存储后端，在检查任务繁重的时候，先把检测任务都放到Redis中，然后按照配置的消费速度下发到Checker容器，容器拿到任务后去靶标上检测指定漏洞的修复情况，并将结果上报，结果最终会存在Redis中供平台消费使用。

gRPC Client放在平台端，给平台调用；gRPC Server在容器内部执行，与靶标交互。

gRPC Client对平台暴露四个接口，分别为查询MD5、上传文件、执行脚本和日志查询接口。

1）查询MD5 。查询容器内已存在的脚本的MD5值，并将值返回给平台，平台拿到这个值之后，与平台上的脚本MD5值相比较，如果不一样就说明容器内的脚本需要更新。

2）上传文件。脚本以文件的形式存放在平台上，需要调用这个接口将文件上传到容器内。

3）执行脚本。该接口携带执行脚本时必须的参数（包括靶标IP、靶标对应的检测脚本路径、脚本名称），给容器内的gRPC Server下发执行指令。

4）日志查询。当检测出现错误，需要分析原因时，可以使用该接口一键下载远程容器中的日志文件。

平台每次下发检测指令时，都需要先调用查询MD5接口，并计算本地脚本文件的MD5值，然后进行比较。如果两个值不一样，就使用上传文件接口，将本地的脚本文件上传一份到容器。之所以这样设计，原因有二。其一，靶标上的漏洞多种多样，Checker容器无法预置未知的漏洞检测方案；其二，每次执行脚本前检查脚本文件，能及时发现平台上脚本文件的更新，防止使用旧的脚本执行检测。

脚本文件及其附件上传到容器之后，容器会对脚本进行本地管理，与对应的靶标做关联，因为容器与靶标不是一对一的关系，一个容器需要负责多个靶标的检测，如果不做管理，就会导致脚本文件混乱甚至丢失。

文件上传之后就可以执行检测了。平台任务发给gRPC Client，消息经ProtoBuf编码后传递到Checker容器内部，gRPC Server收到消息对其进行解码，根据解码后的参数找到对应脚本和附件。一切准备就绪后，通过模块导入的方式载入脚本并执行，此时脚本会把具体的检测方式以及需要的附件下发到靶标进行检测工作。比如在靶标上检测某服务（如web服务）是否可以访问以评估参赛者是否完成了该web漏洞的修复，具体检测可以是nginx服务器配置是否正确、80端口是否可访问、uwsgi服务有没有启动等。脚本如何连接靶标也由脚本自己决定，可以是tcp连接、socket连接等。检测可能需要一定的时间，待结束后回传结果。gRPC Server 拿到结果后对其进行ProtoBuf编码，然后发送给gRPC Client，经解码得到检测结果。

gRPC Client 和 gRPC Server之间的消息之所以要编码，是为了提高检测的效率。本发明实施例编码采用Google ProtoBuf协议，比起json这种方式，后者的内存占用是前者的三倍，且编解码性能次数在两千次以上，前者优势就明显大于后者，次数在10万次以上，ProtoBuf的性能就能够远远大于json。

综上，可得到如下详细的开发与维护操作流程。

1）平台定义Celery异步任务；

2）定义Checker容器各接口，使用Google Proto描述接口，然后根据使用的开发语言编译成对应的代码：

a)查询MD5 rpc GetMd5(NoneRequest) returns (Md5Response) {}

b)上传文件 rpc UploadFile(UploadRequest) returns (UploadResponse) {}

c)执行脚本rpc ExecChecker(ExecRequest) returns (ExecResponse) {}

d)日志查询 rpc DownloadFiles(PathRequest) returns (FilesResponse) {}

3）编译接口描述文件，生成gRPC Client 和 gRPC Server，假设使用Python开发语言，编译后的接口如下

class CheckerStub(object):

"""Missing associated documentation comment in .proto file."""

def __init__(self, channel):

"""Constructor.

Args:

channel: A grpc.Channel.

"""

self.GetMd5 = channel.unary_unary(

'/checker.Checker/GetMd5',

request_serializer=checker__pb2.NoneRequest.SerializeToString,

response_deserializer=checker__pb2.Md5Response.FromString,

)

self.UploadFile = channel.unary_unary(

'/checker.Checker/UploadFile',

request_serializer=checker__pb2.UploadRequest.SerializeToString,

response_deserializer=checker__pb2.UploadResponse.FromString,

)

self.ExecChecker = channel.unary_unary(

'/checker.Checker/ExecChecker',

request_serializer=checker__pb2.ExecRequest.SerializeToString,

response_deserializer=checker__pb2.ExecResponse.FromString,

)

self.DownloadFiles = channel.unary_unary(

'/checker.Checker/DownloadFiles',

request_serializer=checker__pb2.PathRequest.SerializeToString,

response_deserializer=checker__pb2.FilesResponse.FromString,

)

class CheckerServicer(object):

"""Missing associated documentation comment in .proto file."""

def GetMd5(self, request, context):

"""Missing associated documentation comment in .proto file."""

context.set_code(grpc.StatusCode.UNIMPLEMENTED)

context.set_details('Method not implemented!')

raise NotImplementedError('Method not implemented!')

def UploadFile(self, request, context):

"""Missing associated documentation comment in .proto file."""

context.set_code(grpc.StatusCode.UNIMPLEMENTED)

context.set_details('Method not implemented!')

raise NotImplementedError('Method not implemented!')

def ExecChecker(self, request, context):

"""Missing associated documentation comment in .proto file."""

context.set_code(grpc.StatusCode.UNIMPLEMENTED)

context.set_details('Method not implemented!')

raise NotImplementedError('Method not implemented!')

def DownloadFiles(self, request, context):

"""Missing associated documentation comment in .proto file."""

context.set_code(grpc.StatusCode.UNIMPLEMENTED)

context.set_details('Method not implemented!')

raise NotImplementedError('Method not implemented!')

4）定义脚本文件。使用Python编写，脚本中必须包含一个名为checker的入口函数，接收一个必选参数IP和其他可选参数，IP为该脚本需要检测的靶标地址。脚本中其他方法或者类对象可以自定义，没有限制。

def checker(ip, **kwargs):

# 此处省略检测具体方法

if success

return 0

if failed

return 1

5）制作 Checker容器镜像，将gRPC Server及相关依赖文件制作到镜像内，并通过supervisor命令指定当启动容器就自动运行程序；

6）上传容器镜像到paas平台；

7）平台创建靶场环境，实例化靶标，并在靶场中或者靶标上配置比赛需要的漏洞；

8）平台根据靶场网络拓扑动态分配Checker容器，并下发容器创建请求给paas平台，同时需要将容器从靶场网络中移除，隐藏Checker容器；

9）靶场和容器创建完成后，就可以进行正常的比赛和运维，Celery会定时下发检测命令，Checker根据检测命令执行并返回结果。

基于相同的发明构思，本发明实施例提供的一种网络安全赛事平台漏洞修复检测系统，包括：Checker容器部署模块，用于根据靶场网络拓扑分配Checker容器，一个Checker容器对应多个靶标，Checker容器能够访问相同虚拟网络中的靶标，并连接平台服务器；所述Checker容器在靶场网络拓扑中隐藏，对参赛者不可见；检测任务下发模块，用于平台向Checker容器下发检测指令前，先判断本地脚本与容器内脚本是否相同，若不相同则更新容器内脚本；然后向Checker容器下发检测指令；以及，检测任务执行模块，用于Checker容器收到平台下发的检测指令后，载入对应的脚本并执行，把具体的检测方式以及需要的附件下发到靶标进行检测工作，待检测结束后回传结果，并将获取的结果上报给平台。

基于相同的发明构思，本发明实施例提供的一种网络安全赛事平台系统，包括平台服务器，以及承载靶场环境的计算节点设备；所述平台服务器及计算节点设备均包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述平台服务器的计算机程序被加载至处理器时实现所述的网络安全赛事平台漏洞修复检测方法中的平台执行的步骤；所述计算节点设备的计算机程序被加载至处理器时实现所述的网络安全赛事平台漏洞修复检测方法中的Checker容器执行的步骤。

Claims

1.一种网络安全赛事平台漏洞修复检测方法，其特征在于，包括如下步骤：

2.根据权利要求1所述的网络安全赛事平台漏洞修复检测方法，其特征在于，根据靶场网络拓扑分配Checker容器时，为每个独立的虚拟网络创建一个容器，用于检测该网络中的所有靶标。

3.根据权利要求1所述的网络安全赛事平台漏洞修复检测方法，其特征在于，所述Checker容器内的程序使用gRPC框架开发，gRPC客户端给平台调用，gRPC服务端在容器内部运行，与靶标交互。

4.根据权利要求3所述的网络安全赛事平台漏洞修复检测方法，其特征在于，所述gRPC客户端和gRPC服务端之间的消息采用ProtoBuf协议进行编码。

5.根据权利要求3所述的网络安全赛事平台漏洞修复检测方法，其特征在于，平台通过Celery异步调度gRPC客户端的接口，采用Redis作为Celery的消息中间件和结果存储后端，先把检测任务存储在Redis中，然后按照配置的消费速度下发到Checker容器，容器接收到任务后去靶标上检测指定漏洞的修复情况，并将结果上报，结果最终存在Redis中供平台消费使用。

6.根据权利要求3所述的网络安全赛事平台漏洞修复检测方法，其特征在于，所述gRPC客户端对平台提供查询MD5、上传文件、执行脚本和日志查询接口；调用执行脚本接口时，至少要指定靶标的IP地址。

7.根据权利要求1所述的网络安全赛事平台漏洞修复检测方法，其特征在于，平台通过查询容器内已存在的脚本的MD5值，并与本地脚本MD5值相比较，如果不一样则更新容器内的脚本。

8.根据权利要求1所述的网络安全赛事平台漏洞修复检测方法，其特征在于，所述平台服务器不直连靶场网络，通过Checker容器检测解题进度；所述Checker容器通过VPN连接平台服务器。

9.一种网络安全赛事平台漏洞修复检测系统，其特征在于，包括：

10.一种网络安全赛事平台系统，包括平台服务器，以及承载靶场环境的计算节点设备；所述平台服务器及计算节点设备均包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述平台服务器的计算机程序被加载至处理器时实现根据权利要求1-8任一项所述的网络安全赛事平台漏洞修复检测方法中的平台执行的步骤；所述计算节点设备的计算机程序被加载至处理器时实现根据权利要求1-8任一项所述的网络安全赛事平台漏洞修复检测方法中的Checker容器执行的步骤。