The Top Layer AppSwitch 3500 is a 2U device that serves a host of functions, including routing and transparent application switching. The AppSwitch configuration GUI was intimidating at first, but it became easier after we played around in its many tabs (and subtabs). We configured the AppSwitch to serve as a router, placing the Web server and upstream router on different segments.
The AppSwitch comes ready to stop a large number of known attacks: land, smurf, fraggle, UDP bombs and SYN floods. It also handles many other traffic anomalies, such as large ICMP packets, fragments, IP options and source routing. Unfortunately our ICMP flood didn't fall into the smurf category (same as with the Foundry ServerIron), and our ICMP packets were small enough to fall under the preset ICMP maximum size option, which presumably filters out larger ping-of-death packets.
We did trigger a UDP bomb alert during our Targa attack, and of course the SYN-flood protection from the single-source address was right on. Unfortunately, the version of TopPath software (the AppSwitch OS) the 3500 uses does not alert on the random-source-address SYN flood -- yet it was filtering incoming SYNs. This can lead to a scary situation in which an admin is not alerted that the Web server is under attack or that the AppSwitch is actually dropping packets silently. Top Layer has confirmed this bug and says it is looking to fix it in a future release.
The AppSwitch takes a clever approach to SYN-flood mitigation: It acts as a kind of "IP layer proxy" whereby it will complete the TCP three-way handshake with the client before forwarding the initial SYN to the server. This means only legitimate connections are passed along, and the AppSwitch eventually drops all spoofed SYNs without their ever being seen by the target server, keeping the server from having to process the attack traffic. To do this, however, the AppSwitch has to rewrite all packets to translate appropriate TCP sequence numbers, similar to how a device would rewrite packets in a NAT (Network Address Translation) configuration, though not as extreme.
The downside is that the AppSwitch has to track every incoming connection, with a limit on how many it can track at once. This may be fine if the AppSwitch is watching only a few target systems, but it could be a problem in larger environments.
Also, the configuration we used for the AppSwitch didn't count the number of open connections (once all the SYN proxy rigmarole was done). Configuring the AppSwitch's application-switching features to limit the number of open connections to the target server may be possible, but the main attack-mitigation features do not provide for this; thus the Naptha attack went unstopped, as so did the Targa attack (aside from a few "UDP bomb attack" alarms).
Top Layer AppSwitch 3500. Top Layer Networks, (888) 327-9638, (508) 870-1300; fax (508) 870-9797. www.toplayer.com
Reactive Networks FloodGuard
Reactive Networks shipped us a FloodGuard unit installed on a 1U Dell Computer Corp. server. The FloodGuard system uses Linux under the hood and watches network traffic using network taps. FloodGuard does not sit in-line to the traffic; it mitigates by reconfiguring an upstream Cisco router via ACLs bound to the incoming router interface. We're sure that this will raise the hair on the backs of some engineers' necks, and rightfully so: Extra ACLs on the router hurt performance.
What's worse is that the peak of utilization (during a DoS attack) is the point that FloodGuard is apt to install additional ACLs -- causing abnormally higher amounts of utilization. And to boot, the mitigation potential of the FloodGuard is restricted by the limits of Cisco's ACL implementation, which doesn't allow for filtering based on specific packet parameters, such as sequence numbers, window sizes or IP IDs.
The FloodGuard approach to mitigation is two-pronged: Attempt to filter with ACLs and spoof RST packets to close incoming connections to the server during SYN floods, be they from an attack or a large burst of legitimate traffic. These RST packets were essentially the only mitigation during the Naptha and random-source SYN-flood attacks. In the end, the RSTs seemed to be spread evenly against legitimate and attack traffic alike, which indicates that once over a certain threshold, the FloodGuard will shoot down any excess SYNs with a RST.
|
Online Special
Our "DoS Dossier" gives a rundown on the types of attacks we used to test these anti-DoS devices.
Two start-ups, Asta Networks and Arbor Networks, sell anti-DoS solutions that take a different approach to attack mitigation. Read about them in "The Nonmitigators."
|
During the Naptha attack, this resulted in a haphazard traffic pattern, causing all our traffic to congeal into large sudden bursts. One of the downsides to this approach is the bandwidth it consumes: Rather than block the incoming SYN, FloodGuard sends a RST to the server, usually a little after the server sends the follow-up packet to the SYN (a SYN/ACK packet). This means that each SYN results in two more packets being put on the wire, which leads to more bandwidth being used. So what is meant to stop a flood could actually enhance the flood effect!
The ICMP flood did provoke the FloodGuard to put a deny rule for all IP packets traveling to the Web server eventually. The FloodGuard then attempted to put a few allow rules to pass the legitimate traffic. Unfortunately, the majority of the time this resulted in no traffic whatsoever being passed. Reactive says it will have this bug fixed by print time. In addition, the Targa attack did not elicit any response from the FloodGuard, apart from a few RSTs. Because the product takes a baseline of your network before protecting it, we expected it to flag UDP and ICMP packets as erroneous and suspicious.
Finally, the FloodGuard's GUI can be described only as raw. A few real-time network traffic graphs, as well as a source and destination IP address plot, grace the main GUI page, but that is all the administrator gets for analysis tools, apart from a monitor applet that contains gobs of scrolling text. Historical data is kept only in the format of raw text logs. Reactive is well aware of this shortcoming and says the next version of FloodGuard will feature a fully endowed user interface.
FloodGuard. Reactive Network Solutions, (650) 365-4000; fax: (650) 482-9390. www.reactivenetwork.com
Jeff Forristal is the lead security developer for Neohapsis, Chicago. Additional information about and follow-ups to this article are available at www.forristal.com/articles/antiddos/. Send your comments on this article to him at jeff@neohapsis.com.
RSS
