点融NIDS实践

(本文来自2018年携程安全沙龙:《基于NIDS构建纵深防御体系》议题)

1.我们为什么需要NIDS

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

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

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

2.点融的NIDS架构

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

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

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

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

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

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

3.NIDS的规则引擎

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

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

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

无外部函数的使用方法:

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

有外部函数的使用方法:

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

1
<dns_query type="CUSTOM">DGA_CHECK</dns_query>

场景二:威胁情报检测

无外部函数的使用方法:

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

有外部函数的使用方法:

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

1
<id.resp_h type="CUSTOM">xforce_check_ip</id.resp_h>

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

3.规则引擎的告警,联动能力高度开放,如我们设计了标签专门进行告警的下发,可以简单的配置进行向自定义的API下发告警,或邮件通知,阻断等行为.

4.异常检测模块

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

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

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

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

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

1
select uid from user where uid = ? and pwd = ?

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

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

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

1
select uid from user where uid = ? or ? = ? and pwd = ?

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

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

1
select * from user

关于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:

image

image

PCA:

image

5.资产模块

在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.

等等

资产模块连接图:

image

资产数据示例: