拥抱DevOps-“洞犀”高危服务扫描方案

作者：【腾讯安全平台部】ksss

对互联网开放的高危服务引发数据泄漏、赎金勒索以及恶意公关类安全事件多年来一直屡见不鲜，这些事件往往性质恶劣而且后果严重。数据和服务器安全是互联网企业的生命线，高危服务漏洞像一把锋利的匕首，随时可能撕破防御，直接威胁企业核心资产的安全。

建设有效的端口保障体系，让网络资产免因高危服务受到侵害是企业安全建设的重要课题。高危服务扫描通过对端口进行连接和探测完成对风险的评估，是一种直观有效的网络风险发现手段。大型互联网企业服务器量级大，各种发布变更频繁。在复杂的场景下，及时、准确发现收敛高危服务风险，是扫描体系建设的重点和难点。

为了应对以上风险和挑战，腾讯自研了“洞犀”漏洞检测系统，其中就包含了高危服务检测。

2019年，随着DevOps的推展演进和研发效能的全面提升，“洞犀”的高危服务扫描系统对自身的透明、可控和自动化程度等多方面提出了更高要求，进行了全面升级重构，文章记录系统在这一年在自我革新过程中的一些思考和变化。

“洞犀”高危服务扫描系统Tencent Insign PortScan System，简称TPSS，属于腾讯自研漏洞扫描系统“洞犀”的子系统之一。“洞犀”漏洞扫描系统以海量的漏洞信息和完备的情报感知为支撑，与各种攻击力量在一线较量中不断打磨和进化自身，从2005年至今已历十五年。历史情况可参见文章《自研之路：腾讯漏洞扫描系统的十年历程》：https://security.tencent.com/index.php/blog/msg/100

设计初衷，TPSS对自身定位为：通过扫描测试，掌握公司服务器的端口和服务状态，发现并收敛高危服务风险。这个定位贯穿系统建设的各个细节：首先，高危服务扫描是公司的内部安全保障机制，需建立在不影响公司线上服务的稳定运行的前提下。这要求系统使用无攻击危害的探测包，并在与业务部门相互认可的速度内平稳长效运行。其次，扫描需要尽可能快速和准确，有效掌握服务器状态和收敛风险。实战场景中，快速和准确通常难以两全，而稳定的速度阈值更是束缚了追求快速的翅膀，在种种对立中找到平衡点，建立高危服务检测机制的最佳实践是我们十余年不断探索的课题。

2016年，“洞犀”高危服务扫描系统经过大版本重构，进入了TPSS v2.0时代。2.0扫描体系的架构示意图如图1.1所示，由基础数据层、描层和应急响应层三部分组成。

图1.1 高危服务扫描体系架构示意图

基础数据层是风险检测的基石，由企业的IP资产信息，网络拓扑关系等，辅以HIDS数据、流量分析数据等其他安全系统提供的辅助数据，共同组成风险发现的大盘数据。扫描层是风险发现的核心，扫描层由各种不同的风险检测分支组成。应急响应层是扫描体系效能的保障，对风险进行处置完成闭环。

TPSS v2.0时代，我们在扫描层拆解和建设了各种扫描分支来收敛不同场景的风险。架构图摘取了三个为高危服务风险收敛立下赫赫战功的分支“全端口扫描”、“分级扫描”和“HIDS联动扫描”示意。“全端口扫描”是TPSS v2.0系统建设的第一分支，在体系内承担风险兜底检测的功能，扫描结果也作为资产管理、进一步的安全评估如Web漏洞检测，风险溯源等方面的关键数据支持。

“分级扫描”为了对抗严重威胁系统和数据安全和可蠕虫扩散恶化的服务风险而建立。模块为速度而生，力求通过发送最少的包先行发现和收敛最严重风险。 “分级扫描”让TPPS对危害等级为严重的服务风险拥有了秒级打击能力。这个能力在18-19年与同具备秒级杀伤的高危服务蠕虫病毒对抗中取得了良好战果。被动式扫描模块“HIDS联动扫描”由TPSS与腾讯“洋葱”服务器安全系统协作建成，建设重点为通过根据服务器系统中端口和服务状态等HIDS数据辅助，准确完成风险检测。“全端口扫描”追求的全面和稳定、“分级扫描”追求的速度、“HIDS联动扫描”追求的准确这些方面体现了TPSS v2.0扫描层各取所长、分工协作的建设思路。系统每年有效收敛若干起高危服务对外事件，极大的保障了公司网络资产安全。

