再谈入侵检测（一）——浅谈有效性

亡羊补牢

入侵检测，贯穿了传统安全时代和如今的大数据安全时代，虽然威胁情报、态势感知应势而起，但入侵检测却永远是企业“亡羊补牢”的必备产品。

我把入侵检测定义为“亡羊补牢”，是因为一旦入侵检测发现了问题，那说明防火墙已经失效，或是内部有人在搞鬼，并且已经是事后了。

亡羊补牢，为时未晚。

安全是时间的拉力赛，提高入侵检测的效率和有效性，对企业构建安全防御体系有着最关键的意义。

以无法为有法，以无限为有限。——李小龙

IDS控制台

态势感知，虽然目前还并不完善，但其数据来源，必有入侵检测。

从攻击到被检测到，然后检测结果传到态势感知，再将其展示，这本身就耗费了一些时间；并且加上态势感知数据量的庞大，难免一些事件会被淹没。

所以窃以为，入侵检测的控制台（或者叫分析中心）依然需要重点展示和监控。

详细的原始信息和互联关系，是入侵检测一个方面的价值体现。

致命问题

IDS最大的问题在于如何自动筛选出有效攻击。

稍微大点的企业，单入侵检测每天就少则数十万条告警，多则百万条告警。金融、运营商就更加庞大了。

数量相当庞大，但告警质量确不值一提。

一个最简单的例子：

某家电商一天内仅“webshell上传”和“目录遍历”告警事件就已超过万次。小名耗费五六个小时，通过excel等辅助工具，终于处理完毕，结果全部告警事件都仅是攻击尝试，并不是有效攻击。

第二天，小明看了一半的告警，依然全是无效攻击。

第三天，小明看了三分之一，情况仍然一样。

之后，小明每次看到这样大量的告警，就默认为“全部都是扫描触发”，并且写入了提交的报告中，只是偶尔抽查几条告警进行验证。

例子虽然有些极端，但却不失真实。

我们只能祝小明好运，在数十万的无效攻击事件中千万不要出现几条有效攻击事件。否则，饭碗就不保了。

安全服务人员，甚至客户会对IDS产生强烈不满的情绪！但各个厂商都是这样的问题，所以只能暗自叹息了。

问题探讨

那么如何解决告警泛滥这一致命问题呢？除了告警泛滥，自动化分析告警事件如何才能有所突破呢？

IDS提高有效性的几个途径大概如下：

1、保留传统检测方式，如包检测。

2、二次分析，由分析平台对上报的事件进行二次分析，确认事件的准确性。

3、资产关联，再次确认攻击告警的准确性。

4、优化特征库，提高有效检测率。

5、全面开放自定义检测，客户可根据自身环境制定针对性的检测特征库。

6、联动，所谓的威胁情报（各种威胁库）、恶意代码检测等。

IDS最核心的地方，就是规则库。所以，优化特征库，是最能提升有效检测的途径。

必须在检测思路上进行创新。——《全范式检测框架浅析》周涛 潘柱廷

问题探讨

周博士的文章重在分析APT检测，但这里借用文章中的一句话“必须在检测思路上进行创新”，来聊聊IDS如何提升有效性的检测。

规则库优化（以http协议为例）

举例：

使用Sqlmap扫一个网站，IDS便会触发大量告警，而大部分告警，仅是尝试攻击。安全人员根本无法从大量的sql注入中去验证每一条是否攻击成功。

假如Sqlmap却是扫描到了一个url有sql注入漏洞，试问如何从上千条告警中找出这个url？

有效手段：

1、Web攻击添加响应状态码匹配。

2、检测相应内容，判断服务器返回信息是否被攻击成功。

目录遍历、命令注入、CGI攻击、webshell连接等等，均可通过此手段，大幅提高有效告警。

表现：

高质量告警，大幅减少误报和无效告警数量。有效抑制无效攻击告警泛滥，由数十万条无效攻击告警精简为几条有效攻击告警，甚至可能0告警。

在超大流量环境中，还能大幅降低数据库压力。

再优化：

对于某些客户，如果有大数据平台，无论攻击是否有效，部分客户仍然需要全部的告警事件；而判断是否为有效攻击，是通过大数据平台的算法实现，为威胁情报、态势感知、追踪溯源提供更多的数据参考。所以，IDS本身的事件分析已经非常淡化。

因此可优化为：仍然是目前的告警方式，但增加单独的焦点模块，在分析中心上判断告警事件的返回信息，如果判断为有效攻击，对该告警进行标记，并上报到单独的焦点模块中。所有事件，依然上报给大数据平台。

当然，检测上的优化会带来其他方面的投入，比如性能。

资产管理

真实攻击：

不知攻，焉知防？

先暂不关心攻击者使用的具体技术，只重新强调攻击者的目的。

黑客的目标，是拿下内网服务器、路由器等重要资产的权限，并获得内部数据（其它目的的有DDOS、破坏内网环境）。所以资产管理能非常有效地关注重要资产的告警威胁情况，因为即便黑客先攻入内网的终端PC，终极目标仍然是服务器和数据。

