基于流量的网络入侵检测系统实践若干问题分析与思考

网络入侵检测在发展过程中，主要有两大流派：基于日志的入侵检测和基于流量的入侵检测。但因为基于日志的入侵检测的数据源来自各系统的运行日志，日志格式多种多样，标准化程度低，日志记录内容的详尽程度也千差万别，所以基于日志的入侵检测产品很难实现标准化。因此，各家安全厂商一般都是主打基于流量的入侵检测产品，笔者就针对此类检测产品，聊一聊部署实践中出现的各类问题。

一、流量检测产品选型

经过多年的发展，基于流量的网络安全入侵检测可能是目前安全厂商设备型号最多的安全类产品，各安全厂商的命名方式、归类方式也存在一些差别，导致了基于流量的网络入侵检测设备琳琅满目，让人眼花缭乱。笔者结合甲方企业的具体需求和乙方企业的产品目录，将各类产品大概归类为以下8类：防DDoS检测、IDS/IPS、应用防火墙（WAF）、WebIDS、APT检测、威胁情报检测、态势感知、全流量深度分析。下面笔者就将分别说说各类产品的特点以及注意事项，供大家选型时参考。

防DDoS：可以用来对网络中SYN_Flood、ACK_Flood、HTTP_GET等分布式拒绝服务攻击流量进行检测和清洗，一般部署在互联网接入区最外层。但是从实际部署使用情况来看，笔者认为大多数企业在本地部署防DDoS设备作用基本无效果。主要原因有：一是超大流量防不住。超大流量的DDoS攻击流量真的到达企业数据中心出口，几百兆的出口带宽已经处于拥塞状态，防DDoS设备进行本地清洗很难起效果。2019年初，著名的黑客组织“匿名者”扬言要DDoS攻击中国上百个银行网络，其后，某大型银行果真在几天内承受了超过数十G流量的攻击，在防御过程中，边界防DoS设备的功效微乎其微。二是普通流量不用防。随着服务器性能提升以及负载均衡等技术应用，业务服务器本身也具备抵抗普通的DDoS攻击流量的能力。三是平时存在误杀正常业务的风险。虽然很多防DDoS设备都标称自己具备智能检测、精准识别等检测能力，但是实际应用中很多企业还是基于阈值进行判定，这就导致了在瞬时业务突发期（如促销、抢购等）误拦正常业务流量。因此，笔者认为防DDoS检测在实际应用中主要作用在于满足合规要求。

IDS/IPS：笔者认为IDS可以称作为基于流量的入侵检测的祖师爷，一度被认为是保护网络安全的三剑客之一，它主要基于攻击特征或基于异常行为等规则检测流量中的攻击行为。一般认为IDS是工作在TCP/IP协议模型中4层，能够实现对端口扫描攻击、木马后门、蠕虫、拒绝服务攻击、缓冲溢出攻击等的攻击检测，但是，随着技术的发展，笔者发现很多IDS也能够实现对SQL注入攻击、CGI访问攻击、IIS服务器攻击以及其他违规行为进行实时检测告警，从中可见，这里面也包括很多应用层面攻击检测，但是从实际检测效果来看，这个应用层检测能力也就是聊胜于无。IPS是IDS向防火墙拦截功能的延伸，以弥补IDS检测发现攻击不能有效拦截的问题。

Web应用防火墙（WAF）：专注于Web应用安全的检测产品，可防护SQL注入、XSS、Webshell、命令注入、中间件漏洞等常见的OWASP TOP10攻击行为，并可对检测到的外部攻击进行拦截。

WebIDS：也是专注于Web应用安全的检测产品，相比于WAF，WebIDS不具备拦截功能，市场上玩家厂商较少，从笔者的使用效果来看，WebIDS在Web攻击的HTTP请求包、返回包的展示方面比较直观，检索功能也相对比较便捷。

威胁情报检测：相比于传统的IDS产品，最初主要由某几个威胁情报厂商在推动，依托于强大的云端威胁情报库和情报产生能力，在检测产品中增加了基于恶意域名、恶意IP地址、恶意文件等IOC（情报指标）检测方法，并能提供一些溯源能力。

APT检测：相比于传统的IDS、WAF等设备，APT检测一般会是各类检测能力的集大成，比如基于特征的检测、基于异常的检测、沙箱检测、Web攻击检测、威胁情报检测、上下文关联分析、攻击回溯等。笔者个人觉得APT检测只是厂商销售的一个噱头，相比于高级持续攻击（APT），仅仅基于流量就实现APT检测还是有点言过其实。但是，检测能力相对于其他类产品也是有一定的提升。在这顺便提两点：一是，传统的IDS产品也在集成威胁情报库。二是，基于IOC的检测方法本身也存在较大问题，比如，笔者就遇到过基于文件散列码信誉度的IOC指标将应用系统上传的图片文件都识别为恶意文件，导致了大面积误报。

态势感知：笔者认为，如果APT检测是一个噱头，那态势感知就是一个误导，根本就不是企业真实的安全态势感知，它只是在传统的检测能力基础上加了一个大屏展示功能，反映的仅仅是当前流量镜像的安全状况。真正的态势感知必定是集成汇总多种感知设备（Sense）的基础数据进行综合分析、关联分析，从而产生出反映企业当前安全状况的指标**，当然，即便是这样，态势感知的现状也不尽人意。另外，如果企业预算有限、人手又不足，领导又特别钟爱态势感知，采购一个流量型态势感知产品也是一个不错的选择。

全流量深度分析：对网络中的通信数据进行长期数据存储和回溯分析的全流量网络分析设备。相比于前面的产品或系统，入侵检测能力已不是其最重要的功能，方便、快捷的流量全包分析才是主要功能，能够像Wireshark一样分析拆解数据包各层流量。对于攻击行为的确认、回溯分析，全流量深度分析设备必不可少。

二、部署位置选择

在实际工作中，大家经常要为把基于流量类检测设备部署在什么位置而苦恼。在很多企业实践中，基于流量的入侵检测设备一般部署在数据中心互联网出口处，当再进一步部署的时候，大家往往不知道如何选择？在此，笔者给出了一个思考方式，就是从攻击者角度思考攻击者的攻击路径，攻击者进行攻击的可能路径上部署检测点。下图就是笔者从攻击者视角看，可能从6条路径进入企业内部网络，分别为数据中心互联网出口、第三方外联接入区、办公网与数据中心出口、分支机构上联区等。

对于流量监控来说，这些区域的边界都需要部署相应的流量监控设备。在实际部署时，可以根据企业网络规划的特点，选择最佳的部署点，比如分支机构较多的情况，可以在各分支机构上联的点部署流量监控设备。

三、部署模式选择

目前流量类检测设备的主要部署模式分为物理串联、逻辑串联、旁路镜像部署等。读者可以根据流量检测设备的特点，与网络部门一起沟通部署模式。但基本原则是，旁路镜像部署模式一般不能够实现拦截功能，因此，如果抗DDoS、WAF、IPS等设备想启用拦截功能，需要考虑物理串联或逻辑串联的方式。

从笔者了解的情况来看，真正敢于将WAF、IPS等设备串接入网络链路中，并开启拦截模式的企业还是较少的，误拦截引起的业务中断是安全部门承受的最大风险，毕竟一千次正确有效拦截也弥补不了一次误拦截产生的影响，在没有好的包容环境和激励政策下，只开启监控模式是安全团队不得不采取自保模式。

四、流量类检测设备面临的挑战

（一）告警量巨大

真是不经历不知道，经历后吓一跳，单台设备一天告警量竟然达到百万级，告警的数量直是非人力所能分析。如此巨大告警产生的主要原因有：1、现实攻击本身就量非常大。网络中大量的漏洞扫描、爬虫等，导致背景攻击流量就是非常大。由于考虑到业务连续性问题，网络安全防护过程中一般很少采用拦截手段。这就是导致安全运营从业人员的日常分析工作量巨大。2、检测设备本身的误报。在日常运营中，无论是IDS、WAF，还是APT产品，误报率都居高不下，这一点各类检测产品都需要改进，笔者还没有发现哪一款产品没有误报的。3、业务系统开发不规范。现实监控中，我们观察到有些系统把SQL语句作为参数传输，有些登录后台用了弱口令，导致大量报警。

针对日志量巨大的问题，现有的检测设备都有一定攻击分类功能（高危、中危、低危，失陷、严重、企图等），给安全分析人员减轻了一些工作量，可以重点关注高危或失陷了告警。另外，对于安全投入较大的公司，笔者了解的处理方式有：1、很多企业现在采用自建大数据分析平台或SOC的方式，将检测设备的日志进行集中，然后通过聚合、分类等分析手段对大量日志进行去重、归并，以减少运营过程中的人工数据分析量，但即便如此，分析之后的数据量还是很大。2、对于误报的问题，可以要求厂商进行策略优化，毕竟厂商的产品是通用化的产品，真正用于实际还要进行一些本地化改进。3、对于应用系统的自身建设的问题，可以要求系统负责人进行系统改造。

（二）不敢大量拦截

上文中IPS、WAF已经提到了安全团队不敢开启拦截模式，怕导致业务中断。即便目前业界一直大力推广的大数据分析、关联分析等技术手段，也不敢真正启用拦截模式。一千万次正确拦截所带来的功绩，也弥补不了一次错误拦截引起业务中断过错。好事不出门，坏事传千里，安全分析人员只能默默承受这样的痛楚，从海一样的报警数据分析真正成功的攻击事件。对此，笔者认为企业应该对安全防御给予一定的容忍度，这样安全防御措施才能最大发挥效能。

（三）流量加密

随着企业的安全意识的逐步提高，全站HTTPS已经越来越成为业界的最佳实践，这本是一个好事，整体提升了企业安全等级，但是对于流量类检测设备来说，这无疑给了本已复杂的检测环境再增加一道关卡。笔者了解的处理方式主要有：1、将WAF、webIDS等部署在数据中心加密流量卸载设备之后，经过WAF、WebIDS等设备的流量都是解密后的数据。2、在检测类设备中自行实现解密，但这种方式需要注意以下几点：一是必须将检测设备串联进网络链路，旁挂设备就不能采用此种方式。二是加解密证书需要导入检测设备，会增加解密证书泄露风险。三是检测类设备自行解密会极大消耗设备性能，一般需要集群部署。四是加解密过程会增加链路延迟，影响系统的整体吞吐能力，对于高并发业务慎用。

以上说的都是传统数据中心，对于现在大力推广的云计算场景，因为传统的WAF、IDS等盒子设备不能接入云内，传统解决方案也面临较大问题，这一点笔者也在探索之中。

（四）部署位置不全

随着企业业务的不断发展，企业的数据中心出口边界将越来越多，越来越复杂，如第三方外联就有运营商专线、互联网VPN专线、普通互联网接入等，企业内部也将为不同分支机构开辟各类访问接口。与此同时，攻击者的渗透攻击思路也在不断拓展，供应链、第三方跳板攻击等方式不断出现。传统方式认为数据中心的互联网正面出口是唯一防御部署点已经显得不合时宜了。在预算投入允许的情况下，还是应该加大流量检测设备的部署密度，以增加攻击的检出概率。同时要做到流量全覆盖，同时保证同一部署位置的设备流量一致，一台设备全的流量比十台设备流量不全更靠谱。必要时可以利用资产清单反查流量的覆盖率是否达到要求。

（五）源地址丢失

很多网络安全监控设备中检测的源IP地址已经不是真实客户端IP地址，而是企业内网地址或CDN的地址，这主要是因为流量在经过CDN或其他企业内部的网络设备（防火墙、负载均衡等）时，对流量原始地址进行NAT转换导致。笔者了解的解决方案主要有：1、利用CDN的源站透传方式将客户端真实源地址传递过来。2、在企业网络内部尽量采用路由转发模式，而不是采用NAT转发模式。３、如果采用了NAT转发模式可以采用HTTP协议的X-Forword-For将源IP地址传递进来。

（六）异构部署的问题

在网络安全检测实践中，往往存在一种思路就是异构部署的问题，主要思考就是防止单个设备检测能力失效而导致威胁漏报。依笔者来看，这个思路没什么问题，但在具体实践中有些单位可能会采取单点异构部署的模式，这种模式仍然会有误报和漏报并存，异构部署有些互补，但效果不明显，最后同一位置看到的报警绝大部分雷同，少部分差异还有可能是误报。因此，笔者的建议是如果要异构部署也应采取多点纵深部署模式，攻击者在攻击过程中，不同网络位置所采用的攻击手段是有所差异的，比如在边界区可能是利用Weblogic反序列化漏洞进行攻击，在内网去可能就是利用主机漏洞进行缓冲区溢出、弱口令直接爆破等攻击。

总得来说，无论从厂商角度，还是从甲方角度，基于流量类安全检测产品都是一种相对比较容易实施部署解决方案，未来，必将有更多的产品面世并投入企业的安全运营，比如最近又出现的基于流量的数据安全产品。

*本文原创作者：shengl99，本文属FreeBuf原创奖励计划，未经许可禁止转载