漏洞治理平台的设计与实现

几个月前笔者曾经梳理过技术方面的漏洞处理的心得，经过几个月的实践和迭代，我们在公司内推出了漏洞治理的概念，并进行实践中。本文就漏洞治理体系的设计和实现的各个环节做个详细的阐述。

适用场景：

业务系统逻辑复杂，部门间关系较复杂，对网络安全敏感性高的环境。（当然内部环境简单的企业也可以采用，但会感觉方案太重）

整体架构：

整体架构从资产发现开始，第二个阶段是漏洞扫描，第三个阶段是漏洞处理，第四个阶段是数据分析和展示。我们逐个展开一下：

一、资产发现

对于安全和运维工作来讲，资产是一切的基础，其重要性怎么强调都不过分。但大部分企业资产管理工作都不是安全部门的职责，如果运维部门能提供准确、全面的资产信息，那是非常幸福的事，此段可以直接略过。但从笔者了解的情况看，很多企业这方面的工作都或多或少的有所欠缺尤其是经历了快速增长期和漫长建设期的企业更是如此。

1.1 IP&服务资产

为了安全检查的全面性，安全部门的资产发现至少要确认IP、端口和服务，至于业务线和负责人的信息可以交给相关资产管理部门来完善。具体方法如下：

技术选型：经过多方面考虑我们还是选择功能非常成熟的nmap，通过调度程序启动多个nmap进程，并将任务分解后下发给不同nmap；

使用方法：

①第一步还是探活，我们用-sn完成探活，这里需要说明一下，很多文章讲-sn的时候都说仅仅是ICMP探测，但通过抓包我们发现实际策略是ICMP+80+443。

为了增加准确度，我们进一步将nmap源码中探活策略修改为更多常用端口（如：增加22、3389、3306等），具体端口信息可以根据企业实际情况酌情处理，但不要增加太多，以免影响效率。

②探活之后就是全端口和服务发现，这部分就用nmap原生功能就没问题。

③IP&服务下线策略，实际扫描中我们发现nmap会由于各种原因导致漏报，所以不能在新一轮扫描没发现某个服务就直接判断该服务失效。我们的策略是连续三次扫描中都没发现该服务才会将该服务判定为下线。

1.2 url资产

相对于IP资产，url资产是比较麻烦的，单独用一种手段很难完全满足需求。我们基本上通过两种手段：爬虫和流量解析，稍稍展开一下。

①爬虫：我们是通过改造幽灵蛛（https://github.com/henrylee2cn/pholcus）实现的，目前效率还可以接受，一台sever限制一个主域爬15层，2个小时内完成140万个链接的任务。

②流量解析：爬虫的诸多局限性不用多说，所以我们将访问流量解析出的url与url资产列表比对，有新增的加入到资产表中。另一个角度说，如果没有请求，就算这个url存在我们也不必要去检查漏洞，因为根本没人访问（包括黑客）。但流量解析涉及到每秒几十万用户请求的情况下如何快速去重，我们还在实验中。

二、漏洞发现

有了资产信息，下一步就是漏洞发现了，漏洞发现我们通过三类逻辑实现：资产信息匹配，商业扫描器，自主开发扫描器。

2.1 资产信息匹配

这类方法主要适用于0day漏洞爆发，在没有验证脚本的情况下，通过版本信息来判断漏洞影响范围。这个比较好理解，就是前端页面设计的时候注意搜索条件的填写就好。这类方法检查漏洞是有一定缺陷的，所以我们还要用扫描器完成外部扫描工作。

2.2 商业扫描器

商业扫描器大家都比较熟悉，优势是技术成熟、漏洞信息全面、部署简单；但缺点也很明显：

• 扫描速度很慢，我们的经验是约6000台sever需要三周
• 大量漏洞信息需要忽略，导致整理报告时间很长
• 漏洞更新需要依赖厂商，无法自定义

2.3 自主开发扫描器

为了解决商业扫描器的上述问题，我们设计并开发了自己的扫描工具，这里简述一下实际运行逻辑，具体的实现方法暂不过多展开，我会用单独一篇文章阐述。

核心扫描组件：我们分别用java、python和Go做了分布式框架，目前看Go的效果最佳，但Python的适配性最好。基本方法是将资产信息拆分成以服务为单位的条目（如：一个IP开了三个服务，就是三条资产信息），存在Redis中，扫描进程启动时会先加载POC库，在逐条获取Redis中的资产信息，完成匹配后开始扫描工作。需要注意的是这类高并发扫描逻辑要考虑被扫描资产的承载能力，尽量把压力分散到不同被扫描设备上，分散方法有很多，比如将POC和资产一一对应后随机进入扫描任务，或者以POC为核心逻辑，POC1下所有IP扫描完成后再扫描POC2等等，总之不要盯着一个IP玩命扫就是了。

这里可以优化的点是：由于我们的扫描节点和控制节点是分开的，所以获取资产信息的时候可以同时获取一组，避免网络延时对效率的影响，这还要看具体数据。

漏洞扫描组件与资产发现组件的配合：我们打破了传统扫描器中资产扫描和漏扫串行的方式，将资产扫描和漏扫异步进行，可以随意调整，基于此我们设计了如下逻辑：

① 资产扫描后针对新增资产进行漏洞扫描，比较特殊的情况是：系统第一次运行所有资产都是新增的，所以第一次漏扫是全网扫描。之后每次资产扫描后，只针对新增资产进行漏扫。重点来了，这个逻辑将循环执行，我们起名叫“永不停歇模式”。

② 根据资产列表中的资产信息，做定期的全资产扫描。这个扫描周期我们设定的是三天。

基本逻辑说完了，解释一下这么做的理由：按经验来说漏洞的高发区域就是新增的资产和服务，所以我们将资产发现和新增资产漏扫的工作执行了“永不停歇模式”。资产信息不变不代表漏洞情况不变，但属于较低概率事件，所以进行周期扫描。这么做的另外一个好处是，执行POC会产生很多系统日志，虽然我们写了一些过滤脚本，但也有很多过滤不完全的系统还是会产生大量垃圾日志。但资产扫描的情况就会好很多，所以周期执行资产扫描，定期执行全网漏洞扫描可以有效减少垃圾日志的产生。

三、漏洞处理

我们日常安全管理的一个很重要的工作就是督促整改，但从笔者了解的情况看，很多企业都遇到过修复漏洞工作推进十分困难的情况，这也直接导致了安全团队与运维和开发团队的对抗情绪。

笔者团队一直致力于让非安全部门更主动的修改漏洞，我们在去年（2017）根据实际情况建设了“漏洞管理平台”，主要实现如下三个层面的能力：

① 便捷：任何产品级系统便捷性都是最基础、最重要的事。所以，驱动业务使用安全部门“平台”的最低要求就是–不能比处理邮件麻烦。这个要点就是前端页面设计和通知手段的多样化。

② 驱动：比便捷更稳妥的方式是让系统有驱动力，驱动力的来源是领导们的关注，这个层面我们是通过数据分析和展示系统给领导看来解决驱动力的问题。

③ 主动：驱动毕竟有一定强制的成分在，所以比驱动更高的一个层次是让运维和开发主动来看，这要求“平台”的内容对运维和开发有吸引力。这个层面的问题我们也在实验中，比如积分制，配合一些精神和物质的奖励等。

具体实现逻辑如下：