可见，资产管理模块尤为重要。

但仅仅有资产管理模块还只是鸡肋，每天大量告警，仍然无法找出有效攻击。所以只有把资产管理和检测规则相结合，才能发挥最终效果。

2.1.2 场景分析：

IDS上有木马后门告警，目标是某台重要服务器；小明立即使用最简单的方法确认是否误报：查看该事件的影响系统是windows平台，而目标服务器是Linux系统，当即确认为无效攻击。但问题是告警数量非常多，小明花费了半天时间也没有看完，内牛满面！

那么，如果分析平台做了自动化关联，把资产的系统与规则的受影响系统结合判断，不仅减少了大量无效告警，还为分析人员减少了大量无用功时间。

由此延伸，规则中还有受影响的应用软件，如struts2远程代码执行漏洞，并没有受影响的操作系统分类，而是web框架分类。资产管理中加入应用软件的字段，和规则的受影响应用软件进行匹配，比如当目标服务器是IIS时，struts2远程代码执行漏洞攻击标注为无效攻击。

2.1.3 功能特点：

资产管理与规则的自动关联。

面对大量无效的告警信息，分析人员不可能每条都做分析。做自动化管理后，当受影响操作系统或受影响应用软件发现与资产设置的字段不符时，标记为“无效攻击”，但不能直接丢弃（此处的操作，要与上述优化http规则区分清）。

不直接丢弃原因：无效并非无用，可以当作单纯的行为数据上报，并且部分规则说明了源IP有异常，只是目标服务器不受影响（如木马后门等），源IP仍需排查。如果受影响系统或软件相对应，并且最终分析完确定事件误报，可以正常进行规则优化。

2.1.4 核心目的：

既达到高质量告警，又实现了产品自动化。

在直接说明目的IP不受影响的情况下，突出源IP有异常。

2.2 自定义规则

随着用户资产的增多，网络环境也愈加复杂，并且每个用户的环境大相径庭，仅仅依靠内置规则进行传统的入侵检测已经明显落伍。

拥有灵活的自定义规则，已成为入侵检测系统的必备功能！

自定义规则，某种意义上来讲是另一个规则库，和内置规则库方向不同，但足以媲美。安全技术越强，业务逻辑越清晰，自定义规则就越能发挥出应有的价值。

2.3 APT联动

IDS需要和APT进行联动，或者集成APT模块。APT并不仅仅是检测文件，而是需要检测用户行为、木马行为等。

关于APT的检测，在此不再做过多讨论，建议参看周博士的《全范式检测框架浅析》。

2.4 事件聚合

目前的IDS日志管理平台，无法自动处理大量告警日志。

虽然上述一些功能做了一部分告警优化，但是实际环境中事件量依然庞大。并且日志管理平台会同时收集多台IDS引擎的告警事件。

事件聚合的思想可以借鉴大数据平台。

做出自动化聚合告警日志功能，对分析告警、威胁趋势等，有相当大的帮助。

2.5 关联分析

随着安全技术的进步，黑客攻击手段愈加高明，仅凭分析单条告警事件难以发现黑客的真正意图。

通过关联分析，把告警事件、源目IP、时间进行关联，自动化挖掘潜在威胁。

然而目前很多产品的关联分析功能，纯碎是为了关联而关联。

关联分析，需要有着明确的攻击场景和可预测的攻击分析。而该功能的开发，重点在于安全服务人员提供的深度安全分析策略。

2.6 追踪溯源

追踪溯源微型化（之所以称作微型化，是由于单台引擎日志量不大，难以体现；几十台引擎时，日志量大，但相比大数据平台仍然很少）

入侵检测，不仅仅要挖掘出威胁，更要发现攻击者的攻击途径，杜绝后患。

追踪溯源手段见导图：

图3:追踪溯源导图

2.7 恶意URL库

IDS添加恶意URL库，记录访问这些URL的事件，发现内网隐患。

2.8 钓鱼网站库

IDS添加钓鱼网站库，记录访问这些网站的事件，发现内网隐患。

当然，各种库，我把它理解为目前的“威胁情报”库。

问渠哪得清如许，为有源头活水来。——朱熹

四、写在后面的话

本文主要是探讨IDS的检测方式，本身便锁定了立意上的狭窄。

在如今大数据盛行的时代再谈IDS也许有点小题大做，但笔者窃以为IDS仍然有很大的发展空间。上述探讨的一些想法，也许能够真正体现IDS自身价值的途径，算是抛出一块砖头，等待研究者发现更好的美玉。

另外，态势感知、威胁情报等运用的思想，也可以借鉴到IDS日志管理平台上；甚至任何实际有用的方法，都可以借鉴过来，转化为功能做到产品中。所以，本文在前言引用了已故的伟大武术家李小龙先生富含辩证哲理的话。

最后还想说一句：IDS“不死”。

本文对IDS的有效性进行了浅析，其他问题再行整理后和大家一起探讨。

笔者对网络安全建设上存在不足，所以对文中有任何问题欢迎回复，一起交流。