September 1995 - Test - lists.nanog.org

CERT Summary CS-95:02
by CERT Advisory 26 Sep '95

26 Sep '95

--------------------------------------------------------------------------- CERT Summary CS-95:02 September 26, 1995 The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our incident response staff. The summary includes pointers to sources of information for dealing with the problems. Starting with this summary, we will also list new or updated files that are available for anonymous FTP from ftp://info.cert.org Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries --------------------------------------------------------------------------- Recent Activity --------------- Since the July CERT Summary, we have seen these continuing trends in incidents reported to us: 1. Sendmail Attacks We receive several reports each week of attacks through sendmail, with intruders using a variety of techniques. Most of the attacks are aimed at gaining privileged access to the victim machine. To combat these threats, we encourage sites to take the appropriate steps outlined in the following: ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_advisories/CA-95:11.README ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-95:08.README A number of sites have reported some confusion on the need to continue using the sendmail restricted shell program (smrsh). You need to run the smrsh tool in conjunction with the most recently patched version of sendmail for your system. Information on the smrsh tool can be obtained from these places in ftp://info.cert.org/pub/ tools/sendmail/smrsh/ cert_advisories/CA-93:16.sendmail.vulnerability cert_advisories/CA-93:16a.sendmail.vulnerability.supplement cert_advisories/CA-93:16a.README cert_advisories/CA-95:11.sun.sendmail-oR.vul cert_advisories/CA-95:11.README The smrsh program can be obtained from ftp://info.cert.org/pub/tools/smrsh/ It is included in the sendmail 8.7 distribution. 2. Network Scanning Several incidents have recently been reported in which intruders scan a large address range using the Internet Security Scanner (ISS). As described in CERT advisory CA-93:14, this tool interrogates all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. Intruders have used the information gathered from these scans to compromise sites. We are aware of many systems that have suffered a root compromise as a result of information intruders obtained from ISS scans. You may wish to run ISS against your own site in accordance with your organization's policies and procedures. ISS is available from ftp://info.cert.org/pub/tools/iss/iss13.tar We encourage you to take relevant steps outlined in these documents: ftp://info.cert.org/pub/cert_advisories/CA-93:14.Internet.Security.Scanner ftp://info.cert.org/pub/cert_advisories/CA-93:14.README ftp://info.cert.org/pub/tech_tips/security_info ftp://info.cert.org/pub/tech_tips/packet_filtering 3. Exploitation of rlogin and rsh We have received some reports about the continued exploitation of a vulnerability in rlogin and rsh affecting IBM AIX 3 systems and Linux systems. This is not a new vulnerability, but it continues to exist. Sites have reported encountering some Linux distributions that contain this vulnerability. Information on this vulnerability and available solutions can be obtained from ftp://info.cert.org/pub/cert_advisories/CA-94:09.bin.login.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-94:09.README 4. Packet Sniffers We continue to receive new incident reports daily about sniffers on compromised hosts. These sniffers, used to collect account names and passwords, are frequently installed using a kit. In some cases, the packet sniffer was found to have been running for months. Occasionally, sites had been explicitly warned of the possibility of such a compromise, but the sniffer activity continued because the site did not address the problem in the comprehensive manner that we suggest in our security documents. Further information on packet sniffers is available from ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/cert_advisories/CA-94:01.README Information about detecting sniffers using cpm is in the CA-94:01.README file. What's New in the CERT FTP Archive ---------------------------------- We have made the following changes since June 1, 1995. * New Additions: ftp://info.cert.org/pub/ incident.reporting.form (the form you should fill out when reporting an incident to our staff) ftp://info.cert.org/pub/cert_advisories/ CA-95:08.sendmail.v.5.vulnerability CA-95:09.Solaris.ps.vul CA-95:10.ghostscript CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_bulletins/ VB-95:05.osf (OSF/DCE security hole) VB-95:06.cisco (vulnerability in Cisco's IOS software) ftp://info.cert.org/pub/tech_tips/ AUSCERT_checklist_1.0 (UNIX checklist developed by the Australian Emergency Response Team) * Updated Files ftp://info.cert.org/pub/cert_advisories/ CA-93:14.README (Internet Security Scanner) CA-94:01.README (network monitoring) CA-94:02.README (SunOS rpc mountd vulnerability) CA-94:05.README (md5) CA-94:11.README (majordomo) CA-95:01.README (IP spoofing and hijacked terminal connections) CA-95:02.README (binmail vulnerabilities) CA-95:05.README (sendmail - several vulnerabilities) CA-95:08.README (sendmail version 5 and IDA sendmail) CA-95:09.README (Solaris ps) CA-95:11.README (Sun sendmail -oR vulnerability) We have begun adding a note to advisory README files reminding readers to check with vendors for current checksum values. After we publish checksums in advisories and READMEs, files and checksums are sometimes updated at individual locations. * Other Changes: As we will no longer be keeping the lsof directory current, the directory and its files have been removed from our FTP site. The current version of lsof is available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof --------------------------------------------------------------------------- How to Contact the CERT Coordination Center Email cert(a)cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-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 To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request(a)cert.org CERT advisories and bulletins are posted on the USENET news group comp.security.announce If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. We can support a shared DES key, PGP, or PEM (contact CERT staff for details). Location of CERT PGP key ftp://info.cert.org/pub/CERT.PGP_key --------------------------------------------------------------------------- Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center. CERT is a service mark of Carnegie Mellon University.

