[120783] in North American Network Operators' Group
Re: D/DoS mitigation hardware/software needed.
daemon@ATHENA.MIT.EDU (Rick Ernst)
Mon Jan 4 17:00:28 2010
In-Reply-To: <d066472f1001041319r302b272dw2fdc6d8b18ce8658@mail.gmail.com>
Date: Mon, 4 Jan 2010 13:59:50 -0800
From: Rick Ernst <nanog@shreddedmail.com>
To: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Several responses already, and Arbor has poked their head up.
I'm going to start there and keep the other suggestions at-hand.
Thanks,
On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst <nanog@shreddedmail.com> wrote:
>
> Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned
> several times but they haven't been responsive to literature requests (hint,
> if anybody from Arbor is looking...). Our current upstream is 3x GigE from
> 3 different providers, each landing on their own BGP endpoint feeding a
> route-reflector core.
>
> I see two possible solutions:
> - Netflow/sFlow/***Flow feeding a BGP RTBH
> - Inline device
>
> Netflow can lag a bit in detection. I'd be concerned that inline devices
> add an additional point of failure. I'm worried about both failing-open
> (e.g. network outage) and false-positives.
>
> My current system is a home-grown NetFlow parser that spits out syslog to
> our NOC to investigate potential attacks and manually enter them into our
> RTBH.
>
>
> Any suggestions other than Arbor? Any other mechanisms being used? My
> idea is to quash the immediate problem and work additional mitigation with
> upstreams if needed.
>
> I could probably add some automation to my NetFlow/RTBH setup, but I still
> need to worry about false-positives. I'd rather somebody else do the hard
> work of finding the various edge-cases.
>
> Thanks,
> Rick
>
>
