[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ISSForum] Intrusion Detection vs Intrusion Prevention
No offense meant against Toplayer or anyone.
I believe that you were not accurately informed in certain aspects.
1) Our campus's WAN link is only OC3 and there were only about 60Mbps of
traffic going through the AM when packets were dropped.
2) We didn't expect the AM to withstand 800k pps of Syn Flood. However,
it was dropping a lot of packets on our normal traffic of 13k sessions
setup per second. The drop rate was about 35% to 40%. We haven't even
gotten to testing DOS on the AM yet. The average DOS that we had
received from there internet were about 10Mbps, which translates to
about to 19,000 sessions/s.
3) You are right, the 800kpps DOS is very davastating to the network and
usually takes a chunk of the network down. Surprisingly, routers ACLs
and storm-control settings on switchs had been able to reduce these DOSs
to a reasonably manageable level. Of course, its up to the individual to
view whether the Cisco Catalyst 6500 with SFM and SUP2 is a single
device or not.
4) Our suspicion of the CPU idle issue was based on findings from our
extensive testings. Your regional support manager (Chian) with the help
of regional technical expert (Sungki) had all these testing details and
was there to observe the phenomenon as well. We had been waiting for
Toplayer to get back to us on the CPU level phenomenon but after 5
months, there still hasn't been any satisfactory answer. Your
speculation of the AM being placed in an asymetric routing situation is
totally unfounded as the AM was placed directly behind a FW which
happens to be the chokepoint and only point of entry and exit to the
Internet. I strongly suggest that you dig out all the relevant
information from your engineers before making any further speculations.
5) Load balancing is a good solution. I guess its just my personal view
that its better to look for a higher end devices than start load
balancing a group of low-end devices.
I'll like to state once again that our encounter with the AM occurred
about 5 months ago. What we experienced then may or may not be relevant
to the AM available today. These experiences were raised out merely for
the benefit of the community and potential AM customers by highlightly
certain issues that potential AM customers may want to take note of.
From: mpaquette@xxxxxxxxxxxx [mailto:mpaquette@xxxxxxxxxxxx]
Sent: Saturday, December 07, 2002 7:25 AM
Cc: Jeffrey Kok Chew Mun; SEdwards@xxxxxxxxxxxx
Subject: RE: [ISSForum] Intrusion Detection vs Intrusion Prevention
> I would like to respond to Mr. Kok's 29-Nov-02 submission
> 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
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
> 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
> 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
> 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
> 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,
> 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
> 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.
> Mike Paquette
ISSForum mailing list
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo