- Test - lists.nanog.org

Re: routing problem
by Joe Pruett 13 Dec '95

13 Dec '95

i was trying to keep the message short, and i probably elided a bit too much. we're just using bgp for outgoing routing, no load balancing. we've made sure that as3838 isn't filtering, and their upstream providers (alternet and agis) claim to not be filtering, either.

1 0

routing problem
by Joe Pruett 13 Dec '95

13 Dec '95

i hope this is appropriate for this list. 192.108.254.0/24 is being announced from as5798 via as3130 and as3838. we have an radb entry for it. there was an mci entry until monday night. but as of today (wednesday) we still get all incoming traffic via as3130. outgoing seems to be fairly well balanced between our providers, so the theory says that we should get about equal data in from them too. maybe some of you can look at your routers and help me figure out why we aren't getting any data in via as3838. any other clues would be greatly appreciated as well.

2 1

Re: Sprint BGP filters in 207.x.x.x?
by Ted Linnenkamp 13 Dec '95

13 Dec '95

Message-ID: red-13-msg951213213258MTP[01.51.00]000000ac-28766 MCI announces smaller routes for its customers that do not use the CIDR blocks given to MCI. If you brought address space to MCI they would announce it. The most important thing is that on NEW CIDR blocks they stay aggregated. This is why Sprint will not listen to the announcement of /18 or less address space in the 207.xx/8 block. Painful but effective. Ted L. ---------- From: Jon Zeeff <jon(a)branch.com> To: <cook(a)cookreport.com> Cc: <dmbarton(a)mci.net>; <smd(a)chops.icp.net>; <freedman(a)netaxs.com>; <nanog(a)merit.edu> Subject: Re: Sprint BGP filters in 207.x.x.x? Date: Wednesday, December 13, 1995 1:17PM I think this is misleading. MCI does announce routes smaller than this for its customers. > MCI aggregates all its customer's routes into /19's. We have just

1 0

Re: chicago nap questions
by reb＠aads.net 13 Dec '95

13 Dec '95

> At 8:16 PM 12/7/95, Gordon Cook wrote: > > went looking for aadsnet on ameritechs chicago nap web page > > couldn't find them. But shouldn't they be there to get the rest of their > customers to the rest of the internet? AADSNet does not use the NAP for connectivity to the Internet for it's Chicago LATA customers. eric ---- R. Eric Bennett <reb(a)aads.net> | 339 E. Liberty, Suite 310 Internet Engineering | Ann Arbor, MI 48014 Ameritech Advanced Data Services | (313) 913-0802 "We're from the phone company, we're here to help."

1 0

Bogon /8 announcment from PSI
by asp＠uunet.uu.net 13 Dec '95

13 Dec '95

Network Next Hop Metric LocPrf Weight Path *>i5.0.0.0 192.41.177.235 10 100 0 174 i * i 149.20.64.33 10 100 0 174 i * i 149.20.64.33 10 100 0 174 i *>i102.0.0.0 192.41.177.235 10 100 0 174 i * i 149.20.64.33 10 100 0 174 i * i 149.20.64.33 10 100 0 174 i 64/8 to 126/8 are reserved. So is 5/8. --asp(a)uunet.uu.net (Andrew Partan)

2 2

Re: Sprint BGP filters in 207.x.x.x?
by sob＠academ.com 13 Dec '95

13 Dec '95

Gordon, There are lots of reasons a provider might aggregate networks for their customers. One is that many customers are not able to run routing protocols that do aggregation (customers that are not running routing protocols and use a static default is one example). In fact, in this case Sprint ought be doing aggregation for such customers (and I am sure they are). In any case, MCI's policy is not unique. Many providers do this. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Sprint BGP filters in 207.x.x.x?
by SURAnet NACR Account 13 Dec '95

13 Dec '95

