一、NIDS阻断功能描述
NIDS阻断功能按发生阶段,可以分为事中阻断和事后阻断两种,目前事后阻断主要方式防火墙/EDR联动等,即NIDS判断威胁发生后,向防火墙等联动设备发送阻断规则,防止攻击行为继续破坏。事中阻断主要是TCP Reset报文阻断、DNS劫持等,直接对攻击行为进行阻断。
二、事后阻断
事后阻断当前业界厂商主要实现方式就是防火墙联动。以笔者以前在奇X信的莫新一代威胁感知系统为例,在其分析平台侧,防火墙联动作为一种关键的事件响应处置能力引入,对接了各个厂商的防火墙。可能是做的比较重,感觉不是很好用。在HW期间访问客户现场时,某部委值守安服人员,为了减轻夜间值守负担,将NIDS传感器告警以syslog形式发送到安服的个人电脑,电脑上跑python程序分析告警,以告警级别、类型、次数等综合条件,通过API调用防火墙的联动功能,灵活自主,方便维护,节约了夜间的人力负担。
结合上面这个案例,说明防火墙联动这种事后阻断方式还是比较有用的,但是厂商提供的一些联动配置,做到完全开箱即用比较难。总计起来有如下缺点:
1、联动协议问题
现在联动得实现是以现有得某个厂家为核心,其他厂家的产品在一些有限API的支持下实现与核心厂家的某个产品实现互联。这样导致现有和多产品有联动功能,但是没有联动得实际效果。
2、联动生效的滞后
即使产品与防火墙有了优良的联动相应方式,IDS产品在检测得过程中发现了非法得连接,生成一条临时规则发送到防火墙,防火墙应用这条规则阻断这个连接,这个过程存在较大延时。这个延时如果太大,事后阻断的效果就大打折扣,而且这个过程当中IDS的检测是滞后IDS检测到非法连接时,这个连接已经建立了,如果这个连接是蠕虫或木马,足够成功攻击了。
3、联动条件的可配置性
如果是单一条件,以NIDS海量告警和较高误报率的产品形态,估计没有几个客户现场敢敢配置联动功能。如果根据级别、类型、次数等组合条件来配置,大部分厂商的可配置选项又缺少一定灵活性。就容易出现还不如安服人员自己写脚本来调用API的情况。
三、事中阻断
事中阻断即在攻击行为发生时,掐断攻击行为的阻断方式。因为这种阻断方式主要靠NIDS设备伪造报文从旁路发送给会话两端,所以一般叫旁路阻断。以笔者过往厂商实现经验主要有如下两种:
1、DNS劫持
这种原理比较简单,如果客户网内用户访问命中了IOC中域名类型的威胁情报或者黑名单域名,可以在伪造DNS响应报文,将其对恶意域名的访问引导到安全域名。
2、伪造TCP Reset报文掐断会话
NIDS分析到需要阻断的连接时,根据syn+ack序号,双向伪造Reset报文,发送给客户端和服务端,确保客户端与服务端的原有会话无法保持。这种阻断方式当前旁路阻断的通用办法,9012年了,还在有厂商用这个编专利,下面我们详细介绍一下。
四、TCP Reset阻断的注意事项
1、进化历程
1)NIDS时代
笔者在安全厂商启明X辰工作时,NIDS引擎已经具有旁路阻断功能了,旁路阻断作为可选的告警处置方式,工作在规则集配置上。那是2010年代以前的产品,用raw socket的方式实现,当时NIDS还没有进化成NDR,NIDS作为一个合规类产品,主要用于年终出报表。这个亮点功能主要是用于竞标时增加加分项屏蔽对手,在公司待了好几年听说有用户使用过这个功能,公司内部QA也从给这个功能报过BUG。
2)NDR时代
笔者在安全厂商奇X信时,独立承担了NIDS引擎的旁路阻断功能开发。当时还没和360分家,作为一家互联网公司,偏向使用开源软件,就找到了libnet来实现旁路阻断。功能上不再基于告警阻断,以IP+端口的四元组的方式,配置阻断规则。阻断规则类似ACL规则,一旦发现命中规则的syn报文,即可触发阻断。实现简单,测试方便,而且阻断规则的合理与否取决于客户配置。
3)实用性时代
到2019年的时候,TX出了一个叫天幕的专门做旁路阻断的产品。其部署在南北向的上层节点,主打大流量和旁路部署不影响业务。可以理解成一个高吞吐的旁路防火墙。
互联网公司的入场像鲶鱼激发了各厂商对旁路阻断的热情,当年就称为热点。当年笔者在奇X信就开始主导高级旁路阻断功能的开发,主要功能点有两方面:
-
应用层旁路阻断。根据应用层特征触发旁路阻断,主要实现了HTTP的Host、Uri等信息。
-
告警旁路阻断。告警触发旁路阻断,主打实效性,构造恶意参数的访问能在浏览器上看到访问被重置,后门连接能直接掐断。
2、使用难点
2019年底,功能刚编码完成,就有个某宇宙第一银行的的旁路阻断项目要上。在使用路由器、NIDS引擎、笔记本电脑搭建演示环境上,客户对这个告警旁路阻断的功能,比较满意,准备版本发布完成后,在客户环境上线。功能上线需要IT部门重度参与,考虑到旁路阻断的危险性,又引入了线下环境来实验。直到笔者从奇X信离职一年多,这个功能都没有上线。IT部门参与后,才发现了上线可能会遇到的很多问题,总结如下:
1)三层可达性
很多流量是通过TAP设备牵引过来的,不是直接从核心交换机上镜像的。镜像流量的来源和NIDS引擎所在位置往往不在同一个机房,伪造的TCP Reset报文从NIDS引擎管理口出来后,能否通过经过三层的路由转发,找到流量上对应的客户端和服务端,非常存疑。IT部门不可能为NIDS这一个产品调整整个公司的网络架构的,甚至不能回答是否路由是否可达的问题,因为IT部门也不是一个人,没有来自上级的追问,配合度成疑。后来客户(该行安全部门)提出先在流量和NIDS引擎同一个机房的试上线。
2)对网络的破坏
这是IT部门对旁路阻断上线的主要质疑点,担心会产生数据环路。从我们开发角度看,考虑的都是数据平面的,站在IT部门角度,还要考虑控制平面。
3)负载均衡场景
现在大公司对外服务,都是有负载均衡的,一般前面的四层负载均衡设备根据IP地址对请求负载和内外IP地址转换,后面的七层负载均衡设备根据url等应用层信息对请求负载。还有F5这样的设备,代理了SSL加解密功能,后端的服务只需要支持HTTP就行。这种场景增加了网络情况的复杂性,从负载均衡前段、中段、后段等不同位置接入的镜像流量,根据这些流量构造Reset报文后,从NIDS引擎发送出去的时候,经常至少客户端或者服务端有一端是不可达的。因为不管是代理或反向代理,这种报文肯定会丢弃。