- NANOG - lists.nanog.org

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

Compromised boxes
by Sean Donelan 10 Feb '00

10 Feb '00

On Wed, 09 February 2000, lucifer(a)lightbearer.com wrote: > (BTW, the box in question was taken off-net, and is currently being given > the scorched-earth treatment; the person in question will be undergoing > education in security principles from a veteran operator, and realizes > that the compromise was made possible by their own negligence... now.) Of course those are their boxes to do what they want with. But if anyone does have a compromised box involved in the current round of DDOS, please don't "scorch" it. Assuming you don't mind losing your equipment for a while, give your local FBI office a call and ask if they want to look at it. They'll tell you whether to leave it running, shut it down gracefully, or just yank the power cord. Hopefully the FBI will work and play well with others, and not do annoying things like seize equipment. They've said they wanted to create a "partnership" with the community before, but maybe this time they mean it.

5 4

Re: Data Center design.
by Sean Donelan 10 Feb '00

10 Feb '00

On Wed, 09 February 2000, foo wrote: > I'm wondering if there are any mailing lists or other resources concerning > building, designing, and maintaining Data Centers. Try datacenter(a)shorty.com (majordomo(a)shorty.com) > I've found some vaguely helpful resources from netsearches, but so far > I've been pretty disappointed with the amount and level of the available > information. Are there any books? Any respected "authorities"? Is everyone > learning as they go, or are all of the new Internet DC's being built by > old-school mainframe/datawarehouse types? When doing research on the web, only bits and pieces of information from before 1992 are on the web. So you need to look other places in addition to the web. A great source I've found is going to a local public or university library and asking for the government documents section (GOVDOC). Their documents cover many aspects of designing, building and maintaining data centers and lots of other things. However you may have to think creatively to find the information. For example, if you want to know what type of exterior lights to use, think of Illumination Considerations For Nuclear Storage Areas. You will want to scan at least the FIPS index for computer topics. Be prepared to use a microfilm and microfiche reader. Remember there are assumptions in the documents. In particular older data center design existed in a world of batch processes. Computers were extremely expensive, and brief service interruptions were acceptable. In today's world computers are cheap, and interruption of service is very expensive. This affects core elements of the design. Other sources include vendors such as IBM, Liebert, Telcordia and groups like ANSI, ASHRAE, BICSI, IEEE, NFPA, UL, etc, etc, etc. Again be careful about understanding the assumptions. Handing a set of old standards to an architect and saying build me a data center is the worst thing you can do. You will get exactly what you asked for, but not what you wanted.

1 0