If we didn't know better, we would say the 5U Foundry ServerIron 400 is actually a Cisco product. Why? Because the ServerIron 400 command-line configuration bears an uncanny resemblance to Cisco IOS. This should make all you CCIE types feel right at home with the ServerIron. We were grateful for the command line because it allowed us to enter our five simple configuration commands manually, sparing us a painstaking navigation through the Web GUI that would have involved more than a dozen menus and submenus.
To enable SYN-flood protection, we had to set up a virtual Web server with load-balancing. This led to a unique situation that makes grading difficult: The attacks were run against a virtual load-balancing Web service posed by the ServerIron, not against the Web server itself. This means that, for example, all the anomalous packets sent during the Targa flood never make it to the Web server; instead they were "absorbed" by the virtual server's IP stack.
We avoided using any type of load-balancing or virtual host setup on other devices because of the additional complexity and issues of fairness (not all devices featured virtual load-balancing hosts). For the ServerIron, however, achieving SYN-flood protection was necessary. This type of configuration is very similar to a proxy, so the target of the attack is not the final Web server but the proxy. Therefore we must consider the ServerIron's response to some attacks, even though the attack didn't make it to the final Web server itself.
The ServerIron is documented to handle two specific DoS flood attacks: smurf and SYN. The smurf-attack mitigation, while stopping ICMP traffic, did not stop our ICMP flood for a specific reason: Our ICMP flood sent ICMP-echo requests; a smurf attack would result in a mass quantity of ICMP-echo replies. However, the ServerIron does have a rate-limiting feature, which did stop it from sending ICMP-echo replies in response to the flood of incoming echo requests.
The device handled the SYN floods as expected: Once a certain threshold of incoming SYNs was reached, the ServerIron stopped incoming SYNs for a set period. This led to a floodgate-style mitigation, with drawbacks similar to the FireProof's. The virtual Web host configuration let us set a maximum connection limit for our Web server, which helped save the server from connection overflow by the Naptha attack but caused it to drop all further incoming connections.
The anti-DoS features of the ServerIron are nice, but DoS attack mitigation is not the main goal of the ServerIron. If you're looking for an application load-balancing switch, DoS mitigation is a useful extra feature to have -- and the ServerIron definitely has it. But we do not recommend a ServerIron solely for your DoS problems.
ServerIron 400. Foundry Networks, (888) TURBOLAN, (408) 586-1897; fax (408) 586-1900. www.foundrynetworks.com
Captus Networks CaptIO G-2
The Captus CaptIO has a special place in our hearts: It's the only device we've ever encountered that features ASCII diagrams (and elaborate ones, at that) for configuration via the command line. But don't worry -- a full GUI is available for those of you who shy away from the CLI (command-line interface).
The CaptIO owes its magic to TLIDS, an engine that lets you configure various "rules" to describe how to monitor and mitigate your traffic. Of course, someone has to program the CaptIO using TLIDS rules before it will protect your networks. Luckily, the language syntax is simple and intuitive, and Captus offers training in the writing of TLIDS rules. The CaptIO purchase price includes an on-site visit by a Captus product engineer to program the correct rules for your environment. We used a set of general rules recommended by Captus to all its customers, modified slightly to fit our environment.
Although the CaptIO has a good engine, it lags on the reporting front. The only options for alerts are to check the internal syslog periodically or to use an SNMP trap/poll. There are also no traffic breakouts, data analysis or graphs, apart from simple interface-usage statistics. In fact, Captus is the only pure anti-DoS vendor that didn't feature traffic-analysis graphs or tools.
This lack of real-time graphs or packet-review tools didn't stop CaptIO from mitigating our attacks, though. Our ICMP flood was quickly caught and dealt with by our ICMP rate-limiting rule. The single-source SYN flood was also dealt with swiftly; however, the spoofed source SYN flood didn't get noticed. This illustrates the downside of the CaptIO: Mitigation is only as good as the rules that are programmed into it. In our case none of our rules dealt with spoofed-source SYN floods, and we tried our hand at creating some, to no avail. Mitigating this type of attack with the proper rule may be possible, but since we used rules recommended by Captus, we chalked it up as a loss and moved on. Our Naptha attack was unhampered because the CaptIO doesn't count open connections. The CaptIO was able to catch some superfluous UDP and ICMP traffic generated by the Targa attack, so the amount of attack traffic was lessened noticeably.
CaptIO G-2. Captus Networks, (877) 922-7887, (530) 406-3500; fax (530) 406-3406. www.captusnetworks.com
REPORTS
ANALYTICS
Follow 
