[120826] in North American Network Operators' Group
RE: D/DoS mitigation hardware/software needed.
daemon@ATHENA.MIT.EDU (Stefan Fouant)
Tue Jan 5 00:44:47 2010
From: "Stefan Fouant" <sfouant@shortestpathfirst.net>
To: "'Suresh Ramasubramanian'" <ops.lists@gmail.com>,
"'Dobbins, Roland'" <rdobbins@arbor.net>
In-Reply-To: <bb0e440a1001042119m740d4628l6732bd14ba1d83c5@mail.gmail.com>
Date: Tue, 5 Jan 2010 00:39:46 -0500
Cc: 'NANOG list' <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> -----Original Message-----
> From: Suresh Ramasubramanian [mailto:ops.lists@gmail.com]
> Sent: Tuesday, January 05, 2010 12:19 AM
>=20
> On Tue, Jan 5, 2010 at 10:38 AM, Dobbins, Roland <rdobbins@arbor.net>
> wrote:
> >
> >> Additional mitigation would be via manual or automatic RTBH or
> security/abuse@ involvement with upstreams.
> >
> > Automagic is generally bad, as it can be gamed.
>=20
> ... and manual wont scale in ddos
There are pros and cons to each approach. Certain types of things can =
be automated, in fact I've done this using the Auto-mitigate feature in =
Arbor coupled with pre-configured mitigation templates for certain types =
of traffic and it works very well. But generally, as Roland mentioned =
automagic stuff can be gamed and for the majority of the stuff you are =
going to want an operator to look at the alert before making the =
decision to offramp.
The trick is to try to automate as much around the process as possible - =
I've worked in environments where just making little changes to incident =
handling response methods reduced the time to mitigate an attack from =
hours to minutes, all the while still requiring an operator to press the =
"big red button" to offramp and enable the mitigation.
Stefan Fouant, CISSP, JNCIE-M/T
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
