IPS性能测试表明,为了安全,产品必须减速
结果表明,高性能并不总是意味着高安全性。
此外,由于攻击率达到16%,TippingPoint设备禁用了所有警报(它继续阻止攻击,但没有记录任何信息)10分钟。TippingPoint称这是一种减轻负载的功能,并表示绝大多数客户都更喜欢这种设置,而不是在设备过载时关闭设备。
我们理解超负荷期间的设备行为最终是一个决策。对于高可用性胜过安全的企业来说,继续转发数据包的能力是至关重要的——即使这意味着暂时关闭IPS监控。更多疑的网站可能会封锁所有流量以应对过载。在这个测试中,TippingPoint和NFR设备(可能还有其他设备)明确地为用户提供行为选择,这在我们看来是一个理想的特性。
就HTTP响应时间而言,NFR的Sentivist Smart Sensor提供Web页面的速度最快,对于一个11KB的对象,平均约为144毫秒。这是1500个用户在没有攻击流量的情况下请求和检索带有单个11KB对象的Web页面所花费的平均时间。NFR传感器也通过了1%和4%的攻击测试,响应时间低于所有其他供应商的基线测量。
然而,在16%的攻击测试中,Sentivist设备出现了可怕的错误,响应时间比基线测试高出近80倍。这可能只是一个反常的结果;在Sentivist设备上进行的两组和四组端口对测试中,响应时间并没有增加多少。此外,只有当攻击流量超过60Mbps时,设备的延迟才会上升,这表明严重的专用拒绝服务(DoS)攻击正在进行中。在我们结束测试后,NFR说它识别并纠正了CPU过度订阅的问题,但我们没有验证这一点。
在其他设备中,当我们提高攻击率时,ipAngel的响应时间下降最少。考虑到供应商为测试提供的强大的传感器硬件,这并不奇怪。ipAngel传感器有8个双核Opteron处理器。
需要注意的是,这里展示的所有结果都是我们测试的三分钟稳态阶段的平均值。这些平均值是有效的,但它们并不能说明全部情况。在一些测试中,平均性能的下降是非常显著的,随着时间的推移,实际结果显示,对攻击的反应下降得更厉害(见链接受攻击的TCP转发速率)。
所有IPS系统在我们最严重的攻击下都在一定程度上降低了流量,但降低的程度和持续时间不同。ipAngel的速率下降最少,尽管该产品测试结束时的速率为824Mbps,比测试开始时的929Mbps速率低了100Mbps。Top Layer的IPS 5500在攻击后恢复到原来的速率方面做得最好,但即便如此,它暂时将流量降低了550多mbps,降至不到400Mbps。用户是否会注意到这种减速取决于应用程序。涉及持续高速数据传输(例如FTP)的内容会短暂地放缓。
在受到攻击时,TippingPoint 5000E的速率从400Mbps左右降至10Mbps,对其他的更糟糕,速率一路降至零。德马克和NFR数据显示设备过载,而福蒂内设备似乎恢复了,然后又出现了故障。
TCP速率的急剧下降也会影响HTTP页面响应时间(参见链接)下面的图形):
响应时间(客户端请求和接收Web页面之间的间隔)在基线测试中仅为几百毫秒。然而,在我们最猛烈的攻击下,许多IPS系统引入了数秒的延迟。Ambiron TrustWave和顶层IPS系统在攻击下保持低且一致的响应时间方面做得最好。
这些结果表明,IPS设备有可能对网络性能造成严重的延迟,与网络中的恶意流量不成比例。实际上,IPS可能是一种提供自我攻击DoS攻击的工具,在这种攻击中,少量的攻击流量可以使千兆网络的Web流量极其缓慢,并且完全无法用于文件和打印服务。
在测试结束后,Demarc说,它使用的Bivio传感器硬件的新性能参数将大大提高其数量。不幸的是,时间限制使我们无法核实。
我们还测量了UDP吞吐量。我们认为UDP数据不如TCP数据重要,因为UDP通常在生产网络的Internet端流量中所占的百分比要小得多,但这些测试仍然是描述设备转发和延迟的绝对限制的有用方法。如果您计划将IPS深入您的网络,UDP流量来自源,如备份或存储服务器可以形成你的大部分流量。
大多数设备以或接近理论线速率移动中型和大型UDP数据包。这两个例外是FortiGate-3600,它以大约50%的线速率移动中等大小的数据包,以及ipAngel,它以远低于TCP流量的速率移动UDP流量(对于所有数据包长度)。Ambiron TrustWave表示,其传感器使用的是接口设备驱动程序的测试版,后续版本显示UDP的吞吐量更高、延迟更低;我们没有证实这一点。
和TCP测试一样,当我们对大多数IPS系统进行攻击时,UDP测试中的延迟也会急剧增加,延迟增加百倍(或更多)的情况并不少见。唯一的例外是ipAngel,它在攻击测试中对数据包的延迟量与基线测试中大致相同。这可能是由于ipAngel的UDP吞吐量,在这个测试中比其他设备低得多。
在公布测试结果之前,我们给所有供应商一个审查和回应的机会。TippingPoint在内部测试中发现,如果我们测量的是95%而不是100%的吞吐率,延迟会低得多。Top Layer要求减少负载(可能是99.9%),并将其增加的UDP延迟归因于我们的测试工具和IPS之间的时钟差异。
虽然较低的负载可能会产生较低的延迟,但出于两个原因,我们尊重地不同意这两个供应商的建议。首先,正如RFC 2544(网络设备性能基准测试的行业标准)中所描述的,延迟是以吞吐量来衡量的,而不是吞吐量的X %,其中X是产生“良好”延迟的某个数字。
其次,这两家厂商的设备上都没有标签警告客户费率不应超过线路费率的X %。如果供应商希望声明高吞吐量,他们还应该在吞吐量级别度量延迟。
两个端口对
在基线TCP性能测试中,IPS 5500是最快的设备,TippingPoint 5000E紧随其后(参见链接IPS酷刑测试,场景2,如下)。Ambiron TrustWave、Demarc和NFR设备移动TCP流量的速率都远低于单端口对测试中的理论最大值。
Top Layer和TippingPoint设备在攻击测试中也产生了最高的速率,但结果存在问题。TippingPoint 5000E在我们的所有三个攻击测试中转发了少量的思科利用流量,并在我们的4%和16%攻击测试中禁用了日志记录。在所有三次攻击测试中,顶层设备转发了少量的Witty蠕虫流量。这两个供应商的问题与单端口对测试中的问题相同:TippingPoint的Cisco签名有问题,而Top Layer的防火墙配置有问题。
在没有转发任何利用流量的设备中,Sentarus传感器和ipAngel是速度最快的IPS系统。当我们以1%的TCP速率提供攻击,以接近基线速度移动流量时,Sentarus脱颖而出。ipAngel在4%和16%的攻击测试中速度最快,尽管攻击率分别比基线测试低10%和25%。
HTTP响应时间在受到攻击时也会急剧增加,尽管在某些情况下,使用两个端口对的延迟比使用一个端口对的延迟要低。这可以归因于设备架构,IPS传感器对每个端口对使用专用的cpu和/或网络处理器。
在UDP测试中,TippingPoint和Top Layer IPS系统再次是最快的,以行速率移动中型和大型帧。Demarc和NFR设备的速度大约是前者的一半:两者发布的数字相同,可能是因为它们使用的是相同的Bivio传感器硬件。
UDP延迟在攻击下高于基线测试,特别是在16%攻击测试中。然而,排除这一结果,两个端口对受到攻击时的延迟通常比一个端口对受到攻击时的延迟要小,这可能是由分布式处理设计造成的。
四个端口对
对于四对千兆以太网接口(因此,速率理论上能够高达8Gbps),这是对IPS性能的严峻考验。
在我们的TCP基线测试中,TippingPoint 5000E无疑是最快的IPS(见链接IPS酷刑测试,场景3,如下)。它以3.434Gbps的速度移动混合应用程序,离测试平台的理论最高速率3.8Gbps不远,大约是第二快传感器ipAngel的两倍。
IPS酷刑测试:场景3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
在我们的攻击测试中,TippingPoint 5000E再次泄漏了少量的思科利用流量,并在16%的攻击测试中禁用了日志记录。
在没有安全问题的设备中,ipAngel是最快的。在使用两个端口对进行的测试中,ipAngel的TCP转发速率随着我们提高攻击速率而降低,但另一方面,它没有泄漏任何利用流量。
大多数设备在受到攻击时都增加了HTTP响应时间,尤其是16%的攻击测试。在最糟糕的情况下,Sentarus的响应时间从基线测试的166毫秒增加到16%攻击测试的15秒以上。据德马克说,这可能是由于Bivio传感器的一个调谐参数。不幸的是,我们只有在测试结束后才知道这个参数。
TippingPoint的IPS也是我们UDP测试中最快的。在基线测试中,它以4.454Gbps的速度移动大数据包,这是我们测试中最快的单速率。在中短包的基线测试中,它也是表现最好的。