- Test - lists.nanog.org

Re: Sprint violations
by Sean Doran 21 Sep '95

21 Sep '95

| So you are suggesting that we filter out the attached announcements | that are behind AS1239? | | Or to continue with the perfectly clear translations: | "I'm messing with your customers, so you can mess with mine." Yes, I hope that this is exactly what is done. If and when this happens, the prefixes that can be aggregated into something that will pass through inbound filters will be aggregated. Those that cannot will either a/ be SOL or b/ will require a special arrangement with everyone doing that type of filtering. Sean.

1 0

Sprint violations
by Mark Kent 21 Sep '95

21 Sep '95

>> Also, I note that we currently are not applying this list >> *outbound* or against customer BGP sessions. The reason for this >> is quite simple -- call it a (very) small incentive for other folks >> we peer with to apply the same kind of inbound filter against very >> long prefixes. So you are suggesting that we filter out the attached announcements that are behind AS1239? Or to continue with the perfectly clear translations: "I'm messing with your customers, so you can mess with mine." -mark 206.15.224.0/23 206.24.100.0 206.40.96.0 206.40.97.0 206.40.98.0 206.40.99.0 206.41.128.0/20 206.41.192.0/19 206.43.48.0/20 206.43.128.0/19 206.47.2.0 206.47.3.0 206.47.4.0 206.47.12.0 206.47.14.0 206.47.17.0 206.47.18.0 206.47.19.0 206.47.20.0 206.47.21.0 206.47.22.0 206.47.40.0 206.47.41.0 206.47.42.0 206.47.43.0 206.47.45.0 206.47.46.0 206.47.47.0 206.47.80.0 206.47.81.0 206.47.84.0 206.47.85.0 206.47.87.0 206.47.88.0 206.47.89.0 206.47.93.0 206.47.94.0 206.47.95.0 206.47.96.0 206.47.104.0 206.47.106.0 206.48.57.0 206.48.58.0 206.48.59.0 206.48.60.0 206.48.73.0 206.48.112.0/21 206.48.120.0/21 206.48.128.0/19 206.53.96.0/21 206.55.64.0/22 206.56.254.0 206.64.100.0 206.71.32.0/20 206.72.64.0/22 206.80.32.0/19 206.80.64.0 206.80.65.0 206.80.66.0 206.80.67.0 206.80.68.0 206.80.69.0 206.80.70.0 206.80.71.0 206.82.160.0/22 206.108.252.0 206.108.253.0 206.108.254.0 206.194.192.0 206.195.32.0/19 206.195.64.0 206.196.96.0/19 206.197.104.0 206.197.121.0 206.197.130.0 206.197.138.0 206.197.190.0 206.197.207.0 206.201.208.0/20 206.206.0.0 206.215.224.0/19

2 1

Merit GateD Consortium
by skh＠MERIT.EDU 21 Sep '95

21 Sep '95

Merit is now the Caretaker of the GateD Consortium. The Web page for Gated is available on: http://www.merit.edu/~gated. Versions 3.5.9, 3.5.10, 3.5.11 of gated are available via ftp ftp.gated.merit.edu in the net-research/gated directory or via Gopher from the gopher.gated.merit.edu in the Gated Distribution directory. Bugs can be reported to: gated(a)gated.merit.edu. We'd love to hear from people who discovered bugs in these version of gated. Any company who is a GateD consortium member can suscribe to a consoritum members mailing list (gated-members(a)gated.merit.edu.) Merit Staff will will answer any questions sent to the gated-members within a day. If you are a member, and would like to receive mail from that list please subscribe to gated-members-request(a)gated.merit.edu. Gated-people(a)merit.edu is for the exchange of information regarding GateD by those using GateD. If you interested in gated, I'd love to hear from you. Susan Hares Technical Contact Merit GateD Consortium skh(a)merit.edu

1 0

Re: filtering long prefixes
by Sean Doran 21 Sep '95

21 Sep '95

Credit where it's due: I note that PSI is currently announcing 206.0.0.0/13 with no more-specific prefixes. While I have had my differences with PSI, particularly wrt allocations made in The Swamp, I feel I have to praise them for doing a remarkably good job of aggregation in their newer CIDR blocks. Thanks, PSI! (Now, about your old stuff...) Sean. - -- Sean Doran <smd(a)sprint.net>

1 0

updated web pointer
by bmanning＠ISI.EDU 20 Sep '95

20 Sep '95

The ISI/RA web pointers have been updated. http://info.ra.net/div7/ra --bill

2 2

CERT Advisory CA-95:11 - Sun Sendmail -oR Vulnerability
by CERT Advisory 19 Sep '95

19 Sep '95

============================================================================= CA-95:11 CERT Advisory September 19, 1995 Sun Sendmail -oR Vulnerability ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of problems with the -oR option in sendmail. The problem is present in the version of sendmail that is available from Sun Microsystems, Inc. in SunOS 4.1.X, including patches 100377-19 (for SunOS 4.1.3), 101665-04 (for SunOS 4.1.3_U1), and 102423-01 (for SunOS 4.1.4). ***This vulnerability is widely known and is currently being actively exploited by intruders.*** The CERT staff recommends installing the appropriate patches as soon as they are available from Sun Microsystems. Alternatives are installing a wrapper or installing sendmail version 8.6.12; see Section III for details. (Although sendmail 8.7 recently became available, we have not yet reviewed it.) As we receive additional information relating to this advisory, we will place it in: ftp://info.cert.org/pub/cert_advisories/CA-95:11.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 way that the Sun Microsystems, Inc. version of sendmail processes the -oR option. This problem has been verified as existing in the version of sendmail that is in SunOS 4.1.X, including patches 100377-19 (for SunOS 4.1.3), 101665-04 (for SunOS 4.1.3_U1), and 102423-01 (for SunOS 4.1.4). The -oR option specifies the host, called the mail hub, to which mail should be forwarded when a user on a client of that hub receives mail. This host can be identified with the -oR option on the command line as -oRhost_name or in the configuration file as: ORhost_name or by NFS mounting the /var/spool/mail directory from a file server, probably from the mail hub. In this case, the host name of the file server is used as the forwarding host identified as host_name above. All these configurations are vulnerable. II. Impact By exploiting the vulnerabilities, local users may be able to gain unauthorized root access and subsequently read any file on the system, overwrite or destroy files, or run programs on the system. Remote users cannot exploit this vulnerability. III. Solutions A. Install a patch from Sun when it becomes available. As of the date of this advisory, patches are not available to fix this problem. B. Install the sendmail wrapper available from ftp://ftp.cs.berkeley.edu/ucb/sendmail/sendmail_wrapper.c ftp://ftp.auscert.org.au/pub/auscert/tools/sendmail_wrapper.c Checksum: MD5 (sendmail_wrapper.c) = fb53f92b6fc539766cd69e8b08909ba1 C. An alternative to using the patch or wrapper is to install sendmail 8.6.12 and the sendmail restricted shell program ("smrsh"). (Although sendmail 8.7 recently became available, we have not yet reviewed it.) 1. Install sendmail 8.6.12 Sendmail is available by anonymous FTP from ftp://ftp.cs.berkeley.edu/ucb/sendmail ftp://info.cert.org/pub/tools/sendmail/sendmail.8.6.12 ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail ftp://ftp.cert.dfn.de/pub/tools/net/sendmail Checksums: MD5 (sendmail.8.6.12.base.tar.Z) = 31591dfb0dacbe0a7e06147747a6ccea MD5 (sendmail.8.6.12.cf.tar.Z) = c60becd7628fad715df8f7e13dcf3cc6 MD5 (sendmail.8.6.12.misc.tar.Z) = 6212390ca0bb4b353e29521f1aab492f MD5 (sendmail.8.6.12.patch) = 10961687c087ef30920b13185eef41e8 MD5 (sendmail.8.6.12.xdoc.tar.Z) = 8b2252943f365f303b6302b71ef9a841 A note on configuration: Depending upon the currently installed sendmail program, switching to a different sendmail may require significant effort, such as rewriting the sendmail.cf file. We strongly recommend that if you change to sendmail 8.6.12, you also change to the configuration files that are provided with that version. In addition, a paper is available to help you convert your sendmail configuration files from Sun's version of sendmail to one that works with version 8.6.12: "Converting Standard Sun Config Files to Sendmail Version 8" by Rick McCarty of Texas Instruments Inc. This paper is included in the sendmail.8.6.12.misc.tar.Z file and is located in contrib/converting.sun.configs. 2. Install the sendmail restricted shell program To restrict the sendmail program mailer facility, install the sendmail restricted shell program (smrsh) by Eric Allman (the original author of sendmail), following the directions included with the program. Copies of this program may be obtained from ftp://info.cert.org/pub/tools/smrsh ftp://ftp.uu.net/pub/security/smrsh The checksums are MD5 (README) = fc4cf266288511099e44b664806a5594 MD5 (smrsh.8) = 35aeefba9714f251a3610c7b1714e355 MD5 (smrsh.c) = d4822ce7c273fc8b93c68e39ec67739c --------------------------------------------------------------------------- The CERT Coordination Center thanks AUSCERT for providing the sendmail wrapper. --------------------------------------------------------------------------- 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

