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 <randy@psg.com> 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 fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/
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) <fergdawg@netzero.net> 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 <randy@psg.com> 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 fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/
On Sat, 7 May 2005, Kim Onnel wrote:
2) Getting Riverhead, which is a shame if they had it and it didnt save the day.
riverhead has its warts, one of the larger ones is in some assumptions made about DNS client behaviour :( from first-hand experience you have to be very cautious when sticking one in front of a dns server(s), I imagine the mix gets really fun when that server(s) are really boxes with massively large lists of auth domains... Either way, without first-hand info from the attackee it's going to be tough to sort out what was and wasn't the problem... I do think that someone is going to chat about tcp/53 filtering and possibly other things DNS and ATTACK at the NSP-SEC BoF at nanog 34. -Chris
On Sat, 7 May 2005, Kim Onnel wrote:
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
And Number 4 4) Ask for help. If netsol didn't ask for help, is it a surprise they received limited amount of help?
On Fri, 6 May 2005, Sean Donelan wrote:
On Sat, 7 May 2005, Kim Onnel wrote:
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
And Number 4
4) Ask for help.
there are people out on the internet that want to help? :)
If netsol didn't ask for help, is it a surprise they received limited amount of help?
Despite the cynicism, from me not sean, it really would be 'ok' for people to ask for help from their providers when 'bad things' happen.
participants (4)
-
Christopher L. Morrow -
Fergie (Paul Ferguson) -
Kim Onnel -
Sean Donelan