基于Redis的扫描器任务调度设计方案

最近在研究扫描器任务调度相关的东西,几番折腾后有些个人心得,心想需记录下来,避免遗忘,也当作是一种积累。之前我开发过几款扫描器(甲方内部使用),架构一直沿用:mysql(DB)+ rabbitmq(QUEUE)+ celery(调度)+ supervisor(进程监控)+ python(编程语言)。在经过一段时间的使用测试后,深感rabbitmq作为队列其架构还是过于厚重,不太适合扫描器一类的项目。当然并不是说rabbitmq就完全不适合作为扫描器的队列,而是我们应当寻求更简便的方案。

在研究了几款开源队列产品后,我决定在最新版的扫描器中放弃沿用之前的架构,转而使用redis作为队列存储。原因主要有几点:1、redis使用简单 2、redis比较轻量 3、redis可以满足功能需求。熟悉redis的朋友可能知道它是一款开源的key-value存储系统,常常用作数据缓存服务,那么如何使它在扫描器架构中提供一个队列服务呢?

首先需要思考一下,扫描器架构中的队列服务或者说任务调度服务,需要满足哪些功能?第一:控制扫描QPS,第二:任务优先级控制,第三:任务状态ACK确认(丢失重扫),第四:任务指定Agent扫描。

简单解释一下,如果您的扫描器针对甲方,那么控制扫描QPS是非常重要的,因为有些业务有qps要求,胡乱扫描可能会被怼。控制任务优先级就不用多说了,比如针对某个最新漏洞的应急扫描,此任务必须优先,因为需要赶在漏洞被利用之前发现并修复(时间就是kpi)。任务状态ACK也好理解,比如某个节点在扫描过程中异常,导致扫描数据丢失,那么需要将此任务重新放回队列扫描。任务指定扫描agent需求,这个可能比较模糊我解释一下,在甲方公司,资产覆盖办公网、生产网、外网边界等,各个机房的网络还可能不通,因此扫描Agent需要覆盖到各类环境,比如办公服务器、生产网服务器,甚至各个机房服务器都需要部署。那么在添加一个扫描任务时,就需要指定这个任务需要在哪个网络环境下的节点进行扫描,因此任务指定Agent扫描需求也是必须要实现的。

需求设计好了,那么如何实现呢?我们知道redis是一款key-value形式的存储系统,如果需要提供像rabbitmq那样的队列服务,就需要使用redis的一个特殊数据结构–列表。redis中的列表可以实现任务的插入、取出,可简单实现队列存储功能,其次列表可以左、右插入,也可以左、右取出,据此可以实现任务优先级控制。那么如何实现控制QPS、实现任务状态ACK、实现指定Agent扫描?这些功能比较复杂,不单单是靠redis就可以实现的,因此接下来我要重点谈谈如何实现以上这三个功能。

任务调度架构

任务调度部分整体架构,包含:Mysql、控制中心、REDIS、API、Agent

上图中的描述写得比较粗糙,可以直接往下看。

重点内容!!!:一个agent在redis中对应唯一一个agent列表,用来存放任务公共信息;一个task在redis中对应唯一一个task列表用来存在任务扫描数据,以及对应唯一一个task ack列表,用来存放将要ack确认的数据(包含时间戳)。

MYSQL+控制中心+REDIS

来看下MYSQL+控制中心+REDIS这一部分:

说明:这一部分实现的功能主要是:1)循环监听数据库中最新添加的任务,将其插入到指定的redis列表中;2)循环监听redis task列表,若task列表以及task_ack列表都为空,则删除agent列表中对应的任务公共信息;3)遍历task_ack列表,获取数据(包含时间戳),判断是否ack超时,若超时则将该数据重新插入task列表(这里可以设置超时次数阈值,超过上限则丢弃数据)。

执行流程

控制中心将最新任务插入redis过程:

  • 控制中心遍历mysql的task表,获取最新的任务信息,该任务信息包含任务ID以及任务环境等参数,可用其对应agent表中的一批Agent(比如任务网络环境为办公网,则该任务可分配给所有办公网agent;若任务指定了agent个数,则可选择分配给部分agent,这也就是实现了控制QPS)。
  • 控制中心获取任务数据以及对应的agent数据后,将任务数据中的公共信息插入redis中对应的agent列表(一个任务公共信息可能插入多个agent列表,由此来控制此任务由哪些agent扫描);将任务扫描数据插入redis中对应的task列表。

控制中心将任务从redis中删除过程:

  • 控制中心遍历redis中的task表,若task表为空,则判断对应的task_ack表状态,若也为空,则删除所有agent列表中包含该任务的公共信息。
REDIS+API+AGENT

来看下REDIS+API+AGENT这一部分架构:

说明:这一部分实现的功能主要是:1)agent通过api获取对应的任务数据,任务数据包含:1、任务公共信息2、任务扫描数据;2)agent通过api进行任务ack确认。

执行流程

Agent_01请求API获取任务信息过程:

  • agent请求API的时候,带上了自己的agent_id,比如:01
  • api从REDIS中的agent_01_list列表中获取一个任务的公共信息(注意这里是获取任务公共信息,并不是pop,即数据不会从列表中删除)
  • api从任务公共信息中获取该任务的任务ID,比如:001
  • api通过任务ID从对应的任务列表task_001_list中pop出扫描数据,与此同时将该扫描数据插入任务ack列表task_ack_001_list中。

Agent_01请求API进行任务ACK确认过程:

  • agent请求API的时候,带上了任务ID,比如:001;以及任务扫描数据,比如:thief.one
  • api从对应的任务ack列表task_ack_001中删除该扫描数据,thief.one。

实现控制QPS

回顾一下前文中描述的,控制中心将任务信息插入到redis列表中的过程,即可以根据任务参数选择对应的agent数量,每个agent的扫描qps相对是固定的,因此用控制单个任务的agent数量,来控制此任务的扫描QPS。

实现任务状态ACK

回顾一下前文中描述的,agent请求api获取任务信息,以及进行任务ack确认过程,即api从任务列表中取出(pop)一个数据的同时,将该数据插入任务ack列表中。当任务扫描完成后,再通过api将此数据从任务ack列表中删除。控制中心认为任务列表以及任务ack列表都为空时,此任务才算正真扫描完,事实也应该如此。

实现指定Agent扫描

回顾一下前文中描述的,控制中心将任务信息插入到redis列表中的过程,任务在添加到mysql中时可以附带很多参数,比如网络环境、qps数量、扫描插件等等,那么网络环境参数就决定了此任务只能分配给对应网络环境的agent进行扫描。

后文

前文介绍了一些基于redis实现的扫描器调度设计方案,当然这只是个人根据实践得出的方案,尚不够成熟,并且很多实现过程中的细节无法一一详细描述。只能说,很多时候需要靠实践中摸索出一条通往光明的道路。

发表评论

电子邮件地址不会被公开。 必填项已用*标注