To test IPS performance, we constructed a test bed that offered traffic at multigigabit rates (see diagram). Two Spirent ThreatEx 2500 appliances offered various exploits, while two Spirent Avalanche 2500 and two Spirent Reflector 2500 appliances offered a combination of benign Web, e-mail, FTP, and DNS traffic.
All IPS systems operated in simple layer-2 bridging mode and thus were transparent to other nodes on the network. The only IP addressing used by the IPS systems was for out-of-band management ports on the sensor and/or on a separate management station.
To force traffic through an IPS, we set up untagged on two switches, and we attached all unprotected-side ports into one switch and all protected-side ports into the other. Because the IPS was the only bridging device on the test bed, it was the only path available between the unprotected and protected sides. Many IPS systems offered multiple pairs of bridge ports; for these, we configured multiple sets of VLANs on either switch.
Our performance tests measured the effects on benign traffic through each IPS while it also dealt with various exploits.
Using Spirent Avalanche traffic generators, we began with a baseline test involving a mix of TCP traffic types (along with a small amount of UDP-based DNS traffic) and measured forwarding rate and HTTP page response time. The TCP tests involved 1,500 concurrent users all asking for a mix of HTTP, FTP, SMTP, POP3 and a small amount of DNS over .
We then repeated the test using attack traffic from the Spirent ThreatEx appliances, offered at 1, 4 and 16% of the average packet rate from the baseline test. An ideal device shouldn’t have varied at all from the baseline; it should have dropped all attack traffic while forwarding benign traffic at the same rate as in the baseline.
For UDP testing, we used a Spirent SmartBits running TRT Interactive to generate 64-, 512- and 1,518-byte frames, the minimum, average and maximum lengths found in Ethernet. For each frame length, we determined throughput and average latency in a baseline test. As in the TCP tests, we then repeated the tests with varying levels of attack traffic.
Because UDP doesn’t control its own rate the way TCP does, we reduced the offered load for UDP by the rate of attack traffic to avoid any oversubscription. For example, if the UDP throughput was 100 packets per second (pps), and we attacked at 1%, we’d reduce the offered load to 99 pps. As in the TCP tests, we combined benign UDP traffic with exploits offered at 1, 4 and 16% of the UDP throughput rate.
Previous: Downsides of IPS coverage | Next: Ambiron’s ipAngel >