> Aside from what Daniel says about Sprint and MCI's routing policy > mismatch, this statement is interesting on another level. For Dan says: > MCI aggregates all its customer's routes into /19's. This is new is it > not? Also it says *MCI* does the aggregating and not the customer. > Would someone please explain how this differs from what I understand to > be Sprints policy which says (i believe) that it is the CUSTOMER's > responsibility to aggregate the routes they present to sprint??? The difference is that MCI refers to addresses assigned out of their CIDR block. They are saying that they are aggregating nets on a /19 basis- one might assume on a per pop basis, or something similar. > Why would MCI do the aggregating? Is such mci policy good for mci or > good for the customer or equally good for both? They are not referring to proxy aggregation of PI address space. That is another religious war altogether. This is good policy, in that they are aggregating. They are most likely prevented from aggregating their announcements further to their peers in the interests of maintaining better routing policy to the individual nets- for example, say part of the space was in new york, and another was in dallas. If they only announced the aggregated /16 to their peers, their peers would pass off traffic to the closest announcement of the aggregate, as opposed to passing the net off to the closest place to the destination. 'Course, I remember that some poeple are shortest exit to MCI anyway- but that may have changed. _k

1 0

Sprint's filter
by Dorian Kim 12 Dec '95

12 Dec '95

For those who didn't save this the first time. -dorian ---------- Forwarded message ---------- Date: Sat, 23 Sep 1995 18:46:01 -0400 From: Sean Doran <smd(a)sprint.net> To: nanog(a)MERIT.EDU Subject: access-list 112 This is probably ugly and difficult to read. It also can be trimmed, but has been left overly-long and overly-paranoid for readability when using "show access-list 112" and because the IOS 10.3 distribute-list caching doesn't seem to mind the extra deny clauses all that much. Sean. - -- ! list 112 - deny more specifics of some prefixes ! ! IMPORTANT-TO-REMEMBER SYNTAX FOR BGP distribute-list! ! access-list <#> <permit|deny> ip <prefix> <don't care bits> <mask> <don't care bits> ! ! clear old list ! no access-list 112 ! ! this was originally ordered A, B, C and side-effects, but ! what we really want to do is put the permit clauses up front ! starting with the swamp, as this will match the most prefixes ! !!!!! START ! !!!! PERMITs ! !!! C space !! permit /24s in 192/8-205/8. ! (192==1100 0000, 205==1100 1101) ! ! allow M =< /24 in 1100 xx0x * ! (allow mask bits in first three octets) ! 1100xx0x == {192,193,196,197,200,201,204,205} ! access-list 112 permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 ! ! ! allow M =< /24 in 1100 {0010,0011,0110,0111,1010,1011} ! (which really means 1100 {001x,011x,101x}, ! which in turn is really 1110 {x01x,011x}} ! 1100x01x == {194,195,202,203} ! 1100011x == {198,199} ! access-list 112 permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 access-list 112 permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 ! ! !! hack - allow M =< /19 in 206/8 ! access-list 112 permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 ! ! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1110xxxx == {208-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 ! ! !!! B space !! permit /16s in old B-space ! 10xx xxxx * ! (we don't care what bits are in the first two octets ! of the mask; the second two octets must be 0) ! access-list 112 permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 ! ! !!! A space !! permit /8s and shorter prefixes in old A-space ! 0xxx xxxx * would be simple but unsafe from 0/8 POV, so ! we make sure that there is at least one 1 bit in the first ! octet's last seven bits, and that the first bit is 0; ! we don't care what bits are set in the mask, because ! we assume IOS won't present us with a prefix with ! bits set in the prefix's first octet but not in the mask, ! unless it's a long mask... ! ! 126=01111110 (IOW, CddddddC C==CARE, d=don't care) ! 125=01111101 ! ... ! 95=01011111 ! 63=00111111 ! access-list 112 permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0 ! ! !! permit 9.20.0.0/18 and 9.2/16 by exact match ! (both IBM early birds wrt subnets of As) ! access-list 112 permit ip 9.2.0.0 0.0.255.255 255.255.0.0 0.0.0.0 access-list 112 permit ip 9.20.0.0 0.0.255.255 255.255.192.0 0.0.0.0 ! !! permit exp39 /24s and shorter prefixes only ! (no ones set in the fourth octet) ! access-list 112 permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0 ! ! !!!! DENYs ! ! This is super paranoia. At this point we have permitted ! all valid unicast prefixes and masks. ! In theory, we could end right here with a ! ! access-list 112 deny ip any any ! ! but this section below offers some degree of clarity ! policy-wise... (at least to me, but I'm weird -- smd) ! ! we also could have done a quick deny after each permit ! to catch any prefixes which didn't pass the permit filters, ! however, as noted below, I am superparanoid about ! funny, noncontiguous masks and other weirdnesses, and ! would like to be able to see them being caught, if ! they ever get as far as the access-list. ! !!! A space !! deny 0/(9-15) - 127/(9-15) ! deny subnets in old-style class A space, first octet ! (if any bit set in bit 8-15 (second octet), deny) ! ! this is a paranoid way of writing this out; ! less paranoia would let us write: ! ! ... deny ip 0.0.0.0 127.0.0.0 0.0.0.0 255.128.0.0 ! ! because we believe in contiguous netmasks; so we would ! never have a /18 if we block /17. ! ! However, better safe than sorry... ? ! ! 0xxx xxxx * ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 ! !!! B space !! deny 0-127/16, 0-(17-23) - 191/(17-23) ! deny subnets in old-style class-B space ! and second octet of class A space. ! (first two bits will be 00 or 10; so x0xx xxxx; 191==10111111) ! (if any bit set in 16-23, deny) ! we also need to zap 0xxx xxxx * /16 ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 ! ! !!! C space !! deny 206/(19-23) - 239/(19-23) ! block prefixes longer than /18 in 207/8-239/8 ! no < /18 in 1100 1110 *, 1100 1111 *, 1110 xxxx * ! ! we block all M => /24 below and we did /17-/23 for 0/8-191/8 above, ! so we only need to worry about 19-23 for 207/8-239/8 ! ! first, in 1100 111x (206/8, 207/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 ! ! next in 1101 xxxx (208/8-239/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255 ! !!! all UNICAST space !! deny ANY/24, ANY/(25-32) ! now we block the final octet for 0/8-239/8 ! (because we specifically allowed /24s in 192/8-205/8, we can ! just block everything in xxxx xxxx * that has any 1 bits in 4th octet) ! access-list 112 deny ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.0 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.128 255.255.255.127 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.64 255.255.255.191 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.32 255.255.255.223 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.16 255.255.255.239 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.8 255.255.255.247 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.4 255.255.255.251 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.2 255.255.255.253 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.1 255.255.255.252 ! !!! all IP space !! deny 240/(4-32), 0/(8-32) ! finally, we get rid of any announcements that are bogons ! 240/8-255/8 and 0/8 ! 1111 xxxx * and 0000 0000 * (any mask) ! we can leave this last as it's likely almost never to happen ! access-list 112 deny ip 255.0.0.0 15.255.255.255 0.0.0.0 255.255.255.255 access-list 112 deny ip 0.0.0.0 0.255.255.255 0.0.0.0 255.255.255.255 ! !!!!! END end