2019年，随着公司DevOps的推展演进和研发效能全面提升，“洞犀”对高危服务风险收敛提出了更高的要求。更加敏捷高效而快速变化的系统环境，要求对应的安全系统能力更强大、过程更透明、拓展更自由，同时要求系统自身检测策略升级和迭代更加敏捷自动。2019年底，洞犀高危服务扫描进行了一次 “立足现在，畅想未来”的大版本重构，进入TPSS v3.0时代。

TPPS v3.0提升主要体现在架构升级和能力升级两个方面，包括优化代码架构适用于DevOps和开源协同，以及对服务检测模块进行重构和拓展，提升高危服务识别准确性和可拓展性。

TPSS v3.0将高危服务漏洞风险收敛战场的十八般武艺整合为一，对扫描层诸多分支系统取其意而弃其形，统一为3.0虚拟化架构。新架构的系统由容器化的Portscan Server和可自动扩容的若干个Portscan Agent两部分组成。

图2.1 TPSS v3.0架构变化

TPPS v3.0通过自动部署程序可以实现 “全端口扫描”、“分级扫描”、“HIDS联动扫描”检测形态展开，同时也可以通过自动部署程序实现自由切换。具体操作和实现细节将在3.1章节“检测形态快速变化”中进行详细介绍。

  2.2.1 使用令牌桶算法优化并发模式下限速  

TPSS v3.0是可自动快速扩容Portscan Agent的架构中，我们对限速算法进行了升级。使用基于令牌桶算法的限速器调度发包，全面消除了原架构中超出速度阈值的毛刺。令牌桶算法如下图所示：

图2.2 令牌桶算法

指定大小固定的令牌桶，按照恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满。后面再产生的令牌就会从桶中溢出。最后桶中可以保存的最大令牌数永远不会超过桶的大小，Portscan_Agent通过这个取令牌的方式限制扫描速度。

图2.3 Portscan_agent调度流程

 2.2.2规则命中竞争逻辑  

TPSS v2.0中，服务识别的所有探测包是无序并行发送的，为了优化对服务的识别速度，在2.0系统参考业界开源系统nmap制定了一些基于端口号的探针挑选逻辑。

这部分探针挑选逻辑位于高危服务识别引擎的底层，使识别探针的服务指纹的拓展中无法良好的控制发包引擎，也引发了对高危服务监听在非默认端口的误报。重构的TPSS v3.0中将硬编码的探针筛选逻辑迁移到配置文件conf.yml的prob_map参数中，并剔除了代码中为优化速度制定的全部探针挑选逻辑。（部署系统时可以根据需要清除注释激活这部分探针筛选逻辑，图为conf.yml示例。）

图2.4 配置文件探针筛选参数prob_map配置

当前发送流程为：首先发送空探针获取服务banner，进行第一轮服务识别，然后速度阈值发送探针获取服务响应。当同一轮的探针的指纹同时命中时，以序号指纹在文件中的顺序，选取序号的小结果。上述两点改造让服务识别程序对检测规则完全透明可配置，为开源协同塑造基础。

图2.5 服务指纹序号

  2.2.3 提升SSL服务识别的可控性  

SSL服务存在“SSL”握手环节，因此耗时比非SSL请求要长很多。TPSS v2.0中为了优化对基于SSL协议的探针速度，对所有以SSL模式发送的探针不进行限速。在新版本改造中，我们使用令牌桶算法重构了这部分逻辑，优化流程使SSL服务识别更加准确。

图2.6 SSL探针加载流程

  2.2.4 基于GO的扫描引擎提升速度和稳定性  

我们使用Golang重构了发包器，利用Go高性能并发的特性，提升扫描速度和稳定性。创建Goroutine资源消耗非常小，以此实现海量并发。SSL核心发包代码样例如图2.7所示：

图2.7 SSL发包代码demo

  2.2.5 增加风险检测能力  

