被动漏扫系统实践

做被动漏扫也有很长一段时间了,期间自用的版本和企业公用的版本,各单独起分支做持续迭代。目前市面上优秀的轮子已经不少,所以这里只简单讲讲企业内部漏扫设计的思路。

被动漏扫全景图

流量来源

在平时的漏扫使用中,代理流量来源大概有这么几个:

Browser_Plugin

主要代表有chrome插件,对测试环境进行访问时,会把PC端流量传输到流量center。

类Burp插件

在进行测试的过程中,我们需要设置多层代理。

将通过类burp软件的流量,通过代理agent中转,再传输到流量center。

Nids

针对节点主机部署agent,包含蜜罐、节点网关等等,通过流量收集转发到流量center。

Ngnix

在ngnix代理层面,通过镜像旁路流量收集,转发到流量center。

最后,我们在流量center处理流量格式后,再经过中间件(kafka),传输到数据库es存储起来,这样既可以用于被动漏扫进行流量复刻,也可以用于后面kibana(或者二改的)前端进行查询。

扫描调度

在我们覆盖到足够多的流量后,会通过任务调度对存储的流量进行fuzz,这里先假一些基础条件:

强制线下环境

如果是线上流量测试,敏感线上接口需要打标签和加白名单,也会涉及https和qps控制速率的问题,比较麻烦。

token或者session池

除非线下环境本身设置的是登录态能够长期保持的,我们需要单独维护一套token或者session池,通过不同业务线和权限级别分类,方便在测试时做对比替换。

线下环境保持稳定

由于公用的资源有限,在测试完毕后,质量人员一般会把资源给下掉,这样时间一长我们收集到的流量会失效。

做好准备工作,我们就可以进行扫描调度了,我们这里采用的是下发任务给多个扫描agent的方式。任务会存在中间件redis管道里,等待各个agent读取之后,然发送fuzz请求包。

这样虽然扫描进度不一样,但是配置和命令是统一在控制台下发的。保障在启动扫描时各方的统一可控,出现问题也能及时关停止损。

在扫描完成后,我们会把结果传输到数据库中台,再通过人工review进行确认,但这属于漏洞sdl闭环的事儿,这里就不多提了。

漏扫模块

漏扫模块的话,我们主要考虑检测下面几个方面:

OWASP TOP 10

对于常规漏洞的检测是需要的,涉及一些延时的漏洞(比如前端渲染、ssrf),我们主要依靠第三方平台比如类ceye的内网版本,通过标签的形式进行延时漏洞确认。

OWASP API TOP 10

其实自动化只能覆盖部分检测,还有部分需要人工辅助评估。

只能说api检测这块儿,我们可以做的探索还比较多。

POC探测

主要针对可能出现的服务和cms类漏洞进行poc探测,对主动扫描能力进行补充。

很明显,部分poc通过流量复刻进行fuzz,会比主动扫描准确的多。

FUZZ检测

这块儿的话,是我们根据安全团队的测试经验和业务方的特性,进行fuzz字典定制的,主要用于发现一些意外绕过和泄露的情况。

我们使用流量复刻的手段进行fuzz,能在权限认证可控的情况下,针对正常的返回进行对比,去除掉一些误报,提升检测的准确性。