转载

自助安全扫描与代码审计系统架构实践

*本文作者：糖果L5Q，属于FreeBuf原创奖励计划，未经许可禁止转载

一、自动安检的需求背景

公司如果有不同的业务线，各业务系统上线发布之前要进行基本的安全检查。业务在国内的其它城市，机房位置不定，发布时间不定，这时候就需要设计一套自动化机制，在业务上线新功能之前，进行自动安全扫描与代码审计。自助自动是在传统方式上的一种改变，是对即存安检查系统的重新组合使用。传统的扫描和代码审计有历史课题。对于粗放型的安全扫描任务实施，可能会对业务造成伤害，比如Payload脏数据让业务方服务挂掉，为了避免此类情况发生，需要将扫描的粒度细分的更精准，可以定位到新机能具体接口入口位置，再进行扫描和代码审计。

下图是整个自助安检设计的体系图：

自助安全扫描与代码审计系统架构实践

历史课题

1. 安 全扫描 ：一般安全扫描实施会有一个扫描列表，并且配有白名单和不可扫主机，如果被扫业务代码不够强壮，一旦扫描payload被业务认为是无效的脏数据，服务会受影响。解决此问题，如上所述，需要定制化扫描，针对新业务上线，老业务回归扫描检查，进行细化到接口级的扫描，不是一个域名一把梭。

2. 代码审计 ：代码审计误报率，审计程序和策略都是人来写的，存在误报场景。但自动化安检处理可以突出重点误报率低的问题，对代码审计特别擅长的漏洞，给于突出的展示空间，抓主要问题，核心威胁。当业务方触发自动安全检查流程时，让代码审计与安全扫描强强联合，针对那些不能轻易通过扫描被发现的漏洞，或是非常耗时，依赖设计各种复杂Payload扫描发现漏洞的场景，让扫描和审计协同来完成，比如：挂马问题，代码审计可直接扫描代码发现问题，再联合扫描执行进行多重威胁确认。

二、子系统划分与功能互动

多业务线可复用一个安全请求接口，业务推送各自的安全检查需求，无论你在上海、北京还是其它的地方。对于业务方来说，他们不用关心安检系统的实现细节。但从安全开发者的角度，我们要清楚系统的构成，系统是如何把安全检查请求，分发给我们各种子系统去执行，并优先返回那些必要的安检结果反馈。区别于第一个图，我们通过纵向展开的方式，用一张图表现子系统如何通过暴漏接口与业务互动。大体流程如图，由业务方提交安检请求给接口，由网关将接口转发给安全检查处理逻辑进行安检任务的分发，将代码相关信息，PUSH给代码审计系统。将上线环境的相关的信息，PUSH给扫描系统。扫描系统是可以插件化的，通地不同类别的插件装配，进行定制类扫描。代码审计系统可以进行复合审计，调用多种代码审计引擎进行代码审计，比对审计确认结果，找出共通问题。

自助安全扫描与代码审计系统架构实践为了结合实际情况，我们特别突出了安全扫描中SQL注入和WEB扫描在图上的位置，将通用CVE计与挂马检查作为代码检查的重点。一般情况，检查项目越多，误报同比会变高，如果不想被误报威胁信息淹没，前期我们可以集中处理高危的威胁，等系统问题，针对各种误报针对性解决。

三、接口设计

如图所示，接口设计我们采用了REST接口设计，业务在发布系统侧，通过发布系统客户端，发送POST数据请求给网关的REST接口服务，提交安检所要的基本必要的信息，测试的主题是谁，测试的是什么。我们给出接口字段设计，可以基本满足检查子系统的输入需要，当接口调用时，会添上对应的测试机，后期会直接集中到发布系统里进行自动发布调用。

自助安全扫描与代码审计系统架构实践

字段说明：

域名（domain） ：域名，具体业务那个域名下的服务更新发布了。

文件（file） ：文件，新发布功能的文件名。

路由（index） ：路由，发布文件发布的具体接口。

接口参数（params） : 路由对应实参数。对SQL注入这种类别的检查，有了参数才检查更有针对性。

代码地址（git address） ：上线业务代码git服务器地址，方便代码审计系统去下载代码。

邮件地址（mail） ：接受安全检查报告的邮箱。

接口是基本的JSON REST，具体落地实现可以采取多种语言实现方案。

四、安检流程

我们抽出一个业务处理逻辑，进行强化说明，当业务发起安检提交请求后，如何具体触发子系统做了那些居体工作。数据接口设计完之后系统的输入已经明确，接口驱动系统工作的顺序，如下图。

自助安全扫描与代码审计系统架构实践

