|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: engineering --> ddos and flooding
Hot Diggety! Andrew Dorsett was rumored to have written: > > Hey, this is a technical question for all of the Network > Engineers/Architects on the list. Has a method been found to stop an > incoming attack? Granted you can filter the packets to null on the router, Part of the problem is that sources can be easily spoofed... or if not spoofed, coming in from so many actual machines at once (DDoS)... or both! Spoofed source is somewhat easier to handle with stuff like shortened timers for holding in an accept queue and constant queue flushes (amongst other techniques such as mathematical algorithms to detect bogus stuff) on a host machine. Mr. Steenbergen outlines a variety of practical approaches that can be done to ward off or minimize the damage of a [D]DoS attack at: http://www.e-gerbil.net/ras/projects/dos/dos.txt Some on victim end, some on ISP end, some on host end, some on network device end, and so forth. > but that doesn't stop them from coming across the wire and into the > router. Has a way been devised to stop them from coming into the router; > via something like a BGP update to null the packets or what? I'm concerned > about a flood that is so massive coming from the core and flooding a small > T1 or less. Someone pointed out an interesting (and detailed) story about a nasty DDoS attack. It's unlike most others because the victim was a technically astute individual and quickly figured out contents of the traffic, the tools used, crafted a response, learned IRC on the fly, and so forth. He's indicated that he's working on a tool called Spoofarino. For the full story behind his detailed post-attack analysis: http://grc.com/dos/grcdos.htm Talks about the attacker, motivations, ISPs' now familiar variety in responses, the government, the law, technical analysis, and some more. That's Steve Gibson of Gibson Research -- should be a familiar name to quite a few folks in the PC industry. While it doesn't really directly answer your question... it's certainly some interesting food for thought. Kind of long reading, but can be read in 15 minutes. :) The story also certainly validates the other points made in this thread: a) the victim, being target of aggregated traffic, is best end to determine source and profile; b) relying on ISP cooperation to trace or stop an attack is difficult at best so any real improvements would need to be done through some protocol extension (or new protocol) to allow an individual to do some sort of end to end tracing or accountability. I, too, am much looking forward to the proposed standards to turn this kind of thing into a non-event. :) -Dan
|