1 0

CERT Advisory CA-95:17 - rpc.ypupdated vulnerability
by CERT Advisory 12 Dec '95

12 Dec '95

============================================================================= CA-95:17 CERT Advisory December 12, 1995 rpc.ypupdated Vulnerability ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of a vulnerability in the rpc.ypupdated program. An exploitation program has also been posted to several newsgroups. This vulnerability allows remote users to execute arbitrary programs on machines that provide Network Information Service (NIS) master and slave services. Client machines of an NIS master or slave server are not affected. See Section III for a test to help you determine if you are vulnerable, along with a workaround. In addition, Appendix A contains a list of vendors who have reported their status regarding this vulnerability. As we receive additional information relating to this advisory, we will place it in: ftp://info.cert.org/pub/cert_advisories/CA-95:17.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description The rpc.ypupdated program is a server used to change NIS information from a network-based client using various methods of authentication. Note: The Network Information Service (NIS) was formerly known as Sun Yellow Pages (YP). The functionality of the two remains the same; only the name has changed. The name Yellow Pages is a registered trademark in the United Kingdom of British Telecommunications plc, and may not be used without permission. Clients connect to rpc.ypupdated and provide authentication information and proposed changes to an NIS database. If authenticated, the information provided is used to update the selected NIS database. The protocol used when clients communicate with a server only checks to see if the connection is authentic using secure RPC. The protocol does not check to see if the client is authorized to modify the NIS data or if the given NIS map exists. Even after an unsuccessful attempt to update the NIS information, the rpc.ypupdated server invokes the make(1) program to propagate possible changes. The invocation of make is implemented in an insecure fashion which allows the requesting client to pass malicious arguments to the call resulting in the execution of arbitrary commands on NIS master and slave servers. II. Impact Remote users can execute commands on vulnerable NIS master and slave machines. III. Solution First determine if you are vulnerable (see Sec. A below). If you are vulnerable, either follow the instructions vendors have provided in Appendix A or apply the workaround in Sec. B below. A. Consult the vendor information in Appendix A. If your vendor is not listed, then check to see if your system has an rpc.ypupdated server. To do this check, consult your system documentation or look in your system initialization files (e.g., /etc/rc*, /etc/init.d/*, and inetd.conf) for rpc.ypupdated or ypupdated. If you find a reference to this program on your system, then it is likely that you are vulnerable. B. Until patches are available for vulnerable systems, we recommend that you disable rpc.ypupdated as soon as possible. Below are some examples given for reference only. Consult your system documentation for the exact details. In these examples, the rpc.ypupdated program is killed if it is running, and the system is reconfigured so that the daemon does not automatically start again when the system is rebooted. Example 1 - SunOS 4.1.X For SunOS 4.1.X master and slave NIS servers, the rpc.ypupdated program is started by the /etc/rc.local script. First, determine if the server is running, and kill it if it is. Then, rename rpc.ypupdated so that the /etc/rc.local script will not find and therefore start it when the system reboots. # /bin/uname -a SunOS test-sun 4.1.4 1 sun4m # /bin/ps axc | /bin/grep rpc.ypupdated 108 ? IW 0:00 rpc.ypupdated # /bin/kill 108 # /bin/ps axc | /bin/grep rpc.ypupdated # /bin/grep ypupdated /etc/rc /etc/rc.local /etc/rc.local: if [ -f /usr/etc/rpc.ypupdated -a -d /var/yp/$dname ]; then /etc/rc.local: rpc.ypupdated; echo -n ' ypupdated' # /bin/mv /usr/etc/rpc.ypupdated /usr/etc/rpc.ypupdated.CA-95:17 # /bin/chmod 0 /usr/etc/rpc.ypupdated.CA-95:17 Example 2 - IRIX On IRIX systems, ypupdated is started by the inetd daemon. For versions 3.X, 4.X, 5.0.X, 5.1.X, and 5.2, the ypupdated is enabled; but for versions 5.3, 6.0.X, and 6.1, it is disabled. Note that the byte counts given for /bin/ed may vary from system to system. Note also that the inetd.conf file is found in different locations for different releases of IRIX. For 3.X and 4.X, it is located in /usr/etc/inetd.conf. For all other releases (5.0.X, 5.1.X, 5.2, 5.3, 6.0.X, and 6.1) it is in /etc/inetd.conf. # /bin/uname -a IRIX test-iris 5.2 02282015 IP20 mips # /bin/grep ypupdated /etc/inetd.conf ypupdated/1 stream rpc/tcp wait root /usr/etc/rpc.ypupdated ypupdated # /bin/ps -eaf | /bin/grep rpc.ypupdated root 184 1 0 Nov 20 ? 0:00 /usr/etc/rpc.ypupdated root 14694 14610 2 11:30:07 pts/3 0:00 grep -i rpc.ypupdated # /bin/kill 184 # /bin/ed /etc/inetd.conf 3344 /^ypupdated/s/^/#DISABLED# /p #DISABLED# ypupdated/1 stream rpc/tcp wait root /usr/etc/rpc.ypupdated ypupdated w 3355 q # /bin/ps -eac | /bin/grep inetd 193 TS 26 ? 0:04 inetd # /bin/kill -HUP 193 --------------------------------------------------------------------------- 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 non-commercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. .............................................................................. Appendix A: Vendor Information Current as of December 12, 1995 See CA-95.17.README for updated information Below is information we have received from vendors. If you do not see your vendor's name below, please contact the vendor directly for information. Apple Computer, Inc. ------------------- A/UX does not include this functionality and is therefore not vulnerable. Berkeley Software Design, Inc. (BSDI) ------------------------------------- BSD/OS by Berkeley Software Design, Inc. (BSDI) is not vulnerable. Data General Corporation ------------------------ Data General believes the DG/UX operating system to be NOT vulnerable. This includes all supported release, DG/UX 5.4 Release 3.10, DG/UX Release 4.10 and all related Trusted DG/UX releases. Digital Equipment Corporation ----------------------------- OSF/1 on all Digital platforms is not vulnerable. Analysis of ULTRIX is under way, and information will be available soon. Hewlett-Packard Company ----------------------- HP-UX versions 1.01, 10.10, and 10.20 are vulnerable. Solution: Do not run rpc.ypupdated. rpc.ypupdated is used when adding or modifying the public:private key pair in the NIS map public key.byname via the chkey command interface. rpc.ypupdated should ONLY be run while changes are being made, then terminated when the changes are complete. Make sure you re-kill rpc.ypupdated after each reboot. NEC Corporation --------------- OS Version Status ------------------ ------------ -------------------------- EWS-UX/V(Rel4.0) R1.x - R2.x not vulnerable R3.x - R6.x vulnerable EWS-UX/V(Rel4.2) R7.x - R10.x vulnerable EWS-UX/V(Rel4.2MP) R10.x vulnerable UP-UX/V R2.x not vulnerable R3.x - R4.x vulnerable UP-UX/V(Rel4.2MP) R5.x - R7.x vulnerable UX/4800 R11.x vulnerable --------------------------------------------------------------- The following is a workaround for 48 series. ypupdated program is started by the /etc/rc2.d/S75rpc script. First, determine if the server is running, killing it if it is. Then, rename ypupdated so that the /etc/rc2.d/S75rpc script will not find and therefore start it when the system reboots. # uname -a UNIX_System_V testux 4.2 1 R4000 r4000 # /sbin/ps -ef | /usr/bin/grep ypupdated root 359 1 0 08:20:05 ? 0:00 /usr/lib/netsvc/yp/ypupdated root 19938 836 0 23:13:20 pts/1 0:00 /usr/bin/grep ypupdated # /usr/bin/kill 359 # /sbin/mv /usr/lib/netsvc/yp/ypupdated /usr/lib/netsvc/yp/ypupdated.CA-95:17 # /usr/bin/chmod 0 /usr/lib/netsvc/yp/ypupdated.CA-95:17 -------------------------- Contacts for further information: E-mail:UX48-security-support@nec.co.jp Open Software Foundation ------------------------ YP/NIS is not part of the OSF/1 Version 1.3 offering. Hence, OSF/1 Version 1.3 is not vulnerable. Sequent Computer Systems ------------------------ Sequent does not support the product referred to in this advisory, and as such is not vulnerable. Silicon Graphics Inc. (SGI) --------------------------- IRIX 3.x, 4.x, 5.0.x, 5.1.x, 5.2: vulnerable. Turn off rpc.ypudated in inetd.conf; it is shipped with this turned on. IRIX 5.3, 6.0, 6.0.1: rpc.ypupdated was off as distributed. Turn off if you have turned it on. Solbourne --------- Not vulnerable. Sun Microsystems, Inc. ---------------------- SunOS 4.1.X is vulnerable. [Note from CERT Coordination Center: We have examined Solaris and found that Solaris 2.x is not shipped with NIS support and the vulnerability is not present. There is an extra software package named the "Solaris Name Service Transition Kit" which in version 1.2, the current version, does not contain the rpc.ypupdated program and is therefore not vulnerable. However, version 1.0 of the Solaris Name Service Transition Kit does contain rpc.ypupdated and is therefore presumed to be vulnerable.]

1 0

chicago nap questions
by Gordon Cook 08 Dec '95

08 Dec '95

went looking for aadsnet on ameritechs chicago nap web page couldn't find them. But shouldn't they be there to get the rest of their customers to the rest of the internet? can anyone tell me what the following is all about? 198.32.130.228 aads-F.sprint.net any help appreciated. ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $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 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************

2 1