<bdo id="2b3yk"><code id="2b3yk"></code></bdo>

  • <output id="2b3yk"><sup id="2b3yk"></sup></output>
    <output id="2b3yk"><ruby id="2b3yk"></ruby></output>
  • <code id="2b3yk"><delect id="2b3yk"></delect></code>

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

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

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

    一、自动安检的需求背景

    需求

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

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

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

    历?#25151;?#39064;

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

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

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

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

    1.png为了结合实?#26159;?#20917;,我们特别突出了安全扫描中SQL注入和WEB扫描在图?#31995;?#20301;置,将通用CVE计与挂马检查作为代码检查的重点。一般情况,检查项目越多,误报同比会变高,如果不想被误报威胁信息淹没,前期我们可以集?#20889;?#29702;高危的威胁,等系统问题,针对各种误报针对性解决。

    三、接口设计

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

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

    字段说明:

    域名(domain): 域名,具体业务那个域名下的服务更新发布了。

    文件(file):文件,新发布功能的文件名。

    路由(index):路由,发布文件发布的具体接口。

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

    代码地址(git address):上线业务代码git服务器地址,?#22870;?#20195;码审计系统去下载代码。

    邮件地址(mail)?#33322;?#21463;安全检查报告的邮箱。

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

    四、安检流程

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

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

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

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

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

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

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

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

    五、子系统与实现技术栈

    自助安检需多统协同:

    1.发布系统客户端服务:?#24230;?#21040;业务发布上线系统中的,安全检查请求客户端。可以是表单,也可是后端批处理程序。

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

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

    4.扫描系统?#33322;?#21463;调度,进行安全检查,返回扫描报告。

    5.代码审计系统?#33322;?#21463;调度,进行代码审计,返回扫描报告。

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

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

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

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

    推荐几款开源的网关:

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

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

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

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

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

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

    3.RPC服务:如果REST是给前端提供的后端服务, 那RPC就是给后端服务提供服务的后端服务。把业务不想关的公通功能RPC化Docker部署,业务相关的DSL配置描述化部署,简化业务系统的复?#26377;?#21644;不必要的耦合。无论使用什?#20174;?#35328;实现rpc服务,对调用方?#27492;?#26159;黑盒,只要遵循协议要求。

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

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

    六、总结

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

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

    发表评论

    已有 16 条评论

    取消
    Loading...
  • 3月

    四月去挖洞,五月出国游
    进行中
  • 3月 成都

    漏洞盒子高校V计划 成都站
    已结束
  • css.php 宁夏卫视在线直播观看