NIDS阻断功能研究

一、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引擎发送出去的时候，经常至少客户端或者服务端有一端是不可达的。因为不管是代理或反向代理，这种报文肯定会丢弃。