November 1995 - NANOG - lists.nanog.org

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: 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

Urp... Announcement of 208.x.x.x
by Avi Freedman 29 Nov '95

29 Nov '95

I just noticed that AS 3847 was announcing 208.0.1.0/24, 208.0.4.0/24, 208.0.5.0/24, and 208.0.9.0/24. Now, besides the fact that they could announce 208.0.4.0/23 ( :) ), those addresses aren't quite kosher-ly allocated, are they? Is there a spot where the Internic communicates what address space has been allocated? ("We are now allocating out of 207.x.x.x") Avi

2 2

Re: outages, quality monitoring, trouble tickets, etc
by Jeff.Ogden＠um.cc.umich.edu 29 Nov '95

29 Nov '95

OK. I am a small network service provider and I have two customers. One has service that is available 100% of the time. The other has service that due to various problems is available only 50% of the time (not sure why they stay with me, but I am happy to take their money). So what is the availability that I should report to potential new customers? 100% 50% or 75% Does it matter that the reason the one customer has only 50% availability is that the room where the router at that customer's site is underwater every other day due to no fault of my own? It is because of these sorts of questions that I never know what it means when someone says that their network is available 99.9% of the time. Hell at least part of MichNet is available 100% of the time, but that never seems to cut it with the folks who don't have service right now. -Jeff Ogden Merit/MichNet

5 6

URL mixup
by Susan R. Harris 29 Nov '95

29 Nov '95

My apologies for mixing up the URLs in this afternoon's "new RA tools" message. The tools for generating NAP routing table and route flap reports are both available at: http://www.ra.net/~ra/statistics/ --Susan Harris

1 0

Re: outages, quality monitoring, trouble tickets, etc
by Sean Donelan 28 Nov '95

28 Nov '95

>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. Highly redundant backbones remain extremely vunerable to the "glitch." Human glitches, software glitches, "impossible" data glitches. Redundant backbones do protect against the backhoe "glitch." >But since half the web servers I try to talk to refuse me half the time, >I'm not sure that network availability per se (HWB's complaints duly >acknowledged) is the tallest pole in the tent. Part of this problem is the growing number of interdepencies (complexity, chaos?). Even if each individual module is working 99.9% of the time, the probabilities start looking pretty bad when all need to be working at the same time. To make a web connection, you have a string of name servers, a string of networks to the name servers, a string of routers on those networks, another string of networks to the web server, another string of routers, more strings of networks and routers and servers on the return path. I'm amazed it even works 50% of the time. Unfortunately our customers aren't always as understanding. Since error reporting sucks in most network applications, it becomes the fault of whatever help desk happens to take the customers phone call. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: CIDR FAQ
by Steven J. Richardson 28 Nov '95

28 Nov '95

Hank: I'd really appreciate just getting this much message. Thanks, Steve R./Merit > Date: Tue, 28 Nov 95 13:11:21 IST > From: Hank Nussbacher <HANK(a)taunivm.tau.ac.il> > To: cidrd(a)IEPG.ORG, nanog(a)merit.edu, inet-access(a)earth.com, iap(a)vma.cc.nd.edu, local-ir(a)vma.cc.nd.edu, local-ir(a)apnic.net > > ------------------------------------------------------------------------ > The CIDR FAQ > Version 5 > 15 November 1995 > ------------------------------------------------------------------------ > The following document is a collection of Frequently Asked Questions > about CIDR. This document is not meant to be a networking/routing > guide and tutorial. Where appropriate pointers to other documents > of a more general nature have been mentioned. > > Updates from a previous version are marked with a '|' in column 1. > > If you have any questions you would like added, please send them to > the editor mentioned below: > > Hank Nussbacher (Tel Aviv University and IBM Israel) > hank(a)vm.tau.ac.il or hank(a)ibm.net.il > > If you would like to "discuss" items from this FAQ please send > your mail to cidrd(a)iepg.org > > This FAQ is being distributed to the following groups and lists: > alt.internet.services > alt.internet.access.wanted > nanog(a)merit.edu > inet-access(a)earth.com > iap(a)vma.cc.nd.edu > local-ir(a)ripe.net > cidrd(a)iepg.org > |local-ir(a)apnic.net > > To retrieve the most up-to-date version of this document: > |- ftp://ftp.ibm.net.il/pub/docs/cidr.faq > |- http://www.rain.net/faq/cidr.faq.html > ------------------------------------------------------------------------

1 0