IDS测试

一篇有关IDS测试方面技术文章的节选，仅仅是个人理解。初稿，估计错误和错字还不少。
欢迎提出建议
---------------------------------------------------
三. 如何进行关键IDS指标的量化测试
考虑到目前主流IDS厂商还是使用模式匹配的方式进行，因此，进行所谓行为异常方式的测试手段基本不太可行，而且考虑到需要对用户日常行为的建模和分析，这种测试的周期也会很长。
因此，目前我们通常使用攻击测试集来检查IDS的漏报情况，而误报则需要采用流量仿真或者现实环境测试的方式进行。
3.1 测试规则集
在近年的一些测试中，一些用户使用blade进行测试。由于blade内置了数百条攻击代码的特征，使得非专用的用户也能进行误报和规则涵盖方面的测试。但是我们并不认为blade是合适的IDS测试规则集（可参见下面的说明），只是相对而言，目前只有它可用而已。另外，测试规则集通常用于漏报率检测中，而不适用于误报率检测。
我们认为：一个合理的攻击代码测试集应该满足如下条件：
1. 广泛性：应该具备相当的攻击代码数量，并涵盖主流操作系统和主要应用。
2. 重要性：测试代码集中，应该以测试严重和重要级别的安全漏洞的代码为主，毕竟利用严重漏洞的攻击行为是用户最为关心的部分。
3. 时效性：选择的攻击代码应该是在2年内被发布出来的攻击代码特征。上面谈到的blade包含了不少3年前的攻击测试代码，而最新的测试代码比例又有限
4. 适用性：攻击代码能够确定在满足条件的情况下起到该有的攻击效果。一些攻击测试代码并不能起到真正攻击成功的作用，而仅仅只能用于测试是否存在漏洞。
规则测试集并不是exploit代码的集合，因为在实际测试中，测试者通常不可能搭建起完整支持测试这些exploit的环境。为了方便在各种环境下测试，多数情况下是采用tcpdump录制的完整的攻击过程中发生的流量，并在测试时使用tcpreplay进行回放发送。Tcpreplay完美的模拟了实际攻击过程中发生的流量和会话，很适合用于进行IDS的测试。另外，这种测试方法也不会出现私有攻击测试程序外流的问题。
3.2 误报率的测试
误报的定义：在IDS进行监控分析时，将正常的访问行为或者有意伪造的攻击行为（典型的是使用stick工具，而攻击实际并未发生）报告为攻击行为的情况，称之为误报。
常见可能引起误报的原因通常都是由于IDS规则撰写不严密或者错误引起，也有一些误报与产品使用的检测技术有一定关系。
例如：某IDS的规则描述中，没有进行了相应的协议分析，就人为连接某个特定端口的行为就是发生了利用某种后门的攻击行为。基于单包模式匹配的IDS引擎更容易出现误报的情况，针对IDS产品攻击的stick攻击就是利用早期nids引擎这方面的缺陷，制造大量的攻击告警噪音（误报），甚至拖垮IDS的探测引擎。
误报的测试比较难于进行，因为实验室中很难模拟出真实的网络环境，而无法触发比较完整的误报情况。因此，我认为可行的方式包括：条件有些的情况下，使用sniffer捕获真实环境下的100G左右的数据，如果可能建议在不同的应用环境下进行捕获，典型的我认为应该包括(当然可以分得更为细致)：
 互联网混合应用－多平台虚拟主机或者IDC出口的流量是合适的。
 OA应用－企业内网环境下的正常流量。
 电信骨干－多业务承载平台上的流量。
一方面可以用于在实验室环境下进行流量仿真，另一方面，在IDS的性能测试中，还可以用来进行真实背景流量的生成。
另外一种方式可能效果更好，但是需要特殊的环境。我们可以考虑在真实环境下搭建一个NIDS测试平台（流量在待测IDS的负载范围内），同时加载全部待测NIDS探测引擎。

两种方式相比，各有优缺点：
 仿真测试可重复性高，多个产品进行测试可以线性进行，而不影响测试公正。用于专门的产品测评机构是最为合适的方式。但是测试结果受仿真采样的影响很大，不合适的采样流量或者采样空间太小，测试结果可能和实际应用结果有较大偏离。
 真实环境测试必须进行并行进行，如果采用线性方式，顺序放置IDS引擎轮流测试，由于真实环境的随时变化，发生的流量也不同，可能引起测试结果偏差和争议。优点是在真实环境中，可以进行足够的流量采样，更贴近与用户应用的真实指标，此方法用在具体的项目选型中是比较好的。

无论采用真实环境测试还是进行流量仿真环境的误报率测试，测试时均需要采用同一策略
具体测试步骤建议如下：
【略】

误报率=（确认误报条数＋争议误报条数x权重）/告警总数x100%

