信息安全技术日益重要，安全是生命的保障和发展的驱动力。这几天安全圈又有新动作了：2018年9月8日携程安全沙龙在携程上海总部凌空SOHO举行，网络安全专家学者、行业大咖、网络安全从业者、网络安全爱好者共同聚焦网络安全。点融高级安全开发工程师陈越受邀出席了本次讲座，并发表了基于NIDS构建纵深防御体系的演讲，受到了大家对点融信息安全技术的关注与高度认可。

一.我们为什么需要NIDS

▲1.ByPass WAF/FW是有多重情况的,比如大包的绕过,0day,或者诸如SSRF等安全问题的绕过。因此我们不可能完全信任防火墙的防御能力,况且由于防火墙对性能的高要求,也的确在很多方面依赖规则,不可能有更多的扩展性。

▲2.内网的安全需求需要NIDS这样定位的产品,如WAF/FW这些产品对内部的安全威胁往往没有很好的效果,并且对内到外的恶意行为也很难有所感知,如:反弹shell;内鬼的内网行为;边界存在漏洞绕过WAF/FW;C&C通讯等。

▲3.NIDS的视角更加广阔,可以作为安全体系中的重要一环或者数据基础,来实现更多的安全需求。

二.点融的NIDS架构

点融的NIDS架构是目前业界通常的做法:

▲1.流量捕获,从负载节点使用PacketBeat镜像HTTP流量,在核心交换通过Bro镜像内网流量。

▲2.使用Kafka作为数据消息管道。

▲3.NIDS后端使用Python3+Pypy进行编写。

▲4.数据的存储和展示使用ES+Kibana,图数据库使用ArangoDB。

▲5.NIDS主要包含三大主要模块:规则引擎,异常检测模块,资产模块。

三.NIDS的规则引擎

▲1.规则引擎除了常有的正则,多模匹配,频率检测,完全相等等常见的检测之外,还支持外部函数调用。

▲2.外部函数调用即通过在简单的规范下编写的函数可以直接进入规则引擎内被调用,极大的扩展了灵活性。

场景一：通过机器学习训练了DGA模型

无外部函数的使用方法:

通过单独开发相关模块或者单独抽取DNS记录,然后进入单独编写的模块进行DGA检测,结果需要单独处理或者其他处理。

有外部函数的使用方法:

编写调用检测DGA模型的函数,将该函数名在规则引擎中直接写入,即可调用,告警/归档/威胁定级可以完全复用,规则如下:

DGA_CHECK

场景二:威胁情报检测

无外部函数的使用方法:

需要单独开发组建来对接威胁情报的API,需要单独设计数据结构/缓存/存储方案/告警方案等

有外部函数的使用方法:

编写调用威胁情报的函数,将该函数名在规则引擎中直接写入,即可调用,告警/归档/威胁定级可以完全复用,且缓存设计也可以服用NIDS的缓存池和数据结构,无需单独开发,规则如下:

xforce_check_ip

通过自定义外部函数的方法可以快速实现多种需求,快速生效,无需单独开发模块,包含如:统计,快速增加特殊白名单,特殊情况告警,快速简单反爬虫策略部署,快速部署/测试机器学习模型,快速部署测试特殊模块,联动其他产品等等,可以说极大的丰富了规则引擎的功能。

▲3.规则引擎的告警,联动能力高度开放,如我们设计了

标签专门进行告警的下发,可以简单的配置进行向自定义的API下发告警,或邮件通知,阻断等行为。

四.异常检测模块

规则引擎已经可以满足很多安全需求,注入快速增加0day规则,防范已知安全问题,通过特征+行为的方式可以发现很多攻击行为,但是依旧是不足的。甲方安全人员相对较少,并且并非所有的安全问题都可以通过规则来发现,如0day、一些通用型安全问题、不同层面的RCE、SSRF等等。

于是我开始研究其他的方法来发现安全问题,由此开发了第二个通用模块:异常检测模块。

我们先来看一个假设的场景:

假设某公司仅有一个数据库,且仅有一个业务:登陆

那么对于数据库的操作应该仅有:

selectuidfromuserwhereuid =?andpwd =?

那么相关的HTTP请求(提交参数)应该也仅有一个:

{"uid":"123@qq.com","pwd":"123"}

在上面假设的前提下,如果出现了SQL注入行为,那么会出现异常(不常见)的SQL模型:

selectuidfromuserwhereuid =?or?=?andpwd =?

且HTTP的相关参数也会发生变化.

拖库的行为也会出现异常的(不常见)的SQL模型:

select*fromuser

关于SQL的异常检测比较复杂,可以参见我之前的文章:https://mp.weixin.qq.com/s/h-DGDGpvxXaMgLLtQlvajw

到这里异常检测的思路也比较清晰了,即:通过观察流量,发现“大多数”的模式,在“大多数请求不是攻击”的前提下,提炼并生成模型,如果有流量不符合生成的模型,即为异常。

