July 2001 - Test - lists.nanog.org

Re: So.. you want to track some DoS traffic?
by Richard A. Steenbergen 01 Jul '01

01 Jul '01

On Sun, Jul 01, 2001 at 05:34:06PM -0400, Christopher L. Morrow wrote: > > A brief overview of the method would be: "Track the attack from the > after effect of the attack, not the attack itself" Hrm interesting combination of two different techniques... Your border filter method is more commonly done with a community tag which triggers the route-map setting nexthop to a null routed IP block. You can even allow your customers to null route their own IP space within your network without them having to get in touch with your security people. The "backskatter" you are monitoring makes a nice hack for gathering information from many routers which don't support this kind of intelligent mass-management on their own. You could also setup a dedicated sniffing machine or machines and alter the nexthop to route the original DoS their way, if you want to find out details of the attack. It would also be interesting, especially on a UU scale, to do statistical sampling of backskatter generated by the victim instead of that generated by your routers. I'd also be interested in seeing someone setup a global realtime backskatter analysis just for a kind of "DoS weather report". Of course you should probably mention the only global analysis of spoofed attacks by the replies generated to their attacks I am aware of, at: http://www.caida.org/outreach/papers/backscatter/index.xml If you provided a customer community tag so your clued victims could do it theirselves, you could automatically monitor the ICMP Unreachables and already have a list of the ingress interfaces ready without any human interaction, kindof like the Call Trace functionality for phones which records the information for easy processing if charges are filed. If enough other networks did this you could probably stand a half decent chance of catching an attack that is shorter then the "few hours" normally required to get interprovider cooperation. If you really wanted to get nuts, this could fairly easily be packaged up into a program which runs on a unix machine and automatically cooperates with other providers running this service to trace spoofed attacks back to their source. Of course this is all a nasty hack around the lack of a protocol for communicating traceback and source-filtering information directly between routers, but I suspect this method would be a lot easier to actually get written, deployed, and used because of layer 8. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

So.. you want to track some DoS traffic?
by Christopher L. Morrow 01 Jul '01

01 Jul '01

First off, everyone already should know that these views are mine, not UUNET/WCOM/UUcom's... Ok, with the recent craziness on NANOG about DoS Attacks, spoofed packets, tracking attacks and other DoS related junk I figured I'd post out a quicky tracking method that does NOT require hop-by-hop tracking. This method works will pretty much all spoofed attacks (synfloods/smurfs for instance). A brief overview of the method would be: "Track the attack from the after effect of the attack, not the attack itself" A link to the details, which includes cut/paste router config bits for Cisco and Juniper routers. I'd include other router vendor cut/paste but I only had time to figure out the two included... if someone wants to post proper other configs (verified hopefully) I'll add them in also. Link: http://www.secsup.org/Tracking/ Credit: Credit should go to those listed in the link, UUNET's TAC-Eng group, UUNET's Net-Sec group, UUNET's Customer Router Security Group, dies(a)pulltheplug.com and a few others I have forgotten. The goal of posting this info out to NANOG is to get other backbone's to implement this so attacks can be traced in less time and with less effort by all parties. I can succesfully track an attack across my backbone in under 2 minutes with this method where the hop-by-hop has taken me over 8 hours in extreme circumstances (as Paul Vixie can attest since he waited on the call while I did it). Suggestions for improvement or deletions to these procedures would be welcome as well. Thanks, --Chris (chris(a)uu.net)

1 0

Choosing Peering vs Transit
by EA Louie 01 Jul '01

01 Jul '01

List - I'm curious as to how one chooses to Peer versus buy Transit in the Internet. What are the determining factors, if I were to start an ISP, on which I would do to get my network recognized by the Internet and how I would get my customers out into the backbone. thanks Eric

3 2

Procedural Outage Reduction Report
by Sean Donelan 01 Jul '01

01 Jul '01

> "Routine testing" could well mean "our most junior technician > was told to clean up the mess of cables, and one fell out." > I'm sure that's happened to everyone here.... I do not know what happened inside Worldcom. However, when human error is identified as the cause, always ask yourself did the human have a chance? Often it seems like the junior technician is made the scapegoat for inadequate supervision, equipment or training. ATIS and NRIC have identified "procedural errors" as an area of increasing concern for the reliability of the telecommunications network. Through the mandatory FCC reporting mechanism, ATIS and NRIC have identified common errors and recommended changes across carriers. You can read their recommendations at http://www.atis.org/atis/nrsc/nrschome.htm Well, you could, if the links on ATIS' web site actually worked. ATIS has no legal authority, and neither Worldcom nor any other carrier has to follow (or even read) its recommendations. But Internet Service Providers should be aware of the Lessons Learned (the hard way) in other industries.

1 0