1 0

Re: 204.82.160.0/22 invisible
by Hank Nussbacher 26 Sep '95

26 Sep '95

On Mon, 25 Sep 1995 00:41:31 -0400 you said: >If you are small, you can only get a small network assignment (slow start), >as you will be running into the Great Wall "Internic" even with a request >for a /22, and if you really succeed with your /22 or /20 assignment, >you will have to discover that the conspiracy of the big 6 (laugh!) might >have decided you are not worthy, and to go route what you got to yourself >and don't expect them even wanting to know about it. If, on the other hand, Even being big won't help. I know of a certain multinational company that has just spent $15M on lines and routers covering Europe (30 cities) and was only allowed to get a /19 since that is what one gets when one is new to the block, irregardless of whether you are in one city with a 256kb line to Dante or Ebone and 32 modems or whether you are a planning on being a big player (since, I guess, everyone comes along and shows how they are a *big* player). So this company went out and bought out a European ISP with a class A and has now solved its IP address shortage. >Kai Schlichting >Internet Project Manager, BelCom, Inc. >kai(a)belcom.net Hank Nussbacher Israel

1 0

Re: Peering in the LA region?!?:$
by kbc＠exodus.net 26 Sep '95

26 Sep '95

We are active in the Los Angeles Area and will be interested in peering arrangements there. Chandra Sekhar Exodus Communications, Inc. 1-800-263-8872

1 0

Re: Peering in the LA region?!?
by feldman＠MFSDatanet.COM 26 Sep '95

26 Sep '95

I'm sure John Hardie would be happy to talk to you about building an interconnect in LA. He'll be at Interop in Atlanta this week. Steve > Just curious, but after looking around at several sites in LA, I was curious > if ANYONE was actually doing any significant peering in the LA basin? > Currently > we are looking for multiple interconnects down there in the 10mbps/T3 range, > however we can't find anyone... > > We currently have a little >1000sq ft in the One Wilshire building. Is > there anyone else in that building? *SIGH* I was meaning to ask this while > I was at nanog, but other events caused me to forget to ask...

3 2

Peering in the LA region?!?
by Marcos Della 26 Sep '95

26 Sep '95

Just curious, but after looking around at several sites in LA, I was curious if ANYONE was actually doing any significant peering in the LA basin? Currently we are looking for multiple interconnects down there in the 10mbps/T3 range, however we can't find anyone... We currently have a little >1000sq ft in the One Wilshire building. Is there anyone else in that building? *SIGH* I was meaning to ask this while I was at nanog, but other events caused me to forget to ask... Marcos -- ''' (o o) --------------------------oOO--(_)--OOo-------------------------- Marcos R. Della Email: mdella(a)InterNex.Net Director, Network Engineering InterNex Information Services Phone: 408/496-5466 http://www.internex.net/~mdella

