- Test - lists.nanog.org

Censorship, Obligations, and Legal Responsibility
by Alan Hannan 03 Dec '95

03 Dec '95

With the publicity surrounding the recently announced coalition and agreement eliminating 'pornography' from certain providers, I am curious as to what our group's thoughts are wrt potential legal expoure to us in the following two areas: A| Network Connectivity Providing and B| Usenet Network News Providing. I have arguments in my head both ways on the question: "Is the NSP|ISP responsible for content of their Pipes|NNTP feed?" I would be curious to hear what the concensus (as if there might be one) is. -alan

2 1

Re: Westnet and Utah outage
by Scott Huddle 02 Dec '95

02 Dec '95

So this is to imply that you do have a problem w/ Sprint and that you are picking on them in a specific way? -scott > From list-admin(a)merit.edu Wed Nov 22 09:23:19 1995 > Date: Wed, 22 Nov 1995 09:20:38 -0500 (EST) > From: Gordon Cook <gcook(a)tigger.jvnc.net> > Reply-To: cook(a)cookreport.com > To: nanog(a)merit.edu > Subject: Westnet and Utah outage > Mime-Version: 1.0 > Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> > Content-Length: 762 > > small clarification. I have no problem with westnet and do not mean to > be picking on it in anyway. I have a friend who lives in westnet's > service area who gets bothered by these outages and passes them on to me. > > ******************************************************************** > Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 > The COOK Report on Internet Non Profit. $150 > 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 > (609) 882-2572 Corporate $350 > Internet: cook(a)cookreport.com Corporate. Site Lic $650 > Newly expanded COOK Report Web Pages http://pobox.com/cook/ > ******************************************************************** > > >

9 12

Re: Internet software development acceleration
by kwe＠6SigmaNets.com 02 Dec '95

02 Dec '95

At 10:26 AM 12/1/95, Eilish McCaffrey wrote: > I am a participant, as a 'listener', to the nanog. I understand its >origins and also applaud how information is shared among 'competitive' >entities ie ISPs. > ... > We are all working to build an optimal Internet infrasturcture and the >software\web enablement techniques available might help accelerate >capabilities\enhancements to market. If we chose to use this language >'toolkit' as a whole, which can be used for 'intranet' and I\S solutions as >well, it might minimize the technological frustrations of today. > > Any thoughts? > > Eilish McCaffrey > > Does this language toolkit contain terms such as: "I understand what you are saying..." "I respect your position, but I disagree with you on this point, ..." "In the spirit of cooperation, let's do this..."? If not, it won't help much. --Kent

1 0

Internet software development acceleration
by emccaffr＠BayNetworks.com 02 Dec '95

02 Dec '95

I am a participant, as a 'listener', to the nanog. I understand its origins and also applaud how information is shared among 'competitive' entities ie ISPs. Even though I work for a router company ( I am the Internet sales manager with Bay) I look at the Internet as a global 'homogeneous' infrastructure. Inherent in its design and hw\sw features, are a set of problems. Is there any way to identify a common set of problems, regardless of whether the underlying product is Bay or Cisco, and commit to resolving it? The 'net' is that if the Internet, of multivendor routers, is viewed as a single global entity requiring a uniform enhancement, what would that be? What is the barrier to resolving this problem? I am dealing with an internet web enablement company here in CA that provides superior Internet language sets, tools, and technologies. My belief is that their expertise could be focused on enhancing and optimizing the Internet as if it were a single entity through the use of its offering of internet based languages (perl, tcl, c++..), compilers, support and consulting. We are all working to build an optimal Internet infrasturcture and the software\web enablement techniques available might help accelerate capabilities\enhancements to market. If we chose to use this language 'toolkit' as a whole, which can be used for 'intranet' and I\S solutions as well, it might minimize the technological frustrations of today. Any thoughts? Eilish McCaffrey

3 2

Re: outages, quality monitoring, trouble tickets, etc
by kwe＠6SigmaNets.com 02 Dec '95

02 Dec '95

