- NANOG - lists.nanog.org

cflowd / IOS ver question
by John M. Brown 05 Jul '98

05 Jul '98

Ok so we just got a new 7206 to play with and I want to try out the cflowd stuff. The problem I have is that the version of IOS 11.2(12)p doesn't have the ip flow-export {various commands} command. It only has the ip flow-export A.B.C.D udp-port command So did we get the right version, is there something missing that I need to get??? Any help would be great.... Even when I just use this version of the command I don't get any packets on the udp-port / host that I specify. Mr. Sniffer doesn't show anything at all......... jmbrown(a)ihighway.net

6 5

AS3447 flapping?
by Jon Lewis 04 Jul '98

04 Jul '98

Is it my imagination, or is AS 3447 flapping lots of its routes this evening? Anyone know what's up? ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

2 1

The Cidr Report
by Tony Bates 03 Jul '98

03 Jul '98

This is an auto-generated mail on Fri Jul 3 12:00:00 PDT 1998 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 xara.net 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 03Jul98 0) General Status Table History ------------- Date Prefixes 190698 51379 200698 51329 210698 51500 220698 51541 230698 51362 240698 51537 250698 51460 260698 51523 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: 2703 Number of ASes announcing only one prefix: 828 (0 cidr, 828 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1145 announced by AS701 1) Gains by aggregating at the origin AS level --- 03Jul98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 452 247 205 45.4% IMCI AS2493 488 283 205 42.0% iSTAR Internet, Inc. AS3602 511 313 198 38.7% Sprint Canada Inc. AS701 1145 950 195 17.0% Alternet AS271 336 145 191 56.8% BCnet Backbone AS3749 218 70 148 67.9% TECNET AS174 725 587 138 19.0% Performance Systems International AS4755 106 32 74 69.8% Videsh Sanchar Nigam Ltd. India AS3218 78 7 71 91.0% AS-RSSI AS7046 218 148 70 32.1% UUNET-CUSTOMER AS3221 112 42 70 62.5% EENet Autonomous System AS6227 96 28 68 70.8% !nteract AS10928 107 42 65 60.7% UNKNOWN AS5668 116 54 62 53.4% Century Telephone Inc. AS3804 208 146 62 29.8% Bell Solutions AS4740 382 328 54 14.1% ASN-OZEMAIL (Ozemail Pty Ltd) AS3403 180 127 53 29.4% TIAC AS2685 133 83 50 37.6% IBM Global Network - US AS549 194 145 49 25.3% ONet Backbone AS8517 120 72 48 40.0% ULAKNET-ASN AS72 85 37 48 56.5% Schlumberger Information Network AS6335 68 20 48 70.6% NTRNET AS4539 73 25 48 65.8% NETROPOLIS AS4200 145 97 48 33.1% AGIS (Apex Global Information Ser AS1239 543 496 47 8.7% SprintLink Backbone AS719 449 405 44 9.8% LANLINK autonomous system AS852 158 116 42 26.6% AGT Advance Communication AS762 118 80 38 32.2% WELLFLEET-AS AS6181 65 28 37 56.9% FUSE-NET AS4763 109 72 37 33.9% Telstra New Zealand 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

Fwd: SBN Wire: Security Bulletin (WAS: Re: Aside: ability to view ASP/ColdFusion code )
by Eric Germann 03 Jul '98

03 Jul '98

> >*** Microsoft (R) Site Builder Network *** > >This is special edition of the SBN Wire is to inform our >membership of a recent security issue that pertains to >Microsoft Internet Information Servers. Please see the >Security Bulletin below for details. > >The latest information on this matter can be found on >http://www.microsoft.com/security. > >The SBN Team > >------------------ > >MICROSOFT SECURITY BULLETIN (MS98-003) > >Hotfix available for the Microsoft Internet Information >Server file access issue >Last revision: July 2, 1998 > >SUMMARY >Recently Paul Ashton reported an issue on the NTBugtraq >mailing list (http://www.ntbugtraq.com) that affects >Microsoft Internet Information Servers (IIS). Web clients >that connect to IIS can read the contents of files to which >they have execute and read only permissions. These files >have to be in a web server v-root directory and on an NTFS >volume. > >The purpose of this bulletin is to inform Microsoft >customers of this issue, its applicability to Microsoft >products, and the availability of countermeasures Microsoft >has developed to further secure its customers. > >ISSUE >The native Windows NT file system, NTFS, supports multiple >data streams within a file. The main data stream, which >stores the primary content has an attribute called $DATA. >Accessing this NTFS stream via IIS from a browser may >display the script code for the file. > >The issue is a result of the way IIS parses filenames. The >fix involves IIS supporting NTFS alternate data streams by >asking Windows NT to canonicalize the filename. > >For the problem to occur the user must: > >1) Know the name of the file >2) The ACLs on the file must allow some access (i.e. read >and execute access) >3) The file must reside on an NTFS partition > >The user cannot view files on which the ACLs are set to >deny all access. > >For more information on NTFS Alternate Data Streams please >see Microsoft Knowledge Base article Q105763. > >AFFECTED SOFTWARE VERSIONS >Microsoft Internet Information Server version 3.0 and 4.0 > >MORE INFORMATION >Please see Microsoft Knowledge Base article Q188806 for >more information. > >WHAT MICROSOFT IS DOING >The Microsoft Product Security Response Team has produced a >hotfix for Microsoft Internet Information Server version >3.0. > >Microsoft is currently testing a hot fix for Internet >Information Server version 4.0 which will be posted later >today. > >WHAT CUSTOMERS SHOULD DO >Microsoft strongly recommends that customers using IIS >version 3 and 4 should apply the hotfix. > >IIS 3.0 (Intel x86) hotfix - >ftp://ftp.microsoft.com/bussys/IIS/iis- >public/fixes/usa/security/iis3-datafix/iis3fixi.exe > >IIS 3.0 (Alpha) hotfix - >ftp://ftp.microsoft.com/bussys/IIS/iis- >public/fixes/usa/security/iis3-datafix/iis3fixa.exe > >IIS 4.0 hotfix - This will be released later today > >More information on obtaining the hotfix can be found in >Microsoft Knowledge Base article Q188806 > >ADMINISTRATIVE WORKAROUND >Customers who cannot apply the hot fix can use the >following workaround to temporarily address this issue: > >Make the following additions to the Application Map in >IIS4: > >The steps to perform this are: >* Open the Microsoft Management Console >* Right click on the Virtual Server in question >* Select Properties >* Select the Home Directory tab >* Select Configuration > >Now add each of the entries noted below: > >.idc::$DATA >.stm::$DATA >.asp::$DATA >.asa::$DATA >.shtm::$DATA >.shtml::$DATA >.pl::$DATA > > >In addition, the following practices can help to further >improve security for your IIS servers: >* Periodically review the users and groups who have access >to the web server: Review the users and groups and their >permissions to ensure that only valid users have the >appropriate permissions. > >* Use auditing to detect for suspicious activity: Apply >auditing controls on sensitive files and review these logs >periodically to detect suspicious or unauthorized behavior. > > >REVISIONS >July 2, 1998: Bulletin Created > >For additional information on security issues at Microsoft, >please visit www.microsoft.com/security > >THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS >PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT >DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, >INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR >A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT >CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES >WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, >CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, >EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN >ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO >NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR >CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING >LIMITATION MAY NOT APPLY. > >Copyright 1998 Microsoft and/or its suppliers. All rights >reserved. For Terms of Use see: >http://support.microsoft.com/support/misc/cpyright.asp > ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert, OH 45891 http://www.cctec.com Ph: 419 968 2640 Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0

Re: Aside: ability to view ASP/ColdFusion code
by Andrew Staples 02 Jul '98

02 Jul '98

This applies as well to perl and cgi scripts (cgi in iis3.0) For example: http://www.activestate.com/lyris/lyris.pl::$DATA MS hasn't fixed their own site (heh), but they promise a fix today. http://www.microsoft.com/default.asp::$DATA In the meantime, Christoph Wille <Christoph.Wille(a)softwing.com> from Sofwing has graciously made available an IIS ISAPI filter that will protect a site from the ::$DATA vulnerability. You can find it at http://www.softwing.com/iisdev/ddatafix/ Andrew -----Original Message----- From: Manar Hussain <manar(a)ivision.co.uk> >This isn't really a NANOG issue so I'll keep it brief - I'm mentioning it >as it's something people here may well want to consider and pass on to >customers with NT servers. > >Another MS security whole allows people to access the code for >ASP/ASA/ColdFusion pages by adding ::$data to the URL. > >E.g. > >http://www.allaire.com/handlers/index.cfm::$DATA > >http://www.watford.co.uk/global.asa::$DATA > >http://www.datareturn.com/av-asp.asp::$DATA > >I understand that using SiteServer or making the file non-readable (but >retaining execute permissions!) "solves" the problem. > >Regards, > >Manar

1 0

An irrelavant thread.
by Tim Wolfe 02 Jul '98

02 Jul '98

I need to ask a question of some people who are CCIE's. Please reply to me directly and not to the list. Thanks, Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

I need temporary dialup access in Sooke, British Columbia
by Wayne D. Correia 02 Jul '98

02 Jul '98

... from tomorrow evening through next Tuesday. Can anyone out there loan me a dialup account for that period? Also, does anyone know if any of the majors have a POP near there? (Alterdial, PSI, ATT Worldnet, etc.) Thanks in advance! -- Wayne D. Correia Critical Path Inc. tel: +1.415.543.2800 CTO <wayne(a)cp.net> San Francisco, CA 94105 USA fax: +1.415.543.2830 InterNIC: (WAYNE-ORG) http://www.cp.net cell: +1.415.826.6000

2 1

Aside: ability to view ASP/ColdFusion code
by Manar Hussain 02 Jul '98

02 Jul '98

This isn't really a NANOG issue so I'll keep it brief - I'm mentioning it as it's something people here may well want to consider and pass on to customers with NT servers. Another MS security whole allows people to access the code for ASP/ASA/ColdFusion pages by adding ::$data to the URL. E.g. http://www.allaire.com/handlers/index.cfm::$DATA http://www.watford.co.uk/global.asa::$DATA http://www.datareturn.com/av-asp.asp::$DATA I understand that using SiteServer or making the file non-readable (but retaining execute permissions!) "solves" the problem. Regards, Manar

1 0

small vent
by Brian Wallingford 02 Jul '98

02 Jul '98

Why is it that open relays are so common in European/Asian networks? Granted, we still have a long way to go in the US, but at the current rate, I'll likely be blocking all of RIPE and especially APNIC by September. How long does it take to absorb a clue? Just curious. Cheers, Brian -- --=Please direct technical support questions to support(a)meganet.net =-- ======================================================================= Brian Wallingford voice: 508.646.0030 Network Operations Manager email: brian(a)meganet.net MEGANET COMMUNICATIONS, TCIX, Inc. http://www.meganet.net =======================================================================

17 28

Re: Digex transparent proxying
by Chris A. Icide 01 Jul '98

01 Jul '98

[NANOG WARNING: This document contains neither directions on contacting the operational support group for any entity, nor the configuration code for any network hardware] Against my better judgement, I've decided to add my tiny bit of content to this thread. If there is anyone to thank for getting me into it, Mr. Porter has done so with his excellent review of the thread. Without it, I might not have seen the humor in it. However, there is something that I just can't understand. It's amazing to me that with the number of examples in history, people are able to make grand statements like many have in this thread. Please allow me to point out a few historical statements that I feel are very similar to some of the grand statements made in this thread: 1. The world is flat and rests on the back of a giant turtle. 2. Man will never be able to fly faster than the speed of sound. 3. The Dow Jones Industrial Average will never break 4000 Grandiose statements can be generally risky, and almost always the more grand the statement, the more likely it will be wrong to some degree. So if you think some technology is just a short term hack, and is doomed to be forgotten, sure, tell us, and then tell us why you believe it. Just the grand statement alone really is worthless. On to the topic: As far as I can tell there are three major subjects to this thread. The ethical nature of using a transparent cache. The technical and operational problems and solutions associated with the implementation of a transparent cache. And finally, the customer support and management process involved with the implementation of the transparent cache. I'll address these in reverse order. Customer Support and process management seems to be the Achilles' heel of the Internet industry. This industry has seemed to build up a terrible reputation for poor customer support. Coming from the Nuclear industry, I am truly jaded when it comes to process management, but the Internet industry seems to have taken a track as far as possible on the other side. It amazes me the lack of process management in many (not all) of the organizations involved in this industry. Procedures seem to be a dirty word, and tend to result in the exodus of technical talent when imposed upon an organization. In many cases, you can find people in the industry jokingly referring to their facilities and really neat toys. Compared to the multiple interactions in the Internet, a nuclear power plant is simple. And yet, there are very few people if any who could singly determine what one particular action would have upon the operation of the plant as a whole. Obviously, the consequences of something bad happening is far worse, but in many cases, bad means the plant is shut down for some time period, and the company loses cash at an astonishing rate. However, the use of the Internet as a tool for many companies revenue stream continues to grow, and the resulting problems generated by poor process management is beginning to have much wider financial effect. It's apparent that we on the operational side are truly more at fault than anyone else. It's our duty to provide this service to our customers as best we can. If there is any area in which the customer could claim negligence or seek damages, this is one place that they may find a good chance. I'm not pointing fingers here, I've been in organizations that were party to this myself. I'm merely making a general observation. Many organizations have made good headway here. Events such as the infamous 7007 event, the widespread connectivity problems concurrent with filter implementations, down to local effects of such as those resulting in this thread will continue to occur as long as we continue to take a lax view as to the results of our actions. There apparently have been several organizations developed recently that claim to be attempting to address this problem. However, I have not seen an industry-wide affect by the operations of these organizations. As far as the technical and operational problems associated with the implementation of current transparent caching technology, it appears to me that the people on this list who have the most background in cache technology seem to have come to an agreement that technological answers to the problems experienced in this event exist. I can't, nor won't feign any significant technical knowledge in the caching field. I have a general knowledge level at best. >From a general level, this industries technological growth rate is phenomenal and the resulting technological implementation problems can be significant. However, there are organizations that are going to continue to develop and implement these new technologies. The successful ones will be financially rewarded in our capitalistic society, and the unsuccessful ones will fare less well. Sooner or later those implementing the new technology will have a significant advantage over those who don't. To avoid the challenge of new technology can be extremely damaging to the viability of a company in the Internet industry. Yes, I admit that the possibility that any current implementation of a new technology such as caching may actually end up being a temporary fix. However, I would be amazed to find that the effort put into development and operational testing of such a technology did not result in some advancement in that field. From caching, we may find interesting advancements in distributed technology for example. Finally, the ethical question comes around. Is it, or is it not ethical for someone to use a transparent cache? IMHO, the arguments on this portion of the thread have been nothing but sensationalist. It reeks of paranoia. Perhaps the X-Files can (or have they already) done a show on this. THEY are stealing your packets without your knowledge! THEY are monitoring your every transmission and receipt! THEY know your innermost secrets! Bah! Does transparent (or any caching technology, for that matter) give someone additional tools to pry into the data flow? Yes. Does the technology specifically do this and provide this information? No. It's a tool that could be mismanaged and used for something other than its original purpose, and perhaps even intrusive actions. However, it requires someone who wants to do such a thing, and the tools exist already to do similar things if someone so chooses. Attempting to limit the growth of a technology because it could result in the technology being used wrongly is pure folly. In the case of transparent caching, it's my belief that as long as an end user receives content as provided by the content provider in the format specified by the content provider (yes, this includes dynamic information), both the content provider and the end user could care less what physical, electromagnetic, or optical transformations take place from end to end. If the end to end transit is truly transparent, then the goal is accomplished. However, the expectation that this goal could be accomplished while content providers, transit providers, and client/server software providers work independently of each other, is ludicrous. These entities must work together to achieve this. The pointing of fingers and blaming of the other parties does nothing more than delay the maturation process of this industry. This is a complex and extremely interactive system, and must be dealt with as a whole for an optimal solution to arise. Perhaps it's the place here for a Grand Statement concerning the likelihood of this occurring. :) -Against my better judgement, Chris

2 1