5 4

Re: Peering in the LA region?!?
by hoodr＠netcom.com 26 Sep '95

26 Sep '95

> Just curious, but after looking around at several sites in LA, I was curious > if ANYONE was actually doing any significant peering in the LA basin? > Currently > we are looking for multiple interconnects down there in the 10mbps/T3 range, > however we can't find anyone... Is anyone interested in using the PacBell/GTE SMDS cloud down there? I'm pretty sure CERFnet has a connection into the cloud already, and ours is on the way. -- Robert Hood hoodr(a)netcom.com 1-408-551-2160 Manager of Network Operations for NETCOM On-line Communications Services, Inc.

1 0

Re: 206.82.160.0/22
by jnc＠ginger.lcs.mit.edu 26 Sep '95

26 Sep '95

From: gih(a)aarnet.edu.au (Geoff Huston) Given the interaction between the costs of renumbering, vs the cost of establishing an entry in the routing tables, vs the cost of dynamic address translation then its not obvious whether pricing policies should apply to address space allocation, routing table entries or both! It's a truism of large-scale system design (in both biology as well as computers :-) that a single mechanism can do two things well at small scales, but not larger ones. This says to me that a pricing policy that attempts to meet a number of goals (e.g. control routing table growth, maximize efficiency of address space usage) by pricing a single thing is just not going to be as effective, overall, at those goals, as a number of separate pricing policies on different resources. (Hmm, maybe that principle above applies to economics as well? Makes sense, economics and biology have close ties...) Of course, two separate mechanisms (or indeed, any at all) are a lot more complexity, administrative overhead, hassle expended in setting policies (look at DNS name charging :-), etc, etc, so you have to step back and ask, overall, if the gains in getting closer to those goals (using either one mechanism or two) are worth what it costs in complexity, etc. None of which is much help in answering the question "should we price none, one, or both". What I suspect is that we will price none until we simply can't go on without charging, which makes sense; the administrative overhead of charging will be a major headache, so the situation will have to be dire to make it worth it. Noel

1 0

Re: 206.82.160.0/22
by gih＠aarnet.edu.au 26 Sep '95

26 Sep '95

At 5:06 PM 26/9/95, David Conrad wrote: >>I'm arguing that economics have to enter the picture for any application >>for IP address space a registry receives. > >See RFC 1744 for more details. Note that option c is theoretically >not available -- according to current and likely future guidelines, >buying/selling of addresses is essentially disallowed, addresses >should be returned to the orgininating registry to be reallocated as >criteria are met. I would be very interested in hearing people's >opinions regarding this aspect of current allocation guidelines. I would observe that option c) happens today - its just that the parties involved don't inform the InterNIC (becuase if you try to undertake the transfer of title the InterNIC simply takes the address space away. The picture is somewhat complex in so far as IP address space has intrinsic value _as long as it is routeable_. Given the interaction between the costs of renumbering, vs the cost of establishing an entry in the routing tables, vs the cost of dynamic address translation then its not obvious whether pricing policies should apply to address space allocation, routing table entries or both!

1 0

Re: 206.82.160.0/22
by Sean Doran 26 Sep '95

26 Sep '95

However, that aside, I think your policy is reasonable, and just hope it helps cover your costs. Sean.

1 0

Re: 206.82.160.0/22
by Sean Doran 26 Sep '95

26 Sep '95

>I would be very interested in hearing people's opions ?regarding this aspect of current allocation guidelines. It's a joke. Moreover, it's a stupid joke that will wreck the value of registries as sources of accurate information. If the contact person or an officer of the contact organization tells me that a prefix is now to be used by another party, whether it's bought or traded or inherited or sold or whatever, I don't care, I'll route it, provided it's aggregatable into something reasonably short. And if the registries don't update to the new contacts, so what? Sean.

1 0