At 3:43 PM 11/28/95, Sean Donelan wrote: > >>From: kwe(a)6SigmaNets.COM (Kent W. England) >>I'm skeptical of any end-to-end availability figures over 97%. I don't >>think they reflect the reality of leased line circuits today, or else they >>don't include the leaf node circuits and only report backbone availability. >>For a highly redundant backbone, almost any definition of availability >>should result in a number like 99.mumble%. Remember 99.9% availability >>means less than 9 hours outage per year. Routing hiccups take that much. >>One or two leased lines outages is all you get for 9 hours. The real world >>is a lot less available than that. > >Thank you! I thought I was living in a twilight zone with people >reporting 99.9% network availability. This is the rathole end-to-end >network useablity. The customer is interested in end-to-end useability. >While the network operator can only easily measure intra-network modules. > >I can't tell you the answer, but there is definitely something happening >with customer perceptions of Internet useability. Looking at the >numbers I would agree a single leased circuit should be less reliable >(single point of failure) than a highly redundant backbone. But by >our customer perceptions, that isn't the case. Either we have better >than "normal" leased circuits, or the highly redundant backbones aren't, >or our customers needs are based something we aren't directly measuring. My analysis was assumed to apply within a single service providers backbone. I believe you can report end-to-end availability within a single service provider's backbone and have a meaningful number. But leased lines bring that figure down into the range of 99.7%. I think frame relay has the promise of getting that up to .8 or .85, if the regional bells get good at FR net mgmt. The dismal situation you are referring to is the 12-15 service provider backbones, all mashing together at 7-8 exchange points with lots of paths that wind back and forth over asymmetric routes from one coast to the other and back. It's a lot different than when NSFnet was the default. No more default. Today routing is more complex, business is lower margin, and engineer folks don't have time to look up from their router memory overload and route cache woes to figure out why their routes thru ISP#17 aren't optimal. --Kent

1 0

NANOG Feb 15-16 1996 at SDSC
by William B. Norton 01 Dec '95

01 Dec '95

Hi all - The next NANOG is tentatively scheduled for Feb 15-16 at the San Diago Supercomputer Center pending final confirmation on the facilities. We will send out details as they become available. Bill NANOG Web Page: www.ra.net/routing.arbiter/NANOG/NANOG.html Send agenda topic suggestions to srh(a)merit.edu and wbn(a)merit.edu

1 0

Re: outages, quality monitoring, trouble tickets, etc
by edm＠halcyon.com 01 Dec '95

01 Dec '95

>On Mon, 27 Nov 1995, Jon Zeeff wrote: > >> Being in the web hosting business, we measure our own "availability" >> and that of others. The top providers do 99.9%. The median >> in our sample group is 98.5%. That's about 15 times worse and >> 11 hours/month. >> >> It's amazing how many of the companies in the low 98s claim 99.9%. > >I'd be terribly interested to know how you obtained these figures...we do >web hosting services as well. I had one of our clients complain angrily >for weeks that his web site was frequently "down" because he couldn't get >to it from AOL. I had to sit him down and show that his site was >operational and accessible from a dozen other sites to convince him that >AOL was the exception, and that our connectivity and server reliability >were not to blame. I've seen several providers claim "it's AOL's fault" because the provider themselves didn't properly set up an RADB entry so the ANS network would carry their packets. Given that AOL is on the other side of the ANS network, that could be a big problem. So, just sitting down and showing the site is accessible from a dozen other sites proves nothing about it not being the provider's problem -- it helps to show that it works in some cases though. Ed Morin Northwest Nexus, Inc. _________________________________________________________________________ Ed Morin edm(a)halcyon.com Northwest Nexus - Professional Internet Services Bellevue, WA USA Voice: 206 455-3505 Web: http://www.halcyon.com/ Info: info(a)halcyon.com

3 4

NANOG January mtg?
by Paul Ferguson 30 Nov '95

30 Nov '95

The notes from the September NANOG meeting indicate that the next meeting is/was slated for January in Arizona, and that AGIS/NET99 will serve as hosts. Has there been any developments in this regard? I know a lot of us are looking ahead to January already and trying get some scheduling done in advance. Any details would certainly be appreciated. Thanks, - paul

2 1

CERT Advisory CA-95:16 - wu-ftpd Misconfiguration Vulnerability
by CERT Advisory 30 Nov '95

30 Nov '95