1. 代码拉取 ：取得git address字段的地址，分发调用代码审计服务，去具体的git中下载项目代码。其实可以单独通过一个字段让源码推送给的安查系统，但这样有加密成本，并且没有代码下载历史版本管理，如果出现问题，无法溯源代码操作责任人。

2. 代码审计 ：对拉取源码进行审计。更新的码与工程中其它代码是有依赖关系的话，如果时间允许，可审计相关文件模块，甚至整体项目代码。

3. 审计报告 ：作成代码审计报告，安检请求同步发出，但报告可异步发回。

4. 路由解析 ：代码审计系统取得代码后，对源代码进行词法语法分析，再做路由检查处理，取得具体路由的params参数。一般情况，路由的对应的参数是需要人工添加的，但对一些找不到第一开发者的项目，采用自动匹配的方式收集对应参数，这种情况需要特别处理。

5. 接口扫描 ：对已取得的域名、路由、参数的接口进行针对性的WEB安全性检查，扫描的模块往往都是有很多种的，对同一接口，可采用多种扫描工具进行扫描，sqlmap、nmap、WVS、nessus等。如果想收集更多的信息，可采用代理方式进行扫描，在代理服务器上，可以收集更多信息。

6. 扫描报告 ：输出扫描检查报告。扫描的结果可入库，通过库内容对比，进行接口威胁状态跟踪。

五、子系统与实现技术栈

自助安检需多统协同：

1. 发布系统客户端服务 ：嵌入到业务发布上线系统中的，安全检查请求客户端。可以是表单，也可是后端批处理程序。

2. 网关服务 ：网关一般是请求的分发与重定向，简单是直接用Openresty写，复杂的可以使用Kong，活是orange这种网关产品。

3. 接口服务 ：具体实现REST接口的后端程序，也是安查任务调度系统。

4. 扫描系统 ：接受调度，进行安全检查，返回扫描报告。

5. 代码审计系统 ：接受调度，进行代码审计，返回扫描报告。

6. 存储系统 ：保存安全检查请求历史数据，跟踪检测结果。

通过安全开发实践摸索，我们总结出安全开发三件宝：网关、数据库、RPC。

1. 网关服务 ：网关应用作为后端应用的入口，负责转发与授权等基本工作内容，网关本身也是代理。网关是抽离业务抽象出来与7层操作直接相关的公通模块，将公通的功能，从业务中独立出来，降低业务代码维护成本，网关代码还可重用。

关于中间件推荐，一般情况推荐给读者商业产品，读者及单位不一定买，发出来还有广告嫌疑。推荐闭源产品，代码不开放有版权也不能直接给您，所有最后推荐开源产品原型，但又可能被说都是用开源堆砌系统。

推荐几款开源的网关：

OpenResty : Openresty在Nginx的基础上丰富了很多功能，构建网关OR是不错的选择。

Kong : kong本身也是基于Openresty技术，现在很多大的公司在用。

Orange ：同样基于Openresty的一个纯开源的网关产品，内嵌基础WAF功能。

假设读者手里有SAE的云豆，可以体验云版的Orange ，一键部署，方便测试，想要测试码朋友，可以看文章最后的二维码联系方式联系免费提供。软件是开源的，服务是免费，要有云豆。

2. 数据库 ：数据存储是最基础的服务，现在都支持接口化服务，我们通过网关将数据库存储通过接口封装隐藏起来，使用者不用关心具体实现的技术差异。对于调用都来说，数据是存ES还是其它地方不重要，只要性能达标没有瓶颈不关注低层实现。在我们的场景下，ES存一般性数据，Clickhouse存实时性高的数据，RabbitMQ和kafka进行数据缓存，Redis存共享数据。

如果有什么值得特别提的，那就是Clickhouse可以支持Mysql协议，操作CK与操作Mysql体验接近一些，用操作Mysql的动作，实际确是在用强大的ClickHouse做处理数据， CK属于开源产品。关于ES与Clickhouse之间的数据迁移，有一篇文章可供参考：《Clickhouse与威胁日志分析》，是在Freebuf上发布过的。还有一篇《ELK大数据与威胁日志的数据迁徙方法》，让Clickhouse与ES共生，提供安全分析服务。

3. RPC服务： 如果REST是给前端提供的后端服务，那RPC就是给后端服务提供服务的后端服务。把业务不想关的公通功能RPC化Docker部署，业务相关的DSL配置描述化部署，简化业务系统的复杂性和不必要的耦合。无论使用什么语言实现rpc服务，对调用方来说是黑盒，只要遵循协议要求。

大家用的RPC技术Google的产品占一定比例，但其实像Django这种框架也支持RPC技术， Django RPC ，这个版本在Django 1.5时代已存在。

自助安全扫描与代码审计系统架构实践