在原有的服务指纹识别的基础上，TPSS v3.0增加了PocScan的服务风险检测。服务风险检测通过风险剧本实现，在PocScan模式下，扫描Agent根据端口查询配置文件conf.yml中的poc_map，获得需要载入的风险剧本检测服务是否存在已知风险。

剧本通过yaml编写，$符是剧本配置文件的占位符，如$0代表将第1个模块的执行结果赋值为这个位置，在风险检测剧本中需要使用\$进行转义。TPSS v3.0预置了超过50种严重服务风险识别能力。

图2.8 自定义风险剧本示例

此外剧本支持以图2.9中poc_example2的形式载入自定义元件如my_ownaction_0day，这个检测函数的实体如图2.9所示。更多具体拓展方法将会在章节3.3”风险剧本拓展”进行演示。

图2.9 自定义风险检测函数

洞犀漏洞检测系统在今年1月内部开源，就是希望依托公司的“开源协同”战略借力公司内部的安全力量为洞犀提供插件，快速提升策略能力。当然，在合适的机会可能也会以开源社区的形式与大家见面。在TPSS v3.0的全面升级中，我们进行了多项改造使系统能够更加流畅的进行协同。

3.1将会简单介绍新架构应对不同风险的扫描形态变换方法。后面两个小节进一步介绍如何在协同工作中，共同建设的指纹和风险检测剧本方法。

TPSS v3.0的自动部署程序中保留了“全端口扫描”、“分级扫描”和“HIDS扫描”三种扫描形态的展开。自动部署程序通过调整配置文件参数实现不同扫描形态的自由切换。熟悉框架后，开发者和使用者也可以手动修改一些关键位置的参数来配置一些出定制化的扫描展开。图3.1中可以看到运行制动部署程序将系统从“全端口扫描”切换“分级扫描”时配置文件的变化，扫描范围从1-65535转为为只扫描一个端口27017，并对27017端口只发送一个指定的指纹探针。

图3.1 “全端口扫描”到“分级扫描”切换

在零日漏洞或蠕虫病毒的爆发时间点，我们需要以最快的速度，在最短的时间内对指定服务是否存在风险进行进行检测监控。比蠕虫快可能很难有感性认识，历史上我们捕获到最快的蠕虫在服务器启动后46s就完成了入侵。在2019年重构前，洞犀的分级扫描模块已经具备了百万IP场景与蠕虫对抗的秒级发现能力，在TPSS v3.0中我们也可以轻松通过部署程序展开为这种扫描形态。

TPSS拥有15年高危服务漏洞对抗的自我积淀检测策略基础，同时汲取了业界开源应用的优秀指纹，组成了全面而丰富的公共服务和私有协议的指纹库。TPSS v3.0对服务指纹的表达和拓展方法也进行全面重构，以便更好的进行开源协同。服务指纹以YAML格式表达，关键参数包含qcontent的探针内容和mcontent的回包特征，如下图所示。

图3.2 服务识别指纹文件

在新架构下，我们仅需要在指定目录下保存按照开发文档编写指引编写的指纹文件，就能让服务扫描加载上拓展的指纹进行服务识别。图3.3示例指纹demo对应的靶场程序也会同样开放给开发者。简单阅读指纹文件，我们可以发现服务特征是对handshark将会回复handshark完成握手，下图是模拟这个简单协议的TCP server demo。

图3.3 自定义协议TCP服务靶场demo程序

保存图3.2里的yaml指纹后，服务运行效果如图3.4所示。开发者可以自由方便的优化已有和拓展更多的公共指纹，同时使用者也可以配置这样的用于管理私有协议特别是UDP私有协议端口。 

图3.4 TPSS通过自定义指纹识别服务结果

高危服务扫描框架以组合元件形式定义风险检测playbook（剧本）。剧本通过yaml编写，将各个元件组合起来，形成一个完整的检测动作。

当前系统内建元件共有三类：协议、断言、和自定义，各个元件运行结果存储在变量序列中，通过变量作为纽带互相联结组成各种各样的结构。开发者可以通过merge request将自定义元件成为内建元件，给更多的开发者使用。

3.5 TPSS风险检测剧本

如图风险检测示例剧本（简化）所示，检测风险使用了内建协议元件xy_socket和内建断言元件dy_assert_rgx组成。完整的运行过程为，扫描任务查找poc_map载入指定风险检测剧本内容, xy_socket发送指定的请求后获得响应包传递给dy_assert_rgx，然后判断响应包是否命中rgx参数中的正则表达式，如果命中则返回bugname表示风险成立。

