《IPS+vs.+IDS+(Chinese).doc》由会员分享，可在线阅读，更多相关《IPS+vs.+IDS+(Chinese).doc（8页珍藏版）》请在三一办公上搜索。
1、IPS vs. IDS - 表面相似，实质迥异介绍通常的观念认为，入侵防御系统（IPS）不过是一个在线部署，具有拦截能力的入侵检测系统（IDS）罢了。本文将对此进行反驳。尽管IPS和IDS都在检测网络流量，并寻找其中的攻击性内容，但是两者之间仍存在非常重要的区别。IPS和IDS都力求以和网络速度相匹配的速度检测出恶意的或是此要的流量，并尽可能精确和完整地达到要求, 但是IPS是设计用于自动执行网络策略的在线设备，而IDS则不过是一个外部设备，是安全分析师的检查工具。使用和配置上的差异会产生两个直接的结果：1 改变了设备的设计要求中的着重点，以及2 黑客攻击设备的手段顺理成章地，这些变化也将会使
2、得本来对于IDS而言理想的工程设计和技术对IPS的设计而言就不理想，反之亦然。IPS和IDS有四个相同的基本要求：l 稳定性l 确定的网络性能l 最小化误报l 最小化漏报尽管这些要求看起来一样，但是IPS和IDS的部署和用途的差异导致两者设计在这些需求的优先级别定义、意义、以及实施方案的选择上存在本质区别。稳定性：网络中断 vs. 安全分析师的烦恼虽然IPS和IDS同样都需要稳定性，但是两种系统崩溃之后所产生的影响却大不一样。如果一个IDS崩溃了，在设备重启之前就会存在一个暂时的安全盲区，当然，安全工程师将会对这个问题非常头疼。而如果崩溃的是一个IPS系统，那么整个网络很可能被中断。因此，就产
3、品的稳定性而言，对IPS的要求比对IDS要高得多。确定的网络性能：峰值 vs. 平均吞吐量设计网络的性能有两种衡量方式：吞吐量和延迟。吞吐量指设备的处理能力，度量单位是数据包/秒，或比特/秒。延迟则指从报文被收到，到报文被处理和转发之间经过的时间。对作为带外设备的IDS而言，其处理能力应至少满足网络的平均负载。捕捉与报告之间的时延可以是几秒或几分钟。为了满足这些要求，像IDS这样的外部设备可以通过将数据包存储在大容量缓存中来吸收网络中突增的流量。如果使用缓存，IDS的应变能力将会降低，而如果不使用缓存，IDS系统的处理能力就必须达到网络的峰值，这通常会是平均值的510倍。由于IDS是一种记录设
4、备，它为人们提供数据，在接收到数据包并报警之间的时延可以是数秒的时间。事实上，在很多环境下，甚至可以允许出现数分钟的时延。在这样的延迟要求下，我们可以使用超大容量的缓存。对于在线配置的IPS而言，其处理能力必须达到网络负载的峰值，而其延迟必须与网络中最快链路的延迟相等。一般情况下，在网络核心部位，这意味着一个或多个Gbps的处理能力，以及200微秒以下的延迟。而在网络的边缘部位，处理能力的要求就会下降到数百Mbps，而延迟要求则大约在110毫秒左右。如果IPS的吞吐量小于负载峰值，则其将成为网络的一个瓶颈，而如果IPS的延迟很高，程序的响应时间以及TCP吞吐量将会非常糟糕1。使用大容量缓存来吸
5、收网络突增的流量的方法对IPS而言完全不适用，因为缓存势必将大大增加网络的延迟。举例来说，假设有一个平均负载100Mbps的网络，有一秒的时间其负载激增到了1Gbps。一个带有125MB缓存，处理能力为100MBbps的IDS可以满足以上要求（1Gbps*1秒/8bit/s）。而如果将这个IDS在线配置，则在负载激增期间的延迟将会增加到910秒，造成断断续续的网络停摆2。这可以类比到发电站上，在用电高峰期，电站需要更多的燃料来发出更多的电，如果发电站按照的是“平均需求”来设计，那么就将会在用电高峰造成停电。误报：浪费的时间 vs. 阻挡了合法的流量所有IPS和IDS的厂商都致力于减少误报的可能
6、性。但是对两种系统而言，误报的意义和重要性各不相同。这些差异来源于其不同的设计初衷。IDS的目的是将可疑的行为报告给安全分析师，而IPS的目的则是实时地防御攻击。注1 TCP吞吐量在实际操作上由RTT来决定，即两个TCP端点之间的网络延迟的一种度量。注2 从缓存式设计向在线式设计转变是IDS系统核心转向IPS所需的重要改动。大部分IDS厂商只不过是将其产品换了个标签，而产品中依然存在以前的设计缺陷（注：Tippingpoint在实验室所观察到的最大的延迟是一个ICMP的请求回应报文，达到了167秒，这在功能上已经等同于网络中断。）IPS (在线) vs. IDS (旁路)IPSIDS在线部署，
7、自动执行策略旁路，完全消除了低吞吐量，高延迟或低精确度的影响必须具有如交换机一般的可靠性即使可靠性差也只会使安全工作人员忙碌不堪，并不会影响业务流量。必须支持上Gbps的吞吐量，并达到与交换机相近的延迟即使速度慢也不影响网络和应用不可以产生误报或漏报即使精确度差也不影响实际的业务流量IDS系统的误报指对未导致入侵行为的报警，有可能是被攻击的系统并不具有该弱点，也有可能是检测机制出了问题，还有可能是IDS检测到了异常行为，而后证明其是良性的。IDS的误报会使安全分析师徒劳无功。而当IPS出现误报时，人们主要担心的问题是合法流量将会被拒之门外。很多组织将阻挡合法流量看作是比误报严重得多的问题。故I
8、PS的误报是比IDS的误报更加严重的问题。如果一个IPS多次阻挡了合法的流量，那这个IPS将会被直接下线。这些差异使得厂商对于误报的重视程度大大提高，同时也大大加重了过滤器编写和测试小组的任务。IPS过滤器的编写小组除了需要问自己 “这个过滤器能检测到攻击吗？”这个问题之外，还要问自己“有没有可能合法流量会被看作是攻击行为？”3。测试小组需要测试上Tbyte的客户流量，以寻找那些可能会被误报的合法内容。IPS和IDS对误报的态度不同，这也使得一些对IDS适用的过滤器对IPS就不再适用。IDS的过滤器虽然提供可疑行为的线索，但这需要人为去甄别。而IPS的过滤器则直接引发自动的控制策略，例如阻拦或
9、隔离某个端点。两者之间的区别在于可疑行为的判断和能直接响应的智能。任何一种能发现可疑行为，但也有可能误判的过滤器都适用于IDS，但不适用于IPS。这意味着大部分对IDS而言很优秀的协议或异常行为过滤器在IPS看来可用性很低，因为其判断的智能不足以直接执行控制策略。注3：当TippingPoint从友商聘用一位过滤器开发者，几个星期的时间会花费在向他们灌输“无误报”的思想上举例来说，早期TippingPoint编写的一个过滤器检测到一个将源地址设置为环回地址的报文。这种报文本不应出现在网络上，属于一个协议异常的数据。但是，如果设置为阻拦该报文，那么该过滤器将会将客户的基于网络的视频监控系统阻断。
10、其中的问题在于摄像头以UDP报文的形式发送视频数据，其源IP地址被设置为127.0.0.camera-id。这个真实的案例指出了使用异常检测方式和自动执行策略的根本问题：真实网络中的合法流量中充满了异常现象。协议异常现象来自一些使用现成协议库，且使用方式不规范的定制程序。由于定制程序是封闭的，而且经测试其能正常工作，对协议的异常使用也就无法被察觉，直到IDS或IPS系统安装完毕才会出现问题。行为异常来自一些特别的，但常常是非常重要的业务流程中。例如，在一个大型电子商务站点测试一个行为异常检测器时，在两台从未进行过通信的机器之间检测到了巨大的流量。最终发现该流量是由于服务器崩溃，引发自动恢复系统
11、重建服务器。重建服务器的流量确实可以看作是异常流量，但是如果将其阻拦，将会导致灾难性的后果。这些案例以及其他类似的情况都说明基于异常行为的检测机制（协议上的或是统计的）对于IDS很有用，但是却不适用于IPS。一些类型的IDS误报在IPS中不形成误报。若IDS检测到攻击的存在，但是攻击对目标不起作用，这可称为是误报。但如果IPS阻拦了流量，这不叫做是误报。事实上，将该流量阻拦之后还可以减轻网络负载。同样，如果黑客可以构造出一种流量并引发了IDS的报警，对IDS这算是误报，但IPS将该流量阻拦的行为不是误报。误报造成了IDS的潜在漏洞。如果一个黑客能诱发IDS系统的误报，那么他们就可以进行“雪盲”
12、攻击，即在IDS监控台上制造迷惑性的报警信息，这种方式的理想状况是他们既隐藏了攻击源、目标，又隐藏了攻击的方式。在IDS监控台上制造迷惑信息的同时，黑客开始进行真正的攻击，这时对安全分析师的挑战是在黑客制造出的把戏中大海捞针，找出真正的攻击。相反，如果黑客想要对IPS进行雪盲式攻击，系统将会把他制造的迷惑信息连同真正的攻击一起阻挡在外。本段分析可总结出以下三点：l IPS必须不能出现误报；IDS则将误报“最小化”。这将导致代码编写和测试工作出现很大的差异l IPS的误报将会阻挡合法流量；而IDS的误报则是一次未成功（或未能成功）的入侵。l 异常行为过滤器不能用于执行阻拦，只能作报警。这些差异改
13、变了对产品的要求及其设计工程，也导致IDS具有易受雪盲式攻击的弱点。最小化“漏报”：网络性能 vs. 解码真实度漏报就是未察觉到一次攻击。很明显，漏报是谁也不希望出现的情况，每一个厂商都在尽可能完善其过滤器的覆盖范围。尽管如此，“万灵药”是不存在的没有任何一种产品能检测到全部的攻击。因此，人们把目标转向了对高优先级的攻击的覆盖。在确定攻击覆盖范围优先次序时，每个厂商都需要评估以下三个方面：l 这个攻击对客户是否构成严重威胁？l 安全引擎是否能在不出现负面效应的前提下处理？l 过滤器编写小组能否胜任研究和编写工作？在评价IPS的防护能力时，一个有用的度量方式便是检查其对Microsoft Tue
14、sday漏洞的覆盖能力。因为这些漏洞对于每一个客户而言都非常重要。厂商需要排列这些过滤器开发的优先次序，而不提供漏洞覆盖的唯一原因只能是引擎不足以达到要求，或是开发小组不胜任该工组。除了缺乏覆盖范围之外，漏报还有其他的几个原因。攻击数据有可能采用了一些迷惑性的手段来规避IDS或IPS。对IDS而言，系统有可能会由于出现过量的流量而丢弃用于判断攻击的报文。而对IPS而言，设备溢出的效果稍有不同：流量将被丢失，攻击行动也随之失败，因为攻击数据也一同被丢弃，但攻击也未被检测到。对于规避IDS或IPS的攻击，两种系统都应具有处理规避技术的技巧，这些技巧可各不相同。理想状况下，通过这些技巧，系统将破解躲
15、避的技术，并正确地报告攻击。例如通过分割MSPRC流量进行的规避。MSPRC协议本身在应用层支持碎片分割。但是，没有任何的合法应用会在易受攻击的服务中使用到这个特性；实际上，直至最近版本的WINDOWS，MS-PRC的代码中仍存在错误。这个错误存在了很多年，显然是因为从未有人在合法程序中使用过MS-PRC的碎片分割。对于这种情况，IPS只需将含有MS-PRC碎片的有效负载流量阻拦即可，而无需对攻击进行解码。虽然对攻击进行解码显得更加理想，但是将会占用处理周期，从而影响网络的性能（世上没有免费的午餐）。对IPS而言，网络性能比解码真实度更加重要，前提是没有漏报的情况。而对于IDS，解码真实度就比
16、网络性能更为重要。需要注意到，由于一些其他的原因，IDS是无法对MS-PRC碎片报警的。因为对MS-PRC报警将会被利用来实施雪盲式攻击。此外，如果IDS对一个MS-PRC碎片报警，而不去对其解码，也就没有足够的信息来判断攻击是否成功，或是攻击的目标是否具有该弱点，或是有效负载中是否存在攻击行为。因此，如果使用这种方法，IDS将有可能会出现误报。IDS：理论 vs. 现实IDS的厂商经常用理论上的讨论另人们搞不清楚本质上不同的设计要求问题。例如：IDS的设计要求是基于协议解码器，而IPS的是基于特征匹配。一个产品是否能检测到某一异常现象（例如：非标准端口上的HTTP或加密流量）一个产品是否能对
17、付某种特定的规避技术待添加的隐藏文字内容2他们将会用一些会导致误报的人为构造的流量将讨论从每一个产品的基本设计目的转向一些枝节问题。这些讨论常常会退化成抽象的讨论。“协议解码器更优秀”，这样的论点便是这些战术的一个代表例子。协议解码器只不过是对结构化网络通信进行解码的状态机而已。关于协议结构的信息被编码进入状态机之中。通过将解码器输出的值与阀值作对比，或是与一些能引发已知漏洞的值组合作对比来产生警报。协议解码器的优点是可以检测出协议的异常操作，这对使用特征匹配的过滤器而言是很困难的。但是，协议解码器会在产品的稳定性和确定的性能上产生问题，同时也是误报的一个来源。每一个协议解码器都是一小段C代码
18、或汇编代码，而只要是代码，都会存在缺陷。如果一家厂商通过加入新的解码器或是更改当前的解码器来检测攻击，那么他们必须在每一个过滤器升级包发布的时候发布新的软件版本，通常每周一次。这种情况很可能出现，因为当攻击手段出现在新的协议中（JPEG文件漏洞曾经使得所有的协议解码器厂商都叫苦不迭），或是现有的协议出现新的漏洞。例如在Nimda蠕虫出现之前，没有任何一种产品中使用了Unicode解码。加入Unicode解码需要重新编写协议解码器而使用特征匹配技术不存在这问题。软件中频繁的改动会引发稳定性和性能问题。无论测试小组如何地努力，按照每周一次发布的代码必然会存在缺陷。这些缺陷有可能以稳定性问题，性能问
19、题，甚至是漏洞的形式出现，例如Witty蠕虫4，或是Snort DCE/RPC预处理溢出5。另外，协议异常检测也是误报的一个来源。作为阈值的数值需要在安装时根据具体情况进行调整，并在将来每一次的解码器升级或修改时持续进行。为了检测到某一些类型的攻击，有时会需要使用到协议解码器。但是绝大部分的攻击类型都可以通过特征匹配技术来进行准确无误地判断（更适合在IPS上使用），特别是如果特征匹配器大大超越了简单的正则表达式。在实践中，所有的产品都应结合协议解码器和特征匹配器一同使用的。所以，有什么必要专注于协议解码器呢？注4：US-CERT. “March 22, 2004-Current Activit
20、y: Witty Worm.” 22 March 2004. United States Computer Emergency Readiness Team. http:/www.us-cert.gov/current/archive/2004/03/22/archive.html 注5：US-CERT. “Sourcefi re Snort DCE/RPC Preprocessor Buffer Overfl ow.” 19 February 2007. United States Computer Emergency Readiness Team. http:/www.us-cert.go
21、v/cas/techalerts/TA07-050A.html 总结本文讲述了IDS和IPS在设计要求的本质和优先程度之间的很多重要的不同点。对一个在线设备而言，稳定性和性能是最重要的。一个IPS，即使其检测效能非常完善，但延迟太高，吞吐量太低，或是产品不稳定，那么该设备永远也不可能有实用价值。因此，对IPS而言，设计要求的优先级为且必须是：1 稳定性2 确定的网络性能3 无误报4 最小化漏报而对于IDS，其设计要求的优先级是则必须为：1 最小化漏报2 无误报3 确定的网络性能4 稳定性需要注意到的是，第二个表恰好是将第一个表格颠倒了过来。设计要求优先级的差异会对下列方面产生连锁影响：产品需求
22、定义在设计产品时各个方面之间的权衡设计产品时使用的技术以及编写，测试以及支持该产品的组织。当必须作出决定并进行设计平衡的时候，IDS和IPS的设计永远应该是不同的。TippingPoint避免进行抽象的讨论，而关注于实用性问题：研发出一个符合IPS的要求优先级的产品：稳定性，高性能，无误报，最小化漏报。如果有必要，TippingPoint也会使用协议解码器，但是同时关注性能问题，因为改进产品的稳定性和性能至关重要。TippingPoint相信这样符合设计出真正IPS的要求。最终的决定权在用户的手中，以及他们所需要的产品的用途。如果客户需要一个能为其提供警报和异常行为信息的系统，那么他们就应该买一个IDS。同时也应该清楚地知道这一点，IDS不是为在线配置而设计的。如果将其在线配置，则会出现非常严重的问题和挑战。如果客户需要的是一个能在线工作，并实时拦截攻击的产品，他们就需要买一个从设计之初就本着这个目的来开发的，并能对各种可疑行为进行精确判断的产品。如果两者都想要，那么他们应该购买一个专业的IPS，并在其后部署一个能满足要求的IDS。
