Hi All,
> I would like to respond to Mr. Kok's 29-Nov-02 submission regarding
> the Top Layer Attack Mitigator security appliance. I will try to be
> objective in my reply, however you should note that I work for Top Layer.
>
First of all, the AM is successfully deployed in many gig-attached
networks of similar size to his network. That said, Mr. Kok is correct
that, like any stateful inspection device, there are performance
limitations in Top Layer's Attack Mitigator. His assessment of some of
those characteristics is reasonably accurate for the version of the product
he was running at the time.
> He is also correct that there may be some Gigabit links that have
> too much traffic for one Attack Mitigator appliance to handle. Although
> the single appliance Attack Mitigator does indeed have Gigabit Ethernet
> connections (to allow for Gig E connections from Routers and Switches), it
> is rated for use on OC-3 and lower speed links.
>
> He is again correct that a SYN Flood of 800K SYNs/sec can overload a
> single Top Layer Attack Mitigator. In fact, this is a very large SYN
> flood, filling almost an entire OC-12 worth of bandwidth with minimum size
> packets. Indeed this must be devastating to his network when this type of
> attack takes place. I do not know of an effective one-box solution that
> can address a SYN flood of this magnitude, while still letting legitimate
> connections through. Does anyone else know of such a solution?
>
> Finally, Mr. Kok is again correct that the version of Attack
> Mitigator used in his trial was not able to block fragmented versions of
> URI attacks such as Code Red and Nimda. This feature has been radically
> enhanced in our latest version, available worldwide, and now blocks
> fragmented URI attacks effectively.
>
> However, Mr. Kok is mistaken regarding his assumptions about the CPU
> utilization on the Attack Mitigator, and his overall conclusion about the
> applicability of the device in busy networks. Due to the AM's
> architecture, the CPU utilization DOES provide an accurate indication of
> how busy the system becomes dealing with forwarding traffic, mitigating
> SYN flood attacks, and setting up and tearing down connections used in the
> stateful inspection. The fact that the CPU utilization was low would
> indicate that his network was NOT overloading the throughput, connection
> setup/teardown, or SYN flood mitigation capabilities of the Attack
> Mitigator.
>
> The far more likely scenario is that the Attack Mitigator was placed
> into his network in a position that had asymmetrically routed traffic
> (that is, responses may traverse a different path than requests). Like
> any fully stateful device, the Attack Mitigator must see all traffic from
> both directions of a conversation in order to work properly. When placed
> on a single leg of an asymmetrically routed network, for example, a
> stateful device may not see the closing of TCP connections, and thus uses
> up its system resources until the connection record can be timed out due
> to inactivity. In a busy network such as the one Mr. Kok describes, a
> misconfigured stateful device can fill up its own stateful inspection
> tables in a very short time, causing additional problems such as the ones
> his users experienced.
>
> The suggestion that Top Layer made for a multi-box solution was not
> ridiculous, but instead is a clever way to resolve the asymmetric traffic
> handling to allow stateful devices such as the Attack Mitigator to operate
> correctly, and in a distributed scalable manner to address even the very
> largest attacks such as the ones that Mr. Kok describes on his network,
> while not compromising availability.
>
> Thanks,
> Mike Paquette
>
>
_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo
