February 2000 - Test - lists.nanog.org

Re: identifying ASN
by Ramin Sepehr Rad 10 Feb '00

10 Feb '00

On Thu, 10 Feb 2000, Mark Kent wrote: > > With all this talk of tracing attacks I just noticed that > whois -h whois.arin.net > seems to not be as informative as it used to be. > > When looking up various ASN I sometimes get the information I want, > but frequently I get: > > Sorry, you shouldn't see this record. > > or > > No match for ASN "..." > > (Sample ASes are 2855, 5400, 9057, 11486) > > Did I miss some policy change? > > -mark > > P.S. Fortunately, various radb-like entities still list > information for a lot of ASes. Hello Mark, ARIN is aware one of our servers was not reporting proper results to some WHOIS queries. This has been fixed and measures have been taken to ensure this does not occur in the future. Best Regards, ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Ramin Sepehr Rad American Registry for Internet Numbers | | raminr(a)arin.net 4506 Daly Drive | | (703) 227-9876 Suite 200 | | (703) 227-0676 (FAX) Chantilly, VA 20151 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Yahoo! Lessons Learned
by Henry Kilmer 10 Feb '00

10 Feb '00

owen(a)exodus.net writes: >> Last time I tested it, RPF would still fail if it wasn't the way >> packets would flow (not *could* flow). If that has changed, then this >> would work. >> >> >If it hasn't changed, then I think there's a pretty good case for pressuring >the various vendors to make it so. I have to admit, I always thought that >was the case, that there had to be a route out the reverse path, whether >it was preferred or not. > >Thoughts? It would definately make it more useful.

1 0

FW: identifying ASN
by Marsh, Jerry 10 Feb '00

10 Feb '00

Web to the ARIN WHOIS location and enter: ASN xxxx > ---------- > From: Mark E. Mallett[SMTP:mem@mv.mv.com] > Sent: Thursday, February 10, 2000 10:51 AM > To: mark(a)noc.mainstreet.net > Cc: nanog(a)nanog.org > Subject: Re: identifying ASN > > > > > > > > With all this talk of tracing attacks I just noticed that > > whois -h whois.arin.net > > seems to not be as informative as it used to be. > > > > When looking up various ASN I sometimes get the information I want, > > but frequently I get: > > > > Sorry, you shouldn't see this record. > > > > or > > > > No match for ASN "..." > > > > (Sample ASes are 2855, 5400, 9057, 11486) > > > > Did I miss some policy change? > > I noticed this a little while ago and reported it to noc(a)arin.net - > > 10# host whois.arin.net > whois.arin.net has address 192.149.252.22 > whois.arin.net has address 192.149.252.21 > > My perspective is that the .22 server seems to be messed up, and > that querying the .21 server gets good results. > > -mm- >

1 0

identifying ASN
by Mark Kent 10 Feb '00

10 Feb '00

With all this talk of tracing attacks I just noticed that whois -h whois.arin.net seems to not be as informative as it used to be. When looking up various ASN I sometimes get the information I want, but frequently I get: Sorry, you shouldn't see this record. or No match for ASN "..." (Sample ASes are 2855, 5400, 9057, 11486) Did I miss some policy change? -mark P.S. Fortunately, various radb-like entities still list information for a lot of ASes.

4 3

Re: Yahoo! Lessons Learned
by Vadim Antonov 10 Feb '00

10 Feb '00

Dan Hollis <goemon(a)sasami.anime.net> wrote: > The best penalty of all - simply pulling customer's plug till they fix > their network, with a repeat offense resulting in permanent disconnection. Heh. Engineering guys who try to do that very quickly find very irate sales and management types screaming abuse at them :( The DoS prevention functions (not letting directed bcast in, and not letting forged addresses out) should be done at provider's side. --vadim

17 32

Re: FBI / NIPC released a DDoSD detection tool?
by Declan McCullagh 10 Feb '00

10 Feb '00

Those binaries have been there for about a month, the same time as the Feds published the "trinoo" alert (about half a year late, but who's counting). This page has the date: http://www.fbi.gov/nipc/welcome.htm Somehow I doubt that the NIPC wrote the code. -Declan At 10:44 2/10/2000 -0600, Rodney Caston wrote: >I'm not sure if this is news or not, but looking at >http://www.fbi.gov/nipc/trinoo.htm - it seems the NIPC has released >binaries, (no source code, the jerks), for tools to detect if a box has >trin00, tribal flood net, tfn2k and some other DDoSD's on it. > >So far they have a sparc solaris, intel solaris, and x86 linux binary for >download. While I am shocked to see a government agency writing >potentially usefull code so quickly, I am dissappointed they didn't >release their source code so it can be ported to say.. FreeBSD? .. AIX .. >HP/UX ... and so on... > > >Rodney Caston >Southwestern Bell >Internet Services > >

1 0

Re: Strange announcements
by Danny McPherson 10 Feb '00

10 Feb '00

This was resultant of some left over garbage from a deomonstration I was planning to perform during the route filtering panel Tuesday morning, I had forgot about it (JUST KIDDING!!!). It's obvious that it was the result of a configuration error and it's long since been corrected. Fortunately, it didn't [completely] break anything. It does, however, serve as a nice follow-on to my comments regarding providers needing the ability to perform prefix-based filtering on a per-peer level in addition to the current "just BGP customer routes are filtered". Filtering of this level would require vendors to support hundreds of thousands of lines of ingress prefix-based filtering policies, something that's not __completely available today. Presumably, this same set of policies could also be used to perform unicast RPF-type functions WRT SA-based packet filtering. This would scope the effects of IP spoofing considerably, and remove some of the vulnerabilities regarding unauthenticated origination of BGP routes. A widely-deployed explicit acceptence model (prefix filtering) would also allow providers (who are concerned with de-aggregation and the like hosing their routers) to remove prefix-length based policies, and Save all the "rural" multi-homed folks. Of course, this also assumes that scalable backend infrastructure and systems are in place to authenticate database object entries, etc.. Then again, an SS7-type solution with backend databases and an out-of-band network populating SCPs, along with a completely static transport system, provides support for number portability, perhaps we're simply overlooking something? -danny [snip] To QWEST NOC PEOPLE Folks, You appear to be announcing 198.133.219.0, which is the network that www.cisco.com lives on, whats strange is that you are then transiting this route onto GTEI [AS1] to deliver the traffic. This is fairly sub-optimal and I'm sure incorrect. kenny>sh ip bgp 198.133.219.25 BGP routing table entry for 198.133.219.0/24, version 23258497 Paths: (4 available, best #1, advertised over IBGP) 3356 209 209.244.160.57 from 209.244.160.57 (209.244.2.210) Origin IGP, metric 4401, localpref 100, valid, external, best 3356 209, (received-only) 209.244.160.57 from 209.244.160.57 (209.244.2.210) Origin IGP, metric 4401, localpref 100, valid, external 1 109 4.1.74.105 from 4.1.74.105 (4.0.4.8) Origin IGP, metric 11340, localpref 100, valid, external Dampinfo: penalty 492, flapped 1 times in 00:00:23 1 109, (received-only) 4.1.74.105 from 4.1.74.105 (4.0.4.8) Origin IGP, metric 11340, localpref 100, valid, external kenny>traceroute www.cisco.com Type escape sequence to abort. Tracing the route to www.cisco.com (198.133.219.25) 1 serial4-0-3.hsa1.nyc1.Level3.net (209.244.160.57) [AS 3356] 0 msec 0 msec 0 msec 2 hsipaccess2.Denver1.Level3.net (209.244.2.61) [AS 3356] 48 msec 48 msec 48 msec 3 hsipaccess2.Seattle1.Level3.net (209.244.2.23) [AS 3356] 76 msec 72 msec 76 msec 4 209.0.227.130 [AS 3356] 76 msec 200 msec 148 msec 5 sea-core-01.inet.qwest.net (205.171.26.53) [AS 209] 76 msec 72 msec 76 msec 6 sfo-core-02.inet.qwest.net (205.171.5.105) [AS 209] 84 msec 84 msec 84 msec 7 sjo-core-01.inet.qwest.net (205.171.5.121) [AS 209] 80 msec 80 msec 80 msec 8 sjo-edge-05.inet.qwest.net (205.171.22.46) [AS 209] 84 msec 84 msec 80 msec 9 a5-0-1.sanjose1-nbr1.bbnplanet.net (4.24.145.1) [AS 1] 84 msec 84 msec 84 msec 10 p4-0.paloalto-nbr2.bbnplanet.net (4.0.1.1) [AS 1] 84 msec 84 msec 84 msec 11 p0-0-0.paloalto-cr18.bbnplanet.net (4.0.3.86) [AS 1] 84 msec 84 msec 84 msec 12 * * * 13 pigpen.cisco.com (192.31.7.9) [AS 109] 88 msec 88 msec 88 msec 14 www.cisco.com (198.133.219.25) [AS 209] 88 msec 84 msec 88 msec A fix/explanation would be useful. Regards, Neil. -- Neil J. McRae C O L T I N T E R N E T neil(a)COLT.NET

1 0

[fwd] SANS Security Technology Leadership Awards
by Paul Ferguson 10 Feb '00

10 Feb '00

A couple of useful references. - paul [snip] >Date: Wed, 9 Feb 2000 23:15:40 -0700 (MST) >From: The SANS Institute <sans(a)sans.org> >Subject: SANS NewsBites Vol. 2 Num. 6 [snip] >Congratulations to the winners of this year's SANS Security Technology >Leadership Awards: > >Dave Dittrich of the University of Washington and Marcus Ranum of Network >Flight Recorder for developing and distributing a network scanner that >finds trin00 and other distributed denial of service attack tools. >http://www.staff.washington.edu/dittrich > >Eric Kayden of MITRE and Steve Schmidt of the National Infrastructure >Protection Center and their teams for developing and distributing a >system scanner that searches for trin00 and other distributed denial of >service attack tools. http://www.fbi.gov/nipc/trinoo.htm > >John Green of the Naval Surface Warfare Center and Laurie Zirkle of >Virginia Tech University for creation of the document, "Handling A >Distributed Denial of Service Trojan Infection: Step-by-Step." >http://www.sans.org/y2k/DDoS.htm > >Robert Stone and Mark Krause and their team at UUNET for developing >CenterTrack, the tool that Internet Service Providers will use to find >the source of forged IP packets employed in distributed denial of service >attacks. http://www.nanog.org/mtg-9910/robert.html > >Steve Christey, Dave Mann, Mary Zuk, Pete Tasker, and the staff at MITRE >for establishing, nurturing, and sustaining the industry-wide cooperative >CVE (Common Vulnerabilities and Exposures) project that enables accurate >comparisons of vulnerability analysis tools and summaries. >http://cve.mitre.org/ > >The awards, including plaques and financial stipends will be presented >on March 24 at SANS2000 in Orlando. [snip]

1 0

Re: Yahoo! Lessons Learned
by Paul Ferguson 10 Feb '00

10 Feb '00

At 10:12 PM 02/09/2000 -0500, jlewis(a)lewis.org wrote: >Even though the RPF knob is there, there's lots of gear running code that >either doesn't have it or blows up when it's pulled. Well, I never said it was a panacea. :-/ - paul

1 0

Re: Info on the DoS attacks.
by Declan McCullagh 10 Feb '00

10 Feb '00

From my perspective, corporations are filtering information through clueless PR flacks to a (relatively clueless) media. I can't buy that sites hit by an attack 48 hours ago "have no idea what is going on." If that's the case, some people need to be fired real quick. -Declan At 21:24 2/9/2000 -0600, Rodney Caston wrote: >It's because people are being very closed mouthed with this, the corps >either have no idea what is going on or do not wish to share what they >know, and those involved with the attacks have done a good job of keeping >silent. Besides comparing Morris's worm to what is going on now is hardly >fair, the net was a very different place then, and his cpu cycle hog of a >program was alot easier to deal with and detect.

4 3