The InterNIC's talk at NANOG
by peterb＠telerama.lm.com 17 Sep '95

17 Sep '95

Thanks for spending an hour, hour and a half talking about your plans for the domain name system without once mentioning your plans to start charging registration. That's why I go to NANOG -- so I can find out about major policy changes from "USA Today" and "Good Morning America". Peter PS: Mind you, I think it's completely reasonable for the NIC to charge, and have no opposition to the policy. But it would have been appropriate for you to have mentioned it in that forum. -- "Actually, you just think that's a telephone. Really, it's the alarm that rings whenever I get out of my chair." -- E.S. Peter Berger. System Administrator, Telerama Public Access Internet http://www.lm.com/~peterb Serving Pittsburgh since 1991.

1 0

Another tool to look at?
by sob＠academ.com 15 Sep '95

15 Sep '95

> bing can be found (thanks to www.infoseek.com) at > > http://www.cnam.fr/Network/bing.html > > dennis This has been briefly disucssed on the IAP list. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Other flapping prefixes. Compare and contrast.
by kwe＠6SigmaNets.com 14 Sep '95

14 Sep '95

At 7:40 AM 9/11/95, Hans-Werner Braun wrote: > >Well, while Sean's wording at times is, ahem, suboptimal, he is >referring to a real problem in the Internet System, and in fact one >that the North American Network Operators Group should take >responsibility for, at least for the North American part. The problem >is what others believe is a strength: an anarchic system of many >autonomous service providers with little or no service model/metrics >(neither for the local nor for the system level), and no well defined >rules of conduct for interoperation and problem resolution. H-W; There was once, and still technically may be, the "User Connectivity Problems" (UCP) working group in the IETF Ops area that began a process for coordination among the then regional NSFnet network's NOCs back in '90 or so. Much of the work accomplished by UCP on developing process for NOC-to-NOC coordination is still valid, but the players have increased in number and are re-inventing this wheel. So, the Internet anarchy has been under attack for some time now. If there is any interest (I know, hacking the configs is #1, formal coordination and documentation are a distant #2) I'll go look up some of the documents. --Kent

1 0

agenda page is up
by sob＠academ.com 14 Sep '95

14 Sep '95

The "home" page for the latest NANOG is up at the following URL: http://www.academ.com/nanog/september1995/index.html The notes will be filled in over the weekend and the slide will be filled in as I get them and process them. Enjoy. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0