当前在平台上预置了直接在pocmap调用的超过50重严重风险服务识别剧本。建设更多的风险识别poc，以知名Exploit开源框架的一个poc作为示例（隐去部分信息）。

图3.6 开源poc实例

通过简单分析可以得出poc包含有check和exploit两部分逻辑，check部分发送了指定请求包，如果回包没有命中特征则结束，如果命中则进入exploit环节调用两个module。平移到TPSS v3.0的风险检测剧本中如图所示，剧本执行了check部分相同，在exploit部分中剔除了module中的有害输入，执行了命令将一串特征字符发送给检测中心的服务器。

图3.7 开源POC平移为TPSS风险检测剧本

开发者通过$变量赋值将各种内建元件镶嵌组合成各种复杂漏洞检测剧本，同时也预留了发挥空间让编写出自己需要的复杂元件。让漏洞检测程序的编写就像搭建乐高积木一般简单而有乐趣。

TPSS v3.0充分思考在DevOps高效合作与快速迭代场景，对系统的部署和迭代进行了全面优化。同时增加了以流水线插件的服务形式，快速为流水线赋予高危服务管控能力。

TPSS v3.0支持各种主流的容器化自动部署，包括kubernetes 、docker等，当然也支持使用Tencent Kubernetes Engine（TKE）完成。为了模拟一般研究测试的开发者的部署场景，在文章中演示docker部署方式。

图4.1 部署文档PortScanServer的Docker启动方法

图4.2 Portscan Server在容器中启动

如果我们需要5个扫描agent，那么按照图来五遍就完成了。为了直观，笔者从自动部署程序中摘取出一条命令执行了一次进行效果截图。实际的部署中，你只需要通过参数告诉自动部署程序想要多大规模的扫描集群。

在通过参数告诉自动部署程序我们需要以哪种扫描形态展开，可以快速搭建预想场景的高危服务扫描系统。

此外，TPSS v3.0也支持通过流水线进行快速部署和横向扩容，开发者也可以通过我们预置的流水线，对 “洞犀”高危服务扫描系统进行CI/CD操作。安全策略维护人员在编写好风险检测剧本后，仅需对自己仓库要一条git 更新请求，流水线就会自动完成预设任务，输出检测报告。

“洞犀”DevSecOps组件，除白盒代码审计、IAST等等研发漏洞发现能力赋能外，在赋能运维漏洞发现能力的安全规范监控部分，可以赋予加载了组件的流水线高危服务检控能力。

运行场景如下：Devops流水线在进行持续交付过程中，“洞犀”组件识别到本次发布行为引入了一个可被外部访问的高危服务，则通过质量红线终止本次发布行为。在发出预警的同时，生成报告详情和调整建议。如果发布行为没有引入高危服务相关漏洞，开发、运维、测试等流水线的参与者将对高危服务检测的整个过程中拥有无感知安全体验。组件通过质量红线预警如图4.3所示。

图4.3 DevOps流水线中高危服务检测组件运行

高危服务扫描是企业端口安全的最直观的外层防线，肩负掌握企业服务器资产状态和发现高危服务风险使命，是企业安全体系建设的重要环节。安全是处于长期动态发展的过程，保持敬畏和进步才能在攻防中争取到主动。“洞犀”高危服务扫描将在企业服务风险收敛最佳实践上不断探索和前进，也期待和诸位读者共同建设高危服务管控生态的一天。

安全是一个整体，强大的反入侵、TSRC、蓝军等等兄弟团队为“洞犀”、“门神”和“金刚”系统能力优化提供了非常宝贵的信息支持和帮助，向战友们致敬。

笔拙表述不当或存在错误之处，欢迎交流指正，也欢迎志同道合的伙伴们加入腾讯安全平台大家庭。最后，感谢harite、tututu、sharpen和heine在成文过程中提供的帮助和建议。

我们是TSRC

互联网安全的守护者

用户数据安全的保卫者

我们找漏洞、查入侵、防攻击

与安全行业精英携手共建互联网生态安全

期待正能量的你与我们结盟！

微信号：tsrc_team