 |
|
 |
Attack Mitigator Certification Summary Security Effectiveness Detection Accuracy & Breadth This group of tests verifies that the Attack Mitigator will not block legitimate traffic (Accuracy) and is capable of detecting and blocking a wide range of common DOS/DDOS attacks (Breadth). Although breadth is extremely important, accuracy is critical because an Attack Mitigator that blocks legitimate traffic will not remain in-line for long. NSS has a huge arsenal of DOS/DDOS tools, both hardware- and software-based, in order to stress Rate-Based devices. Tests ensure that the device is capable of detecting and mitigating a wide range of rate-based attacks such as port scans, SYN floods, connection floods, and so on. Tests are repeated with both high-and low-volume attacks, and we note which of these are mitigated completely, which are mitigated partially, and which require the use of built-in firewall capabilities. Common evasion techniques such as timing delays, fragmentation and obfuscation are employed, and their effects noted Performance Any Attack Mitigator is expected to be reliable (not crash), to never block legitimate traffic, and to not unduly affect network or host system performance. The latency and throughput of an Attack Mitigation device must be on a par with other equipment in the network on which it is deployed, and in this respect, an in-line device must strive to perform much more like a switch than a typical passive security device, especially when it is necessary to install more than one appliance in the same data path. Detection/Blocking Performance Under Load This group of tests verifies that the device does not adversely impact legitimate traffic, even when new TCP connections are being created rapidly. We also verify that the sensor is capable of detecting and blocking exploits when subjected to increasing loads of background traffic up to the maximum bandwidth supported as claimed by the vendor, using a range of HTTP response sizes and packet sizes. An Attack Mitigator that misses attacks under load can be evaded. A device that adversely affects legitimate background traffic will not stay in-line for long. A fixed number of exploits are launched with zero background traffic to ensure the sensor is capable of detecting our baseline attacks. Once that has been established, increasing levels of varying types of background traffic are generated through the device in order to determine the point at which the sensor begins to miss attacks. All tests are repeated with 25 per cent, 50 per cent, 75 per cent and 100 per cent loads of background traffic up to the maximum rated throughput of the device. The tests are conducted with UDP, HTTP, and mixed-protocol traffic and include very high packet rates and TCP connection rates designed to stress the device, as well as determine its likely performance on a “typical” live network. Latency & User Response Times In any network environment latency is important. Latency may impose an upper bound on throughput and it also has an impact on interactive applications, thus affecting user response time. As such, it is important to understand the impact of latency introduced by an Attack Mitigation device and to determine the maximum acceptable delay, which will be different for each network. There is a direct relationship between latency introduced by a networking device and the maximum throughput allowed by that device on a single TCP connection. There is a critical value for the round trip time (RTT) of a packet in each network, and if the latency is below this critical value, TCP throughput will be unaffected - instead, it is the line speed of the underlying network which becomes the bottleneck. Above this critical value, however, TCP throughput is negatively impacted. To be specific, the maximum throughput achievable for any given TCP connection in a zero loss network is expressed as: throughput = window / RTT where window is the maximum TCP window size (64 Kbytes by default) and RTT is the round trip time in the network. This equation tells us that the throughput of a TCP connection is inversely proportional to network latency (note that this is TCP throughput for one connection - the aggregate bandwidth is not affected by latency). In other words, if you double latency, you halve throughput. Consider adding an in-line device in an internal Gigabit network where the RTT is 200 microseconds. The critical value for RTT in a Gigabit network is 500 microseconds (below which it may no longer be possible to achieve 1Gbps of throughput), which means the device can add a maximum of 300 microseconds to the RTT without affecting the network. In this particular case, therefore, for an internal, high speed deployment, the administrator may determine that his chosen IPS device needs to be capable of sub-300 microsecond latency under normal traffic loads. Of course, the latency of an in-line device may vary significantly based on packet size, complexity of the protocol, presence of attack traffic, or simply the makeup of the normal traffic passing through it. For example, Gigabit segments, will rarely carry only a single TCP connection. Rather, a saturated Gigabit segment could be supporting hundreds, if not thousands of TCP connections, and this multiplexing eases the impact of latency on the overall throughput on the segment. Although each of these connections carries only a fraction of the total throughput, a few connections tend to dominate. The maximum latency for a device is then determined by the utilisation of the fastest connection. For example, in a Gigabit Ethernet segment carrying 10,000 TCP connections the fastest connection might have a throughput of 250Mbps. In this case, the critical value for round trip latency is as high as 2 milliseconds. Assuming the latency without the device is 300 microseconds, an administrator may therefore determine that his chosen device must be capable of 1700 microsecond round trip latency (850 microseconds in each direction). Such critical value calculations are important when TCP connections achieve maximum throughput, which is true for large data transfers. For smaller data transfers, and non-TCP applications like NFS, latency has a more direct impact on user experience - response time is directly proportional to latency. That is, doubling latency doubles response time. In these situations, the latency of the network in which an in-line is deployed determines the acceptable latency of the appliance. Consider deploying a hypothetical Attack Mitigator with 1 millisecond one-way latency in the following scenarios:
The latency of the appliance must therefore
be evaluated in the context of the network in which it is deployed. For
example, to protect networks that are accessed over the public Internet,
one-way latencies in the 1-2 millisecond range would be acceptable. Whereas
for deployments on MAN/WAN links, latencies of well under 1 millisecond
would be essential. As we have already mentioned, for deployments on
internal networks where latencies are a few hundred microseconds, latencies
of less than 300 microseconds would be more appropriate. |
Attack Mitigator Certification:
|
Send mail to webmaster
with questions or
|