- Test - lists.nanog.org

AT&T national cable outage
by Sean Donelan 15 Apr '00

15 Apr '00

According to AT&T's cable service recording, AT&T Cable Services is experiencing a national outage with their digital cable service. Since I don't have cable @Home, I can't tell if it is only affecting the video services or also the Internet service.

3 2

Re: NSI's registrar db hacked
by Rodney Joffe 15 Apr '00

15 Apr '00

bill(a)daze.net wrote: > Nothing new here. Network Solutions has known about the MAIL-FROM problem > for years, yet they refuse to do anything about it. Doh. Didn't realize it was the same old thing. This seems like such a trivial problem to solve... a) force guardian (crypt-pw seems the most reliable) on all new domain registrations b) with NSI's next spam to their customer database, lead people forcibly to guardian (crypt-pw again) c) use a mail system that scales, so that 1 week delays don't happen. One good thing I've noticed in the last week or so - if someone attempts to register a domain, or modify a domain, to use your nameservers, your nameserver contacts get an email. Of course, in typical NSI style, the email is non-intuitive. And in typical NSI style, although it says you must "ack" for it to go through, it goes through anyway. But it's a start... at least you know that someone is trying to use your dns. -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(SM)

5 5

Re: DVWSSR.dll Vulnerability in Microsoft IIS 4.0 Web Servers (fwd)
by Vincent Power 14 Apr '00

14 Apr '00

-- +---------------------------------+-----------------------+ | Vincent Power | mailto:vince@mha.ca | | Senior System Administrator | Cell: +1 604 817 4284 | | Macdonald Harris and Associates | http://www.mha.ca/ | +---------------------------------+-----------------------+ ---------- Forwarded message ---------- Date: Fri, 14 Apr 2000 15:32:52 -0400 From: Russ <Russ.Cooper(a)RC.ON.CA> To: NTBUGTRAQ(a)LISTSERV.NTBUGTRAQ.COM Subject: Re: DVWSSR.dll Vulnerability in Microsoft IIS 4.0 Web Servers Ok, here's a breaking update. Latest reports say that there is NO VULNERABILITY IN DVWSSR.DLL Yup, that's right, different again from what I said earlier, and even more different than what I said yesterday to WSJ. Please accept that I have followed the story published elsewhere and tried to keep you abreast of everything I knew. Also appreciate that the amount of time given to verify and research the claims made by others has been extremely short. I've had probably 30 interviews today by orgs pressing for information on the story as the feeding frenzy occurs after the first one goes to press (WSJ in this case). MS have had people working on this thing like madmen, trying to verify the claims and investigate all of the possible pieces of code that may be affected. As that research progressed, different observations were made and so the story came out in various stages (with varying levels of "correctness"). Had they been given a reasonable amount of time to respond, nobody would have been in a tizzy about anything (i.e. the press would not have cared to run this story anywhere). Decide for yourself whether we were better served by (more) immediate disclosure or not. I've stood where I stand for a reason, despite the loathing of others for my stance... In the end, it turns out that unless you actually have permissions for the file you are requesting, you'll get an error message when you follow the procedures outlined by RFP in his RFP2K02 advisory. That said, understand that sites that allow connections by Front Page may very well provide you with source asp if you request it. BUT THAT WILL HAPPEN with or without the .dll. Without proper and full permissions applied across virtual servers on a given box, site leakage or manipulation by others will always be possible in myriad ways. >From what I've heard/seen/been told, permissions on the test servers must have either been non-existent, incorrectly applied, or permissioned the user across multiple virtual sites (i.e. incorrectly applied). I had someone claim that they could get into an FP98 site using "Netscapeengineersareweenies!" as a userID and no password...making them think it was a backdoor userID. Fact is they could get into the same sites using "TomDickandHarry" as a userID too. If the permissions aren't set correctly, anything is possible. This info may change again before its finalized. It may well be that there is some way to use this .dll in a way that's not intended...it just doesn't appear to be this one. On a box where multiple sites have not been individually permissions, or permissions are lax or non-existent...anyone permissioned to execute the .dll in the first place would have the ability to simply open the other sites and manipulate them directly (i.e. no need to do this junk with the dvwssr.dll) Finally, to my point out the string not being a password. Elias Levy of SecurityFocus.com and Mark Edwards of NTSecurity.net have both correctly pointed out that using the term password to apply to that string is not beyond the realm of understanding. The client component mtd2lv.dll and the server component dvwssr.dll both need to know this value, and use it correctly, for communications to work. If you try and talk directly to dvwssr.dll and don't obfuscate your communication with the correct "key", it won't understand you. Of course if you don't already have permissions, knowing this value gets you nothing...hence my observation that its not a password. Whatever it is, it appears to be meaningless junk text used as data. Cheers, Russ - NTBugtraq Editor "dot-age" (as in "we're in the dot-age") = senility (source Webster's)

