[120797] in North American Network Operators' Group
Re: D/DoS mitigation hardware/software needed.
daemon@ATHENA.MIT.EDU (kowsik)
Mon Jan 4 21:23:02 2010
In-Reply-To: <d066472f1001041319r302b272dw2fdc6d8b18ce8658@mail.gmail.com>
Date: Mon, 4 Jan 2010 18:22:29 -0800
From: kowsik <kowsik@gmail.com>
To: Rick Ernst <nanog@shreddedmail.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
If you want to recreate D/DoS from captures (for testing purposes) you
might want to check out:
http://www.pcapr.net/dos
This lets you validate how your mitigation solutions are holding up.
K.
On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst <nanog@shreddedmail.com> wrote:
> Looking for D/DoS mitigation solutions. =C2=A0I've seen Arbor Networks me=
ntioned
> several times but they haven't been responsive to literature requests (hi=
nt,
> if anybody from Arbor is looking...). =C2=A0Our current upstream is 3x Gi=
gE from
> 3 different providers, each landing on their own BGP endpoint feeding a
> route-reflector core.
>
> I see two possible solutions:
> - Netflow/sFlow/***Flow =C2=A0feeding a BGP RTBH
> - Inline device
>
> Netflow can lag a bit in detection. =C2=A0I'd be concerned that inline de=
vices
> add an additional point of failure. =C2=A0I'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? =C2=A0Any other mechanisms being used? =
=C2=A0My 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 stil=
l
> need to worry about false-positives. I'd rather somebody else do the hard
> work of finding the various edge-cases.
>
> Thanks,
> Rick
>
