[120814] in North American Network Operators' Group
Re: D/DoS mitigation hardware/software needed.
daemon@ATHENA.MIT.EDU (Rick Ernst)
Tue Jan 5 00:06:39 2010
In-Reply-To: <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com>
Date: Mon, 4 Jan 2010 21:05:53 -0800
From: Rick Ernst <nanog@shreddedmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Not necessarily an appliance, per se. But a "solution". :)
A solution preferably that integrates with NetFlow and RTBH. An in-line
solution obviously requires an appliance, or at least special/additional
hardware.
A software-only solution that sucks in NetFlow data and can speak BGP to
inject /32 routes is also good. This is essentially what I have right now.
With white-listing as a safety-net, I can chose whether traffic should be
blocked automatically or punted for human eyes/brains/fingers to be the
intelligence.
I'm interested in seeing products (including software) that already have the
development (anomaly detection, trends/reports, etc.) work done so I can
spend my cycles elsewhere.
Additional usefulness (not mentioned earlier) would be some form of API or
other hook into the system so non-NetFlow input (e.g. syslog) could generate
the /32 routes as well.
I'm looking at taking the first whack at immediate mitigation at the
border/edge (upstream) via uRPF and RTBH. Additional mitigation would be
via manual or automatic RTBH or security/abuse@ involvement with upstreams.
Thanks,
Rick
On Mon, Jan 4, 2010 at 8:41 PM, Christopher Morrow
<morrowc.lists@gmail.com>wrote:
> The original poster seemed to be asking about appliance based
> solutions, so your pointed remarks about Roland aside he was actually
> answering the question. I wonder if Stefan Fouant would offer some of
> his experience with 'not arbor' vendor solutions to be used when other
> techniques come up short?
>