1 0

RE: NetSol screwing the pooch?
by Newell, Tom 14 Apr '00

14 Apr '00

Eric, if you would have looked at the NS set for COM (instead of the NS set for .), you would have found that authoritive hosts for COM are: com. 6D IN NS A.ROOT-SERVERS.NET. com. 6D IN NS G.ROOT-SERVERS.NET. com. 6D IN NS F.GTLD-SERVERS.NET. com. 6D IN NS F.ROOT-SERVERS.NET. com. 6D IN NS B.ROOT-SERVERS.NET. com. 6D IN NS I.ROOT-SERVERS.NET. com. 6D IN NS E.ROOT-SERVERS.NET. com. 6D IN NS J.GTLD-SERVERS.NET. com. 6D IN NS K.GTLD-SERVERS.NET. com. 6D IN NS A.GTLD-SERVERS.NET. com. 6D IN NS H.GTLD-SERVERS.NET. com. 6D IN NS C.GTLD-SERVERS.NET. ...and their serials are: Server COM. Operator a.root-servers.net 2000041301 NSI g.root-servers.net 2000041301 DOD f.gtld-servers.net 2000041301 NSI f.root-servers.net 2000041301 ISC b.root-servers.net No answer ISI i.root-servers.net 2000041301 Sweden (Royal Inst of Tech) e.root-servers.net 2000041300 NASA j.gtld-servers.net 2000041301 NSI k.gtld-servers.net 2000041301 NSI a.gltd-servers.net 2000041301 NSI h.gtld-servers.net 2000041301 NSI c.gtld-servers.net 2000041301 NSI So in every case where NSI operates the host NS for COM, you should see that the serialization is correct. In those cases where a traditional root server still serves COM, should they get out of synch, our NOC contacts them to encourage resolution. However, as the host is not an NS operated by NSI, beyond encouraging them to fix the problem, there is little we can do. This is part of the reason for moving COM off of the traditional roots in just the same fashion as other first level delegations are managed today. Tom > -----Original Message----- > From: Eric Germann [mailto:ekgermann@cctec.com] > Sent: Thursday, April 13, 2000 9:34 PM > To: nanog(a)merit.edu > Subject: NetSol screwing the pooch? > > > > In trying to track down why an old DNS server dies I found > the following > interesting stuff for the [a-i].root-servers.net over a > two-hour sample > period ... > > > Server COM. . > a 2000041300 2000041300 > b no answer no answer > c no answer no answer > d answer with ref 2000041300 > e 2000041300 2000041300 > f 2000041201 2000041300 > g 2000041101 2000041101 > h answer with ref 2000041101 > i 2000041300 2000041300 > > So I thought the purpose of multiple DNS servers was to have > mirroring for > redundancy. Does anyone find 1-2 day lags in the updates > acceptable? I'm > glad NetSol is moving these to commercial grade data centers. :( > > The no answers are pingable but don't answer queries from > here (over a two > hour period). The answer with ref answered with referrals to other > servers. I don't have the patience to recurse the whole mess of > *.gtld-servers.net. > > Any other observations other than NetSol has apparently > screwed the pooch > again ? > > Eric > > > > > ============================================================== > ============ > Eric Germann Inacom > Info Systems > egermann(a)inacomlima.com Lima, OH 45801 > Ph: > 419 331 9050 > ICQ: 41927048 Fax: > 419 331 9302 > > "It is so easy to miss pretty trivial solutions to problems deemed > complicated. The goal of a scientist is to find an > interesting problem, > and live off it for a while. The goal of an engineer is to evade > interesting problems :)" -- Vadim Antonov <avg(a)kotovnik.com> on NANOG >

2 1

NetSol screwing the pooch?
by Eric Germann 14 Apr '00

14 Apr '00