============================================================================= CA-95:16 CERT Advisory November 30, 1995 wu-ftpd Misconfiguration Vulnerability ----------------------------------------------------------------------------- A vulnerability exists with certain configurations of the SITE EXEC command in the Washington University ftpd, also known as wu-ftpd. Exploitation of this vulnerability may allow root access from any account on the system. The vulnerable configuration is known to exist in numerous Linux distributions and is currently being actively exploited by intruders. It should be noted that this vulnerability is not necessarily limited to Linux but may exist on any wu-ftpd installation. Thus, all users of the wu-ftpd program, not just the Linux users, should take this opportunity to verify the configuration of their daemons. Note that versions of wu-ftpd before the 2.4 release contain serious security vulnerabilities and should be updated immediately. Section III contains instructions for disabling ftpd and correcting the configuration. As we receive additional information relating to this advisory, we will place it in: ftp://info.cert.org/pub/cert_advisories/CA-95:16.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description There is a problem with the default configuration of the Washington University FTP Server version 2.4 in major Linux distributions, including but not limited to Slackware 2.0, 2.1, 2.2, 2.3, Yggdrasil Plug&Play Fall'94, and the Debian Distribution. By exploiting this problem, any user who is able to log into a system having the vulnerable configuration via FTP using their login, and not the anonymous login, may gain root access. Other systems besides Linux can be configured to be vulnerable although the standard wu-ftpd 2.4 source code as distributed is not vulnerable. The problem is that the variable _PATH_EXECPATH was set to "/bin" in the configuration file src/pathnames.h when the distribution binary was built. _PATH_EXECPATH should be set to "/bin/ftp-exec" or a similar directory that does not contain a shell or command interpreter, for example. The source code shipped with the Linux distributions contains the correct value ("/bin/ftp-exec") despite the incorrect distribution binary. You should verify that _PATH_EXECPATH has the correct value before recompiling. Note that the documentation for wu-ftpd states that the directory defined by _PATH_EXECPATH is relative to ~ftp, the ftp home directory as specified in the password file. This is misleading. The pathname is relative to ~ftp for anonymous users only. This pathname is relative to "/" for other user sessions. II. Impact Any user with a local account on a system offering FTP services with the vulnerable configuration may gain root access. Support for anonymous FTP access is not required to exploit this vulnerability. III. How to determine if you are vulnerable All systems running wu-ftpd should be checked to determine if the configuration is vulnerable. To test your configuration, access the ftp server using a legitimate user account (not an anonymous ftp login) and execute the following commands: srchost> ftp ftphost Connected to ftphost 220 ftphost FTP server (Version wu-2.4(2) Mon Apr 18 09:12:35 GMT+1000 1994) ready. Name (srchost:joe): 331 Password required for joe. Password: 230 User joe logged in. ftp> quote site exec echo problem 200-echo problem 200-problem 200 (end of 'echo problem') ftp> quit 221 Goodbye. srchost> If you receive the line "200-problem", your site is vulnerable. IV. Solution If you have the vulnerability, we recommend that you turn off ftpd immediately using the method described in Section A below. Once you have done that, you can then decide whether to rebuild or fetch a new ftpd binary. If you have built wu-ftpd from a source distribution, follow the steps in Sections B.2 and B.3 below. Once you have eliminated this vulnerability, turn on ftpd with the method described in Section C below. A. Disable ftpd To disable ftpd, do the following as root. 1. Shut down the FTP server using the ftpshut command. This command blocks all connections to the FTP server. For ftpshut to work correctly, the ftpaccess(5) file will need a shutdown directive that names a file used by wu-ftpd to indicate that the server is shutdown. If your ftpaccess file does not have such a directive, add one to that file. When added, use ftpshut(8) to shut down the server. Once the server has been shutdown, all new incoming FTP requests will fail. Here is an example of the ftpshut command: ftpshut now 2. Verify that the FTP service has been shut down by attempting to connect to it. You should see a message that contains a line similar to the following: hostname FTP server shut down -- please try again later where hostname is the host from which you are requesting FTP service. B. Correct the configuration Item 1 below applies to those running Debian Linux. Item 2 applies to all other Linux systems. Item 3 applies to those who are building wu-ftpd from source on systems other than Linux. 1. If you are running Debian Linux, obtain a fixed binary, available from the following location, and install this binary. ftp://ftp.debian.org/debian/debian-0.93/binary/net/wu-ftpd-2.4-14.deb MD5 (wu-ftpd-2.4-14.deb) = c00a0aac75216bf83568aee4c2e7d168 2. If you are running any version of Linux, there is a version of the source code available that has been improved to compile more cleanly. It too is correctly configured for SITE EXEC. It is available from (file wu-ftpd-2.4-fixed.tar.gz) ftp://bach.cis.temple.edu/pub/Linux/security/wu-ftpd-2.4-fix/ MD5 (wu-ftpd-2.4-fixed.tar.gz) = 3e1c6fd7cd6757e45894df0d3638b524 This version is also correctly configured for the SITE EXEC command and can be compiled and installed. Consult Section IV below for suggestions on how to configure wu-ftpd. 3. If you are running a version of wu-ftpd before version 2.4, you should upgrade to version 2.4 first. That version is available from ftp://wuarchive.wustl.edu/packages/wuarchive-ftpd/wu-ftpd-2.4.tar.Z MD5 (wu-ftpd-2.4.tar.Z) = 57f1a962c90a9b12825d39af518df433 Version 2.4 is correctly configured for the SITE EXEC command and can be compiled and installed. Consult Section IV below for suggestions on how to configure wu-ftpd. C. Enabling ftpd 1. To turn ftpd back on, delete the file referenced by the shutdown directive in your ftpaccess file. 2. Verify that the FTP service has been enabled by attempting to connect to it. You should see a message that contains lines similar to the following: srchost> ftp ftphost Connected to ftphost 220 ftphost FTP server (Version wu-2.4(3) Mon Apr 3 16:53:11 EDT 1995) ready. Name (srchost:joe): IV. Advice on configuring the FTP Daemon for SITE EXEC Here are some configuration guidelines for the directories named by the _PATH_EXECPATH variable. 1. Directories used by SITE EXEC: The documentation for wu-ftpd states that the directory defined by the _PATH_EXECPATH variable is relative to ~ftp, the ftp home directory as specified in the password file. This is misleading. The pathname is relative to ~ftp for anonymous users only. The pathname is relative to "/" for all other user sessions. Therefore, you need to check the two directories used by the SITE EXEC command. For example, if the _PATH_EXECPATH variable is set to /bin/ftp-exec, then wu-ftpd searches the ~ftp/bin/ftp-exec directory for programs specified by SITE EXEC when the anonymous login is used, and the /bin/ftp-exec directory specified by SITE EXEC when any other login is used. 2. Contents of the directories used by SITE EXEC: The commands installed in these directories can be executed by the SITE EXEC command. We strongly recommend that this directory contain only those programs that you wish to be executed by those users who connect to your FTP server. An example of a program to install in these directories is the ls program. Programs that should not be installed in these directories are shells, for example sh or csh, and command interpreters, for example awk and perl. --------------------------------------------------------------------------- The CERT Coordination Center thanks AUSCERT, the Australian response team, and Alexander O. Yuriev, Temple University, author of Linux Security Updates, for their support in responding to this problem. Linux Security Updates are available from http://bach.cis.temple.edu/linux/linux-security/ --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet email: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT advisories and bulletins are posted on the USENET newsgroup comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request(a)cert.org. Past CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University.

