- 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

The Cidr Report
by Tony Bates 30 Jun '01

30 Jun '01

This is an auto-generated mail on Fri Jun 29 23:00:01 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 29Jun01 0) General Status Table History ------------- Date Prefixes 220601 101078 230601 100823 240601 100985 250601 101071 260601 101116 270601 100751 280601 100644 290601 100654 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 11095 Number of ASes announcing only one prefix: 6545 (3732 cidr, 2813 classful) Largest number of cidr routes: 1029 announced by AS701 Largest number of classful routes: 1429 announced by AS701 1) Gains by aggregating at the origin AS level --- 29Jun01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1366 1019 347 25.4% TELSTRA-AS AS701 1429 1216 213 14.9% Alternet AS4293 398 283 115 28.9% part of AS assignment AS4287 - AS AS6595 157 58 99 63.1% DoD Education Activity Network As AS705 237 141 96 40.5% part of AS assignment AS701 - AS7 AS6429 202 107 95 47.0% ATT LA Internet Chile AS7018 734 648 86 11.7% AT&T WorldNet Service Backbone AS4755 211 129 82 38.9% Videsh Sanchar Nigam Ltd. Autonom AS4151 159 77 82 51.6% part of AS assignment AS4151 - AS AS8013 300 220 80 26.7% PSINet Ltd. Canada AS13999 98 18 80 81.6% Mega Cable S.A. de C.V. AS577 246 173 73 29.7% Bell Advanced Communications Inc. AS724 238 166 72 30.3% part of AS assignment AS721 - AS7 AS6471 113 50 63 55.8% ENTEL CHILE S.A. AS7046 306 245 61 19.9% UUNET Technologies, Inc. AS3464 151 90 61 40.4% Alabama Research and Education Ne AS1 585 526 59 10.1% GTE Internetworking AS16758 63 6 57 90.5% IKON Office Solutions AS1239 446 391 55 12.3% SprintLink Backbone AS226 144 91 53 36.8% Los Nettos AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS3908 207 155 52 25.1% Supernet, Inc. AS17561 112 61 51 45.5% Internet service provision to Wes AS9842 54 5 49 90.7% Lotte Data Communication Company AS852 211 163 48 22.7% Telus Advanced Communications AS5106 82 34 48 58.5% Ameritech Advanced Data Services, AS2149 300 252 48 16.0% PSINET-2 AS15290 237 190 47 19.8% AT&T Canada IES AS855 143 97 46 32.2% part of AS assignment AS853 - AS1 AS3602 226 180 46 20.4% Sprint Canada Inc. For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Cisco IOS Vulnerability
by Larry Diffey 30 Jun '01

30 Jun '01

CERT and Cisco have issued a warning about a vulnerability in the Cisco IOS starting at version 11.3 and affecting all later versions. If your Cisco equipment is HTTP enabled and you're not using TACACS+ or RADIUS for authentication it is vulnerable to complete takeover. The hack is very simple. Please read the Cisco warning and/or the CERT advisory for further information. The warnings were released yesterday. Happy Hacker Stopping. Larry Diffey

3 2

Nasdaq Breaks Down for 2nd Day, Disrupts Trading
by Rishi Singh 30 Jun '01

30 Jun '01

New York, June 29 (Bloomberg) -- The Nasdaq Stock Market broke down for a second straight day, disrupting traders for about 90 minutes this afternoon on one of the busiest days of the year. The No. 2 U.S. stock exchange cancelled its aftermarket session. Complete story here: http://quote.bloomberg.com/fgcgi.cgi?ptitle=Top%20Financial%20News&s1=blk&tp =ad_topright_topfin&refer=topsum&T=markets_bfgcgi_content99.ht&s2=blk&bt=ad_ position1_topfin&middle=ad_frame2_topfin&s=AOz0AhxPxTmFzZGFx

4 3

Re: My apologies to the list
by Sean Donelan 30 Jun '01

30 Jun '01

On Fri, 29 June 2001, Rishi Singh wrote: > I offering a general apology to the entire nanog list. At least one > subscriber found my post about the NASDAQ outage not relevant to the charter > of NANOG. Those that don't remember the past are doomed to repeat it. The fact it was NASDAQ is not very interesting. The fact some error by a network technician disrupted a large, normally reliable is relevant to network operators. Did the network technician have a chance, make a mistake, or was it inherent to the equipment or design? Was the root cause a vulnerability that other network operators may also have in their network. The reason why NRIC and the FCC require telecommunication carriers report errors isn't to punish bad network technicians. But to identify and correct common errors which may exist in multiple carriers. Sticking your head in the sand, and not talking about it doesn't fix anything. If you do not know what went wrong with Worldcom's network, you don't know if your network may be vulnerable to the same thing. Problems in non-Internet networks have later shown up in the same equipment and operations used for the Internet.

1 0

My apologies to the list
by Rishi Singh 29 Jun '01

29 Jun '01

I offering a general apology to the entire nanog list. At least one subscriber found my post about the NASDAQ outage not relevant to the charter of NANOG. I thought it would be quite handy to a few folks who's companies, like mine have network connections directly to NASDAQ stock market along with a multitude of ECNs. I consider NASDAQ a major networked system as well, although not a public ip network, carries quite important information. In addition I am willing to guess that a lot of people on this list work for publicly traded companies who would find the news helpful. -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Friday, June 29, 2001 6:49 PM To: nanog(a)merit.edu Subject: Re: Nasdaq Breaks Down for 2nd Day, Disrupts Trading On Fri, 29 June 2001, Rishi Singh wrote: > New York, June 29 (Bloomberg) -- The Nasdaq Stock Market broke down for a > second straight day, disrupting traders for about 90 minutes this afternoon > on one of the busiest days of the year. The No. 2 U.S. stock exchange > cancelled its aftermarket session. Officials of the computerized stock market said an error by an MCI Worldcom technician led to the problems.

1 0

Re: Nasdaq Breaks Down for 2nd Day, Disrupts Trading
by Sean Donelan 29 Jun '01

29 Jun '01

On Fri, 29 June 2001, Rishi Singh wrote: > New York, June 29 (Bloomberg) -- The Nasdaq Stock Market broke down for a > second straight day, disrupting traders for about 90 minutes this afternoon > on one of the busiest days of the year. The No. 2 U.S. stock exchange > cancelled its aftermarket session. Officials of the computerized stock market said an error by an MCI Worldcom technician led to the problems.

1 0