In trying to track down why an old DNS server dies I found the following interesting stuff for the [a-i].root-servers.net over a two-hour sample period ... Server COM. . a 2000041300 2000041300 b no answer no answer c no answer no answer d answer with ref 2000041300 e 2000041300 2000041300 f 2000041201 2000041300 g 2000041101 2000041101 h answer with ref 2000041101 i 2000041300 2000041300 So I thought the purpose of multiple DNS servers was to have mirroring for redundancy. Does anyone find 1-2 day lags in the updates acceptable? I'm glad NetSol is moving these to commercial grade data centers. :( The no answers are pingable but don't answer queries from here (over a two hour period). The answer with ref answered with referrals to other servers. I don't have the patience to recurse the whole mess of *.gtld-servers.net. Any other observations other than NetSol has apparently screwed the pooch again ? Eric ========================================================================== Eric Germann Inacom Info Systems egermann(a)inacomlima.com Lima, OH 45801 Ph: 419 331 9050 ICQ: 41927048 Fax: 419 331 9302 "It is so easy to miss pretty trivial solutions to problems deemed complicated. The goal of a scientist is to find an interesting problem, and live off it for a while. The goal of an engineer is to evade interesting problems :)" -- Vadim Antonov <avg(a)kotovnik.com> on NANOG

2 1

Re: Netflow problem
by Simon Leinen 13 Apr '00

13 Apr '00

>>>>> "ylt" == Yannick Le Teigner <9368Def(a)excite.com> writes: > I have a little problem setting up Netflow on routers. > It seems like the timeout to remove unactive flow from the cache is too > low(15"), and I can't set it to a bigger value (say 5 minutes). Given a recent enough IOS, you can use swiCE1(config)#ip flow-cache timeout inactive ? <10-600> Timeout in seconds > A good example is the bgp session. Depending on the time I execute a > "show ip cache flow", the bgp session is seen active or not, > although it is always active! Maybe your routes don't flap enough, otherwise there would always be update activity keeping the flow active. Do you use route dampening? Just kidding. > The problem is that if the router doesn't see any data on a flow > during 15 seconds, it considers it unactive. If you set the inactive timeout too high, you will probably keep a lot of obsolete flows in the NetFlow cache. This may cause the cache to fill up (note that you can also configure the size of that cache in recent IOS versions), maybe causing additional cleanup overhead. > I included two outputs of "show ip cache flow" to show you the problem. Well, is this really a problem for you? You can always use e.g. the SNMP tcpConnTable and the BGP-4 MIB to get very detailed information about BGP connections terminating at the router. Regards, -- Simon.

1 0

NSI's registrar db hacked
by Rodney Joffe 13 Apr '00

13 Apr '00

Looks like another hole in the NSI registrar (not registry) system has been found and exploited. Apparently some 2,000 domains have been hijacked, so if something weird has happened to a domain of yours, this may explain it... Whois lucasfilm.com Query: indianajones.com Registry: whois.networksolutions.com Results: Registrant: Lucasfilm Ltd (INDIANAJONES5-DOM) senojanaidn 12 Tirana, Albania 10000 AL Domain Name: INDIANAJONES.COM Administrative Contact, Technical Contact, Zone Contact, Billing Contact: indianajones, inetn (IIO27) justdoit(a)MEGAPOST.NET indianajonesorgni senojanaidn 12 Tirana, Albania 10000 AL 323432444 (FAX) 323432431 Record last updated on 10-Apr-2000. Record expires on 02-Oct-2000. Record created on 01-Oct-1997. Database last updated on 12-Apr-2000 04:49:41 EDT. Domain servers in listed order: NS1.WEBPROVIDER.COM 209.143.154.70 NS2.WEBPROVIDER.COM 207.226.255.71 Results brought to you by the GeekTools WHOIS Proxy v3.0 Server results may be copyrighted and are used with permission. Your host (204.74.78.193) has visited 2 times today. Story appears at http://filmforce.ign.com/news/781.html pointer provided by jra :-) The url does take you to the lucasfim website now, but earlier it took you to Webprovider.com. The above story has a screencapture of the way it looked. -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(SM)

2 1

Netflow problem
by Yannick Le Teigner 13 Apr '00

13 Apr '00

Hi, I have a little problem setting up Netflow on routers. It seems like the timeout to remove unactive flow from the cache is too low(15"), and I can't set it to a bigger value (say 5 minutes). A good example is the bgp session. Depending on the time I execute a "show ip cache flow", the bgp session is seen active or not, although it is always active! The problem is that if the router doesn't see any data on a flow during 15 seconds, it considers it unactive. I included two outputs of "show ip cache flow" to show you the problem. Thank you for any help! -Yannick --------------------------------------------------------------------- without bgp session seen as active (although it is!) --------------------------------------------------------------------- >#show ip cache flow IP packet size distribution (89333 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .306 .240 .422 .008 .003 .004 .000 .001 .000 .000 .000 .000 .000 .000 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .000 .000 .009 .000 .000 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 4456704 bytes 1 active, 65535 inactive, 15172 added 603804 ager polls, 0 flow alloc failures Active flows timeout in 10 minutes last clearing of statistics 1w1d Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 33 0.0 68 41 0.0 42.7 13.9 TCP-BGP 15053 0.0 5 93 0.1 23.9 15.4 UDP-other 3 0.0 6 74 0.0 9.9 15.9 ICMP 84 0.0 26 98 0.0 2.6 15.6 Total: 15173 0.0 5 92 0.1 23.9 15.4 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Fa1/0/0 ???.7.34.2 Local ???.0.140.130 06 0CC5 0017 94 ---------------------------------------------------------------------- with bgp session seen as ative ---------------------------------------------------------------------- >#show ip cache flow IP packet size distribution (89638 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .308 .239 .421 .008 .003 .004 .000 .001 .000 .000 .000 .000 .000 .000 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .000 .000 .009 .000 .000 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 4456704 bytes 2 active, 65534 inactive, 15179 added 604112 ager polls, 0 flow alloc failures Active flows timeout in 10 minutes last clearing of statistics 1w1d Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 35 0.0 72 41 0.0 42.7 14.0 TCP-BGP 15057 0.0 5 93 0.1 23.9 15.4 UDP-other 3 0.0 6 74 0.0 9.9 15.9 ICMP 84 0.0 26 98 0.0 2.6 15.6 Total: 15179 0.0 5 92 0.1 23.9 15.4 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Fa1/0/0 ???.7.34.2 Local ???.0.140.130 06 0CC5 0017 118 Fa1/0/0 ???.0.140.129 Local ???.0.140.130 06 A34A 00B3 2 The flow from the ???.0.140.129 is the bgp session. _______________________________________________________ Get 100% FREE Internet Access powered by Excite Visit http://freelane.excite.com/freeisp

1 0

NANOG 19 CFP
by Susan R. Harris 12 Apr '00

12 Apr '00

* * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS * * NANOG 19 * * June 11 - 13, 2000 * * * * * * * * * * * * * * * * * The North American Network Operators Group (NANOG) will hold its 19th meeting in Albuquerque, NM, between June 11 - 13, 2000. The meeting will be hosted by iHighway. NANOG conferences provide a forum for the coordination and dissemination of technical information related to large-scale (i.e., national/international) Internet backbone networking technologies and operational practices. NANOG meetings, held three times each year, include two days of short presentations, plus afternoon/evening tutorial sessions. Meetings are informal, with an emphasis on relevance to current backbone engineering practices. The conference draws around 500 participants, mainly consisting of engineering staff from large national service providers, and members of the research and education community. Now in its fifth year, NANOG evolved from the NSFNET "regional-techs" meetings, where technical staff from the regional networks met to discuss operational issues of common concern. With the emergence of the commercial Internet, NANOG meetings evolved to include a broader base of providers, network operators, and researchers. The meeting will be held at the Albuquerque Hyatt Regency. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Previous meetings have included presentations on: - Backbone traffic engineering - Coordination of inter-provider QoS - Deployment experience with queueing disciplines (CAR, RED) - Inter-provider security and routing protocol authentication - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Cooperative inter-provider caching - Alternatives to hot-potato routing - Recommendations on queue management and congestion avoidance - Experience with differentiated services - Reports from next-generation networks (Internet2, CA*net, etc.) - Inter-domain multicast deployment - Backbone network failure analysis Tutorials have covered topics such as: - BGP case studies - MPLS fundamentals - External route selection - IP multicast technologies - Distributed content caching in large IP networks ------------------------------------------------------------------------------ HOW TO PRESENT Submit an informal one- or two-paragraph abstract describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is May 8, 2000. The majority of speaking slots will be filled by May 8; a limited number of slots will be available after that date for topics that are exceptionally timely and important. Presenters will be notified of acceptance by May 22, 2000. NANOG also welcomes suggestions/recommendations for tutorials, panels and other presentation topics. ------------------------------------------------------------------------------

1 0

IMF part two
by Sean Donelan 12 Apr '00

12 Apr '00

While looking for more information about the power failure at the Reagan National Airport air traffic control tower, I read about the preparations for the IMF meeting in Washington this weekend. As you may remember, last fall in Seattle several ISP NOC folks experienced the pain and agony of tear gas up close while trying to go to and from work. http://washingtonpost.com/wp-srv/local/daily/april00/bankmap.htm Looking at the map, I don't recall any ISPs with offices within the affected area. Some CLECs have offices following fiber along the metro line and L street. But nothing super-critical for the Internet.

1 0