四? 扫描节点
4.1 概述
此文原出自【爱运维社区】： http://www.easysb.cn
扫描节点(scanner)是整个分布式扫描系统的终端节点，负责具体漏洞扫描。由于我们的漏洞扫描系统需要集中许多不同的扫描工具，在这些工具当中，有的是只能运行在Windows上，比如WVS，而有的则是只能运行在Linux上，比如openvas，而有的则是可以同时在两种系统上运行，比如nmap。所以，为了能够更好的地集中这些工具，就必须解决系统的异构问题，达到同时支持Linux扫描节点和Windows扫描节点，才能更大地发挥集中扫描平台的优势。
4.2 扫描框架
4.2.1 系统异构
出于系统设计的需求，扫描节点必须需要同时运行在Linux和Windows节点，所以我们在设计扫描节点的框架时，必须要考虑到系统的异构问题。此外，为了减少代码的开发时间和运维工作量，我们不希望在Linux开发一套扫描系统，而在Windows上开发另外一套系统，这样无疑会增加我们的开发和运维成本，而且对以后的升级都是比较棘手的。所以，我们采用脚本语言python开发整个扫描系统，所有的扫描工具都是采用插件的形式封装，然后根据扫描任务动态加载。举个例子，扫描系统启动的时候，它是不会加载任何插件的，保证系统能够同时运行在Linux和Windows节点上，当用户发起的一个WEB扫描任务时，那么该任务会被发送到Windows消息队列，Windows扫描节点会从该消息队列中提取任务，然后动态加载WVS插件，然后调用WVS进行漏洞扫描。同理，假如用户发起的主机扫描任务，那么该任务就会发送到Linux消息队列，Linux扫描节点会从该消息队列中提取任务，然后动态加载openvas插件，然后调用openvas进行漏洞扫描。如此一来，同一个扫描系统可以同时兼容Windows和Linux系统，就很好地解决系统的异构问题。
4.2.2 框架结构
在【消息通信】章节中，整个分布式系统主要是通过消息队列（ActiveMQ）来进行扫描任务的分发。同时，为解决系统异构问题，我们使用了Windows和Linux两个消息队列，用于不同类型的任务分发，扫描节点的框架如下图4-1所示。
图4-1 扫描节点的框架结构
从上图中，我们可以看到扫描节点存在好几个不同类型的线程，分别负责不同的功能，其功能如下表3-1所示。
表3-1 扫描节点内部主要的线程和进程功能表
对照图3-1和表3-1，我们可以看出，扫描节点的内部有任务队列【Task Queue】和结果队列【Result Queue】两个队列，而接收任务线程【Receive
MQ Thread】首先从ActiveMQ中获取扫描任务，然后将其推入到内部的任务队列【Task Queue】中，主线程【Main Porcess Thread】会从内部队列【Task Queue】中提取扫描任务消息，然后根据任务消息启动一个扫描线程【Scan Thread】， 而扫描线程【Scan Thread】启动之后会创建一个插件进程【Plugin Process】，该进程会调用nmap， WVS，openvas等相关工具，待执行结束后会将扫描的结果推入到结果队列【Result Queue】。结果同步线程【Sync
Result Thread】从结果队列【Result Queue】中获取扫描结果，然后通过WEB的REST接口同步到中央数据库。而查询任务状态线程【Query Task status Thread】则是周期性地通过WEB的REST接口查询当前扫描任务的状态，如果发现有任务被取消的话，那么它就会发送一个取消【Cancel】的消息到任务队列【Task Queue】中，然后主线程【Main Porcess Thread】取出这个消息后，就会终止相应的扫描线程【Scan Thread】和插件进程【Plugin Thread】。
扫描节点内的多个线程，不同的线程负责不同的功能，虽然看起来比较复杂，但是这样可以尽量解耦各个模块之间，以增强可扩展性和稳定性，也可以大大降低后期的维护和升级的成本。
4.2.3扫描线程和插件进程的启动
扫描节点中主线程会根据扫描任务通过内部线程管理器【Thread Manager】启动一个扫描线程，其框架如下图4-2所示。
图 4-2 扫描线程与插件进程
从上图4-2可以看出，线程管理器启动了扫描线程之后，扫描线程会根据任务任务从插件工厂【Plugin Factory】获取任务相对应的插件进程实例，并启动插件进程。比如扫描线程1的任务类型是主机安全扫描，那么它会通过插件工厂获得一个openvas的插件实例(plugin
A)，然后启动该插件进程，扫描线程2的任务类型是Web漏洞扫描，那么它会通过插件工厂获得WVS的插件实例（Plugin B），然后启动该插件进程。
4.2.4扫描线程和插件进程的通信
当扫描任务被取消的时候，主进程会找到相对应的扫描线程【Scan Thread】，然后通过扫描线程来终止相对应的插件进程【Plugin Thread】，其通信的框架如图4-3所示。
图 4-3 扫描线程和插件进程的通信结构图
扫描线程【Scan Thread】在启动插件进程时，会创建一个队列Queue用于和插件进程【Plugin Process】通信。在插件进程内部有任务扫描【Task
Scanning】和通信【communication】两个线程，其中任务扫描线程是调用具体的扫描工具或者脚本的，比如openvas，nmap，WVS等等，在调用结束后会将扫描的结果推入到扫描节点内部的结果队列【Result Queue】中，而通信线程则是通过队列【Queue】与扫描线程通信。
当任务被取消时，主线程会通过相对应的扫描线程发送一个终止的命令到队列queue中，插件进程中的通信线程收到这个消息时就会调用终止函数(stop_script)来结束当前的线程。各个插件的终止函数略有不同，这样可以让各个插件进程在终止前做一些必要的工作，比如同步已有结果，清理扫尾等，增加插件的灵活性。但是，如果超过一定的时间相关进程和线程还没有被终止的话，那么就会被主进程强制杀掉，避免进程僵死的情况发生。
4.4 小结
为了解决系统的异构问题，我们采用了两个任务消息队列来下发扫描任务，扫描节点中的各个扫描功能模块全部采用插件的形式，在需要的时候动态加载，保证了系统的稳定性和可扩展性。
作者：胡杨<[email protected]><[email protected]>
此文原出自【爱运维社区】： http://www.easysb.cn
如转载请标明原出处，谢绝阉割党。