With Guard appliance and 65xx module being EoL'd, and Cisco's desire to exist the DDoS mitigation market, I'd like to get some recommendations of what other products people are having good success with.
We are looking for something that can support 3Gbps - 10Gbps, multi-tenancy, seamless integration, and many of the basic features you'd see on the Guard.
Thank you,
Arbor stuff comes to mind and works very well in our experiences....
Arbor++
One more for Arbor.
We've already done an initial trial with the Arbor device, and it does work well. Our biggest sticking point with it is that it lacks the granular level of visibility and control that we've been used to and often needed to tweak profiles. Basically, it does what it's supposed to well, but you really can't tell what that is, and if it's not catching all of a DDoS you have little insight as to what's being missed or control to correct it.
Thank you,
Tom Sands
Chief Network Engineer
Rackspace
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@rackspace.com, and delete the original message.
Your cooperation is appreciated.
IntruGuard is highly customizable both from the GUI and CLI with the
engineer's assistance. Its the highest performance, reasonably priced box
that we've tried so far.
Jeff
From: David Freedman [mailto:david.freedman@uk.clara.net] Sent: Tues...
We've already done an initial trial with the Arbor device, and it does work
well. Our biggest sticking point with it is that it lacks the granular
level of visibility and control that we've been used to and often needed to
tweak profiles. Basically, it does what it's supposed to well, but you
really can't tell what that is, and if it's not catching all of a DDoS you
have little insight as to what's being missed or control to correct it.
Thank you,
Tom Sands
Chief Network Engineer
Rackspace
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intend...
IntruGuard is highly customizable both from the GUI and CLI with the
engineer's assistance. Its the highest performance, reasonably priced box
that we've tried so far.
'highest performance' == 100mbps on a 1gbps copper interface? or
sessions setup/second? or remote-addresses tracked? or ?
-chris
sessions setup/second = ddos mitigation fail 
Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
'unqualified adjectives == fail' ... or 'lies, damned lines and
statistics' or 'pls to be qualifying your statement with some useful
data'
-chris
Excerpts from Christopher Morrow's message of Thu Jan 28 08:55:34 -0800 2010:
> IntruGuard is highly customizable both from the GUI and CLI with the
> engineer's assistance. Its the highest performance, reasonably priced box
> that we've tried so far.'highest performance' == 100mbps on a 1gbps copper interface? or
sessions setup/second? or remote-addresses tracked? or ?
Indeed, the only IntruGuard products I can see on their site appear to
be some sort of active inspection device that support 100 and 1000
Mbit/s of traffic.
Being able to task a device to inspect the data in every packet is
wonderful. It allows a properly-controlled system to be able to create
statistics, capture traffic, and deeply-inspect traffic.
But then you're putting all that traffic through a CPU-bound chokepoint,
no?
I suppose one could use some sort of ECMP or link aggregation and split
that traffic over several inspection devices, but at some point you're
bound by the maximum number of paths (Anyone know if all vendors have a
limitation of max. links per group?)
If one wanted to increase the breadth of this fanout, they could add
layers of routers, all fanning out n*n equal-cost paths.
Add n*n inspection devices to the bottom of this tree.
At todays traffic levels in larger ISPs, adding all this hardware can
become expensive to maintain enough capacity.
And this, I think, is the crux of why hardware-based traffic traffic
inspection and filtering is, at a certain scale, far more efficient at
finding abberant network behavior and squashing it at your edge (or even
at your upstream's network edge).
It can leverage network routing hardware you already have to measure
traffic and to redirect it as necessary.
Something utilizing sflow/netflow and flowspec to block or direct
traffic into a scrubbing box gets you much better bang for your buck
past a certain scale.
Cheers,
jof
Out of curiousity, what's your baseline or "that we've been used"?
tv
This is absolutely key for packet-flooding types of attacks, and other attacks in which unadulterated pathological traffic can be detected/classified in detail, with minimal collateral damage. Everyone should implement S/RTBH and/or flow-spec whenever possible, this cannot be emphasized enough. Operators have made significant investments in high-speed, ASIC-powered routers at their edges; there's no reason not to utilize that horsepower, as it's already there and paid for.
For situations in which valid and invalid traffic are highly intermixed, and/or layer-4/-7 heuristics are key in validating legitimate traffic and invalidating undesirable traffic, the additional capabilities of an IDMS which can perform such discrimination can be of benefit. As mentioned in a previous thread, it's possible to construct a base-level capability using open-source software, and commercial solutions from various vendors [full disclosure: I'm employed one of said vendors] are available, as well.