North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: anycast and ddos

  • From: Kim Onnel
  • Date: Fri May 06 20:50:25 2005
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LjI4mnYYrTTvkRcIhCZmftrg40SJYU7F/JJoSH9tfI9/PqNx3QkrIva6t5aMk72JcPysVrVt7xwQffoB73AQfnzTDYGIUCmrnxp5wXXz1LklSq6kYSUA8oVNOQjaz9iMJ5+SaZkgkmdtQdZv0IX3mauzzkqaP7VLVP9QEhnYV44=

I've looked around most DDoS prevention methods outhere, i can safely
say that alot of them usually just repeat each other, for me it all
boils down to

1) CoPP and aggresive SPD to protect the routing/management when
infrastructure is attacked.

2) Getting Riverhead, which is a shame if they had it and it didnt save the day.

3) Netflow to detect the attacking sources/dst and using Filtering and
blackholing methods. (Arbor, open-source tools...)

So, if they had all that in place and still they were brought down,
then i would seriously like to look for new/different solutions
applied or perhaps someone on the list could give us his experience in
a case of a heavy ddos where it was easily mitigated with the above.

Regards

On 5/6/05, Fergie (Paul Ferguson) <[email protected]> wrote:
> 
> 
> As one of the co-authors of RFC-2827, I'm assuming you
> meant me -- if so, no apology needed.  :-)
> 
> I'm just sorry to have to see a "weakness" exploited which
> could easily be "fixed"....
> 
> - ferg
> 
> ps. This also seems like a good time to mention (again)
> "The Spoofer Project" at MIT:
> 
>  http://momo.lcs.mit.edu/spoofer/
> 
> [and]
> 
>  http://momo.lcs.mit.edu/spoofer/summary.php
> 
> 
> -- Randy Bush <[email protected]> wrote:
> 
> it seems that anycasting was quite insufficient to protect
> netsol's service from being severely damaged (udp dead, tcp
> worked) for a considerable length of time by a ddos [0] last
> week [1].  it would be very helpful to other folk concerned
> with service deployment to understand how the service in
> question was/is anycast, and what might be done differently
> to mitigate exposure of similar services.
> 
> anyone have clues or is this ostrich city?  maybe a preso at
> nanog would be educational.
> 
> randy
> 
> ---
> 
> [0] - as it seems that the ddos sources were ip address
>       spoofed (which is why the service still worked for
>       tcp), i owe paul an apology for downplaying the
>       immediacy of the need for source address filtering.
> 
> [1] - netsol is not admitting anything happened, of course
>       <sigh>.  but we all saw the big splash as it hit the
>       water, the bubbles as it sank, and the symptoms made
>       the cause pretty clear.
> 
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  [email protected] or [email protected]
>  ferg's tech blog: http://fergdawg.blogspot.com/
>