From Firewalls-Owner Mon Apr 12 20:09:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02895; Mon, 12 Apr 93 20:09:12 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02888; Mon, 12 Apr 93 13:09:02 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA11802 for ; Mon, 12 Apr 93 15:56:48 -0400 Received: from stimpys.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA13930; Mon, 12 Apr 93 15:43:01 EDT Received: from localhost by stimpys.imsi.com (4.1/SMI-4.1) id AA02408; Mon, 12 Apr 93 15:40:49 EDT Message-Id: <9304121940.AA02408@stimpys.imsi.com> To: firewalls@GreatCircle.COM Subject: Is there Packet Filtering Software for SunOS? Reply-To: rens@imsi.com Cc: rens@stimpys.IMSI.COM Date: Mon, 12 Apr 1993 15:40:48 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi- Does anyone know of any packet filtering software for SunOS, preferably free. I am aware of Dave Mischler's ka9q mods, but I have a sparcstation and no PC to use as a firewall. FTPable would be great, but any commercial solutions would be acceptable as well. Any ideas? -Rens From Firewalls-Owner Mon Apr 12 20:29:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02945; Mon, 12 Apr 93 20:29:54 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02938; Mon, 12 Apr 93 13:29:40 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA24121; Tue, 13 Apr 93 06:30:32 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9304122030.AA24121@coombs.anu.edu.au> Subject: Re: Is there Packet Filtering Software for SunOS? To: rens@imsi.com Date: Tue, 13 Apr 93 6:30:30 EST Cc: firewalls@GreatCircle.COM In-Reply-To: <9304121940.AA02408@stimpys.imsi.com>; from "Rens Troost" at Apr 12, 93 3:40 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In some email I received from Rens Troost, Sie wrote: > > > Hi- > > Does anyone know of any packet filtering software for SunOS, > preferably free. I am aware of Dave Mischler's ka9q mods, but I have a > sparcstation and no PC to use as a firewall. FTPable would be great, > but any commercial solutions would be acceptable as well. > > Any ideas? I'm working on an addition now which should fit into most any kernel that you can get the source to (ie those who have 386BSD - dunno about linux). I should be able to put out the required .o's for SunOS 4.1.2 and diffs for those who have source and want to hook it in. It's not likely docs will get done in a hurry. At the moment I'm working on some utilities you put 'test' packets in and it passes them through a 'pretend' filter to see what it would do. If you can wait about 24 hours or so, I should have something that you can test. I'm not sure how it will stack up against other solutions yet. Darren From Firewalls-Owner Mon Apr 12 21:10:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03204; Mon, 12 Apr 93 21:10:17 GMT Received: from siemens.siemens.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03194; Mon, 12 Apr 93 14:10:06 PDT Received: from yogi.siemens.com by siemens.siemens.com with smtp (Smail3.1.28.1 #22) id m0niVmE-0019LgC; Mon, 12 Apr 93 17:10 EDT Received: by yogi.siemens.com (4.1/SMI-4.1) id AA01321; Mon, 12 Apr 93 17:11:05 EDT Date: Mon, 12 Apr 93 17:11:05 EDT From: map@yogi.siemens.com (Michael Platoff) Message-Id: <9304122111.AA01321@yogi.siemens.com> To: rens@imsi.com Cc: firewalls@GreatCircle.COM In-Reply-To: <9304121940.AA02408@stimpys.imsi.com> Subject: Is there Packet Filtering Software for SunOS? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Rens Troost writes: > > Hi- > > Does anyone know of any packet filtering software for SunOS, > preferably free. I am aware of Dave Mischler's ka9q mods, but I have a > sparcstation and no PC to use as a firewall. FTPable would be great, > but any commercial solutions would be acceptable as well. > > Any ideas? > > -Rens The following came across this mailing list in January: _________________________________________________________________ From: Michael Haberler Sender: Firewalls-Owner@GreatCircle.COM To: firewalls@GreatCircle.COM Cc: fuer@siemens.co.at Subject: IP access list streams module available Date: Tue, 26 Jan 1993 19:06:25 +0100 (MET) Gerhard Fuernkranz of fuer@siemens.co.at has written a SVR4 STREAMS module which implements access lists very nicely. I've not tried it yet but it looks very good. Comes under Gnu GPL. I put it up for anonymous ftp on eunet.co.at:pub/network/ipacl/ipacl.[shar|tar.Z] Mirrors welcome. Michael Haberler -- Michael Haberler mah@eunet.co.at EUnet Austria Ltd A-1010 Vienna, Austria, Schottenring 33 Tel: +43 (1) 346184 fax: +43 (1) 3104462 _________________________________________________________________ Michael Platoff email: map@scr.siemens.com Siemens Corporate Research phone: (609) 734-3354 755 College Road East fax: (609) 734-6565 Princeton, NJ 08540-6668 From Firewalls-Owner Mon Apr 12 23:49:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06389; Mon, 12 Apr 93 23:49:53 GMT Received: from lsr.nei.nih.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06382; Mon, 12 Apr 93 16:49:46 PDT Received: from lsr (lsr-vax.nei.nih.gov) by lsr.nei.nih.gov (4.1/1.35(leaf-1.0)) id AA01764; Mon, 12 Apr 93 19:54:46 EDT Received: from lsr-sund.nei-lsr by lsr (4.1/SMI-4.1) id AA05261; Mon, 12 Apr 93 19:49:57 EDT Date: Mon, 12 Apr 93 19:49:57 EDT From: art@lsr.nei.nih.gov (Art Hays - PSTAFF) Message-Id: <9304122349.AA05261@lsr> To: firewalls@GreatCircle.COM Subject: Performance of PC based filter programs Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can someone give me an idea of how the PC based filtering programs compare in performance to a cisco box? (assume a best case pc- 486/33 with fast ethernet interfaces). Thanks. Art Hays, Nat. Eye Institute, art@lsr.nei.nih.gov Nat. Institutes of Health, Bethesda, MD (301) 496-7143 From Firewalls-Owner Tue Apr 13 14:01:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08456; Tue, 13 Apr 93 14:01:35 GMT Received: from usav01.glaxo.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08445; Tue, 13 Apr 93 07:01:25 PDT Message-Id: <9304131401.AA08445@mycroft.GreatCircle.COM> Date: 13 Apr 93 04:48:00 EST From: "USA::MRGATE::"A1::POSTMASTER"" Subject: Delivery Failure Report To: "Firewalls" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: NAME: Mail Postmaster FUNC: USA TEL: To: WINS%"Firewalls@GreatCircle.COM"@USA@MRGATE ALL-IN-1 was unable to deliver your message dated to HOLT JL - user cannot accept new mail on node USAV02 The subject of the message was : Firewalls Digest V2 #62 From Firewalls-Owner Tue Apr 13 17:39:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09442; Tue, 13 Apr 93 17:39:33 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09434; Tue, 13 Apr 93 10:39:17 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA26671; Wed, 14 Apr 93 03:39:22 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9304131739.AA26671@coombs.anu.edu.au> Subject: Re: Is there Packet Filtering Software for SunOS? To: rens@imsi.com Date: Wed, 14 Apr 93 3:39:19 EST Cc: firewalls@GreatCircle.COM In-Reply-To: <9304122030.AA24121@coombs.anu.edu.au>; from "Darren Reed" at Apr 13, 93 6:30 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In some email I received from Darren Reed, Sie wrote: > > I'm working on an addition now which should fit into most any kernel > that you can get the source to (ie those who have 386BSD - dunno about linux). > I should be able to put out the required .o's for SunOS 4.1.2 and diffs for > those who have source and want to hook it in. Well, you can retrieve what I've managed to do so far from coombs.anu.edu.au:/pub/net/fil.tar.Z It doesn't log packets, I'm not sure how that would/should be done from inside the kernel and would most likely slow things down. The primary purpose of this is for sys admins who don't have ciscos or other nice routers to setup but would like more control over what goes in and out of their subnets. The docs are pretty much sparse (not even man page skeletons yet). In writing this, I've tried to use the papers from Brent Chapman and Jeff Mogul in building something 'friendly' and useful. The only thing it doesn't handle which makes me quesy is fragmented packets. Other than that, it should do most of the things which are commonly done. I'm not sure when or if I'll get more comprehensive docs done, its mainly a hack to provide some SS2's which act as gateways some control and security over their subnets. The ip_input.o and route.o files were built on a sun4c if that matters any and are for 4.1.x (not sure about 4.1.3 though). Darren From Firewalls-Owner Wed Apr 14 08:57:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12711; Wed, 14 Apr 93 08:57:35 GMT Received: from usav01.glaxo.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12704; Wed, 14 Apr 93 01:57:13 PDT Message-Id: <9304140857.AA12704@mycroft.GreatCircle.COM> Date: 14 Apr 93 04:43:00 EST From: "USA::MRGATE::"A1::POSTMASTER"" Subject: Delivery Failure Report To: "Firewalls" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: NAME: Mail Postmaster FUNC: USA TEL: To: WINS%"Firewalls@GreatCircle.COM"@USA@MRGATE ALL-IN-1 was unable to deliver your message dated to HOLT JL - user cannot accept new mail on node USAV02 The subject of the message was : Firewalls Digest V2 #63 From Firewalls-Owner Thu Apr 15 01:49:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14704; Thu, 15 Apr 93 01:49:50 GMT Received: from alpha.xerox.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14697; Wed, 14 Apr 93 18:49:32 PDT Received: from vertigo.parc.xerox.com ([13.1.136.17]) by alpha.xerox.com with SMTP id <11931>; Wed, 14 Apr 1993 18:49:31 PDT Received: from 13.1.248.3 ([13.1.248.3]) by vertigo.parc.xerox.com with SMTP id <66627>; Wed, 14 Apr 1993 18:49:19 -0700 Date: Wed, 14 Apr 1993 19:52:36 PDT To: firewalls@GreatCircle.COM From: John Larson X-Sender: jlarson@vertigo.parc.xerox.com Subject: Internally initiated outbound X traffic Cc: JLarson@parc.xerox.com Message-Id: <93Apr14.184919pdt.66627@vertigo.parc.xerox.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A question has come up here whether there are any known security problems with allowing internally initiated X windows traffic to an external machine (ie. pop up an X-window tool on external machine). Are there any known security problems with allowing X in the outbound direction ? Thanks, John Larson Xerox PARC From Firewalls-Owner Thu Apr 15 03:15:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14820; Thu, 15 Apr 93 03:15:57 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14813; Wed, 14 Apr 93 20:15:47 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA25545; Wed, 14 Apr 93 23:17:19 EDT Date: Wed, 14 Apr 93 23:17:19 EDT From: Marcus J Ranum Message-Id: <9304150317.AA25545@TIS.COM> To: firewalls@GreatCircle.COM, jlarson@parc.xerox.com Subject: Re: Internally initiated outbound X traffic Cc: JLarson@parc.xerox.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Are there any known security problems with allowing X in the outbound >direction ? Yes. With X you can basically kiss security goodbye unless you run it over a channel with point-to-point crypto. mjr. From Firewalls-Owner Thu Apr 15 06:17:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15246; Thu, 15 Apr 93 06:17:51 GMT Received: from motgate.mot.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15239; Wed, 14 Apr 93 23:17:41 PDT Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.13 for ) id AA20684; Thu, 15 Apr 1993 01:17:49 -0500 Received: from next3.corp.mot.com (next3.corp.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.12) id AA20248; Thu, 15 Apr 1993 01:17:47 -0500 Received: from secjjk.corp.mot.com by next3.corp.mot.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA23797; Thu, 15 Apr 93 01:15:53 CDT From: kinyon@next3.corp.mot.com (John J. Kinyon) Message-Id: <9304150615.AA23797@ next3.corp.mot.com > Received: by secjjk.corp.mot.com (NX5.67c/NX3.0X) id AA04684; Thu, 15 Apr 93 01:15:52 -0500 Subject: Re: Internally initiated outbound X traffic To: mjr@tis.com (Marcus J Ranum) Date: Thu, 15 Apr 1993 01:15:51 -0500 (CDT) Cc: firewalls@GreatCircle.COM, jlarson@parc.xerox.com In-Reply-To: <9304150317.AA25545@TIS.COM> from "Marcus J Ranum" at Apr 14, 93 11:17:19 pm X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 508 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >Are there any known security problems with allowing X in the outbound > >direction ? > > Yes. With X you can basically kiss security goodbye unless you > run it over a channel with point-to-point crypto. > > mjr. > Don't mince words, Bones. Say what you really think! (I happen to agree. Crypto and authentication.) _JJK -- John Kinyon, Manager, Network Security, Motorola, IL06-S2022 1299 East Algonquin Road, Schaumburg, IL 60196-1077, USA Internet: kinyon@corp.mot.com (NeXTmail accepted) From Firewalls-Owner Thu Apr 15 13:08:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16066; Thu, 15 Apr 93 13:08:54 GMT Received: from eticket.llnl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16059; Thu, 15 Apr 93 06:08:47 PDT Received: by eticket.llnl.gov (4.1/LLNL-1.18) id AA22620; Thu, 15 Apr 93 06:09:17 PDT Date: Thu, 15 Apr 93 06:09:17 PDT From: tmd@eticket.llnl.gov (Tina M. Darmohray) Message-Id: <9304151309.AA22620@eticket.llnl.gov> To: mjr@tis.com Subject: Re: Internally initiated outbound X traffic Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Marcus, We've argued the X issue forever at our site. My contention was that the X "server" was on the "wrong" side of the firewall to be an OK thing to let pass. -- You seem to agree about X, but I'd be interested in hearing your reasons for it. Tina From Firewalls-Owner Thu Apr 15 13:35:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16164; Thu, 15 Apr 93 13:35:00 GMT Received: from eticket.llnl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16157; Thu, 15 Apr 93 06:34:52 PDT Received: by eticket.llnl.gov (4.1/LLNL-1.18) id AA22665; Thu, 15 Apr 93 06:35:23 PDT Date: Thu, 15 Apr 93 06:35:23 PDT From: tmd@eticket.llnl.gov (Tina M. Darmohray) Message-Id: <9304151335.AA22665@eticket.llnl.gov> To: tmd@eticket.llnl.gov Subject: Re: Internally initiated outbound X traffic Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk That's the one that I've been going on, and it's been enough so far. Thanks! Tina From Firewalls-Owner Thu Apr 15 15:01:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16285; Thu, 15 Apr 93 15:01:09 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16278; Thu, 15 Apr 93 08:01:01 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA14703; Thu, 15 Apr 93 11:02:24 EDT Date: Thu, 15 Apr 93 11:02:24 EDT From: Marcus J Ranum Message-Id: <9304151502.AA14703@TIS.COM> To: firewalls@GreatCircle.COM Subject: X and firewalls and whatnot - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I realize my initial response on the X question was a bit terse and not terribly informative. Considering the presence of tools like xkeys on the net, I can't imagine why anyone would trust X without some kind of reasonably strong protection wrapped around the communications channel. MIT magic cookie is not really adequate - but it takes a step in the right direction. It's a shame the folks who designed X didn't give this stuff any thought when they initially wrote the protocol - a few simple tricks could have rendered it very secure indeed. Using a cryptographic sequence number in each operation, with the ability to turn it off if you knew you were over a safe link, rather than no security at all, always, as the default... Eeesh. I believe there's hope. There's interesting work being done by folks in the IETF IP security working groups, and we may see a version of real security and authenticated connections for IP in the not too terribly distant future. Doubtless it'll take a while to spread to the world at large, but it's got interesting ramifications for firewalls. With link encryption and cryptographic authentication for your TCP connections, suddenly firewalls become almost a moot point. Simply replace all firewalls with a generic host with TCP forwarders for all authenticated TCP connections, and you're done. I believe this kind of work, rather than continuing to kludge away at an application level, is the way to solve the problem for once and for all. Mind you, I'm as guilty as the next guy as far as trying to kludge around making applications work, but that's just because it's nice to have something usable *today*. mjr. From Firewalls-Owner Thu Apr 15 15:21:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16325; Thu, 15 Apr 93 15:21:01 GMT Received: from cray.com (timbuk.cray.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16318; Thu, 15 Apr 93 08:20:54 PDT Received: from matrix.cray.com by cray.com (4.1/CRI-MX 2.17) id AA27744; Thu, 15 Apr 93 10:21:43 CDT Received: by matrix.cray.com id AA24972; 4.1/CRI-5.6a; Thu, 15 Apr 93 10:21:42 CDT From: btk@matrix.cray.com (Bryan Koch) Message-Id: <9304151521.AA24972@matrix.cray.com> Subject: re: Internally initiated outbound X traffic To: firewalls@GreatCircle.COM Date: Thu, 15 Apr 93 10:21:39 CDT X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > A question has come up here whether there are any known security problems > with allowing internally initiated X windows traffic to an external machine > (ie. pop up an X-window tool on external machine). > > Are there any known security problems with allowing X in the outbound > direction ? Connections from internal X clients to external X servers can lead to a total bypass of packet-filter-based security policies. This has actually happened here, in at least two cases that I am aware of. It is, unfortunately, very easy to do. Consider the combination of "xterm", DISPLAY set to an external host, and a mail filter. Bryan Koch Data Security Leader VOICE: +1-612-683-3129 Cray Research, Inc. FAX: +1-612-683-3099 Eagan, Minnesota, USA EMAIL: btk@cray.com From Firewalls-Owner Thu Apr 15 16:00:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16416; Thu, 15 Apr 93 16:00:24 GMT Received: from leigh.s1.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16409; Thu, 15 Apr 93 09:00:17 PDT Received: from ducati.s1.gov ([128.15.16.60]) by leigh.s1.gov (4.1/TMD1.4) id AA22531; Thu, 15 Apr 93 09:00:59 PDT From: dave@s1.gov (Dave Wright) Received: by ducati.s1.gov (4.1/TMD1.5) id AA01960; Thu, 15 Apr 93 09:00:55 PDT Message-Id: <9304151600.AA01960@ducati.s1.gov> Subject: Re: Internally initiated outbound X traffic To: btk@matrix.cray.com (Bryan Koch) Date: Thu, 15 Apr 93 9:00:55 PDT Cc: firewalls@GreatCircle.COM In-Reply-To: <9304151521.AA24972@matrix.cray.com>; from "Bryan Koch" at Apr 15, 93 10:21:39 am X-Mailer: ELM [version 2.4dev PL32] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > A question has come up here whether there are any known security problems > > with allowing internally initiated X windows traffic to an external machine > > (ie. pop up an X-window tool on external machine). > > > > Are there any known security problems with allowing X in the outbound > > direction ? > > Connections from internal X clients to external X servers can lead to a > total bypass of packet-filter-based security policies. This has actually > happened here, in at least two cases that I am aware of. It is, > unfortunately, very easy to do. Consider the combination of "xterm", > DISPLAY set to an external host, and a mail filter. > > Bryan Koch > Data Security Leader VOICE: +1-612-683-3129 > Cray Research, Inc. FAX: +1-612-683-3099 > Eagan, Minnesota, USA EMAIL: btk@cray.com > There are also a very simple tool available to watch this. xscope Even with xscope you could set the DIPLAY to be a trused host but have the client disply somewhere else. ________ o Dave Wright _______ _/\_> dave@s1.gov _______O=>// O 91CBR1000F -------------- AMA#680445 HSTA#4592 DoD#0568 From Firewalls-Owner Thu Apr 15 16:07:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16434; Thu, 15 Apr 93 16:07:28 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16427; Thu, 15 Apr 93 09:07:16 PDT Received: from shuldig.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA11723 (5.65b/HUJI 4.114); Thu, 15 Apr 93 19:09:56 +0300 Received: from localhost by shuldig.cs.huji.ac.il with SMTP id AA13647 (5.65c/HUJI 4.1 for firewalls@greatcircle.com); Thu, 15 Apr 1993 19:09:56 +0300 Message-Id: <199304151609.AA13647@shuldig.cs.huji.ac.il> To: firewalls@GreatCircle.COM Subject: Re: Internally initiated outbound X traffic In-Reply-To: Your message of Thu, 15 Apr 93 10:21:39 CDT . <9304151521.AA24972@matrix.cray.com> From: Amos Shapira Date: Thu, 15 Apr 1993 19:09:49 +0300 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk btk@matrix.cray.com (Bryan Koch) writes: |> A question has come up here whether there are any known security problems |> with allowing internally initiated X windows traffic to an external machine |> (ie. pop up an X-window tool on external machine). |> |> Are there any known security problems with allowing X in the outbound |> direction ? | |Connections from internal X clients to external X servers can lead to a |total bypass of packet-filter-based security policies. This has actually |happened here, in at least two cases that I am aware of. It is, |unfortunately, very easy to do. Consider the combination of "xterm", |DISPLAY set to an external host, and a mail filter. Again, I didn't understand why is X to outside was such a terrible idea until I read this last sentence: it seems like those who replied "yes" are also concerned about info leaking to the outside world, while I, as a university, don't worry about such things. So I think some sort of distinguishing between these "levels" (?) of security is needed. Please correct me if I'm wrong. Cheers, |Bryan Koch |Data Security Leader VOICE: +1-612-683-3129 |Cray Research, Inc. FAX: +1-612-683-3099 |Eagan, Minnesota, USA EMAIL: btk@cray.com --Amos --Amos Shapira (Jumper Extraordinaire) | "It is true that power corrupts, C.S. System Group, Hebrew University, | but absolute power is better!" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- the Demon to his son From Firewalls-Owner Thu Apr 15 17:30:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16812; Thu, 15 Apr 93 17:30:26 GMT Received: from cray.com (timbuk.cray.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16803; Thu, 15 Apr 93 10:30:16 PDT Received: from matrix.cray.com by cray.com (4.1/CRI-MX 2.17) id AA07944; Thu, 15 Apr 93 12:31:06 CDT Received: by matrix.cray.com id AA02684; 4.1/CRI-5.6a; Thu, 15 Apr 93 12:31:04 CDT From: btk@matrix.cray.com (Bryan Koch) Message-Id: <9304151731.AA02684@matrix.cray.com> Subject: Re: X traffic, academic environments To: amoss@cs.huji.ac.il (Amos Shapira) Date: Thu, 15 Apr 93 12:31:01 CDT Cc: firewalls@GreatCircle.COM In-Reply-To: <199304151609.AA13647@shuldig.cs.huji.ac.il>; from "Amos Shapira" at Apr 15, 93 7:09 pm X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > |Connections from internal X clients to external X servers can lead to a > |total bypass of packet-filter-based security policies. This has actually > |happened here, in at least two cases that I am aware of. It is, > |unfortunately, very easy to do. Consider the combination of "xterm", > |DISPLAY set to an external host, and a mail filter. > > Again, I didn't understand why is X to outside was such a terrible idea until > I read this last sentence: it seems like those who replied "yes" are also > concerned about info leaking to the outside world, while I, as a university, > don't worry about such things. So I think some sort of distinguishing between > these "levels" (?) of security is needed. > > Please correct me if I'm wrong. To be meaningful, academic freedom implies not only the imperative to publish, but also the responsiblity to decide when and in what form to do so. If the information being leaked to the outside world is a not-ready-for-publication copy of research results, this could cause harm to a researcher's reputation. I am often surprised to find that members of academic communities assume that security is contradictory to their mission. Security mechanisms and concerns are one way of supporting the concepts of "privacy" and "choice", and surely there is a place for these in the academic world. Bryan Koch From Firewalls-Owner Thu Apr 15 17:49:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16905; Thu, 15 Apr 93 17:49:27 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16897; Thu, 15 Apr 93 10:49:12 PDT Received: from shuldig.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA12663 (5.65b/HUJI 4.114); Thu, 15 Apr 93 20:52:01 +0300 Received: from localhost by shuldig.cs.huji.ac.il with SMTP id AA15000 (5.65c/HUJI 4.1 for firewalls@greatcircle.com); Thu, 15 Apr 1993 20:52:10 +0300 Message-Id: <199304151752.AA15000@shuldig.cs.huji.ac.il> To: firewalls@GreatCircle.COM Subject: Re: X traffic, academic environments In-Reply-To: Your message of Thu, 15 Apr 93 12:31:01 CDT . <9304151731.AA02684@matrix.cray.com> From: Amos Shapira Date: Thu, 15 Apr 1993 20:52:00 +0300 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk btk@matrix.cray.com (Bryan Koch) writes: |To be meaningful, academic freedom implies not only the imperative to |publish, but also the responsiblity to decide when and in what form to |do so. If the information being leaked to the outside world is a |not-ready-for-publication copy of research results, this could cause |harm to a researcher's reputation. | |I am often surprised to find that members of academic communities |assume that security is contradictory to their mission. Security |mechanisms and concerns are one way of supporting the concepts of |"privacy" and "choice", and surely there is a place for these in |the academic world. I also find myself questioning the wisdom in letting our files get out even just because it is so easy to extract our users database once someone is logged in, I think we are quite in agreement about that. The point is that money is not involved, so the university itself doesn't have a big interest (at least compared to most commercial companies) to hide its data. And we do (or can) provide our researchers with tools to hide their data if they wish to do so, we even erect stricter firewalls around labs of proffesors which are more concerned about security than others. But the tradeoff is *convenience*, our users regard the firewall telnet daemon I've just writen to be a real nuisance, they don't CARE so much about it. OK, so you could say that we, as system admins, should make them aware of that, but they are still not interested, in fact they regard the fact that in order to ftp files from inside out (when they are abroad) they have to telnet inside first as a real nuisance. I'm just providing services, and noone asked me to provide more adequate security than I allready give, actually they would have preffered to do without it. (and just to make clear, I'm not a policy maker, just a programmer, my boss makes policies). I suspect that all (or most) of the people on this mailing list are tiered of these 'political'(?) discussions, so I would preffer to get off this subject, unless a third party will express interest, ok? | |Bryan Koch | Cheers, --Amos --Amos Shapira (Jumper Extraordinaire) | "It is true that power corrupts, C.S. System Group, Hebrew University, | but absolute power is better!" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- the Demon to his son From Firewalls-Owner Thu Apr 15 18:21:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17027; Thu, 15 Apr 93 18:21:08 GMT Received: from cray.com (timbuk.cray.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17019; Thu, 15 Apr 93 11:20:55 PDT Received: from matrix.cray.com by cray.com (4.1/CRI-MX 2.17) id AA11439; Thu, 15 Apr 93 13:21:41 CDT Received: by matrix.cray.com id AA06999; 4.1/CRI-5.6a; Thu, 15 Apr 93 13:21:38 CDT From: btk@matrix.cray.com (Bryan Koch) Message-Id: <9304151821.AA06999@matrix.cray.com> Subject: Re: Internally initiated outbound X traffic To: dave@s1.gov (Dave Wright) Date: Thu, 15 Apr 93 13:21:37 CDT Cc: firewalls@GreatCircle.COM In-Reply-To: <9304151600.AA01960@ducati.s1.gov>; from "Dave Wright" at Apr 15, 93 9:00 am X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Connections from internal X clients to external X servers can lead to a > > total bypass of packet-filter-based security policies. This has actually > > happened here, in at least two cases that I am aware of. It is, > > unfortunately, very easy to do. Consider the combination of "xterm", > > DISPLAY set to an external host, and a mail filter. > > > There are also a very simple tool available to watch this. > > xscope > > Even with xscope you could set the DIPLAY to be a trused host but have > the client disply somewhere else. I wasn't aware of xscope until your message. At least in its released version, it doesn't address the problem I'm faced with which is that trusted internal users are using their access priviledges to bypass our firewall's authentication system. As released, xscope must be attached to the (external) X-server, and the internal user must cooperate by connecting to xscope instead of the X-server server. Bryan Koch From Firewalls-Owner Thu Apr 15 18:32:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17129; Thu, 15 Apr 93 18:32:27 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17122; Thu, 15 Apr 93 11:32:18 PDT Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18407; Thu, 15 Apr 93 14:33:09 -0400 Received: from srg.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 135640.20232; Thu, 15 Apr 1993 13:56:40 EDT Received: from rams.srg.af.mil by srg.srg.af.mil id aa06799; Thu, 15 Apr 93 13:44:10 EDT From: Bob Reinhardt Reply-To: Bob Reinhardt Date: Thu Apr 15 13:37:34 1993 Subject: Is there an FTP client that logs activity? To: firewalls@GreatCircle.COM Cc: breinhar@srg.af.mil Message-Id: <9304151337.aa20679@rams.srg.af.mil> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Question says it all (almost). Is there an ftp client that can replace the one that comes from SCO for SCO ODT 1.1/2.0 that will log the file transfers that people do? The aim obviously is to keep tracking of files that are brought into the local network from the outside. This is in addition to manually screening code and virus checking binaries. Either post to the list or e-mail me at "breinhar%srg@UUNET.UU.NET" Thanks, Bob From Firewalls-Owner Thu Apr 15 19:29:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17361; Thu, 15 Apr 93 19:29:34 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17354; Thu, 15 Apr 93 12:29:28 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA03683; Thu, 15 Apr 93 15:31:06 EDT Date: Thu, 15 Apr 93 15:31:06 EDT From: Marcus J Ranum Message-Id: <9304151931.AA03683@TIS.COM> To: breinhar@srg.srg.af.mil, firewalls@GreatCircle.COM Subject: Re: Is there an FTP client that logs activity? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Is there an ftp client that can replace the one that >comes from SCO for SCO ODT 1.1/2.0 that will log >the file transfers that people do? The one on gatekeeper.dec.com in pub/DEC does so, I believe. It logs the GET/PUT commands users issue. >The aim obviously is to keep tracking of files that >are brought into the local network from the outside. >This is in addition to manually screening code and >virus checking binaries. The problem is that if I can FTP from the net, I can FTP the sources for a client FTP and use my own, which does no logging. This problem you're dealing with is why I designed the FTP applications gateway DEC (and its SEAL customers) use - the only way to *really* know that you're getting an accurate picture of what is going in or out via FTP is to interpose a block and have an application gateway that logs traffic. The DEC FTP gateway also lets the firewall manager select what to log, and gives the ability to block certain commands directionally, depending on who is talking to whom. Virii are a whole 'nother, very, very tricky issue. With all the zillions of ASCII encodings of binaries and with the ability to Email stuff, it's almost impossible to prevent people from bringing in virii, other than through educating them. mjr. From Firewalls-Owner Thu Apr 15 19:41:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17402; Thu, 15 Apr 93 19:41:31 GMT Received: from uu6.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17395; Thu, 15 Apr 93 12:41:15 PDT Received: from jupiter.fuentez.com by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA07615 for firewalls@greatcircle.com; Thu, 15 Apr 93 15:41:33 -0400 Received: from localhost by fuentez.com (4.1/FSC-1.2) id AA02296; Thu, 15 Apr 93 15:39:34 EDT Message-Id: <9304151939.AA02296@fuentez.com> To: firewalls@GreatCircle.COM Subject: Re: X traffic, academic environments In-Reply-To: Message from btk@matrix.cray.com (Bryan Koch) of "Thu, 15 Apr 1993 12:31:01 -0500" <9304151731.AA02684@matrix.cray.com> Date: Thu, 15 Apr 1993 15:39:31 -0400 From: Mike Robitaille Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > To be meaningful, academic freedom implies not only the imperative to > publish, but also the responsiblity to decide when and in what form to > do so. If the information being leaked to the outside world is a > not-ready-for-publication copy of research results, this could cause > harm to a researcher's reputation. > > I am often surprised to find that members of academic communities > assume that security is contradictory to their mission. Security > mechanisms and concerns are one way of supporting the concepts of > "privacy" and "choice", and surely there is a place for these in > the academic world. > > Bryan Koch > Amen! I'm starting to get the opinion that those people that don't feel they need privacy types of computer security protection are those folks that haven't been burned yet... ---------- Michael A. Robitaille Fuentez Systems Concepts, Inc. miker@fuentez.com 11781 Lee Jackson Highway Voice: +1 (703) 273-1447 Fairfax, VA 22033 USA Fax: +1 (703) 273-2972 From Firewalls-Owner Thu Apr 15 20:05:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17443; Thu, 15 Apr 93 20:05:33 GMT Received: from erenj.com (ereapp.erenj.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17436; Thu, 15 Apr 93 13:05:21 PDT Received: by erenj.com (5.65/mjr-920806); id AA08179; Thu, 15 Apr 93 16:06:06 -0400 Received: by eredns.erenj.com (5.65/bdb-mailv1.2-erenj-gw); id AA10293; Thu, 15 Apr 93 16:06:05 -0400 Received: by maverick1.erenj.com (5.57/bdb-mailv1.0); id AA09416; Thu, 15 Apr 93 16:06:04 -0400 Posted-Date: Thu, 15 Apr 1993 16:06:03 -0400 From: bdboyle@maverick1.erenj.com (Bryan D. Boyle) Message-Id: <9304151606.ZM9414@maverick1.erenj.com> Date: Thu, 15 Apr 1993 16:06:03 -0400 In-Reply-To: Marcus J Ranum "Re: Is there an FTP client that logs activity?" (Apr 15, 3:31pm) References: <9304151931.AA03683@TIS.COM> X-Mailer: Z-Mail (2.1.0 10/1/92) To: Marcus J Ranum Subject: Re: Is there an FTP client that logs activity? Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Apr 15, 3:31pm, Marcus J Ranum wrote: > Subject: Re: Is there an FTP client that logs activity? > >Is there an ftp client that can replace the one that > >comes from SCO for SCO ODT 1.1/2.0 that will log > >the file transfers that people do? > > The one on gatekeeper.dec.com in pub/DEC does so, I believe. It > logs the GET/PUT commands users issue. > > >The aim obviously is to keep tracking of files that > >are brought into the local network from the outside. > >This is in addition to manually screening code and > >virus checking binaries. > > The problem is that if I can FTP from the net, I can FTP the > sources for a client FTP and use my own, which does no logging. > > This problem you're dealing with is why I designed the FTP > applications gateway DEC (and its SEAL customers) use - the only way > to *really* know that you're getting an accurate picture of what is > going in or out via FTP is to interpose a block and have an application > gateway that logs traffic. The DEC FTP gateway also lets the firewall > manager select what to log, and gives the ability to block certain > commands directionally, depending on who is talking to whom. > > Virii are a whole 'nother, very, very tricky issue. With all > the zillions of ASCII encodings of binaries and with the ability to > Email stuff, it's almost impossible to prevent people from bringing > in virii, other than through educating them. > > mjr. >-- End of excerpt from Marcus J Ranum I have always found that (and I am using DEC's SEAL, and no, they are not paying me to say this...) education (and a little economic persuasion, ie you need permission from a senior manager to use the ftp facility, and if _your_ efforts cause the infection of the net, then your cost center gets charged for the cleanup...) tend to keep the noise level and problems down. I am pleased with the level of logging (down to the userid, target host, cd, get, put, bin, etc. level) that this product provides. Even tracks the # bytes across the firewall... Or (sorry, marcus, I couldn't resist...:-)) as a Japanese strategist once stated: "In large scale strategy, when the enemy embarks on an attack, if you make a show of strongly suppressing his technique, he will change his mind...--Miyamoto Musashi" -- Bryan D. Boyle <>< |Physical: Exxon Research, Annandale, NJ 08801 #include |Logical: bdboyle@erenj.com < USENET: Post to exotic, distant machines. Meet exciting, > < unusual people. And flame them. > From Firewalls-Owner Thu Apr 15 20:24:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17489; Thu, 15 Apr 93 20:24:14 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17482; Thu, 15 Apr 93 13:24:05 PDT Message-Id: <9304152024.AA17482@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu Apr 15 16:20:29 EDT 1993 To: John Larson Cc: firewalls@GreatCircle.COM Subject: Re: Internally initiated outbound X traffic Date: Thu, 15 Apr 93 16:20:28 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A question has come up here whether there are any known security problems with allowing internally initiated X windows traffic to an external machine (ie. pop up an X-window tool on external machine). Are there any known security problems with allowing X in the outbound direction ? As always, yes and no... The answer depends on your security policy. If you feel a strong need to monitor outbound traffic (i.e., if you're the sort of site that configures DEC's SEAL with its paranoid ftp client), then you should not permit that sort of call. I don't feel that way, mostly because of the existence of 2 gigabyte 8mm tapes, but I know that others either don't agree with me, or have bosses that don't. If you have people using open doors in your packet filters to evade or ignore company security guidelines, what you have is a people problem, not a technical problem. The same goes double for folks who like to set up IP tunnels. Other than that, the major risk you're taking is folks doing evil things to the X terminal. The usual example is xkeys or the like. But that's a problem if you permit any sort of inbound call at all from such terminals. If I'm spying on your X session, I can do that whether you run xterm from the inside out, or telnet from the outside in, even through a checkpoint (we require use of hand-held authenticators for call-in). I've been told -- and I'm not an Xpert, for which I regularly thank various deities -- that there is increased risk if people choose to run their window manager on the secure side of a firewall. Most folks won't, for performance reasons, but... The danger, apparently, is that an attacker who can connect to the X terminal can send all sorts of interesting messages to the window manager, and fire up all manner of interesting programs that are homed on invisible windows. That's *far* worse than simply spying on a telnet session. (N.B. by default, xterm will ignore synthetic events, which makes it harder to take over such a session.) --Steve Bellovin From Firewalls-Owner Thu Apr 15 23:53:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18356; Thu, 15 Apr 93 23:53:09 GMT Received: from ADDVAX.LLNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18349; Thu, 15 Apr 93 16:53:02 PDT Received: from addvax.llnl.gov by addvax.llnl.gov (PMDF #12441) id <01GX1PPUSRK0000B1R@addvax.llnl.gov>; Thu, 15 Apr 1993 16:53 PST Date: Thu, 15 Apr 1993 16:53 PST From: "R.L.Palasek (510)422-8527" Subject: Re: Firewalls Digest V2 #64 To: Firewalls@GreatCircle.COM Message-Id: <01GX1PPUSRK0000B1R@addvax.llnl.gov> X-Envelope-To: Firewalls@greatcircle.COM X-Vms-To: IN%"Firewalls@greatcircle.COM" X-Vms-Cc: PALASEK Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Re: Re: Internally initiated outbound X traffic >>Are there any known security problems with allowing X in the outbound >>direction ? > > Yes. With X you can basically kiss security goodbye unless you >run it over a channel with point-to-point crypto. Is that security on the initiator, the recipient, or both? Is it an impersonation problem? Loss of service? or what? Is there any way in which it differs from other network security problems? Can we consider a weaker security that is not total security? I get the impression that the original question was to distinguish outbound and inbound security. What if I don't care about confidentiality; do I still have some sense of integrity? If client A on workstation A opens a window on server B on workstation B, does the adversary impersonate either of these agents at will? Is this a network problem or an X-Windows problem? Bob Palasek Software Applications Developer From Firewalls-Owner Fri Apr 16 13:15:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20083; Fri, 16 Apr 93 13:15:04 GMT Received: from mwunix.mitre.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20073; Fri, 16 Apr 93 06:14:38 PDT Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA12675; Fri, 16 Apr 93 09:15:06 -0400 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA19986; Fri, 16 Apr 93 09:14:25 EDT Message-Id: <9304161314.AA19986@smiley.mitre.org.sit> Date: Fri, 16 Apr 1993 09:15:26 -0500 To: Firewalls@GreatCircle.COM From: shirey@mitre.org (Robert W. Shirey) X-Sender: shirey@smiley.mitre.org Subject: ISOC Symposium on Network and Distributed System Security Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security 3-4 February 1994, Catamaran Hotel, San Diego, California The symposium will bring together people who are building software and hardware to provide network or distributed system security services. The symposium is intended for those interested in practical aspects of network and distributed system security, rather than in theory. Symposium proceedings will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: * Design and implementation of services--access control, authentication, availability, confidentiality, integrity, and non-repudiation --including criteria for placing services at particular protocol layers. * Design and implementation of security mechanisms and support services--encipherment and key management systems, authorization and audit systems, and intrusion detection systems. * Requirements and architectures for distributed applications and network functions--message handling, file transport, remote file access, directories, time synchronization, interactive sessions, remote data base management and access, routing, voice and video multicast and conferencing, news groups, network management, boot services, mobile computing, and remote I/O. * Special issues and problems in security architecture, such as -- very large systems like the international Internet, and -- high-speed systems like the gigabit testbeds now being built. * Interplay between security goals and other goals--efficiency, reliability, interoperability, resource sharing, and low cost. GENERAL CHAIR: Dan Nessett, Lawrence Livermore National Laboratory PROGRAM CHAIRS: Russ Housley, Xerox Special Information Systems Rob Shirey, The MITRE Corporation PROGRAM COMMITTEE: Dave Balenson, Trusted Information Systems Tom Berson, Anagram Laboratories Matt Bishop, Dartmouth College Ed Cain, U.S. Defense Information Systems Agency Jim Ellis, CERT Coordination Center Steve Kent, Bolt, Beranek and Newman John Linn, Independent Consultant Clifford Neuman, Information Sciences Institute Michael Roe, Cambridge University Rob Rosenthal, U.S. National Institute of Standards and Technology Jeff Schiller, Massachusetts Institute of Technology Ravi Sandhu, George Mason University Peter Yee, U.S. National Aeronautics and Space Administration SUBMISSIONS: The committee seeks both original technical papers and proposals for panel discussions on technical and other topics of general interest. Technical papers should be 10-20 pages in length. Panels should include three or four speakers. A panel proposal must name the panel chair, include a one-page topic introduction authored by the chair, and also include one-page position summaries authored by each speaker Both the technical papers and the panel papers will appear in the proceedings. Submissions must be made by 16 August 1993. Submissions should be made via electronic mail to 1994symposium@smiley.mitre.org. Submissions may be in either of two formats: ASCII or PostScript. If the committee is unable to read a PostScript submission, it will be returned and ASCII requested. Therefore, PostScript submissions should arrive well before 16 August. If electronic submission is absolutely impossible, submissions should be sent via postal mail to Robert W. Shirey, Mail Stop Z202 The MITRE Corporation McLean, Virginia 22102-3481 USA All submissions must include both an Internet electronic mail address and a postal address. Each submission will be acknowledged through the medium by which it is received. If acknowledgment is not received within seven days, please contact either Rob Shirey or Russ Housley , or telephone Mana Weigand at MITRE in Mclean, 703-883-5397. Authors and panelists will be notified of acceptance by 15 October 1993. Instructions for preparing camera-ready copy for the proceedings will be postal mailed at that time. The camera-ready copy must be received by 15 November 1993. From Firewalls-Owner Sun Apr 18 15:37:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28413; Sun, 18 Apr 93 15:37:30 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28406; Sun, 18 Apr 93 08:37:19 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA14393; Mon, 19 Apr 93 01:38:04 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9304181538.AA14393@coombs.anu.edu.au> Subject: DNS over TCP To: firewalls@GreatCircle.COM (Firewall Mailing List) Date: Mon, 19 Apr 93 1:38:03 EST Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk People have said that they block all UDP packets bar those from and to port 53 (the port assigned to DNS and used by nameservers). Isn't there some motivation here to try to get a universal block on UDP and move the DNS requests to be handled by TCP connects ? BIND 4.8.3 supports it (RES_USEVC in resolv.h) and it is assigned: domain 53/tcp nameserver # name-domain server domain 53/udp nameserver so why not ? Are DNS transactions light weight enough to make requiring TCP an overkill ? What if the TCP connection were kept open during the life of the namesrver rather than on a per-request basis ? Darren From Firewalls-Owner Sun Apr 18 16:12:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28459; Sun, 18 Apr 93 16:12:41 GMT Received: from grasp1.univ-lyon1.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28452; Sun, 18 Apr 93 09:12:29 PDT Received: by grasp1.univ-lyon1.fr (5.67a8/IDA-1.5f) via Rocad id AA02530; Sun, 18 Apr 1993 18:13:03 +0200 From: Christophe Wolfhugel Message-Id: <199304181613.AA02530@grasp1.univ-lyon1.fr> Subject: Re: DNS over TCP To: avalon@coombs.anu.edu.au Date: Sun, 18 Apr 1993 18:13:01 +0100 (MEST) Cc: firewalls@GreatCircle.COM In-Reply-To: <9304181538.AA14393@coombs.anu.edu.au> from "Darren Reed" at Apr 19, 93 01:38:03 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 599 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Darren Reed said: |so why not ? Are DNS transactions light weight enough to make requiring |TCP an overkill ? What if the TCP connection were kept open during the |life of the namesrver rather than on a per-request basis ? TCP connections are a pain for the DNS. IBM's stupid netstat uses one such... I just can't imagine all the datagrams and time wasted in TCP handshaking particularly true on slow lines ! Keeping TCP sockets open ? I can't imagine to have 200 open just for the pleasure. Keep it on UDP ! -- Christophe Wolfhugel | Email: Christophe.Wolfhugel@grasp.insa-lyon.fr From Firewalls-Owner Sun Apr 18 16:38:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28501; Sun, 18 Apr 93 16:38:58 GMT Received: from sayshell.umd.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28494; Sun, 18 Apr 93 09:38:51 PDT Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0) id AA05598; Sun, 18 Apr 93 12:39:29 -0400 Message-Id: <9304181639.AA05598@sayshell.umd.edu> To: avalon@coombs.anu.edu.au Cc: firewalls@GreatCircle.COM (Firewall Mailing List) From: "Louis A. Mamakos" Subject: Re: DNS over TCP In-Reply-To: Your message of "Mon, 19 Apr 1993 01:38:03 EST." <9304181538.AA14393@coombs.anu.edu.au> Date: Sun, 18 Apr 1993 12:39:29 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > People have said that they block all UDP packets bar those from and to > port 53 (the port assigned to DNS and used by nameservers). > > Isn't there some motivation here to try to get a universal block on UDP > and move the DNS requests to be handled by TCP connects ? BIND 4.8.3 > supports it (RES_USEVC in resolv.h) and it is assigned: What about other UDP based services, like NTP (Network Time Protocol)? It seems that disabling a complete class of network transport is a bit of overkill. > so why not ? Are DNS transactions light weight enough to make requiring > TCP an overkill ? What if the TCP connection were kept open during the > life of the namesrver rather than on a per-request basis ? > It would greatly increase the amount of traffic and time to perform a simple query, as well as increase the resource useage on both the "client" machine and the name server. It is impractical to just keep a connection open to "the" name server. Some root name servers, for instance, will refuse to accept TCP connections for queries because of the additional overhead. For example, the root name server which we run at the University of Maryland processes on the order of 5 queries per second, averaged over a day. Louis A. Mamakos University of Maryland, College Park From Firewalls-Owner Sun Apr 18 16:53:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28529; Sun, 18 Apr 93 16:53:08 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28522; Sun, 18 Apr 93 09:52:54 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA16561; Mon, 19 Apr 93 02:53:54 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9304181653.AA16561@coombs.anu.edu.au> Subject: Re: DNS over TCP To: louie@NI.umd.edu (Louis A. Mamakos) Date: Mon, 19 Apr 93 2:53:53 EST Cc: firewalls@GreatCircle.COM In-Reply-To: <9304181639.AA05598@sayshell.umd.edu>; from "Louis A. Mamakos" at Apr 18, 93 12:39 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In some email I received from Louis A. Mamakos, Sie wrote: [...] > > so why not ? Are DNS transactions light weight enough to make requiring > > TCP an overkill ? What if the TCP connection were kept open during the > > life of the namesrver rather than on a per-request basis ? > > > > It would greatly increase the amount of traffic and time to perform a > simple query, as well as increase the resource useage on both the > "client" machine and the name server. It is impractical to just keep > a connection open to "the" name server. > > Some root name servers, for instance, will refuse to accept TCP > connections for queries because of the additional overhead. For > example, the root name server which we run at the University of > Maryland processes on the order of 5 queries per second, averaged over > a day. Okay, what I was getting at here was people often have a normal host in the 'DMZ' which has less restrictions than the rest of the protected network and often is used to relay news/email (and maybe do proxy ftp, telnet, etc) which could be setup to use a TCP connection to the remote nameserver that it looks up to while allowing UDP from internal machines. To keep this open for the life of the nameserver as the forwardding point isn't going to cost much more and could be setup by special arrangement if the upstream server normally disallows TCP connections. It is also possible that a TCP DNS tree would be more 'secure' than one which works using UDP, but there are a lot of other factors that go into security and doesn't quite fit here. Darren From Firewalls-Owner Mon Apr 19 15:24:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01443; Mon, 19 Apr 93 15:24:14 GMT Received: from norman.li.cubic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01436; Mon, 19 Apr 93 08:23:48 PDT Received: by norman.li.cubic.com (5.67/1.34a) id AA06146; Mon, 19 Apr 93 11:23:43 -0400 Date: Mon, 19 Apr 93 11:23:43 -0400 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9304191523.AA06146@norman.li.cubic.com> To: avalon@coombs.anu.edu.au Subject: Re: DNS over TCP Cc: FireWalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Another point I haven't seen anybody bring up is that the way you run a nameserver so it will handle individual requests but not allow zone transfers is by filtering TCP packets to port 53 (only recognized secondaries should be allowed through). Note that CERT has come out in favor of disallowing unfiltered zone transfers. Dave Mischler mischler@cubic.com From Firewalls-Owner Mon Apr 19 17:09:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01836; Mon, 19 Apr 93 17:09:42 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01826; Mon, 19 Apr 93 10:09:38 PDT Message-Id: <9304191709.AA01826@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM (Firewall Mailing List) Subject: Re: DNS over TCP In-Reply-To: Your message of Sun, 18 Apr 1993 12:39:29 -0400 Date: Mon, 19 Apr 93 10:09:36 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Louis A. Mamakos" writes: # > People have said that they block all UDP packets bar those from and to # > port 53 (the port assigned to DNS and used by nameservers). # # What about other UDP based services, like NTP (Network Time Protocol)? # It seems that disabling a complete class of network transport is a bit # of overkill. Unfortunately, that's about the only option you have to keep folks from exploiting security holes in RPC-based services such as NFS and Yellow Pages (aka NIS). By the nature of RPC, you don't know for certain what UDP port an RPC-based server is going to end up using (though NFS usually uses 2049; NFS is a special case, though, that's more predictable than the others). You end up having to block almost all UDP in order to keep people from getting at your RPC-based services. Fortunately, most of the troublesome services aren't offered under TCP, or you'd have the same problem there. NTP may be able to take advantage of the same loophole as DNS, if the well-known NTP port number is used as both source and destination port on NTP server-to-server traffic. client-to-server UDP traffic (whether it's DNS or NTP or whatever) through the packet filter is still a problem, though. -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 Apr 19 18:09:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02422; Mon, 19 Apr 93 18:09:50 GMT Received: from CCA.CAMB.COM (camb.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02412; Mon, 19 Apr 93 11:09:17 PDT Received: from gs.com by camb.com (PMDF V4.2-11 #4085) id <01GX750DQV9S8Y5VAL@camb.com>; Mon, 19 Apr 1993 14:05:52 EDT Received: from moose.wan.gs.com by gs.com (PMDF #2348 ) id <01GX752L2ON495O9T6@gs.com>; Mon, 19 Apr 1993 14:06:54 EDT Received: by moose.wan.gs.com (4.1/SMI-4.1) id AA00769; Mon, 19 Apr 93 14:03:52 EDT Date: Mon, 19 Apr 1993 14:03:52 -0400 (EDT) From: safdas@moose.wan.gs.com (Shabbir J Safdar) Subject: Re: DNS over TCP To: firewalls@GreatCircle.COM, brent@GreatCircle.COM Message-Id: <9304191803.AA00769@moose.wan.gs.com> Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From Firewalls-Owner@GreatCircle.COM Mon Apr 19 13:50:14 1993 > Date: 19 Apr 1993 10:09:36 -0700 > Unfortunately, that's about the only option you have to keep folks > from exploiting security holes in RPC-based services such as NFS and > Yellow Pages (aka NIS). By the nature of RPC, you don't know for > certain what UDP port an RPC-based server is going to end up using > (though NFS usually uses 2049; NFS is a special case, though, that's > more predictable than the others). You end up having to block almost > all UDP in order to keep people from getting at your RPC-based > services. Fortunately, most of the troublesome services aren't > offered under TCP, or you'd have the same problem there. There are two other options. To block access to NIS/YP, you should install Sun patch 100482. It lets you specify, by subnet, who gets access to your NIS/YP services. It really works too. I had a co-worker setup a workstation over the weekend. He was unable to use my NIS server because I had not given him permission in my /var/yp/securenets file. Your second option (and one I would highly recommend) is to use the "securelib" product from William Lefebvre. With it, you produce a new shared library for use by RPC daemons. It intercepts the accept(), recvmsg(), and recvfrom() socket calls. I've attached the README for it. This product also gives you IP-level control over who connects to your RPC daemons. I have tested it on 4.1.2 and 4.1.3 Sun systems. -Shabbir I've included the first part of the README. The product can be ftp'ed from ftp.eecs.nwu.edu. SunOS 4.1 secure C library package Written by William LeFebvre, EECS Department, Northwestern University. Internet address: phil@eecs.nwu.edu Code for reading the configuration file, along with a few important patches, was provided by Sam Horrocks of UCI (sam@ics.uci.edu). OVERVIEW: This package contains replacement routines for these three kernel calls: accept, recvfrom, recvmsg. These replacements are compatible with the originals, with the additional functionality that they check the Internet address of the machine initiating the connection to make sure that it is "allowed" to connect. Once compiled, these can be used when building a new shared libc. The resulting libc.so can then be put in a special place. Any program that should be protected can then be started with an alternate LD_LIBRARY_PATH. What you need: SunOS version 4.1, 4.1.1, or 4.1.2 (or 4.1.3 if there ever is one), installation of the "shared library" option, root access. SunOS 5 (Solaris 2.0) users are on your own. I have no idea if this will work with version 5 or its successors. You can see if your machine has the shared library option installed by looking for the directory "/usr/lib/shlib.etc". If it is not installed, then you will need to extract it from the distribution tapes (Sun-factory installed machines will NOT have it installed). Do you need to use this? If you can answer all of these questions with "yes", then this package will benefit you: Are you connected to the Internet (even via a local or regional network)? Do all of the routers/gateways between your machine and the "rest of the world" route all packets regardless of protocol or port number? Are you concerned about the fact that any user on any system anywhere on the Internet can connect to any network daemon that runs on your machine, including ypserv and pwdauthd? AVAILABILITY: The latest version of securelib is available via anonymous FTP from the host "eecs.nwu.edu". It is stored in the file "pub/securelib.tar". Remember to use the "binary" transfer mode! DETAILS: Each modified system call has the same basic algorithm: { int retval; if ((retval = syscall(...)) >= 0) { if (_ok_address(socket, addr, *addrlen)) { return (retval); } close(retval); /* this line: "accept" only */ errno = ECONNREFUSED; return (-1); } return (retval); } Connections that are established from a host that is not "okay" will be closed (if established via "accept"), then errno will be set to ECONNREFUSED and the calling application will get an error indication back from its system call. It is assumed that the application will deal with such an error in an intelligent fashion. All Sun daemons that we have tried seem to handle this correctly: they merely do the system call again. The application will only see success for machines that "_ok_address" says are acceptable. All other connections look like failures. The function "_ok_address" reads a configuration file (normally "/etc/securelib.conf" or "/etc/security/securelib.conf") which describes what Internet address are acceptable. From Firewalls-Owner Mon Apr 19 22:13:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03256; Mon, 19 Apr 93 22:13:16 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03242; Mon, 19 Apr 93 15:12:41 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA29237; Tue, 20 Apr 93 07:52:17 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9304192152.AA29237@coombs.anu.edu.au> Subject: Re: DNS over TCP To: firewalls@GreatCircle.COM (Firewall Mailing List) Date: Tue, 20 Apr 93 7:52:15 EST Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk If zone transfers are a problem, why not use the BIND 4.8.3 source and just hack them out all together ? Ok, this would take longer than just blocking TCP, but customizing your environment like this is a good way to increase security. For example, a few sys admins I know who passionately keep logs have picked up the source to in.rshd and hacked that to log stuff properly, in addition to using TCP wrapper V5 to get usernames via ident where possible. Darren From Firewalls-Owner Tue Apr 20 15:55:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05381; Tue, 20 Apr 93 15:55:15 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05372; Tue, 20 Apr 93 08:54:56 PDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA02662; Tue, 20 Apr 93 11:55:41 EDT Received: from snark.shearson.com by shearson.com (4.1/LB-0.6) id AA16321; Tue, 20 Apr 93 11:55:39 EDT Received: by snark.shearson.com (4.1/SMI-4.1) id AA22647; Tue, 20 Apr 93 11:55:37 EDT Date: Tue, 20 Apr 93 11:55:37 EDT From: pmetzger@lehman.com (Perry E. Metzger) Message-Id: <9304201555.AA22647@snark.shearson.com> To: firewalls@GreatCircle.COM Subject: looking for.... Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm looking for a generic TCP service proxy for our firewall with which I could implement new proxy services in addition to our current proxy ftp and proxy telnet services. Does anyone have such a beast? Perry From Firewalls-Owner Tue Apr 20 16:48:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05527; Tue, 20 Apr 93 16:48:36 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05520; Tue, 20 Apr 93 09:48:28 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14431>; Tue, 20 Apr 1993 12:49:16 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA14430 (5.65a/IDA-1.4.2 for safdas@moose.wan.gs.com); Tue, 20 Apr 93 12:41:24 -0400 Received: by dino.alias.com id AA13790 (5.65a/IDA-1.4.2 for brent@GreatCircle.COM); Tue, 20 Apr 93 12:41:26 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9304201641.AA13790@dino.alias.com> Subject: Re: DNS over TCP To: safdas@moose.wan.gs.com (Shabbir J Safdar) Date: Tue, 20 Apr 1993 13:41:25 -0400 Cc: firewalls@GreatCircle.COM, brent@GreatCircle.COM In-Reply-To: <9304191803.AA00769@moose.wan.gs.com> from "Shabbir J Safdar" at Apr 19, 93 02:03:52 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 571 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > There are two other options. To block access to NIS/YP, you should install > Sun patch 100482. I'm sure this will cause my SGI, IBM RS/6000, and HP machines to crash instantly. The only Sun in the building is currently turned off. All the world isn't a Sun, despite propoganda. This fact seems to need restating every once in a while. -- C. Harald Koch, Network Manager | Grandpa Charnock's Law: Alias Research Inc. Toronto, ON | You never really learn to swear until chk@alias.com | you learn to drive. chk@gpu.utcc.utoronto.ca | From Firewalls-Owner Tue Apr 20 22:17:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06471; Tue, 20 Apr 93 22:17:18 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06464; Tue, 20 Apr 93 15:17:11 PDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA03406; Tue, 20 Apr 93 18:18:02 EDT Received: from snark.shearson.com by shearson.com (4.1/LB-0.6) id AA24858; Tue, 20 Apr 93 18:18:02 EDT Received: by snark.shearson.com (4.1/SMI-4.1) id AA23323; Tue, 20 Apr 93 18:18:01 EDT Date: Tue, 20 Apr 93 18:18:01 EDT From: pmetzger@lehman.com (Perry E. Metzger) Message-Id: <9304202218.AA23323@snark.shearson.com> To: firewalls@GreatCircle.COM Subject: can sun igateway proxy telnet pass binary data? Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm thinking of using the sun igateway proxy telnet daemon for doing something it was not intended for. My question is this -- can I coax it to send binary data straight through, or will all the telnet option negotiation signaling junk screw it up? Perry From Firewalls-Owner Tue Apr 20 23:17:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00292; Wed, 21 Apr 93 06:04:51 GMT Received: from netcom2.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00281; Tue, 20 Apr 93 23:04:45 PDT Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom) id AA09848; Tue, 20 Apr 93 17:55:57 -0700 Date: Tue, 20 Apr 93 17:55:57 -0700 From: johnj@netcom.com (John J Graham) Message-Id: <9304210055.AA09848@netcom2.netcom.com> To: Firewalls@GreatCircle.COM Subject: Firewall protection software - TermServer? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Is anyone familiar with a piece of software called TermServer or TermService? Someone at the VAR we use told us about it and that it is a "Modem Firewall" and security terminal product. Does anyone have any pointers to it or know how it works? It is supposed to be the product used internally for secure dialin at Sun Mircosystems. Thanks, John Graham From Firewalls-Owner Tue Apr 20 23:26:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00205; Wed, 21 Apr 93 06:02:37 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00190; Tue, 20 Apr 93 23:02:22 PDT Received: from shuldig.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA23378 (5.65b/HUJI 4.114); Wed, 21 Apr 93 07:33:17 +0300 Received: from localhost by shuldig.cs.huji.ac.il with SMTP id AA28856 (5.65c/HUJI 4.1 for firewalls@greatcircle.com); Wed, 21 Apr 1993 07:33:33 +0300 Message-Id: <199304210433.AA28856@shuldig.cs.huji.ac.il> To: pmetzger@lehman.com Cc: firewalls@GreatCircle.COM Subject: Re: can sun igateway proxy telnet pass binary data? In-Reply-To: Your message of Tue, 20 Apr 93 18:18:01 EDT . <9304202218.AA23323@snark.shearson.com> From: Amos Shapira Date: Wed, 21 Apr 1993 07:33:30 +0300 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9304202218.AA23323@snark.shearson.com> you write: | |I'm thinking of using the sun igateway proxy telnet daemon for doing |something it was not intended for. My question is this -- can I coax |it to send binary data straight through, or will all the telnet option |negotiation signaling junk screw it up? | |Perry The only thing you should do to avoid telnet messing around with your data is to duplicate every byte containing ascii 255 (decimal) before passing it through the link (and remove the extra copy on the recieving side of the NVT). Hope this helps, --Amos --Amos Shapira (Jumper Extraordinaire) | "It is true that power corrupts, C.S. System Group, Hebrew University, | but absolute power is better!" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- the Demon to his son From Firewalls-Owner Wed Apr 21 14:11:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01790; Wed, 21 Apr 93 14:11:04 GMT Received: from starbase.qstar.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01783; Wed, 21 Apr 93 07:10:45 PDT Received: from samiam.qstar.com by starbase.qstar.com (4.1/3.1.090690-Qstar Technologies) id AA25611; Wed, 21 Apr 93 10:10:12 EDT Received: by samiam.qstar.com (AIX 3.2/UCB 5.64/4.03) id AA12202; Wed, 21 Apr 1993 10:10:16 -0400 From: dand@qstar.com (Dan Dunn) Message-Id: <9304211410.AA12202@samiam.qstar.com> To: johnj@netcom.com (John J Graham) Cc: Firewalls@GreatCircle.COM Subject: Re: Firewall protection software - TermServer? In-Reply-To: (Your message of Tue, 20 Apr 93 17:55:57 MST.) <9304210055.AA09848@netcom2.netcom.com> Date: Wed, 21 Apr 93 10:10:16 -0500 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The product is called TermServ and is available from Los Altos Technologies, Inc., 346 Costello Court, Los Altos, CA 94024. Their phone is 415/949-4567. They are willing to send evauation copies which are good for 60 days. I just got mine and have yet to install it, so I can not give you any input on its worth. Dan Dunn QStar Technologies From Firewalls-Owner Wed Apr 21 17:00:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02203; Wed, 21 Apr 93 17:00:53 GMT Received: from cs.columbia.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02196; Wed, 21 Apr 93 10:00:40 PDT Received: from tiemann.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad+jtt) with SMTP id AA05372; Wed, 21 Apr 1993 13:01:21 -0400 Received: by tiemann.cs.columbia.edu id AA09431 (5.65c/IDA-1.4.4.5/jba/jtt/ad for firewalls@greatcircle.com); Wed, 21 Apr 1993 13:01:18 -0400 Date: Wed, 21 Apr 93 13:01:18 EDT From: Alexander Dupuy To: avalon@coombs.anu.edu.au Cc: firewalls@GreatCircle.COM (Firewall Mailing List) Reply-To: dupuy@hudson.cs.columbia.edu Subject: Re: DNS over TCP In-Reply-To: Your message of Tue, 20 Apr 93 7:52:15 EST Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > If zone transfers are a problem, why not use the BIND 4.8.3 source and > just hack them out all together ? Actually, bind 4.9, which just went into beta, has support for screening zone transfers hacked in already. This allows the administrator to specify those networks or hosts from which zone transfers will be allowed. Note that the filtering is done at the DNS level, and does not arbitrarily block all DNS/TCP connections, but only XFR requests. This is especially helpful if you use the IBM AIX version of netstat, which uses a TCP connection to the DNS nameserver (apparently because it expects to make a lot of DNS queries). The current beta is available via anonymous ftp from gatekeeper.dec.com. Kudos to Paul Vixie at DECWRL for coordinating the bind 4.9 effort, and for hacking the zone-transfer restriction so that it doesn't just block TCP requests entirely. @alex From Firewalls-Owner Thu Apr 22 15:26:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02236; Thu, 22 Apr 93 21:59:26 GMT Received: from sc.tamu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02160; Thu, 22 Apr 93 14:59:07 PDT Received: from JUPITER.TAMU.EDU by sc.tamu.edu (AA06551); Thu, 22 Apr 93 16:59:50 CDT To: firewalls@GreatCircle.COM Subject: ANNOUNCE: TAMU Security Tools Package Date: Thu, 22 Apr 1993 16:59:48 -0500 Message-Id: <6550.735515988@sc.tamu.edu> From: Douglas Lee Schales Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Texas A&M Network Security Package Overview BETA Release 1.0 -- 4/16/93 Dave Safford Doug Schales Dave Hess DESCRIPTION: Last August, Texas A&M University UNIX computers came under extensive attack from a coordinated group of internet crackers. This package of security tools represents the results of over seven months of development and testing of the software we have been using to protect our estimated twelve thousand internet connected devices. This package includes three coordinated sets of tools: "drawbridge", an exceptionally powerful bridging filter package; "tiger", a set of convenient yet thorough machine checking programs; and "netlog", a set of intrusion detection network monitoring programs. While these programs have undergone extensive testing and modification in use here, we consider this to be a beta test release, as they have not had external review, and the documentation is still very preliminary. KEY FEATURES: For full technical details on the products, see their individual README's, but here are some highlights to wet your appetite: DRAWBRIDGE: - inexpensive (pc with SMC/WD 8013 cards) - high level filter language and compiler - powerful filtering parameters - DES authenticated remote filter management - O(1) table lookup processing for full ethernet bandwidth processing, even with dense class B net filter specifications. TIGER: - checks key binaries against cryptographic checksums from original distribution files - checks for critical security patches - checks for known intrusion signatures - checks all critical configuration files - will run on most UNIX systems, and has tailored components for SunOS, Next, SVR4, Unicos. NETLOG: - efficiently logs all tcp/udp establishment attempts - powerful query tool for analyzing connection logs - "intelligent" intrusion detection program AVAILABILITY: This package is available via anonymous ftp in sc.tamu.edu:pub/security/TAMU Note that there are some distribution limitations, such as the inability to export (outside the US) the DES libraries used in drawbridge; see the respective tool readme's for details of any restrictions. CONTACT: Comments and questions are most welcome. Please address them to: drawbridge@sc.tamu.edu From Firewalls-Owner Thu Apr 22 16:26:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17775; Thu, 22 Apr 93 23:13:14 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17735; Thu, 22 Apr 93 16:13:00 PDT Message-Id: <9304222313.AA17735@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Forwarded CERT ADVISORY - Cisco Router Packet Handling Vulnerability Date: Thu, 22 Apr 93 16:12:58 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk For those of you who haven't already gotten 17 copies, a NEW CERT advisory concerning filtering bugs on Ciscos (note that this is a different problem from the one described a few months ago). Please note that CERT advisories concerning Ciscos do NOT imply that Ciscos are less secure than something else; they just mean that Cisco is more willing to work with CERT to get the word out about these problems and their fixes, for which I commend them. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 ------- Forwarded Message Message-Id: <9304222053.AA14741@tictac.cert.org> From: CERT Advisory Date: Thu, 22 Apr 93 16:47:58 EDT To: cert-advisory@cert.org Subject: CERT ADVISORY - Cisco Router Packet Handling Vulnerability Organization: Computer Emergency Response Team : 412-268-7090 =============================================================================== CA-93:07 CERT Advisory April 22, 1993 Cisco Router Packet Handling Vulnerability ----------------------------------------------------------------------------- The CERT Coordination Center has received information indicating that under some circumstances Cisco routers will pass IP source routed packets which should have been denied. Routers which do not use the "no ip source-route" command are not affected. This vulnerability applies to all models of Cisco routers. This problem occurs with the following releases of software: 8.2, 8.3, 9.0, 9.1 and 9.17. Cisco Systems and CERT recommend that sites using Cisco routers to provide firewall protection take action to eliminate this vulnerability from their networks. This security issue is fixed in Cisco software releases 8.3(7.2), 9.0(5), 9.1(4) 9.17(2.1) and in all later releases. Customers who are using software release 8.2 must upgrade to a later release and should contact Cisco's Technical Assistance Center (TAC) at 800-553-2447 (Internet: tac@cisco.com) for more information. Cisco recommends that customers whose routers may be affected by this vulnerability upgrade their software to the following versions: Release (Update) 8.3 (8) 9.0 (5) 9.1 (4) 9.17 (3) These releases are available on Cisco's Customer Information On-Line (CIO) service for those customers having a maintenance contract. Other customers may obtain these releases through Cisco's Technical Assistance Center or by contacting their local Cisco distributor. ----------------------------------------------------------------------------- I. Description A vulnerability exists in Cisco routers such that a router which is configured to suppress source routed packets with the following command: no ip source-route may allow traffic which should be suppressed. II. Impact This vulnerability can allow unauthorized traffic to pass through the router/gateway. III. Solution Cisco recommends that affected customers upgrade to a later version. Customers who cannot upgrade immediately may be able use access lists to prevent unauthorized traffic. Customers who have questions should contact the Cisco Technical Assistance Center at 800-553-2447 for assistance. Internet: tac@cisco.com --------------------------------------------------------------------------- The CERT Coordination Center wishes to thank Cisco Systems for responding to this problem. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in FIRST (Forum of Incident Response and Security Teams). Internet E-mail: cert@cert.org Telephone: 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 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). ------- End of Forwarded Message From Firewalls-Owner Thu Apr 29 02:09:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00657; Thu, 29 Apr 93 02:09:35 GMT Received: from smarts.com ([147.225.1.151]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00629; Wed, 28 Apr 93 19:07:48 PDT Received: from brainy.smarts.com by smarts.com (4.1/SMI-4.1) id AA08679; Tue, 27 Apr 93 19:43:46 EDT Received: by brainy.smarts.com (5.0/SMI-SVR4) id AA07340; Tue, 27 Apr 93 19:43:58 EDT Date: Tue, 27 Apr 93 19:43:58 EDT From: dupuy@smarts.com (Alexander Dupuy) Message-Id: <9304272343.AA07340@brainy.smarts.com> To: ppp-users@MorningStar.Com Subject: Good filtering methodology, but bad filter? Cc: timbo@ig.co.uk, firewalls@GreatCircle.COM X-Sun-Charset: US-ASCII Content-Length: 1645 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In a message on the ppp-users mailing list, Jim Murff wrote: > > I am trying to avoid "pass !all" and then turning on only what I know > > because I might not know everything I need to pass. In a reply, Tim Bunce wrote > This seems a flawed approach if security is an issue for you. I took the > opposite view and setup a basic filter with pass !all and log rejected > then ran for several weeks logging !pass lines to the console. Gradually > the filter was refined until it does what we need but *no more*. > Our default pass section looks similar to: > > pass > icmp domain > smtp/158.152.1.72 !smtp # smtp from server only > nntp/158.152.8.99 !nntp # news from server only > !ftp/syn/recv ftp ftp-data # ftp outward only > !telnet/syn/recv telnet # telnet out only > !login/syn/recv login # login out only > !shell/syn/recv shell # shell out only > !finger/syn/recv finger # finger outward only > 1024-5999/tcp > !all # exclude anything not explicitly listed I may be misunderstanding the MST ppp.Filter man page, but isn't there a major problem with this? Won't the "domain" stanza match any TCP or UDP packet where either source or destination port is 53? So if I'm root on any machine anywhere there is no DNS server, I can grab port 53 and send packets to any port on your machine (and get replies). Unfortunately, it seems that because of this, explicit reject stanzas are needed for all sensitive services, even if you use !all to reject unless otherwise accepted. @alex From Firewalls-Owner Wed Apr 28 20:08:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01199; Thu, 29 Apr 93 03:02:41 GMT Received: from gate.demon.co.uk ([158.152.1.65]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01171; Wed, 28 Apr 93 20:02:20 PDT Received: from ignite.demon.co.uk by gate.demon.co.uk id aa25972; 28 Apr 93 1:45 BST Received: by ig.co.uk (4.1/25-eef) id AA02281; Wed, 28 Apr 93 01:44:24 BST Date: Wed, 28 Apr 93 01:44:24 BST From: Tim Bunce Message-Id: <9304280044.AA02281@ig.co.uk> To: ppp-users@morningstar.com Subject: Re: Good filtering methodology, but bad filter? Cc: timbo@ig.co.uk, firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: Alexander Dupuy > > In a message on the ppp-users mailing list, Jim Murff wrote: > > > I am trying to avoid "pass !all" and then turning on only what I know > > > because I might not know everything I need to pass. > > In a reply, Tim Bunce wrote > > This seems a flawed approach if security is an issue for you. I took the > > opposite view and setup a basic filter with pass !all and log rejected > > then ran for several weeks logging !pass lines to the console. Gradually > > the filter was refined until it does what we need but *no more*. > > > Our default pass section looks similar to: > > > > pass > > icmp domain > > smtp/158.152.1.72 !smtp # smtp from server only > > nntp/158.152.8.99 !nntp # news from server only > > !ftp/syn/recv ftp ftp-data # ftp outward only > > !telnet/syn/recv telnet # telnet out only > > !login/syn/recv login # login out only > > !shell/syn/recv shell # shell out only > > !finger/syn/recv finger # finger outward only > > 1024-5999/tcp > > !all # exclude anything not explicitly listed > > I may be misunderstanding the MST ppp.Filter man page, but isn't there > a major problem with this? Won't the "domain" stanza match any TCP or > UDP packet where either source or destination port is 53? So if I'm > root on any machine anywhere there is no DNS server, I can grab port 53 > and send packets to any port on your machine (and get replies). > Ah! Thanks. That's just the sort of information I'm after. I had left domain in from the start without applying my break-it then fix-it rule. How about if I changed 'domain' to be: domain/X.X.X.X !domain # to/from named name server only Which would be ok for me querying my default external name server (assuming that I trust it). I guess life would not be so easy if I was running a name server to be used by others. For your particular scenario would: domain/X.X.X.X # to/from named name server only + domain/dst/Y.Y.Y.Y # allow others to use MY domain port !domain (where Y.Y.Y.Y is your OWN ip address) plug the hole? This extra stanza would only match and pass domain packets destined for YOUR domain port and NOT match packets FROM a domain port but destined for a non-domain port. What do you think? > Unfortunately, it seems that because of this, explicit reject stanzas > are needed for all sensitive services, even if you use !all to reject > unless otherwise accepted. Maybe I'm lucky in that my default requirements seem to be covered by the (modified) example above. I can see that people with more complicated requirements may not be able to find a concise filter. Even so, I feel happier with !all than all. > > @alex > Regards, Tim. From Firewalls-Owner Wed Apr 28 22:39:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02428; Thu, 29 Apr 93 04:43:28 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02268; Thu, 29 Apr 93 04:34:06 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02261; Wed, 28 Apr 93 21:34:02 PDT Date: Wed, 28 Apr 93 21:34:02 PDT Message-Id: <9304290434.AA02261@mycroft.GreatCircle.COM> From: Brent@GreatCircle.COM (Brent Chapman) To: Brent@GreatCircle.COM (Brent Chapman) Subject: Mail lost through crash of Mycroft.GreatCircle.COM Reply-To: Brent@GreatCircle.COM (Brent Chapman) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mycroft.GreatCircle.COM (aka FTP.GreatCircle.COM and GreatCircle.COM) suffered a major disk crash on Monday night, 26 April 93. The machine was returned to service on Wednesday night, 28 April 93. The machine was restored to its state as of 0130 PDT Sunday 25 April 93 (0830 GMT), which means that everything done on the machine Sunday and Monday was lost. Any mail sent to or through GreatCircle.COM between 0130 PDT Sunday 25 April 93 (0830 GMT Sunday 25 April 93) and about 2330 PDT Monday 26 April 93 (0630 GMT Tuesday 27 April 93) has been lost. Any mail sent to or through GreatCircle.COM after about 2330 PDT Monday 26 April 93 (0630 GMT Tuesday 27 April 93) should be OK, and will be processed over the next day or so as things get caught up around here. If you sent mail to me personally (Brent@GreatCircle.COM) on Sunday or Monday, I may or may not have seen it before the crash. If I saw it, I I probably replied to it before the crash, but I've lost both your original and my reply. I'd appreciate it if you could resend any mail you sent to me during that period, even if I already replied to it, so that I have a record (if you could also send me a copy of my own reply to you, that would be fantastic). If you sent mail to Majordomo@GreatCircle.COM on Sunday or Monday, you'll need to send it again, even if you got back a confirmation from Majordomo that it had been processed. The mailing lists were on the disk that died, so they're back to where there were as of 0130 PDT Sunday 25 April 93. If you sent mail to one of the mailing lists here (Firewalls, List-Managers, Majordomo-Users, and PhoneStation) on Sunday or Monday, it may or may not have been forwarded to the list, but it's missing from the archives. I don't remember anything earth-shaking being posted during that period, but I could be mistaken. If you got a copy of your message back from the list, then everybody else did too, and there's no need to resend it. If you sent something and haven't gotten a copy back, or if you sent something and did get a copy back but you think it's critical that it make it into the archives, you should send it again. Sorry for the inconvenience. My apologies if you end up getting multiple copies of this; it's going out to several mailing lists. Thanks for your help! -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 Apr 30 19:37:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11491; Fri, 30 Apr 93 19:37:22 GMT Received: from uxc.cso.uiuc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11484; Fri, 30 Apr 93 12:37:15 PDT Received: by uxc.cso.uiuc.edu id AA20879 (5.67a8/IDA-1.5 for Firewalls@GreatCircle.COM); Fri, 30 Apr 1993 13:38:45 -0500 Date: Fri, 30 Apr 1993 13:38:45 -0500 From: Paul Pomes - UofIllinois CSO Message-Id: <199304301838.AA20879@uxc.cso.uiuc.edu> To: Firewalls@GreatCircle.COM Subject: kerberos application gateway Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Greetings, The University of Illinois is planning an on-line registration system to be in place by fall semester of 1994. An ad-hoc committee will be recommending V4 Kerberos for authentication and the use of encrypting telnet clients for accessing sensitive data. Some parts of the puzzle are still missing however. The registration application currently runs on a IBM MVS machine and uses DB2 as its database. The problem is providing encrypted service to the MVS application. IBM's Kerberos product does authentication only. My idea was to run an application gateway on a RS-6000 host to do the Kerberos telnet conversion to vanilla telnet. The network shared by the RS-6000 and the MVS system is secured. Is there an extant solution to the problem? The lead time is such that we can roll our own if necessary, however, no one wants to re-invent the wheel. Pointers or other solutions are welcome. /pbp