Re: DDoS mitigation recommendations
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 On Jan 28, 2010 7:02 AM, "Tom Sands" <tsands@rackspace.com> wrote:
-----Original Message----- 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...
On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon <jeffrey.lyon@blacklotus.net> wrote:
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
Jeff
On Jan 28, 2010 7:02 AM, "Tom Sands" <tsands@rackspace.com> wrote:
-----Original Message----- 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...
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Thursday, January 28, 2010 11:56 AM To: Jeffrey Lyon Cc: nanog@nanog.org Subject: Re: DDoS mitigation recommendations
On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon <jeffrey.lyon@blacklotus.net> wrote:
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 ?
sessions setup/second = ddos mitigation fail ;) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
On Thu, Jan 28, 2010 at 9:22 PM, Stefan Fouant <sfouant@shortestpathfirst.net> wrote:
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Thursday, January 28, 2010 11:56 AM To: Jeffrey Lyon Cc: nanog@nanog.org Subject: Re: DDoS mitigation recommendations
On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon <jeffrey.lyon@blacklotus.net> wrote:
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 ?
sessions setup/second = ddos mitigation fail ;)
'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:
On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon <jeffrey.lyon@blacklotus.net> wrote:
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
On Jan 29, 2010, at 10:04 AM, Jonathan Lassoff wrote:
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.
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
participants (5)
-
Christopher Morrow -
Dobbins, Roland -
Jeffrey Lyon -
Jonathan Lassoff -
Stefan Fouant