1 0

CIDR Aggregation Tool
by Avi Freedman 29 Nov '95

29 Nov '95

Well, after observing the debates about What To Do About The Routing Table Size, I decided to work on some informal tools to examine the current routing table space for possible aggregations. Right now, the raw data is the routing table from the Net Access MAE-East router. It only searches for aggregates /15 < x < /25 right now - ignoring some fairly obvious aggregation-suggestions in the /8 < x < /16 range. The results are up at http://routes.netaxs.com and the some of the caveats are listed on the web page, but are: 1) When the Net Access MAE-East router has multiple identical routes that point to the same next-hop (192.41.177.x), the system only uses the one first listed in the cisco 'sho ip bgp summ' output - even though that's not always the 'best' route. 2) When an AS advertises both an aggregate and a specific, the specific is 'dropped' by the aggregator. If the input is: {205.89.10.128/17, 205.89.10.130}, the output will be: {205.89.10.128/17} (205.89.10.130 will be dropped). 3) The source of data is the Net Access MAE-East router routing table, and we don't peer with all parties at MAE-East directly - thus, it's possible that the system catches aggregations that are impossible because they're announced to a 3rd party via different paths - but an informal look around doesn't appear to indicate that. 4) The system goes by next-hop rather than by AS-Path. There seems to be a good correlation, but ... Also, the final disclaimer: I've examined the results and they *look* reasonable. But I haven't written tester-tools to attempt to verify by another algorithm that the results are correct. Here's the table at the end of the web page: Before After Run Agg. Run 192.41.177.110 ibm 81 68 192.41.177.115 digex 98 98 192.41.177.120 eu.net 949 775 192.41.177.125 nsn.nasa 126 112 192.41.177.140 ans 2146 1425 192.41.177.145 agis 539 304 192.41.177.150 uscyber 2 2 192.41.177.160 interpath 2 2 192.41.177.170 net99 309 246 192.41.177.180 mci 2 2 192.41.177.181 mci 8963 6828 192.41.177.190 pipex 367 308 192.41.177.210 netcom 370 348 192.41.177.235 psi 1 1 192.41.177.240 icp 4499 3712 192.41.177.241 sprintlink 6429 4694 192.41.177.245 psi 1491 1098 192.41.177.249 alternet 3971 3148 192.41.177.251 es.net 96 88 192.41.177.252 es.net 122 101 192.41.177.6 suranet 470 445 192.41.177.70 internex 1 1 192.41.177.80 ios 10 8 192.41.177.85 cais 184 158 192.41.177.86 hlc 354 243 192.41.177.89 energis 2 2 192.41.177.95 delphi 3 3 A final note: We're open to {Additional static sources of route tables at MAE-East; Additional static sources of route tables at {MAE-West, Pennsauken, or the PacBell NAP}; and dynamic (i.e. the vty password so we can run a sho ip bgp summ every so often) sources at any of the MAEs or NAPs. If we get good feedback, we may automate this to run overnight and keep a history. Avi Freedman freedman(a)netaxs.com

5 13