注1：考虑到各个IDS产品的可检测数目指标不同，如果都全部加载规则，在误报测试中就有可能对检测规则集较大的产品不公正 －因为规则数目越多的产品，在同等NIDS实现技术情况下，出现误报的可能性越大，因此加载全部检测规则的方式应该用于漏报测试中。
注2：【略】
注3：【略】
3.3 漏报率的测试
和误报率指标不同，我们认为漏报率的测试应该有两个指标：绝对漏报率和相当漏报率。
1.绝对漏报：使用规则测试集发起确定的攻击流量，但IDS系统未能报告此攻击
产生绝对漏报的原因包括：
 IDS没有检测此攻击的规则。
 IDS有关此攻击的规则制作错误，无法正确判断攻击，放过了攻击代码
但是有一点需要指出的是，部分基于异常检测技术的IDS能够对未知（即此IDS并没有专门针对此攻击的检测规则）进行告警，只要能够报告出异常（未指明具体的攻击名称），我们也可认为是一个成功准确的告警。
因此，很容易我们可以知道：
绝对漏报率＝漏报规则数的目/测试规则总数目 x100%

注：任何一个IDS系统都不能保证其全部规则是基于攻击原理检测，因此肯定会出现绝对漏报的情况。

2.相对漏报：正常网络环境下能够准确报告攻击的发生，但是在某些特定情况下无法正常告警的漏报情况。
产生相对漏报的原因主要是以下几种
 IDS引擎实现有问题，无法进行完整的TCP重组，使得利用TCP分片发送攻击frageroute发起的攻击可以逃过IDS的检测。如果能够利用此类工具使得某种IDS系统无法检测到攻击，那么应该来说，此种IDS具有重大的技术缺陷，在这些情况下，漏报可以说是100%。
 攻击测试使用URL编码工具Whisker对CGI的攻击代码进行等效变形，如果IDS引擎编写没有考虑到这些编码或者等效因素，将产生漏报。
 测试代码使用ADMmutate对溢出攻击的shellcode进行编码，仅仅依靠shellcode特征检测的IDS可能发生漏报。
 因为性能原因，虽然正常情况下能够报告此攻击，但是在一定流量压力下，IDS引擎开始丢包，无法重组会话或者遗漏关键的特征报文而漏报此攻击行为。因此，测试相对漏报时，必须要有流量背景作为漏报率的参考值。

从目前的主流IDS技术来看，没有一个产品能够做得100%无绝对漏报，即使是相对漏报率，同样也不可能达到0%，严格来说，如果采用逃避，部分IDS甚至可能完全不能检测真正有效的攻击。

由于上面一些可能造成逃避IDS技术的存在，相对漏报率比较难于衡量。例如，某种IDS在正常环境下漏报率假如是20%，但是由于引擎设计问题，一旦加入fragroute技术的攻击测试时，可能一条也无法报警，也就是说漏报率为100%，那么最终指标如何计算？
针对这种情况，我们建议测试时分别考虑，同样给出两个测试结果。分别是不加入变形测试时，不同流量背景下的标准相对误报率；另一个是使用3种IDS逃避技术情况下的严格相对漏报率。标准相对误报率的测试比较容易进行。此处不详细描述，对于严格相对漏报率的测试，建议步骤如下：
1． 背景流量的选择，虽然可以使用包发生器（如smartbit和IXIA等）产生背景流量，但是又可能引入复杂的包大小因素（详见IDS性能测试章节），建议从简化的角度来进行，使用在误报率测试中使用的标准背景流量，通过多台主机使用tcprelay参数控制发送速率，产生不同的背景流量级别。
【略】

某流量压力下严格相对误报率=(fragroute技术实际总报告条数/测试规则数目x参数数目)x33%+(Whiske技术实际总报告条数/测试规则数目x参数数目)x33%
+(ADMmutate技术实际总报告条数/测试规则数目x参数数目)x33%

也就是说，实际考核IDS的漏报率指标应该为：
某流量负载下，不加入变形或者分片等逃避IDS检测的技术
标准漏报率＝绝对漏报率x标准相对漏报率
严格漏报率＝绝对漏报率x严格相对漏报率

最终的漏报率指标表可能如下：
Xx产品漏报指标 标准漏报率 严格漏报率
10%流量压力 绝对漏报率x标准相对漏报率 绝对漏报率x严格相对漏报率
25%流量压力
50%流量压力
75%流量压力
95%流量压力


大多数情况下，误报率和漏报率是相互矛盾的，为了降低误报率，那么规则需要特别严格，一不小心就有可能增加了漏报的情况，提高漏报率；为了降低漏报率而放宽规则的严密性或者加入异常检测技术，又往往带来误报率的上升。另外，任何希望同时降低误报率和漏报率的努力，都会带来大量的开发投入，多数情况下还会造成性能的下降。因此入侵检测系统都是需要根据自身的特点和设计目标在误报率和漏报率中选择一个平衡。

另外，我们可以看到，如果严格按照上面的方式进行测试，需要较长的周期和大量的准备和事后分析工作，通常个人、甚至小的公司都无法组织一次全面测试。

---------------------------------------------------

在国外近年的一些测试中，我们看到真正专业的一些测试方法和过程，而不是目前在国内很多产品选型测试中各个厂商各显神通去影响测试方案。如果有哪位朋友有资源组织一次公正的第三方测试或者希望开发规范的IDS测试方案，欢迎和我联系。