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

2019-04-11 128848人围观 ,发现 16 个不明物体 企业安全

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

一、自动安检的需求背景

需求

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

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

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

历史课题

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

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

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

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

1.png为了结合实际情况,我们特别突出了安全扫描中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时代已存在。

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

六、总结

梳理了自助接口扫描与代码审计系统架构,描述了各个子系统间的协调互动与具体技术栈。对有类似应用场景的单位,通过类似机制实现自动安检只待时日,使用开源、商业、自研技术,可就地取材。这篇抛砖引玉,一些挑战的课题还在等待我们解决, 比如路由参数的自动识别,代理扫描工具的实现方案,代码审计如何开放调度接口等。

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

发表评论

已有 16 条评论

取消
Loading...
css.php