根据上面的思想,对于HTTP协议为例:我们根据当前业务自动进行白名单的生成,以接口为单位,生成接口-参数key-参数模型的白名单模型,白名单生成的算法目前我们使用多种无监督聚类算法和异常点检测算法实现,并针对业务更新迭代专门做了优化和调整。

流程如下:

▲1.Request请求包含参数,且Response Code不为4XX/5XX的请求进入学习阶段。

▲2.进行Path分析(Request Path中经常包含参数,如:/get/12345/name)。

▲3.对Request Params进行解析和Feature计算。

▲4.保存Feature,进行机器学习计算,得到相关模型。

▲5.定期更新模型。

异常检测缺点:

▲1.异常不等于攻击(可以通过设定多次处罚异常再告警降低误报)。

▲2.面对富文本型接口误报/漏报高且难以调整。

▲3.性能问题(但是通过白名单的数据不需要过规则引擎)。

▲4.可解释性差。

▲5.需要一定的数据量进行白名单模型的生成。

异常检测优点:

▲1.可以和黑名单形成互补。

▲2.不仅可以发现攻击行为,也可以帮助甲方梳理自己的业务。

▲3.面对大多数攻击(除逻辑漏洞),漏报极低。

拓展:

▲1.可以适用于多种协议,不仅仅HTTP。

▲2.我们使用异常检测算法对ICMP隐秘通道检测的情况是零漏报。

异常检测Test:

PCA:

五.资产模块

在NIDS的丰富的数据基础上,我们开发了资产模块,主要作用如下:

▲1.实时梳理资产信息:端口,服务,版本。

▲2.实时记录资产间关系:协议,频次,对于部分协议进行全量记录。

▲3.按小时分片,帮助安全事件调查,溯源,分析。

根据资产间通信和规则引擎,可以编写基于行为的规则,如:

▲1.X秒连接X个端口被RST视作端口扫描行为。

▲2.WebServer通过高权限登陆数据库或SSH登陆其他任何主机视为异常(根据信任等级)。

▲3.主动连接外网服务器会进行威胁情报检测。

但是往往我们得到告警,我们信息也有限,我们需要获得更多的信息,这些信息会基于资产模块进行联动:

▲1.联动CMDB,得到IP基本信息和业务信息,如PM/DBA/DevOps等。

▲2.联动FW,获得连接规则。

▲3.联动Nginx配置文件,获得配置信息。

▲4.联动FW白名单,避免误报。

▲5.联动云管理端,获得云资产列表信息。

▲6.部分协议可以关联到人/项目,如:MySQL。

等等

资产模块连接图:

资产数据示例:

连接情况示例:

六：NIDS的不足

Packetbeat/Bro不支持的协议,加密的协议,场景:

▲1.各种反弹shell

▲2.各种后门

信息依旧过少,安全工程师无法准确分析,场景举例:威胁情报半夜3点告警一台服务器连接恶意服务器,此时抓包已经来不及,我们也不知道具体是什么进程/文件的行为,难以判断。

在此基础上我们着手开始进行HIDS的自研,以下是HIDS的部分基本功能:

▲1.轻量级,侵入型小,系统占用小。

▲2.支持与点融自研NIDS联动,实时查询进程/端口占用/文件等信息。

▲3.对登陆/线上操作/关键文件变动记录等信息会记录并同步到Server。

▲4.实现了一小部分可信计算的东西。

▲5.支持各种姿势检测Rootkit。

▲6.支持基线检查。

▲7.规则引擎语法与NIDS相同。

▲8.支持Docker容器的部分信息查询,为后期联动CMDB做数据基础支撑。

▲9.天然支持于点融NIDS联动,联动方式仅仅是在NIDS的规则里增加一个字段。

至此,我们面对的信息不再是割裂的,而是完整的:

{PID和PPID的cmdline;cwd;user;exe+TCP/UDP五元组+部分协议的原始数据+业务相关信息+FW_RULE+NIDS/HIDS规则ID+威胁情报信息+其他联动信息}

即,一个文件的主机信息到防火墙的信息我们全生命周期都可以掌握,在这样的基础上,我们进行告警的判断也好,跨不同维度的规则制定也好,都有足够的数据源的支撑。

从这里可以看到,NIDS已经不仅仅是NIDS,由于原本的规则引擎,异常检测,资产模块的完全共用,无论是N(Network)还是H(Host)都只是一个数据源而已。

七.总结

点融NIDS的发展其实是思维的进化,从一开始的规则(黑名单)到异常检测模块(白名单)到自研HIDS联动(对每一条流量都要有认知能力的需求),突破了NIDS的局限性,也突破了HIDS的局限性,联动能力打破了原来的信息割裂的局面,赋予了我们全新的视角。