From firewalls-owner Fri Apr 1 01:04:25 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA17027; Fri, 1 Apr 1994 01:04:25 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA17020; Thu, 31 Mar 1994 17:04:19 -0800 Message-Id: <199404010104.RAA17020@mycroft.GreatCircle.COM> To: Ray Hunter ECD cc: Firewalls@GreatCircle.COM Subject: Re: Cisco 3101 as a firewall In-reply-to: Your message of Thu, 31 Mar 94 14:01:51 EST Date: Thu, 31 Mar 1994 17:04:18 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Ray Hunter ECD writes: # David Conran asks: is a Cisco 3101 suitable as a Firewall? # # Personal experience (confirmed by other notes I've seen on the net) # tells me that setting *any* access list slows down routing considerably. # (due to disabling of fast-switching.) However, the *length* of the # access list does not affect performance that much more. # The typical performance hit I've seen quoted is in the range of 20-30% The key question is: does this 20-30% hit matter to your application? If you're talking about ether-to-ether (or faster, like FDDI or T-3), and expect heavy loads, then it probably does matter. However, most firewalls are bottlenecked by a 56 kb/s or 1.544 mb/s (T-1) leased line connection; even if it takes a 20-30% performance hit because of packet filtering, I think a Cisco 3000-series router is still fast enough to drive a 56 kb/s or 1.544 mb/s line at full rated speed. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Fri Apr 1 01:20:06 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA17147; Fri, 1 Apr 1994 01:20:06 GMT Received: from lokkur.dexter.mi.us by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA17136; Thu, 31 Mar 1994 17:19:48 -0800 Received: (scs@localhost) by lokkur.dexter.mi.us (8.6.7/8.6.5) id UAA29228 for firewalls@greatcircle.com; Thu, 31 Mar 1994 20:19:33 -0500 From: Steve Simmons Message-Id: <199404010119.UAA29228@lokkur.dexter.mi.us> Subject: Mixing Authentification Strategies To: firewalls@greatcircle.com (Firewalls Mailing List) Date: Thu, 31 Mar 1994 20:19:31 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1069 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been looking at skey, one-time pads, etc. One issue which doesn't seem to be addressed is the mixing of authentication types. For example, inside a reasonably secure net one might chose to use `ordinary' unix authentication. When accessing from outside, one might want to normally use skey, but fall back to a set of memorized one-time passwords if no local/trustworthy skey generator is available. The trick is how to decide on the fly which to use. Alternate ports for alternate authentications involves excessive memorization. What I'd do if I were recoding login.c is to let one modify the login id to indicate desired authentication type: login: scs # system default login: scs/skey # skey login: scs/onetime # one-time list login: scs/unix # normal unix login: scs/whatever # local custom job A good implementation would refuse to do the wrong thing, eg, not permit scs/unix from locations known to be outside the secured facility. If anybody's thought seriously about the virtues of this or has other solutions, I'd love to hear it. From firewalls-owner Fri Apr 1 02:01:07 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA17467; Fri, 1 Apr 1994 02:01:07 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA17460; Thu, 31 Mar 1994 18:00:59 -0800 Message-Id: <199404010200.SAA17460@mycroft.GreatCircle.COM> To: Randy Bias cc: firewalls@greatcircle.com Subject: Re: INN on a Firewall vs Socks proxy NNTP In-reply-to: Your message of Wed, 30 Mar 1994 16:59:00 -0800 (PST) Date: Thu, 31 Mar 1994 18:00:57 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Randy Bias writes: # One thing that needs mentioning: I have been contemplating whether to move # our News server from the Firewall to an internal host, but I've been torn # because the of the security issues. The biggest reason I see for the move is # that I'd like to have news groups for local Kalpana traffic but would prefer # that the data not reside on the Firewall, but internally. News groups with # proprietary information on the firewall sounds like a big security risk to me. I think you're right; it _is_ a big security risk to have private newsgroups on a bastion host. I generally recommend putting news on an internal host for exactly that reason. In most ways, NNTP is very similar to SMTP from a packet filtering point of view. One of the key differences is that you might get an incoming SMTP connection from anywhere, but you generally know in advance who your incoming NNTP connections will be coming from: whatever host or hosts you get your NNTP feeds from. You can thus set up a peephole in your packet filtering to allow your NNTP feed site to talk NNTP to your internal NNTP server, and vice versa. Marcus Ranum (mjr@tis.com) suggested another alternative last year: an NNTP "tunnel daemon" that runs on a bastion host and passes NNTP traffic between your internal news server and your external feed site. See the pub/firewalls/topics/nntp.Z file from FTP.GreatCircle.COM for the code and discussion. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Fri Apr 1 02:21:14 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA17617; Fri, 1 Apr 1994 02:21:14 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA17611; Thu, 31 Mar 1994 18:21:05 -0800 Received: by relay.tis.com; id AA08748; Thu, 31 Mar 94 21:21:36 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma008745; Thu Mar 31 21:21:02 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA27689; Thu, 31 Mar 94 21:20:22 EST From: Marcus J Ranum Received: by otter.tis.com (4.1/SMI-4.1) id AA17569; Thu, 31 Mar 94 21:20:20 EST Date: Thu, 31 Mar 94 21:20:20 EST Message-Id: <9404010220.AA17569@otter.tis.com> To: firewalls@GreatCircle.COM, scs@lokkur.dexter.mi.us Subject: Re: Mixing Authentification Strategies Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >The trick is how to decide on the fly which to use. Alternate ports for >alternate authentications involves excessive memorization. What I'd do >if I were recoding login.c is to let one modify the login id to indicate >desired authentication type: First off, if you're hacking login.c, then you're in the nightmare of twistly little vendor incompatibilities, all slightly different. It's not a fun place to be... You might want to consider doing something like our login-shell hack, where the person's login shell is a challenge/response application that exits if they can't authenticate, and that pastes up their environment and executes the real login shell if they do. [yes -- this approach has advantages and disadvantages] One trick we pull with our firewall is we configure our authentication server with records for each user, and for users who want multiple forms of authentication, rather than having to add code to the firewall, we just have multiple identities. So if I want to use my default authentication (id="mjr", authentication protocol is digital pathways) I log in as "mjr" -- if I forgot my SNK I could fall back on s/key and log in as "mjr-skey" mjr. From firewalls-owner Fri Apr 1 04:47:15 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA18347; Fri, 1 Apr 1994 04:47:15 GMT Received: from hosaka.smallworks.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA18341; Thu, 31 Mar 1994 20:47:07 -0800 Received: by hosaka.smallworks.com (4.1/SMI-4.1) id AA06915; Thu, 31 Mar 94 22:47:33 CST Date: Thu, 31 Mar 94 22:47:33 CST From: charisse@SmallWorks.COM (Charisse Castagnoli) Message-Id: <9404010447.AA06915@hosaka.smallworks.com> To: firewalls@GreatCircle.COM, mjr@tis.com, scs@lokkur.dexter.mi.us Subject: Re: Mixing Authentification Strategies Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>One trick we pull with our firewall is we configure our >>authentication server with records for each user, and for users >>who want multiple forms of authentication, rather than having >>to add code to the firewall, we just have multiple identities. So >>if I want to use my default authentication (id="mjr", authentication >>protocol is digital pathways) I log in as "mjr" -- if I forgot my >>SNK I could fall back on s/key and log in as "mjr-skey" Are you saying you have multiple logins per userid? This might be OK for accountability if your auditing system tracks by userid, not loginname. If you are saying you have multiple userids for each person that sounds like an accountability nightmare. I'm not really positive I like the former from an accountability perspective either since somewhere I'm sure loginname will be used when what I need is userid. charisse@smallworks.com From firewalls-owner Fri Apr 1 05:39:54 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA18522; Fri, 1 Apr 1994 05:39:54 GMT Received: from gw.home.vix.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA18516; Thu, 31 Mar 1994 21:39:45 -0800 Received: by gw.home.vix.com id AA10388; Thu, 31 Mar 94 21:39:40 -0800 Message-Id: <9404010539.AA10388@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: bsdi-users@bsdi.com, firewalls@greatcircle.com Cc: paul@vix.com, mogul@pa.dec.com Subject: screend on BSD/386 is now available Date: Thu, 31 Mar 1994 21:39:40 -0800 From: Tim Guarnieri Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Almost one year ago, I sent out mail to these two lists indicating that Paul Vixie & I had successfully ported Digital Equipment Corporation's packet screening daemon (screend) to BSD/386 1.0. I also mentioned at that time that there were a number of licensing restrictions and other matters that needed to be worked out before we could release our work. Over the course of the past year, a number of good things have happened which make the public release of our port possible. In brief: - We've worked through the licensing issues with the folks in DEC Palo Alto. This is all documented in this release and you should read it very carefully before using the software. - We've thoroughly tested it on BSD/386 1.0 and 1.1 and have it running in a production environment. Much thanks goes to the folks who participated in the alpha test of our port. Their comments, patches, suggestions, and overall patience contributed greatly to this release. - Some bugs were fixed and some features were added. Again, this is documented in this release and you should read about these items before using the software. We realize this has been a long time in coming and that many of you have asked in public forum and private e-mail when it was going to be released and we kept saying "soon". For this we must apologize, however, the time was well spent. Our port is now very stable and has some new features that folks on these lists will likely find quite useful. The release can be gotten via ftp from gatekeeper.dec.com in: /pub/misc/vixie/screend-940331.tar.gz There are two lists you can subscribe to for future discussions of screend: screend-users@vix.com screend-workers@vix.com The users list is for general use questions/issues; the workers list is for folks who want to participate in the development and maintenance of screend itself. All requests for list membership, etc. should be sent to the appropriate -request form of the above aliases and not to the lists themselves. If you have questions on the release, please direct your mail to one of these two lists. Tim & Paul From firewalls-owner Fri Apr 1 01:23:17 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA19132; Fri, 1 Apr 1994 09:10:56 GMT Received: from vm.gmd.de by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA19110; Fri, 1 Apr 1994 01:10:14 -0800 Message-Id: <199404010910.BAA19110@mycroft.GreatCircle.COM> Received: from VM.GMD.DE by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 3463; Fri, 01 Apr 94 11:04:28 +0200 Received: from ESOC.BITNET (NJE origin MAILER@ESOC) by VM.GMD.DE (LMail V1.2a/1.8a) with BSMTP id 7835; Fri, 1 Apr 1994 11:04:04 +0200 Received: from ESOC (NJE origin RHUNTER@ESOC) by ESOC.BITNET (LMail V1.2a/1.8a) with BSMTP id 3142; Fri, 1 Apr 1994 11:06:24 -0500 Comments: Converted from PROFS to RFC822 format by PUMP V2.2X Date: Fri, 1 Apr 94 11:06:22 EST From: Ray Hunter ECD Subject: Re: Cisco 3101 as a firewall In-Reply-To: note of 94-04-01 03:12 To: Brent Chapman Cc: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk fair comment Brent. I think this discussion is a bit marginal to the list, but I beg your indulgence. If you want even more Cisco opinions then have a look at the newsnet group comp.dcom.sys.cisco. I agree that the 4000 is almost certainly overkill in 95% of cases. It depends how much budget you have! If you are looking for a 2e 'choke router' aka packet filter, that is not running much multiprotocol routing then a 3101 is fine. However, the applications mentioned were: (1) ethernet to ethernet (2) involved large use of graphics (WWW etc) (I assumed by the positioning that it involved large volumes) Also the world (and especially Cisco) drop hardware as soon as it is out of fashion. I have heard (a rumour) from a Cisco VAR that the 3000 has a limited future. OK perhaps he was trying to sell us a more expensive box! Since the design is now virtually the oldest in the range I tend to agree. (if you agree the AGS+ on a CSC4 is very different from an AGS on CSC3; and a 3000 is basically a reboxed IGS) The 3000 is fixed hardware config, and stands little chance of re-use if the topology changes. The 4000 (with the addition of an NP-E module and the new ip packet filtering on inbound packets) could conceivably be used as a screened subnet gateway on its own for a small incremental cost. One thing that is rarely metioned in testing, is that when a cisco rebuilds routing tables it can stop forwarding. This can give a noticable 'pause' of 0.5-1 second where NO packets are forwarded (yes I have seen this on the 4000 too). Here the larger processor comes into its own when running multi-protocol routing. To conclude: If you are looking at a *cheap* packet filter with only 2e interfaces for IP only with no fancy routing beyond IGRP/static then look at the 3101 with the basic software option. European list price= $4994 (plus $563 for bridging if you need it) If you think your net is going to change or you have really *high* X/ graphics based applications or you are running a complex routing set up then look at the 4000 with 1 NP2-e interface: European list=$9500 (plus $1001 for bridging) It's only double the price. I *know* our net is going to change (otherwise I'd be out of a job ;-) ______________________RHUNTER@ESOC.BITNET________________________ Ray Hunter: Cray Systems on contract to the European Space Agency Tel. +49 6151 902953 FAX.+49 6151 902908 Room B107, ESOC, Robert Bosch Strasse 5, 64293 DARMSTADT, Germany From firewalls-owner Fri Apr 1 03:24:49 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA20157; Fri, 1 Apr 1994 10:46:52 GMT Received: from cs.utexas.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA20151; Fri, 1 Apr 1994 02:46:38 -0800 Message-Id: <9404011046.AA20653@cs.utexas.edu> Received: from slip-3-5.ots.utexas.edu by cs.utexas.edu (5.64/1.25/mx-relay) with SMTP id AA20653; Fri, 1 Apr 94 04:46:52 -0600 X-Sender: werner@mailbox.cs.utexas.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Apr 1994 04:48:06 -0600 To: Firewalls@GreatCircle.COM From: werner@cs.utexas.edu (Werner Uhrig) Subject: INTERNET STILL VULNERABLE, encryption standard only reliable solution ( Vinton Cerf Testimony at a House Subcommittee ) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> INTERNET STILL VULNERABLE Testimony at a House Subcommittee on >> Science indicates that threats to Internet security should be viewed >> as on-going rather than isolated events. Internet Society President >> Vinton Cerf says that development and use of an international >> encryption standard is the only reliable solution to the problem. >> (Chronicle of Higher Education 3/30/94 A22) --- Werner Uhrig From firewalls-owner Fri Apr 1 03:33:16 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA19521; Fri, 1 Apr 1994 09:39:03 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA19502; Fri, 1 Apr 1994 01:38:51 -0800 Message-Id: <199404010938.BAA19502@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: My apologies for bogus Firewalls-Digest issues last night Date: Fri, 01 Apr 1994 01:38:50 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk My apologies to the Firewalls-Digest subscribers who got the bogus Firewalls-Digest issues last night. It wasn't an April Fool's prank, at least not on my part (_my_ prank was going to be to rename the list "Fireballs" for the day, but I never had time to get it set up). I make the software I use for creating digests available via anonymous FTP. The configuration files for Firewalls-Digest are included as examples. Somebody somewhere apparently obtained the software, installed it, and started running it using the unmodified sample configuration files as their own. I've updated the examples in the software distribution so that this won't happen again. People who read the un-digested main Firewalls list never saw these bogus digests, and weren't affected by the problem. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Fri Apr 1 12:49:23 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA20517; Fri, 1 Apr 1994 12:49:23 GMT Received: from post.demon.co.uk by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA20508; Fri, 1 Apr 1994 04:49:06 -0800 Received: from demon.demon.co.uk by post.demon.co.uk id ab00528; 1 Apr 94 13:42 GMT-60:00 Received: from cellnet.uucp by demon.demon.co.uk id aa11937; 1 Apr 94 13:42 BST From: Steve Kennedy Message-Id: <5455.9404011252@marvin.gbnet.org> Subject: Re: Cisco 3101 as a firewall To: vm.gmd.de!esoc.bitnet!RHUNTER@gbnet.org Date: Fri, 1 Apr 1994 12:52:47 +0000 (GMT) Cc: greatcircle.com!brent@gbnet.org, greatcircle.com!Firewalls@gbnet.org In-Reply-To: <199404010910.BAA19110@mycroft.GreatCircle.COM> from "Ray Hunter ECD" at Apr 1, 94 11:06:22 am X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1177 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Ray et al, > To conclude: > If you are looking at a *cheap* packet filter with only 2e interfaces for > IP only with no fancy routing beyond IGRP/static then look at the 3101 > with the basic software option. European list price= $4994 > (plus $563 for bridging if you need it) > If you think your net is going to change or you have really *high* X/ > graphics based applications or you are running a complex routing set up > then look at the 4000 with 1 NP2-e interface: European list=$9500 > (plus $1001 for bridging) You could also use a KarlBrouter (only does static routes) - it's a LOT cheaper. Regards Steve -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 WorldBlazer T3000 V32bis/PEP+... ISDN: 722 7969/70 Email Snail Mail steve@gbnet.{org,com,net} [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd stevek@cellnet.co.uk [work] London, NW3 4LU From firewalls-owner Fri Apr 1 17:54:14 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA21413; Fri, 1 Apr 1994 17:54:14 GMT Received: from sprintlink.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA21407; Fri, 1 Apr 1994 09:54:08 -0800 Received: by sprintlink.net (5.65/1.34) id AA03096; Fri, 1 Apr 94 12:54:38 -0500 Date: Fri, 1 Apr 1994 12:54:38 -0500 (EST) From: Luther Garcia Subject: "ICMP redirects" To: firewalls@greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I was wondering if anyone out there knows a way to protect from forged ICMP redirects. We can't just disable ICMP as we need the ability to do pings. Any suggestions would be apprecitated and carefully considered. luth@tiny.sprintlink.net From firewalls-owner Fri Apr 1 18:01:25 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA21483; Fri, 1 Apr 1994 18:01:25 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA21467; Fri, 1 Apr 1994 10:01:01 -0800 Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id KAA08260 for ; Fri, 1 Apr 1994 10:01:17 -0800 Message-Id: <199404011801.KAA08260@mailgate.cadence.com> Received: from mac32_223.cadence.com(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma008204; Fri Apr 1 10:00:51 1994 Date: Fri, 1 Apr 1994 10:00:51 -0800 To: firewalls@greatcircle.com From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: Mixing Authentification Strategies Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I've been looking at skey, one-time pads, etc. One issue which doesn't >seem to be addressed is the mixing of authentication types. For example, >inside a reasonably secure net one might chose to use `ordinary' unix >authentication. When accessing from outside, one might want to normally >use skey, but fall back to a set of memorized one-time passwords if no >local/trustworthy skey generator is available. > >The trick is how to decide on the fly which to use. Alternate ports for >alternate authentications involves excessive memorization. What I'd do >if I were recoding login.c is to let one modify the login id to indicate >desired authentication type: Take a look at the firewalls toolkit from tis.com, this allows you to specify a different authentication protocol by user and run everything from a central authentication server over encrypted channels. I'll be expanding our version of it to allow the same user to use strong authentication (in our case SecurID or Skey), in some instances and passwords in others. This will involve expanding the account record format somewhat. Marcus is against adding too much functionality to the toolkit as complexity ->> bugs, but we need this flexibility in our environment, particularly in the transition from passwords to something better. Have source, will travel :-) I am particularly keen on using the TIS authsrv daemon to do this, specifically because it does allow multiple authentication protocols simultaneously and you don't have to hack your client programs (login, ftpd etc) every time you want to try out a new vendors authentication token. We are using SecurID now because it is the simplest from the user's point of view. What I'm really waiting for is the iPower card in SmartDisk format. SecurID in SmartDisk format would be nice too, particularly for ppp applications where the system drops the line when its quiet and re-establishes the connection automatically when required. Having an authentication daemon which acts as a clearing house for multiple protocols gives real flexibility for future changes in technology. Al --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From firewalls-owner Fri Apr 1 18:08:52 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA21550; Fri, 1 Apr 1994 18:08:52 GMT Received: from sprintlink.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA21543; Fri, 1 Apr 1994 10:08:45 -0800 Received: by sprintlink.net (5.65/1.34) id AA03253; Fri, 1 Apr 94 13:09:14 -0500 Date: Fri, 1 Apr 1994 13:09:13 -0500 (EST) From: Luther Garcia Subject: "FORGED ICMP REDIRECTS CORRECTION" To: firewalls@greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I previously (a few seconds ago) sent a message asking for help about forced ICMP redirects. Well, reading my sent mailbox, I realized that I made a typo, "forced ICMP redirects" should be changed to: "forged ICMP redirects" thank you for your patience and understanding, I have throttled myself appropriately for it. :) luth@tiny.sprintlink.net From firewalls-owner Fri Apr 1 18:18:31 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA21619; Fri, 1 Apr 1994 18:18:31 GMT Received: from kalpana.kalpana.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA21610; Fri, 1 Apr 1994 10:18:18 -0800 Received: from charon.kalpana.COM (charon.kalpana.com [192.216.249.11]) by kalpana.kalpana.COM (8.6.4/8.6.4) with ESMTP id KAA24383; Fri, 1 Apr 1994 10:15:49 -0800 Received: from localhost (randyb@localhost) by charon.kalpana.COM (8.6.4/8.6.4) id KAA00296; Fri, 1 Apr 1994 10:19:52 -0800 From: Randy Bias Message-Id: <199404011819.KAA00296@charon.kalpana.COM> Subject: Re: INN on a Firewall vs Socks proxy NNTP To: brent@GreatCircle.COM (Brent Chapman) Date: Fri, 1 Apr 1994 10:19:52 -0800 (PST) Cc: randyb@kalpana.com, firewalls@GreatCircle.COM In-Reply-To: <199404010200.SAA17460@mycroft.GreatCircle.COM> from "Brent Chapman" at Mar 31, 94 06:00:57 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 731 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent Chapman says: >I think you're right; it _is_ a big security risk to have private >newsgroups on a bastion host. I generally recommend putting news on >an internal host for exactly that reason. OK. Your point about knowing the external hosts is well taken. A quick digression; has anyone directly on the Internet ever had MX records created in DNS for the purpose of routing all of your mail through one external host? (a service provider for example). I don't know if that is very useful or not, but it would make attacks on SMTP difficult from anywhere but the external MX mail forwarder. >See the pub/firewalls/topics/nntp.Z file from FTP.GreatCircle.COM for >the code and discussion. Thanks for the pointer. --Randy From firewalls-owner Fri Apr 1 18:57:52 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA21846; Fri, 1 Apr 1994 18:57:52 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA21838; Fri, 1 Apr 1994 10:57:38 -0800 Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id KAA11678 for ; Fri, 1 Apr 1994 10:58:07 -0800 Message-Id: <199404011858.KAA11678@mailgate.cadence.com> Received: from mac32_223.cadence.com(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma011653; Fri Apr 1 10:57:44 1994 Date: Fri, 1 Apr 1994 10:57:44 -0800 To: firewalls@greatcircle.com From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: "ICMP redirects" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I was wondering if anyone out there knows a way to protect from >forged ICMP redirects. We can't just disable ICMP as we need the >ability to do pings. Any suggestions would be apprecitated and carefully >considered. > > luth@tiny.sprintlink.net We selectively drop ICMP redirects using a modified version of the Smallworks NetGate packet filter (info@smallworks.com). The capability to select ICMP packets by type and code is not in the current release, but I sent them the changes about a year ago. Al --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From firewalls-owner Sun Apr 3 01:18:47 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA27346; Sun, 3 Apr 1994 01:18:47 GMT Received: from runner.knoware.nl by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA27338; Sat, 2 Apr 1994 17:18:15 -0800 Received: by runner.knoware.nl (5.64/A/UX-3.00) id AA13083; Sun, 3 Apr 94 02:07:22 WET DST Date: Sun, 3 Apr 1994 02:04:28 +0100 (WET DST) From: "J.P. Mante" Subject: Re: INTERNET STILL VULNERABLE, encryption standard only reliable solution ( Vinton Cerf Testimony at a House Subcommittee ) To: Werner Uhrig Cc: Firewalls@GreatCircle.COM In-Reply-To: <9404011046.AA20653@cs.utexas.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Fri, 1 Apr 1994, Werner Uhrig wrote: > >> INTERNET STILL VULNERABLE Testimony at a House Subcommittee on > >> Science indicates that threats to Internet security should be viewed > >> as on-going rather than isolated events. Internet Society President > >> Vinton Cerf says that development and use of an international > >> encryption standard is the only reliable solution to the problem. > >> (Chronicle of Higher Education 3/30/94 A22) > > --- > Werner Uhrig > > > Well this make a lot of sense, unfortunately there are countries such as the Netherlands were encryption will most likely become illagal fro other than Government agencies. At one side we are to be protected against hacking on the other side it seems to be the idea to take away the tools which would enable us to do so. Omega From firewalls-owner Sun Apr 3 21:49:26 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA02859; Mon, 4 Apr 1994 04:34:08 GMT Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA28265; Sun, 3 Apr 1994 01:00:16 -0800 Date: Sun, 3 Apr 1994 01:00:16 -0800 Message-Id: <199404030900.BAA28265@mycroft.GreatCircle.COM> From: Firewalls-Digest-Owner@GreatCircle.COM To: Firewalls-Digest@GreatCircle.COM Subject: Firewalls Digest V3 #102 Reply-To: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Firewalls Digest Sunday, 3 April 1994 Volume 03 : Number 102 In this issue: Re: INTERNET STILL VULNERABLE, encryption standard only reliable solution ( Vinton Cerf Testimony at a House Subcommittee ) See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: "J.P. Mante" Date: Sun, 3 Apr 1994 02:04:28 +0100 (WET DST) Subject: Re: INTERNET STILL VULNERABLE, encryption standard only reliable solution ( Vinton Cerf Testimony at a House Subcommittee ) On Fri, 1 Apr 1994, Werner Uhrig wrote: > >> INTERNET STILL VULNERABLE Testimony at a House Subcommittee on > >> Science indicates that threats to Internet security should be viewed > >> as on-going rather than isolated events. Internet Society President > >> Vinton Cerf says that development and use of an international > >> encryption standard is the only reliable solution to the problem. > >> (Chronicle of Higher Education 3/30/94 A22) > > --- > Werner Uhrig > > > Well this make a lot of sense, unfortunately there are countries such as the Netherlands were encryption will most likely become illagal fro other than Government agencies. At one side we are to be protected against hacking on the other side it seems to be the idea to take away the tools which would enable us to do so. Omega ------------------------------ End of Firewalls Digest V3 #102 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). From firewalls-owner Sun Apr 3 21:59:28 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA02861; Mon, 4 Apr 1994 04:34:12 GMT Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA25169; Sat, 2 Apr 1994 01:00:10 -0800 Date: Sat, 2 Apr 1994 01:00:10 -0800 Message-Id: <199404020900.BAA25169@mycroft.GreatCircle.COM> From: Firewalls-Digest-Owner@GreatCircle.COM To: Firewalls-Digest@GreatCircle.COM Subject: Firewalls Digest V3 #101 Reply-To: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Firewalls Digest Saturday, 2 April 1994 Volume 03 : Number 101 In this issue: Re: Cisco 3101 as a firewall INTERNET STILL VULNERABLE, encryption standard only reliable solution ( Vinton Cerf Testimony at a House Subcommittee ) My apologies for bogus Firewalls-Digest issues last night Re: Cisco 3101 as a firewall "ICMP redirects" Re: Mixing Authentification Strategies "FORGED ICMP REDIRECTS CORRECTION" Re: INN on a Firewall vs Socks proxy NNTP Re: "ICMP redirects" See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: Ray Hunter ECD Date: Fri, 1 Apr 94 11:06:22 EST Subject: Re: Cisco 3101 as a firewall fair comment Brent. I think this discussion is a bit marginal to the list, but I beg your indulgence. If you want even more Cisco opinions then have a look at the newsnet group comp.dcom.sys.cisco. I agree that the 4000 is almost certainly overkill in 95% of cases. It depends how much budget you have! If you are looking for a 2e 'choke router' aka packet filter, that is not running much multiprotocol routing then a 3101 is fine. However, the applications mentioned were: (1) ethernet to ethernet (2) involved large use of graphics (WWW etc) (I assumed by the positioning that it involved large volumes) Also the world (and especially Cisco) drop hardware as soon as it is out of fashion. I have heard (a rumour) from a Cisco VAR that the 3000 has a limited future. OK perhaps he was trying to sell us a more expensive box! Since the design is now virtually the oldest in the range I tend to agree. (if you agree the AGS+ on a CSC4 is very different from an AGS on CSC3; and a 3000 is basically a reboxed IGS) The 3000 is fixed hardware config, and stands little chance of re-use if the topology changes. The 4000 (with the addition of an NP-E module and the new ip packet filtering on inbound packets) could conceivably be used as a screened subnet gateway on its own for a small incremental cost. One thing that is rarely metioned in testing, is that when a cisco rebuilds routing tables it can stop forwarding. This can give a noticable 'pause' of 0.5-1 second where NO packets are forwarded (yes I have seen this on the 4000 too). Here the larger processor comes into its own when running multi-protocol routing. To conclude: If you are looking at a *cheap* packet filter with only 2e interfaces for IP only with no fancy routing beyond IGRP/static then look at the 3101 with the basic software option. European list price= $4994 (plus $563 for bridging if you need it) If you think your net is going to change or you have really *high* X/ graphics based applications or you are running a complex routing set up then look at the 4000 with 1 NP2-e interface: European list=$9500 (plus $1001 for bridging) It's only double the price. I *know* our net is going to change (otherwise I'd be out of a job ;-) ______________________RHUNTER@ESOC.BITNET________________________ Ray Hunter: Cray Systems on contract to the European Space Agency Tel. +49 6151 902953 FAX.+49 6151 902908 Room B107, ESOC, Robert Bosch Strasse 5, 64293 DARMSTADT, Germany ------------------------------ From: werner@cs.utexas.edu (Werner Uhrig) Date: Fri, 1 Apr 1994 04:48:06 -0600 Subject: INTERNET STILL VULNERABLE, encryption standard only reliable solution ( Vinton Cerf Testimony at a House Subcommittee ) >> INTERNET STILL VULNERABLE Testimony at a House Subcommittee on >> Science indicates that threats to Internet security should be viewed >> as on-going rather than isolated events. Internet Society President >> Vinton Cerf says that development and use of an international >> encryption standard is the only reliable solution to the problem. >> (Chronicle of Higher Education 3/30/94 A22) - --- Werner Uhrig ------------------------------ From: Brent Chapman Date: Fri, 01 Apr 1994 01:38:50 -0800 Subject: My apologies for bogus Firewalls-Digest issues last night My apologies to the Firewalls-Digest subscribers who got the bogus Firewalls-Digest issues last night. It wasn't an April Fool's prank, at least not on my part (_my_ prank was going to be to rename the list "Fireballs" for the day, but I never had time to get it set up). I make the software I use for creating digests available via anonymous FTP. The configuration files for Firewalls-Digest are included as examples. Somebody somewhere apparently obtained the software, installed it, and started running it using the unmodified sample configuration files as their own. I've updated the examples in the software distribution so that this won't happen again. People who read the un-digested main Firewalls list never saw these bogus digests, and weren't affected by the problem. - -Brent - -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates ------------------------------ From: Steve Kennedy Date: Fri, 1 Apr 1994 12:52:47 +0000 (GMT) Subject: Re: Cisco 3101 as a firewall Ray et al, > To conclude: > If you are looking at a *cheap* packet filter with only 2e interfaces for > IP only with no fancy routing beyond IGRP/static then look at the 3101 > with the basic software option. European list price= $4994 > (plus $563 for bridging if you need it) > If you think your net is going to change or you have really *high* X/ > graphics based applications or you are running a complex routing set up > then look at the 4000 with 1 NP2-e interface: European list=$9500 > (plus $1001 for bridging) You could also use a KarlBrouter (only does static routes) - it's a LOT cheaper. Regards Steve - -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 WorldBlazer T3000 V32bis/PEP+... ISDN: 722 7969/70 Email Snail Mail steve@gbnet.{org,com,net} [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd stevek@cellnet.co.uk [work] London, NW3 4LU ------------------------------ From: Luther Garcia Date: Fri, 1 Apr 1994 12:54:38 -0500 (EST) Subject: "ICMP redirects" I was wondering if anyone out there knows a way to protect from forged ICMP redirects. We can't just disable ICMP as we need the ability to do pings. Any suggestions would be apprecitated and carefully considered. luth@tiny.sprintlink.net ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Fri, 1 Apr 1994 10:00:51 -0800 Subject: Re: Mixing Authentification Strategies >I've been looking at skey, one-time pads, etc. One issue which doesn't >seem to be addressed is the mixing of authentication types. For example, >inside a reasonably secure net one might chose to use `ordinary' unix >authentication. When accessing from outside, one might want to normally >use skey, but fall back to a set of memorized one-time passwords if no >local/trustworthy skey generator is available. > >The trick is how to decide on the fly which to use. Alternate ports for >alternate authentications involves excessive memorization. What I'd do >if I were recoding login.c is to let one modify the login id to indicate >desired authentication type: Take a look at the firewalls toolkit from tis.com, this allows you to specify a different authentication protocol by user and run everything from a central authentication server over encrypted channels. I'll be expanding our version of it to allow the same user to use strong authentication (in our case SecurID or Skey), in some instances and passwords in others. This will involve expanding the account record format somewhat. Marcus is against adding too much functionality to the toolkit as complexity ->> bugs, but we need this flexibility in our environment, particularly in the transition from passwords to something better. Have source, will travel :-) I am particularly keen on using the TIS authsrv daemon to do this, specifically because it does allow multiple authentication protocols simultaneously and you don't have to hack your client programs (login, ftpd etc) every time you want to try out a new vendors authentication token. We are using SecurID now because it is the simplest from the user's point of view. What I'm really waiting for is the iPower card in SmartDisk format. SecurID in SmartDisk format would be nice too, particularly for ppp applications where the system drops the line when its quiet and re-establishes the connection automatically when required. Having an authentication daemon which acts as a clearing house for multiple protocols gives real flexibility for future changes in technology. Al - --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ From: Luther Garcia Date: Fri, 1 Apr 1994 13:09:13 -0500 (EST) Subject: "FORGED ICMP REDIRECTS CORRECTION" I previously (a few seconds ago) sent a message asking for help about forced ICMP redirects. Well, reading my sent mailbox, I realized that I made a typo, "forced ICMP redirects" should be changed to: "forged ICMP redirects" thank you for your patience and understanding, I have throttled myself appropriately for it. :) luth@tiny.sprintlink.net ------------------------------ From: Randy Bias Date: Fri, 1 Apr 1994 10:19:52 -0800 (PST) Subject: Re: INN on a Firewall vs Socks proxy NNTP Brent Chapman says: >I think you're right; it _is_ a big security risk to have private >newsgroups on a bastion host. I generally recommend putting news on >an internal host for exactly that reason. OK. Your point about knowing the external hosts is well taken. A quick digression; has anyone directly on the Internet ever had MX records created in DNS for the purpose of routing all of your mail through one external host? (a service provider for example). I don't know if that is very useful or not, but it would make attacks on SMTP difficult from anywhere but the external MX mail forwarder. >See the pub/firewalls/topics/nntp.Z file from FTP.GreatCircle.COM for >the code and discussion. Thanks for the pointer. - --Randy ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Fri, 1 Apr 1994 10:57:44 -0800 Subject: Re: "ICMP redirects" > I was wondering if anyone out there knows a way to protect from >forged ICMP redirects. We can't just disable ICMP as we need the >ability to do pings. Any suggestions would be apprecitated and carefully >considered. > > luth@tiny.sprintlink.net We selectively drop ICMP redirects using a modified version of the Smallworks NetGate packet filter (info@smallworks.com). The capability to select ICMP packets by type and code is not in the current release, but I sent them the changes about a year ago. Al - --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ End of Firewalls Digest V3 #101 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). From firewalls-owner Mon Apr 4 07:08:15 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA04360; Mon, 4 Apr 1994 07:08:15 GMT Received: from ftp.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA04353; Mon, 4 Apr 1994 00:08:05 -0700 Received: by ftp.com ; Mon, 4 Apr 1994 03:07:54 -0400 Date: Mon, 4 Apr 1994 03:07:54 -0400 From: hobbit@ftp.com (*Hobbit*) Message-Id: <9404040707.AA28009@ftp.com> To: firewalls@greatcircle.com Subject: system() Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Since this sort of BASIC-grade programming is such a perennial problem, perhaps someone should write a safe_system() to replace such calls with, that does more arg checking, flushes dangerous things, warns of impending lossage, etc? One or more instances of this should have been written ten years ago. _H* From firewalls-owner Mon Apr 4 18:02:44 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA06890; Mon, 4 Apr 1994 18:02:44 GMT Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA06883; Mon, 4 Apr 1994 11:02:37 -0700 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id KAA20947; Mon, 4 Apr 1994 10:46:51 -0700 Received: from avalle.insoft.com by insoft1.insoft.com (4.1/RHP-1.0) id AA11323; Mon, 4 Apr 94 13:33:04 EDT Received: by avalle.insoft.com (5.0/SMI-SVR4) id AA00892; Mon, 4 Apr 1994 13:29:14 +0500 Date: Mon, 4 Apr 1994 13:29:14 +0500 From: francis@avalle.insoft.com (John [Francis] Stracke) Message-Id: <9404041729.AA00892@avalle.insoft.com> To: firewalls@GreatCircle.COM In-Reply-To: *Hobbit*'s message of Mon, 4 Apr 1994 03:07:54 -0400 <9404040707.AA28009@ftp.com> Subject: system() Content-Length: 927 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Since this sort of BASIC-grade programming is such a perennial problem, perhaps >someone should write a safe_system() to replace such calls with, that does >more arg checking, flushes dangerous things, warns of impending lossage, etc? >One or more instances of this should have been written ten years ago. It'd be AI-complete. How do you know what's dangerous & what's not? I'd rather not have people thinking safe_system() is safe when it really isn't. /===========================================================================\ |John (Francis) Stracke | My opinions are my own. | |InSoft, Inc. |==================================================| |Mechanicsburg, PA | If you're going to walk on thin ice, | |francis@insoft.com | you might as well *dance*! | \===========================================================================/ From firewalls-owner Mon Apr 4 18:21:55 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA07437; Mon, 4 Apr 1994 18:21:55 GMT Received: from sprintlink.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA07431; Mon, 4 Apr 1994 11:21:42 -0700 Received: by sprintlink.net (5.65/1.34) id AA23848; Mon, 4 Apr 94 13:21:19 -0500 Date: Mon, 4 Apr 1994 13:21:19 -0500 (EST) From: Luther Garcia Subject: "One time passwords" To: firewalls@greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi. I know that this really isn't a forum for advertising, but I was wondering if anyone could give me some information on prices, and possibly a recommendation for those one time password hoo-yah thingees that kind of look like a little calculator. We are thinking of using those for anyone who would need to telecommute this way it doesn't make our net behind the firewall so vulnerable, without having to sacrifice dial-up access all together. We are considering some other options, if you have any don't be bashful. One would be a dedicated phone server that is also running the firewall, has anyone else had any experience with this? luth@sprintlink.net From firewalls-owner Mon Apr 4 12:33:23 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA00464; Mon, 4 Apr 1994 19:23:53 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA00458; Mon, 4 Apr 1994 12:23:45 -0700 Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA20161; Mon, 4 Apr 94 15:17:53 -0400 Received: by cobalt.house.gov (AA02787); Mon, 4 Apr 94 15:18:14 -0700 Date: Mon, 4 Apr 94 15:18:14 -0700 From: Dorian Deane Message-Id: <9404042218.AA02787@cobalt.house.gov> To: firewalls@GreatCircle.COM, francis@avalle.insoft.com Subject: Re: system() Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > >Since this sort of BASIC-grade programming is such a perennial problem, perhaps > >someone should write a safe_system() to replace such calls with, that does > >more arg checking, flushes dangerous things, warns of impending lossage, etc? > >One or more instances of this should have been written ten years ago. > > It'd be AI-complete. How do you know what's dangerous & what's not? > I'd rather not have people thinking safe_system() is safe when it > really isn't. > How about doing for system() what 386BSD does for gets()? cobalt 67 % ./a.out warning: this program uses gets(), which is unsafe. ^C cobalt 68% Some people might find a 386BSD-type solution a bit draconian, especially in a production environment, but it really gets the message across. dorian From firewalls-owner Mon Apr 4 15:33:24 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA01863; Mon, 4 Apr 1994 22:22:08 GMT Received: from lokkur.dexter.mi.us by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA01857; Mon, 4 Apr 1994 15:21:58 -0700 Received: (scs@localhost) by lokkur.dexter.mi.us (8.6.7/8.6.5) id SAA09219; Mon, 4 Apr 1994 18:21:05 -0400 From: Steve Simmons Message-Id: <199404042221.SAA09219@lokkur.dexter.mi.us> Subject: Re: system() To: dorian@cobalt.house.gov (Dorian Deane) Date: Mon, 4 Apr 1994 18:21:04 -0400 (EDT) Cc: firewalls@GreatCircle.COM, francis@avalle.insoft.com In-Reply-To: <9404042218.AA02787@cobalt.house.gov> from "Dorian Deane" at Apr 4, 94 03:18:14 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 178 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >How about doing for system() what 386BSD does for gets()? > > cobalt 67 % ./a.out > warning: this program uses gets(), which is unsafe. > ^C > cobalt 68% Respectfully, no. From firewalls-owner Mon Apr 4 22:46:02 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA02149; Mon, 4 Apr 1994 22:46:02 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA02140; Mon, 4 Apr 1994 15:45:56 -0700 Message-Id: <199404042245.PAA02140@mycroft.GreatCircle.COM> To: Steve Simmons cc: dorian@cobalt.house.gov (Dorian Deane), firewalls@GreatCircle.COM, francis@avalle.insoft.com Subject: Re: system() In-reply-to: Your message of Mon, 4 Apr 1994 18:21:04 -0400 (EDT) Date: Mon, 04 Apr 1994 15:45:55 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Steve Simmons writes: # >How about doing for system() what 386BSD does for gets()? # > # > cobalt 67 % ./a.out # > warning: this program uses gets(), which is unsafe. # > ^C # > cobalt 68% # # Respectfully, no. I agree with Steve on this one. When I first glanced at the original message quoted above, I assumed it was a compile-time or link-time warning, and thought "Hey, good idea!". But a run-time message? I don't think so. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Tue Apr 5 01:05:42 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA03007; Tue, 5 Apr 1994 01:05:42 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA03001; Mon, 4 Apr 1994 18:05:35 -0700 Received: by relay.tis.com; id AA29289; Mon, 4 Apr 94 21:05:37 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma029284; Mon Apr 4 21:05:27 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA27729; Mon, 4 Apr 94 21:04:42 EDT From: Marcus J Ranum Received: by otter.tis.com (4.1/SMI-4.1) id AA24444; Mon, 4 Apr 94 21:04:40 EDT Date: Mon, 4 Apr 94 21:04:40 EDT Message-Id: <9404050104.AA24444@otter.tis.com> To: brent@GreatCircle.COM, scs@lokkur.dexter.mi.us Subject: Re: system() Cc: dorian@cobalt.house.gov, firewalls@GreatCircle.COM, francis@avalle.insoft.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I agree with Steve on this one. When I first glanced at the original >message quoted above, I assumed it was a compile-time or link-time warning, >and thought "Hey, good idea!". But a run-time message? I don't think so. I think: ar d /lib/libc.a system.o ranlib /lib/libc.a will have the same (or perhaps a more salubrious) effect. mjr. From firewalls-owner Tue Apr 5 13:33:33 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA06408; Tue, 5 Apr 1994 13:33:33 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA06402; Tue, 5 Apr 1994 06:33:26 -0700 Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA25765; Tue, 5 Apr 94 09:27:12 -0400 Received: by cobalt.house.gov (AA03297); Tue, 5 Apr 94 09:27:38 -0700 Date: Tue, 5 Apr 94 09:27:38 -0700 From: Dorian Deane Message-Id: <9404051627.AA03297@cobalt.house.gov> To: firewalls@GreatCircle.COM Subject: Re: system() Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > >I agree with Steve on this one. When I first glanced at the original > >message quoted above, I assumed it was a compile-time or link-time warning, > >and thought "Hey, good idea!". But a run-time message? I don't think so. Think of it as a way of forcing developers to make their changes almost overnight. Or, think of it as a way to shake the bugs out. Or, think of it as a perfect demonstration that large systems are houses of cards, ready to fall in the first breeze of unexpected input. (No polemics, please, about this last stmt--especially since it's a bit of a digression.) > > I think: > > ar d /lib/libc.a system.o > ranlib /lib/libc.a > > will have the same (or perhaps a more salubrious) effect. > > mjr. > That _does_ cut to the chase, doesn't it? dorian From firewalls-owner Tue Apr 5 23:44:28 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA02748; Tue, 5 Apr 1994 23:44:28 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA02742; Tue, 5 Apr 1994 16:44:21 -0700 Received: from odin.UU.NET by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwkjm23176; Tue, 5 Apr 94 19:44:19 -0400 Received: by odin.UU.NET (5.61/UUNET-mail-drop) id AA21369; Tue, 5 Apr 94 19:44:18 -0400 From: earle@uunet.uu.net (Earle Ady) Message-Id: <9404052344.AA21369@odin.UU.NET> Subject: Re: system() To: dorian@cobalt.house.gov (Dorian Deane) Date: Tue, 5 Apr 1994 19:44:17 -0400 (EDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9404051627.AA03297@cobalt.house.gov> from "Dorian Deane" at Apr 5, 94 09:27:38 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1238 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Do you plan on stripping out every ``dangerous'' thing as it comes along? Are you going to disable popen() too? Why not just fix the problem where it exists instead of disabling every single problem that arises? Pretty soon we'll be left with nothing, then everyone loses. --- Earle Ady earle@uunet.uu.net Dorian Deane claims: ] ] > ] > >I agree with Steve on this one. When I first glanced at the original ] > >message quoted above, I assumed it was a compile-time or link-time warning, ] > >and thought "Hey, good idea!". But a run-time message? I don't think so. ] ] Think of it as a way of forcing developers to make their changes almost ] overnight. Or, think of it as a way to shake the bugs out. Or, ] think of it as a perfect demonstration that large systems are houses ] of cards, ready to fall in the first breeze of unexpected input. (No ] polemics, please, about this last stmt--especially since it's a bit of ] a digression.) ] ] > ] > I think: ] > ] > ar d /lib/libc.a system.o ] > ranlib /lib/libc.a ] > ] > will have the same (or perhaps a more salubrious) effect. ] > ] > mjr. ] > ] ] That _does_ cut to the chase, doesn't it? ] ] dorian ] ] ] From firewalls-owner Tue Apr 5 19:38:37 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA00535; Wed, 6 Apr 1994 02:25:43 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA00529; Tue, 5 Apr 1994 19:25:30 -0700 Received: by relay.tis.com; id AA07094; Tue, 5 Apr 94 22:25:32 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma007087; Tue Apr 5 22:25:29 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA26094; Tue, 5 Apr 94 22:24:43 EDT From: Marcus J Ranum Received: by otter.tis.com (4.1/SMI-4.1) id AA27083; Tue, 5 Apr 94 22:24:42 EDT Date: Tue, 5 Apr 94 22:24:42 EDT Message-Id: <9404060224.AA27083@otter.tis.com> To: dorian@cobalt.house.gov, earle@uunet.uu.net Subject: Re: system() Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This is a bit "off topic" for the general issue of firewalls, but it raises a fundamental question about how you develop secure software, so I'll soapbox a little bit. >Do you plan on stripping out every ``dangerous'' thing as it comes along? >Are you going to disable popen() too? Why not just fix the problem where >it exists instead of disabling every single problem that arises? Pretty >soon we'll be left with nothing, then everyone loses. There are 2 ways to design secure software. The first way is to identify everything that's dangerous, and to eliminate it, until you have something that you trust. The second way is to design it such that, given a few basic assumptions, it's not going to be dangerous at all. Guess which one works better. Guess which one requires more skill, and more familiarity with the systems model under which the software is being built. Generally, what happens is you wind up with something that's full of security holes, and then you've got to fix them. This can sometimes consume more total effort than doing it right in the first place. Sendmail leaps to mind as an example of a case where "penetrate and patch" is a very, very expensive approach. [Anyone who complains, "but sendmail is free!" simply doesn't get it] With respect to finding holes in programs, you tend to find after a while that some things are Bad Ideas. Things that are Bad Ideas are stuff like: 1: having privileged programs that execute other programs based on what someone else tells them to do (example of 1) using system() in privileged programs (example of 2) using popen() in privileged programs -> having privileged programs when sensibly designed programs will do -> having large, complex privileged programs instead of small simple privileged programs -> using system access software that relies on "privileged ports" -> having privileged programs that write to disk files based on what someone tells them to do -> having programs that rely on complex built-in permissions systems instead of relying on the operating system's built-in permissions People who have been around UNIX security and who have seen (in nauseating profusion) examples of software which is misdesigned from a security standpoint will probably agree that bugs tend to be instances of categories of oversight like the ones I list above. I tend to avoid the kinds of things I list above because I seen folks who are much smarter than I am write insecure software because they ignored these basics. That's one reason why (not to put too fine a point on it) when I looked at the xMosaic code and saw that it used: sprintf(buf,"mv %s %s",oldname,newname); system(buf); to rename files, my heart sank. Not because that's buggy code, but it indicates a lack of awareness of how to program under UNIX that makes me inclined to suspect that the subtler design issues like security weren't handled with any more expertise. >Are you going to disable popen() too? Why not just fix the problem where >it exists instead of disabling every single problem that arises? Pretty >soon we'll be left with nothing, then everyone loses. The problem of "pretty soon we'll be left with nothing" is a real one. The tradeoff is that you've got to decide if your security model is: What we don't know can hurt us. What we don't know doesn't bother us until we know about it. Believe it or not, most of the software people run is built with the latter assumption. It's only when someone spills the beans about there being a hole you can toss a moose through that everyone gets upset. Obviously, we have to work with what we've got, which is why lots of us use stuff that's substandard from a security perspective (hey, we use NFS internally, too). Because you need it to get your job done. The "what we don't know doesn't bother us" approach means that the software security model becomes "penetrate and patch" -- whenever a new bug is found, you install a new version of the software. yeech. Aren't you tired of replacing your version of sendmail?? Vendors certainly are!!! That's why nothing ever gets fixed fast enough. A better approach is to design stuff *right* the first time, and to be able to have a degree of assurance that it won't be able to hurt you. Pretty soon we'll be left with nothing is the problem. There's so much seriously broken code out there that if we threw it all away, most operating systems would be unusable. Throwing it all away's not an option -- but we need to do ANYTHING we can to encourage a shift in mind set away from the "see, it works, it's cool, we'll worry about security later" to "see, it works, it's cool, and here's how it takes advantage of the way your system enforces permissions to ensure that no matter what ugly stuff it does, it can't hurt you." mjr. From firewalls-owner Wed Apr 6 06:08:25 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA01596; Wed, 6 Apr 1994 06:08:25 GMT Received: from panix.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA01589; Tue, 5 Apr 1994 23:08:17 -0700 Received: by panix.com id AA05833 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 6 Apr 1994 00:49:42 -0400 From: John Hawkinson Message-Id: <199404060449.AA05833@panix.com> Subject: Re: system() To: dorian@cobalt.house.gov (Dorian Deane) Date: Wed, 6 Apr 1994 00:49:42 -0400 (EDT) Cc: firewalls@greatcircle.com, mjr@tis.com In-Reply-To: <9404051627.AA03297@cobalt.house.gov> from "Dorian Deane" at Apr 5, 94 09:27:38 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 345 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: Dorian Deane > > I think: > > > > ar d /lib/libc.a system.o > > ranlib /lib/libc.a > > > > will have the same (or perhaps a more salubrious) effect. > > > > mjr. > > > > That _does_ cut to the chase, doesn't it? It would if you also remved any shareable versions... -- John Hawkinson jhawk@panix.com From firewalls-owner Wed Apr 6 17:55:21 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA06418; Wed, 6 Apr 1994 17:55:21 GMT Received: from shadow.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA06412; Wed, 6 Apr 1994 10:55:09 -0700 Received: (cklaus@localhost) by shadow.net (8.6.8.1/jc-1.0) id NAA26521; Wed, 6 Apr 1994 13:56:28 -0400 From: Christopher Klaus Message-Id: <199404061756.NAA26521@shadow.net> Subject: Re: CERT Advisory - wuarchive ftpd Trojan Horse To: firewalls@greatcircle.com, bugtraq@crimelab.com Date: Wed, 6 Apr 94 13:56:27 EDT In-Reply-To: <9404061654.AA02450@clorets.cert.org>; from "CERT Advisory" at Apr 6, 94 12:51 pm X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Yikes. Here is something you might want to take fast action against. I wish CERT would have posted more details though. like how the trojan worked or where it was or what sites contained copy of it. how do i know the newest version 2.3 has no already been modified? > ============================================================================= > CA-94:07 CERT Advisory > April 6, 1994 > wuarchive ftpd Trojan Horse > ----------------------------------------------------------------------------- > > The CERT Coordination Center has received confirmation that some copies > of the source code for the wuarchive FTP daemon (ftpd) were modified by > an intruder, and contain a Trojan horse. > > We strongly recommend that any site running the wuarchive ftpd take steps > to immediately install version 2.3, or disable their FTP daemon. > > ----------------------------------------------------------------------------- > > I. Description > > Some copies of the source code for versions 2.2 and 2.1f of the > wuarchive ftpd were modified by an intruder, and contain a Trojan > horse. If your FTP daemon was compiled from the intruder-modified > source code, you are vulnerable. > > It is possible that previous versions of the source code for the server > were modified in a similar manner. > > If you are running the wuarchive ftpd, but not providing anonymous FTP > access, you are still vulnerable to this Trojan horse. > > > II. Impact > > An intruder can gain root access on a host running an FTP daemon > that contains this Trojan horse. > > > III. Solution > > We strongly recommend that any site running the wuarchive ftpd (version > 2.2 or earlier) take steps to immediately install version 2.3. > > If you cannot install the new version in a timely manner, you should > disable FTP service. It is not sufficient to disable anonymous FTP. > You must disable the FTP daemon. > > Sites can obtain version 2.3 via anonymous FTP from ftp.uu.net, in the > "/networking/ftp/wuarchive-ftpd" directory. We recommend that you turn > off your FTP server until you have installed the new version. > > Be certain to verify the checksum information to confirm that you have > retrieved a valid copy. > > BSD SVR4 > File Checksum Checksum MD5 Digital Signature > ----------------- -------- --------- -------------------------------- > wu-ftpd-2.3.tar.Z 24416 181 30488 361 e58adc5ce0b6eae34f3f2389e9dc9197 > > > --------------------------------------------------------------------------- > The CERT Coordination Center wishes to thank Bryan O'Connor and Chris Myers > of Washington University in St. Louis for their invaluable assistance in > resolving this problem. CERT also gratefully acknowledges the help of > Neil Woods and Karl Strickland. > --------------------------------------------------------------------------- > > If you believe that your system has been compromised, contact the CERT > Coordination Center or your representative in the Forum of Incident > Response and Security Teams (FIRST). > > If you wish to send sensitive incident or vulnerability information to > CERT via electronic mail, CERT strongly advises that the e-mail be encrypted. > CERT can support a shared DES key, PGP (public key available via > anonymous FTP on info.cert.org), or PEM (contact CERT for details). > > 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 via anonymous > FTP from info.cert.org. > > -- Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner 2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)998-5871. From firewalls-owner Wed Apr 6 18:40:35 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA06718; Wed, 6 Apr 1994 18:40:35 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA06711; Wed, 6 Apr 1994 11:40:28 -0700 Message-Id: <199404061840.LAA06711@mycroft.GreatCircle.COM> To: Christopher Klaus Cc: firewalls@greatcircle.com, bugtraq@crimelab.com Subject: Re: CERT Advisory - wuarchive ftpd Trojan Horse In-reply-to: Your message of Wed, 6 Apr 94 13:56:27 EDT Date: Wed, 06 Apr 1994 11:40:27 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Please do NOT cross-post the same message to the Firewalls and BugTraq mailing lists. The lists have two different charters and memberships, with somewhat different (although related) interests. It WAS appropriate to post this message to both lists, but it should have been done as a separate message to each list, so that followups and discussions would stay within each list instead of crossing over between both lists. Folks on both lists, please take care in writing your follow-ups to include only one list in your replies, not both of them. Thanks! -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Wed Apr 6 18:55:16 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA06824; Wed, 6 Apr 1994 18:55:16 GMT Received: from clavin.uprc.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA06818; Wed, 6 Apr 1994 11:55:08 -0700 Received: from cygnus.uprc.com by clavin.uprc.com (4.1/3.2.012693-Union Pacific Resources Company); id AA17371 for firewalls@greatcircle.com; Wed, 6 Apr 94 13:53:09 CDT Received: by cygnus.uprc.com (5.0/SMI-SVR4) id AA01706; Wed, 6 Apr 1994 13:53:08 +0600 Date: Wed, 6 Apr 1994 13:53:08 +0600 From: lacoursj@uprc.com (Jeffrey D. LaCoursiere) Message-Id: <9404061853.AA01706@cygnus.uprc.com> To: firewalls@greatcircle.com Subject: digital pathways X-Sun-Charset: US-ASCII Content-Length: 398 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Anyone else having trouble getting a hold of Digital Pathway's SNK-004 DES keys? My sales guy in Dallas is claiming backlog - I ordered 5 over a month ago and can't seem to get them in. He has since given me his personal key plus 3 others that he dug up from other sales sites near by... Guess my high volume makes me "REALLY HIGH PRORITY" ?? Jeff LaCoursiere Network Admin UPRC Ft. Worth, TX From firewalls-owner Wed Apr 6 19:29:17 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA07133; Wed, 6 Apr 1994 19:29:17 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA07127; Wed, 6 Apr 1994 12:29:10 -0700 Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id MAA11947; Wed, 6 Apr 1994 12:29:02 -0700 Message-Id: <199404061929.MAA11947@mailgate.cadence.com> Received: from mac32_223.cadence.com(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma011931; Wed Apr 6 12:28:17 1994 Date: Wed, 6 Apr 1994 12:28:17 -0800 To: firewalls@GreatCircle.COM, bugtraq@crimelab.com, Christopher Klaus From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: CERT Advisory - wuarchive ftpd Trojan Horse Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 1:56 PM 4/6/94 -0400, Christopher Klaus wrote: >> >Yikes. Here is something you might want to take fast action against. > >I wish CERT would have posted more details though. >like how the trojan worked or where it was or what sites >contained copy of it. how do i know the newest version >2.3 has no already been modified? > Check your source for the string '"NULL"' ie the word NULL in double quotes. We have an older version (2.1a) which appears to be clean. Al --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From firewalls-owner Wed Apr 6 12:31:59 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA07112; Wed, 6 Apr 1994 19:19:30 GMT Received: from cgi.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA07089; Wed, 6 Apr 1994 12:19:09 -0700 Received: by ult4 (5.57/3.1.090690-CGI) id AA06616; Wed, 6 Apr 94 15:16:14 -0400 Message-Id: <9404061916.AA06616@ult4> Date: Wed, 6 Apr 94 15:16:14 EDT X-Mailer: Mail User's Shell (6.5 4/17/89) From: espiritu@cgi.com (Rex Espiritu) To: Christopher Klaus Subject: Re: CERT Advisory - wuarchive ftpd Trojan Horse Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk [In "Re: CERT Advisory - wuarchive ftpd Trojan Horse", on 6 Apr at 13:56, Christopher Klaus writes:] > ... > contained copy of it. how do i know the newest version > 2.3 has no already been modified? > ... How about by verifying the checksum? ... > > Be certain to verify the checksum information to confirm that you have > > retrieved a valid copy. > > > > BSD SVR4 > > File Checksum Checksum MD5 Digital Signature > > ----------------- -------- --------- -------------------------------- > > wu-ftpd-2.3.tar.Z 24416 181 30488 361 e58adc5ce0b6eae34f3f2389e9dc9197 > > ... > > -- > Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner > 2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)998-5871. > From firewalls-owner Wed Apr 6 19:37:27 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA07227; Wed, 6 Apr 1994 19:37:27 GMT Received: from shadow.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA07213; Wed, 6 Apr 1994 12:37:18 -0700 Received: (cklaus@localhost) by shadow.net (8.6.8.1/jc-1.0) id PAA28316 for firewalls@greatcircle.com; Wed, 6 Apr 1994 15:39:01 -0400 From: Christopher Klaus Message-Id: <199404061939.PAA28316@shadow.net> Subject: Wu-ftpd trojan info To: firewalls@greatcircle.com Date: Wed, 6 Apr 94 15:38:59 EDT X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Here is some information that may help you know if you have a trojan version. If your version appears to have a trojan, please e-mail me. the password checking routine in ftpd.c should probably not differ from the following: #ifdef ULTRIX_AUTH if ((numfails = ultrix_check_pass(passwd, xpasswd)) < 0) { #else /* The strcmp does not catch null passwords! */ if (pw == NULL || *pw->pw_passwd == '\0' || strcmp(xpasswd, pw->pw_passwd)) { #endif reply(530, "Login incorrect."); -- Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner 2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)998-5871. From firewalls-owner Wed Apr 6 12:48:44 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA07091; Wed, 6 Apr 1994 19:19:12 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA07078; Wed, 6 Apr 1994 12:18:59 -0700 Message-Id: <199404061918.MAA07078@mycroft.GreatCircle.COM> To: lacoursj@uprc.com (Jeffrey D. LaCoursiere) cc: firewalls@greatcircle.com Subject: Re: digital pathways In-reply-to: Your message of Wed, 6 Apr 1994 13:53:08 +0600 Date: Wed, 06 Apr 1994 12:18:56 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk lacoursj@uprc.com (Jeffrey D. LaCoursiere) writes: # # Anyone else having trouble getting a hold of Digital Pathway's SNK-004 # DES keys? My sales guy in Dallas is claiming backlog - I ordered 5 # over a month ago and can't seem to get them in. He has since given me # his personal key plus 3 others that he dug up from other sales sites # near by... It took me about a month and a half to get mine. I ordered them in February, and got them last week. The units are made overseas (they have a little "Made in China" sticker on them). The telephone order person I talked to implied that deliveries from the factory were somewhat unpredictable. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Wed Apr 6 19:58:51 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA07425; Wed, 6 Apr 1994 19:58:51 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA07419; Wed, 6 Apr 1994 12:58:44 -0700 Received: by relay.tis.com; id AA12951; Wed, 6 Apr 94 15:58:52 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma012934; Wed Apr 6 15:58:21 1994 Received: from sol.tis.com by tis.com (4.1/SUN-5.64) id AA11264; Wed, 6 Apr 94 15:57:34 EDT Message-Id: <9404061957.AA11264@tis.com> From: Frederick M Avolio X-Organization: Trusted Information Systems, Inc. X-Phone: +1 301 854 6889, +1 410 442 1673, FAX: +1 301 854 5363 To: lacoursj@uprc.com (Jeffrey D. LaCoursiere) Cc: firewalls@greatcircle.com Subject: Re: digital pathways In-Reply-To: Your message of Wed, 06 Apr 94 13:53:08 +0600. <9404061853.AA01706@cygnus.uprc.com> Date: Wed, 06 Apr 94 15:57:32 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Well, this is no surprise given the most recent (Feb) Internet attack report, right? Fred From firewalls-owner Wed Apr 6 13:01:44 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA07316; Wed, 6 Apr 1994 19:43:45 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA07306; Wed, 6 Apr 1994 12:43:20 -0700 Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA24861(telemann.inoc.dl.nec.com); Wed, 6 Apr 94 14:43:16 CDT Received: by texas.syl.dl.nec.com (8.6.4/YDL1.9-930614.17) id OAA18591(texas.syl.dl.nec.com); Wed, 6 Apr 1994 14:43:13 -0500 Received: by michigan.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA08038(michigan.syl.dl.nec.com); Wed, 6 Apr 94 14:43:12 CDT From: cornell@syl.dl.nec.com (Cornell Kinderknecht) Message-Id: <9404061943.AA08038@michigan.syl.dl.nec.com> Subject: PC SOCKS Pack - PC clients behind firewall To: firewalls@greatcircle.com Date: Wed, 6 Apr 1994 14:43:11 -0500 (CDT) Cc: cornell@syl.dl.nec.com (Cornell Kinderknecht), ylee@syl.dl.nec.com (Ying-Da Lee) X-Mailer: ELM [version 2.4 PL23beta] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9532 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Announcing the availability of the "PC SOCKS Pack" Version 1.01... The "PC SOCKS Pack" is a collection of Windows network applications that are Winsock 1.1 compliant that have been modified to be SOCKS compliant. They can be run on PCs sitting behind a firewall that have access to a SOCKS 4.0 or above server. The "PC SOCKS Pack" is intended to be dynamic--adding more SOCKSified PC network applications as they become available. Right now it's pretty small and only contains three clients which I've converted. We'd be happy to convert more Winsock compliant applications if source is made available (hint hint). The applications are: FTP-s: This is very nice and is based on John A. Jounod's WS_FTP version 93.12.05. Works pretty slick. FINGER-s: This is based on Lee Murach's Finger 3.1. Pretty self-explanatory and easy to use. TELNET-s: This is real clunky (the SOCKS stuff works great however) and has some bugs. It seems to work OK for most sites that I've tried to connect to but it's not too graceful about timed out connections and other out of the ordinary things. It's based on the NCSA unsupported beta 3 Wintel. Anyone want to offer some nice, well-behaved Telnet source to be converted over to SOCKS?????? You can get the "PC SOCKS Pack" via anonymous ftp from: ftp.nec.com in the directory /pub/security/socks.cstc/PC_Socks_Pack Grab the FILES file to see what's in there. All clients are archived into one zip file. NOTE: The zip files extract into multiple subdirectories so be sure to supply the -d option to PKUNZIP. The top directory of the release has information and detailed instructions for configuring the PC for SOCKS and each subdirectory has a SOCKSified application. Questions and comments about the "PC SOCKS Pack" in general and the SOCKS part of the individual applications can be directed to me. I'm not much help with the original applications although I can probably look at obvious bugs. I've left the user interface and workings of the original applications pretty much untouched from the original. Again, we're looking for source to other Winsock network applications to convert over!! At the end of this message, I'll include the README file from the "PC SOCKS Pack" followed by a blurb describing SOCKS itself for those unfamiliar with it. --- Cornell | Cornell Kinderknecht Email: cornell@syl.dl.nec.com | | CSTC/CNAD | | NEC Systems Lab./NEC USA Phone: 214-518-3509 | | Irving, TX (Dallas) Fax: 214-518-3552 | >>>>>>>>>> Start README file <<<<<<<<<<<< ============================ PC SOCKS Pack - Version 1.01 ============================ File: README Welcome to the PC SOCKS Pack. This is a collection of Windows Sockets client applications that can be used from a PC sitting behind a network firewall that has direct access to a proxy SOCKS server running version 4.0 or above to reach hosts outside the firewall. Presently, there are many packages available in the UNIX environment that are SOCKS compliant and there seems to be a similar need in the PC environment. Currently, there are three applications included in the pack that I've converted (SOCKSified) from other packages found on the net in source form. I hope to add more to the collection. Can anyone point me to the source for other packages? I'd like to find source for a Windows Gopher client real fast. The applications: FINGER-s: A finger application based on Lee Murach's Finger3.1. WINTEL-s: A telnet application based on NCSA's unsupported beta 3 telnet. This application is a bit buggy. WS_FTP-s: An ftp client based on John A. Junod's WS_FTP version 93.12.05. ------------------- 1.0 Where to get it ------------------- If you're reading this file, chances are you already know where to get it but just in case... The PC SOCKS Pack can be downloaded via anonymous ftp from: ftp.nec.com in the directory: /pub/security/socks.cstc/PC_Socks_Pack Get the file "FILES" from that directory to see a description of what's in the directory and what files you need to download. ---------------------- 2.0 About this release ---------------------- The PC SOCKS Pack is distributed as a single ZIP file which extracts into multiple directories (remember to use the -d option for PKUNZIP). The top directory contains general information about the package and instructions for configuring SOCKS on your system. Each subdirectory contains an individual SOCKSified application with specific installation instructions for the application along with files from that package's original release. The SOCKSification of each package only adds the capability to connect to outside networks through a SOCKS server. The original user interface and operation of each package have not been changed from the original author's package. I should mention that if you do not need the SOCKS capabilities, you can still use the applications in this package by setting the SOCKS configuration on your machine so that all connections are direct. However, it's probably best to use the original un-modified applications if you don't need SOCKS. In most cases, I've included a copy of the original executable for convenience and testing purposes. --------------------- 3.0 Priliminary steps --------------------- To see a description of all the files in this distribution, see the "FILES" file in the top directory of this distribution. If you need to know more about SOCKS itself, see the file "WHATSOCK" in the top directory of this distribution. There are some system and software requirements that you must meet in order to use the PC SOCKS Pack. It is important that you read the file "REQUIRES" and verify that all the requirements are met for your system and network. Please read and understand the individual copyrights and permissions for each package. In the top directory, there is a file called "COPYRGHT" that contains the notices and copyrights from all of the applications included in this distribution. See the file "ACKNLGMT" to see the credits for each application. To see what system and software setups that this software has been tested on, see the file "SYSTEMS". I'd like to add your system and software setups to the list if you'd like to email me the information. ------------------- 4.0 Getting started ------------------- To start installing the PC SOCKS Pack, please refer to the file "INSTALL" in the top directory of this distribution. ---------------------- 5.0 SOCKS Mailing List ---------------------- There is a mailing list for SOCKS maintained by the C&C Software Technology Center at NEC Systems Lab. It's primarly a technical discussion group concerning the ongoing development and nurturing of the SOCKS protocol and related software. To join the SOCKS mailing list, send email to: majordomo@syl.dl.nec.com with subscribe socks your@email.address as the first line of the message body. ------------------------- 6.0 PC SOCKS Pack Contact ------------------------- The PC SOCKS Pack was organized and the applications in it were converted for SOCKS compliance by: Cornell Kinderknecht C&C Software Technology Center (CSTC) NEC Systems Laboratory Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies, and that the name of NEC Systems Laboratory not be used in advertising or publicity pertaining to distribution of the document or software without specific, written prior permission. THE SOFTWARE IS PROVIDED ``AS IS'' AND NEC SYSTEMS LABORATORY DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL NEC SYSTEMS LABORATORY BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >>>>>>>>>> Start What_Is_SOCKS.CSTC <<<<<<<<<< What Is SOCKS.CSTC SOCKS belongs to the type generally referred to as proxy servers. Usually when a network firewall is set up to protect hosts inside an organization from attacks that may come from outside through the network, these inside hosts lose their IP-accessibility with the outside world and thus can no longer use things like telnet, ftp, gopher, WWW, etc. to access the vast resources available in the Internet. Proxy servers with their clients restore these functions to the hosts inside the firewall without breaching their security requirements. The original SOCKS was written by David Koblas . The CSTC releases have been mainly the results of work by Ying-Da Lee of C&C Software Technology Center (CSTC), NEC Systems Laboratory, with contributions by many others throughout the world. The current CSTC release is version 4.1. It is known to run on SunOS 4.1.x, Irix 4.0.x, Ultrix 4.3, HP-UX 9.0x, AIX 3.2.x, Interactive Systems Unix, Alpha OSF 1.3, Solaris 2.2, NetBSD 0.9, UnixWare, and Linux 0.99pl13. The SOCKS.CSTC release can be found via anonymous ftp to ftp.nec.com in the directory /pub/security/socks.cstc. The file "FILES" in that directory describes what is contained there. From firewalls-owner Wed Apr 6 20:21:48 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA07577; Wed, 6 Apr 1994 20:21:48 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA07570; Wed, 6 Apr 1994 13:21:42 -0700 Message-Id: <199404062021.NAA07570@mycroft.GreatCircle.COM> To: Frederick M Avolio cc: lacoursj@uprc.com (Jeffrey D. LaCoursiere), firewalls@greatcircle.com Subject: Re: digital pathways In-reply-to: Your message of Wed, 06 Apr 94 15:57:32 -0400 Date: Wed, 06 Apr 1994 13:21:40 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Frederick M Avolio writes: # Well, this is no surprise given the most recent (Feb) Internet attack # report, right? # # Fred I ordered mine before those attacks were widely publicized (before the CERT advisories came out and before the NY Times articles and so forth). Same problem, though it may be worse now. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Wed Apr 6 20:46:42 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA07706; Wed, 6 Apr 1994 20:46:42 GMT Received: from jupiter.hsi.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA07700; Wed, 6 Apr 1994 13:46:32 -0700 Received: from localhost by jupiter.hsi.com with SMTP id AA15170 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 6 Apr 1994 16:45:41 -0400 Message-Id: <199404062045.AA15170@jupiter.hsi.com> To: alastair@cadence.com (Alastair Young) Cc: firewalls@greatcircle.com Subject: Re: CERT Advisory - wuarchive ftpd Trojan Horse In-Reply-To: Your message of "Wed, 06 Apr 94 12:28:17 -0800." <199404061929.MAA11947@mailgate.cadence.com> Date: Wed, 06 Apr 94 16:45:41 -0400 From: "Justus J. Addiss (addiss@hsi.com) 203-949-6414" X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> At 1:56 PM 4/6/94 -0400, Christopher Klaus wrote: >> >> >> >Yikes. Here is something you might want to take fast action against. >> > >> >I wish CERT would have posted more details though. >> >like how the trojan worked or where it was or what sites >> >contained copy of it. how do i know the newest version >> >2.3 has no already been modified? >> > >> >> Check your source for the string '"NULL"' ie the word NULL in double quotes. >> >> We have an older version (2.1a) which appears to be clean. >> Does "NULL" mean you're clean or dirty? How about NULL (no quotes around it)? From firewalls-owner Wed Apr 6 13:58:48 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA07746; Wed, 6 Apr 1994 20:51:13 GMT Received: from colossus.cse.psu.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA07740; Wed, 6 Apr 1994 13:51:03 -0700 Received: from localhost by colossus.cse.psu.edu with SMTP id <37724>; Wed, 6 Apr 1994 16:50:36 -0400 To: Christopher Klaus cc: firewalls@greatcircle.com Subject: Re: Wu-ftpd trojan info X-Work-Address: Department of Computer Science, 121A Pond Laboratory The Pennsylvania State University, University Park, PA 16802 X-Work-Phone: +1 814 863 1142 (Voice) +1 814 865 3176 (FAX) In-reply-to: Your message of Wed, 06 Apr 1994 15:38:59 EDT. <199404061939.PAA28316@shadow.net> X-Mailer: exmh version 1.3delta 3/31/94 Date: Wed, 6 Apr 1994 16:50:19 -0400 From: Daniel R Ehrlich Message-Id: <94Apr6.165036edt.37724@colossus.cse.psu.edu> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > >Here is some information that may help you know if you have a trojan >version. If your version appears to have a trojan, please e-mail me. > >the password checking routine in ftpd.c should probably not differ >from the following: > >#ifdef ULTRIX_AUTH > if ((numfails = ultrix_check_pass(passwd, xpasswd)) < 0) { >#else > /* The strcmp does not catch null passwords! */ > if (pw == NULL || *pw->pw_passwd == '\0' || > strcmp(xpasswd, pw->pw_passwd)) { >#endif > reply(530, "Login incorrect."); > > >-- >Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner >2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)998-5871. > Which module is the password checking routine in? Dan Ehrlich - Systems Analyst - PSU Computer Science and Engineering "Universities should be safe havens where ruthless examination of realities will not be distorted by the aim to please or inhibited by the risk of displeasure." - Kingman Brewster echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc From firewalls-owner Wed Apr 6 14:08:43 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA07763; Wed, 6 Apr 1994 20:52:30 GMT Received: from bwh.harvard.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA07749; Wed, 6 Apr 1994 13:52:13 -0700 Received: from bwface.bwh.harvard.edu (bwface.bwh.harvard.edu [134.174.81.42]) by bwh.harvard.edu (8.6.4/8.6.4) with ESMTP id QAA06876; Wed, 6 Apr 1994 16:36:16 -0400 From: Adam Shostack Received: from localhost (adam@localhost) by bwface.bwh.harvard.edu (8.6.4/8.6.4) id QAA26879; Wed, 6 Apr 1994 16:36:16 -0400 Message-Id: <199404062036.QAA26879@bwface.bwh.harvard.edu> Subject: Re: system() To: mjr@tis.com (Marcus J Ranum) Date: Wed, 6 Apr 94 16:36:15 EDT Cc: firewalls@greatcircle.com In-Reply-To: <9404060224.AA27083@otter.tis.com>; from "Marcus J Ranum" at Apr 5, 94 10:24 pm Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Marcus wrote: | Pretty soon we'll be left with nothing is the problem. | There's so much seriously broken code out there that if we | threw it all away, most operating systems would be unusable. | Throwing it all away's not an option -- but we need to do ANYTHING | we can to encourage a shift in mind set away from the "see, it | works, it's cool, we'll worry about security later" to "see, | it works, it's cool, and here's how it takes advantage of | the way your system enforces permissions to ensure that no | matter what ugly stuff it does, it can't hurt you." On this note, its important to tell your salespeople that the insecurity of their software is a problem. If you're in a position to, try to hold up, or slow down their sales because of security issues. Let them know that you want new versions of the OS to be patched up, not reintroduce the old security holes. When vendors start to hear that people want more secure software, they will think about the possibility of attempting to ship it. They sure aren't going to ship secure software if none of their customers are asking for it. More people are becoming aware of the problem, but we need to communicate our awareness to vendors, and let them know that the market wants systems to ship securely. Adam -- Adam Shostack adam@bwh.harvard.edu Politics. From the greek "poly," meaning many, and ticks, a small, annoying bloodsucker. Have you signed the anti-Clipper petition? From firewalls-owner Wed Apr 6 21:12:42 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA07986; Wed, 6 Apr 1994 21:12:42 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA07979; Wed, 6 Apr 1994 14:12:33 -0700 Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id OAA17554; Wed, 6 Apr 1994 14:12:07 -0700 Message-Id: <199404062112.OAA17554@mailgate.cadence.com> Received: from mac32_223.cadence.com(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma017519; Wed Apr 6 14:11:37 1994 Date: Wed, 6 Apr 1994 14:11:37 -0800 To: "Justus J. Addiss (addiss@hsi.com) 203-949-6414" From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: CERT Advisory - wuarchive ftpd Trojan Horse Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 4:45 PM 4/6/94 -0400, Justus J. Addiss (addiss@hsi.com) 203-949-6414 wrote: >>> At 1:56 PM 4/6/94 -0400, Christopher Klaus wrote: >>> >> >>> >Yikes. Here is something you might want to take fast action against. >>> > >>> >I wish CERT would have posted more details though. >>> >like how the trojan worked or where it was or what sites >>> >contained copy of it. how do i know the newest version >>> >2.3 has no already been modified? >>> > >>> >>> Check your source for the string '"NULL"' ie the word NULL in double quotes. >>> >>> We have an older version (2.1a) which appears to be clean. >>> > >Does "NULL" mean you're clean or dirty? How about NULL (no quotes around >it)? NULL with quotes around means you are dirty. This appears in the bit of code that Christopher Klaus just posted. You could probably do a strings on your binaries and grep for NULL as a double check. Can't verify that this'll work but its worth a try. Certainly if the grep comes up with anything then you've been done. Al --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From firewalls-owner Wed Apr 6 16:38:44 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA08699; Wed, 6 Apr 1994 23:27:24 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA08693; Wed, 6 Apr 1994 16:27:16 -0700 Received: by relay.tis.com; id AA14578; Wed, 6 Apr 94 19:27:21 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma014575; Wed Apr 6 19:27:14 1994 Received: from sol.tis.com by tis.com (4.1/SUN-5.64) id AA21614; Wed, 6 Apr 94 19:26:26 EDT Message-Id: <9404062326.AA21614@tis.com> From: Frederick M Avolio X-Organization: Trusted Information Systems, Inc. X-Phone: +1 301 854 6889, +1 410 442 1673, FAX: +1 301 854 5363 To: Adam Shostack Cc: mjr@tis.com (Marcus J Ranum), firewalls@greatcircle.com Subject: Re: system() In-Reply-To: Your message of Wed, 06 Apr 94 16:36:15 -0400. <199404062036.QAA26879@bwface.bwh.harvard.edu> Date: Wed, 06 Apr 94 19:26:25 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Like John the Baptist, we are voices crying out in the wilderness. Okay, not much like the Baptist, but my point is, in reaction to the enclosed (which I agree with), the majority of folks want what's cool. What's Jazzy. I have given myself a pain in the neck and a headache trying to cool just a couple of folks off about Mosaic. But it's sooooo neat. Work faster, security trolls. They're listening out there :-) Fred > Marcus wrote: > > | Pretty soon we'll be left with nothing is the problem. > | There's so much seriously broken code out there that if we > | threw it all away, most operating systems would be unusable. > | Throwing it all away's not an option -- but we need to do ANYTHING > | we can to encourage a shift in mind set away from the "see, it > | works, it's cool, we'll worry about security later" to "see, > | it works, it's cool, and here's how it takes advantage of > | the way your system enforces permissions to ensure that no > | matter what ugly stuff it does, it can't hurt you." > > On this note, its important to tell your salespeople that the > insecurity of their software is a problem. If you're in a position > to, try to hold up, or slow down their sales because of security > issues. Let them know that you want new versions of the OS to be > patched up, not reintroduce the old security holes. > > When vendors start to hear that people want more secure > software, they will think about the possibility of attempting to ship > it. They sure aren't going to ship secure software if none of their > customers are asking for it. > > More people are becoming aware of the problem, but we need to > communicate our awareness to vendors, and let them know that the > market wants systems to ship securely. > > Adam > > > -- > Adam Shostack adam@bwh.harvard.edu > > Politics. From the greek "poly," meaning many, and ticks, a small, > annoying bloodsucker. > > Have you signed the anti-Clipper petition? From firewalls-owner Thu Apr 7 00:29:14 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA09013; Thu, 7 Apr 1994 00:29:14 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA09007; Wed, 6 Apr 1994 17:29:07 -0700 Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id RAA28264 for ; Wed, 6 Apr 1994 17:29:08 -0700 Message-Id: <199404070029.RAA28264@mailgate.cadence.com> Received: from mac32_223.cadence.com(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma028233; Wed Apr 6 17:28:25 1994 Date: Wed, 6 Apr 1994 17:28:26 -0800 To: firewalls@greatcircle.com From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: X proxies Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk What can anyone tell me about X-windows proxies? What where and how? I already know the "why not?" :-) Al --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From firewalls-owner Thu Apr 7 04:59:10 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA09915; Thu, 7 Apr 1994 04:59:10 GMT Received: from turtle.mrj.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA09909; Wed, 6 Apr 1994 21:58:56 -0700 Received: from newt.mrj.com (newt.mrj.com [192.101.175.69]) by turtle.mrj.com (8.6.4/8.6.4) with ESMTP id AAA11997 for ; Thu, 7 Apr 1994 00:58:50 -0400 Received: from localhost (kmayer@localhost) by newt.mrj.com (8.6.4/8.6.4) id AAA19256; Thu, 7 Apr 1994 00:58:49 -0400 Date: Thu, 7 Apr 1994 00:58:48 -0400 (EDT) From: Ken Mayer Subject: Re: system() To: Firewalls@GreatCircle.COM In-Reply-To: <199404050800.BAA05126@mycroft.GreatCircle.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>someone should write a safe_system() to replace such calls with, that does >It'd be AI-complete. How do you know what's dangerous & what's not? >I'd rather not have people thinking safe_system() is safe when it >really isn't. Back in February in comp.security.unix, someone posted msh.c, a minimal shell program that recognizes I/O redirection but ignores any other shell metacharacters. Not exactly what was asked for, but a step in the right direction... Article 2706 of comp.security.unix: Path: turtle.mrj.com!uunet!s850.mwc.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!EU.net!sun4nl!news.nic.surfnet.nl!tuegate.tue.nl!news.win.tue.nl!wzv.win.tue.nl!wzv.win.tue.nl!not-for-mail From: wietse@wzv.win.tue.nl (Wietse Venema) Newsgroups: nasa.infosystems.www,comp.infosystems.www,larc.users.mosaic,comp.security.unix Subject: Re: Be Careful!! Common security vulnerability w/Fill out forms... Date: 21 Feb 1994 19:30:12 +0100 Organization: Eindhoven University of Technology, The Netherlands Lines: 174 Message-ID: <2kaujk$7df@wzv.win.tue.nl> References: NNTP-Posting-Host: wzv.win.tue.nl Xref: turtle.mrj.com comp.infosystems.www:7232 comp.security.unix:2706 bianco@MiSTy.larc.nasa.gov (David Bianco) writes: >What if you set the DISPLAY to: > > dew.cs.odu.edu:0.0 `xterm -display dew.cs.odu.edu:0.0` That's why we run gopher, www etc. inside a jail (a restricted file system subtree and "nobody" privilege), with only a minimal shell. Wietse /* * sh.c - Minimal shell, for use with popen(3) or system(3) only. Recognizes * I/O redirection, but rejects commands with any other shell metacharacters. * * Wietse Venema (wswietse@win.tue.nl) 921013: initial version without any * shell metacharacter support. * * Wietse Venema (wswietse@win.tue.nl) 921014: added <, > and >> because * gopherd needs redirection. */ /* Library stuff */ #include #include extern char *malloc(); /* Local stuff */ static int parse(); static char *strndup(); static char *special(); static char *redirect(); /* Character classification stuff. */ static char metach[] = "$[]<>*?&^|`;{}()'\"\\"; static char blnks[] = " \t\r\n"; static char meta_or_blnks[] = " \t\r\n$[]<>*?&^|`;{}()'\"\\"; static char *myname; /* for diagnostics */ main(argc, argv) int argc; char **argv; { char *args[BUFSIZ]; /* generated command-line vector */ /* Allow the form "sh -c command" only. */ myname = argv[0]; if (argc != 3 || strcmp(argv[1], "-c") != 0) { fprintf(stderr, "usage: %s -c 'command'\n", myname); exit(1); } /* Convert argv[2] to command-line vector. */ if (parse(argv[2], args, BUFSIZ) == 0) { fprintf(stderr, "%s: empty command\n", myname); exit(1); } /* Run the command or give up. */ execvp(args[0], args); perror(args[0]); exit(1); } /* parse - build argument vector */ static int parse(src, args, maxarg) char *src; char **args; int maxarg; { int argno = 0; int len; while (*src) { /* Sanity check. */ if (argno >= maxarg - 1) { fprintf(stderr, "%s: too many arguments\n", myname); exit(1); } /* Skip leading whitespace. */ src += strspn(src, blnks); /* Process next token. */ if (strchr(metach, *src)) { /* special */ src = special(src); } else { /* regular word */ len = strcspn(src, meta_or_blnks); args[argno++] = strndup(src, len); src += len; } } args[argno] = 0; return (argno); } /* special - handle operators etc. */ static char *special(src) char *src; { switch (*src) { case '>': if (src[1] == '>') { return (redirect(src + 2, stdout, "a")); } else { return (redirect(src + 1, stdout, "w")); } /* NOTREACHED */ case '<': return (redirect(src + 1, stdin, "r")); default: fprintf(stderr, "%s: unsupported operator: ``%c''\n", myname, *src); exit(1); /* NOTREACHED */ } } /* redirect - redirect input/output from/to file */ static char *redirect(src, strm, mode) char *src; FILE *strm; char *mode; { char *path; int len; /* Skip whitespace. */ src += strspn(src, blnks); /* Next token should be regular word. */ if ((len = strcspn(src, meta_or_blnks)) == 0) { fprintf(stderr, "%s: filename expected, got: %s\n", myname, src); exit(1); } path = strndup(src, len); src += len; /* Redirect or bust. */ if (freopen(path, mode, strm) == 0) { perror(path); exit(1); } return (src); } /* strndup - make copy of string */ static char *strndup(str, len) char *str; int len; { char *dst; if ((dst = malloc(len + 1)) == 0) fprintf(stderr, "%s: out of memory\n", myname); dst[len] = 0; return (strncpy(dst, str, len)); } -- Ken Mayer kmayer@mrj.com From firewalls-owner Thu Apr 7 05:18:35 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA09993; Thu, 7 Apr 1994 05:18:35 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA09987; Wed, 6 Apr 1994 22:18:27 -0700 Received: by tadpole.tadpole.com (4.1/SMI-4.1-jim) id AA08568; Thu, 7 Apr 94 00:17:54 CDT Date: Thu, 7 Apr 94 00:17:54 CDT From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9404070517.AA08568@tadpole.tadpole.com> To: Firewalls@GreatCircle.COM, kmayer@mrj.com Subject: Re: system() Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I don't know if I'd trust anything that tromps through what could be a NULL pointer. In this case, 'dst' could be NULL (if malloc fails), and the program would print the warning, then dump core (unless run on a little-endian machine, say, a VAX.) Jim /* strndup - make copy of string */ static char *strndup(str, len) char *str; int len; { char *dst; if ((dst = malloc(len + 1)) == 0) fprintf(stderr, "%s: out of memory\n", myname); dst[len] = 0; return (strncpy(dst, str, len)); } From firewalls-owner Thu Apr 7 13:16:01 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA11886; Thu, 7 Apr 1994 13:16:01 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA11880; Thu, 7 Apr 1994 06:15:53 -0700 Received: from ozone.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA11727; Thu, 7 Apr 94 09:11:35 -0400 Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/3.2.083191-) id AA21820; Thu, 7 Apr 1994 09:00:14 -0400 Date: Thu, 7 Apr 1994 09:00:14 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9404071300.AA21820@oxygen.house.gov> To: firewalls@GreatCircle.COM Subject: Re: system() -> Mosaic Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: Frederick M Avolio > ... the majority of folks want what's cool. > What's Jazzy. I have given myself a pain in the neck and a headache > trying to cool just a couple of folks off about Mosaic. > > But it's sooooo neat. > > Work faster, security trolls. They're listening out there :-) I prefer to read, and I prefer technical information ("I like to watch" [from Being There, the great film] :-) but I am provoked to respond to the direction this thread is taking. The goal of firewallers is to enable the most widespread access for the emerging technology enabled mostly by the Internet. Mosaic is one client of the Internet development of the World Wide Web (WWW) of information that epitomizes the future of the Internet (and NII). The ONLY solution is to work with the people who are developing these GREAT applications to help them avoid security problems. Resisting technological (and maybe even social) advances has been the biggest mistake people really interested in network security have made. Remember that security is the last bastion for reactionary managers trying to maintain the status quo. The originators of WWW at CERN, and the crafty people at UIUC have expressed interest in making HTTP secure enough to enable its greatest penetration. Help them with technology. Do not disparage their products. (Isn't "nii" a laugh line from a Monty Python film :-) Send flames to me only, not this mailing list. From firewalls-owner Thu Apr 7 13:51:04 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA12047; Thu, 7 Apr 1994 13:51:04 GMT Received: from MRICD1.APGEA.ARMY.MIL by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA12040; Thu, 7 Apr 1994 06:50:57 -0700 Message-Id: <199404071350.GAA12040@mycroft.GreatCircle.COM> Date: Thu, 7 Apr 1994 09:50:25 -0400 From: nicholson_jd@mricd1.apgea.army.mil (Jim Nicholson) To: firewalls@GreatCircle.com Subject: Test X-VMS-To: SMTP%"firewalls@GreatCircle.com" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Test... None of my postings have gone thru before. From firewalls-owner Thu Apr 7 15:14:19 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA12349; Thu, 7 Apr 1994 15:14:19 GMT Received: from chenas.inria.fr by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA12343; Thu, 7 Apr 1994 08:14:11 -0700 Received: from edf.edf.fr by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA01454; Thu, 7 Apr 1994 17:14:04 +0200 (MET) Received: from cli55ca.der.edf.fr by edf.edf.fr with SMTP id AA17295 (5.65c8/IDA-1.4.4 for ); Thu, 7 Apr 1994 17:14:07 +0200 Received: by cli55ca.der.edf.fr (4.1/SMI-4.1) id AA11817; Thu, 7 Apr 94 17:13:37 +0200 Date: Thu, 7 Apr 94 17:13:37 +0200 From: Yves.Dherbecourt@der.edf.fr (Yves Dherbecourt) Message-Id: <9404071513.AA11817@cli55ca.der.edf.fr> To: firewalls@greatcircle.com Subject: X3270 through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Did somebody get X3270 work through a firewall WITH authentication set on this firewall ? and How ? X3270 works on the telnet port, but it doesn't seem fair enough to handle properly the authentication dialog with the firewall before launching the real X3270 session. (Tn3270 does). #----------------------------------------------------------------------------# # Yves Dherbecourt | Tel : (1) 47 65 37 90 # # Electricite de France | Fax : (1) 47 65 35 23 # # DER / IMA / ICI / ASR | Tlx : 631576 # # 1, avenue du General de Gaulle | # # 92141 CLAMART Cedex | Email : Yves.Dherbecourt@der.edf.fr # # France | # #----------------------------------------------------------------------------# From firewalls-owner Thu Apr 7 16:27:19 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA12828; Thu, 7 Apr 1994 16:27:19 GMT Received: from george.arc.nasa.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA12822; Thu, 7 Apr 1994 09:27:12 -0700 Received: from localhost.arc.nasa.gov by george.arc.nasa.gov (8.6.8/1.35) id JAA18374; Thu, 7 Apr 1994 09:27:11 -0700 Message-Id: <199404071627.JAA18374@george.arc.nasa.gov> To: firewalls@greatcircle.com Subject: Routers, filters and thanks Date: Thu, 07 Apr 1994 09:27:11 -0700 From: "Rob Tanner" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk First of all, thank you to everyone who responded to my query a couple of weeks ago regarding best choices for screening routers. By a hefty margin, the two most popular choices were Karlbridge and Morning Star. The one question I have has to do with how filtering is done in the router. Karlbridge contrasts bit pattern filters as used by other router manufacturers with the algorithm based filter in the Karlbridge. Naturally, they claim theirs is better. It is, according to the documents I picked up, easier to configure and less limited in scope then other filtering strategies. Basically, what is the difference and why would one router filtering strategy be better then the other? Thanks. -- Rob Tanner NASA Ames Research Center tanner@george.arc.nasa.gov From firewalls-owner Thu Apr 7 17:38:00 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA13052; Thu, 7 Apr 1994 17:38:00 GMT Received: from gw1.att.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA13046; Thu, 7 Apr 1994 10:37:52 -0700 From: joe@clipper.cb.att.com Received: by emsr0.emsr.att.com (4.1/EMS main.cf 1.33 7/21/93 (SMI-4.1/SVR4)) id AA17678; Thu, 7 Apr 94 13:38:34 EDT Received: from clipper.cb.att.com by emsr0.emsr.att.com (4.1/EMS main.cf 1.33 7/21/93 (SMI-4.1/SVR4)) id AA17674; Thu, 7 Apr 94 13:38:32 EDT Received: by clipper.cb.att.com (4.1/EMS-1.1 main.cf 1/8/94 (SMI-4.1/SVR4)) id AA05296; Thu, 7 Apr 94 13:40:04 EDT Received: from cbjoe.cb.att.com by clipper.cb.att.com (4.1/EMS-1.1 main.cf 1/8/94 (SMI-4.1/SVR4)) id AA05292; Thu, 7 Apr 94 13:40:03 EDT Date: Thu, 7 Apr 94 13:40:03 EDT Message-Id: <9404071740.AA05292@clipper.cb.att.com> To: firewalls@GreatCircle.com Subject: Re: digital pathways X-Sun-Charset: US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We've been using them here (att.com) for years. We have an open Purchase Order with them ... and usually get boxes of 20 or so at a time. I don't remember them taking more than a couple weeks to a month. - joe > lacoursj@uprc.com (Jeffrey D. LaCoursiere) writes: > > # > # Anyone else having trouble getting a hold of Digital Pathway's SNK-004 > # DES keys? My sales guy in Dallas is claiming backlog - I ordered 5 > # over a month ago and can't seem to get them in. He has since given me > # his personal key plus 3 others that he dug up from other sales sites > # near by... > > It took me about a month and a half to get mine. I ordered them in > February, and got them last week. > > The units are made overseas (they have a little "Made in China" > sticker on them). The telephone order person I talked to implied that > deliveries from the factory were somewhat unpredictable. > > > -Brent > -- > Brent Chapman | Great Circle Associates | Call or email for info about > Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security > +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates > From firewalls-owner Thu Apr 7 17:45:53 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA13086; Thu, 7 Apr 1994 17:45:53 GMT Received: from Relay.CV.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA13080; Thu, 7 Apr 1994 10:45:46 -0700 Message-Id: <199404071745.KAA13080@mycroft.GreatCircle.COM> Received: from bdso.cv.com by Relay.CV.COM; 07 Apr 94 13:43:20 EST Received: (from user CHIP.S) by bdso.cv.com; 07 Apr 94 13:43:19 EST Received: (from user CHIP using PRIMAILPLUS Version 2.6.3) Subject: What?? To: firewalls@greatcircle.com From: Chip Seymour Date: Thu, 07 Apr 1994 13:43:16 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Would someone fill me in on the Digital Pathways DES keys thing? I'm in the dark. What are they, and why are they so popular? chip From firewalls-owner Fri Apr 8 02:38:36 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA15266; Fri, 8 Apr 1994 02:38:36 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA15260; Thu, 7 Apr 1994 19:38:29 -0700 Received: by relay.tis.com; id AA22021; Thu, 7 Apr 94 22:38:37 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma022018; Thu Apr 7 22:37:51 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA09353; Thu, 7 Apr 94 22:36:58 EDT From: Marcus J Ranum Received: by otter.tis.com (4.1/SMI-4.1) id AA29560; Thu, 7 Apr 94 22:36:57 EDT Date: Thu, 7 Apr 94 22:36:57 EDT Message-Id: <9404080236.AA29560@otter.tis.com> To: CHIP@bdso.cv.com, firewalls@GreatCircle.COM Subject: Re: What?? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Would someone fill me in on the Digital Pathways DES keys thing? >I'm in the dark. What are they, and why are they so popular? It's a handheld cryptographic authentication calculator. They cost ~$55 in quantity. They contain a replaceable (hot swap) battery that keeps a DES key in memory all the time. The admin programs the key into it -- so you don't rely on someone else to key your authentication device. It's fairly solid, not especially attractive, but it uses an algorithm someone published a few years back, that's easy to implement in software, so you can avoid host-software licensing, portability, and availability issues. It's one of the authentication devices the TIS firewall toolkit supports -- we have a server-side implementation that requires no additional software, so you can just buy 'em and key 'em and issue 'em to users. mjr. From firewalls-owner Thu Apr 7 22:29:47 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA15811; Fri, 8 Apr 1994 05:25:28 GMT Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA15794; Fri, 8 Apr 1994 05:25:19 GMT Date: Fri, 8 Apr 1994 05:25:19 GMT Message-Id: <199404080525.FAA15794@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.com From: Majordomo@GreatCircle.COM Subject: Welcome to firewalls Reply-To: Majordomo@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk -- Welcome to the firewalls mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "Majordomo@GreatCircle.COM": unsubscribe firewalls firewalls@GreatCircle.com Here's the general information for the list you've subscribed to, in case you don't already have it: Description =========== This list is for discussions of Internet "firewall" security systems and related issues. It is an outgrowth of the Firewalls BOF session at the Third UNIX Security Symposium in Baltimore on September 15, 1992. This is the undigestified version of the list. All messages sent to this list are immediately forwarded to members of the list. The digestified version of the list is Firewalls-Digest@GreatCircle.COM. Policies ======== Code for cracking programs (programs designed to help break into another system) should not be posted to the Firewalls mailing list. You can subscribe a local redistribution list or a gateway to a local newsgroup, as long as whatever you do is local to your site. This restriction makes it much easier for me to track down mailer problems. I'm very aggressive when it comes to bounced email. If email to you starts bouncing, I'll probably drop you from the list fairly quickly; you'll have to resubscribe when you get the problem fixed, and retrieve the archives to find out what you missed. Archives ======== All messages to the list are archived. The archives are available via Majordomo using the "get" command (send "help" in the body of a message to "Majordomo@GreatCircle.COM" for more info), or via anonymous FTP from host FTP.GreatCircle.COM in directory "pub/firewalls/archive". The archives are broken down by year and month, and are stored in files named "firewalls.YYMM". The copy of the archive available by anonymous FTP is updated every night at 2am local time (0900 GMT in the summer, 1000 GMT in the winter). For further information, contact: 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 8 05:56:22 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA16018; Fri, 8 Apr 1994 05:56:22 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA16011; Thu, 7 Apr 1994 22:56:16 -0700 Message-Id: <199404080556.WAA16011@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.com Subject: Re: Welcome to firewalls In-reply-to: Your message of Fri, 8 Apr 1994 05:25:19 GMT Date: Thu, 07 Apr 1994 22:56:15 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Majordomo@GreatCircle.COM writes: # -- # # Welcome to the firewalls mailing list! # # If you ever want to remove yourself from this mailing list, send the # following command in email to "Majordomo@GreatCircle.COM": # # unsubscribe firewalls firewalls@GreatCircle.com # Again?! Nuts! Sorry about that, gang, I accidentally approved a request to subscribe the list to itself again.. I've fixed it already. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Fri Apr 8 18:21:52 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA20402; Fri, 8 Apr 1994 18:21:52 GMT Received: from hac2arpa.hac.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA20396; Fri, 8 Apr 1994 11:21:33 -0700 Received: from GSGMVS.EMIS.HAC.COM ([192.27.11.11]) by hac2arpa.hac.com (4.1/SMI-DDN) id AA14308; Fri, 8 Apr 94 11:20:22 PDT Received: from CCMAIL.EMIS.HAC.COM by GSGMVS.EMIS.HAC.COM (Soft-Switch Central V4L380P3); 08 Apr 1994 11:13:11 GMT Message-Id: Date: 08 Apr 1994 11:13:11 GMT From: "Ronald A Martin" <0066169@CCMAIL.EMIS.hac.com> Subject: Re[2]: What?? To: firewalls@GreatCircle.COM Comment: MEMO 1994/04/08 11:19 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Would someone fill me in on the Digital Pathways DES keys thing? >I'm in the dark. What are they, and why are they so popular? ) It's a handheld cryptographic authentication calculator. They cost )~$55 in quantity. They contain a replaceable (hot swap) battery that keeps a )DES key in memory all the time. The admin programs the key into it -- so you )don't rely on someone else to key your authentication device. ) It's fairly solid, not especially attractive, but it uses an algorithm )someone published a few years back, that's easy to implement in software, so )you can avoid host-software licensing, portability, and availability issues. ) It's one of the authentication devices the TIS firewall toolkit )supports -- we have a server-side implementation that requires no additional )software, so you can just buy 'em and key 'em and issue 'em to users. )mjr. Digital Pathways also offers a client SSNK (Software Secure Net Key) for DOS and Mac OSs (I believe they're working on a UNIX client). It's a more convenient implmentation of the cryptographic authentication calculator (SNK) if you tend to loose or forget the calculator hardware. Ron Martin Hughes Aircraft From firewalls-owner Fri Apr 8 19:16:57 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA20732; Fri, 8 Apr 1994 19:16:57 GMT Received: from iphase.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA20725; Fri, 8 Apr 1994 12:16:36 -0700 Received: from chip.iphase.com by iphase.com (4.1/1.34) id AA25464; Fri, 8 Apr 94 14:15:06 CDT Received: by chip.iphase.com (4.1/SMI-4.1) id AA21237; Fri, 8 Apr 94 14:15:05 CDT Date: Fri, 8 Apr 94 14:15:05 CDT From: plarkin@iphase.com (Patrick Larkin Jr) Message-Id: <9404081915.AA21237@chip.iphase.com> To: firewalls@greatcircle.com Subject: Minimalist 'telnet' wanted (was: Mixing Authentification Strategies) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In article <9404010220.AA17569@otter.tis.com>, uunet!tis.com!mjr (Marcus J Ranum) writes: > You might want to consider > doing something like our login-shell hack, where the person's login > shell is a challenge/response application that exits if they can't > authenticate, and that pastes up their environment and executes the > real login shell if they do. [yes -- this approach has advantages > and disadvantages] I wish to do something similar, but It would require a special telnet client. We want remote users to connect to a special host which runs an 'athentication shell' and if he/she is able to authenticate, then the system would ask them for the name of the internal host they want to connect to (nobody should have an interactive account on the 'gate' host). I am looking for a telnet client replacement that would allow US to set the modes and communication parameters and not accept the ^] escape. This way users could only connect to hosts/ports that we have defined as 'OK' and also allow us to force a 'raw' mode so such thinks as BREAK, Control codes and Escapes get passed safely thru to the target for such things as PC (ugh) file transfers. Any ideas on such a thing? (Please mail me direct and I'll post if there's enuff interest.) Thanks, -- ////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ |\| PATRICK LARKIN - System Administrator |\| |/| #include /* Interphase Corporation */ |/| |\| #include "clever_quote_de_jour.h" /* Dallas TX - USA */ |\| From firewalls-owner Fri Apr 8 19:29:26 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA20806; Fri, 8 Apr 1994 19:29:26 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA20799; Fri, 8 Apr 1994 12:29:02 -0700 Received: from nscultrix2.network.com by nsco.network.com (5.61/1.34) id AA02733; Fri, 8 Apr 94 14:32:18 -0500 Received: by nscultrix2.network.com (5.57/Ultrix3.0-C) id AA29052; Fri, 8 Apr 94 14:28:35 CDT Date: Fri, 8 Apr 94 14:28:35 CDT From: dotytr@nscultrix2.network.com (Ted Doty) Message-Id: <9404081928.AA29052@nscultrix2.network.com> To: firewalls@greatcircle.com, johns@oxygen.house.gov Subject: Re: system() -> Mosaic Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: johns@oxygen.house.gov (John Schnizlein) > The goal of firewallers is to enable the most widespread access for the > emerging technology enabled mostly by the Internet. > Mosaic is one client of the Internet development of the World Wide Web (WWW) > of information that epitomizes the future of the Internet (and NII). > The ONLY solution is to work with the people who are developing these GREAT > applications to help them avoid security problems. > Resisting technological (and maybe even social) advances has been the biggest > mistake people really interested in network security have made. > Remember that security is the last bastion for reactionary managers trying > to maintain the status quo. I remember Dave Clark at Interop 90 pounding the podium and doing his very best Kruschev impersonation, saying that the 1990s was going to be the "decade of the great unplugging" because of highly publicised security breaches. I can't think of anyone who would accuse him of being reactionary and trying to maintain the status quo. We ALL want to "enable the most widespread access" for people in our organizations (no, I am neither a manager nor a reactionary). The fact of the matter is that some people are PAID to ensure (try to ensure?) that the crown jewels aren't stolen. One thing I have found particularly humerous is that the two biggest threads on this list lately have been "Software is grotesquely buggy and the damn vendors better do something about it" and "What's the cheapest screaning router around?". Vendors aren't able to do anything if people aren't willing to pay for product. This, unfortunately, is a classic security related problem (hey, anybody ever made any money off a NSCS-certified operating system?). - Ted -------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Road, Suite 250 | fax: +1 410 381-3320 Columbia, MD, 21046 USA | voice mail: (800) 233-1485 -------------------------------------------------------------------------- if (setsockopt(sockfd, SOL_SOCKET, STD_DISCLAIMER, (char *), &sendbuff, &optlen) < 0) printf ("Standard Disclaimers Apply ...\n"); From firewalls-owner Fri Apr 8 22:37:49 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA21637; Fri, 8 Apr 1994 22:37:49 GMT Received: from ftp.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA21624; Fri, 8 Apr 1994 15:37:40 -0700 Received: by ftp.com ; Fri, 8 Apr 1994 18:37:41 -0400 Received: by ftp.com ; Fri, 8 Apr 1994 18:37:41 -0400 Date: Fri, 8 Apr 1994 18:37:41 -0400 From: hobbit@ftp.com (*Hobbit*) Message-Id: <9404082237.AA27596@ftp.com> To: firewalls@greatcircle.com Subject: unplugging... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk No need. What's so hard about providing all these swoopy services on a machine located just *outside* your firewall, with a completely expendable OS and utilities that can be restored from tape in a couple of hours, and doing all your real work [including generating the master tree for your swoopy-server] behind the wall? Said machine will continue supplying swoopy services even if it's cracked, until the crackers manage to completely destroy it, after which you slap a tape on and restore it to its known configuration [maybe with some more holes plugged]. It also gives you a "target" that you can carefully watch for weird activity against, if you want to spent the time trapping perpetrators. A warning to all callers that things they obtain from such a machine may not necessarily be trustworthy might be appropriate, though, so they might *expect* things like the wu-ftpd hole to show up. _H* From firewalls-owner Sat Apr 9 01:03:43 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA22977; Sat, 9 Apr 1994 01:03:43 GMT Received: from igw.merck.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA22971; Fri, 8 Apr 1994 18:03:35 -0700 Message-Id: <199404090103.SAA22971@mycroft.GreatCircle.COM> Received: by igw.merck.com with rsmtp; Fri, 8 Apr 1994 21:07:33 EDT Date: Fri, 8 Apr 1994 20:52:57 -0400 From: anthony_starks@merck.com (Anthony Starks) To: firewalls@greatcircle.com Subject: TELNET URL SECURITY PROBLEM: DETAILS Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This is from the URL: http://south.ncsa.uiuc.edu/security.html Note: This problem only affects the X Windowing System versions of NCSA Mosaic. The Mac and MS Windows versions are not affected by this problem! This problem could result in the Mosaic client arbitrarily executing any UNIX command when the user clicked on a link to telnet, tn3270, or rlogin URL. This could happen because the official form of the string passed to this kind of URL was user@machine:password, and the machine string was just being passed on to the UNIX system() command. By passing strings such as machine; unix_command The command after the ';' was being executed with all the permissions of the Mosaic user. As of Mosaic 2.3 this problem has been fixed. The fix is made up of two changes as outlined below. 1. Use fork()/execlp() instead of system(). 2. MITs xterm currently uses exec(), but there are no guarantees about custom xterms, so before passing on the information to execlp(), the port number is required to be in the range 1-65535. Also, the hostname and username are both allowed to only contain the alphanumeric characters, plus '.', '_', '-', and '+'. The characters '-' and '+' are not allowed to be leading characters. This should prevent any harmful commands being executed, even on a machine whose version of xterm does use system(). From firewalls-owner Fri Apr 8 22:09:05 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA25909; Sat, 9 Apr 1994 04:59:52 GMT Received: from firewall.meaddata.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA25903; Fri, 8 Apr 1994 21:59:44 -0700 Received: from meaddata.com ([138.12.96.71]) by firewall.meaddata.com (4.1/SMI-4.1) id AA02555; Sat, 9 Apr 94 01:00:46 EDT Received: from jungle.meaddata.com by meaddata.com (4.1/SMI-4.1) id AA04732; Sat, 9 Apr 94 01:00:29 EDT Received: by jungle.meaddata.com (4.1/SMI-4.1) id AA17143; Sat, 9 Apr 94 01:00:23 EDT From: sdw@meaddata.com (Stephen Williams) Message-Id: <9404090500.AA17143@jungle.meaddata.com> Subject: Re: unplugging... To: hobbit@ftp.com (*Hobbit*) Date: Sat, 9 Apr 1994 01:00:22 -0400 (EDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9404082237.AA27596@ftp.com> from "*Hobbit*" at Apr 8, 94 06:37:41 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1684 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > No need. What's so hard about providing all these swoopy services on a > machine located just *outside* your firewall, with a completely expendable > OS and utilities that can be restored from tape in a couple of hours, and > doing all your real work [including generating the master tree for your > swoopy-server] behind the wall? Said machine will continue supplying swoopy > services even if it's cracked, until the crackers manage to completely > destroy it, after which you slap a tape on and restore it to its known > configuration [maybe with some more holes plugged]. > > It also gives you a "target" that you can carefully watch for weird activity > against, if you want to spent the time trapping perpetrators. > > A warning to all callers that things they obtain from such a machine may not > necessarily be trustworthy might be appropriate, though, so they might > *expect* things like the wu-ftpd hole to show up. > > _H* It's perfectly feasible to run such a system from a bootable CDROM/readonly floppy/ram disk configuration (at least with Linux). Optional HD to be reformatted/initialized from CD of course.... With CDD (writer) drives running <$4000 and disks about $15 each, this is perfectly feasible. sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw@lig.net OO R&D Source Dist. By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430 Comm. Consulting ICBM: 39 34N 85 15W I love it when a plan comes together Newbie Notice: (Surfer's know the score...) I speak for LIGCo., CCI, myself, and no one else, regardless of where it is convenient to post from or thru. From firewalls-owner Sat Apr 9 15:02:21 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA28430; Sat, 9 Apr 1994 15:02:21 GMT Received: from mccaw.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA28424; Sat, 9 Apr 1994 08:02:13 -0700 Received: from nwestmail.entp.mccaw.com ([155.176.15.34]) by mccaw.com (4.1/SMI-4.1) id AA02665; Sat, 9 Apr 94 08:01:34 PDT Received: from loki.ncent.mccaw.com by nwestmail.entp.mccaw.com (4.1/McCaw SUN-RMR Mailer, SMI-4.1) id AA27102; Sat, 9 Apr 94 08:01:32 PDT Received: by loki.ncent.mccaw.com (Smail3.1.28.1 #5) id m0ppeXL-000ENyC; Sat, 9 Apr 94 10:01 CDT Message-Id: From: fahnoe@loki.ncent.mccaw.com (Larry Fahnoe) Subject: Re: Re[2]: What?? To: 0066169@CCMAIL.EMIS.hac.com (Ronald A Martin) Date: Sat, 9 Apr 1994 10:01:31 -0500 (CDT) Cc: firewalls@GreatCircle.COM In-Reply-To: from "Ronald A Martin" at Apr 8, 94 11:13:11 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 988 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Digital Pathways also offers a client SSNK (Software Secure Net Key) > for DOS and Mac OSs (I believe they're working on a UNIX client). It's > a more convenient implmentation of the cryptographic authentication > calculator (SNK) if you tend to loose or forget the calculator hardware. If you are interested in using the SSNK with Apple's ARA (remote access) protocol, you will need to wait a little bit. I have been attempting to get this code from Digital Pathways for some time now, but have been held up by the fact that their code is based on ARA 2.01 (if memory serves) which Apple still has in beta. The SSNK with ARA support is still in beta as well, but due to be released real soon now. --Larry -- Larry Fahnoe Cellular One IS VAX System Manager 7900 S. Xerxes Ave, Suite 301 612/832-7616 Minneapolis, MN 55431 Internet: fahnoe@loki.ncent.mccaw.com McCaw DECnet: 18435::FAHNOE From firewalls-owner Sat Apr 9 16:25:49 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA28627; Sat, 9 Apr 1994 16:25:49 GMT Received: from csn.org by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA28621; Sat, 9 Apr 1994 09:25:42 -0700 Received: from [128.138.213.21] by csn.org with SMTP id AB16864 (5.65c/IDA-1.4.4 for ); Sat, 9 Apr 1994 10:25:00 -0600 Message-Id: <199404091625.AB16864@csn.org> To: hobbit@ftp.com (*Hobbit*) Cc: firewalls@greatcircle.com Subject: Re: unplugging... In-Reply-To: Your message of "Fri, 08 Apr 1994 18:37:41 EDT." <9404082237.AA27596@ftp.com> Date: Sat, 09 Apr 1994 10:25:00 -0600 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > No need. What's so hard about providing all these swoopy services on a > machine located just *outside* your firewall, with a completely expendable > OS and utilities that can be restored from tape in a couple of hours, and > doing all your real work [including generating the master tree for your > swoopy-server] behind the wall? Said machine will continue supplying swoopy > services even if it's cracked, until the crackers manage to completely > destroy it, after which you slap a tape on and restore it to its known > configuration [maybe with some more holes plugged]. As long as the swoopy-server doesn't contain information (including crackable passwords) that will provide access to your internal network. brad From firewalls-owner Sat Apr 9 18:12:09 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA29165; Sat, 9 Apr 1994 18:12:09 GMT Received: from lokkur.dexter.mi.us by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA29159; Sat, 9 Apr 1994 11:11:40 -0700 Received: (scs@localhost) by lokkur.dexter.mi.us (8.6.7/8.6.5) id OAA05583; Sat, 9 Apr 1994 14:10:13 -0400 From: Steve Simmons Message-Id: <199404091810.OAA05583@lokkur.dexter.mi.us> Subject: Re: system() -> Mosaic To: dotytr@nscultrix2.network.com (Ted Doty) Date: Sat, 9 Apr 1994 14:10:08 -0400 (EDT) Cc: firewalls@GreatCircle.COM, johns@oxygen.house.gov In-Reply-To: <9404081928.AA29052@nscultrix2.network.com> from "Ted Doty" at Apr 8, 94 02:28:35 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 709 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >One thing I have found particularly humerous is that the two biggest >threads on this list lately have been "Software is grotesquely buggy and >the damn vendors better do something about it" and "What's the cheapest >screaning router around?". Vendors aren't able to do anything if people >aren't willing to pay for product. Hear hear! I was at a client site the other day and they gasped at the idea of a $25,000 firewall package. I asked how much they paid for 24x365 security guards, electronic door cards, locks on the doors, keys for desks, etc, etc, etc. I told them connecting to the information highway without a firewall and a security policy is like removing all the doors from your building. From firewalls-owner Sat Apr 9 21:38:15 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA00701; Sat, 9 Apr 1994 21:38:15 GMT Received: from ax.ibase.br by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA00695; Sat, 9 Apr 1994 14:37:58 -0700 Received: by ax.ibase.br (8.6.8.1/Revision: 1.9 ) id SAA03899; Sat, 9 Apr 1994 18:35:13 -0300 From: Fernando Cabral To: 0066169@ccmail.emis.hac.com, firewalls@greatcircle.com Subject: Re[3]: What?? X-Mailer: ScoMail 1.0 Date: Sat, 9 Apr 1994 18:03:10 +0100 (BST) Message-ID: <9404091803.aa05710@boemia.pix.com.br> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk => >Would someone fill me in on the Digital Pathways DES keys thing? => >I'm in the dark. What are they, and why are they so popular? => => ) It's a handheld cryptographic authentication calculator. They cost => )~$55 in quantity. They contain a replaceable (hot swap) battery that keeps a => )DES key in memory all the time. The admin programs the key into it -- so you => )don't rely on someone else to key your authentication device. => ) It's fairly solid, not especially attractive, but it uses an algorithm => )someone published a few years back, that's easy to implement in software, so => )you can avoid host-software licensing, portability, and availability issues. => ) It's one of the authentication devices the TIS firewall toolkit => )supports -- we have a server-side implementation that requires no additional => )software, so you can just buy 'em and key 'em and issue 'em to users. => => )mjr. => => Digital Pathways also offers a client SSNK (Software Secure Net Key) => for DOS and Mac OSs (I believe they're working on a UNIX client). It's => a more convenient implmentation of the cryptographic authentication => calculator (SNK) if you tend to loose or forget the calculator hardware. => => Ron Martin => Hughes Aircraft => => Haven't you dumb heard him saying that he is in the dark? For a blind person like him, the TSNSKF (AKA Touch-Sensitive Network Secure-Key Facility) is the right answer. This simple device has an universal AU (Atachment Unit) which is level-2 complient. This means it can be plugged into any network, including Ethernet and Token-Ring. It is protocol independent and work with any operating system, in two different modes: client (if you beg for things) and server (if you are a public worker). The Japanese version is good, the American version is the most expensive, the European version is OK but not reliable; the Taiwan-made works well as long as there is no rain. Good if you in the Sahara. Not recommended for the rain forest. - fernando Fernando Cabral fcabral@ibase.br PADRAO iX Sistemas Abertos voice: +55 61 274-6092 fax: +55 61 274-5302 Modem: +55 61 273-5559 From firewalls-owner Mon Apr 11 11:24:32 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA08632; Mon, 11 Apr 1994 11:24:32 GMT Received: from london.micrognosis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA08626; Mon, 11 Apr 1994 04:24:20 -0700 Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA22581; Mon, 11 Apr 94 12:22:42 BST Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma022578; Mon Apr 11 12:22:29 1994 Received: from pmsls11 by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA14709; Mon, 11 Apr 94 12:22:24 BST From: imarr@london.micrognosis.com (Ian Marr) Received: by pmsls11 (4.1//ident-1.0) id AA13439; Mon, 11 Apr 94 12:22:24 BST Message-Id: <9404111122.AA13439@pmsls11> Subject: Re: system() -> Mosaic To: dotytr@nscultrix2.network.com Date: Mon, 11 Apr 1994 12:22:23 +0100 (BST) Cc: firewalls@GreatCircle.COM X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1341 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Steve Simmons writes: > > Vendors aren't able to do anything if people aren't willing to pay > > for product. > > Hear hear! I was at a client site the other day and they gasped at the > idea of a $25,000 firewall package. I asked how much they paid for 24x365 > security guards, electronic door cards, locks on the doors, keys for desks, > etc, etc, etc. I told them connecting to the information highway without > a firewall and a security policy is like removing all the doors from your > building. I don't *really* believe my next question but ... Is an Internet connection as beneficial to the company as the building that everyone works in ? And ... $25,000 is *a lot* of money for a secure connection - when you add (or compare) this to the cost of the service, you'd be hard pressed to find a commercial (profit generating) reason for such an expensive connection. [Or can someone contradict me ?] It's a sad fact that your $25,000 is thought of as part of the Internet service cost *not* general security costs for operating at a particular site. Ian. ------------------------------------------------------------------------------ Ian Marr, Systems Manager, Micrognosis, 63 Queen Victoria St, London, EC4N 4UD imarr@london.micrognosis.com +44-71-815-5254 From firewalls-owner Mon Apr 11 12:15:34 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA08849; Mon, 11 Apr 1994 12:15:34 GMT Received: from erenj.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA08843; Mon, 11 Apr 1994 05:15:26 -0700 Posted-Date: Mon, 11 Apr 1994 08:15:27 -0400 From: bdboyle@maverick1.erenj.com (Bryan D. Boyle) Message-Id: <9404110815.ZM16803@maverick1.erenj.com> Date: Mon, 11 Apr 1994 08:15:27 -0400 In-Reply-To: imarr@london.micrognosis.com (Ian Marr) "Re: system() -> Mosaic" (Apr 11, 12:22pm) References: <9404111122.AA13439@pmsls11> X-Mailer: Z-Mail (2.1.0 10/1/92) To: firewalls@GreatCircle.COM Subject: Re: system() -> Mosaic Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Apr 11, 12:22pm, Ian Marr wrote: > > I don't *really* believe my next question but ... > > Is an Internet connection as beneficial to the company as the building > that everyone works in ? A building can be replaced. It is just a building. The reason that security is put up between the net and the inside resources is that the destruction or theft of intellectual property is much more serious, since it is not a 'fixed asset', but may represent the only true value that an organization has. And besides, systems administrators are not the final arbiters of this policy, they only enforce the access rules that the company has decided are in its best interest to enforce. As to the web's beneficence to a company that is connected to it? I wouldn't want to be sitting in my office if we disconnected the net. A lot of scientists, engineers, and managers would go into withdrawal, and a lot of information and collaboration would end quickly, to my company's chagrin. I would say that the net is not a necessary utility YET. But, like the pervasiveness of phones, fax machines (which the net eliminates to a certain extent), and ATM cards, it is almost there. Ask me in 2 years... > > And ... $25,000 is *a lot* of money for a secure connection - when you > add (or compare) this to the cost of the service, you'd be hard pressed > to find a commercial (profit generating) reason for such an expensive > connection. [Or can someone contradict me ?] I don't know. If you are a 100 million dollar a year operation, and the ongoing work that is being done on your network may generate 1 billion dollars in revenue over the next year, than 25,000. is a small price to pay for security to ensure that outsiders don't have access. A more pertinent question, perhaps, is how much would your data be worth to your competitor (forget for a moment about the college students on hormonal overdrive out for the 90's equivalent of 'joyriding')? (This assumes, of course, that you have at least some information on your computer systems that is worth something (no, windoze doesn't count as worth anything...)) > > It's a sad fact that your $25,000 is thought of as part of the Internet > service cost *not* general security costs for operating at a particular > site. > It is also a sad fact that part of the cost of a new home is an electronic security system, deadbolt locks, and window pins. If you are supporting a full-time connection to the net, monitoring the inside traffic for load projection, and charged with protecting the assets of the company from the data buccaneers, then even $100,000. spent to protect the network, if it enforces the corporate security and access policy (and they give you the buck to do so...) while providing a reasonable level of access is not a Bad Thing (tm). Just my $.02 -- Bryan D. Boyle |Physical: ER&E, Clinton, NJ (908) 730-3338 #include |Virtual: bdboyle@erenj.com "If everyone is thinking alike, then someone isn't thinking." -Patton Pardon me, I'm lost, can you direct me to the information superhighway? From firewalls-owner Mon Apr 11 06:19:22 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA09115; Mon, 11 Apr 1994 13:10:32 GMT Received: from MIT.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA09107; Mon, 11 Apr 1994 06:10:23 -0700 From: drmorris@MIT.EDU Received: from BOLOGNESE.MIT.EDU by MIT.EDU with SMTP id AA11614; Mon, 11 Apr 94 09:10:27 EDT Received: by bolognese.MIT.EDU (5.57/4.7) id AA16933; Mon, 11 Apr 94 09:10:24 -0400 Message-Id: <9404111310.AA16933@bolognese.MIT.EDU> To: imarr@london.micrognosis.com (Ian Marr) Cc: firewalls@greatcircle.com Subject: Re: system() -> Mosaic In-Reply-To: Your message of Mon, 11 Apr 94 12:22:23 +0100. <9404111122.AA13439@pmsls11> Date: Mon, 11 Apr 94 09:10:23 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Is an Internet connection as beneficial to the company as the building > that everyone works in ? I find it difficult to answer without first agreeing on the definitions of "beneficial", "company", and "building". I could answer "Yes, absolutely, even more so." and "No, absolutely not", for suitable definitions. > And ... $25,000 is *a lot* of money for a secure connection - when you > add (or compare) this to the cost of the service, you'd be hard pressed > to find a commercial (profit generating) reason for such an expensive > connection. [Or can someone contradict me ?] *I* am not hard pressed... Reason to spend money for a connection: An Internet connection can get you contracts (oh, you have better support on the Internet than your competitor and that means problems with your product should get fixed faster - we'll buy from you). An solid Internet connection can boost your company's image as a technology leader. Employees may be able to solve problems faster with the use of an Internet connection, meaning an increase in productivity. Employees can develop outside connections easier, and learn/play with "up and coming technologies". Again, we haven't agreed on a definition for "company", so some or all of these may not apply. Once the benefit of the connection is established (having a connection is worth at least $xxx,xxx to my bottom line), assess and manage the risks. In my experience, for moderate to large "companies", the cost of incurring one major security incident well exceeds $25,000, and without a good firewall setup, having such an incident is a near certainty. What the original analogy attempts to do, IMHO, is clarify that there are risks, and that there are costs in managing risks. This client already did it with physical security (so it made sense to them there), and doing the same for network security is no different. > It's a sad fact that your $25,000 is thought of as part of the Internet > service cost *not* general security costs for operating at a particular > site. How so? It is part of the Internet service cost. Cheers, Dave Morrison drmorris@mit.edu From firewalls-owner Mon Apr 11 14:14:23 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA09458; Mon, 11 Apr 1994 14:14:23 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA09452; Mon, 11 Apr 1994 07:14:12 -0700 Received: from nscultrix2.network.com by nsco.network.com (5.61/1.34) id AA16146; Mon, 11 Apr 94 09:17:20 -0500 Received: by nscultrix2.network.com (5.57/Ultrix3.0-C) id AA10399; Mon, 11 Apr 94 09:13:34 CDT Date: Mon, 11 Apr 94 09:13:34 CDT From: dotytr@nscultrix2.network.com (Ted Doty) Message-Id: <9404111413.AA10399@nscultrix2.network.com> To: emon@nscultrix2.network.com, imarr@london.micrognosis.com Subject: Re: system() -> Mosaic Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Is an Internet connection as beneficial to the company as the building > that everyone works in ? (please don't interpret this as a flame) I think the day is rapidly approaching when it will be impossible to NOT do business on the Internet, if only because your organization's productivity will be so much lower than your competitor's that you will be take-over bait (note that this doesn't apply to the government, but I've found governments more receptive to the concept of security than most organizations). Remember, most of the things that are driving the "Information Superhighway" (sorry for the parochial view from this side of the pond) are in support of Hillary's health care plans ... wide-area medical immaging, transfer of insurance info, etc. This type of transfer simply cannot exist without better security. Also, the costs of not implementing this technology is non-trivial. > And ... $25,000 is *a lot* of money for a secure connection - when you > add (or compare) this to the cost of the service, you'd be hard pressed > to find a commercial (profit generating) reason for such an expensive > connection. [Or can someone contradict me ?] Hmm.. Add the cost of a router ($4,000 over here), installation of the wide area line ($1,000), the CSU/DSU ($1,000). Now calculate the present value of a 56 kb line for 3 years. This is the cost of doing business, and is not grosly under the cost of the firewall. Consider commercial profit generating motive (true story): NSC is in the process of rolling out a laptop-based system to support the sales force. This will basically eliminate 90% of the paperwork people now do. The INFORMATION wil;l still be generated, but will be passed via email (and management approvals will be via email). This system's total HARDWARE cost is over $2 million. The special-purpose software cost is well over $3 million. The payoff time? Currently estimated at under a year due to higher productivity. This is, admittedly, a narrow vision, but I firmly believe that it is the future. Now add in intangibles, like people being able to work in ways they never could before, and the cost of the security becomes essentially negligable. > It's a sad fact that your $25,000 is thought of as part of the Internet > service cost *not* general security costs for operating at a particular > site. Probably the main problems for security are (1) a firewall is perhaps not the most appropriate technology because of high recurring costs (for a Unix kernel wizzard) and obtrusive procedures requiring retraining of users (you can't just use your normal apps ... you have to double-hop, etc), and (2) it's too hard to set up and maintain robust, extensible access controls (too much human involvement costs money and introduces errors). Once these problems get solved, and I think we're very close, this security stuff will probably take off. My $0.02 worth. - Ted -------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Road, Suite 250 | fax: +1 410 381-3320 Columbia, MD, 21046 USA | voice mail: (800) 233-1485 -------------------------------------------------------------------------- if (setsockopt(sockfd, SOL_SOCKET, STD_DISCLAIMER, (char *), &sendbuff, &optlen) < 0) printf ("Standard Disclaimers Apply ...\n"); From firewalls-owner Mon Apr 11 15:03:43 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA09681; Mon, 11 Apr 1994 15:03:43 GMT Received: from interlock.reston.ans.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA09675; Mon, 11 Apr 1994 08:03:31 -0700 Received: by interlock.reston.ans.net id AA06558 (InterLock SMTP Gateway 1.1 for firewalls@greatcircle.com); Mon, 11 Apr 1994 11:03:35 -0400 Message-Id: <199404111503.AA06558@interlock.reston.ans.net> Received: by interlock.reston.ans.net (Internal Mail Agent-2); Mon, 11 Apr 1994 11:03:35 -0400 Received: by interlock.reston.ans.net (Internal Mail Agent-1); Mon, 11 Apr 1994 11:03:35 -0400 Date: Mon, 11 Apr 1994 11:03:12 +0500 From: sangster@reston.ans.net (Paul Sangster) To: firewalls@greatcircle.com Subject: Re: Mixing Authentification Strategies X-Sun-Charset: US-ASCII Content-Length: 4031 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Steve Simmons writes: |> I've been looking at skey, one-time pads, etc. One issue which doesn't |> seem to be addressed is the mixing of authentication types. For example, |> inside a reasonably secure net one might chose to use `ordinary' unix |> authentication. When accessing from outside, one might want to normally |> use skey, but fall back to a set of memorized one-time passwords if no |> local/trustworthy skey generator is available. |> |> The trick is how to decide on the fly which to use. Alternate ports for |> alternate authentications involves excessive memorization. What I'd do |> if I were recoding login.c is to let one modify the login id to indicate |> desired authentication type: |> |> login: scs # system default |> login: scs/skey # skey |> login: scs/onetime # one-time list |> login: scs/unix # normal unix |> login: scs/whatever # local custom job Its seems like if you allow "scs" to have many different authentication schemes available, the weakest form is the one which hackers will try to attack. Since it only takes 1 time using the "ordinary" unix password for the password to be sniffed, I wonder if this is what you really want. (This partly comes down to user education issue, since many users if given the opportunity will just choose the easiest authentication form which is frequently also the easiest to attack, passwords.) I guess what I am saying is if you are going to go the extra mile for stronger authentication, you should pick one you will always be confortable with and don't leave the old door open. |> |> A good implementation would refuse to do the wrong thing, eg, not permit |> scs/unix from locations known to be outside the secured facility. If |> anybody's thought seriously about the virtues of this or has other |> solutions, I'd love to hear it. On the InterLock, we tried to address some of these authentication mix issue. The approach we settled on was to provide maximum flexibility to allow the customer to define (in our access control rule base) their authentication policy. What this means is that as part of each rule, the administrator defines that "sangster" when he is connecting from a machine (or net) on the protected network outbound will be authenticated using standard unix passwords. Likewise, the admin can have another rule saying "sangster" when coming from the Internet will be required to use SecurId. Currently we only support SecurId, Pinpad (from Security Dynamics) and the use (or absense from protected side) of a unix password. We also support combinations of these authentication schemes, so you can define multiple schemes be used on a connection (if desired) and the order which they will occur. Our changes to dynamically select and enforce the authentication policy are to our gateways for ftp and telnet as well as in the login daemon. This may not be practical for admins trying to build their own firewalls, but since were in that business ... :-). In order to get full flexibility of orderings, authentication schemes and tie it to connection direction it seems reasonable and most secure to make the changes at the earliest point of entry (the daemons). However, if thats not practical you can still do some powerful things using shell replacement. For example, Security Dynamics has you replace your initial shell with a special SDI card prompting shell which handles the authentication I/O and talking with their ACE server. Then after you are authorized to login it runs your normal shell for you. Paul ____________________________________________________________________________ Paul Sangster Advanced Network & Services Software Engineer 1875 Campus Commons Dr. sangster@reston.ans.net Suite 220, Reston VA 22091 (703) 758-7706 ____________________________________________________________________________ From firewalls-owner Mon Apr 11 15:08:38 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA09732; Mon, 11 Apr 1994 15:08:38 GMT Received: from interlock.reston.ans.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA09726; Mon, 11 Apr 1994 08:08:28 -0700 Received: by interlock.reston.ans.net id AA08354 (InterLock SMTP Gateway 1.1 for firewalls@greatcircle.com); Mon, 11 Apr 1994 11:08:32 -0400 Message-Id: <199404111508.AA08354@interlock.reston.ans.net> Received: by interlock.reston.ans.net (Internal Mail Agent-2); Mon, 11 Apr 1994 11:08:32 -0400 Received: by interlock.reston.ans.net (Internal Mail Agent-1); Mon, 11 Apr 1994 11:08:32 -0400 Date: Mon, 11 Apr 1994 11:08:06 +0500 From: sangster@reston.ans.net (Paul Sangster) To: firewalls@greatcircle.com Subject: Re: X3270 through firewall X-Sun-Charset: US-ASCII Content-Length: 2088 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Yves.Dherbecourt@der.edf.fr (Yves Dherbecourt) writes: |> |> Did somebody get X3270 work through a firewall WITH authentication set on |> this firewall ? and How ? Yes, the current version of the InterLock gateways 3270 over a telnet connection for clients that follow the RFCs. However some clients seem to come up and by default insist upon 3270 data stream formats which makes it tougher. The next version of the InterLock will also support these types of clients. |> |> X3270 works on the telnet port, but it doesn't seem fair |> enough to handle properly the authentication dialog with the firewall |> before launching the real X3270 session. (Tn3270 does). The problem is that in order for your gateway to talk to a 3270 client that is emulating 3270, you will need to have the gateway properly negotiate the appropriate telnet options (eg. EOR, Term Type). Then your gateway has to be able to send and receive properly formatted 3270 data streams for displaying and retrieving information. |> |> #---------------------------------------------------------------------------# |> # Yves Dherbecourt | Tel : (1) 47 65 37 90 # |> # Electricite de France | Fax : (1) 47 65 35 23 # |> # DER / IMA / ICI / ASR | Tlx : 631576 # |> # 1, avenue du General de Gaulle | # |> # 92141 CLAMART Cedex | Email : Yves.Dherbecourt@der.edf.fr # |> # France | # |> #---------------------------------------------------------------------------# ____________________________________________________________________________ Paul Sangster Advanced Network & Services Software Engineer 1875 Campus Commons Dr. sangster@reston.ans.net Suite 220, Reston VA 22091 (703) 758-7706 ____________________________________________________________________________ From firewalls-owner Mon Apr 11 15:23:20 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA09828; Mon, 11 Apr 1994 15:23:20 GMT Received: from uai.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA09822; Mon, 11 Apr 1994 08:23:10 -0700 Received: from hp.uai.com by uai.com with SMTP id AA24192 (5.65c/IDA-1.4.4 for ); Mon, 11 Apr 1994 08:22:34 -0700 From: "Mark R. Ludwig" Received: by hp.uai.com id ; Mon, 11 Apr 94 08:22:32 -0700 Message-Id: <9404111522.AA17585@hp.uai.com> To: Steve Simmons Cc: dotytr@nscultrix2.network.com (Ted Doty), firewalls@greatcircle.com, johns@oxygen.house.gov Subject: Re: system() -> Mosaic In-Reply-To: <199404091810.OAA05583@lokkur.dexter.mi.us> from "Steve Simmons" on Sat, 09 Apr 1994 14:10:08 EDT. X-Mailer: MH [Version 6.8] Date: Mon, 11 Apr 1994 08:22:31 -0700 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> "Steve" == Steve Simmons writes: Steve> I was at a client site the other day and they gasped at the Steve> idea of a $25,000 firewall package. I asked how much they paid Steve> for 24x365 security guards, electronic door cards, locks on the Steve> doors, keys for desks, etc, etc, etc. I told them connecting Steve> to the information highway without a firewall and a security Steve> policy is like removing all the doors from your building. This is an exaggeration. In the words of Malcolm Forbes, "never exaggerate." If you exaggerate about this, how accurate was the rest of what you said? If you have better ones, fine, but it's analogy time, and we Internauts desperately need some good analogies to Real Life to help people understand, so here goes: An Internet Firewall is like the fences/gates/guards/card-keys surrounding an exclusive, private community. It's also like the lock on the front door of your apartment/condominium building. It provides a buffer between your immediate space and the "outside world." Your personal password/SecurID/retina-scan/voice-print which grants you access to your computer account is like the locks on the doors to your home. If you do not have a firewall, you have to know more about how your system was built, be more careful about passwords, etc. The analogy here is that you have to worry about how the builder installed the doorjams, windows, and walls, about how competently the burglar/home-invasion alarm company secured your perimeter, and also about the children leaving their windows and patio doors unlocked in the morning when they run off to school or something like that.$$ -- INET: Mark-Ludwig@UAI.COM NIC: ML255 ICBM: USA; Lower Left Coast "Cigarettes are ... not a drug." -- An unknown speaker from the Tobacco Institute From firewalls-owner Mon Apr 11 16:46:55 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA10127; Mon, 11 Apr 1994 16:46:55 GMT Received: from hermes.intel.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA10121; Mon, 11 Apr 1994 09:46:26 -0700 Received: from argus.intel.com by hermes.intel.com (5.65/10.0i); Mon, 11 Apr 94 09:45:43 -0700 Received: by argus.intel.com (5.65/10.0i); Mon, 11 Apr 94 09:45:42 -0700 From: sedayao@argus.intel.com (Jeffrey C. Sedayao) Message-Id: <9404111645.AA07190@argus.intel.com> Subject: Re: system() -> Mosaic To: imarr@london.micrognosis.com (Ian Marr) Date: Mon, 11 Apr 94 9:45:40 PDT Cc: dotytr@nscultrix2.network.com, firewalls@GreatCircle.COM In-Reply-To: <9404111122.AA13439@pmsls11> from "Ian Marr" at Apr 11, 94 12:22:23 pm X-Mailer: ELM [version 2.4dev PL66] Mime-Version: 1.0 Content-Type: text Content-Length: 1629 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I don't *really* believe my next question but ... > Is an Internet connection as beneficial to the company as the building > that everyone works in ? It can be, yes. > And ... $25,000 is *a lot* of money for a secure connection - when you > add (or compare) this to the cost of the service, you'd be hard pressed > to find a commercial (profit generating) reason for such an expensive > connection. [Or can someone contradict me ?] Sure. An Internet connection can be justified on a pure return on investment basis. One example is support. The cost of having a support technician answer an 800 number support call (phone toll is free to the caller) and send a diskette via overnight mail is much much higher than cost of having the customer copy a file from an Internet anonymous FTP server. It doesn't take long for an anonymous FTP server and Internet connection to pay for itself. Using the Internet is faster, too. I also know of cases where business was lost because a vendor couldn't support a potential customer via the Internet. $25,000 for a secure Internet connection seems like a bargain to me. > It's a sad fact that your $25,000 is thought of as part of the Internet > service cost *not* general security costs for operating at a particular > site. > Ian. > ------------------------------------------------------------------------------ > Ian Marr, Systems Manager, Micrognosis, 63 Queen Victoria St, London, EC4N 4UD > imarr@london.micrognosis.com +44-71-815-5254 > -- Jeff Sedayao Intel Corporation sedayao@argus.intel.com From firewalls-owner Mon Apr 11 21:08:34 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA10906; Mon, 11 Apr 1994 21:08:34 GMT Received: from gatekeeper.imagen.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA10900; Mon, 11 Apr 1994 14:08:22 -0700 Received: from imagen.sclara.qms.com (imagen.imagen.com) by gatekeeper.imagen.com (4.1/SMI-4.1) id AA08249; Mon, 11 Apr 94 14:08:09 PDT Received: from cockroach.sclara.qms.com by imagen.sclara.qms.com (4.1/SMI-4.1) id AA18664; Mon, 11 Apr 94 14:08:07 PDT Received: by cockroach.sclara.qms.com (4.1/client-1.5) id AA06352; Mon, 11 Apr 94 14:08:06 PDT Message-Id: <9404112108.AA06352@cockroach.sclara.qms.com> From: pomeranz@sclara.qms.com (Hal Pomeranz) Date: Mon, 11 Apr 1994 14:08:06 -0700 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: bind@uunet.uu.net, namedroppers@nic.ddn.mil, firewalls@greatcircle.com Subject: BayLISA April Meeting: Paul Vixie Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk BayLISA will be holding it's monthly meeting on April 21, 1994. Please note that we are at a new location, Synopsys. Please see directions below. This months speaker, Paul Vixie, sent the following abstract: Stolen Networks And How To Live With Them Since Class A networks have always been hard to get and Class B's have recently also become hard to get, a growing number of IP-using organizations are using Class A and B network numbers which officially belong to someone else. This abuse creates some interesting problems for the Internet gateways to such organizations, especially if they want end-to-end IP connectivity from within their internal, illegal, unadvertised, ambiguous network all the way out to the real Internet. This talk will focus on an implementation of ``proxy forwarding'' done mostly via intercepted system calls and the ``hooks'' interface in the BIND 4.9.2 resolver. The described system is similar to ``Socks'' but violates fewer invariants. It is running in production on BSD/386, and should be portable to any BSD-like operating system whose Socket interface is implemented with system calls rather than library stubs. The code will shortly be released to the public. We hope you can attend. - ----- Notes: The BayLISA Summer Picnic is coming together, and we are currently looking at late July as our target date. Watch for further announcements. - ----- General Meeting Information: Date: Thursday, Apr 21st, 7:30 PM (Third Thursday of every month) Please do not arrive before 7 PM. Place: Synopsys Building C 700 E. Middlefield Road Mountain View, CA 94043 [SEE BELOW FOR MAP AND DIRECTIONS] BayLISA Information: The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. BayLISA Contact Information: For general information: baylisa-info@baylisa.org BayLISA Board: blw@baylisa.org Individual Board members: first_lastname@baylisa.org FTP Service: ftp.baylisa.org:/BayLISA Non-electronic mail: BayLISA PO Box 64369 Sunnyvale, CA 94088-4369 To join the BayLISA mailing list, send email to majordomo@baylisa.org with a body message of help. - ----- Synopsys is located at the corner of Highway 237 and Middlefield. If you are going South on 101 you exit on Ellis street. Turn right towards Mountain View (not Moffet field). Turn left onto Middlefield. Go past the light at Highway 237. The next light will be Bernardo, turn left into the parking lot. Head left to Building C. If you are going North on 101, exit on to Mountain View (I don't remember if it's West or South 237, freeways here just don't make sense). Turn left at Middlefield. It will be the second traffic light. The next light will be Bernardo, turn left into the parking lot. Head left to Building C. Ascii diagram, not to scale :-) Highway 101 | | | ellis \ +--------\ | \ | \ - ---------+------+--------------------- Highway 237 |M | \ |i @ |maude \ --------+d--- | \ bernardo |d | |l | |f |i |e |l @ = Synopsys |d From firewalls-owner Tue Apr 12 02:08:14 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA11933; Tue, 12 Apr 1994 02:08:14 GMT Received: from deshaw.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA11924; Mon, 11 Apr 1994 19:08:03 -0700 Received: from cs2.deshaw.com by deshaw.com with SMTP id AA19316 (5.65c/IDA-1.4.4 for ); Mon, 11 Apr 1994 14:35:44 -0400 Message-Id: <199404111835.AA19316@deshaw.com> To: firewalls@greatcircle.com Subject: Re: system() -> Mosaic Date: Mon, 11 Apr 94 14:35:44 -0400 From: Mark Moraes Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk dotytr@nscultrix2.network.com (Ted Doty) wrote: | One thing I have found particularly humerous is that the two biggest | threads on this list lately have been "Software is grotesquely buggy and | the damn vendors better do something about it" and "What's the cheapest | screaning router around?". Vendors aren't able to do anything if people | aren't willing to pay for product. To me, the two are unrelated. In general, cost is a concern for most people once the functionality/reliability requirements are met (and to some people, cost is a concern, regardless of functionality -- that's life; be careful you don't mistake the two when correlating statements as you've done above -- I've worked in both environments:-); if a screening router priced at $2.5k works as well for the purpose of screening as a router priced at $25k, most people will likely buy the former. (And I've seen some low-end routers do better screening for Internet security purposes than some high-end ones) However, grotesquely buggy software is a separate can of worms. The last time I heard a software vendor talk about security, they (as always) focused on password aging schemes, C2 level security, etc. Absolutely nothing about fixing many well-known problems (we had already documented those problems) in existing daemons, vetting the systems for basic security and code quality. Sorry, to me, the latter is part of general operating system support. Mark. From firewalls-owner Tue Apr 12 03:06:28 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA12120; Tue, 12 Apr 1994 03:06:28 GMT Received: from owl.pooh.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA12114; Mon, 11 Apr 1994 20:06:19 -0700 Received: from rabbit.pooh.com by owl.pooh.com with smtp (Smail3.1.28.1 #2) id m0pqYnx-000nRxC; Mon, 11 Apr 94 20:06 WET DST Received: by rabbit.pooh.com (4.1/SMI-4.1) id AA01295; Mon, 11 Apr 94 20:06:56 PDT Date: Mon, 11 Apr 94 20:06:56 PDT From: david@pooh.com (David Wolfskill) Message-Id: <9404120306.AA01295@rabbit.pooh.com> To: firewalls@GreatCircle.COM Subject: Vendors & security (was: Re: system() -> Mosaic) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Date: Mon, 11 Apr 94 14:35:44 -0400 >From: Mark Moraes >However, grotesquely buggy software is a separate can of worms. The last >time I heard a software vendor talk about security, they (as always) >focused on password aging schemes, C2 level security, etc. Absolutely >nothing about fixing many well-known problems (we had already documented >those problems) in existing daemons, vetting the systems for basic >security and code quality. Sorry, to me, the latter is part of general >operating system support. Quite true -- but here, you're bringing up the issue of system "integrity" -- which is different from, but closely related to, security. Indeed, I think of them as two side of the same coin: you can't have one without the other. There are some vendors (I *hope* the plural is justified!) who take "integrity" seriously. (I've spent the previous 12 years as an IBM mainframe (MVS) systems programmer; defending IBM isn't something that comes very natural to me.... :-} Nevertheless, based on the system maintenance that I did during that time, as well as converstaions with IBMers & other systems folk, I got the distinct impression that IBM treated "system integrity" as an extremely important issue. This is one respect in which I believe that IBM has had a good approach to such things. Of course, different parts of IBM may well treat such things differently -- and the changes within IBM of late are certain to have externaly visible changes, some of which may affect all of this. Your mileage may vary; void where prohibited, etc., etc.) In any case, if there is a hole in the system integrity, there is certainly the possiblity of a hole in its security... and vice versa. We need to make sure that both vendors *and* the folks spending the money are aware of the importance of both issues -- and that trying to address one without the other is a lost cause... and certainly ought to result in a lost sale. Yours for trying to keep the vendors honest, david -- David H. Wolfskill david@pooh.com From firewalls-owner Tue Apr 12 18:15:11 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA14999; Tue, 12 Apr 1994 18:15:11 GMT Received: from riverside.mr.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA14984; Tue, 12 Apr 1994 11:14:57 -0700 Received: from plym.fingerhut.com by riverside.mr.net (8.6.4/SMI-4.1.R931202) id NAA14768; Tue, 12 Apr 1994 13:14:34 -0500 Received: from norma-jean.plym.fingerhut.com by plym.fingerhut.com (5.0/SMI-SVR4) id AA21147; Tue, 12 Apr 1994 13:14:29 +0600 Received: by norma-jean.plym.fingerhut.com (5.0/SMI-SVR4) id AA01726; Tue, 12 Apr 1994 13:14:28 +0600 Date: Tue, 12 Apr 1994 13:14:28 +0600 From: Matt.Sherek@plym.fingerhut.com (Matt Sherek) Message-Id: <9404121814.AA01726@norma-jean.plym.fingerhut.com> To: Firewalls-Digest@GreatCircle.COM Subject: Monitoring E-mail traffic through firewall X-Sun-Charset: US-ASCII Content-Length: 251 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk All, Does anyone know of a good way to monitor E-mail traffic to users on your network? I'm looking for something that will tell me: To From Size Time something like that. Any help would be appreciated. Matt Sherek Matt.Sherek@plym.fingerhut.com From firewalls-owner Tue Apr 12 18:32:29 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA15099; Tue, 12 Apr 1994 18:32:29 GMT Received: from isi.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA15093; Tue, 12 Apr 1994 11:32:23 -0700 Received: from chief.isi.com by isi.com (4.1/Ultrix3.0-C) id AA17893; Tue, 12 Apr 94 11:35:46 PDT Received: from corina.universe (corina.isi.com) by chief.isi.com (4.1/inc/isi-1.6s) id AA17488; Tue, 12 Apr 94 11:35:28 PDT Date: Tue, 12 Apr 94 11:35:28 PDT From: langston@isi.com (Richard Langston x247) Message-Id: <9404121835.AA17488@chief.isi.com> To: Firewalls-Digest@GreatCircle.COM, Matt.Sherek@plym.fingerhut.com Subject: Re: Monitoring E-mail traffic through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > All, > Does anyone know of a good way to monitor E-mail traffic to users > on your network? > I'm looking for something that will tell me: > > To From Size Time Well, I don't see how that belongs on this list, but personally I think everything except "Size" is none of your business... Security doesn't have anything to do with evesdroping... From firewalls-owner Tue Apr 12 18:52:57 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA15160; Tue, 12 Apr 1994 18:52:57 GMT Received: from riverside.mr.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA15154; Tue, 12 Apr 1994 11:52:50 -0700 Received: from plym.fingerhut.com by riverside.mr.net (8.6.4/SMI-4.1.R931202) id NAA15268; Tue, 12 Apr 1994 13:52:54 -0500 Received: from norma-jean.plym.fingerhut.com by plym.fingerhut.com (5.0/SMI-SVR4) id AA21197; Tue, 12 Apr 1994 13:52:50 +0600 Received: by norma-jean.plym.fingerhut.com (5.0/SMI-SVR4) id AA01729; Tue, 12 Apr 1994 13:52:47 +0600 Date: Tue, 12 Apr 1994 13:52:47 +0600 From: Matt.Sherek@plym.fingerhut.com (Matt Sherek) Message-Id: <9404121852.AA01729@norma-jean.plym.fingerhut.com> To: langston@isi.com Subject: Re: Monitoring E-mail traffic through firewall Cc: Firewalls-Digest@GreatCircle.COM, Matt.Sherek@plym.fingerhut.com X-Sun-Charset: US-ASCII Content-Length: 502 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Richard, >>Well, I don't see how that belongs on this list, but personally >>I think everything except "Size" is none of your business... Security >>doesn't have anything to do with evesdroping... I'm sorry you feel this way, but next time I suggest if you don't like something you keep it to yourself. This is a firewall forum, not a place to voice your personal opinions. Our policy at Fingerhut is, if it uses our resources it's our business. Not my policy, but I do agree with it. Matt Sherek From firewalls-owner Tue Apr 12 19:07:59 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA15229; Tue, 12 Apr 1994 19:07:59 GMT Received: from isi.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA15223; Tue, 12 Apr 1994 12:07:52 -0700 Received: from chief.isi.com by isi.com (4.1/Ultrix3.0-C) id AA18169; Tue, 12 Apr 94 12:11:34 PDT Received: from corina.universe (corina.isi.com) by chief.isi.com (4.1/inc/isi-1.6s) id AA17793; Tue, 12 Apr 94 12:11:16 PDT Date: Tue, 12 Apr 94 12:11:16 PDT From: langston@isi.com (Richard Langston x247) Message-Id: <9404121911.AA17793@chief.isi.com> To: langston@isi.com, Matt.Sherek@plym.fingerhut.com Subject: Re: Monitoring E-mail traffic through firewall Cc: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > I'm sorry you feel this way, but next time I suggest if you don't like > something you keep it to yourself. This is a firewall forum, not a place > to voice your personal opinions. > > Our policy at Fingerhut is, if it uses our resources it's our business. > Not my policy, but I do agree with it. > > Matt Sherek > Firewalls != email monitoring Firewalls = safe internet connections Please take this to the nazi-hall-monitors list. From firewalls-owner Tue Apr 12 19:37:34 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA15377; Tue, 12 Apr 1994 19:37:34 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA15371; Tue, 12 Apr 1994 12:37:27 -0700 Received: from toad.tadpole.com by tadpole.tadpole.com (4.1/SMI-4.1-jim) id AA04211; Tue, 12 Apr 94 14:37:00 CDT Date: Tue, 12 Apr 94 14:37:00 CDT From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9404121937.AA04211@tadpole.tadpole.com> To: Matt.Sherek@plym.fingerhut.com, langston@isi.com Subject: Re: Monitoring E-mail traffic through firewall Cc: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At the risk of contributing toward what appears to be the beginning of a fine flame fest: a) I side with the privacy folks. b) I realize that the company can control its resources as it sees fit. c) You would be well-advised to notify your users that this is happening, as otherwise you're leaving yourself wide-open to a big lawsuit. There may be some risk of 'outside' folks getting pissed and filing suit as well. d) What you want can be cooked-up in Perl (if you like Perl), or awk in 30 minutes or less, using the sendmail log file (via syslog). Jim From firewalls-owner Tue Apr 12 19:56:09 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA15506; Tue, 12 Apr 1994 19:56:09 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA15499; Tue, 12 Apr 1994 12:55:59 -0700 Received: by relay.tis.com; id AA26480; Tue, 12 Apr 94 15:56:26 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma026475; Tue Apr 12 15:55:41 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA27820; Tue, 12 Apr 94 15:54:41 EDT From: Marcus J Ranum Received: by otter.tis.com (4.1/SMI-4.1) id AA05016; Tue, 12 Apr 94 15:54:40 EDT Date: Tue, 12 Apr 94 15:54:40 EDT Message-Id: <9404121954.AA05016@otter.tis.com> To: Firewalls-Digest@GreatCircle.COM, Matt.Sherek@plym.fingerhut.com Subject: Re: Monitoring E-mail traffic through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk If you're using the firewall toolkit, there's a mail summarizer for smap traffic that summarizes the top 'N' senders and recips. It should be portable to use sendmail system log entries with a little hammering, though sendmail doesn't log things as nicely, IMHO. The smap summarizer is in a file named fwtk/tools/admin/reporting/smap-summ.sh One thing it does is disassociates (deliberately) the senders and recips, to somewhat protect the user's privacy. mjr. From firewalls-owner Tue Apr 12 12:59:57 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA15438; Tue, 12 Apr 1994 19:46:19 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA15432; Tue, 12 Apr 1994 12:46:07 -0700 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA29679; Tue, 12 Apr 94 14:21:18 -0500 Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA21627; Tue, 12 Apr 94 14:17:31 CDT Date: Tue, 12 Apr 94 14:17:31 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9404121917.AA21627@anubis.network.com> To: Firewalls-Digest@GreatCircle.COM, Matt.Sherek@plym.fingerhut.com, langston@isi.com Subject: Re: Monitoring E-mail traffic through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Please let's keep the issues of whether such and such a policy is right or wrong off the list, please? As for how to do it, running sendmail at a sufficiently high debug level produces To, From and Size info in wherever syslogd sends your mail logs. It's not terrifically neat, but a little awking could generate nifty reports easily. I have OL20 in my sendmail.cf, which generates copious log information, but may be somewhat higher than necessary to get what you want. Andrew From firewalls-owner Tue Apr 12 20:07:46 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA15577; Tue, 12 Apr 1994 20:07:46 GMT Received: from research.att.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA15571; Tue, 12 Apr 1994 13:07:39 -0700 From: smb@research.att.com Message-Id: <199404122007.NAA15571@mycroft.GreatCircle.COM> Received: by gryphon; Tue Apr 12 16:05:58 EDT 1994 To: Firewalls-Digest@GreatCircle.COM Subject: Re: Monitoring E-mail traffic through firewall Date: Tue, 12 Apr 94 16:05:53 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At the risk of contributing toward what appears to be the beginning of a fine flame fest: etc. By the authority vested in me by Brent before he left on a trip: STOP This is exactly the sort of discussion considered inappropriate for the Firewalls list. From firewalls-owner Tue Apr 12 13:09:37 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA15444; Tue, 12 Apr 1994 19:46:32 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA15431; Tue, 12 Apr 1994 12:46:07 -0700 Received: from localhost by bedrock.cs.UMD.EDU (8.6.5/UMIACS-0.9/04-05-88) id PAA28345; Tue, 12 Apr 1994 15:45:38 -0400 Date: Tue, 12 Apr 1994 15:45:38 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <199404121945.PAA28345@bedrock.cs.UMD.EDU> To: Firewalls-Digest@GreatCircle.COM, Matt.Sherek@plym.fingerhut.com Subject: Re: Monitoring E-mail traffic through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk * From: Matt.Sherek@plym.fingerhut.com (Matt Sherek) * To: Firewalls-Digest@GreatCircle.COM * Subject: Monitoring E-mail traffic through firewall * * All, * Does anyone know of a good way to monitor E-mail traffic to users * on your network? * I'm looking for something that will tell me: * * To From Size Time * * something like that. * * Any help would be appreciated. I've already read the flame to this posting, and I agree that it's uncalled for. The information above is very useful for charging back users/departments against channel utilization, and if you've got all of your mail going out a single gateway (what a concept ;), then that's the best place to measure it. You can also use the data for other things like: if someone who's just put in their two week notice is starting to mail Size:Big_Megabyte messages, or is increasing the frequency of their smaller messages, that is a red flag IMO. My suggestion is to write a perl script that parses the (e.g., Sun 4.1) /var/log/syslog file on some periodic basis. Everything you want is there. (a different) Richard From firewalls-owner Tue Apr 12 13:19:40 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA15428; Tue, 12 Apr 1994 19:45:36 GMT Received: from london.micrognosis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA15422; Tue, 12 Apr 1994 12:45:22 -0700 Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA27132; Tue, 12 Apr 94 20:44:13 BST Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma027129; Tue Apr 12 20:43:16 1994 Received: from moria by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA29100; Tue, 12 Apr 94 20:43:07 BST From: nreadwin@london.micrognosis.com (Neil Readwin) Received: by moria (4.1//ident-1.0) id AA26794; Tue, 12 Apr 94 20:43:06 BST Message-Id: <9404121943.AA26794@moria> Subject: Re: Monitoring E-mail traffic through firewall To: langston@isi.com (Richard Langston x247) Date: Tue, 12 Apr 1994 20:43:06 +0100 (BST) Cc: Firewalls-Digest@GreatCircle.COM, Matt.Sherek@plym.fingerhut.com In-Reply-To: <9404121835.AA17488@chief.isi.com> from "Richard Langston x247" at Apr 12, 94 11:35:28 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1535 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Richard, > Well, I don't see how that belongs on this list, but personally > I think everything except "Size" is none of your business... Security > doesn't have anything to do with evesdroping... With all due respect, that is nonsense. Firstly, eavesdropping *is* a legitimate tool in the toolbag of the person responsible for security. This is as true of e-mail as it is for telephones, and yes, I know of people whose phone calls are routinely monitored and/or recorded (they know in advance that this will occur, they are free to find an employer who won't tap their phone). Secondly, consider the defect tracking product that we run that uses e-mail to keep remote databases in sync. Knowing that it is exchanging x Mb of mail with site A and y Mb with site B is probably more interesting to me than the fact that last week we shifted 1294cps of NNTP traffic through our firewall 24x7x60x60. The easiest way to find that out is to analyze the mailer logs for from/to/size/time data. Thirdly, my employer owns the machines. I signed a contract saying I would only use them for business purposes. Even though that is very loosely interpreted they are free to impose a policy that forbids personal e-mail through the firewalls. If they did so then quite likely we would enforce that by monitoring the logs, not by adding yet more code to a mailer system that is already about 50000 lines too long. -- nreadwin@london.micrognosis.com Phone: +1 718 273 8234 Anything is a cause for sorrow that my mind or body has made From firewalls-owner Tue Apr 12 20:24:05 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA15688; Tue, 12 Apr 1994 20:24:05 GMT Received: from openlink.openlink.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA15682; Tue, 12 Apr 1994 13:23:48 -0700 Received: from autodesk.UUCP by openlink.openlink.com with UUCP id AA25203 (5.67b/IDA-1.5 for Firewalls-Digest@greatcircle.com); Tue, 12 Apr 1994 13:24:48 -0700 Received: from meefun.autodesk.com by autodesk.com (4.1/MADMAX-RED-CUCCIA) id AA26284; Tue, 12 Apr 94 13:07:40 PDT Received: from localhost by meefun.autodesk.com (8.6.5/SMI-5.3) with SMTP id NAA17914; Tue, 12 Apr 1994 13:07:38 -0700 Message-Id: <199404122007.NAA17914@meefun.autodesk.com> X-Authentication-Warning: meefun: andy owned process doing -bs To: Matt.Sherek@plym.fingerhut.com (Matt Sherek) Cc: Firewalls-Digest@greatcircle.com Subject: Re: Monitoring E-mail traffic through firewall In-Reply-To: Your message of "Tue, 12 Apr 1994 13:14:28 +0600." <9404121814.AA01726@norma-jean.plym.fingerhut.com> Date: Tue, 12 Apr 1994 13:07:36 -0700 From: Andrew Purshottam Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Isn't this a sendmail issue? Permit mail traffic from outside to your mail host only, and config sendmail to forward to appropriate user@inside_host though aliases. Least that's how I used to do it, and how I think its done (by others) for me now. From firewalls-owner Tue Apr 12 13:29:37 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA15387; Tue, 12 Apr 1994 19:39:02 GMT Received: from erenj.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA15380; Tue, 12 Apr 1994 12:38:49 -0700 Posted-Date: Tue, 12 Apr 1994 15:38:54 -0400 From: bdboyle@maverick1.erenj.com (Bryan D. Boyle) Message-Id: <9404121538.ZM666@maverick1.erenj.com> Date: Tue, 12 Apr 1994 15:38:54 -0400 In-Reply-To: langston@isi.com (Richard Langston x247) "Re: Monitoring E-mail traffic through firewall" (Apr 12, 11:35am) References: <9404121835.AA17488@chief.isi.com> X-Mailer: Z-Mail (2.1.0 10/1/92) To: Firewalls-Digest@GreatCircle.COM Subject: Re: Monitoring E-mail traffic through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Apr 12, 11:35am, Richard Langston x247 wrote: > Subject: Re: Monitoring E-mail traffic through firewall > > All, > > Does anyone know of a good way to monitor E-mail traffic to users > > on your network? > > I'm looking for something that will tell me: > > > > To From Size Time > > > Well, I don't see how that belongs on this list, but personally > I think everything except "Size" is none of your business... Security > doesn't have anything to do with evesdroping... >-- End of excerpt from Richard Langston x247 Why on this list? Frequently (well, in many cases...) the mail in/out log is kept on the firewall syslog. I know many of us have [perl,awk,grep,egrep,etc] scripts to glom that data out of the log and reduce it to something meaningful. Unless, that is, you don't monitor your firewall goings-on. None of your business? Depends on the company you work for. Providing these gateway services and the firewalls they run on is a physical manifestation of your corporate security and acceptable use policies. If you work for a company that is providing access to the internet, _they_, not you, own the service. It is there for their benefit. Not yours. The fact that they may not actively monitor your mail does not mean that they can't, and, in fact, that may be part of their active security measures for preventing loss of intellectual property if they think you are shipping the company secrets out the net.pipe. That is aside from the fact that frequently the front door is more leaky... corporate audit types are more concerned about the net connection, since its transaction happens almost instantaneously between machines. Like most corporations are quick to point out, if you don't like the policies, you are free to find your path elsewhere. If you don't like the fact that the company _may_ monitor your mail usage, you don't have to use their mail service. Just my $.02, only my $.02. -- Bryan D. Boyle |Physical: ER&E, Clinton, NJ (908) 730-3338 #include |Virtual: bdboyle@erenj.com "If everyone is thinking alike, then someone isn't thinking." -Patton Pardon me, I'm lost, can you direct me to the information superhighway? From firewalls-owner Tue Apr 12 20:57:43 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA15811; Tue, 12 Apr 1994 20:57:43 GMT Received: from relay.tandy.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA15805; Tue, 12 Apr 1994 13:57:31 -0700 Received: from tcgw.tandy.com by relay.tandy.com (5.65/3.1.090690) id AA21739; Tue, 12 Apr 94 15:55:26 -0500 Received: from tisdec.tis.tandy.com by tcgw.tandy.com (5.65/3.1.090690) id AA29959; Tue, 12 Apr 94 15:53:45 -0500 Received: by tisdec.tis.tandy.com (5.65/DEC-Ultrix/4.3) id AA03622; Tue, 12 Apr 1994 15:53:37 -0500 From: chris@tisdec.tis.tandy.com (Chris Riney) Message-Id: <9404122053.AA03622@tisdec.tis.tandy.com> Subject: Re: Monitoring E-mail traffic through firewall To: langston@isi.com (Richard Langston x247) Date: Tue, 12 Apr 1994 15:53:35 -0500 (CDT) Cc: firewalls@greatcircle.com In-Reply-To: <9404121835.AA17488@chief.isi.com> from "Richard Langston x247" at Apr 12, 94 11:35:28 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 894 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > All, > > Does anyone know of a good way to monitor E-mail traffic to users > > on your network? > > I'm looking for something that will tell me: > > > > To From Size Time > > > Well, I don't see how that belongs on this list, but personally > I think everything except "Size" is none of your business... Security > doesn't have anything to do with evesdroping... > Message size might not have much to do with security, but it sure has a lot to do with capacity planning and billing. And capacity planning is intertwined with security. ========================================================================== Chris Riney E-mail: chris@sasoom.tis.tandy.com Tandy Information Services chris.riney@tandy.com Tandy Technology Sqr, Suite 200 Fort Worth, TX 76102 Phone: 817/878-0308; 8:00am-5:00pm CST,Mo-Fr /* opinion is mine alone. */ From firewalls-owner Tue Apr 12 21:05:13 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA15862; Tue, 12 Apr 1994 21:05:13 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA15854; Tue, 12 Apr 1994 14:04:55 -0700 Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA28484; Tue, 12 Apr 94 17:03:29 EDT Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA03020; Tue, 12 Apr 94 17:02:13 EDT Date: Tue, 12 Apr 94 17:02:13 EDT From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9404122102.AA03020@s.ecc.engr.uky.edu> To: firewalls@greatcircle.com Subject: Monitoring email through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >a) I side with the privacy folks. In normal, routine situations, I err on the side of privacy. >c) You would be well-advised to notify your users that this is happening, > as otherwise you're leaving yourself wide-open to a big lawsuit. There > may be some risk of 'outside' folks getting pissed and filing suit as well. Keep in mind that there is a *huge* difference between collecting the information and what one does with it. I am *routinely* called upon to trace email problems that date back days, weeks, or even months. It's *extremely* handy to have log files to check. If one is routing all external email through a firewall, why not log it? (It should be noted that audit trails, such as this one, will be in high demand as more and more business is conducted online. I won- der if ora.com, with its credit-card-sales-via-email facility, logs messages to/from its ordering address, or to/from its sales personnel?) I log every email message that comes through my mail hub. The *only* thing anyone other than me sees during routine operations is something like this: Begin date: 11 Apr 08:39:41 End date: 12 Apr 15:41:39 Internal messages: 832 Local messages: 179 (58 incoming, 71 outgoing) Off-campus messages: 739 (458 incoming, 319 outgoing) Pending errors: 9 Yes, I keep the log files around; no, I do not divulge their contents. No, I perform no logging whatsoever of the *content* of the messages. As far as 'lawsuit awareness' goes, here's an interesting excerpt from the Electronic Communications Privacy Act: > (h) It shall not be unlawful under this chapter-- > > [...] > > (ii) for a provider of electronic communication service to record the >fact that a wire or electronic communication was initiated or completed in >order to protect such provider, another provider furnishing service toward >the completion of the wire or electronic communication, or a user of that >service, from fraudulent, unlawful or abusive use of such service. If you're thinking about a potential ECPA lawsuit, I would think that this exemption allows us to log the nuts and bolts of email traffic. It might be worthwhile to run this one past Mike Godwin; when last this subject came up, the consensus was that such non-content-based logging was legal *as long as* the information was kept confidential, and as long as the *content* of the messages was not monitored. [ An online copy of the ECPA may be retrieved via anonymous FTP from ] [ ftp.eff.org: /pub/eff/Policy/Legal/ecpa.law ] Whether we like it or not, folks, issues like this one will be coming to the fore as more businesses join the net. Rather than flaming, let's work for some acceptable solutions/compromises. --Wes From firewalls-owner Tue Apr 12 14:09:38 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA15792; Tue, 12 Apr 1994 20:54:25 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA15786; Tue, 12 Apr 1994 13:54:17 -0700 Received: from magna.magna.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwlix21902; Tue, 12 Apr 94 16:54:20 -0400 Received: from magna20.magna.com by magna.magna.com (5.65/MSC-0.9) id AA00607; Tue, 12 Apr 94 16:45:02 -0400 Received: by magna20.magna.com (BOSX 3.2/UCB 5.64/MSC-1.0) id AA35843; Tue, 12 Apr 1994 16:48:02 -0400 Date: Tue, 12 Apr 1994 16:48:02 -0400 From: "Matt D'Errico" Message-Id: <9404122048.AA35843@magna20.magna.com> To: Matt.Sherek@plym.fingerhut.com, langston@isi.com Subject: Re: Monitoring E-mail traffic through firewall Cc: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Keep in mind that there is already pending legislation in the US Congress roughly equating EMail delivery with US Postal proivacy... This doesn't preclude a company's right to audit mail, nor access it should an employee leave a company... But it does preclude the "right" to read the mail (i.e.: "Open" it) without just cause... -- Doc From firewalls-owner Tue Apr 12 14:19:38 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA15802; Tue, 12 Apr 1994 20:55:46 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA15796; Tue, 12 Apr 1994 13:55:38 -0700 Received: by relay.tis.com; id AA27175; Tue, 12 Apr 94 16:56:05 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma027168; Tue Apr 12 16:55:46 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA03212; Tue, 12 Apr 94 16:54:49 EDT From: Marcus J Ranum Received: by otter.tis.com (4.1/SMI-4.1) id AA05723; Tue, 12 Apr 94 16:54:47 EDT Date: Tue, 12 Apr 94 16:54:47 EDT Message-Id: <9404122054.AA05723@otter.tis.com> To: Firewalls-Digest@GreatCircle.COM, Matt.Sherek@plym.fingerhut.com, reh@cs.UMD.EDU Subject: Re: Monitoring E-mail traffic through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I've already read the flame to this posting, and I agree that it's >uncalled for. The information above is very useful for charging >back users/departments against channel utilization, and if you've >got all of your mail going out a single gateway (what a concept ;), >then that's the best place to measure it. You can also use the data >for other things like: if someone who's just put in their two week >notice is starting to mail Size:Big_Megabyte messages, or is increasing >the frequency of their smaller messages, that is a red flag IMO. When I ran a similar thing on one machine, I discovered that the top mail recipient one week was: someone@some.machine: 15mb some-mailing-list-errors: 15mb At that point, I cross-indexed the summary and determined that someone was on a very high volume mailing list and his account had been deleted when he left the company. So, it was nice to be able to fix that. I've also found that when some mailing list sends a huge number of messages to 5 or 6 users, it's time to politely, "ahem" and suggest an internal mail exploder. One guy's "fascism" is another guy's "good systems managment" but I don't think we're going to clarify the dividing line in this mailing list. At least I hope we don't try. mjr. From firewalls-owner Tue Apr 12 16:29:39 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA16632; Tue, 12 Apr 1994 23:18:52 GMT Received: from mapp.org by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA16625; Tue, 12 Apr 1994 16:18:39 -0700 Received: by mapp.org (5.0/SMI-SVR4(MAPPCOR 01/03/94-01)) id AA01581; Tue, 12 Apr 1994 16:35:27 +0600 Date: Tue, 12 Apr 1994 16:35:27 +0600 From: bmv@mapp.org (BM.Vornbrock) Message-Id: <9404122135.AA01581@mapp.org> To: firewalls-digest@greatcircle.com Subject: Re: Monitoring E-mail traffic through firewall X-Sun-Charset: US-ASCII content-length: 0 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In advance, please put up with this presentation style a bit: 1. > > All, > > Does anyone know of a good way to monitor E-mail traffic to users > > on your network? > > I'm looking for something that will tell me: > > > > To From Size Time > > Well, I don't see how that belongs on this list, but personally > I think everything except "Size" is none of your business... Security > doesn't have anything to do with evesdroping... 2. > > > > Our policy at Fingerhut is, if it uses our resources it's our business. > > Not my policy, but I do agree with it. > > 3. > > Firewalls != email monitoring > > Firewalls = safe internet connections Comments: My initial reaction to 1. was: here was a start at examining eMail as a potential source of security problems where known who from/to and how big _might_ be a crude first cut at scoping a potential problem. I've appreciated this lists willingness to tolerate and educate novices, like me, and I put 1. into that category: tolerate and reply in the spirit of the firewalls list. The personal thrust in the reply to it seems like a flame and that I've been led to believe, by earlier traffic, is out of bounds. My reaction to two: knee jerk to the thrust. 3. : Firewalls = safer Internet connections, perhaps originating in the concepts surrounding firebreaks (that firefighters use); range seems to go from "similar to a security guard -- 'I will clear that before it goes in' (at many levels of detail) to extensive, custom, moat/castle bastions and expands out out from there. So, any spirited educators out there? From firewalls-owner Wed Apr 13 00:20:57 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA17138; Wed, 13 Apr 1994 00:20:57 GMT Received: from cheetah.llnl.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA17132; Tue, 12 Apr 1994 17:20:35 -0700 Received: (from karyn@localhost) by cheetah.llnl.gov (8.6.8.1/8.6.6) id RAA19404; Tue, 12 Apr 1994 17:20:31 -0700 Date: Tue, 12 Apr 1994 17:20:31 -0700 From: Karyn Pichnarczyk Message-Id: <199404130020.RAA19404@cheetah.llnl.gov> To: firewalls@greatcircle.com Subject: Monitoring email through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Please, people, Stop! 1. Discussing the privacy issues involved with email is not related to Firewalls! 2. Discussing how much space email takes up is not related to Firewalls! 3. Trying to justify a conversation about email by throwing in a comment that it gets routed through a firewall does not belong on this list! 4. comments like this: Whether we like it or not, folks, issues like this one will be coming to the fore as more businesses join the net. Rather than flaming, let's work for some acceptable solutions/compromises. should be discussed, but not on inappropriate mailing lists. Please! take the conversation to another forum, I suggest alt.flame. I didn't join the firewalls mailing list to hear about email/privacy/legislation/etc issues! karyn From firewalls-owner Wed Apr 13 00:31:07 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA17204; Wed, 13 Apr 1994 00:31:07 GMT Received: from mbunix.mitre.org by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA17198; Tue, 12 Apr 1994 17:30:48 -0700 From: bede@scotty.mitre.org Received: from scotty.mitre.org by mbunix.mitre.org (8.6.4/4.7) id UAA23246; Tue, 12 Apr 1994 20:30:25 -0400 Posted-from: The MITRE Corporation, Bedford, MA Received: by scotty.mitre.org (8.6.7/ITF-Bedford) id UAA03385; Tue, 12 Apr 1994 20:29:40 -0400 Date: Tue, 12 Apr 1994 20:29:40 -0400 Message-Id: <199404130029.UAA03385@scotty.mitre.org> To: Matt.Sherek@plym.fingerhut.com CC: Firewalls-Digest@GreatCircle.COM In-reply-to: Matt Sherek's message of Tue, 12 Apr 1994 13:14:28 +0600 <9404121814.AA01726@norma-jean.plym.fingerhut.com> Subject: RE: Monitoring E-mail traffic through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Date: Tue, 12 Apr 1994 13:14:28 +0600 > From: Matt.Sherek@plym.fingerhut.com (Matt Sherek) > > All, > Does anyone know of a good way to monitor E-mail traffic to users > on your network? > I'm looking for something that will tell me: > > To From Size Time > > [ . . . ] Assuming you're using a UNIX host, sendmail normally syslog()'s all this information, albeit not on a single line. For example, here's my local sendmail's log output for your "firewalls" posting: Apr 12 14:25:31 scotty sendmail[2195]: OAA02195: from=, size=1617 ... Apr 12 14:25:32 scotty sendmail[2197]: OAA02195: to= ... The usual thing to do is begin by dropping your sendmail syslog output into a single log file. For example, your /etc/syslog.conf should have a line something like this in it: mail.debug /var/log/mail.log You can identify related syslog lines simply by looking at sendmail's local ID ("OAA02195" in the above) for the message. - Bede B. McCall The MITRE Corporation Burlington Road Bedford, Massachusetts From firewalls-owner Wed Apr 13 00:41:52 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA17240; Wed, 13 Apr 1994 00:41:52 GMT Received: from amdahl.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA17233; Tue, 12 Apr 1994 17:41:44 -0700 Received: by amdahl.com (/\==/\ Smail #25.33) id ; Tue, 12 Apr 94 17:42 PDT Received: from idontcare.eng.amdahl.com by cliffy.eng.amdahl.com (4.1/SMI-4.1) id AA06769; Tue, 12 Apr 94 17:41:15 PDT Date: Tue, 12 Apr 94 17:41:15 PDT From: pjh70@eng.amdahl.com (Patrick J Horgan) Message-Id: <9404130041.AA06769@cliffy.eng.amdahl.com> To: Matt.Sherek@plym.fingerhut.com, langston@isi.com, jim@Tadpole.COM Subject: Re: Monitoring E-mail traffic through firewall Cc: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk While this is interesting, and of interest to some of the same people that are interested in firewalls, it's not really about firewalls. If you want to discuss the pros and cons of monitoring people's email, (or how to do it,) try the newsgroups: comp.admin.policy, and news.admin.policy. I think an occasional request for help off the firewalls subject is ok, after all we have a lot of expertise here, but if you do, please ask for responses by private email. (And throw in a few mea culpas;) Patrick These opinions are mine, and not Amdahl's (except by coincidence;). ~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ / | | (\ \ | Patrick J. Horgan | Amdahl Corporation | \\ Have | | pjh70@eng.amdahl.com | 1250 East Arques Avenue | \\ _ Sword | | Phone : (408)992-2779 | P.O. Box 3470 M/S 253 | \\/ Will | | FAX : (408)773-0833 | Sunnyvale, CA 94088-3470 | _/\\ Travel | \ | | \) / ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ From firewalls-owner Wed Apr 13 01:18:09 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA17365; Wed, 13 Apr 1994 01:18:09 GMT Received: from research.att.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA17358; Tue, 12 Apr 1994 18:18:02 -0700 From: smb@research.att.com Message-Id: <199404130118.SAA17358@mycroft.GreatCircle.COM> Received: by gryphon; Tue Apr 12 21:17:14 EDT 1994 To: morgan@engr.uky.edu (Wes Morgan) cc: firewalls@GreatCircle.COM Subject: Re: Monitoring email through firewall Date: Tue, 12 Apr 94 21:17:13 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > As far as 'lawsuit awareness' goes, here's an interesting excerpt from > the Electronic Communications Privacy Act: > > > (h) It shall not be unlawful under this chapter-- > > > > [...] > > > > (ii) for a provider of electronic communication service to record the > >fact that a wire or electronic communication was initiated or completed in > >order to protect such provider, another provider furnishing service toward > >the completion of the wire or electronic communication, or a user of that > >service, from fraudulent, unlawful or abusive use of such service. > > If you're thinking about a potential ECPA lawsuit, I would think that > this exemption allows us to log the nuts and bolts of email traffic. > It might be worthwhile to run this one past Mike Godwin; when last this > subject came up, the consensus was that such non-content-based logging > was legal *as long as* the information was kept confidential, and as > long as the *content* of the messages was not monitored. Sorry, but I'm fairly certain that you've drawn the wrong conclusion from that excerpt from the ECPA. According to @article{hernandez, title = {{ECPA} and Online Computer Privacy}, author = {Ruel Torres Hernandez}, journal = {Federal Communications Law Journal}, volume = 41, number = 1, month = {November}, year = 1988, pages = {17--41} } the legislative history of the ECPA indicates that it does not bar monitoring of messages sent to or from employees on company-owned machines. The sponsors wanted to do that, but felt they couldn't get such a provision passed. Bills are pending to change that -- H.R.1900 and S.984, if I'm not mistaken. From firewalls-owner Wed Apr 13 01:45:33 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA17495; Wed, 13 Apr 1994 01:45:33 GMT Received: from ricohigw.ricoh.co.jp by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA17489; Tue, 12 Apr 1994 18:45:22 -0700 Received: from eagle.src.ricoh.co.jp (root@eagle.src.ricoh.co.jp [133.139.214.29]) by ricohigw.ricoh.co.jp (8.6.8+2.4Wb/3.3Wb-0.93) with SMTP id KAA11883 for ; Wed, 13 Apr 1994 10:45:23 +0900 Received: from localhost.src.ricoh.co.jp by eagle.src.ricoh.co.jp (4.1/2.8Wb-s1.1) id AA24755; Wed, 13 Apr 94 10:45:21 JST Message-Id: <9404130145.AA24755@eagle.src.ricoh.co.jp> To: firewalls@greatcircle.com Subject: Re: Monitoring E-mail traffic through firewall In-Reply-To: Your message of Tue, 12 Apr 1994 15:45:38 -0400. <199404121945.PAA28345@bedrock.cs.UMD.EDU> Date: Wed, 13 Apr 1994 10:45:21 +0900 From: Akihiro Nishida Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: reh@cs.UMD.EDU (Richard Huddleston) Subject: Re: Monitoring E-mail traffic through firewall Date: Tue, 12 Apr 1994 15:45:38 -0400 > * From: Matt.Sherek@plym.fingerhut.com (Matt Sherek) > * To: Firewalls-Digest@GreatCircle.COM > * Subject: Monitoring E-mail traffic through firewall > * > * All, > * Does anyone know of a good way to monitor E-mail traffic to users > * on your network? > * I'm looking for something that will tell me: > * > * To From Size Time > * > * something like that. > * > * Any help would be appreciated. > My suggestion is to write a perl script that parses the (e.g., Sun 4.1) > /var/log/syslog file on some periodic basis. Everything you want is there. There is a perl script called 'fromto' by utashiro@sra.co.jp (Kazumasa Utashiro). There is no information about size, but you can modify to show that information. output examples is as follows. Apr 13 10:30 firewalls-owner@GreatCircl -> nishida@lennon.src.ricoh.co.jp try ftp://srawgw.sra.co.jp/pub/lang/perl/sra-scripts/fromto-1.2 ------------------------------------------------------- Ricoh Company, Ltd. Akihiro Nishida Software Research Center nishida@src.ricoh.co.jp ------------------------------------------------------- From firewalls-owner Wed Apr 13 02:33:12 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA17670; Wed, 13 Apr 1994 02:33:12 GMT Received: from lloyd.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA17664; Tue, 12 Apr 1994 19:33:03 -0700 Received: by lloyd.com (Smail3.1.28.1 #3) id m0pqulM-000ERtC; Tue, 12 Apr 94 19:33 PDT Message-Id: To: Firewalls@greatcircle.com cc: Firewalls-Digest@greatcircle.com Subject: Monitoring Email traffic In-reply-to: Your message of "Tue, 12 Apr 1994 18:47:14 PDT." <199404130147.SAA17512@mycroft.GreatCircle.COM> Date: Tue, 12 Apr 1994 19:33:11 -0700 From: Howard Chu Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I wrote a program to digest sendmail logs about 7 years ago (yah, before anybody ever heard of PERL. This is C code...) that we used to monitor traffic, detect problems, etc. I posted it to net.sources, you might be able to find it still (under the name "zlog"). Here's a sample of the output... [Don't worry, the sample is about 7 years old too.] [I realize this has nothing to do with firewalls, and I don't care to get involved in any privacy flamefest, but the question was posted here, so the answer is here.] Summary of mail log from Aug 14 04:14:34 to Aug 14 22:35:45 ... Host or Messages Bytes Avg Len Avg Send Send Domain recv/sent recv/sent recv/sent Delay Tries polymnia 12/12 63417/63417 5284/5284 02:08:30 30(1) edu 12/12 63417/63417 5284/5284 00:00:06 12 org 0/0 0/0 0/0 1+03:49:12 18(1) mit.edu 1/0 2588/0 2588/0 00:00:00 0 umich.edu 11/12 60829/63417 5529/5284 00:00:06 12 ai.mit.edu 1/0 2588/0 2588/0 00:00:00 0 reagan.ai.mit.edu 1/0 2588/0 2588/0 00:00:00 0 cc.umich.edu 10/0 59702/0 5970/0 00:00:00 0 lsa.umich.edu 1/12 1127/63417 1127/5284 00:00:06 12 mailgw.cc.umich.ed 4/0 8647/0 2161/0 00:00:00 0 starbarlounge.cc.u 1/0 1464/0 1464/0 00:00:00 0 umix.cc.umich.edu 5/0 49591/0 9918/0 00:00:00 0 math.lsa.umich.edu 1/12 1127/63417 1127/5284 00:00:06 12 fidonet.org 0/0 0/0 0/0 1+03:49:12 18(1) rubbs1.fidonet.org 0/0 0/0 0/0 1+03:49:12 18(1) Host or Messages Bytes Avg Len Avg Send Send Domain recv/sent recv/sent recv/sent Delay Tries stag 1/1 983/983 983/983 00:00:02 1 edu 1/1 983/983 983/983 00:00:02 1 umich.edu 1/1 983/983 983/983 00:00:02 1 lsa.umich.edu 1/1 983/983 983/983 00:00:02 1 math.lsa.umich.edu 1/1 983/983 983/983 00:00:02 1 -- Howard Chu, Sr. Systems Engineer Lloyd Internetworking howard@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From firewalls-owner Wed Apr 13 04:04:11 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA17865; Wed, 13 Apr 1994 04:04:11 GMT Received: from ax.ibase.br by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA17859; Tue, 12 Apr 1994 21:03:59 -0700 Received: by ax.ibase.br (8.6.8.1/Revision: 1.10 ) id BAA11105; Wed, 13 Apr 1994 01:00:43 -0300 From: Fernando Cabral To: langston@isi.com, Firewalls-Digest@greatcircle.com, Matt.Sherek@plym.fingerhut.com Subject: Re: Monitoring E-mail traffic through firewall X-Mailer: ScoMail 1.0 Date: Tue, 12 Apr 1994 19:59:51 +0100 (BST) Message-ID: <9404121959.aa17821@boemia.pix.com.br> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk => > Does anyone know of a good way to monitor E-mail traffic to users => > on your network? => > I'm looking for something that will tell me: => > => > To From Size Time => => => Well, I don't see how that belongs on this list, but personally => I think everything except "Size" is none of your business... Security => doesn't have anything to do with evesdroping... My 0.01 worth: *Security doesn't have anything to do with evesdroping* - Perfect. Nevertherless, the netter might have the same problem I have: Many differente connections using Local Ethernet, local phone line, leased line, international phone lines... Problem here is: I shouldn't charge a Ethernet mail transfer the same as an international call. I have costs varying from about $4 (that 4 US dollars) a minute, with low speed lines, up to very small costs in connection between two machines connected back-back. Besides that, if I don't know where the traffic comes from and where it goes to, I wont be able take reasonable decision based on effective demand, not in my opinion. Weren't I to know the To/From/Time information I wouldn't be able to charge the user accordingly. Is it fair to have someone who only send mail to his neigbour pay the same as his colleague who sends and receives international mail every other minute. Checking contents is a quite different thing... - fernando Fernando Cabral fcabral@ibase.br PADRAO iX Sistemas Abertos voice: +55 61 274-6092 fax: +55 61 274-5302 Modem: +55 61 273-5559 From firewalls-owner Wed Apr 13 04:37:00 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA17940; Wed, 13 Apr 1994 04:37:00 GMT Received: from shadow.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA17934; Tue, 12 Apr 1994 21:36:52 -0700 Received: (cklaus@localhost) by shadow.net (8.6.8.1/jc-1.0) id AAA22561 for firewalls@greatcircle.com; Wed, 13 Apr 1994 00:38:44 -0400 From: Christopher Klaus Message-Id: <199404130438.AAA22561@shadow.net> Subject: Wu-FTP info. To: firewalls@greatcircle.com Date: Wed, 13 Apr 94 0:38:43 EDT X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk CERT information is misleading. Even if you do not have the trojan wu-ftpd version, Versions before 2.2 are insecure and have a major security hole. You think that CERT would have at least mentioned that even if your src for ftpd was not trojaned, please get the 2.3 version. I am not sure what the point of not releasing that information. EMPHASIS: Get wu-ftpd2.3! even if your src was not trojaned. Anyways, Graham Toal has pointed this out. To fix the security hole in previous version 2.3: 1. remove "site exec" from commands. 2. stop anonymous uploading via adding "chmod no anonymous" and "umask no anonymous" to ftpaccess file. 3. remove ftp-exec subdirectory in ~ftp/bin 4. Obtain and install wu-ftpd 2.3 Below is the information for Trojaned version. But even if you do not have Trojaned version, you will need to install wu-ftpd2.3. Here is some information that may help you know if you have a trojan version. you can grep \"NULL\" in *.c for that will let you know if you have the trojan. the password checking routine in ftpd.c should probably not differ from the following: #ifdef ULTRIX_AUTH if ((numfails = ultrix_check_pass(passwd, xpasswd)) < 0) { #else /* The strcmp does not catch null passwords! */ if (pw == NULL || *pw->pw_passwd == '\0' || strcmp(xpasswd, pw->pw_passwd)) { #endif reply(530, "Login incorrect."); -- Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner 2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)998-5871. From firewalls-owner Wed Apr 13 17:22:09 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA20569; Wed, 13 Apr 1994 17:22:09 GMT Received: from ddnmail.fnoc.navy.mil by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA20563; Wed, 13 Apr 1994 10:21:55 -0700 Received: by ddnmail.fnoc.navy.mil (4.1/SMI-4.1) id AA18943; Wed, 13 Apr 94 17:20:02 GMT Received: from gds-03.fnoc.navy.mil by ccpa.fnoc.navy.mil (4.1/SMI-4.1) id AA05972; Wed, 13 Apr 94 17:19:56 GMT Received: by gds-03.fnoc.navy.mil (4.1/SMI-4.1) id AA01262; Wed, 13 Apr 94 10:19:56 PDT From: jpack@fnoc.navy.mil (Jeff Pack) Message-Id: <9404131719.AA01262@gds-03.fnoc.navy.mil> Subject: Filtering NFS with Cisco ACLs To: firewalls@GreatCircle.COM Date: Wed, 13 Apr 94 10:19:55 BST X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am setting up an FDDI-Ethernet network and further partitioning that network using access lists on a cisco. The plan is to have one host as a file server on a subnet and one "secure" network that can only access the file server via NFS and only access two other hosts on the rest of the net. It would look something like this: 219 Subnet (Secure) |------------------| | | _ | | |------------------| | 6 Subnet | | | (File Server) | Cisco |---------| | | | |------------------| | | | | - | | |------------------| 201 Subnet (2 Others) So, just setting up the access lists on the 219 interface, I have: ! ! allow 2 others to access secure host access-list 101 permit ip 152.80.201.202 0.0.0.0 152.80.219.201 0.0.0.0 access-list 101 permit ip 152.80.201.204 0.0.0.0 152.80.219.201 0.0.0.0 ! ! allow server to provide NFS to secure host access-list 101 permit udp 152.80.6.201 0.0.0.0 152.80.219.201 0.0.0.0 eq 2049 where: 152.80.201.202 host 1 152.80.201.204 host 2 152.80.6.201 fileserver 152.80.219.201 secure host This allows host 1 and host 2 to connect to the secure host, but NFS doesn't work. It does work when I allow all udp traffic (i.e., remove the eq 2049). The fileserver is a Sun SS 10 running SunOS 4.1.3 and the "secure" host is another SS 10 running 4.1.3. Which additional ports do I need to specify to get *just* NFS to work? I'm sure someone has done this before.... -- Jeff Pack, Grumman Data Systems jpack@fnoc.navy.mil Fleet Numerical Meteorology and Oceanography Center Phone: (408) 656-4647 7 Grace Hopper Ave, Stop 1 FAX: (408) 656-4648 Monterey, CA 93943-5501 From firewalls-owner Wed Apr 13 23:18:46 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA22372; Wed, 13 Apr 1994 23:18:46 GMT Received: from george.arc.nasa.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA22366; Wed, 13 Apr 1994 16:18:38 -0700 Received: by george.arc.nasa.gov (8.6.8/1.35) id QAA27636; Wed, 13 Apr 1994 16:17:45 -0700 Date: Wed, 13 Apr 1994 16:17:45 -0700 From: jstevens@george.arc.nasa.gov (Judy Stevens -- IAS) Message-Id: <199404132317.QAA27636@george.arc.nasa.gov> To: firewalls@greatcircle.com Subject: probe_tcp_ports Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I am interested in obtaining this program. Is it available via anonymous ftp somewhere. I didn't find it using archie. thanks, Judy Stevens jstevens@ccf.arc.nasa.gov From firewalls-owner Thu Apr 14 00:32:41 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA22720; Thu, 14 Apr 1994 00:32:41 GMT Received: from ALABAMA.CF.CS.YALE.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA22714; Wed, 13 Apr 1994 17:32:29 -0700 Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Wed, 13 Apr 1994 20:32:30 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.67b/res.client.cf-3.7) id AA29058; Wed, 13 Apr 1994 20:32:29 -0400 Date: Wed, 13 Apr 1994 20:32:29 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199404140032.AA29058@SPARKY.CF.CS.YALE.EDU> To: firewalls@GreatCircle.COM, jstevens@george.arc.nasa.gov Subject: Re: probe_tcp_ports Cc: cert-tools@cert.org Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Hi, > I am interested in obtaining this program. Is it available via >anonymous ftp somewhere. I didn't find it using archie. > thanks, > Judy Stevens >jstevens@ccf.arc.nasa.gov I'm the author. I`ve appended a copy of the latest source to this message. I should probably send a copy to CERT tools someday.... H. Morrow Long, Mgr of Dev., Yale Univ., Comp Sci Dept, 011 AKW, New Haven, CT 06520-8285, VOICE: (203)-432-{1248,1254} FAX: (203)-432-0593 INET: Long-Morrow@CS.Yale.EDU UUCP: yale!Long-Morrow BITNET: Long-Morrow@YaleCS WWW: http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/long-morrow.html /* * $Header: probe_tcp_ports.c,v 1.3 93/10/01 12:54:46 long Exp $ * * probe_tcp_ports [-dhv] [hostname [hostname ...] ] * * H. Morrow Long, Manager of Development, Yale U CS Computing Facility * P. O. Box 208285, INET: Long-Morrow@CS.Yale.EDU * New Haven, CT 06520-8285 BITNET: Long-Morrow@YaleCS * (203)-432-{1248,1254} FAX: (203)-432-0593 * * $Log: probe_tcp_ports.c,v $ * Revision 1.3 93/10/01 12:54:46 long * Added RCS Keywords. * * */ #include #include #include #include #include #include #include #define RETURN_ERR -1 #define RETURN_FAIL 0 #define RETURN_SUCCESS 1 int Debug; int Hack; int Verbose; main(ArgC, ArgV) int ArgC; char **ArgV; { int Index; int SubIndex; for (Index = 1; (Index < ArgC) && (ArgV[Index][0] == '-'); Index++) for (SubIndex = 1; ArgV[Index][SubIndex]; SubIndex++) switch (ArgV[Index][SubIndex]) { case 'd': Debug++; break; case 'h': Hack++; break; case 'v': Verbose++; break; default: (void) fprintf(stderr, "Usage: probe_tcp_ports [-dhv] [hostname [hostname ...] ]\n"); exit(1); } for (; Index < ArgC; Index++) (void) Probe_TCP_Ports(ArgV[Index]); exit(0); } Probe_TCP_Ports(Name) char *Name; { unsigned Port; char *Host; struct hostent *HostEntryPointer; struct sockaddr_in SocketInetAddr; struct hostent TargetHost; struct in_addr TargetHostAddr; char *AddressList[1]; char NameBuffer[128]; extern int inet_addr(); extern char *rindex(); if (Name == NULL) return (RETURN_FAIL); Host = Name; if (Host == NULL) return (RETURN_FAIL); HostEntryPointer = gethostbyname(Host); if (HostEntryPointer == NULL) { TargetHostAddr.s_addr = inet_addr(Host); if (TargetHostAddr.s_addr == -1) { (void) printf("unknown host: %s\n", Host); return (RETURN_FAIL); } (void) strcpy(NameBuffer, Host); TargetHost.h_name = NameBuffer; TargetHost.h_addr_list = AddressList, TargetHost.h_addr = (char *) &TargetHostAddr; TargetHost.h_length = sizeof(struct in_addr); TargetHost.h_addrtype = AF_INET; TargetHost.h_aliases = 0; HostEntryPointer = &TargetHost; } SocketInetAddr.sin_family = HostEntryPointer->h_addrtype; bcopy(HostEntryPointer->h_addr, (char *) &SocketInetAddr.sin_addr, HostEntryPointer->h_length); for (Port = 1; Port < 65536; Port++) (void) Probe_TCP_Port(Port, HostEntryPointer, SocketInetAddr); return (RETURN_SUCCESS); } Probe_TCP_Port(Port, HostEntryPointer, SocketInetAddr) unsigned Port; struct hostent *HostEntryPointer; struct sockaddr_in SocketInetAddr; { char Buffer[BUFSIZ]; int SocketDescriptor; struct servent *ServiceEntryPointer; SocketInetAddr.sin_port = htons(Port); SocketDescriptor = socket(AF_INET, SOCK_STREAM, 6); if (SocketDescriptor < 0) { perror("socket"); return (RETURN_ERR); } if (Verbose) { (void) printf("Host %s, Port %d ", HostEntryPointer->h_name, Port); if ((ServiceEntryPointer = getservbyport(Port, "tcp")) != (struct servent *) NULL) (void) printf(" (\"%s\" service) ", ServiceEntryPointer->s_name); (void) printf("connection ... "); (void) fflush(stdout); } if (connect(SocketDescriptor, (char *) &SocketInetAddr, sizeof(SocketInetAddr)) < 0) { if (Verbose) (void) printf("NOT open.\n"); if (Debug) perror("connect"); } else { if (!Verbose) { (void) printf("Host %s, Port %d ", HostEntryPointer->h_name, Port); if ((ServiceEntryPointer = getservbyport(Port,"tcp")) != (struct servent *) NULL) (void) printf(" (\"%s\" service) ", ServiceEntryPointer->s_name); (void) printf("connection ... "); (void) fflush(stdout); } (void) printf("open.\n"); if (Hack) { (void) sprintf(Buffer, "/usr/ucb/telnet %s %d", HostEntryPointer->h_name, Port); (void) system(Buffer); } } (void) close(SocketDescriptor); return (RETURN_SUCCESS); } From firewalls-owner Thu Apr 14 03:27:53 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA23476; Thu, 14 Apr 1994 03:27:53 GMT Received: from lokkur.dexter.mi.us by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA23470; Wed, 13 Apr 1994 20:27:39 -0700 Received: (scs@localhost) by lokkur.dexter.mi.us (8.6.7/8.6.5) id VAA08688 for firewalls@greatcircle.com; Wed, 13 Apr 1994 21:00:57 -0400 From: Steve Simmons Message-Id: <199404140100.VAA08688@lokkur.dexter.mi.us> Subject: Re: system() -> Mosaic To: firewalls@greatcircle.com (Firewalls Mailing List) Date: Wed, 13 Apr 1994 21:00:03 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2538 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Pardon the omnibus response, but it's been quite busy the last seven days here in Glorious Dexter, Heart of the Internet. So onward: Mark Ludwig (Mark-Ludwig@uai.com) complains that my analogy that "connecting to the information highway without a firewall and a security policy is like removing all the doors from your building" is an exaggeration. Then he says that the internal doors and corridors are secured by the vendors supplying the systems. Exactly -- we know the systems are suspect, so if you aren't *as a matter of policy* taking the extra steps to secure those systems, you have no secure internal doors. If you don't have a firewall, you have no secure external door. I stand by the analogy. Mark Moraes wrote: MarkM> In general, cost is a concern for most people once the MarkM> functionality/reliability requirements are met . . . He goes on to compare a $2,500 filtering router to a $25,000 firewall and points out that if a client is willing to accept the limitations of the former, they'll always chose it over the latter. Absolutely, it's the only rational decision. However, there are two related problems. First, until fairly recently most sites have simply not considered security as one of the requirements [[and I might cynically add that even if they did, in far too many vendors cases the security of their systems was so close to zero there *were* no good choices.]] Second, there is a real tendency to make an uninformed decision. "Oh, we can live without ." Then when there is pressure to do , they open holes in the filter and are right back where they started from, ie, zero. Going on on this topic... There is an understandable tendency in any corporation to not regard security as a departmental issue. If department A is well-supported and puts effort into security while department B just uses whatever is shipped from the vendor, department B will run at a lower cost than department A. This is especially so when evaluating the vendor-shipped security of a given system. First and foremost in any hardware selection is if it runs the software you need. That choice often narrows the field to one, count it, one contender. Suddenly it's not a price/security choice any more. If the corporation needs that software, the decision is made. Then you make an after-the- fact decision about how to live with it. In such cases, a firewall is almost always cheaper than making the vendor systems secure and keeping them so. From firewalls-owner Thu Apr 14 06:30:16 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA24034; Thu, 14 Apr 1994 06:30:16 GMT Received: from neptunus.rivm.nl by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA24028; Wed, 13 Apr 1994 23:30:08 -0700 Received: from floyd.rivm.nl by neptunus.rivm.nl with SMTP (PP); Thu, 14 Apr 1994 08:29:13 +0200 Received: by floyd.rivm.nl (4.1/SMI-4.1) id AA03725; Thu, 14 Apr 94 08:27:50 +0100 Date: Thu, 14 Apr 94 08:27:50 +0100 From: Rens.Schipper@rivm.nl (Rens Schipper) Message-Id: <9404140727.AA03725@floyd.rivm.nl> To: firewalls@GreatCircle.COM Subject: X through a firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I'm looking for a way to support X through a firewall. All I found at this moment is a document from CRL, "X through the firewall, and other apllications relays". It mentions a 'XFORWARD' program that seems to do what I want. I can't find anything on the net so I turn to this list. Is xforward public domain? and if yes, where can I get a copy? Are there other ways to support X through a firewall? Regards, Rens Schipper RIVM From firewalls-owner Thu Apr 14 07:00:48 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA24296; Thu, 14 Apr 1994 07:00:48 GMT Received: from tamarin.bath.ac.uk by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA24290; Thu, 14 Apr 1994 00:00:40 -0700 Received: from ss1.bath.ac.uk by tamarin.bath.ac.uk with SMTP (PP) id <05324-0@tamarin.bath.ac.uk>; Thu, 14 Apr 1994 08:00:31 +0100 To: Rens Schipper CC: firewalls@greatcircle.com Subject: Re: X through a firewall In-reply-to: Your message of "Thu, 14 Apr 1994 08:27:50 BST." <9404140727.AA03725@floyd.rivm.nl> Date: Thu, 14 Apr 1994 08:00:17 +0100 From: Icarus Sparry Message-ID: <9404140800.aa26976@uk.ac.bath.ss1> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk xforward was published in comp.soures.x, (volume 21). The README says The current version of xforward can be copied by anonymous FTP from crl.dec.com:/pub/DEC/xforward.tar.Z. Icarus From firewalls-owner Thu Apr 14 03:29:49 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA25143; Thu, 14 Apr 1994 09:49:22 GMT Received: from campino.informatik.rwth-aachen.de by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA25137; Thu, 14 Apr 1994 02:49:11 -0700 Received: from i3.informatik.rwth-aachen.de (mozart.Informatik.RWTH-Aachen.DE) by campino.informatik.rwth-aachen.de (4.1/campino-5) id AA16455; Thu, 14 Apr 94 11:49:06 +0200 Received: from grieg.informatik.rwth-aachen.de by i3.informatik.rwth-aachen.de (4.1/SMI-4.1-i3) id AA12952; Thu, 14 Apr 94 11:48:49 +0200 Date: Thu, 14 Apr 94 11:48:49 +0200 From: peter@i3.informatik.rwth-aachen.de (Peter Heimann) Message-Id: <9404140948.AA12952@i3.informatik.rwth-aachen.de> To: firewalls@greatcircle.com Subject: Re: Filtering NFS with Cisco ACLs Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jeff Pack writes > I am setting up an FDDI-Ethernet network and further partitioning > that network using access lists on a cisco. The plan is to have one > host as a file server on a subnet and one "secure" network that can > only access the file server via NFS > [all ports except udp 2049 blocked] > but NFS doesn't > work. It does work when I allow all udp traffic (i.e., remove the > eq 2049). [...] Which additional ports do > I need to specify to get *just* NFS to work? When I watch a mount with etherfind, I get the following output (hostnames replaced by 'client' and 'server' respectively): # etherfind -host client -host server icmp type lnth proto source destination src port dst port (Client aks portmapper on the server for mountd's port and gets a reply, here: port=718) 98 udp client server 947 111 70 udp server client 111 947 (Client talks to mountd) 82 udp client server 948 718 66 udp server client 718 948 130 udp client server 948 718 102 udp server client 718 948 (Client send nfs requests and gets replies) 154 udp client server 1061 2049 138 udp server client 2049 1061 154 udp client server 1061 2049 90 udp server client 2049 1061 To allow the portmapper communication, you just would have to add access-list 101 permit udp 152.80.6.201 0.0.0.0 152.80.219.201 0.0.0.0 eq 111 This strategy does not really work for mountd, as the port it listens on gets dynamically assigned at daemon start time, and thus depends on the server configuration. You would have to check and possibly change your access list after every server config change. You can, however, open a range of probable ports with the 'gt ' and 'lt ' operators and thus trade access control for administrator convenience. -- Peter Heimann Lehrstuhl fuer Informatik III peter@i3.informatik.rwth-aachen.de RWTH Aachen From firewalls-owner Thu Apr 14 11:13:01 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA25512; Thu, 14 Apr 1994 11:13:01 GMT Received: from research.att.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA25506; Thu, 14 Apr 1994 04:12:55 -0700 From: smb@research.att.com Message-Id: <199404141112.EAA25506@mycroft.GreatCircle.COM> Received: by gryphon; Thu Apr 14 07:12:26 EDT 1994 To: Rens.Schipper@rivm.nl (Rens Schipper) cc: firewalls@GreatCircle.COM Subject: Re: X through a firewall Date: Thu, 14 Apr 94 07:12:24 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I'm looking for a way to support X through a firewall. All I found at this moment is a document from CRL, "X through the firewall, and other apll ications relays". It mentions a 'XFORWARD' program that seems to do what I want . I can't find anything on the net so I turn to this list. Is xforward public domain? and if yes, where can I get a copy? Are there other ways to support X through a firewall? Regards, Rens Schipper RIVM It's not public domain, but it is freely available. See \software{crl.dec.com}{/pub/DEC/xforward.tar.Z} From firewalls-owner Thu Apr 14 12:09:43 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA25672; Thu, 14 Apr 1994 12:09:43 GMT Received: from gatekeeper.mcimail.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA25666; Thu, 14 Apr 1994 05:09:36 -0700 Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA04130; Thu, 14 Apr 94 07:09:47 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ai20845; 14 Apr 94 12:01 GMT Date: Thu, 14 Apr 94 07:05 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: firewalls Subject: Encrypted tunnels Message-Id: <14940414120541/0003858921NA4EM@mcimail.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I need to understand how do create encrypted tunnels between trading partners where there can be no requirement of matching firewall products. Senario: Employee X and Company A needs to jointly develop a part with Employee Y at Company B. Employee X does something directed at Company A's firewall, this results in some data going across a unique or multiplexed pipe to Company B's firewall (connection arrangements will already have been established between the two companies). This then goes on to Employee Y's system and they can now do their design work securely. Please tell me who to do this today. And if it cannot be done, tell me how to start up a process to make it happen... Bob Moskowitz Chrysler Corp IS Technical Services From firewalls-owner Thu Apr 14 14:03:23 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA26115; Thu, 14 Apr 1994 14:03:23 GMT Received: from london.micrognosis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA26109; Thu, 14 Apr 1994 07:03:13 -0700 Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA02897; Thu, 14 Apr 94 15:02:17 BST Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma002894; Thu Apr 14 15:01:57 1994 Received: from pmsls11 by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA02996; Thu, 14 Apr 94 15:01:55 BST From: imarr@london.micrognosis.com (Ian Marr) Received: by pmsls11 (4.1//ident-1.0) id AA14068; Thu, 14 Apr 94 15:01:54 BST Message-Id: <9404141401.AA14068@pmsls11> Subject: Re: Encrypted tunnels To: 0003858921@mcimail.com (Robert G. Moskowitz) Date: Thu, 14 Apr 1994 15:01:53 +0100 (BST) Cc: firewalls@GreatCircle.COM In-Reply-To: <14940414120541/0003858921NA4EM@mcimail.com> from "Robert G. Moskowitz" at Apr 14, 94 07:05:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1254 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Robert G. Moskowitz writes: > > I need to understand how do create encrypted tunnels between trading > partners where there can be no requirement of matching firewall products. If I understand this correctly ... you could do the following: Morning Star PPP can tunnel IP over a (unique/predictable) TCP circuit. So ... setup two PPP hosts internally, inside your networks, punch some holes in your firewalls and routers (we use the TIS toolkit plug-gw and a Cisco/IGS) and point the PPP vct at the holes. You should be able to do this with most firewalls and routers. PPP can be configured to encrypt all the traffic across the tunnel giving you transparent IP between your two company's networks; but you can also use PPP's filtering to restrict stuff too. Well, that's the theory, I want to do the same thing between London and the States but the other end are a bit sloooow. Let us know if you get any other, more sensible ideas. (Hey, it's just after "lunch" :-). Ian. ------------------------------------------------------------------------------ Ian Marr, Systems Manager, Micrognosis, 63 Queen Victoria St, London, EC4N 4UD imarr@london.micrognosis.com +44-71-815-5254 From firewalls-owner Thu Apr 14 15:38:50 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA26439; Thu, 14 Apr 1994 15:38:50 GMT Received: from uai.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA26433; Thu, 14 Apr 1994 08:38:41 -0700 Received: from hp.uai.com by uai.com with SMTP id AA20737 (5.65c/IDA-1.4.4 for ); Thu, 14 Apr 1994 08:38:20 -0700 From: "Mark R. Ludwig" Received: by hp.uai.com id ; Thu, 14 Apr 94 08:38:16 -0700 Message-Id: <9404141538.AA05340@hp.uai.com> To: Steve Simmons Cc: firewalls@greatcircle.com (Firewalls Mailing List) Subject: Re: system() -> Mosaic In-Reply-To: <199404140100.VAA08688@lokkur.dexter.mi.us> from "Steve Simmons" on Wed, 13 Apr 1994 21:00:03 EDT. X-Mailer: MH [Version 6.8] Date: Thu, 14 Apr 1994 08:38:16 -0700 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> "S" == Steve Simmons writes: S> Mark Ludwig (Mark-Ludwig@uai.com) complains that my analogy that S> "connecting to the information highway without a firewall and a S> security policy is like removing all the doors from your building" is S> an exaggeration. Then he says that the internal doors and corridors S> are secured by the vendors supplying the systems. Exactly -- we know S> the systems are suspect, so if you aren't *as a matter of policy* S> taking the extra steps to secure those systems, you have no secure S> internal doors. If you don't have a firewall, you have no secure S> external door. I stand by the analogy. We were obviously in violent agreement. You were terse in saying "removing all the doors from your building" which I interpreted as "removing ALL the doors," inside or outside. Now that I understand you meant _external_ doors, I see we were actually agreeing all along. Sorry about the confusion.$$ -- INET: Mark-Ludwig@UAI.COM NIC: ML255 ICBM: USA; Lower Left Coast "Cigarettes ... are not a drug." -- Tom Lorea from the Tobacco Institute From firewalls-owner Thu Apr 14 16:05:38 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA26526; Thu, 14 Apr 1994 16:05:38 GMT Received: from ALABAMA.CF.CS.YALE.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA26520; Thu, 14 Apr 1994 09:05:25 -0700 Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Thu, 14 Apr 1994 12:05:27 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.67b/res.client.cf-3.7) id AA01456; Thu, 14 Apr 1994 12:05:26 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199404141605.AA01456@SPARKY.CF.CS.YALE.EDU> To: firewalls@GreatCircle.COM Cc: jstevens@george.arc.nasa.gov, cert-tools@cert.org Subject: Minor cosmetic fix for probe_tcp_ports.c on little endian machines In-Reply-To: Your message of Wed, 13 Apr 94 20:32:29 EDT. Date: Thu, 14 Apr 94 12:05:25 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Following up on a rumor I received via email of a problem with an older version of probe_tcp_ports on a 64bit Alpha machine I decided to make sure probe_tcp_ports.c compiled and ran on the DEC Alpha here. It did. But I noticed that the "well known service" names from /etc/services were not being printed out because the port number short needed to be converted (bit/byte ordering) on little endian such as DEC Vaxen and Alphas, Intel X86 microprocessors before calling getservbyport(). Here is the minor cosmetic fix : 135c135 < if ((ServiceEntryPointer = getservbyport(Port, "tcp")) != --- > if ((ServiceEntryPointer = getservbyport(htons(Port), "tcp")) != 156c156 < if ((ServiceEntryPointer = getservbyport(Port,"tcp")) != --- > if ((ServiceEntryPointer = getservbyport(htons(Port),"tcp")) != - Morrow From firewalls-owner Thu Apr 14 17:07:41 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA26768; Thu, 14 Apr 1994 17:07:41 GMT Received: from ALABAMA.CF.CS.YALE.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA26762; Thu, 14 Apr 1994 10:07:34 -0700 Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Thu, 14 Apr 1994 13:07:43 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.67b/res.client.cf-3.7) id AA01635; Thu, 14 Apr 1994 13:07:41 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199404141707.AA01635@SPARKY.CF.CS.YALE.EDU> To: firewalls@GreatCircle.COM Cc: cert-tools@cert.org Subject: Re: probe_tcp_ports In-Reply-To: Your message of Thu, 14 Apr 94 12:34:39 EDT. Date: Thu, 14 Apr 94 13:07:40 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In a mail message someone wrote me: >Could you please give me some insight on wht this does? probe_tcp_ports attempts to connect (sequentially) to all of the TCP ports on a host running IP to see which ones have a process listening for connections on them. This allows you to scan all of your hosts to see if one of your users is running a gopher, WWW or MUD server that you don't know about (as well as other possibly insecure services). You could also probe remote hosts on the internet to see if they are running any interesting services at any ports in the range 1-65535 (although the etiquette and ethics of doing this to a remote Internet hosts are certainly a controversial debate). Unfortunately it can't tell you if anyone on your network is running an illicit FSP site from which they are distributing pirated software (because FSP is a protocol on top of UDP). You'll have to use etherfind, snoop or a Sniffer/Lanalyzer for that. With the -h flag (hack mode) it will fire up telnet on the found port. With the -v flag (verbose mode) it will report on ports that it couldn't connect to as well as those it can. The -d flag is for debug mode. You run it as : probe_tcp_ports hostname or probe_tcp_ports -h hostname - Morrow From firewalls-owner Thu Apr 14 17:58:50 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA26974; Thu, 14 Apr 1994 17:58:50 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA26968; Thu, 14 Apr 1994 10:58:43 -0700 Received: from relay.sgi.com (relay.sgi.com [192.26.51.36]) by sgigate.sgi.com (8.6.4/8.6.4) with SMTP id KAA10687; Thu, 14 Apr 1994 10:58:38 -0700 Received: from yeager.corp.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgigate.sgi.com:0003858921@mcimail.com id AA15907; Thu, 14 Apr 94 10:58:36 -0700 Received: by yeager.corp.sgi.com (931110.SGI/911001.SGI) for @sgi.com:firewalls@GreatCircle.COM id AA07576; Thu, 14 Apr 94 10:58:35 -0700 From: lear@yeager.corp.sgi.com (Eliot Lear) Message-Id: <9404141058.ZM7574@yeager.corp.sgi.com> Date: Thu, 14 Apr 1994 10:58:34 -0700 In-Reply-To: "Robert G. Moskowitz" <0003858921@mcimail.com> "Encrypted tunnels" (Apr 14, 7:05am) References: <14940414120541/0003858921NA4EM@mcimail.com> X-Mailer: Z-Mail-SGI (3.1S.0 3mar94 MediaMail) To: "Robert G. Moskowitz" <0003858921@mcimail.com>, firewalls Subject: Re: Encrypted tunnels Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There are several companies such as Semaphore Technologies that provide encryption tools that will encrypt/decrypt IP on the fly. If you use two such boxes, and allow IP to pass between them, you may be OK. There are a number of variables in this equation,such as whether you allow the two machines to talk to others within their respective companies. If you do, then you must take great care to control the environments of each of these machines. (I fully realize that you would likely be directly responsible for only one end). -- Eliot Lear [lear@sgi.com] From firewalls-owner Thu Apr 14 19:36:55 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA27391; Thu, 14 Apr 1994 19:36:55 GMT Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA27385; Thu, 14 Apr 1994 12:36:48 -0700 Received: from sgsjsco.sextantgroup.com by netcomsv.netcom.com with SMTP (8.6.4/SMI-4.1) id MAA29660; Thu, 14 Apr 1994 12:38:07 -0700 Received: from smtplink by sgsjsco.sextantgroup.com with SMTP (5.65/1.2-eef) id AA16772; Thu, 14 Apr 94 12:21:39 -0700 Received: from ccMail by smtplink.sextantgroup.com id AA766351898 Thu, 14 Apr 94 12:31:38 PST Date: Thu, 14 Apr 94 12:31:38 PST From: "Rhett, Joe" Message-Id: <9403147663.AA766351898@smtplink.sextantgroup.com> To: Firewalls@GreatCircle.COM Subject: Inbound telnet sessions. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Have an interesting requirement. Have a network system with Internet connection. Blocking all connection attempts to any address except for the FTP server. (Protocol Filtering Router) One of the requirements is the ability for users to telnet to their workstations (Sun and SCO) from the Internet. This is currently allowed by telneting to the FTP server, then telneting out from there. This is relatively secure, as the number of accounts on that system is strictly limited. Once there, you need to know an IP address to get out. After giving users a shell and various and sundry attempts to limit that shell, I have actually found it more secure to put telnet into their home directory, and execute it as a shell instead. Without an underlying shell, no shell functions can be performed, and the connection is dropped when they log out of the remote system. user:ashdfkja:1000:1000:Remote Access User:/home/user/telnet 2 Questions: 1 - Any user can use > open xxx.xxx.xxx.xxx 25 .. and telnet to the sendmail port on the Sun boxes. The security here is performed at the Router and Firewall system, trying to leave the inner system alone. (Yah, I know that a single break and the whole system is compromised but this is how it's being done...) -- Therefore, I'd like to find a way to kill that ability, and/or replace telnet with something more limited. 2 - Is there anything else left open for attack? BTW: The Router allows ICMP and DNS (port 53) data through. It allows port 21,23,25 to go to the firewall (FTP,Telnet,SMTP) but disallows all other protocols under 1024, blocks the standard NFS and NIS ports, as well as X-Window ports. From firewalls-owner Thu Apr 14 19:49:12 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA27470; Thu, 14 Apr 1994 19:49:12 GMT Received: from research.att.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA27464; Thu, 14 Apr 1994 12:49:06 -0700 From: smb@research.att.com Message-Id: <199404141949.MAA27464@mycroft.GreatCircle.COM> Received: by gryphon; Thu Apr 14 15:46:05 EDT 1994 To: "Robert G. Moskowitz" <0003858921@mcimail.com> cc: firewalls Subject: Re: Encrypted tunnels Date: Thu, 14 Apr 94 15:46:03 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I need to understand how do create encrypted tunnels between trading partners where there can be no requirement of matching firewall products. There are several products available today to do it. Xerox Semaphore and UUNET make network-level encryptors. (AT&T OEMs the Semaphore unit.) Or you could use Morningstar's PPP, which can operate over TCP and can do encryption. From firewalls-owner Thu Apr 14 20:19:45 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA27646; Thu, 14 Apr 1994 20:19:45 GMT Received: from nsco.network.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA27640; Thu, 14 Apr 1994 13:19:26 -0700 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA24351; Thu, 14 Apr 94 15:23:01 -0500 Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA18148; Thu, 14 Apr 94 15:19:16 CDT Date: Thu, 14 Apr 94 15:19:16 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9404142019.AA18148@anubis.network.com> To: firewalls@GreatCircle.COM Subject: Re: Encrypted tunnels Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This may be obvious, but you need to consider, exactly, your needs. The things that encrypt at the IP layer still allow traffic analysis to go on, if you've got a really dedicated listener. If you just need to protect the details of the data inflight, they're fine. If you really need secure communications, doing something like PPP over an encrypted TCP stream, and adding random noise by sending (say) pings over the same channel at intervals determined by a strong random number generator would probably be better. Andrew Molitor From firewalls-owner Thu Apr 14 20:42:05 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA27737; Thu, 14 Apr 1994 20:42:05 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA27731; Thu, 14 Apr 1994 13:41:53 -0700 Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id NAA01090; Thu, 14 Apr 1994 13:42:03 -0700 Message-Id: <199404142042.NAA01090@mailgate.cadence.com> Received: from mac32_223.cadence.com(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma001031; Thu Apr 14 13:41:02 1994 Date: Thu, 14 Apr 1994 13:41:02 -0800 To: Firewalls@GreatCircle.COM, "Rhett, Joe" From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: Inbound telnet sessions. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 12:31 PM 4/14/94 -0800, Rhett, Joe wrote: > >Have an interesting requirement. Have a network system with Internet >connection. Blocking all connection attempts to any address except for >the FTP server. (Protocol Filtering Router) > >One of the requirements is the ability for users to telnet to their >workstations (Sun and SCO) from the Internet. This is currently allowed >by telneting to the FTP server, then telneting out from there. > >This is relatively secure, as the number of accounts on that system is >strictly limited. Once there, you need to know an IP address to get out. > >After giving users a shell and various and sundry attempts to limit that >shell, I have actually found it more secure to put telnet into their >home directory, and execute it as a shell instead. Without an underlying >shell, no shell functions can be performed, and the connection is dropped >when they log out of the remote system. > >user:ashdfkja:1000:1000:Remote Access User:/home/user/telnet > >2 Questions: > >1 - Any user can use > >> open xxx.xxx.xxx.xxx 25 > > .. and telnet to the sendmail port on the Sun boxes. The security >here is performed at the Router and Firewall system, trying to leave the >inner system alone. (Yah, I know that a single break and the whole system >is compromised but this is how it's being done...) > -- Therefore, I'd like to find a way to kill that ability, and/or >replace telnet with something more limited. > >2 - Is there anything else left open for attack? > >BTW: The Router allows ICMP and DNS (port 53) data through. It allows >port 21,23,25 to go to the firewall (FTP,Telnet,SMTP) but disallows >all other protocols under 1024, blocks the standard NFS and NIS ports, >as well as X-Window ports. Your passwords are eavesdroppable on the Internet. Also allowing them a command shell allows them to diddle with your firewall/ftp system. Try the tn-gw from the TIS firewalls toolkit (ftp tis.com) and use strong authentication (skey,SecurID etc) Al --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From firewalls-owner Thu Apr 14 21:01:16 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA27812; Thu, 14 Apr 1994 21:01:16 GMT Received: from sgi1.phlab.missouri.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA27805; Thu, 14 Apr 1994 14:01:04 -0700 Received: from sgi12.phlab.missouri.edu by sgi1.phlab.missouri.edu via SMTP (931110.SGI/931108.SGI.AUTO.ANONFTP) for firewalls@GreatCircle.COM id AA16165; Thu, 14 Apr 94 16:01:03 -0500 Received: by sgi12.phlab.missouri.edu (931110.SGI/931108.SGI.AUTO.ANONFTP) for @sgi1.phlab.missouri.edu:firewalls@GreatCircle.COM id AA10633; Thu, 14 Apr 94 15:01:01 -0600 Date: Thu, 14 Apr 1994 15:00:56 -0600 (CST) From: Paul Walmsley Subject: Re: probe_tcp_ports To: H Morrow Long Cc: firewalls@GreatCircle.COM In-Reply-To: <199404141707.AA01635@SPARKY.CF.CS.YALE.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Thu, 14 Apr 1994, H Morrow Long wrote: > > Unfortunately it can't tell you if anyone on your network is > running an illicit FSP site from which they are distributing > pirated software (because FSP is a protocol on top of UDP). > You'll have to use etherfind, snoop or a Sniffer/Lanalyzer for that. > However, if the computer in question running fspd is also running snmpd, you can discover all open TCP *and* UDP ports by simply querying SNMP. I succeeded in compiling CMU's cmu-snmp distribution here on our IRIX 4.0.5H machines, and by monitoring certain SNMP variables you can observe which UDP and TCP ports are currently open. The SNMP variables in question are, according to my (currently very limited) MIB are: ... for tcp: tcp.tcpConnTable.tcpConnEntry.tcpConnLocalPort.* ... for udp: udp.5.1.1.* -Paul From firewalls-owner Thu Apr 14 14:09:57 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA27785; Thu, 14 Apr 1994 21:00:00 GMT Received: from druggist.gg.caltech.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA27778; Thu, 14 Apr 1994 13:59:37 -0700 Message-Id: <199404142059.NAA27778@mycroft.GreatCircle.COM> Received: by druggist.gg.caltech.edu with SMTP (16.8/15.6) id AA19374; Thu, 14 Apr 94 13:57:44 -0700 To: "Rhett, Joe" Cc: Firewalls@greatcircle.com Subject: Re: Inbound telnet sessions. In-Reply-To: Your message of "Thu, 14 Apr 1994 12:31:38 PST." <9403147663.AA766351898@smtplink.sextantgroup.com> Date: Thu, 14 Apr 1994 13:57:43 PDT From: Walker Aumann Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > 2 Questions: > > 1 - Any user can use > > open xxx.xxx.xxx.xxx 25 > .. and telnet to the sendmail port on the Sun boxes. The security > here is performed at the Router and Firewall system, trying to leave the > inner system alone. (Yah, I know that a single break and the whole system > is compromised but this is how it's being done...) > -- Therefore, I'd like to find a way to kill that ability, and/or > replace telnet with something more limited. Write a program that has them type in the IP address and then execs telnet so you're sure they're connecting to the correct port on the destination machine. Walker Aumann walkera@gg.caltech.edu From firewalls-owner Thu Apr 14 21:12:21 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA27853; Thu, 14 Apr 1994 21:12:21 GMT Received: from alpha.xerox.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA27847; Thu, 14 Apr 1994 14:12:13 -0700 Received: from avalon.parc.xerox.com ([13.1.101.241]) by alpha.xerox.com with SMTP id <14404(2)>; Thu, 14 Apr 1994 14:11:26 PDT Received: by avalon.parc.xerox.com id <2440>; Thu, 14 Apr 1994 14:11:39 -0700 From: Mark Verber To: Firewalls@greatcircle.com, JRhett@sextantgroup.com Subject: Re: Inbound telnet sessions. Message-Id: <94Apr14.141139pdt.2440@avalon.parc.xerox.com> Date: Thu, 14 Apr 1994 14:11:25 PDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > One of the requirements is the ability for users to telnet to their > workstations (Sun and SCO) from the Internet. This is currently allowed > by telneting to the FTP server, then telneting out from there. > > This is relatively secure, as the number of accounts on that system is > strictly limited. Once there, you need to know an IP address to get out. > > After giving users a shell and various and sundry attempts to limit that > shell, I have actually found it more secure to put telnet into their > home directory, and execute it as a shell instead. Without an underlying > shell, no shell functions can be performed, and the connection is dropped > when they log out of the remote system. > > user:ashdfkja:1000:1000:Remote Access User:/home/user/telnet > > 2 Questions: > > 1 - Any user can use > > > open xxx.xxx.xxx.xxx 25 > > .. and telnet to the sendmail port on the Sun boxes. The security > here is performed at the Router and Firewall system, trying to leave the > inner system alone. (Yah, I know that a single break and the whole system > is compromised but this is how it's being done...) > -- Therefore, I'd like to find a way to kill that ability, and/or > replace telnet with something more limited. You are still open to one of the most common attacks. Watching telnet streams establish and snoop for machine/user/password and the first 128-1k bytes. Eg they get a log displaying your host IP address, a username, a valid password, and the first bit that you type (so the machine address your user is accessing, his internal username and password). You lose. Also, you telnet isn't logging so you have no idea what people are doing once they are on your machine. I would suggest taking a look at the TIS firewall-toolkit's (ftp.tis.com) telnet gateway, or better yet rlogin so people can't sniff the internal password either. Use it with one-time passwords (token cards or Skey). You also might want to run your telnet server on a port other than 23. Not that this will stop people, but it does mean that the sniffing programs will have to be modified to listen to more than the telnet, rlogin, and ftp ports. I run a telnet server which has a rlogin backend. This way machine (like Macs) which don't have rlogin clients can still come over the firewall while still not using a password. --Mark From firewalls-owner Thu Apr 14 22:14:41 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA28141; Thu, 14 Apr 1994 22:14:41 GMT Received: from primus.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA28135; Thu, 14 Apr 1994 15:14:32 -0700 Received: (from mre@localhost) by primus.com (8.6.8.1/8.6.8) id PAA02439; Thu, 14 Apr 1994 15:14:47 -0700 Date: Thu, 14 Apr 1994 15:14:47 -0700 (PDT) From: Mike Evans Subject: Re: probe_tcp_ports To: Paul Walmsley cc: H Morrow Long , firewalls@GreatCircle.COM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Thu, 14 Apr 1994, Paul Walmsley wrote: > > > On Thu, 14 Apr 1994, H Morrow Long wrote: > > > > > Unfortunately it can't tell you if anyone on your network is > > running an illicit FSP site from which they are distributing > > pirated software (because FSP is a protocol on top of UDP). > > You'll have to use etherfind, snoop or a Sniffer/Lanalyzer for that. > > > > However, if the computer in question running fspd is also running snmpd, > you can discover all open TCP *and* UDP ports by simply querying SNMP. I > succeeded in compiling CMU's cmu-snmp distribution here on our IRIX 4.0.5H > machines, and by monitoring certain SNMP variables you can observe which > UDP and TCP ports are currently open. The SNMP variables in question are, > according to my (currently very limited) MIB are: > > ... for tcp: > tcp.tcpConnTable.tcpConnEntry.tcpConnLocalPort.* > > ... for udp: > udp.5.1.1.* You can get ntop, a kmem-based window connection viewer (shows listening ports and uid), or even udplog from TAMU's netlog package. Mike From firewalls-owner Fri Apr 15 06:09:06 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA29146; Fri, 15 Apr 1994 06:09:06 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA29140; Thu, 14 Apr 1994 23:08:59 -0700 Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id XAA24955 for ; Thu, 14 Apr 1994 23:09:12 -0700 Received: from cds9258.cadence.com(158.140.32.4) by mailgate.cadence.com via smap (V1.0mjr) id sma024923; Thu Apr 14 23:08:58 1994 Received: from localhost (alastair@localhost) by cds9258.cadence.com (8.6.4/8.6.8) id XAA05431 for firewalls@greatcircle.com; Thu, 14 Apr 1994 23:08:57 -0700 Date: Thu, 14 Apr 1994 23:08:57 -0700 From: Alastair Young Message-Id: <199404150608.XAA05431@cds9258.cadence.com> To: firewalls@greatcircle.com Subject: wuftpd.....again Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk CERT announced today that there are two further bugs in wuftpd and also a couple of other ftp daemons. One of the bugs in wuftpd which I assume did apply to us was to do with a "race condition". if anyone can let me know how I might detect past attempts to activate this by browsing my logfiles I'd be grateful. Alastair Young alastair@cadence.com From firewalls-owner Fri Apr 15 06:16:08 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA29186; Fri, 15 Apr 1994 06:16:08 GMT Received: from netmail2.microsoft.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA29180; Thu, 14 Apr 1994 23:15:56 -0700 Received: by netmail2.microsoft.com (5.65/25-eef) id AA00293; Thu, 14 Apr 94 22:17:30 -0700 Message-Id: <9404150517.AA00293@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 14 Apr 94 22:17:30 PDT X-Msmail-Message-Id: 9EEA706B X-Msmail-Conversation-Id: 9EEA706B From: Jonathon Tidswell (MS Research Fellow) To: firewalls@greatcircle.com Date: Fri, 15 Apr 94 16:00:17 TZ Subject: firewalling Windows NT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has anybody set up a firewall using Windows NT on the firewall ? What I want to achieve is reasonably easy to describe :-) an opaque wall on the external interface, no inbound connections are to be permitted a reasonably transparent wall on the internal interface, probably requires a series of redirectors and daemons Any pointers to documents, source or commercial products for the Windows NT operating system, [for firewalls] would be appreciated. thanks JonT PS If you reply to the list please Cc: me explicitly as I don't know if I have actually been added to the list yet. ---- jont@mpce.mq.edu.au Postgraduate Student, Department of Computing, Macquarie University t-jont@microsoft.com Research Fellow, Microsoft Institute of Advanced Software Technology Disclaimer: I think my thoughts are my own, and I believe my writings are too. From firewalls-owner Fri Apr 15 13:26:21 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA01376; Fri, 15 Apr 1994 13:26:21 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA01370; Fri, 15 Apr 1994 06:26:15 -0700 Received: by relay.tis.com; id AA24831; Fri, 15 Apr 94 09:26:16 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma024826; Fri Apr 15 09:25:50 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA04087; Fri, 15 Apr 94 09:24:48 EDT From: Marcus J Ranum Received: by otter.tis.com (4.1/SMI-4.1) id AA05292; Fri, 15 Apr 94 09:24:45 EDT Date: Fri, 15 Apr 94 09:24:45 EDT Message-Id: <9404151324.AA05292@otter.tis.com> To: alastair@cadence.com, firewalls@GreatCircle.COM Subject: Re: wuftpd.....again Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >CERT announced today that there are two further bugs in wuftpd and also a >couple of other ftp daemons. Run them pre-chrooted, people. We've had versions of ftpd for years and years and new bugs are still cropping up. Ftpd should be right up there on your Bad News Code list along with sendmail. mjr. From firewalls-owner Fri Apr 15 14:20:48 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA01750; Fri, 15 Apr 1994 14:20:48 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA01744; Fri, 15 Apr 1994 07:20:39 -0700 Received: by relay.tis.com; id AA25322; Fri, 15 Apr 94 10:20:41 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma025312; Fri Apr 15 10:19:45 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA07638; Fri, 15 Apr 94 10:18:45 EDT From: Marcus J Ranum Received: by otter.tis.com (4.1/SMI-4.1) id AA05696; Fri, 15 Apr 94 10:18:43 EDT Date: Fri, 15 Apr 94 10:18:43 EDT Message-Id: <9404151418.AA05696@otter.tis.com> To: firewalls@greatcircle.com Subject: FTP services -- Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk My recent note about running ftpds pre-chrooted has garnered me several how-to requests. I'll describe briefly how we do it, and I guess I'll add it to the FAQ. Steps ----- 1: Build a statically linked version of ftpd and put it in ~ftp/bin. Make sure it's owned by root. 2: Build a statically linked version of /bin/ls if you'll need one. Put it in ~ftp/bin. If you are on a Sun, and need to build one, there's a ported version of the BSD net2 ls command for SunOs on ftp.tis.com: pub/firewalls/toolkit/patches/ls.tar.Z Make sure it's owned by root. 3: Chown ~ftp to root and make it mode 755 THIS IS VERY IMPORTANT 4: If you're on a Sun, make a copy of /dev/zero in ~ftp/dev and chown it to root. Make sure it's readable. 5: Set up copies of ~ftp/etc/passwd and ~ftp/etc/group just as you would normally, EXCEPT make 'ftp's home directory '/' -- make sure they are owned by root. 6: Write a wrapper to kick ftpd off and install it in /etc/inetd.conf The wrapper should look something like: (assuming ~ftp = /var/ftp) main() { if(chdir("/var/ftp")) { perror("chdir /var/ftp"); exit(1); } if(chroot("/var/ftp")) { perror("chroot /var/ftp"); exit(1); } /* optional: seteuid(FTPUID); */ execl("/bin/ftpd","ftpd","-l",(char *)0); perror("exec /bin/ftpd"); exit(1); } Options: You can use 'netacl' from the toolkit or tcp_wrappers to achieve the same effect. We use 'netacl' to switch so that a few machines that connect to the FTP service *don't* get chrooted first. This makes transferring files a bit less painful. You may also wish to take your ftpd sources and find all the places where it calls seteuid() and remove them, then have the wrapper do a setuid(ftp) right before the exec. This means that if someone knows a hole that makes them "root" they still won't be. Relax and imagine how frustrated they will be. If you're hacking ftpd sources, I suggest you turn off a bunch of the options in ftpcmd.y by unsetting the "implemented" flag in ftpcmd.y. This is only practical if your FTP area is read-only. 7: As usual, make a pass through the FTP area and make sure that the files are in correct modes and that there's nothing else in there that can be executed. 8: Note, now, that your FTP area's /etc/passwd is totally separated from your real /etc/passwd. This has advantages and disadvantages. 9: Some stuff may break, like syslog, since there is no /dev/log. Either build a version of ftpd with a UDP-based syslog() routine or run a second syslogd based on the BSD Net2 code, that maintains a unix-domain socket named ~ftp/dev/log with the -p flag REMEMBER: If there is a hole in your ftpd that lets someone get "root" access they can do you some damage even chrooted. It's just lots harder. If you're willing to hack some code, making the ftpd run without permissions is a really good thing. The correct operation of your hacked ftpd can be verified by connecting to it and (while it's still at the user prompt) do a ps-axu and verify that it's not running as root. mjr. From firewalls-owner Fri Apr 15 15:29:52 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA02157; Fri, 15 Apr 1994 15:29:52 GMT Received: from tta.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA02151; Fri, 15 Apr 1994 08:29:45 -0700 Received: by tta.com (5.67/TTA-1.00) id AA13879; Fri, 15 Apr 94 10:22:28 -0500 Date: Fri, 15 Apr 94 10:22:28 -0500 From: stan@tta.com (Stan Hanks) Message-Id: <9404151522.AA13879@tta.com> To: 0003858921@mcimail.com Subject: Re: Encrypted tunnels Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I need to understand how do create encrypted tunnels between trading >partners where there can be no requirement of matching firewall products. You might also consider the GRE tunneling protocol as implemented in cisco routers as the basis for building the tunnel. Once you have a tunnel, it's relatively easy to use off-the-shelf encryption products to protect the data flowing through it. Note as well that this solution will work for non-IP routed protocols. I have other solutions for non- routed protocols... Stan Hanks (co-developer of the GRE protocol) From firewalls-owner Fri Apr 15 16:35:44 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA02597; Fri, 15 Apr 1994 16:35:44 GMT Received: from cs.utexas.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA02591; Fri, 15 Apr 1994 09:35:37 -0700 Message-Id: <9404151635.AA04026@cs.utexas.edu> Received: from slip-1-90.ots.utexas.edu by cs.utexas.edu (5.64/1.26/mx-relay) with SMTP id AA04026; Fri, 15 Apr 94 11:35:27 -0500 X-Sender: werner@128.83.139.9 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Apr 1994 11:36:41 -0600 To: nobody@rascal.ics.utexas.edu (FYI -For Your Information- courtesy copy) From: werner@cs.utexas.edu (Werner Uhrig) Subject: [CLIP] Denver/Chinese software scandal Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk [ secondhand phone-call heads-up alert: if I understood correctly the Denver newspapers report this morning.... ] Apparently two Chinese nationals working for a software company in Denver were caught stealing code being developed for communication. They had been given $500,000 by the Chinese govt to set up a company owned by the Chinese govt. while they still worked for the Denver company. A raid on their homes indicate they had set up an elaborate computer system and had copies of the material being developed by their Denver employers. Supposedly this involves national network computer security, but not the Clipper Chip. The story seems to have implications beyond commercial theft. --- Werner Uhrig From firewalls-owner Fri Apr 15 09:50:02 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA02674; Fri, 15 Apr 1994 16:46:07 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA02668; Fri, 15 Apr 1994 09:45:55 -0700 Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA12082; Fri, 15 Apr 94 12:42:49 -0400 Received: by cobalt.house.gov (AA09820); Fri, 15 Apr 94 12:44:19 -0700 Date: Fri, 15 Apr 94 12:44:19 -0700 From: Dorian Deane Message-Id: <9404151944.AA09820@cobalt.house.gov> To: firewalls@GreatCircle.COM Subject: Re: probe_tcp_ports Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > You can get ntop, a kmem-based window connection viewer (shows > listening ports and uid), or even udplog from TAMU's netlog package. > > Mike > > How are these things better than netstat? netstat also uses kmem, so it should be just as hard/easy to hide a connection, I would think. dorian From firewalls-owner Fri Apr 15 10:00:12 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA02667; Fri, 15 Apr 1994 16:45:39 GMT Received: from commix.ikos2.iao.fhg.de by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA02660; Fri, 15 Apr 1994 09:45:14 -0700 Received: by commix.ikos2.iao.fhg.de (5.61+/iao.fhg.de/gandalf) id AA10973; Fri, 15 Apr 94 18:45:29 +0200 Message-Id: <9404151645.AA10973@commix.ikos2.iao.fhg.de> Date: Fri, 15 Apr 94 18:45:29 +0200 From: Wolfram Schmidt To: firewalls@GreatCircle.COM Subject: Re: FTP services -- Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ] From: Marcus J Ranum [...] ] My recent note about running ftpds pre-chrooted has garnered ] me several how-to requests. I'll describe briefly how we do it, and ] I guess I'll add it to the FAQ. [...] ] 6: Write a wrapper to kick ftpd off and install it in /etc/inetd.conf ] The wrapper should look something like: (assuming ~ftp = /var/ftp) ] ] main() ] { [...] ] } I don't know how well this works for other people, but I placed the following line in /etc/inetd.conf (SunOS 4.1.x): [edited to fit on one line] rftp stream tcp nowait root /usr/etc/chroot rftpd /path/PROJECT /bin/rftpd Wolfram Schmidt -- Email: wschmidt@iao.fhg.de Voice: +49 711 970 2431 FAX: +49 711 970 2401 Office: Fraunhofer Institut IAO, Holzgartenstr. 17, 70174 Stuttgart, Germany From firewalls-owner Fri Apr 15 17:07:54 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA02922; Fri, 15 Apr 1994 17:07:54 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA02916; Fri, 15 Apr 1994 10:07:48 -0700 Received: by relay.tis.com; id AA27216; Fri, 15 Apr 94 13:08:24 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma027204; Fri Apr 15 13:07:48 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA21808; Fri, 15 Apr 94 13:06:48 EDT From: Marcus J Ranum Received: by otter.tis.com (4.1/SMI-4.1) id AA06398; Fri, 15 Apr 94 13:06:47 EDT Date: Fri, 15 Apr 94 13:06:47 EDT Message-Id: <9404151706.AA06398@otter.tis.com> To: firewalls@greatcircle.com, ken@bridge.com Subject: Re: FTP services -- Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>4: If you're on a Sun, make a copy of /dev/zero in ~ftp/dev and chown >> it to root. Make sure it's readable. >... >> If there is a hole in your ftpd that lets someone get "root" >> access they can do you some damage even chrooted. It's just > >Gack! I was going to ask why /dev/zero, in case you wanted to have >ftpd chrooted to a partition mounted "nodev" (ignore device files), but >my Suns' man pages don't list that as a mount option! You only need /dev/zero if you're using shared libs. I'm sorry about that -- it was a mistake in my posting. I've (in the past) experimented with setting up chrooted areas that also support dynamic executables, and /dev/zero is needed. With all static linked executables, they're not needed. mjr. From firewalls-owner Fri Apr 15 10:10:02 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA02823; Fri, 15 Apr 1994 17:00:53 GMT Received: from gatekeeper.Bridge.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA02817; Fri, 15 Apr 1994 10:00:44 -0700 Received: from racerx.bridge.com (racerx.bridge.com [167.76.24.6]) by gatekeeper.Bridge.COM (8.6.5/8.6.5) with SMTP id GAA02235; Fri, 15 Apr 1994 06:00:38 -0500 Received: from bert.bridge.com (ernie.bridge.com) by racerx.bridge.com with SMTP id AA26050 (5.67b/IDA-1.5); Fri, 15 Apr 1994 12:01:42 -0500 Date: Fri, 15 Apr 1994 12:01:42 -0500 From: Ken Hardy Message-Id: <199404151701.AA26050@racerx.bridge.com> To: firewalls@greatcircle.com Subject: Re: FTP services -- Cc: mjr@tis.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk mjr wrote: >4: If you're on a Sun, make a copy of /dev/zero in ~ftp/dev and chown > it to root. Make sure it's readable. ... > If there is a hole in your ftpd that lets someone get "root" > access they can do you some damage even chrooted. It's just Gack! I was going to ask why /dev/zero, in case you wanted to have ftpd chrooted to a partition mounted "nodev" (ignore device files), but my Suns' man pages don't list that as a mount option! I started a thread on bugtraq about threats to be aware of from root in a chrooted environment. Being able to mknod devices whence to mount verbotten filesystems is one obvious attack, not to mention /dev/kmem, etc. From firewalls-owner Fri Apr 15 18:01:00 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA03590; Fri, 15 Apr 1994 18:01:00 GMT Received: from news.std.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA03584; Fri, 15 Apr 1994 11:00:53 -0700 Received: from world.std.com by news.std.com (5.65c/Spike-2.1) id AB18760; Fri, 15 Apr 1994 14:01:05 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA04009; Fri, 15 Apr 1994 14:01:00 -0400 Date: Fri, 15 Apr 1994 14:01:00 -0400 (EDT) From: Peter von Zirpolo Subject: TIS Toolkit vs DEC's SEAL To: Firewalls@GreatCircle.Com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We're a large financial institution, looking into the desirability and/or feasibility of connecting to the Internet. Security is (What a shock!) a prime concern and I've begun looking at the TIS Toolkit and DEC's SEAL offering as the basis for a protecting firewall. We're discounting a 'Black Box' approach, as not leaving us with enough flexibility or control after the installation. With SEAL, DEC provides EVERYTHING - hardware, software, setup, tailoring, and staff training but since we have have VERY little UNIX experience, we'd probably require the services of a security consultant (TIS?) even if we went the Toolkit route. >From what I can gather, the Toolkit will support Dual-Homed Gateway, Screened Host, or Screened Subnet approaches, while SEAL is based on the latter. I like to get your knowledgeable opinions on the design issues themselves as well as these two products. Thanks, Peter von Zirpolo From firewalls-owner Fri Apr 15 19:54:58 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA04675; Fri, 15 Apr 1994 19:54:58 GMT Received: from primus.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA04669; Fri, 15 Apr 1994 12:54:50 -0700 Received: (from mre@localhost) by primus.com (8.6.8.1/8.6.8) id MAA07204; Fri, 15 Apr 1994 12:55:15 -0700 Date: Fri, 15 Apr 1994 12:55:15 -0700 (PDT) From: Mike Evans Subject: Re: probe_tcp_ports To: Dorian Deane cc: firewalls@GreatCircle.COM In-Reply-To: <9404151944.AA09820@cobalt.house.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Fri, 15 Apr 1994, Dorian Deane wrote: > > > > You can get ntop, a kmem-based window connection viewer (shows > > listening ports and uid), or even udplog from TAMU's netlog package. > > > > Mike > > > > > > How are these things better than netstat? netstat also uses kmem, > so it should be just as hard/easy to hide a connection, I would > think. > > dorian ntop is like top but for tcp connections.. From firewalls-owner Fri Apr 15 20:26:59 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA05005; Fri, 15 Apr 1994 20:26:59 GMT Received: from databus.databus.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA04999; Fri, 15 Apr 1994 13:26:52 -0700 Date: Fri, 15 Apr 94 16:28 EDT Message-ID: <9404151628.AA02061@databus.databus.com> From: Barney Wolff To: firewalls@greatcircle.com Subject: ntop Content-Length: 136 Content-Type: text Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Since archie has no (exact) match for ntop, can someone give a hint as to where to get it? Thanks, Barney Wolff From firewalls-owner Fri Apr 15 20:37:33 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA05131; Fri, 15 Apr 1994 20:37:33 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA05124; Fri, 15 Apr 1994 13:37:23 -0700 Received: from magna.magna.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwlty12497; Fri, 15 Apr 94 16:37:30 -0400 Received: from magna20.magna.com by magna.magna.com (5.65/MSC-0.9) id AA21274; Fri, 15 Apr 94 16:27:58 -0400 Received: by magna20.magna.com (BOSX 3.2/UCB 5.64/MSC-1.0) id AA53920; Fri, 15 Apr 1994 16:31:24 -0400 Date: Fri, 15 Apr 1994 16:31:24 -0400 From: "Matt D'Errico" Message-Id: <9404152031.AA53920@magna20.magna.com> To: Firewalls@GreatCircle.COM, pvz@world.std.com Subject: Re: TIS Toolkit vs DEC's SEAL Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk For that matter, there's also ANS+Core Interlock as a complete hardware/software package... My company has just contracted TIS to do the installation after some exhaustive research of a bunch. We've found the TIS folks to be extremely reasonable in price (they also will vary price based on existing client expertise) and the most flexible with regard to platform. We happened to have some surplus Sun's and were more than willing to help us work with them... They're also correcting some DNS problems along the way, much less security specific issues... And no, TIS is not restricted to dual-homed implementations. We're using a classic 2 router/ bastion host approach. The nicest thing I just learned only today is that the TIS architecture allows our very large network requirements to expand by adding more bastion hosts if needed ! My vote: TIS... -- Doc From firewalls-owner Fri Apr 15 20:39:45 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA05153; Fri, 15 Apr 1994 20:39:45 GMT Received: from colossus.cse.psu.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA05147; Fri, 15 Apr 1994 13:39:37 -0700 Received: from localhost by colossus.cse.psu.edu with SMTP id <36919>; Fri, 15 Apr 1994 16:39:31 -0400 To: Mike Evans cc: Dorian Deane , firewalls@greatcircle.com Subject: Re: probe_tcp_ports X-Work-Address: Department of Computer Science, 121A Pond Laboratory The Pennsylvania State University, University Park, PA 16802 X-Work-Phone: +1 814 863 1142 (Voice) +1 814 865 3176 (FAX) In-reply-to: Your message of Fri, 15 Apr 1994 15:55:15 EDT. X-Mailer: exmh version 1.3delta 3/31/94 Date: Fri, 15 Apr 1994 16:39:19 -0400 From: Daniel R Ehrlich Message-Id: <94Apr15.163931edt.36919@colossus.cse.psu.edu> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >On Fri, 15 Apr 1994, Dorian Deane wrote: > >> > >> > You can get ntop, a kmem-based window connection viewer (shows >> > listening ports and uid), or even udplog from TAMU's netlog package. >> > >> > Mike >> > >> > >> >> How are these things better than netstat? netstat also uses kmem, >> so it should be just as hard/easy to hide a connection, I would >> think. >> >> dorian > >ntop is like top but for tcp connections.. > > Where can one find all of these goodies? Thanks, Dan Ehrlich From firewalls-owner Fri Apr 15 21:28:46 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA05584; Fri, 15 Apr 1994 21:28:46 GMT Received: from scr.siemens.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA05577; Fri, 15 Apr 1994 14:28:38 -0700 Received: from yogi.siemens.com (yogi.siemens.com [129.73.1.12]) by scr.siemens.com (8.6.8/8.6.6) with ESMTP id RAA19206; Fri, 15 Apr 1994 17:27:39 -0400 Received: (from root@localhost) by yogi.siemens.com (8.6.8/8.6.6) id RAA09560; Fri, 15 Apr 1994 17:24:09 -0400 Date: Fri, 15 Apr 1994 17:24:09 -0400 From: Michael Platoff Message-Id: <199404152124.RAA09560@yogi.siemens.com> To: "Matt D'Errico" CC: Firewalls@GreatCircle.COM, pvz@world.std.com In-reply-to: <9404152031.AA53920@magna20.magna.com> Subject: Re: TIS Toolkit vs DEC's SEAL Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Matt D'Errico" writes: > > For that matter, there's also ANS+Core Interlock as a complete > hardware/software package... > I rarely see Raptor's Eagle/Eaglet products discussed in this group. They appear to have some innovative features. On that note, does anyone have a comparative analysis of various turn-key firewall products that they would be willing to share on this list? From firewalls-owner Fri Apr 15 21:54:17 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA05823; Fri, 15 Apr 1994 21:54:17 GMT Received: from primus.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA05817; Fri, 15 Apr 1994 14:54:11 -0700 Received: (from mre@localhost) by primus.com (8.6.8.1/8.6.8) id OAA08273; Fri, 15 Apr 1994 14:54:38 -0700 Date: Fri, 15 Apr 1994 14:54:37 -0700 (PDT) From: Mike Evans Subject: ntop To: firewalls@greatcircle.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk For those of you who were interested in ntop; it is available for anonymous ftp at ftp.primus.com in /pub/security/tools. Mike From firewalls-owner Sat Apr 16 02:37:54 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA08152; Sat, 16 Apr 1994 02:37:54 GMT Received: from sungear.mame.mu.OZ.AU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA08146; Fri, 15 Apr 1994 19:37:47 -0700 Received: from circlip.mame.mu.OZ.AU (root@circlip.mame.mu.OZ.AU [128.250.210.5]) by sungear.mame.mu.OZ.AU (8.6.4/8.6.4) with ESMTP id MAA09955 for ; Sat, 16 Apr 1994 12:37:48 +1000 Received: from circlip.mame.mu.OZ.AU (mrgreen@localhost [127.0.0.1]) by circlip.mame.mu.OZ.AU (8.6.4/8.6.4) with ESMTP id MAA27920 for ; Sat, 16 Apr 1994 12:37:42 +1000 Message-Id: <199404160237.MAA27920@circlip.mame.mu.OZ.AU> To: firewalls@greatcircle.com Subject: Re: probe_tcp_ports In-reply-to: Your message of "Fri, 15 Apr 1994 12:55:15 MST." Date: Sat, 16 Apr 1994 12:37:36 +1000 From: matthew green Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >ntop is like top but for tcp connections.. as long as you don't get connected to a ``fake'' (*) ident server, that is. .mrg. (*) you should be capable of defining ``fake'' here. From firewalls-owner Sun Apr 17 15:11:57 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA04409; Sun, 17 Apr 1994 22:02:04 GMT Received: from cs.utexas.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA04395; Sun, 17 Apr 1994 15:01:49 -0700 Message-Id: <9404170055.AA09498@cs.utexas.edu> Received: from slip-14-13.ots.utexas.edu by cs.utexas.edu (5.64/1.27/mx-relay) with SMTP id AA09498; Sat, 16 Apr 94 19:55:22 -0500 X-Sender: werner@128.83.139.9 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 16 Apr 1994 19:56:34 -0600 To: Firewalls@GreatCircle.COM From: werner@cs.utexas.edu (Werner Uhrig) Subject: [CLIP] more on Denver/Chinese software scandal Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Reuter reports that a federal judge, citing national security concerns, refuses to release from house arrest a Chinese suspect, because it is "a serious offense involving much money and, potentially, national security, An FBI agent told the judge that the alleged theft of source code fits a "profile of Chinese intelligence operations." The source code is described as "part of the information superhighway" valued at significantly more than $1 million. Two men arrested earlier this year were accused by a grand jury of planning to supply unspecified technology to Beijing Machinery Import & Export in return for $550,000. Both men have pleaded innocent. Obtaining technology from American companies is the suggested motive of the theft from Ellery Systems (Boulder) which "is developing software for the information superhighway." Data/Code was apparently transfered over the Internet from one guy (working at Ellery) to the other, employed at Unidata. A company named China Resource Products (U.S.A) Ltd., Inc was named as a cover for the whole operation. --- Werner Uhrig From firewalls-owner Sun Apr 17 23:41:11 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA04766; Sun, 17 Apr 1994 23:41:11 GMT Received: from post.demon.co.uk by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA04760; Sun, 17 Apr 1994 16:41:01 -0700 Received: from demon.demon.co.uk by post.demon.co.uk id aa19269; 18 Apr 94 0:39 GMT-60:00 Received: from cellnet.uucp by demon.demon.co.uk id aa29063; 17 Apr 94 23:38 BST From: Steve Kennedy Message-Id: <783.9404172312@marvin.gbnet.org> Subject: Re: Encrypted tunnels To: mcimail.com!0003858921@gbnet.org Date: Sun, 17 Apr 1994 23:12:52 +0000 (GMT) Cc: greatcircle.com!firewalls@gbnet.org In-Reply-To: <14940414120541/0003858921NA4EM@mcimail.com> from "Robert G. Moskowitz" at Apr 14, 94 07:05:00 am X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1379 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob, > I need to understand how do create encrypted tunnels between trading > partners where there can be no requirement of matching firewall products. You could get a commercial KarlBridge. This will allow tunnelling (of any protocol within IP) between any two (or more) addresses. The tunnel may also be encrypted. If the traffic is purely IP that may be encrypted between any addresses. Currently the encryption is really a 'translation' on a byte basis. This is not 'real' encryption (UK GCHQ definition anyway) but is good enough to deter snoopers etc. There are plans to implement DES/IDEA etc. but then the bridge is covered under munitions and export becomes a problem. Current all encryption work is being 'designed' in the UK, but there are still problems with exporting encryption code. Regards Steve -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 WorldBlazer T3000 V32bis/PEP+... ISDN: 722 7969/70 Email Snail Mail steve@gbnet.{org,com,net} [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd stevek@cellnet.co.uk [work] London, NW3 4LU From firewalls-owner Tue Apr 19 15:34:46 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA11936; Tue, 19 Apr 1994 15:34:46 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA11930; Tue, 19 Apr 1994 08:34:36 -0700 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05240; Tue, 19 Apr 94 08:34:57 PDT Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1/SMI-4.1) id AA20296; Tue, 19 Apr 94 08:34:06 PDT Received: from elbow.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA01050; Tue, 19 Apr 1994 08:34:54 -0700 Received: by elbow.Eng.Sun.COM (5.x/SMI-SVR4) id AA00612; Tue, 19 Apr 1994 08:35:21 -0700 Date: Tue, 19 Apr 1994 08:35:21 -0700 From: Paul.Fronberg@Eng.Sun.COM (Paul Fronberg [CONTRACTOR]) Message-Id: <9404191535.AA00612@elbow.Eng.Sun.COM> To: firewalls@greatcircle.com Subject: Talk on firewalls and Internet security at Sun Microsystems April 20th Content-Type: X-sun-attachment Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 2 The speaker suggested that I post the announcement of the talk to this mailing list. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: firewall X-Sun-Charset: us-ascii X-Sun-Content-Lines: 53 SVNet Meeting Wednesday, April 20, 1994, 7:30pm - FREE and OPEN TO THE PUBLIC. WHAT: Firewalls and Internet Insecurity In today's world of hackers and crackers, a corporation's enterprise network needs a secure gateway (or "firewall") to protect its systems from the Internet while at the same time providing interconnectivity. Too much security and it becomes unusable or bypassed; too little and it is easily usurped. We will be discussing current firewall alternatives hardware and software, including bastion hosts and DMZ networks. WHO: Geoff Mulligan, SunSoft Geoff Mulligan is a Member of the Technical Staff in the Internet Engineering group at SunSoft. He works on the TCP/IP kernel and ultiity software in Solaris 2, Sun's operating system. He also works on disconnected e-mail processing, and network security firewalls and encryption. Prior to joining Sun, Geoff worked at Digital's Network Systems Laboratory where is was project lead on the DEC SEAL (a firewall) product, and Director of Education. Before working at Digital, he spent 11 years in the Air Force working at the Pentagon on networking and network security (an oxymoron) issues throughout the Air Force and building campus wide networks and teaching computer science at the Air Force Academy. Geoff received is M.Sc in 1988 from the University of Denver and B.Sc. in 1979 from the United States Air Force Academy. WHEN: Wednesday, April 20, 1994 at 7:30pm Please note that we will now be meeting on the 3rd Wednesday of the month! WHERE: Sun Microsystems Bldg 6, 2750 Coast Avenue, Mountain View Coast Ave appears to be just a driveway next to Bldg 5 on Garcia Ave between Amphitheatre Pkwy and San Antonio, so don't get confused. FOR MORE INFORMATION: please call either Paul Fronberg at (415) 366-6403 or Ralph Barker at (408) 559-6202. SVNet is a UNIX and open systems user group supported by member dues and donations. SVNet Meetings are FREE and OPEN TO THE PUBLIC. UNIX is a registered trademark of Unix System Laboratories, Novell or X/Open (few people are sure anymore) From firewalls-owner Tue Apr 19 16:25:45 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA12128; Tue, 19 Apr 1994 16:25:45 GMT Received: from spectre.uunet.ca by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA12122; Tue, 19 Apr 1994 09:25:38 -0700 Received: from cchtor.ca.cch.com ([192.139.241.2]) by spectre.uunet.ca with SMTP id <33524(2)>; Tue, 19 Apr 1994 12:25:48 -0400 Received: (from larry@localhost) by cchtor.ca.cch.com (8.6.8.1/8.6.6) id MAA07357 for firewalls@greatcircle.com; Tue, 19 Apr 1994 12:28:39 -0400 Date: Tue, 19 Apr 1994 12:28:39 -0400 From: Larry Chin Message-Id: <199404191628.MAA07357@cchtor.ca.cch.com> To: firewalls@greatcircle.com Subject: routing tables for DMZ machines Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello all. I was wondering if anyone has some generic examples of routing tables for the machines in an external router/bastion host/internal router configuration, or would be willing to comment on the tables that I have formulated. I guess I am looking for some verification of my thinking. At the moment it looks something like the following ( generic IP addresses ) 192.100.100.x - external net 192.200.200.x - internal net 192.250.250.x - internal net Routing Table on External router ( 192.100.100.1 ) ================================= default route to the Internet Routing table on Bastion Host: ( 192.100.100.2 ) ============================= default 192.100.100.1 192.200.200.x 192.100.100.3 100.250.250.x 192.100.100.3 Routing table on Internal router ( 192.100.100.3) ================================================= internal net ( 192.200.200.1) interface 2 internal net ( 192.250.250.1) interface 3 default 192.200.200.1 192.250.250.x 192.250.250.1 102.200.200.x 192.200.200.1 192.100.100.x 192.100.100.3 Any and all comments or pointers are welcome. Tue Apr 19 12:26:54 EDT 1994 =========================================================================== Larry Chin {larry@cchtor.ca.cch.com} CCH Canadian Ltd. System Administrator 6 Garamond Court Research and Development North York, Ontario. (416) 441-4001 ext. 349 M3C 1Z5 =========================================================================== Johnson's First Law: When any mechanical contrivance fails, it will do so at the most inconvenient possible time. From firewalls-owner Wed Apr 20 03:40:50 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA16890; Wed, 20 Apr 1994 08:46:03 GMT Received: from relay1.pipex.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA16884; Wed, 20 Apr 1994 01:45:54 -0700 From: R.P.Handy@ste0411.wins.icl.co.uk X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=GB/; Relayed; Wed, 20 Apr 1994 09:45:24 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Wed, 20 Apr 1994 09:42:23 +0100 Date: Wed, 20 Apr 1994 09:42:23 +0100 X400-Originator: R.P.Handy@ste0411.wins.icl.co.uk X400-Recipients: firewalls@GreatCircle.COM X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0411 0000042100003096] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3096 Message-ID: <"3096*/I=RP/S=Handy/OU=ste0411/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: firewalls@GreatCircle.COM Subject: Information request: Sprint Plus Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello, I am trying to find information about Sprint Plus. In particular, what does it do, how does it compare with the ANS Interlock and is it avialable in the UK? Does anyone know a UK Sprint contact number? If anyone from Sprint is listening, please get in touch. Thanks. Rich Handy +44 438 313361 r.p.handy@ste0411.wins.icl.co.uk From firewalls-owner Wed Apr 20 10:50:45 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA17768; Wed, 20 Apr 1994 10:50:45 GMT Received: from gw1.att.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA17762; Wed, 20 Apr 1994 03:50:39 -0700 From: uezechuk@mlsma.att.com Received: from mlsma.UUCP by ig1.att.att.com id AA12379; Wed, 20 Apr 94 06:51:04 EDT Message-Id: <9404201051.AA12379@ig1.att.att.com> Date: 20 Apr 94 10:53:00 GMT To: firewalls@greatcircle.com Subject: Help Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk HELP From firewalls-owner Wed Apr 20 08:30:49 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA20224; Wed, 20 Apr 1994 15:20:50 GMT Received: from ll.mit.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA20203; Wed, 20 Apr 1994 08:20:37 -0700 Received: by ll.mit.edu (4.1/LL-1.3) id AA29262; Wed, 20 Apr 94 11:19:21 EDT Date: Wed, 20 Apr 94 11:19:20 -0400 From: kevinmac@ll.mit.edu (Kevin McElearney) Message-Id: <9404201119.AA23331@LL.MIT.EDU> To: firewalls@GreatCircle.COM Subject: Dual Homed Attached Printers (PROBLEMS?) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does anyone see security problems in connecting a Apple Laserwriter printer to networks both inside a firewall and outside. One connection would be to it's ethernet port (outside) and the other would be to it's Appletalk port (inside) which in turn connects to a GatorBox. Would it be possible (practical or theoretical) for an *outside* user to do any of the following to a PostScript printer: o Route packets through the printer to the internal network o Capture / redirect any printouts from the inside out o any others? The following I know o Printer can be corrupted o I can set the PS password for serverdict commands NOTE: Please respond directly to me and not the entire list. I will summarize back to the list. Thx Kevin McElearney ----------------------------------------------------------------------------- MIT Lincoln Laboratory Phone: (617) 981-3556 244 Wood Street, MS C157 Fax: (617) 981-0782 Lexington, MA 02173-9108 EMail: kevinmac@ll.mit.edu From firewalls-owner Wed Apr 20 08:40:52 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA20160; Wed, 20 Apr 1994 15:16:02 GMT Received: from sprintlink.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA20152; Wed, 20 Apr 1994 08:15:51 -0700 Received: by sprintlink.net (5.65/1.34) id AA16279; Wed, 20 Apr 94 11:16:19 -0500 Date: Wed, 20 Apr 1994 11:16:18 -0500 (EST) From: Luther Garcia Reply-To: Luther Garcia Subject: Re: Information request: Sprint Plus To: R.P.Handy@ste0411.wins.icl.co.uk Cc: firewalls@GreatCircle.COM In-Reply-To: <"3096*/I=RP/S=Handy/OU=ste0411/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Wed, 20 Apr 1994 R.P.Handy@ste0411.wins.icl.co.uk wrote: > Hello, I am trying to find information about Sprint Plus. In > particular, what does it do, how does it compare with the ANS > Interlock and is it avialable in the UK? Does anyone know a UK > Sprint contact number? If anyone from Sprint is listening, > please get in touch. Thanks. > Rich Handy +44 438 313361 r.p.handy@ste0411.wins.icl.co.uk > You can find out all the info you need by talking to Bo Thomas 703-904-2000, this is a switch-board number so you can just leave a message. I don't know alot about it really, but I do know that it is available in the UK, Bo will be able to hook you up with the right people. Please feel free to contact me if you have anymore questions about sprintlink. luth@sprintlink.net From firewalls-owner Thu Apr 21 14:38:20 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA00260; Thu, 21 Apr 1994 20:42:43 GMT Received: from bagout.BELL-ATL.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA00236; Thu, 21 Apr 1994 13:42:27 -0700 Received: by bagate.BELL-ATL.COM (O) id ; Thu, 21 Apr 94 12:34 EDT Received: by bagate.BELL-ATL.COM (I1) id ; Thu, 21 Apr 94 12:33 EDT Received: by if000353.bell-atl.com (/\==/\ Smail3.1.28.1 #28.2) id ; Thu, 21 Apr 94 12:31 EDT Message-Id: From: bbh7rqj@if000353.bell-atl.com (Davies) Subject: Applications authenticating to firewalls To: firewalls@GreatCircle.COM Date: Thu, 21 Apr 94 12:31:31 EDT Reply-To: Christopher.I.Davies@Bell-Atl.Com X-Mailer: ELM [version 2.3 PL8] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We have a need for firewall(s) on our interal "internet". We need a proxy application approach rather than just router filtering/screening. We have seen several products that meet most of our requirements, but we still have a few outstanding issues. Most importantly is that we have APPLICATIONS wanting to pass (authenticated of course) through the firewall in addition to ordinary interactive users. A specific example would be the following: We have an application "A" running on an MVS mainframe which is connected to our "internet" with tcp/ip. Application A wishes to talk across the internet to application "B" running on a UNIX box. The applications may wish to transfer files or have other interactions. Application A may have the same userid asssociated with it at all times. We want to put a firewall between the MVS machine and our internet. Is this possible? What alternatives are there? Are there any vendors that might offer such a product? Remember this is a scripted job rather than interactive. Thanks for your help, Chris. -- ****************************************************************************** Chris Davies e-mail: Christopher.I.Davies@bell-atl.com Information Highway Network Voice: (301) 989-4111 Bell Atlantic Fax: (301) 989-3945 ****************************************************************************** From firewalls-owner Thu Apr 21 14:39:47 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA00980; Thu, 21 Apr 1994 21:03:30 GMT Received: from spike.insci.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA00974; Thu, 21 Apr 1994 14:03:21 -0700 Received: by spike.insci.com (5.65/1.2-eef) id AA01461; Thu, 21 Apr 94 17:02:38 -0400 Message-Id: <9404212102.AA01461@spike.insci.com> From: brad@spike.insci.com (Brad Segal) X-Mailer: SCO System V Mail (version 3.2) To: firewalls@greatcircle.com Date: Thu, 21 Apr 94 17:02:37 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk join From firewalls-owner Thu Apr 21 22:46:54 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA02454; Thu, 21 Apr 1994 22:46:54 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA02448; Thu, 21 Apr 1994 15:46:33 -0700 Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id PAA29781 for ; Thu, 21 Apr 1994 15:42:09 -0700 Message-Id: <199404212242.PAA29781@mailgate.cadence.com> Received: from mac32_223.cadence.com(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma029748; Thu Apr 21 15:41:38 1994 Date: Thu, 21 Apr 1994 15:41:39 -0800 To: firewalls@greatcircle.com From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: IRC Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Anyone have a good way to block and/or proxy Internet Remote Chat? It keeps firing up inbound connections to random port numbers, and I'm missing a lot of sleep.... Al --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From firewalls-owner Thu Apr 21 23:09:43 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA02688; Thu, 21 Apr 1994 23:09:43 GMT Received: from tadpole by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA02682; Thu, 21 Apr 1994 16:09:36 -0700 Received: from chiba.tadpole.com by tadpole (4.1/SMI-4.1-jim) id AA10532; Thu, 21 Apr 94 18:09:20 CDT Received: by chiba.tadpole.com (5.0/SMI-SVR4) id AA07774; Thu, 21 Apr 1994 18:09:55 +0600 Date: Thu, 21 Apr 1994 18:09:55 +0600 From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9404212309.AA07774@chiba.tadpole.com> To: alastair@cadence.com Subject: Re: IRC Cc: firewalls@GreatCircle.COM Content-Length: 114 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk IRC is so incredibly braindamaged that you're better off without it. The whole thing aches for multicast. Jim From firewalls-owner Fri Apr 22 01:53:09 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA03495; Fri, 22 Apr 1994 01:53:09 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA03488; Thu, 21 Apr 1994 18:52:57 -0700 Received: by relay.tis.com; id AA25713; Thu, 21 Apr 94 21:53:53 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma025705; Thu Apr 21 21:53:41 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA24245; Thu, 21 Apr 94 21:52:28 EDT Date: Thu, 21 Apr 94 21:52:28 EDT From: Marcus J Ranum Message-Id: <9404220152.AA24245@tis.com> To: Christopher.I.Davies@Bell-Atl.Com, firewalls@GreatCircle.COM Subject: Re: Applications authenticating to firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >A specific example would be the following: We have an application "A" running >on an MVS mainframe which is connected to our "internet" with tcp/ip. >Application A wishes to talk across the internet to application "B" running >on a UNIX box. The applications may wish to transfer files or have other >interactions. Application A may have the same userid asssociated with it >at all times. We want to put a firewall between the MVS machine and >our internet. The reason that the proxy server approach was developed was to gain higher assurance by completely blocking network level traffic. If you're not routing any traffic, then you only need to worry about your gatewaying applications and your host security -- it simplifies things. Your example illustrates the main problem with the proxy approach: it's very reductionist and some applications just don't proxy very well. In that case, you have 2 choices: a) Tell the end user, "Sorry. No can do." -- and they'll go find someone to replace you who tells them they don't need a firewall at all. :) b) Bend the rules. The TIS firewall toolkit is *designed* to work on a firewall that doesn't route traffic. After all, that's what proxies are for. It doesn't, however, mean that you can't mix and match approaches as long as you're very careful and think about what you're doing before you do it. Suppose you have a trustworthy business relationship with someone, and you need to access one of their machines, peer-to-peer, without a firewall in the way. You can do something like set up a bastion host running our software, in *parallel* with a screening router, and configure the router to let traffic between the two machines that need to talk. Everyone else has to go through the bastion host and proxies. You're leaving a "hole" in your defenses and that's a risk -- but if it's the only option, then it might be worth it. Obviously, you want to close the "hole" down as tightly as possible -- if there's only a few service ports needed, shut the rest down. You can also protect the point-to-point connection with encryption, if need be. We've been experimenting with the TIS toolkit running on BSDI with screend to control routing. It's a pretty flexible package -- you can route through it, or proxy through it, depending on the policy you want to enforce. ["It's a router! No! it's a firewall! No! it's a firewall AND a router!] You need to be careful with this kind of stuff. If they are allowed bidirectional access with you, if they are broken into, they can act as a jumping off point into your network. You may consider instituting security sweeps on all your machines that talk directly to remote business partners in such a manner. I've talked to a few customers who have had similar requirements -- what gets fun is when your "business partner" expects their machine to have complete access to your whole WAN, bidirectionally, but they screen you so that you can only talk to one server on their 'net -- a server that's tightly secured. In that case, you want to ask them what their liability is if someone breaks into you through them. Getting a copy of their security policy [they *DO* have one, right?] and incident response practices might be worthwhile. In a sense you're making them part of your perimeter. >Is this possible? What alternatives are there? Are there any vendors >that might offer such a product? Remember this is a scripted >job rather than interactive. Scripted job implies authentication that's part of the script, I.e.; a password or something like that. That can be dangerous over the 'net, as I think we've already seen. Scripted jobs can be problematic, unless the thing on the other side of the script runs in a fairly secure manner. If you're using plain passwords in script jobs you might want to consider using network-level encryption. mjr. From firewalls-owner Fri Apr 22 01:57:26 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA03578; Fri, 22 Apr 1994 01:57:26 GMT Received: from SINet.SLB.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA03571; Thu, 21 Apr 1994 18:57:14 -0700 Received: from San-Jose.ate.slb.com (k2-1.San-Jose.ate.slb.com) by SINet.SLB.COM id AA00473; Fri, 22 Apr 94 02:02:21 GMT Received: from bishom.San-Jose.ate.slb.com by San-Jose.ate.slb.com (4.1/SMI-4.1-DNI-7.0.1-Y) id AA17766; Thu, 21 Apr 94 18:51:50 PDT From: basie@San-Jose.ate.slb.com (Basie Etukudo) Message-Id: <9404220151.AA17766@San-Jose.ate.slb.com> Received: by bishom.San-Jose.ate.slb.com (4.1/SMI-4.1) id AA06291; Thu, 21 Apr 94 18:57:02 PDT To: firewalls@greatcircle.com Date: Thu, 21 Apr 94 18:57:01 -0700 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Please ad me ti the firewall mailing list. Thanks, /basie From firewalls-owner Fri Apr 22 05:04:47 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA04614; Fri, 22 Apr 1994 05:04:47 GMT Received: from clark.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA04608; Thu, 21 Apr 1994 22:04:36 -0700 From: farsight@clark.net Received: (from farsight@localhost) by clark.net (8.6.8/8.6.7) id BAA19382; Fri, 22 Apr 1994 01:06:18 -0400 Date: Fri, 22 Apr 1994 01:06:17 -0400 (EDT) Subject: Re: IRC To: Jim Thompson cc: alastair@cadence.com, firewalls@GreatCircle.COM In-Reply-To: <9404212309.AA07774@chiba.tadpole.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Thu, 21 Apr 1994, Jim Thompson wrote: > > IRC is so incredibly braindamaged that you're better off without it. > > The whole thing aches for multicast. > > > Jim > I agree semi-heartedly with Jim that it is a damaged, not to mention the custom scripts IRC users have added-on, the custom BOTs written in C that do who knows what, and the known habit of young IRC users of xmitting who knows what software via the DCC commands to each other in the background while chatting -- IRC is both ugly and beautiful and frightening from user involvement, much like the early days of UNIX itself. Get rid of it, _unless_ you have several dozen frenzied IRC addicts at your site screaming at you to put it back up. :-) I know of no easy solution to the random port problem with IRC, and would be interested in hearing from other in regards to this. Kurt From firewalls-owner Fri Apr 22 11:16:12 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA06020; Fri, 22 Apr 1994 11:16:12 GMT Received: from zon.sepa.tudelft.nl by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA06014; Fri, 22 Apr 1994 04:16:04 -0700 Received: from tbmail.sepa.tudelft.nl by zon.sepa.tudelft.nl with SMTP (16.6/16.2) id AA09225; Fri, 22 Apr 94 13:10:34 +0200 Received: From ZONDISK/MAIL-WORKQUEUE by tbmail.sepa.tudelft.nl via Charon-4.0A-VROOM with IPX id 100.940422131000.352; 22 Apr 94 13:10:07 +0500 Message-Id: To: firewalls@GreatCircle.COM From: Date: Fri, 22 Apr 1994 13:09:52 MET Subject: Priority: normal X-Mailer: WinPMail v1.0 (R2) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk help +------------------------------------------+----------------------+ | Ronald Otte | Jaffalaan 5 | | Faculteit der Technische Bestuurskunde | 2629 JB Delft | | Technische Universiteit Delft | Tel. 015-785290 | | email: Otte@sepa.tudelft.nl | Fax. 015-784811 | +------------------------------------------+----------------------+ | I'm still confused, but on a much higher level ! | +-----------------------------------------------------------------+ From firewalls-owner Fri Apr 22 12:02:40 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA06165; Fri, 22 Apr 1994 12:02:40 GMT Received: from alphalma.cnrs-mrs.fr by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA06159; Fri, 22 Apr 1994 05:02:32 -0700 From: vincendon@ALPHALMA.CNRS-MRS.FR Received: by ALPHALMA.CNRS-MRS.FR (MX V3.3 AXP) id 909; Fri, 22 Apr 1994 14:01:23 EDT Date: Fri, 22 Apr 1994 14:01:20 EDT To: firewalls@GreatCircle.COM Message-ID: <0097D570.89A61E6A.909@ALPHALMA.CNRS-MRS.FR> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From firewalls-owner Fri Apr 22 13:00:54 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA06409; Fri, 22 Apr 1994 13:00:54 GMT Received: from Darwin.CMH.McMaster.CA by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA06403; Fri, 22 Apr 1994 06:00:47 -0700 Received: from Darwin.CMH.McMaster.CA by Darwin.CMH.McMaster.CA (PMDF V4.2-14 #3) id <01HBGXGKH59S000HBF@Darwin.CMH.McMaster.CA>; Fri, 22 Apr 1994 09:00:52 EST Date: Fri, 22 Apr 1994 09:00:52 -0500 (EST) From: Marty Viilma Subject: wildcard ptr rec To: firewalls@greatcircle.com Message-id: <01HBGXGKIR5E000HBF@Darwin.CMH.McMaster.CA> X-VMS-To: IN%"firewalls@greatcircle.com" MIME-version: 1.0 Content-transfer-encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been trying to implement the strategy of returning an unknown.mydomain response with a wildcard ptr rec but when testing the address to name translation with nslookup it only return an A rec not found response. The record looks like this currently: * IN PTR unknown.mydomain. Do I need an A rec of some description as well? Any help would be appreciated. Marty From firewalls-owner Fri Apr 22 14:52:20 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA07013; Fri, 22 Apr 1994 14:52:20 GMT Received: from ttown.apci.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA07007; Fri, 22 Apr 1994 07:52:08 -0700 Received: by ttown.apci.com (5.57/Ultrix3.0-C) id AA14157; Fri, 22 Apr 94 10:54:14 -0400 Date: Fri, 22 Apr 94 10:54:14 -0400 From: gaulse@ttown.apci.com (that kid in research...) Message-Id: <9404221454.AA14157@ttown.apci.com> To: firewalls@greatcircle.com Subject: WWW, Wais and Gopher proxies Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We here at APCI are currently reviewing our present firewall setup and looking into the possibility of adding additional services as well as "seamless" connectivity to the internet. I've been monitoring this list four about the last 5 months or so and I seem to recall someone mentioning the development of "secure" proxies for WWW, Gopher and Wais... Can anyone tell me the current status of development or proxies that may become available for these services? Any help would be appreciated. Thanks in advance, ______________________________________________________________________ /// / /// Stephen E. Gaul, Jr. / /// /\ Air Products and Chemicals, Inc. / __/// /__\ Lehigh Valley, PA 18001 / ///_ ______ __ INET: gaulse@ttown.apci.com || gaulS@moravian.edu / ///// /______\ \/ VOICE: (215) 481-7054 / ///______________ FAX: (215) 481-3988 / //////////////////____________________________________________________/ NOTE: These statements and opinions are mine, not those of APCI... From firewalls-owner Fri Apr 22 15:21:50 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA07259; Fri, 22 Apr 1994 15:21:50 GMT Received: from bosnia.pop.psu.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA07252; Fri, 22 Apr 1994 08:21:39 -0700 Received: from localhost (barr@localhost) by bosnia.pop.psu.edu (8.6.5/8.6.5) with ESMTP id LAA12675 for ; Fri, 22 Apr 1994 11:21:34 -0400 Message-Id: <199404221521.LAA12675@bosnia.pop.psu.edu> To: firewalls@greatcircle.com Subject: Re: wildcard ptr rec In-reply-to: Your message of "Fri, 22 Apr 1994 09:00:52 CDT." <01HBGXGKIR5E000HBF@Darwin.CMH.McMaster.CA> X-Face: $+9-wYg.[->94HJ{go[7Q]E!K&hUg7ZhLyCMyq_FU*ca0GazE>^/2BKLcK0bP-'%;Nn?M+am,jlSP>1K$iz@ %'v'FEW{@](U&Ed/}>ju3Ctlr!XwJ27Q)7h2a%"`sz;j:/3EC[mXi@*X@HE1]'ddq$ZX"ePsMyTkeg >zdML.SVvX1W`adGIUD Date: Fri, 22 Apr 1994 11:21:33 -0400 From: David Barr Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <01HBGXGKIR5E000HBF@Darwin.CMH.McMaster.CA>, Marty Viilma writes: >I've been trying to implement the strategy of returning an unknown.mydomain >response with a wildcard ptr rec but when testing the address to name >translation with nslookup it only return an A rec not found response. >The record looks like this currently: >* IN PTR unknown.mydomain. Ouch. This is likely to cause some bizarre problems for you. I would not recommend doing this unless 1) you know all the consequences and 2) you have a real reason for doing something like this. >Do I need an A rec of some description as well? Sun's gethostbyaddr() checks that PTR records match addresses with an A record. Many programs like tcp_wrapper (with -DPARANOID) also do a similar check. If you want these to not return error messages, you're going to have to have an A record for every possible unknown address, and that's very likely to overflow internal resolver tables and break things. Why not just put in individual PTR records and A records for all possible addresses for your zone? Why do you need a name for every unknown address, anyway? --Dave From firewalls-owner Fri Apr 22 16:31:17 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA07665; Fri, 22 Apr 1994 16:31:17 GMT Received: from gatekeeper.Bridge.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA07659; Fri, 22 Apr 1994 09:31:03 -0700 Received: from localhost (mail@localhost) by gatekeeper.Bridge.COM (8.6.5/8.6.5) id LAA11002; Fri, 22 Apr 1994 11:12:02 -0500 Received: from racerx.bridge.com(167.76.24.6) by gatekeeper.Bridge.COM via smap (V1.0mjr) id sma011000; Fri Apr 22 11:11:40 1994 Received: from bert.bridge.com (ernie.bridge.com) by racerx.bridge.com with SMTP id AA00397 (5.67b/IDA-1.5); Fri, 22 Apr 1994 11:13:45 -0500 Date: Fri, 22 Apr 1994 11:13:45 -0500 From: Ken Hardy Message-Id: <199404221613.AA00397@racerx.bridge.com> To: gaulse@ttown.apci.com Subject: Re: WWW, Wais and Gopher proxies Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk That kid in research wrote: >or so and I seem to recall someone mentioning the development >of "secure" proxies for WWW, Gopher and Wais... > >Can anyone tell me the current status of development or >proxies that may become available for these services? (Usuall warnings about firewall proxy not protecting you from certain potential insecurities in the underlying applications & their protocols, etc.) The CERN httpd server will serve as a proxy for WWW, Gopher, FTP, NNTP, and, reportedly, WAIS when those services are used from the latest versions of Mosaic, which can be made to understand the proxy by the addition of some environment variables or resource entries. It seems to work very well, except for these two problems: 1. It does _not_ want to proxy WAIS for us. Mosaic sends the request to the proxy, and then it says "...could not be accessed...". I'd appreciate communications from anyone who has WAIS working, preferably through Mosaic, but I'd settle for any sort of connectivity. 2. We cannot seem to get to an internal HTTP server when using the proxy on the firewall. It seems that the request should go to the proxy which will resolve the hostname to the internal host and forward the request there, handle the response, etc.; it shouldn't differentiate between internal & external servers (it does clients; it won't accept external connections; it runs chrooted under the TIS toolkit which rejects external connections before launhing the server.) Any help with this problem is also appreciated; does anyone have this sort of setup working? -KH From firewalls-owner Fri Apr 22 19:19:11 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA08711; Fri, 22 Apr 1994 19:19:11 GMT Received: from spool.cs.wisc.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA08704; Fri, 22 Apr 1994 12:19:02 -0700 Received: by spool.cs.wisc.edu; Fri, 22 Apr 94 14:17:01 -0500 Received: by Arnold.Com with UUCP/PMDF (DECUS UUCP); Fri, 22 Apr 1994 14:13:37 -0500 (CDT) Received: from Arnold.Com by Arnold.Com (PMDF V4.3-7 #6072) id <01HBH19G7FTC8WVYKK@Arnold.Com>; Fri, 22 Apr 1994 14:13:09 -0500 (CDT) Date: Fri, 22 Apr 1994 14:02:19 -0500 (CDT) From: Stephen.L.Arnold@Arnold.Com Subject: Wanted: firewall manager position description To: Firewalls@GreatCircle.Com Cc: Stephen.L.Arnold@Arnold.Com Message-Id: <01HBH8JBQ6KS8WVYKK@Arnold.Com> Organization: Arnold Consulting Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm a long-time lurker on this list and an independent consultant whose practice seems to involve more firewalls all the time. One of my clients is a large organization and seems to be comitted to doing firewalls right. They intend to hire a few staff members to manage and monitor their firewalls (they expect to be dual-connected to the Internet) and to develop new, secure firewall applications specific to their business. I'm looking for some boilerplate that describes firewall (and related systems) management tasks and skills as input to this staffing process. If any of you have such text that you wouldn't mind sharing, please send it to me by private mail. (If it's *really* good, send it to the list, too, but I'm willing to do more editing and integration of fragments than the average ready of this list.) Please don't send your resume (unless it contains useful input for a position description)! I'm not the one who will be doing any hiring, and I won't be forwarding prospective names to anyone who will. Thanks in advance for any input you can provide! Regards, "Steve" Stephen L. Arnold, Ph.D., Principal, Arnold Consulting Address 4138 Iroquois Drive, Madison, Wisconsin 53711-3701 U.S.A. Telephone +1 608 238 4850 Facsimile +1 608 238 4855 Internet Stephen.L.Arnold@Arnold.Com BITNET ARNOLD@WISCPSL Pager (800) Sky-Page, PIN 238-4850 From firewalls-owner Fri Apr 22 19:26:03 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA08748; Fri, 22 Apr 1994 19:26:03 GMT Received: from odie.gta.doc.ca by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA08742; Fri, 22 Apr 1994 12:25:08 -0700 Received: from apnetadmin.gta.doc.ca by odie.gta.doc.ca id aa05627; 22 Apr 94 15:13 EDT Received: by apnetadmin.gta.doc.ca (4.1/SMI-4.1) id AA22231; Fri, 22 Apr 94 15:30:04 EDT From: Neil Kochar Message-Id: <9404221930.AA22231@apnetadmin.gta.doc.ca> Subject: Course on Innernet Security isues. To: firewalls@GreatCircle.COM Date: Fri, 22 Apr 94 15:30:03 EDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Just wondering if anyone knows of any course being offered on the security aspect of the Internet access. Neil Kochar From firewalls-owner Fri Apr 22 20:25:46 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA08957; Fri, 22 Apr 1994 20:25:46 GMT Received: from gate.ggr.co.uk by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA08951; Fri, 22 Apr 1994 13:25:36 -0700 Received: from mailhub.ggr.co.uk by gate.ggr.co.uk; Fri, 22 Apr 1994 21:24:02 +0100 Received: from uk0x04 by mailhub.ggr.co.uk; Fri, 22 Apr 1994 21:20:37 +0100 Received: by uk0x04 (8.6.8.1/imd160294) id VAA09158; Fri, 22 Apr 1994 21:23:54 +0100 Date: Fri, 22 Apr 1994 21:23:52 +0100 (BST) From: Ian Dunkin Reply-To: Ian Dunkin Subject: Re: WWW, Wais and Gopher proxies To: Ken Hardy cc: firewalls@GreatCircle.COM In-Reply-To: <199404221613.AA00397@racerx.bridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Fri, 22 Apr 1994, Ken Hardy wrote: > 2. We cannot seem to get to an internal HTTP server when using the > proxy on the firewall. It seems that the request should go to the > proxy which will resolve the hostname to the internal host and > forward the request there, handle the response, etc.; it shouldn't > differentiate between internal & external servers Silly question: Are you sure it's not simply that your firewall configuration (eg router filters) is such that connections cannot be initiated inwards from the firewall system back into your internal net? -- this would not be an unusual setup. In which case, although the httpd gets and tries to fulfil a request to an internal resource, it physically cannot get back to it. The CERN WWW people have been talking (www-talk list) about a mechanism to allow the proxy redirections on the client to differentiate between those to directly accessible nets and those which must be proxied; but this is not there yet. This problem of inward access back to internal servers was one of the reasons behind adding SOCKS to the CERN httpd; another was simply not wanting to run the big lump of code that is an httpd on a firewall bastion system at _all_. Having SOCKS in the proxy httpd allows it to run on your _internal_ net; and SOCKS already has knowledge of which nets are directly reachable. I. -- Ian Dunkin -- From firewalls-owner Fri Apr 22 21:09:01 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA09077; Fri, 22 Apr 1994 21:09:01 GMT Received: from gatekeeper.Bridge.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA09071; Fri, 22 Apr 1994 14:08:52 -0700 Received: from localhost (mail@localhost) by gatekeeper.Bridge.COM (8.6.5/8.6.5) id QAA11825; Fri, 22 Apr 1994 16:08:02 -0500 Received: from racerx.bridge.com(167.76.24.6) by gatekeeper.Bridge.COM via smap (V1.0mjr) id sma011823; Fri Apr 22 16:08:01 1994 Received: from bert.bridge.com (ernie.bridge.com) by racerx.bridge.com with SMTP id AA03075 (5.67b/IDA-1.5); Fri, 22 Apr 1994 16:10:08 -0500 Date: Fri, 22 Apr 1994 16:10:08 -0500 From: Ken Hardy Message-Id: <199404222110.AA03075@racerx.bridge.com> To: firewalls@greatcircle.com Subject: Re: WWW, Wais and Gopher proxies Cc: imd1707@ggr.co.uk Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Fri, 22 Apr 1994, Ken Hardy wrote: > 2. We cannot seem to get to an internal HTTP server when using the > proxy on the firewall. It seems that the request should go to the > proxy which will resolve the hostname to the internal host and > forward the request there, handle the response, etc.; it shouldn't > differentiate between internal & external servers I erred! Perhaps it is the latest version of Mosaic (2.3) or a newer version of http that I put on the firewall while struggling with WAIS that makes the difference, but I tried using an internal server for the first time in some weeks today, and it worked flawlessly. Snooping on the ethernet shows the traffic bouncing off the firewall, as I expected it should. That leaves only WAIS, via Mosaic or otherwise, as something that I don't have working. -KH From firewalls-owner Fri Apr 22 21:17:47 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA09147; Fri, 22 Apr 1994 21:17:47 GMT Received: from tadpole by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA09141; Fri, 22 Apr 1994 14:17:39 -0700 Received: from chiba.tadpole.com by tadpole (4.1/SMI-4.1-jim) id AA21426; Fri, 22 Apr 94 16:17:05 CDT Received: by chiba.tadpole.com (5.0/SMI-SVR4) id AA08709; Fri, 22 Apr 1994 16:17:39 +0600 Date: Fri, 22 Apr 1994 16:17:39 +0600 From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9404222117.AA08709@chiba.tadpole.com> To: nkochar@apnetadmin.gta.doc.ca Subject: Re: Course on Innernet Security isues. Cc: firewalls@greatcircle.com Content-Length: 91 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Rob Kolstad and someone whom I can't remember are teaching one at Usenix in Boston. Jim From firewalls-owner Fri Apr 22 22:45:28 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA09493; Fri, 22 Apr 1994 22:45:28 GMT Received: from freenet3.scri.fsu.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA09487; Fri, 22 Apr 1994 15:45:16 -0700 Received: by freenet3.scri.fsu.edu; id AA01715; Fri, 22 Apr 1994 18:35:46 -0400 From: Butch Kay Message-Id: <9404222235.AA01715@freenet3.scri.fsu.edu> Subject: Info To: Firewalls@greatcircle.com Date: Fri, 22 Apr 94 18:35:46 18000 X-Mailer: ELM [version 2.3.1 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk INDex filelist_firewalls -- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@ @@ @@ Dr. Forest E. "Butch" Kay Jr.@@ @@ KESTREL International Ltd. @@ @@ @@ @@ In the land of the rising @@ @@ @@ @@ "SUN" @@ @@ @@ @@ I can be reached at: @@ @@ @@ @@ bkay53@freenet.fsu.edu @@ @@ or @@ @@ 71732.1472@Compuserve.com @@ @@ @@ @@ "SAYONARA" @@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ From firewalls-owner Sat Apr 23 18:07:06 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA13021; Sat, 23 Apr 1994 18:07:06 GMT Received: from frege.math.ethz.ch by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA13015; Sat, 23 Apr 1994 11:06:57 -0700 From: saouli@math.ethz.ch Received: from panoramix.ethz.ch (panoramix.ethz.ch [129.132.104.35]) by frege.math.ethz.ch (8.6.4/Main-mathdept-mailer) with ESMTP id UAA03252 for ; Sat, 23 Apr 1994 20:03:59 +0200 Received: (saouli@localhost) by panoramix.ethz.ch (8.6.7/D-MATH-client) id UAA12842 for firewalls@greatcircle.com; Sat, 23 Apr 1994 20:07:20 +0200 Message-Id: <199404231807.UAA12842@panoramix.ethz.ch> Subject: Re: IRC (fwd) To: firewalls@greatcircle.com Date: Sat, 23 Apr 1994 20:07:20 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=LATIN-1 Content-Transfer-Encoding: 8bit Content-Length: 2467 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Forwarded message: From saouli Fri Apr 22 15:13:59 1994 Subject: Re: IRC To: farsight@clark.net Date: Fri, 22 Apr 1994 15:13:59 +0200 (MET DST) In-Reply-To: from "farsight@clark.net" at Apr 22, 94 01:06:17 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=LATIN-1 Content-Transfer-Encoding: 8bit Content-Length: 1805 Hello, I would like to comment a bit about irc, since more of the personns that up to now did comment on that have a very scares view of what Internet Relayed Chat (and not Internet Remote Chat). The system has been first written in 1988, and still used in its basics the same way as 8 years ago. No fundamental changes have been brought. A good rethinking wouldn't be bad at especially since we now have around 5000 users at peek time. The client systems that are proposed do not all support the DCC features, the irc client doesn't the emacs clients do not, the perl clients do partially implement such features. I do not see the point to be worried about young users using add-on scripts they don't even know something about. I think that most of the "lusers" do use scripts that they don't understand and they don't even read. And I wonder if everyone goes onto each piece of code he is compiling to see if there is no hiden troyan. It is for sure something open lacking of security mechanism, but it is certainly not the biggest danger. And if you really want to be sure that your users don't fool around too much on the internet then simply setup a gateway-leaf server that would only enable your local client to be connected to it. And as for everything IRC is depending on the quality of the material the users do provide...(maybe it is a question of education afterall????) Regards, K. Saouli PS: === I know this is a bit of the mean stream of the firewall issue but I guess it has something to do with networks and security. -- Karim Saouli Math Department of the System administrator Swiss Fed. Inst. of Tech (ETHZ) Room: HG G 14.2 S-Mail: HG G 14.2 Email: saouli@math.ethz.ch ETH Zentrum Phone: ++41-1-632-2230 CH-8092 Zurich FAX : ++41-1-252-3401 -- Karim Saouli Math Department of the System administrator Swiss Fed. Inst. of Tech (ETHZ) Room: HG G 14.2 S-Mail: HG G 14.2 Email: saouli@math.ethz.ch ETH Zentrum Phone: ++41-1-632-2230 CH-8092 Zurich FAX : ++41-1-252-3401 From firewalls-owner Sun Apr 24 18:49:19 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA17167; Sun, 24 Apr 1994 18:49:19 GMT Received: from bos1g.delphi.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA17161; Sun, 24 Apr 1994 11:49:10 -0700 From: BMITTLEMAN@delphi.com Received: from delphi.com by delphi.com (PMDF V4.2-14 #6563) id <01HBK26PF2LC9TE4VZ@delphi.com>; Sun, 24 Apr 1994 14:48:27 EDT Date: Sun, 24 Apr 1994 14:48:27 -0400 (EDT) Subject: Mosaic, finger and others through a firewall. To: firewalls-digest@greatcircle.com Message-id: <01HBK26PFC8I9TE4VZ@delphi.com> X-VMS-To: INTERNET"firewalls-digest@greatcircle.com" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello, I'm a network user at my company. I basically IP'd all of the machines in our department, as the computreer dept. people are very slow to respond. My company has a firewall installed which will allow outgoing telnet, and FTP (through a port). I was wondering if there was a way to use Mosaic and access Gopher and WWW servers through this firewall (without having to ask the computer dept. for assistance.). Can I telnet to a srervice which would provide the necessary WWW and Gopher servers to work with Mosaic? What about fingering? Thanks for the assistance, Bruce From firewalls-owner Sun Apr 24 14:10:13 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA17534; Sun, 24 Apr 1994 20:56:54 GMT Received: from ibeam.intel.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA17528; Sun, 24 Apr 1994 13:56:48 -0700 Received: from [137.102.207.13] by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0pvBBW-0003V2C; Sun, 24 Apr 94 13:53 PDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Apr 1994 13:57:15 -0800 To: Ian Dunkin , Ken Hardy From: altis@ibeam.intel.com (Kevin Altis) Subject: Re: WWW, Wais and Gopher proxies Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 9:23 PM 4/22/94 +0100, Ian Dunkin wrote: >The CERN WWW people have been talking (www-talk list) about a mechanism to >allow the proxy redirections on the client to differentiate between those >to directly accessible nets and those which must be proxied; but this is >not there yet. The latest CERN libWWW supports a proxy exception list so that Web clients can differentiate between hosts outside and inside the firewall. This is not a full SOCKS exception list with subnet masks. As an example: setenv no_proxy "cern.ch, foo.bar:8001, ncsa.uiuc.edu" This is a simple solution. If this is is good enough for your needs, you should make a request to your favorite client team to support it, it comes for free with libWWW. ka From firewalls-owner Sun Apr 24 14:20:11 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA17542; Sun, 24 Apr 1994 20:58:04 GMT Received: from ibeam.intel.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA17536; Sun, 24 Apr 1994 13:57:50 -0700 Received: from [137.102.207.13] by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0pvBBM-0003V1C; Sun, 24 Apr 94 13:53 PDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Apr 1994 13:57:05 -0800 To: Ken Hardy , gaulse@ttown.apci.com From: altis@ibeam.intel.com (Kevin Altis) Subject: Re: WWW, Wais and Gopher proxies Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 11:13 AM 4/22/94 -0500, Ken Hardy wrote: >The CERN httpd server will serve as a proxy for WWW, Gopher, FTP, NNTP, >and, reportedly, WAIS when those services are used from the latest >versions of Mosaic, which can be made to understand the proxy by the >addition of some environment variables or resource entries. It seems >to work very well, except for these two problems: > >1. It does _not_ want to proxy WAIS for us. Mosaic sends the request > to the proxy, and then it says "...could not be accessed...". I'd > appreciate communications from anyone who has WAIS working, > preferably through Mosaic, but I'd settle for any sort of > connectivity. Direct WAIS support (access to a WAIS database via a WAIS URL) continues to be broken in the cern_httpd. Hopefully, this will be fixed in the next release. This hasn't been a great problem though, since most WAIS servers are accessed via HTTP and Gopher gateways, not directly from a client via the WAIS protocol. Last time I checked, only Mosaic for X and Lynx supported direct WAIS URLs. ka From firewalls-owner Mon Apr 25 03:02:41 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA19115; Mon, 25 Apr 1994 03:02:41 GMT Received: from george.arc.nasa.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA19109; Sun, 24 Apr 1994 20:02:34 -0700 Received: from localhost.arc.nasa.gov by george.arc.nasa.gov (8.6.8/1.35) id UAA27951; Sun, 24 Apr 1994 20:02:57 -0700 Message-Id: <199404250302.UAA27951@george.arc.nasa.gov> To: firewalls@greatcircle.com Subject: Problem porting firewall toolkit to HP-UX 9.01 Date: Sun, 24 Apr 1994 20:02:56 -0700 From: "Rob Tanner" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk When attempting to execute the makefile in /fwtk/auth, make comes up with the following error: /bin/ld: Unsatisfied symbols: dbm_open (code) dbm_fetch (code) dbm_delete (code) dbm_close (code) dbm_store (code) dbm_firstkey (code) dbm_nextkey (code) *** Error code 1 Anybody know what's going on? Thanks, -- Rob _ _ _ _ _ _ _ _ _ _ /\_\_\_\_\ /\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ Robert J. Tanner /\/_/__\/_/ __ /\/_/ /\/_/ Ames Research Center /\/_/_/_/_/ /\_\ /\/_/ /\/_/ (415) 604-3451 (SETI) /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (415) 604-5347 (Kuiper) \/_/ \/_/ \/_/_/_/_/ \/_/ tanner@george.arc.nasa.gov ____________________________________________________________________ From firewalls-owner Sun Apr 24 21:20:13 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA19482; Mon, 25 Apr 1994 04:15:30 GMT Received: from databus.databus.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA19470; Sun, 24 Apr 1994 21:15:20 -0700 Date: Mon, 25 Apr 94 00:18 EDT Message-ID: <9404250018.AA27799@databus.databus.com> From: Barney Wolff To: firewalls@GreatCircle.COM Cc: tanner@george.arc.nasa.gov Subject: Re: Problem porting firewall toolkit to HP-UX 9.01 Content-Length: 852 Content-Type: text Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Date: Sun, 24 Apr 1994 20:02:56 -0700 > From: george.arc.nasa.gov!tanner ("Rob Tanner") > > /bin/ld: Unsatisfied symbols: > dbm_open (code) > ... Looks like the BSD dbm library. Look on Archie under ndbm. I know it's available on ftp.uu.net in the BSD library sources. Perhaps better, use GNU's dbm library, which should be equivalent. The difference, as I recall, is that the BSD version produces database files with gigantic holes, which makes life difficult for backup via tar or cpio. Either one should compile under hp-ux without too much heartache. Barney Wolff, Pres. Voice: 914-591-6572 Databus Inc. Fax: 914-591-5677 15 Victor Drive Internet: barney@databus.com Irvington, NY 10533-1919 USA "At the corner of database & datacomm" From firewalls-owner Mon Apr 25 05:43:48 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA19773; Mon, 25 Apr 1994 05:43:48 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA19767; Sun, 24 Apr 1994 22:43:40 -0700 Message-Id: <199404250543.WAA19767@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (1.37.109.8/16.2) id AA27833; Mon, 25 Apr 1994 15:44:14 +1000 From: Darren Reed Subject: Bastion Host configuration. To: firewalls@greatcircle.com Date: Mon, 25 Apr 1994 15:44:12 +1000 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 801 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Much has been said about what should and shouldn't run on bastion hosts, and that they shouldn't be trusted by anyone, so, how plausible is it to remove the setuid and setgid bits on _every_ executeable/directory/normal file on one ? Will local mail fail (/bin/mail needs setuid-root) ? This would make it very inconvienient for people wanting to do "w" or "ps" or similar, but IMO, the only people who should have a shell and be wanting to do that type of activity are those who are root on that machine anyway. Does anyone use this in practice or tried it ? If this can be done, then it solves a high % of security problems on that host and greatly reduces options available to those who have broken into it from the inside/outside - agreed ? (rlogin/rsh would be useless here too :-) Darren From firewalls-owner Mon Apr 25 12:48:56 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA22249; Mon, 25 Apr 1994 12:48:56 GMT Received: from p-o.ans.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA22243; Mon, 25 Apr 1994 05:48:50 -0700 Received: by p-o.ans.net id AA14587 (5.65c/IDA-1.4.4 for Firewalls mailing list ); Mon, 25 Apr 1994 08:34:53 -0400 Message-Id: <199404251234.AA14587@p-o.ans.net> Date: Mon, 25 Apr 94 08:34:47 EST From: "Andrew T. Robinson" To: Firewalls mailing list Subject: Cost of firewall hosts; BSDI Unix Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk What are some typical hosts used for firewall/bastion hosts, and what is their ultimate cost including all necessary hardware and software? I'm assuming a UNIX system with 32Mb RAM and >1Gb of disk space (these numbers are gleaned from _Firewalls and Internet Security_ by Cheswick/Bellovin). I'm particularly interested in the cost of systems which support the TIS toolkit without porting. Also, what is the status of BSDI Unix? In the most recent UNIX REVIEW there is an article titled "Farewell to Berkeley UNIX." Does this mean BSDI will no longer be offered/supported (in a cursory scan of the article I didn't see BSDI explicitly mentioned anywhere)? I was hoping to implement a TIS toolkit-based firewall using BSDI and a 486 box (the cost of which I know), but if BSDI will no longer be available this option will be a lot less attractive. Andy From firewalls-owner Mon Apr 25 13:09:51 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA22392; Mon, 25 Apr 1994 13:09:51 GMT Received: from chulkn.chula.ac.th by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA22386; Mon, 25 Apr 1994 06:09:43 -0700 Received: by chulkn.chula.ac.th (Smail3.1.28.1 #12) id m0pvQNr-0003I1C; Mon, 25 Apr 94 20:07 BKK Date: Mon, 25 Apr 1994 20:07:34 +0700 (BKK) From: Solos Arthachinda - Undergrad student of Engineer To: Firewalls@GreatCircle.Com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Subscript firewalls From firewalls-owner Mon Apr 25 14:11:01 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA22973; Mon, 25 Apr 1994 14:11:01 GMT Received: from DUKEMC.MC.DUKE.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA22963; Mon, 25 Apr 1994 07:10:53 -0700 Received: from orion (orion.mc.duke.edu) by mc.duke.edu (PMDF V4.2-15 #5528) id <01HBL73JU6HS005B33@mc.duke.edu>; Mon, 25 Apr 1994 10:15:17 EDT Received: from ipl.orion.mc.duke.edu by orion (4.1/SMI-4.1) id AA18800; Mon, 25 Apr 94 10:10:29 EDT Date: Mon, 25 Apr 1994 10:06:36 -0400 (EDT) From: ajl@Orion.MC.Duke.EDU (Arne J. Ludwig) Subject: Re: Cost of firewall hosts; BSDI Unix In-reply-to: <199404251234.AA14587@p-o.ans.net> from "Andrew T. Robinson" at Apr 25, 94 08:34:47 am To: atr@maine.net (Andrew T. Robinson) Cc: firewalls@GreatCircle.COM Message-id: <9404251410.AA18800@orion> X-Mailer: ELM [version 2.4 PL21] Content-type: text Content-transfer-encoding: 7BIT Content-Length: 205 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Also, what is the status of BSDI Unix? Although BSD in general will no longer be supported by the University of California, BSD/386 definitely is and will be supported by BSDI, a commercial firm. Arne From firewalls-owner Mon Apr 25 14:38:52 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA23215; Mon, 25 Apr 1994 14:38:52 GMT Received: from nacm.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA23209; Mon, 25 Apr 1994 07:38:41 -0700 Received: from sun1.nicholas_applegate (sun1.nacm.com) by nacm.com with SMTP id AA04988 (5.65c/IDA-1.4.4 for ); Mon, 25 Apr 1994 07:39:01 -0700 Received: from sunlite.nicholas_applegate by sun1.nicholas_applegate (4.1/SMI-4.1) id AA08760; Mon, 25 Apr 94 10:38:59 EDT Received: by sunlite.nicholas_applegate (4.1/SMI-4.1) id AA09304; Mon, 25 Apr 94 10:38:58 EDT Date: Mon, 25 Apr 1994 10:37:15 -0400 (EDT) From: Barry Lustig Subject: Re: Cost of firewall hosts; BSDI Unix To: Firewalls mailing list In-Reply-To: <199404251234.AA14587@p-o.ans.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk BSDI's BSD/386 is alive and well. As a matter of fact, I am just about to buy a copy to use on a Bastion machine. You can reach them at 1-800-800-4BSD or try WWW to www.bsdi.com. barry From firewalls-owner Mon Apr 25 07:40:21 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA23110; Mon, 25 Apr 1994 14:18:22 GMT Received: from gatekeeper.Bridge.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA23104; Mon, 25 Apr 1994 07:18:08 -0700 Received: from localhost (mail@localhost) by gatekeeper.Bridge.COM (8.6.5/8.6.5) id JAA14145; Mon, 25 Apr 1994 09:17:03 -0500 Received: from racerx.bridge.com(167.76.24.6) by gatekeeper.Bridge.COM via smap (V1.0mjr) id sma014143; Mon Apr 25 09:16:34 1994 Received: from bert.bridge.com (ernie.bridge.com) by racerx.bridge.com with SMTP id AA02292 (5.67b/IDA-1.5); Mon, 25 Apr 1994 09:19:01 -0500 Date: Mon, 25 Apr 1994 09:19:01 -0500 From: Ken Hardy Message-Id: <199404251419.AA02292@racerx.bridge.com> To: atr@maine.net Subject: Re: Cost of firewall hosts; BSDI Unix Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Also, what is the status of BSDI Unix? In the most recent UNIX REVIEW there is >an article titled "Farewell to Berkeley UNIX." Does this mean BSDI will no That article is simply about Berkeley, the University, shutting down its Unix development group. BSDI is an independent company producing a commercial version of BSD Unix for x86 platforms. Berkeley's action does not affect them, or any of the other Unix-on-x86 efforts. Of course, it affects the future direction/source of their R&D. We are using BSDI on our firewall. A runtime-only license is something like $250, or with full source for ~$1000. They recently released version 1.1, and it seems very stable. Circa 6 months ago, I queried this list for recommended OSes for x86-based firewalls, and BSDI came the most highly recommended. I have no complaints about it; it seems very stable in the configuration I am using and is doing everything that I ask of it. It's on a 66MHz Dell '486. If cost is a big issue, there seem to be multiple free Unixes available for x86 platforms. I've got Linux running on a 20MHz 386 as my Usenet News server, and it seems stable, as well as more efficient (faster) than BSDI. I'm told by some, though, that Linux is a little weak in networking, but it _should_ be fixed in version 1.1 due real soon if not already. The responses for firewall systems I received from this group were ambivalent about Linux; BSDI was recommended as true BSD, a known entity, vs. Linux which is an amalgam of BSD & System V, the security aspects of which have been less fully explored. That, at least, is what I gathered from the experts assembled here. I defer to them for clarification or correction. -KH From firewalls-owner Mon Apr 25 15:37:09 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA23651; Mon, 25 Apr 1994 15:37:09 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA23645; Mon, 25 Apr 1994 08:37:01 -0700 Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA22534; Mon, 25 Apr 94 11:33:28 -0400 Received: by cobalt.house.gov (AA00224); Mon, 25 Apr 94 11:33:43 -0700 Date: Mon, 25 Apr 94 11:33:43 -0700 From: Dorian Deane Message-Id: <9404251833.AA00224@cobalt.house.gov> To: atr@maine.net, firewalls@GreatCircle.COM Subject: Re: Cost of firewall hosts; BSDI Unix Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > What are some typical hosts used for firewall/bastion hosts, and what is their > ultimate cost including all necessary hardware and software? I'm assuming a > UNIX system with 32Mb RAM and >1Gb of disk space (these numbers are gleaned from > _Firewalls and Internet Security_ by Cheswick/Bellovin). I'm particularly > interested in the cost of systems which support the TIS toolkit without porting. > Why the >1Gb? Mail spool? > Also, what is the status of BSDI Unix? In the most recent UNIX REVIEW there is > an article titled "Farewell to Berkeley UNIX." Does this mean BSDI will no > longer be offered/supported (in a cursory scan of the article I didn't see BSDI > explicitly mentioned anywhere)? I was hoping to implement a TIS toolkit-based > firewall using BSDI and a 486 box (the cost of which I know), but if BSDI will > no longer be available this option will be a lot less attractive. > I'm fairly sure BSDI is not going away. The BSD group at UCB has stopped research on BSD Unix, but the existing flavors, such as BSDI's version of 386BSD, NETBSD, etc. have taken on a life of their own. If I recall the gist of that article you mention, they were only referring to UCB's research group. Personally, I would have no hesitations buying BSDI, but if it were all left to me (it isn't), I'd probably use 386BSD or NETBSD simply because they're free and BSDI isn't. Yes, I may have to deal with more rough edges that BSDI has already smoothed over, but I'm prepared to deal with that. dorian dorian@cobalt.house.gov From firewalls-owner Mon Apr 25 16:26:04 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA23957; Mon, 25 Apr 1994 16:26:04 GMT Received: from uai.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA23935; Mon, 25 Apr 1994 09:25:34 -0700 Received: from sgi.uai.com by uai.com with SMTP id AA15998 (5.65c/IDA-1.4.4 for ); Mon, 25 Apr 1994 08:38:53 -0700 Received: by sgi.uai.com id ; Mon, 25 Apr 94 08:38:02 -0700 Message-Id: <9404251538.AA25935@sgi.uai.com> To: Darren Reed Cc: firewalls@greatcircle.com Subject: Re: Bastion Host configuration. In-Reply-To: <199404250543.WAA19767@mycroft.GreatCircle.COM> from "Darren Reed" on Mon, 25 Apr 1994 15:44:12 +1000. X-Mailer: MH [Version 6.8] Date: Mon, 25 Apr 1994 08:37:59 -0700 From: "Mark R. Ludwig" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> "Darren" == Darren Reed writes: Darren> Much has been said about what should and shouldn't run on bastion Darren> hosts, and that they shouldn't be trusted by anyone, so, how Darren> plausible is it to remove the setuid and setgid bits on _every_ Darren> executeable/directory/normal file on one ? Will local mail fail Darren> (/bin/mail needs setuid-root) ? Don't remove setUID on /bin/login, for example. Could someone with more detailed information explain why this is, though? In the "classic" configuration, init launches getty which then launches login. I'm looking at SunOS, one of the few platforms we have around here which doesn't use XDM, and I see getty on the console running as root. When it launches login, it's still going to be root, even if login isn't setUID. In the rlogin environment, in.rlogind runs as root, so when it launches login, it's still root. Similarly for telnet, wherein in.telnetd runs as root. So why does login need setUID? I'm not interested in trying it, I'm just curious to understand.$$ -- INET: Mark-Ludwig@UAI.COM NIC: ML255 ICBM: USA; Lower Left Coast "Cigarettes ... are not a drug." -- Tom Lorea from the Tobacco Institute From firewalls-owner Mon Apr 25 16:55:08 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA24147; Mon, 25 Apr 1994 16:55:08 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA24139; Mon, 25 Apr 1994 09:54:59 -0700 Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id JAA13804; Mon, 25 Apr 1994 09:55:21 -0700 Message-Id: <199404251655.JAA13804@mailgate.cadence.com> Received: from mac32_223.cadence.com(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id smaa13677; Mon Apr 25 09:54:10 1994 Date: Mon, 25 Apr 1994 09:54:10 -0800 To: firewalls@GreatCircle.COM, saouli@math.ethz.ch From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: IRC (fwd) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 8:07 PM 4/23/94 +0200, saouli@math.ethz.ch wrote: >I would like to comment a bit about irc, since more of the personns >that up to now did comment on that have a very scares view of what Internet >Relayed Chat (and not Internet Remote Chat). > >The system has been first written in 1988, and still used in its basics the >same >way as 8 years ago. No fundamental changes have been brought. > >A good rethinking wouldn't be bad at especially since we now have around 5000 >users at peek time. > >The client systems that are proposed do not all support the DCC features, >the irc client doesn't the emacs clients do not, the perl clients do partially >implement such features. > >I do not see the point to be worried about young users using add-on scripts >they >don't even know something about. I think that most of the "lusers" do use >scripts that they don't understand and they don't even read. And I wonder >if everyone goes onto each piece of code he is compiling to see if there is >no hiden troyan. > >It is for sure something open lacking of security mechanism, but it is >certainly >not the biggest danger. And if you really want to be sure that your users don't >fool around too much on the internet then simply setup a gateway-leaf >server that would only enable your local client to be connected to it. > >And as for everything IRC is depending on the quality of the material the users >do provide...(maybe it is a question of education afterall????) > The activity was at our New Delhi, India office, and they were watching real-time commentary of the India-Pakistan cricket test match. I had been tolerating the previous occasional use of IRC as there was only one user and the pattern was consistent. This incident made its use more widespread and inbound IP connections to high port numbers can't be distinguished from people setting up telnet daemons on high port numbers. Many thanks to the person who suggested zapping ports 6667 and 194, it seems to have done the trick. I'm not so worried about our users fooling around on the Internet, I'm worried about the Internet fooling around with our users. Al --------------------------------------------------------------------------- Alastair Young _ 2 Ariel NH Red Hunters Cadence Design Systems, Information Services )/___ _ 555 River Oaks Parkway, 4B1 __/(___)_*##/c 56 Red Menace San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ alastair@cadence.com (408)428-5278 \__/ ----'\__/ 49 TwinportKit --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From firewalls-owner Mon Apr 25 17:05:18 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA24252; Mon, 25 Apr 1994 17:05:18 GMT Received: from tamarin.bath.ac.uk by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA24246; Mon, 25 Apr 1994 10:05:03 -0700 Received: from ss1.bath.ac.uk by tamarin.bath.ac.uk with SMTP (PP) id <17169-0@tamarin.bath.ac.uk>; Mon, 25 Apr 1994 18:05:18 +0100 To: "Mark R. Ludwig" cc: firewalls@greatcircle.com Subject: Re: Bastion Host configuration. In-reply-to: Your message of "Mon, 25 Apr 1994 08:37:59 PDT." <9404251538.AA25935@sgi.uai.com> Date: Mon, 25 Apr 1994 18:05:07 +0100 From: Icarus Sparry Message-ID: <9404251805.aa23741@uk.ac.bath.ss1> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: "Mark R. Ludwig" >Don't remove setUID on /bin/login, for example. The only reason for keeping the setUID bit on /bin/login is to enable people to say 'login fred', instead of 'exit' followed by logging in as fred. A very silly idea IM(NS)HO! It means extra code in /bin/sh, /bin/csh etc to make login a builtin command which will exec /bin/login, rather than fork and exec it as it would any other command. Real Unix (i.e. 10th Edition) has abandoned the setUID bit on this command. We (Bath University) have run without the setUID bit on /bin/login for a number of years. I suggest that you remove the setUID bit, and update your manual pages to remove the reference to 'login' as being a builtin command. From firewalls-owner Mon Apr 25 17:08:24 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA24275; Mon, 25 Apr 1994 17:08:24 GMT Received: from mail.fwi.uva.nl by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA24269; Mon, 25 Apr 1994 10:08:07 -0700 Received: from adam.fwi.uva.nl by mail.fwi.uva.nl with SMTP (5.65c/5.1) id AA17039; Mon, 25 Apr 1994 19:08:18 +0200 Received: by adam.fwi.uva.nl from localhost.fwi.uva.nl with SMTP (5.65c/2.0) id AA28143; Mon, 25 Apr 1994 19:08:05 +0200 Message-Id: <199404251708.AA28143@adam.fwi.uva.nl> X-Organisation: Faculty of Mathematics & Computer Science University of Amsterdam Kruislaan 403 NL-1098 SJ Amsterdam The Netherlands X-Phone: +31 20 525 7463 X-Telex: 10262 hef nl X-Fax: +31 20 525 7490 To: "Mark R. Ludwig" Cc: Darren Reed , firewalls@GreatCircle.COM Subject: Re: Bastion Host configuration. In-Reply-To: Your message of "Mon, 25 Apr 94 08:37:59 PDT." <9404251538.AA25935@sgi.uai.com> Date: Mon, 25 Apr 94 19:08:04 +0200 From: Casper Dik Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>>> "Darren" == Darren Reed writes: >Could someone with more detailed information explain why this is, >though? In the "classic" configuration, init launches getty which >then launches login. I'm looking at SunOS, one of the few platforms >we have around here which doesn't use XDM, and I see getty on the >console running as root. When it launches login, it's still going to >be root, even if login isn't setUID. In the rlogin environment, >in.rlogind runs as root, so when it launches login, it's still root. >Similarly for telnet, wherein in.telnetd runs as root. So why does >login need setUID? We've run /bin/login with set-uid bit on SunOS 4.1.x and Solaris for years. There's only one caveat: when people logout by typing `login'', login will typically happily start a new session for an unsuspecting new user w/o checking whether setuid(uid) returns 0 or not. So you need to change /bin/login in such a way that it will exit when not run as root or that it cannot be execute by non-root users. (Which is a tad difficult if you use NFS'ed /usr partitions) Casper From firewalls-owner Mon Apr 25 17:11:25 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA24312; Mon, 25 Apr 1994 17:11:25 GMT Received: from gateway.morgan.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA24306; Mon, 25 Apr 1994 10:11:11 -0700 Received: from bkadm1.morgan.com ([138.20.76.11]) by gateway.morgan.com with SMTP id <41866>; Mon, 25 Apr 1994 13:11:16 -0400 Received: from bkis101.morgan.com by bkadm1.morgan.com (5.65c/IDA-sendmail/cf.hub v1.24) id AA09942; Mon, 25 Apr 1994 13:10:58 -0400 Received: by bkis101.morgan.com (5.65c/IDA-sendmail/cf.host v1.23) id AA05210; Mon, 25 Apr 1994 13:10:42 -0400 Date: Mon, 25 Apr 1994 13:10:42 -0400 From: vt@morgan.com (W.Vaughan Turner III) Message-Id: <199404251710.AA05210@bkis101.morgan.com> To: Mark-Ludwig@uai.com, avalon@coombs.anu.edu.au Subject: Re: Bastion Host configuration. Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> "Mark" == Mark R. Ludwig writes: Mark) To: Darren Reed Mark) Cc: firewalls@GreatCircle.COM Mark) Subject: Re: Bastion Host configuration. Mark) Date: Mon, 25 Apr 1994 11:37:59 -0400 Mark) From: "Mark R. Ludwig" Mark) Sender: Firewalls-Owner@GreatCircle.COM Mark) Mark) >>>>> "Darren" == Darren Reed writes: Darren> Much has been said about what should and shouldn't run on bastion Darren> hosts, and that they shouldn't be trusted by anyone, so, how Darren> plausible is it to remove the setuid and setgid bits on _every_ Darren> executeable/directory/normal file on one ? Will local mail fail Darren> (/bin/mail needs setuid-root) ? Mark) Don't remove setUID on /bin/login, for example. Mark) Mark) Could someone with more detailed information explain why this is, Mark) though? In the "classic" configuration, init launches getty which Mark) then launches login. I'm looking at SunOS, one of the few platforms Mark) we have around here which doesn't use XDM, and I see getty on the Mark) console running as root. When it launches login, it's still going to Mark) be root, even if login isn't setUID. In the rlogin environment, Mark) in.rlogind runs as root, so when it launches login, it's still root. Mark) Similarly for telnet, wherein in.telnetd runs as root. So why does Mark) login need setUID? I don't think it does. In a fit of sheer frustration, I hacked this on a student unix system running Ultrix 3.2 over a year ago. If anyone's curious, our wtmp/utmp information would get very confused when users switched logins with the login program. For auditing purposes, we needed to know who was on the machine, so this was unacceptable. I looked at it briefly, changed it to non-setuid, went to take an exam, and waited for people to complain (ah, the luxuries of a volunteer student domain... :). It's still set up that way, and I never heard any complaints about it breaking functionality. Mark) I'm not interested in trying it, I'm just curious to understand.$$ Me too. What did I break? :) Vaughan ---- Vaughan Turner vt@ms.com Morgan Stanley & Co. Inc. From firewalls-owner Mon Apr 25 18:12:50 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA25166; Mon, 25 Apr 1994 18:12:50 GMT Received: from tamarin.bath.ac.uk by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA25160; Mon, 25 Apr 1994 11:12:42 -0700 Received: from ss1.bath.ac.uk by tamarin.bath.ac.uk with SMTP (PP) id <19294-0@tamarin.bath.ac.uk>; Mon, 25 Apr 1994 19:12:40 +0100 To: H Morrow Long cc: "Mark R. Ludwig" , firewalls@greatcircle.com Subject: Re: Bastion Host configuration. In-reply-to: Your message of "Mon, 25 Apr 1994 14:06:08 EDT." <199404251806.AA16144@SPARKY.CF.CS.YALE.EDU> Date: Mon, 25 Apr 1994 19:12:40 +0100 From: Icarus Sparry Message-ID: <9404251912.aa27617@uk.ac.bath.ss1> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Doesn't /bin/login write entries (records of logins) into the >/etc/utmp and /var/adm/wtmp files? Yes. >If you remove the setuid bit from /bin/login, this means that you >will have to make the utmp and wtmp files writable by all - >if you want to records who logs in - right? No. At the time that /bin/login is run, either by init via getty, or via telnetd/rlogind via inetd, it is running as root. This was pointed out in the original post which started this discusssion. >Having /etc/utmp and /var/adm/wtmp writable by the world introduces >its own set of security concerns. Indeed. From firewalls-owner Mon Apr 25 11:20:20 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA25099; Mon, 25 Apr 1994 18:06:30 GMT Received: from ALABAMA.CF.CS.YALE.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA25093; Mon, 25 Apr 1994 11:06:13 -0700 Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Mon, 25 Apr 1994 14:06:12 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.67b/res.client.cf-3.7) id AA16144; Mon, 25 Apr 1994 14:06:11 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199404251806.AA16144@SPARKY.CF.CS.YALE.EDU> To: Icarus Sparry Cc: "Mark R. Ludwig" , firewalls@GreatCircle.COM Subject: Re: Bastion Host configuration. In-Reply-To: Your message of Mon, 25 Apr 94 18:05:07 BST. Date: Mon, 25 Apr 94 14:06:08 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9404251805.aa23741@uk.ac.bath.ss1> you write: >>From: "Mark R. Ludwig" >>Don't remove setUID on /bin/login, for example. > >The only reason for keeping the setUID bit on /bin/login is to >enable people to say 'login fred', instead of 'exit' followed by >logging in as fred. > >A very silly idea IM(NS)HO! It means extra code in /bin/sh, /bin/csh >etc to make login a builtin command which will exec /bin/login, >rather than fork and exec it as it would any other command. > >Real Unix (i.e. 10th Edition) has abandoned the setUID bit on this >command. We (Bath University) have run without the setUID bit on >/bin/login for a number of years. > >I suggest that you remove the setUID bit, and update your manual >pages to remove the reference to 'login' as being a builtin command. Doesn't /bin/login write entries (records of logins) into the /etc/utmp and /var/adm/wtmp files? If you remove the setuid bit from /bin/login, this means that you will have to make the utmp and wtmp files writable by all - if you want to records who logs in - right? Having /etc/utmp and /var/adm/wtmp writable by the world introduces its own set of security concerns. - Morrow From firewalls-owner Mon Apr 25 19:16:35 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA25618; Mon, 25 Apr 1994 19:16:35 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA25612; Mon, 25 Apr 1994 12:16:24 -0700 Message-Id: <199404251916.MAA25612@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (1.37.109.8/16.2) id AA06576; Tue, 26 Apr 1994 05:16:55 +1000 From: Darren Reed Subject: Re: Bastion Host configuration. To: firewalls@greatcircle.com Date: Tue, 26 Apr 1994 05:16:54 +1000 (EST) Cc: gh@crl.com In-Reply-To: <199404251617.AA29910@crl.crl.com> from "George Herbert CRL Support" at Apr 25, 94 09:17:43 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1856 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Ok, some programs that seem to be a problem: /bin/login /bin/su /bin/passwd Solutions ? chmod 700 /bin/login - only daemons running as root should execute login anyway, and doing it other ways should be discouraged. Remember, this is the bastion host, not an ordinary host giving user privs. chmod 700 /bin/su - put "console" in /etc/securettys and force any root activity to be done from console. Inconvienient for you and inconvienient for someone who might discover the root password. chmod 700 /bin/passwd - Well, firstly, use of skey or some other authentication scheme ir probably better in place here, as this is the host typically used by "in the field" people, logging back into work, for whatever reason. In other cases, well, how many would agree that "A well chosen password is bettern than having to change it regularly" ? Until you can crack crypt in an economical way. Also means people have to come and see you to change passwords..in a small operation, this would be not so bad and maybe positive and get your users to care more (hope!). Others ? Someone mentioned auditing users being a problem with them typing "login" again to relogin. An interesting feature of Pyramid's OSx 5.1 (not sure about their other products) is the concept of an "auth id", which no matter how many times you su, use setruid(), seteuid(), setuid(), can only be set once (through the traditional system call interface - not counting writing /dev/kmem but with this as an immutable file under 4.4, it could be interesting :). However, from what I can tell, this isn't used in process accounting logs anywhere. Do any of the other Unix variants support a similar feature in the kernel ? (Perhaps it is something a few more of them could add - even as a standard part!) Darren From firewalls-owner Mon Apr 25 19:18:11 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA25626; Mon, 25 Apr 1994 19:18:11 GMT Received: from bigbird.hri.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA25620; Mon, 25 Apr 1994 12:17:59 -0700 Received: from sysguy.hri.com by bigbird.hri.com (5.65+/1.0s) id AA15414; Mon, 25 Apr 94 15:18:16 -0400 From: rali@hri.com (Reto Lichtensteiger) Message-Id: <9404251918.AA15414@bigbird.hri.com> Subject: Re: Bastion Host configuration. To: long-morrow@CS.YALE.EDU (H Morrow Long) Date: Mon, 25 Apr 1994 15:18:32 -0400 (EDT) Cc: firewalls@greatcircle.com In-Reply-To: <199404251806.AA16144@SPARKY.CF.CS.YALE.EDU> from "H Morrow Long" at Apr 25, 94 02:06:08 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 731 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Doesn't /bin/login write entries (records of logins) into the > /etc/utmp and /var/adm/wtmp files? > > If you remove the setuid bit from /bin/login, this means that you > will have to make the utmp and wtmp files writable by all - > if you want to records who logs in - right? > > Having /etc/utmp and /var/adm/wtmp writable by the world introduces > its own set of security concerns. You could always set login sgid to some nice harmless group of it's own and make the utmp and wtmp files 664 that group ... -- R A Lichtensteiger System Administrator rali@hri.com Horizon Research Inc (617) 466-8304 Heard Recently (from a cc:Mail Administrator): "It's all in RFC822, whatever that is" From firewalls-owner Mon Apr 25 20:44:14 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA26343; Mon, 25 Apr 1994 20:44:14 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA26337; Mon, 25 Apr 1994 13:44:07 -0700 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA19121; Mon, 25 Apr 94 13:44:11 PDT Received: from future.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA14365; Mon, 25 Apr 94 13:43:19 PDT Received: from localhost by future.Eng.Sun.COM (5.x/SMI-SVR4) id AA07369; Mon, 25 Apr 1994 13:44:02 -0700 Message-Id: <9404252044.AA07369@future.Eng.Sun.COM> To: Icarus Sparry Cc: firewalls@GreatCircle.COM Subject: Re: Bastion Host configuration. In-Reply-To: Your message of "Mon, 25 Apr 94 19:12:40 BST." <9404251912.aa27617@uk.ac.bath.ss1> Date: Mon, 25 Apr 94 13:44:01 PDT From: Geoff Mulligan Content-Length: 617 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > >Doesn't /bin/login write entries (records of logins) into the > >/etc/utmp and /var/adm/wtmp files? > > Yes. > > >If you remove the setuid bit from /bin/login, this means that you > >will have to make the utmp and wtmp files writable by all - > >if you want to records who logs in - right? > > No. At the time that /bin/login is run, either by init via getty, or > via telnetd/rlogind via inetd, it is running as root. This was > pointed out in the original post which started this discusssion. > What if you as a user wants to relogin by just typing "login foo" - login then needs to be suid. geoff From firewalls-owner Mon Apr 25 23:40:35 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA27566; Mon, 25 Apr 1994 23:40:35 GMT Received: from ibeam.intel.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA27560; Mon, 25 Apr 1994 16:40:24 -0700 Received: from [134.134.208.67] by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0pvaF9-0003UqC; Mon, 25 Apr 94 16:39 PDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Apr 1994 16:42:36 -0800 To: firewalls@GreatCircle.COM From: altis@ibeam.intel.com (Kevin Altis) Subject: WWW proxy information Cc: luotonen@ptsun00.cern.ch (Ari Luotonen) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Many of you already know about the application level proxy design developed by Kevin Altis, Ari Luotonen, and Lou Montulli. However, there have been enough questions on this list lately that I thought I should shed some more light on the work. Since February, 1994, firewalls have been "safely permeable" for World Wide Web (WWW) clients via an application level proxy. Proxy support is built into popular Web clients such as Lynx and Mosaic and works across all operating systems, not just Unix. The hypertext server developed at CERN, cern_httpd, provides seamless external access to HTTP, Gopher, WAIS, and FTP. Thanks to standard proxy support in the clients, and the wide availability of the cern_httpd proxy server, anyone behind a firewall can now have full Web access through the firewall host with minimum effort and without compromising security. A paper on WWW Proxies will be presented at the first WWW conference in Geneva at the end of May. This is an open standard and as such we hope to publish an RFC and standardize a proxy port number through the Internet authority. Clients supporting the proxy: Lynx, X Mosaic, Win Mosaic, Mac Mosaic (unreleased), Emacs WWW browser, CERN line mode browser. This message was not intended as an ad, but I am soliciting direct feedback from you so that I can find out which clients support the proxy which I may have missed. I also want to find out which vendors are shipping proxies that are based on the application level proxy mechanism. These may be based on the cern_httpd, work as Common Gateway Interface (CGI) scripts, or something else entirely. At one time, I had gotten email from some of the firewall vendors indicating their support, but I haven't heard from any of them in a while. Finally, if you or your organization, corporation, etc. is using the application level proxy I would like to hear from you. Please email me directly and I'll summarize for the list in a few weeks. If you have concerns about application level proxies in general or our solution specifically, then please raise them on this list rather than emailing me directly so that we can all participate in the discussion. Thanks, ka --- Kevin Altis Ari Luotonen For more information, see: From firewalls-owner Mon Apr 25 21:10:28 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA28742; Tue, 26 Apr 1994 03:01:56 GMT Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA28736; Mon, 25 Apr 1994 20:01:44 -0700 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id TAA17191; Mon, 25 Apr 1994 19:46:09 -0700 Received: from avalle.insoft.com by insoft1.insoft.com (4.1/RHP-1.0) id AA25628; Mon, 25 Apr 94 18:43:45 EDT Received: by avalle.insoft.com (5.0/SMI-SVR4) id AA20188; Mon, 25 Apr 1994 18:39:45 +0500 Date: Mon, 25 Apr 1994 18:39:45 +0500 From: francis@avalle.insoft.com (John [Francis] Stracke) Message-Id: <9404252239.AA20188@avalle.insoft.com> To: firewalls@GreatCircle.COM In-Reply-To: Geoff Mulligan's message of Mon, 25 Apr 94 13:44:01 PDT <9404252044.AA07369@future.Eng.Sun.COM> Subject: Bastion Host configuration. Content-Length: 610 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >What if you as a user wants to relogin by just typing "login foo" - >login then needs to be suid. alias login "exec rlogin localhost -l" /===========================================================================\ |John (Francis) Stracke | My opinions are my own. | |InSoft, Inc. |==================================================| |Mechanicsburg, PA | "I said no camels! That's *five* camels! Can't | |francis@insoft.com | you count!" -- Indiana Jones & The Last Crusade | \===========================================================================/ From firewalls-owner Mon Apr 25 21:20:42 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA29085; Tue, 26 Apr 1994 03:24:36 GMT Received: from munnari.oz.au by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA29078; Mon, 25 Apr 1994 20:24:18 -0700 From: hduc@epa.gov.au Received: from airmoon.epa.gov.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25985; Tue, 26 Apr 1994 11:49:36 +1000 (from hduc@epa.gov.au) Received: by airmoon.epa.gov.au (4.1/SMI-4.1) id AA02034; Tue, 26 Apr 94 10:42:09 EST Date: Tue, 26 Apr 1994 10:31:49 +1000 (EST) Subject: Distributed Object security ? To: firewalls@greatcircle.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I run SunOS 4.1.3 on a Sparc machine connecting to the Internet. The other day, I noticed that a RPC service called rpc.ttdbserverd running on my system. I never use this before, so I disabled it and remove it from my inetd.conf file. This is a Sun Tooltalk database server for distributed object environment. Someone probably has initated the service without knowing it. I heard that the Distributed Object Environment and the new Common Object Request Broker Architecture (CORBA) is now adopted as a standard by a number of companies. Has security considered as an issue when they set up the standard ? Thanks, ************************************************************************* Dr Hiep Duc, Metropolitan Air Quality Study * hduc@epa.gov.au * Environment Protection Authority NSW (EPANSW)* ------------------------ * 66 Rickard Road * * Bankstown, NSW 2200 ph: (02) 7955205 * * ph: (02) 795 5454 Fax: (02) 7092836 * * ************************************************************************* From firewalls-owner Tue Apr 26 03:44:42 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA01622; Tue, 26 Apr 1994 09:41:28 GMT Received: from srv.cip.physik.tu-muenchen.de by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA01610; Tue, 26 Apr 1994 02:41:15 -0700 Received: from ss5.cip.physik.tu-muenchen.de by srv.cip.physik.tu-muenchen.de with SMTP id AA12780 for (5.67a/IDA-1.5/bs03); Tue, 26 Apr 1994 11:40:16 +0200 Message-Id: <199404260940.AA12780@srv.cip.physik.tu-muenchen.de> To: Geoff Mulligan Cc: Icarus Sparry , firewalls@greatcircle.com Subject: Re: Bastion Host configuration. In-Reply-To: Your message of "Mon, 25 Apr 94 13:44:01 PDT." <9404252044.AA07369@future.Eng.Sun.COM> Date: Tue, 26 Apr 94 11:40:16 +0200 From: Bernhard.Schneck@Physik.TU-Muenchen.DE Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9404252044.AA07369@future.Eng.Sun.COM> you write: > What if you as a user wants to relogin by just typing "login foo" - > login then needs to be suid. stty -hupcl logout From firewalls-owner Tue Apr 26 14:43:26 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA02969; Tue, 26 Apr 1994 14:43:26 GMT Received: from firstfloor.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA02963; Tue, 26 Apr 1994 07:43:17 -0700 Received: from thekid.firstfloor.COM ([198.206.195.7]) by firstfloor.COM (4.1/SMI-4.1) id AA03535; Tue, 26 Apr 94 07:44:02 PDT From: jjames@firstfloor.COM (John W. James - First Floor, Inc) To: hduc@epa.gov.au, firewalls@GreatCircle.COM Subject: RE: Distributed Object security ? Reply-To: jjames@firstfloor.COM Date: Tue, 26 Apr 94 07:42:48 PDT Message-Id: <9404261442.3079A8@thekid.firstfloor.COM> X-Mailer: SelectMAIL 1.1 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Actually, I don't think ToolTalk has much of anything to do with DOE, as they'll handle their own implementation in much different ways. ttdbserverd is used by the existing OpenWindows desktop to allow some interoperability between deskset apps and third party apps. It is used, for example, by mailtool to figure out which app should be used to launch an attachment to a mail message. (Sometimes you'll see references to the "classing engine" in conjunction with this.) The inetd.conf entry used to get put in place during OpenWindows installation, but it may actually be put in place during the OS load now on Solaris 2.X systems. The best I recall, just starting mailtool is enough to kick off the tooltalk daemon, as it wants to gather up all the classes the classing engine knows about in the beginning, probably to cache them. If you still run mailtool on this system, you will likely now see a significant lag time in mailtool's startup, as it won't move on until the obligatory 25 seconds of failing to get the daemon to reply have expired. As for CORBA having thought through security issues, this is a good topic, and one that should be pushed on by the community if it is not to their liking. Nothing in DOE has hit the released product stream as yet, so there would still be time to read over the specs and voice opinions before there are some legacy apps out there. When I was at Sun and looking at DOE, I was mainly concerned over the amount of test support that was in it, and I never looked at anything relating to security, though I think anything that was added for testing probably was a step backward for security. John --- Begin Included Message --- From POP3-Server@firstfloor Tue Apr 26 07:22:19 1994 Return-Path: Received: from relay1.UU.NET by firstfloor.COM (4.1/SMI-4.1) id AA10734; Mon, 25 Apr 94 21:56:05 PDT Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwngd20949; Tue, 26 Apr 94 00:53:25 -0400 Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA29085; Tue, 26 Apr 1994 03:24:36 GMT Received: from munnari.oz.au by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA29078; Mon, 25 Apr 1994 20:24:18 -0700 From: hduc@epa.gov.au Received: from airmoon.epa.gov.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25985; Tue, 26 Apr 1994 11:49:36 +1000 (from hduc@epa.gov.au) Received: by airmoon.epa.gov.au (4.1/SMI-4.1) id AA02034; Tue, 26 Apr 94 10:42:09 EST Date: Tue, 26 Apr 1994 10:31:49 +1000 (EST) Subject: Distributed Object security ? To: firewalls@GreatCircle.COM Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Content-Length: 1144 Status: Hi, I run SunOS 4.1.3 on a Sparc machine connecting to the Internet. The other day, I noticed that a RPC service called rpc.ttdbserverd running on my system. I never use this before, so I disabled it and remove it from my inetd.conf file. This is a Sun Tooltalk database server for distributed object environment. Someone probably has initated the service without knowing it. I heard that the Distributed Object Environment and the new Common Object Request Broker Architecture (CORBA) is now adopted as a standard by a number of companies. Has security considered as an issue when they set up the standard ? Thanks, ************************************************************************* Dr Hiep Duc, Metropolitan Air Quality Study * hduc@epa.gov.au * Environment Protection Authority NSW (EPANSW)* ------------------------ * 66 Rickard Road * * Bankstown, NSW 2200 ph: (02) 7955205 * * ph: (02) 795 5454 Fax: (02) 7092836 * * ************************************************************************* --- End Included Message --- From firewalls-owner Tue Apr 26 15:02:32 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA03134; Tue, 26 Apr 1994 15:02:32 GMT Received: from tadpole by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA03128; Tue, 26 Apr 1994 08:02:26 -0700 Received: from chiba.tadpole.com by tadpole (4.1/SMI-4.1-jim) id AA21102; Tue, 26 Apr 94 10:01:28 CDT Received: by chiba.tadpole.com (5.0/SMI-SVR4) id AA00832; Tue, 26 Apr 1994 10:02:03 +0600 Date: Tue, 26 Apr 1994 10:02:03 +0600 From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9404261502.AA00832@chiba.tadpole.com> To: firewalls@GreatCircle.COM, hduc@epa.gov.au, jjames@firstfloor.COM Subject: RE: Distributed Object security ? Content-Length: 125 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Has security considered as an issue when they set up the standard? Considered? Yes. Implimented? Remains to be seen. From firewalls-owner Tue Apr 26 08:30:33 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA03298; Tue, 26 Apr 1994 15:24:02 GMT Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA03292; Tue, 26 Apr 1994 08:23:52 -0700 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id IAA25429; Tue, 26 Apr 1994 08:23:14 -0700 Received: from avalle.insoft.com by insoft1.insoft.com (4.1/RHP-1.0) id AA26934; Tue, 26 Apr 94 11:07:42 EDT Received: by avalle.insoft.com (5.0/SMI-SVR4) id AA20748; Tue, 26 Apr 1994 11:03:41 +0500 Date: Tue, 26 Apr 1994 11:03:41 +0500 From: francis@avalle.insoft.com (John [Francis] Stracke) Message-Id: <9404261503.AA20748@avalle.insoft.com> To: firewalls@GreatCircle.COM In-Reply-To: Kevin Altis's message of Mon, 25 Apr 1994 16:42:36 -0800 Subject: WWW proxy information Content-Length: 1595 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Since February, 1994, firewalls have been "safely permeable" for World Wide >Web (WWW) clients via an application level proxy. Proxy support is built "Safely"? I don't think so. There was some talk a while ago on this list about mosaic (and, perhaps, lynx) having serious security holes. Something about using system() indiscriminately, something like: { char cmd[1024]; sprintf(cmd,"more %s",filename); system(cmd); } where filename is provided by the http page you're reading. If filename is "foo ; otherCmd", first you see what you expect, then otherCmd is executed *as you*. With some trickiness, otherCmd can be used to compromise your system, or at least your own account, and send a notification to the slime who wrote it. >If you have concerns about application level proxies in general or our >solution specifically, then please raise them on this list rather than >emailing me directly so that we can all participate in the discussion. I think there's (likely) nothing wrong with your proxy; but people need to realize that running a proxied mosaic is scarcely safer than running without a firewall. /===========================================================================\ |John (Francis) Stracke | My opinions are my own.| The cheapest, fastest, | |InSoft, Inc. |========================/ and most reliable | |Mechanicsburg, PA | components of a computer system are those that | |francis@insoft.com | aren't there.--Gordon Bell | \===========================================================================/ From firewalls-owner Tue Apr 26 15:38:26 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA03458; Tue, 26 Apr 1994 15:38:26 GMT Received: from CITB.CITADEL.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA03452; Tue, 26 Apr 1994 08:38:17 -0700 Received: from citadel.edu by citadel.edu (PMDF V4.2-11 #4957) id <01HBMO8QP4WG8WWDJU@citadel.edu>; Tue, 26 Apr 1994 11:39:11 EDT Date: Tue, 26 Apr 1994 11:39:11 -0400 (EDT) From: "George C. Russ: 803-953-6817" Subject: Dial-in accounting for charge back To: Firewalls@GreatCircle.COM Message-id: <01HBMO8QTOV68WWDJU@citadel.edu> X-VMS-To: IN%"Firewalls@GreatCircle.COM" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We are trying to develop a system to allow modem access while accounting for the usage. The Host(called) site would pay a per minute charge based upon the duration of the successful login to its host. No password checking need to be accomplished these will be for public access to a specified number of hosts. Accounting needs show : 1)Succesful telnet connection. Need to know if login was succesful. 2)The Host to which the user connected 3)The amount of time the connection existed. Any suggestions?? // George C. Russ 803-953-6817 (FAX 953-2212) Network Services Manager Internet:russg@citadel.edu The Citadel, Charleston SC 29409 BITNET:russg@citadel ** GO 'NOLES ** From firewalls-owner Tue Apr 26 08:40:45 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA03418; Tue, 26 Apr 1994 15:31:07 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA03411; Tue, 26 Apr 1994 08:30:55 -0700 Received: by relay.tis.com; id AA07946; Tue, 26 Apr 94 11:32:03 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma007941; Tue Apr 26 11:31:44 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA05012; Tue, 26 Apr 94 11:30:15 EDT Date: Tue, 26 Apr 94 11:30:15 EDT From: Marcus J Ranum Message-Id: <9404261530.AA05012@tis.com> To: atr@maine.net, firewalls@GreatCircle.COM Subject: Re: Cost of firewall hosts; BSDI Unix Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >What are some typical hosts used for firewall/bastion hosts, and what is their >ultimate cost including all necessary hardware and software? I'm assuming a >UNIX system with 32Mb RAM and >1Gb of disk space A 486/55 w/ 1gb disk and 32Mb of RAM is plenty of hardware. I have no idea what one costs since the price of such hardware drops every day. :) BSDI is about $500 on top of that. Not a lot of money, all things considered. Such a machine can handle a T1 line without much trouble -- after all, a T1 is a pretty low data rate and a 486 is a pretty zippy processor. >I'm particularly >interested in the cost of systems which support the TIS toolkit without porting It's very likely that the reference platform for the toolkit with switch to BSDI [from SunOs] very soon. "porting" it, in either case, is a matter of changing a line in one Makefile, and another line in firewall.h. BSDI is also very attractive, now that screend has been released for it! It can now act as a semi-permeable dual-homed gateway. mjr. From firewalls-owner Tue Apr 26 09:59:50 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA03829; Tue, 26 Apr 1994 16:03:41 GMT Received: from tadpole by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA03823; Tue, 26 Apr 1994 09:03:30 -0700 Received: from chiba.tadpole.com by tadpole (4.1/SMI-4.1-jim) id AA22029; Tue, 26 Apr 94 11:03:30 CDT Received: by chiba.tadpole.com (5.0/SMI-SVR4) id AA01072; Tue, 26 Apr 1994 11:04:06 +0600 Date: Tue, 26 Apr 1994 11:04:06 +0600 From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9404261604.AA01072@chiba.tadpole.com> To: atr@maine.net, firewalls@GreatCircle.COM, mjr@tis.com Subject: Re: Cost of firewall hosts; BSDI Unix Content-Length: 174 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > BSDI is also very attractive, now that screend has been released > for it! It can now act as a semi-permeable dual-homed gateway. As can SunOS, with the right bits. Jim From firewalls-owner Tue Apr 26 17:23:11 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA05044; Tue, 26 Apr 1994 17:23:11 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA05037; Tue, 26 Apr 1994 10:23:04 -0700 Message-Id: <199404261723.KAA05037@mycroft.GreatCircle.COM> To: jim@Tadpole.COM (Jim Thompson) cc: atr@maine.net, firewalls@GreatCircle.COM, mjr@tis.com Subject: Re: Cost of firewall hosts; BSDI Unix In-reply-to: Your message of Tue, 26 Apr 1994 11:04:06 +0600 Date: Tue, 26 Apr 1994 10:23:03 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk jim@Tadpole.COM (Jim Thompson) writes: # # > BSDI is also very attractive, now that screend has been released # > for it! It can now act as a semi-permeable dual-homed gateway. # # As can SunOS, with the right bits. # # Jim Sure, but the port of screend to SunOS is not generally available, because it requires SunOS kernel source, which most people don't have. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Tue Apr 26 10:30:36 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA04057; Tue, 26 Apr 1994 16:14:39 GMT Received: from freenet3.carleton.ca by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA04051; Tue, 26 Apr 1994 09:14:29 -0700 Received: from localhost (xx247@localhost) by freenet3.carleton.ca (8.6.4/8.6.4) id MAA01595 for firewalls@greatcircle.com; Tue, 26 Apr 1994 12:15:01 -0400 From: "G.J.W. Hagenaars" Message-Id: <199404261615.MAA01595@freenet3.carleton.ca> Subject: Re: WWW proxy information To: firewalls@greatcircle.com Date: Tue, 26 Apr 1994 12:15:01 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 890 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk francis@avalle.insoft.com (John [Francis] Stracke) wrote: % There was some talk a while ago on this % list about mosaic (and, perhaps, lynx) having serious security holes. % Something about using system() indiscriminately, something like: % % { % char cmd[1024]; % sprintf(cmd,"more %s",filename); % system(cmd); % } % % where filename is provided by the http page you're reading. If % filename is "foo ; otherCmd", first you see what you expect, then % otherCmd is executed *as you*. With some trickiness, otherCmd can be % used to compromise your system, or at least your own account, and send % a notification to the slime who wrote it. Does anyone know if it is possible to run lynx in it's own directory tree with something like chrootuid? And only allow a (very limited) list of commands to execute that are in _that_ tree? That would stop the above mentioned attack. GJ From firewalls-owner Tue Apr 26 17:48:57 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA05411; Tue, 26 Apr 1994 17:48:57 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA05404; Tue, 26 Apr 1994 10:48:51 -0700 Message-Id: <199404261748.KAA05404@mycroft.GreatCircle.COM> To: "G.J.W. Hagenaars" cc: firewalls@greatcircle.com Subject: Re: WWW proxy information In-reply-to: Your message of Tue, 26 Apr 1994 12:15:01 -0400 (EDT) Date: Tue, 26 Apr 1994 10:48:50 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "G.J.W. Hagenaars" writes: # Does anyone know if it is possible to run lynx in it's own directory # tree with something like chrootuid? And only allow a (very limited) list # of commands to execute that are in _that_ tree? That would stop the # above mentioned attack. It would also make it much more annoying for users who are doing things like retrieving files... Their files would get saved into this restricted area, and they'd have to transfer them out again. It would also mean that their configuration and control files for the program would have to be in that restricted area. Seems like a lot of trouble to me... I'm a strong believer that, if you make things too inconvenient for users, they'll find ways of their own to make things convenient, and the ways they find will generally not be very good from a security standpoint. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Tue Apr 26 11:11:07 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA05621; Tue, 26 Apr 1994 18:02:26 GMT Received: from ALABAMA.CF.CS.YALE.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA05615; Tue, 26 Apr 1994 11:02:17 -0700 Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Tue, 26 Apr 1994 14:02:42 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.67b/res.client.cf-3.7) id AA01605; Tue, 26 Apr 1994 14:02:41 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199404261802.AA01605@SPARKY.CF.CS.YALE.EDU> To: "G.J.W. Hagenaars" Cc: firewalls@GreatCircle.COM Subject: Re: WWW proxy information In-Reply-To: Your message of Tue, 26 Apr 94 12:15:01 EDT. Date: Tue, 26 Apr 94 14:02:39 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <199404261615.MAA01595@freenet3.carleton.ca> you write: >Does anyone know if it is possible to run lynx in it's own directory >tree with something like chrootuid? And only allow a (very limited) list >of commands to execute that are in _that_ tree? That would stop the >above mentioned attack. Telnet to INFO.CS.YALE.EDU (128.36.16.17), supply the name of a reasonably intelligent terminal, and you will be running "lynx" in a chrooted environment - if you want to check it out. You won't be able to save files or print, etc inside this "guest" telnet to WWW gateway (which you would probably want to do) but your basic idea should work (I ran lynx in a chroot()ed env. without telneting into the anonymous lynx setup while setting up and testing it). - Morrow From firewalls-owner Tue Apr 26 20:33:50 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA06972; Tue, 26 Apr 1994 20:33:50 GMT Received: from ibeam.intel.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA06966; Tue, 26 Apr 1994 13:33:26 -0700 Received: from [134.134.208.67] by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0pvtmx-0003UqC; Tue, 26 Apr 94 13:31 PDT Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Apr 1994 13:34:46 -0800 To: francis@avalle.insoft.com (John [Francis] Stracke) From: altis@ibeam.intel.com (Kevin Altis) Subject: Re: WWW proxy information Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>Since February, 1994, firewalls have been "safely permeable" for World Wide >>Web (WWW) clients via an application level proxy. Proxy support is built > >"Safely"? I don't think so. There was some talk a while ago on this >list about mosaic (and, perhaps, lynx) having serious security holes. >Something about using system() indiscriminately, something like: The security hole you pointed out is valid, however that's not the point. The trojan horse problem, discussed on this list previously, is a separate issue and as far as I can tell, unsolvable except by denying access altogether. >I think there's (likely) nothing wrong with your proxy; but people >need to realize that running a proxied mosaic is scarcely safer than >running without a firewall. That is a major overstatement of the problem. Running without a firewall opens your net up to a number of attacks that are not possible just because you allow outgoing HTTP, FTP, Gopher connections via a proxy. In the case of most corporations, the above mentioned problems with Lynx and Mosaic for X (which have or are being addressed) aren't at issue anyway, since they don't apply to Mosaic for Mac, Mosaic for Windows, Cello, etc. Those PC and Mac environments which are the majority of machines, don't have the *same* environment problems mentioned above. On the other hand, there is always the possibility that a particular Web or ftp or gopher or wais, etc. client application will be vunerable to trojan horse attacks in yet another way because of its particular implementation. ka From firewalls-owner Tue Apr 26 21:54:33 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA07416; Tue, 26 Apr 1994 21:54:33 GMT Received: from research.att.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA07410; Tue, 26 Apr 1994 14:54:26 -0700 From: smb@research.att.com Message-Id: <199404262154.OAA07410@mycroft.GreatCircle.COM> Received: by gryphon; Tue Apr 26 17:42:46 EDT 1994 To: firewalls@greatcircle.com Subject: firewalls book Date: Tue, 26 Apr 94 17:42:45 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Since I've received a fair number of questions about the book, I'll make one (and only one) post about it, with the prior permission of our esteemed host and (quasi-)moderator. The book is Firewalls and Internet Security: Repelling the Wily Hacker William R. Cheswick and Steven M. Bellovin Addison-Wesley ISBN 0-201-63357-4 $26.95, paperback The book was printed yesterday (literally!); it should be in technical bookstores within a couple of weeks, and in larger general bookstores (i.e., Barnes and Noble) by the end of May. It will take somewhat longer for the book to reach non-U.S. locations. If you can't find it in your own neighborhood, you can order it directly from Addison-Wesley. You can snarf the preface, table of contents, and cover from research.att.com:/dist/internet_security/firewall.book/* More stuff (i.e., an errata list) may show up there on occasion. There's a gopher and ftp server on aw.com, but they're not fully up to speed yet. --Steve Bellovin From firewalls-owner Wed Apr 27 00:15:20 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA08091; Wed, 27 Apr 1994 00:15:20 GMT Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA08085; Tue, 26 Apr 1994 17:15:11 -0700 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id RAA04759; Tue, 26 Apr 1994 17:15:55 -0700 Received: from avalle.insoft.com by insoft1.insoft.com (4.1/RHP-1.0) id AA28274; Tue, 26 Apr 94 17:26:06 EDT Received: by avalle.insoft.com (5.0/SMI-SVR4) id AA20952; Tue, 26 Apr 1994 17:22:06 +0500 Date: Tue, 26 Apr 1994 17:22:06 +0500 From: francis@avalle.insoft.com (John [Francis] Stracke) Message-Id: <9404262122.AA20952@avalle.insoft.com> To: firewalls@GreatCircle.COM In-Reply-To: Kevin Altis's message of Tue, 26 Apr 1994 13:34:46 -0800 Subject: WWW proxy information Content-Length: 1785 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>Since February, 1994, firewalls have been "safely permeable" for World Wide >>>Web (WWW) clients via an application level proxy. Proxy support is built >> >>"Safely"? I don't think so. There was some talk a while ago on this > >The trojan horse problem, discussed on this list previously, is a separate >issue and as far as I can tell, unsolvable except by denying access >altogether. Unsolvable from the library/protocol level, yes. >>I think there's (likely) nothing wrong with your proxy; but people >>need to realize that running a proxied mosaic is scarcely safer than >>running without a firewall. > >That is a major overstatement of the problem. Well, OK, but your implication that proxies make you safe is also a major overstatement; I was concerned that, in your attempt to make your (valid) point that proxies are good, you were going to go too far, which would wind up in trusting people getting burned. I believe you stated that using a proxy meant you didn't compromise your firewall at all. >Cello, etc. Those PC and Mac environments which are the majority of >machines, don't have the *same* environment problems mentioned above. True. And they probably have fewer holes, and more obscure; there's probably nothing so egregious as the system() calls. But you can be sure there are some. /===========================================================================\ |John (Francis) Stracke | My opinions are my own. | |InSoft, Inc. |==================================================| |Mechanicsburg, PA | But this one goes to 11x. | |francis@insoft.com | | \===========================================================================/ From firewalls-owner Wed Apr 27 01:56:10 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id BAA08571; Wed, 27 Apr 1994 01:56:10 GMT Received: from ncnoc.concert.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA08565; Tue, 26 Apr 1994 18:56:02 -0700 Received: from ash.rjrt.com by ncnoc.concert.net (5.65/tas-concert/aug93) id AA15941; Tue, 26 Apr 94 21:56:27 -0400 Received: by rjrt.COM (5.0/SMI-SVR4) id AA12422; Tue, 26 Apr 1994 21:54:01 +0500 Date: Tue, 26 Apr 1994 21:54:01 +0500 From: dwg@rjrt.COM (David W. Griffith) Message-Id: <9404270154.AA12422@rjrt.COM> To: firewalls@GreatCircle.COM Subject: Re: WWW proxy information X-Sun-Charset: US-ASCII Content-Length: 1017 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From firewalls-owner@GreatCircle.COM Tue Apr 26 14:21 EDT 1994 > Subject: Re: WWW proxy information > To: firewalls@GreatCircle.COM > X-Mailer: ELM [version 2.4 PL23] > Sender: Firewalls-Owner@GreatCircle.COM > Content-Type: text > Content-Length: 890 > X-Lines: 24 > > francis@avalle.insoft.com (John [Francis] Stracke) wrote: > > % There was some talk a while ago on this > % list about mosaic (and, perhaps, lynx) having serious security holes. > % Something about using system() indiscriminately, something like: > % > % { > % char cmd[1024]; > % sprintf(cmd,"more %s",filename); > % system(cmd); > % } > % > % where filename is provided by the http page you're reading. If > % filename is "foo ; otherCmd", first you see what you expect, then > % otherCmd is executed *as you*. With some trickiness, otherCmd can be > % used to compromise your system, or at least your own account, and send > % a notification to the slime who wrote it. > I believe this problem was cleared up in NCSA Mosaic 2.3 From firewalls-owner Wed Apr 27 12:00:43 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA14423; Wed, 27 Apr 1994 12:00:43 GMT Received: from merlin.resmel.bhp.com.au by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA14409; Wed, 27 Apr 1994 05:00:33 -0700 Received: from monster.resmel.bhp.com.au by merlin.resmel.bhp.com.au with SMTP id AA29143 (5.67b/IDA-1.5 for ); Wed, 27 Apr 1994 22:00:59 +1000 Received: by monster.resmel.bhp.com.au id AA22841 (5.67b/IDA-1.5 for firewalls@greatcircle.com); Wed, 27 Apr 1994 22:00:58 +1000 From: Ian Hoyle Message-Id: <199404271200.AA22841@monster.resmel.bhp.com.au> Subject: TIS WWW server To: firewalls@greatcircle.com Date: Wed, 27 Apr 1994 22:00:57 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 679 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I can't remember it being mentioned in this list before, but the TIS WWW server presents a nice interface for getting at information about the products they market, as well as the TIS toolkit we all know and love :-) I've just had a fun 1/2 hr or so browsing around and it's not bad at all, ian -- /\/\ : Ian Hoyle, Senior Research Scientist / / /\ : BHP Research - Melbourne Laboratories / / / \ : 245 Wellington Rd, Mulgrave, 3170, AUSTRALIA / / / /\ \ : Phone +61-3-560-7066 \ \/ / / / : E-mail ianh@resmel.bhp.com.au \ / / / : \/\/\/ : "perl - the swiss army chainsaw of UNIX tools" : -- Rob Kolstad From firewalls-owner Wed Apr 27 12:41:48 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA14598; Wed, 27 Apr 1994 12:41:48 GMT Received: from jupiter.hsi.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA14592; Wed, 27 Apr 1994 05:41:35 -0700 Received: from localhost by jupiter.hsi.com with SMTP id AA15246 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 27 Apr 1994 08:41:06 -0400 Message-Id: <199404271241.AA15246@jupiter.hsi.com> To: Ian Hoyle Cc: firewalls@greatcircle.com, addiss@hsi.com Subject: Re: TIS WWW server In-Reply-To: Your message of "Wed, 27 Apr 94 22:00:57 +1000." <199404271200.AA22841@monster.resmel.bhp.com.au> Date: Wed, 27 Apr 94 08:41:06 -0400 From: "Justus J. Addiss (addiss@hsi.com) 203-949-6414" X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> Hi, >> >> I can't remember it being mentioned in this list before, but >> the TIS WWW server presents a nice interface for getting at information >> about the products they market, as well as the TIS toolkit we all >> know and love :-) >> >> I've just had a fun 1/2 hr or so browsing around and it's not bad at all, How about posting the HTTP to get to it? Justus J. Addiss, Sr. Software Engineer, 3M Health Information Systems addiss@hsi.com, 203-949-6414 From firewalls-owner Wed Apr 27 12:55:26 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA14699; Wed, 27 Apr 1994 12:55:26 GMT Received: from ALABAMA.CF.CS.YALE.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA14693; Wed, 27 Apr 1994 05:55:19 -0700 Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Wed, 27 Apr 1994 08:55:30 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.67b/res.client.cf-3.7) id AA05394; Wed, 27 Apr 1994 08:55:29 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199404271255.AA05394@SPARKY.CF.CS.YALE.EDU> To: "Justus J. Addiss (addiss@hsi.com) 203-949-6414" Cc: Ian Hoyle , firewalls@GreatCircle.COM Subject: Re: TIS WWW server In-Reply-To: Your message of Wed, 27 Apr 94 08:41:06 EDT. Date: Wed, 27 Apr 94 08:55:27 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <199404271241.AA15246@jupiter.hsi.com> you write: >>> Hi, >>> >>> I can't remember it being mentioned in this list before, but >>> the TIS WWW server presents a nice interface for getting at information >>> about the products they market, as well as the TIS toolkit we all >>> know and love :-) >>> >>> I've just had a fun 1/2 hr or so browsing around and it's not bad at all, > >How about posting the HTTP to get to it? > >Justus J. Addiss, Sr. Software Engineer, 3M Health Information Systems >addiss@hsi.com, 203-949-6414 This one was fairly easy to figure out: http://www.tis.com/ H. Morrow Long, Mgr of Dev., Yale Univ., Comp Sci Dept, 011 AKW, New Haven, CT 06520-8285, VOICE: (203)-432-{1248,1254} FAX: (203)-432-0593 INET: Long-Morrow@CS.Yale.EDU UUCP: yale!Long-Morrow BITNET: Long-Morrow@YaleCS WWW: http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/long-morrow.html From firewalls-owner Wed Apr 27 22:24:39 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA27576; Wed, 27 Apr 1994 22:24:39 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA27570; Wed, 27 Apr 1994 15:24:32 -0700 Received: by mail-relay-2.mv.us.adobe.com; id PAA02967; Wed, 27 Apr 1994 15:24:36 -0700 Received: by guardi.mv.us.adobe.com; id PAA00510; Wed, 27 Apr 1994 15:24:33 -0700 Message-Id: <199404272224.PAA00510@guardi.mv.us.adobe.com> To: firewalls@GreatCircle.COM Subject: Re: WWW proxy information In-reply-to: Your message of "Tue, 26 Apr 1994 11:03:41 +0500." <9404261503.AA20748@avalle.insoft.com> Date: Wed, 27 Apr 1994 15:24:31 -0700 From: Tim Guarnieri Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> I think there's (likely) nothing wrong with your proxy; but people >> need to realize that running a proxied mosaic is scarcely safer than >> running without a firewall. The whole idea of "safety" is subjective and depends largely on the environment in which something is implemented and the specific security policies/concerns within that environment. That being said, I do not wish to get into a debate (in this message, anyway :-) of what "safe" means or which approach may or may not be "safer" than another. Suffice it to say that the very nature of Mosaic, et al. creates some element of risk for the host on which it is run. To the extent that the Mosaic application itself uses conventions (i.e. use of system()) that increase risk unnecessarily, then those issues need to be addressed by the application developers. I believe this specific issue was addressed in the 2.3 release. The point I wish to make in this message is that the proxy daemon approach is a much cleaner way (in my view) of permitting WWW access through the firewall than, say, the SOCKS approach is. In the SOCKS approach, one specifies "connection level" filters that specify who can and cannot make connections to the SOCKS daemon. Once a connection to the SOCKS daemon is permitted, it simply glues two file descriptors together and "pumps" bits between them (via a small function named Pump()). Since no protocol filtering ability is available under SOCKS, this approach is little different from allowing direct connections between internal hosts and Internet hosts. This is much closer to the "running without a firewall" scenario than the proxy daemon approach. In the proxy daemon approach, one still has "connection level" filtering capability, however, one also has the ability to do protocol-level filtering as well (by virtue of being able to enable/disable commands within the protocol suite in the proxy configuration file). Using configuration directives, one can also have the daemon run as a non-priviledged process (i.e. nobody/nogroup or daemon/daemon or whatever). It is also "cleaner" in the sense that one no longer has to replace functions inside the client code (i.e. connect with Rconnect), and link against a library containing those functions. I like this approach because it is a true "application level" gateway and can be used with "out of the box" Mosaic. If other client applications adopt this approach then they, too, could conceivably be used "out of the box" and would not need to be recompiled on a platform by platform basis. I realize many folks out there use the SOCKS approach and are perfectly comfortable and happy with it. Being a satisified user of the proxy approach, I did want to share my insights here for folks to consider. Tim From firewalls-owner Thu Apr 28 00:03:45 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA27955; Thu, 28 Apr 1994 00:03:45 GMT Received: from hermes.intel.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA27949; Wed, 27 Apr 1994 17:03:30 -0700 Received: from argus.intel.com by hermes.intel.com (5.65/10.0i); Wed, 27 Apr 94 17:03:29 -0700 Received: by argus.intel.com (5.65/10.0i); Wed, 27 Apr 94 17:03:28 -0700 From: sedayao@argus.intel.com (Jeffrey C. Sedayao) Message-Id: <9404280003.AA25375@argus.intel.com> Subject: Re: WWW proxy information To: altis@ibeam.jf.intel.com (Kevin Altis) Date: Wed, 27 Apr 94 17:03:27 PDT Cc: francis@avalle.insoft.com, firewalls@GreatCircle.COM In-Reply-To: from "Kevin Altis" at Apr 26, 94 01:34:46 pm X-Mailer: ELM [version 2.4dev PL66] Mime-Version: 1.0 Content-Type: text Content-Length: 1826 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk [stuff deleted] > >I think there's (likely) nothing wrong with your proxy; but people > >need to realize that running a proxied mosaic is scarcely safer than > >running without a firewall. > That is a major overstatement of the problem. Running without a firewall > opens your net up to a number of attacks that are not possible just because > you allow outgoing HTTP, FTP, Gopher connections via a proxy. > In the case of most corporations, the above mentioned problems with Lynx > and Mosaic for X (which have or are being addressed) aren't at issue > anyway, since they don't apply to Mosaic for Mac, Mosaic for Windows, > Cello, etc. Those PC and Mac environments which are the majority of > machines, don't have the *same* environment problems mentioned above. > On the other hand, there is always the possibility that a particular Web or > ftp or gopher or wais, etc. client application will be vunerable to trojan > horse attacks in yet another way because of its particular implementation. Since it is difficult to know if clients are vulnerable to trojan horses, it would seem to make sense to put trojan detection code in the proxy daemon. The code could look for semicolons in URLs, file operations in incoming postscript, etc. When new trojans need to be detected, you would only need to change one proxy rather than lots and lots of clients. Being able to scan URLs and incoming information is one of the benefits of application layer proxy. Are there any plans for putting this kind of trojan detection in the CERN httpd or any other proxy package? By the way, Mosaic 2.4 still uses system quite liberally, although the developers are clearly looking to use fork (there are some comments like "we really should use fork instead"). > ka -- Jeff Sedayao Intel Corporation sedayao@argus.intel.com From firewalls-owner Thu Apr 28 01:00:56 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id HAA06945; Thu, 28 Apr 1994 07:46:32 GMT Received: from sun4nl.NL.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id AAA06938; Thu, 28 Apr 1994 00:46:21 -0700 Received: from uugignl by sun4nl.NL.net via EUnet id AA25161 (5.65b/CWI-3.3); Thu, 28 Apr 1994 09:46:38 +0200 Received: from godot.bs.gig.nl by dejavu.gig.nl (920330.SGI/5.6) id AA22260; Thu, 28 Apr 94 09:45:34 +0100 Received: by godot.gig.nl (930416.SGI/890607.SGI) (for firewalls@greatcircle.com) id AA03445; Thu, 28 Apr 94 09:45:42 +0100 Date: Thu, 28 Apr 94 09:45:42 +0100 From: paul@gig.nl (Paul Boots) Message-Id: <9404280945.ZM3409@godot> Company: DIGIT ALL entertainment Address: Amstel 222 City: 1017 AJ Amsterdam Country: The Netherlands Phone: (31) (0)20 627 0263 Fax: (31) (0)20 627 5566 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: firewalls@greatcircle.com Subject: What is a firewall Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi there, After getting interested in security issues I got directed to this mailing list. Problem is, I don't know what a firewall is!!! Would somebody care to tell me please, what is it, where can you get it, what do you pay for it etc... Please be so kind as to send any answers to my personal mail address. Most people reading this probably allready know what there talking about. Thank you. Paul Boots (paul@gig.nl) From firewalls-owner Thu Apr 28 03:41:34 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA08144; Thu, 28 Apr 1994 10:32:09 GMT Received: from gate.ggr.co.uk by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA08138; Thu, 28 Apr 1994 03:31:55 -0700 Received: from mailhub.ggr.co.uk by gate.ggr.co.uk; Thu, 28 Apr 1994 11:29:02 +0100 Received: from uk0x04 by mailhub.ggr.co.uk; Thu, 28 Apr 1994 11:25:32 +0100 Received: by uk0x04 (8.6.8.1/imd160294) id LAA11649; Thu, 28 Apr 1994 11:28:52 +0100 Date: Thu, 28 Apr 1994 11:28:50 +0100 (BST) From: Ian Dunkin Subject: Re: WWW proxy information To: Kevin Altis cc: firewalls@GreatCircle.COM, Ari Luotonen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Mon, 25 Apr 1994, Kevin Altis wrote: > Many of you already know about the application level proxy design developed > by Kevin Altis, Ari Luotonen, and Lou Montulli. Yes, a very useful mechanism too. > If you have concerns about application level proxies in general or our > solution specifically, then please raise them on this list [...] Several responses to this have mentioned particular security holes in browsers like Mosaic rather than replying about the proxying of WWW per se. Admittedly these holes are _related_ to the proxying effort, since some of the offending code was inherited as common from the WWW library; and there was discussion on this list that some of this code seemed not to have been written with UNIX security well in mind. But I think people made suggestions how this might be improved.. But however it is coded that (say) telnet URLs get satisfied, and assuming that any holes there can be fixed, the existence of a mechanism for proxying WWW has to be a good thing, doesn't it? - that you can now get clients to redirect their WWW requests. And the Altis/Luotonen/Montulli redirection mechanism works, whereas the older one didn't, really. What you then redirect the clients TO is up to you: If you're happy with running an httpd on your firewall system you can do so. (I'm not happy with this, because I don't like running such a big lump of mysterious [to me] code there.) If you're not, you can satisfy the redirected requests in some other way, eg, write you own WWW proxy (I imagine this is the way that black-box Firewall vendors will go?); or run the WWW proxy inside your firewall and use some other firewall protocol to work through the firewall (eg SOCKS). All that's easy once you can get the clients to redirect their requests. So, I think the ability that the Altis/Luotonen/Montulli mechanism provides _has_ to be a Good Thing. My more _persistent_ concerns about the proxying of WWW are not so much to do with the mechanism, but rather -- now we can extend WWW access through firewalls to all our PC users -- with the way that browsers like Mosaic (intentionally) hide very well from dumb users the import of what they're actually doing (ironic, eh?); this makes it harder for them to understand that (for example) the cute PC package they acquired by clicking on a blue word in a prettily imaged page still needs to go through the software vetting procedures. They don't see this as software import. And so on. I don't suppose anyone has written any form of words on `security considerations for naive WWW users' ? I. "Jeffrey C. Sedayao" idea of the proxy doing safety checks on URLs is quite nice, but presumaby if all this fixed for good in the common WWW library, it would get everywhere anyway, and would then apply to non-proxied accesses too. -- Ian Dunkin -- From firewalls-owner Thu Apr 28 11:02:55 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA08368; Thu, 28 Apr 1994 11:02:55 GMT Received: from gate.ggr.co.uk by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id EAA08362; Thu, 28 Apr 1994 04:02:47 -0700 Received: from mailhub.ggr.co.uk by gate.ggr.co.uk; Thu, 28 Apr 1994 12:01:29 +0100 Received: from uk0x04 by mailhub.ggr.co.uk; Thu, 28 Apr 1994 11:57:59 +0100 Received: by uk0x04 (8.6.8.1/imd160294) id MAA11674; Thu, 28 Apr 1994 12:01:24 +0100 Date: Thu, 28 Apr 1994 12:01:23 +0100 (BST) From: Ian Dunkin Reply-To: Ian Dunkin Subject: Re: WWW proxy information To: Tim Guarnieri cc: firewalls@GreatCircle.COM In-Reply-To: <199404272224.PAA00510@guardi.mv.us.adobe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Wed, 27 Apr 1994, Tim Guarnieri wrote: > In the SOCKS approach, one specifies "connection level" filters that specify > who can and cannot make connections to the SOCKS daemon. Once a connection > to the SOCKS daemon is permitted, it simply glues two file descriptors > together and "pumps" bits between them (via a small function named Pump()). > Since no protocol filtering ability is available under SOCKS, this approach > is little different from allowing direct connections between internal hosts > and Internet hosts. if I might clarify this last sentence of yours for anyone reading it quickly: Of course, SOCKS _does_ allow filtering based on particular protocols -- that is, you can decide which protocols are to be allowed between which combinations of local and remote systems, and for which users (if you trust your local systems or their identd). What it does not provide, as you say, is filtering within a particular protocol. That is, if you are allowing Jill to connect from her workstation to prep.ai.mit.edu for ftp, you cannot restrict which operations within the FTP protocol are available to her, nor which files she can transfer. I. -- Ian Dunkin -- From firewalls-owner Thu Apr 28 05:30:57 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA08742; Thu, 28 Apr 1994 12:15:36 GMT Received: from seraph.uunet.ca by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id FAA08736; Thu, 28 Apr 1994 05:15:21 -0700 Received: from edfor by mail.uunet.ca with UUCP id <88343-4>; Thu, 28 Apr 1994 08:15:11 -0400 Received: by edfor (MKS UUCP); Thu, 28 Apr 94 08:13:00 EST To: firewalls@GreatCircle.COM Subject: Subscription Message-Id: <767520780@edfor> Date: Thu, 28 Apr 1994 09:13:00 -0400 From: pierre@edfor.com (Pierre Bernatchez) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk help From firewalls-owner Thu Apr 28 13:49:27 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA09174; Thu, 28 Apr 1994 13:49:27 GMT Received: from clavin.uprc.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA09168; Thu, 28 Apr 1994 06:49:12 -0700 Received: from cygnus.uprc.com by clavin.uprc.com (4.1/3.2.012693-Union Pacific Resources Company); id AA17977 for firewalls@greatcircle.com; Thu, 28 Apr 94 08:47:28 CDT Received: by cygnus.uprc.com (5.0/SMI-SVR4) id AA20720; Thu, 28 Apr 1994 08:47:27 +0600 Date: Thu, 28 Apr 1994 08:47:27 +0600 From: lacoursj@uprc.com (Jeffrey D. LaCoursiere) Message-Id: <9404281347.AA20720@cygnus.uprc.com> To: firewalls@greatcircle.com Subject: SNK key checksums X-Sun-Charset: US-ASCII Content-Length: 867 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk When loading a Digital Pathways SNK key with the initial 24 digit seed, the key provides a checksum so you can verify that you loaded what you meant to load. Digital Pathways sells a box to manage the keys that can generate "random" 24 digit seeds and provide a checksum that should match what the key will generate after loading. Being cheap, (or maybe just cost-conscious :-> ) we opted for the TIS toolkit and did not buy the authentication server from Digital Pathways. We are using the toolkit's "snkkey" to generate the "random" 24 digit seeds. The question? Has anyone figured out the algorithmn being used by the key to generate the checksum displayed after loading? Would be very nice to hack snkkey to spit out both a "random" seed and the checksum that will match what the key itself displays... Jeff LaCoursiere Network Admin UPRC Ft. Worth, TX From firewalls-owner Thu Apr 28 06:50:59 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA09154; Thu, 28 Apr 1994 13:41:07 GMT Received: from spool.cs.wisc.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA09148; Thu, 28 Apr 1994 06:40:56 -0700 Received: by spool.cs.wisc.edu; Thu, 28 Apr 94 08:40:11 -0500 Received: by Arnold.Com with UUCP/PMDF (DECUS UUCP); Thu, 28 Apr 1994 08:27:06 -0500 (CDT) Received: from Arnold.Com by Arnold.Com (PMDF V4.3-7 #6072) id <01HBP8Z7BURK8WVYY9@Arnold.Com>; Thu, 28 Apr 1994 08:26:51 -0500 (CDT) Date: Thu, 28 Apr 1994 08:16:59 -0500 (CDT) From: Stephen.L.Arnold@Arnold.Com Subject: Screend ports (other than ULTRIX and BSD/386)? To: Firewalls@GreatCircle.Com Cc: Stephen.L.Arnold@Arnold.Com Message-Id: <01HBPA75649O8WVYY9@Arnold.Com> Organization: Arnold Consulting Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am designing a screened subnet firewall for a client. We plan to use screend running on a host for packet screening because of the limitations of screening routers. The UNIX support services provided by the client are oriented toward Solaris, and there is considerable suspicion of other types of "open systems". (Go figure!) Unfortunately, it appears to be prohibitively expensive to either license Solaris source code or hire SunSoft to port screend's kernel support to Solaris. So we are considering ready-to-run screend on ULTRIX or BSD/386. Several questions: 1. Can anyone suggest a way to run screend on Solaris without licensing the source code or paying SunSoft, or have experience with either of those options? (Due diligence, you know...) 2. There is already some SCO UNIX in the company. Does anyone know of a way to run screend on SCO UNIX on an Intel PC? (We're not interested in alternatives to screend.) Thanks for any input you can provide! Regards, "Steve" Stephen L. Arnold, Ph.D., Principal, Arnold Consulting Address 4138 Iroquois Drive, Madison, Wisconsin 53711-3701 U.S.A. Telephone +1 608 238 4850 Facsimile +1 608 238 4855 Internet Stephen.L.Arnold@Arnold.Com BITNET ARNOLD@WISCPSL Pager (800) Sky-Page, PIN 238-4850 From firewalls-owner Thu Apr 28 07:00:58 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA09162; Thu, 28 Apr 1994 13:41:32 GMT Received: from spool.cs.wisc.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id GAA09156; Thu, 28 Apr 1994 06:41:16 -0700 Received: by spool.cs.wisc.edu; Thu, 28 Apr 94 08:40:10 -0500 Received: by Arnold.Com with UUCP/PMDF (DECUS UUCP); Thu, 28 Apr 1994 08:14:47 -0500 (CDT) Received: from Arnold.Com by Arnold.Com (PMDF V4.3-7 #6072) id <01HBP8Z7BURK8WVYY9@Arnold.Com>; Thu, 28 Apr 1994 08:14:33 -0500 (CDT) Date: Thu, 28 Apr 1994 07:59:29 -0500 (CDT) From: Stephen.L.Arnold@Arnold.Com Subject: RE: Wanted: firewall manager position description To: Firewalls@GreatCircle.Com Cc: Stephen.L.Arnold@Arnold.Com Message-Id: <01HBP9QWOO2C8WVYY9@Arnold.Com> Organization: Arnold Consulting Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Last Friday I wrote to this list: > I'm a long-time lurker on this list and an independent consultant whose > practice seems to involve more firewalls all the time. > > One of my clients is a large organization and seems to be comitted to > doing firewalls right. They intend to hire a few staff members to > manage and monitor their firewalls (they expect to be dual-connected to > the Internet) and to develop new, secure firewall applications specific > to their business. > > I'm looking for some boilerplate that describes firewall (and related > systems) management tasks and skills as input to this staffing process. > If any of you have such text that you wouldn't mind sharing, please send > it to me by private mail. (If it's *really* good, send it to the list, > too, but I'm willing to do more editing and integration of fragments > than the average reader of this list.) > > Please don't send your resume (unless it contains useful input for a > position description)! I'm not the one who will be doing any hiring, and > I won't be forwarding prospective names to anyone who will. > > Thanks in advance for any input you can provide! I received the expected response: six folks who'd like a copy of whatever I come up with and no input! So I'll be undertaking to write such a beast. When it's done, I'll send it to this list, to the folks who send me explicit requests for it, and to anyone else who subsequently asks. The position description will be oriented to a large company with a highly developed IS infrastructure and very high security needs. Among the requirements is "separation of duties"--that is, it should be impossible for a single individual, including a firewall manager, to subvert the purpose of the firewall. Also, my client requires connections to multiple Internet service providers, 100% up time with two firewall sites in different states, and all alerts forwarded to a remote 7x24 operations group for escalation and dispatch. If you have less complex requirements, you better not hold off writing your own position description until mine is done, as it might not be so helpful to you. Contributions are still welcome, if only in the nature of "Don't forget that the firewall manager must be able to...". I'd like to get this together in a format I not embarrased to post within 2-3 weeks. Regards, "Steve" Stephen L. Arnold, Ph.D., Principal, Arnold Consulting Address 4138 Iroquois Drive, Madison, Wisconsin 53711-3701 U.S.A. Telephone +1 608 238 4850 Facsimile +1 608 238 4855 Internet Stephen.L.Arnold@Arnold.Com BITNET ARNOLD@WISCPSL Pager (800) Sky-Page, PIN 238-4850 From firewalls-owner Thu Apr 28 15:36:01 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA09889; Thu, 28 Apr 1994 15:36:01 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA09883; Thu, 28 Apr 1994 08:35:45 -0700 Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA17969; Thu, 28 Apr 94 11:34:57 -0400 Received: by cobalt.house.gov (AA03432); Thu, 28 Apr 94 11:35:19 -0700 Date: Thu, 28 Apr 94 11:35:19 -0700 From: Dorian Deane Message-Id: <9404281835.AA03432@cobalt.house.gov> To: Firewalls@GreatCircle.COM, Stephen.L.Arnold@Arnold.Com Subject: RE: Wanted: firewall manager position description Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > highly developed IS infrastructure and very high security needs. Among > the requirements is "separation of duties"--that is, it should be > impossible for a single individual, including a firewall manager, to > subvert the purpose of the firewall. Also, my client requires > "Steve" Stephen L. Arnold, Ph.D., Principal, Arnold Consulting "Including the firewall manager???" Ah, I see. You will kill him or her after the design is completed. Now I understand. But seriously, is that really possible? Without thinking too deeply about it, my initial reaction is that it's a bit like trying to play yourself in chess: it's fairly difficult to outsmart yourself. BTW, this question still applies even if you trust the designer %100 at the moment. (And obviously, if you trusted this person forever, then there would be no need to worry about this issue.) dorian From firewalls-owner Thu Apr 28 15:40:43 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA09941; Thu, 28 Apr 1994 15:40:43 GMT Received: from infoexp.express.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id IAA09934; Thu, 28 Apr 1994 08:40:27 -0700 Received: from snoopy.express.com (snoopy.express.com [199.74.247.4]) by infoexp.express.com (8.6.8/8.6.6) with ESMTP id IAA04223 for ; Thu, 28 Apr 1994 08:40:35 -0700 Received: from [199.74.247.5] (macsnoopy.express.com [199.74.247.5]) by snoopy.express.com (8.6.8/8.6.6) with SMTP id IAA17933 for ; Thu, 28 Apr 1994 08:40:46 -0700 Message-Id: <199404281540.IAA17933@snoopy.express.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Apr 1994 08:39:14 -0800 To: firewalls@GreatCircle.COM From: pzee@express.com (Philip J. Zee) Subject: Re: What is a firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On April 28, Paul Boots wrote: >Hi there, > >After getting interested in security issues I got >directed to this mailing list. > >Problem is, I don't know what a firewall is!!! > >Would somebody care to tell me please, what is it, >where can you get it, what do you pay for it etc... > >Please be so kind as to send any answers to my personal >mail address. Most people reading this probably allready >know what there talking about. > I am glad he asked this question. I am new here too. I kinda know what a firewall is, but not sure on the true meaning of it. I believe that there are more people like me or Paul on this mailing list would like to learn the answers too. Philip ____________________________________________________________________________ Philip J. Zee / / / Information Express / / / 3250 Ash St. o o o / / / Palo Alto, CA 94306 o o / o / / Main: (415) 494-8787 DID: (415) 812-3530 o /o /o / Internet: pzee@express.com / / / ____________________________________________________________________________ From firewalls-owner Thu Apr 28 11:24:35 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA18207; Thu, 28 Apr 1994 17:58:05 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA18198; Thu, 28 Apr 1994 10:57:57 -0700 Received: by relay.tis.com; id AA01151; Thu, 28 Apr 94 13:57:48 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma001138; Thu Apr 28 13:57:09 1994 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA25491; Thu, 28 Apr 94 13:55:44 EDT Date: Thu, 28 Apr 94 13:55:44 EDT From: Marcus J Ranum Message-Id: <9404281755.AA25491@tis.com> To: firewalls@GreatCircle.COM, pzee@express.com Subject: Re: What is a firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I am glad he asked this question. I am new here too. I kinda know what a >firewall is, but not sure on the true meaning of it. I believe that there >are more people like me or Paul on this mailing list would like to learn >the answers too. At the risk of seeming to blow my own horn, I'd like to point at a couple of documents on ftp.tis.com in pub/firewalls: pub/firewalls/firewalls-FAQ - Internet firewalls FAQ pub/firewalls/firewalls.ps.Z - Overview of Internet firewalls and design issues Also on research.att.com: dist/internet_security/gateway.ps mjr. From firewalls-owner Thu Apr 28 11:31:02 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA17822; Thu, 28 Apr 1994 17:33:28 GMT Received: from clark.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA17755; Thu, 28 Apr 1994 10:33:05 -0700 From: farsight@clark.net Received: (from farsight@localhost) by clark.net (8.6.9/8.6.9) id NAA03664; Thu, 28 Apr 1994 13:30:21 -0400 Date: Thu, 28 Apr 1994 13:30:20 -0400 (EDT) Subject: Re: What is a firewall To: "Philip J. Zee" cc: firewalls@GreatCircle.COM In-Reply-To: <199404281540.IAA17933@snoopy.express.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Thu, 28 Apr 1994, Philip J. Zee wrote: > On April 28, Paul Boots wrote: > > >Problem is, I don't know what a firewall is!!! > > > >Would somebody care to tell me please, what is it, > >where can you get it, what do you pay for it etc... > > I am glad he asked this question. I am new here too. I kinda know what a > firewall is, but not sure on the true meaning of it. I believe that there > are more people like me or Paul on this mailing list would like to learn > the answers too. > > Philip > You and anyone else who would like a mass of firewall docs may get them via a simple Veronica search available via Gopher. The search results are impressive, just on the work "firewall" without any further boolean parsing of the key word needed. Check it out! fs. From firewalls-owner Thu Apr 28 11:40:58 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA16985; Thu, 28 Apr 1994 17:30:30 GMT Received: from freenet3.carleton.ca by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA16855; Thu, 28 Apr 1994 10:30:02 -0700 Received: from localhost (xx247@localhost) by freenet3.carleton.ca (8.6.4/8.6.4) id NAA15738; Thu, 28 Apr 1994 13:30:22 -0400 From: "G.J.W. Hagenaars" Message-Id: <199404281730.NAA15738@freenet3.carleton.ca> Subject: Re: Wanted: firewall manager position description To: dorian@cobalt.house.gov (Dorian Deane) Date: Thu, 28 Apr 1994 13:30:22 -0400 (EDT) Cc: firewalls@greatcircle.com In-Reply-To: <9404281835.AA03432@cobalt.house.gov> from "Dorian Deane" at Apr 28, 94 11:35:19 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1221 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk % > Among % > the requirements is "separation of duties"--that is, it should be % > impossible for a single individual, including a firewall manager, to % > subvert the purpose of the firewall. % % > "Steve" Stephen L. Arnold, Ph.D., Principal, Arnold Consulting % % But seriously, is that really possible? Without thinking too deeply % about it, my initial reaction is that it's a bit like trying to % play yourself in chess: it's fairly difficult to outsmart yourself. There are mathematical solutions to this. It is possible to design a (mathematical) lock with n keys, and to open it you need a sufficienlty large subset m of those n keys (most of the time m = n/2 + 1 or larger). How you would _implement_ something like this so that it would be possible to _work_ with this situation is an entirely different matter. % BTW, this question still applies even if you trust the designer % %100 at the moment. (And obviously, if you trusted this person % forever, then there would be no need to worry about this issue.) It also keeps the designer from being sued as the one who broke into the system (if that has happened). (S)he can "only" be held responsible for not anticipating every attack. % dorian GJ From firewalls-owner Thu Apr 28 11:50:59 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id SAA18976; Thu, 28 Apr 1994 18:41:44 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id LAA18968; Thu, 28 Apr 1994 11:41:32 -0700 Message-Id: <199404281841.LAA18968@mycroft.GreatCircle.COM> To: Marcus J Ranum cc: firewalls@GreatCircle.COM, pzee@express.com Subject: Re: What is a firewall In-reply-to: Your message of Thu, 28 Apr 94 13:55:44 EDT Date: Thu, 28 Apr 1994 11:41:30 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Marcus J Ranum writes: # >I am glad he asked this question. I am new here too. I kinda know what a # >firewall is, but not sure on the true meaning of it. I believe that there # >are more people like me or Paul on this mailing list would like to learn # >the answers too. # # At the risk of seeming to blow my own horn, I'd like to point # at a couple of documents on ftp.tis.com in pub/firewalls: # # pub/firewalls/firewalls-FAQ - Internet firewalls FAQ # pub/firewalls/firewalls.ps.Z - Overview of Internet firewalls and # design issues # # Also on research.att.com: # dist/internet_security/gateway.ps There is a collection of firewalls-related papers available for anonymous FTP from FTP.GreatCircle.COM, directory pub/firewalls/papers. Marcus' FAQ is also there, file pub/firewalls/FAQ. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Thu Apr 28 12:01:04 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA12595; Thu, 28 Apr 1994 17:01:03 GMT Received: from ll.mit.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA12582; Thu, 28 Apr 1994 10:00:50 -0700 Received: by ll.mit.edu (4.1/LL-1.3) id AA10274; Thu, 28 Apr 94 12:56:41 EDT Date: Thu, 28 Apr 94 12:56:41 -0400 From: kevinmac@ll.mit.edu (Kevin McElearney) Message-Id: <9404281256.AA21067@LL.MIT.EDU> To: firewalls@GreatCircle.COM Subject: SUMMARY: Dual Homed Attached Printers (PROBLEMS?) Cc: lind@ll.mit.edu Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Original Query: > Does anyone see security problems in connecting a Apple Laserwriter printer to > networks both inside a firewall and outside. One connection would be to it's > ethernet port (outside) and the other would be to it's Appletalk port (inside) > which in turn connects to a GatorBox. > > Would it be possible (practical or theoretical) for an *outside* user to do > any of the following to a PostScript printer: > > o Route packets through the printer to the internal network > o Capture / redirect any printouts from the inside out > o any others? > > The following I know > > o Printer can be corrupted > o I can set the PS password for serverdict commands The answer is, "I wouldn't do that". Most people commented on the insecurity of the PS printer password (not to mention setting it breaks other things). Most mentioned the relative ease in capturing / redirect any printouts. Denial of service would also be a snap. My real concern was the possibility of routing packets through the printer. No one was clear whether or not this could be done but given it *is* a computer with multiple interfaces... better safe than sorry... Thanks go to: Andy Finkenstadt Granville Moore Jeff Edelheit Andrew Klossner David Forthoffer Kevin McElearney ----------------------------------------------------------------------------- MIT Lincoln Laboratory Phone: (617) 981-3556 244 Wood Street, MS C157 Fax: (617) 981-0782 Lexington, MA 02173-9108 EMail: kevinmac@ll.mit.edu From firewalls-owner Thu Apr 28 12:11:03 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id RAA16836; Thu, 28 Apr 1994 17:29:59 GMT Received: from bwh.harvard.edu by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA16714; Thu, 28 Apr 1994 10:29:32 -0700 Received: from miles.bwh.harvard.edu (miles.bwh.harvard.edu [134.174.81.54]) by bwh.harvard.edu (8.6.4/8.6.4) with ESMTP id NAA13342; Thu, 28 Apr 1994 13:29:28 -0400 From: Adam Shostack Received: from localhost (adam@localhost) by miles.bwh.harvard.edu (8.6.4/8.6.4) id NAA00489; Thu, 28 Apr 1994 13:29:27 -0400 Message-Id: <199404281729.NAA00489@miles.bwh.harvard.edu> Subject: RE: Wanted: firewall manager position description To: dorian@cobalt.house.gov (Dorian Deane) Date: Thu, 28 Apr 94 13:29:26 EDT Cc: firewalls@greatcircle.com In-Reply-To: <9404281835.AA03432@cobalt.house.gov>; from "Dorian Deane" at Apr 28, 94 11:35 am Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk | > "Steve" Stephen L. Arnold, Ph.D., Principal, Arnold Consulting: | > highly developed IS infrastructure and very high security needs. Among | > the requirements is "separation of duties"--that is, it should be | > impossible for a single individual, including a firewall manager, to | > subvert the purpose of the firewall. Also, my client requires Dorian: | "Including the firewall manager???" Ah, I see. You will kill him or | her after the design is completed. Now I understand. | | But seriously, is that really possible? Without thinking too deeply | about it, my initial reaction is that it's a bit like trying to | play yourself in chess: it's fairly difficult to outsmart yourself. I can see a large multinational, say a bank, wanting to have a 'two key' requirement to make changes on the main firewall, and might also have an audit trail that goes somewhere other than the firewall manager for (post facto) approval. Anyone can be comprimised if the stakes are high enough. The way to address this is to first raise the cost of corrupting your system (by requiring the bribery/blackmail of two or more people instead of one) and then to create an audit trail so you can see that theres a problem. Adam -- Adam Shostack adam@bwh.harvard.edu Politics. From the greek "poly," meaning many, and ticks, a small, annoying bloodsucker. Have you signed the anti-Clipper petition? From firewalls-owner Thu Apr 28 19:35:10 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA19679; Thu, 28 Apr 1994 19:35:10 GMT Received: from oxygen.house.gov by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA19665; Thu, 28 Apr 1994 12:34:59 -0700 Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/3.2.083191-) id AA19565; Thu, 28 Apr 1994 15:24:12 -0400 Date: Thu, 28 Apr 1994 15:24:12 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9404281924.AA19565@oxygen.house.gov> To: firewalls@GreatCircle.COM Subject: RE: Wanted: firewall manager position description Cc: dorian@oxygen.house.gov Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk :From dorian Thu Apr 28 11:35:18 1994 > highly developed IS infrastructure and very high security needs. Among > the requirements is "separation of duties"--that is, it should be > impossible for a single individual, including a firewall manager, to > subvert the purpose of the firewall. Also, my client requires > "Steve" Stephen L. Arnold, Ph.D., Principal, Arnold Consulting :But seriously, is that really possible? Without thinking too deeply :about it, my initial reaction is that it's a bit like trying to :play yourself in chess: it's fairly difficult to outsmart yourself. : :dorian I think my colleague has been working within resource limits too long :-) The classic solution to this problem is requiring two people to each perform the same actions before it takes effect. That is why 2 keys are necessary in an ICBM silo. Of course, (human) management methods are necessary to prevent collusion. For an Internet firewall application, two firewall are necessary in series. Whatever one person lets through his firewall can only get as far as the next firewall unless it has been done there also. The more trustworthy person should be responsible for the internal firewall and monitoring (unsuccessful) attempts that could only reach that layer if the outside firewall had unauthorized capabilities enabled. I do not endorse this lack of trust of the firewall manager, since so many other actions (how hard is it to set up a modem, or copy a floppy) could undermine the security perimeter. Remember, if it is sufficiently inconvenient just about anybody will subvert the security you put in place. (Brent says this 20 times a day, so I did it for him this time :-) From firewalls-owner Thu Apr 28 20:40:48 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id UAA20244; Thu, 28 Apr 1994 20:40:48 GMT Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id NAA20238; Thu, 28 Apr 1994 13:40:39 -0700 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id NAA17747; Thu, 28 Apr 1994 13:42:26 -0700 Received: from avalle.insoft.com by insoft1.insoft.com (4.1/RHP-1.0) id AA02169; Thu, 28 Apr 94 15:25:07 EDT Received: by avalle.insoft.com (5.0/SMI-SVR4) id AA00348; Thu, 28 Apr 1994 15:21:05 +0500 Date: Thu, 28 Apr 1994 15:21:05 +0500 From: francis@avalle.insoft.com (John [Francis] Stracke) Message-Id: <9404281921.AA00348@avalle.insoft.com> To: Firewalls@GreatCircle.COM In-Reply-To: Dorian Deane's message of Thu, 28 Apr 94 11:35:19 -0700 <9404281835.AA03432@cobalt.house.gov> Subject: Wanted: firewall manager position description Content-Length: 822 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> impossible for a single individual, including a firewall manager, to >> subvert the purpose of the firewall. Also, my client requires > >"Including the firewall manager???" Ah, I see. You will kill him or >her after the design is completed. Now I understand. Perhaps there need to be two managers, who have to work together to change anything. /===========================================================================\ |John (Francis) Stracke | My opinions are my own. | |InSoft, Inc. |==================================================| |Mechanicsburg, PA | If you're going to walk on thin ice, | |francis@insoft.com | you might as well *dance*! | \===========================================================================/ From firewalls-owner Thu Apr 28 21:04:25 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA20348; Thu, 28 Apr 1994 21:04:25 GMT Received: from bagout.BELL-ATL.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA20342; Thu, 28 Apr 1994 14:04:15 -0700 Received: by bagate.BELL-ATL.COM (O) id ; Thu, 28 Apr 94 17:06 EDT Received: by bagate.BELL-ATL.COM (I1) id ; Thu, 28 Apr 94 16:56 EDT Received: from localhost (bjp@localhost) by is000796.bell-atl.com (8.6.5/8.6.4) with SMTP id QAA21086; Thu, 28 Apr 1994 16:51:12 -0400 Message-Id: <199404282051.QAA21086@is000796.bell-atl.com> To: johns@oxygen.house.gov (John Schnizlein) cc: firewalls@GreatCircle.COM, dorian@oxygen.house.gov Subject: Re: Wanted: firewall manager position description In-reply-to: Your message of "Thu, 28 Apr 94 15:24:12 EDT." <9404281924.AA19565@oxygen.house.gov> Date: Thu, 28 Apr 94 16:51:11 -0400 From: Brad Passwaters Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > The classic solution to this problem is requiring two people to each > perform the same actions before it takes effect. > That is why 2 keys are necessary in an ICBM silo. > Of course, (human) management methods are necessary to prevent collusion. > > For an Internet firewall application, two firewall are necessary in series. > Whatever one person lets through his firewall can only get as far as the next > firewall unless it has been done there also. The more trustworthy person shou ld > be responsible for the internal firewall and monitoring (unsuccessful) attemp ts > that could only reach that layer if the outside firewall had unauthorized > capabilities enabled. I thought about this too but it appears to me that the inner firewall person could still compromise security. The two firewill admins have to understand how each others stuff works. (or they can at least infer based on given data). So the inner firewall person could replace valid secure services with trojan versions. Classic easy example - EXT-firewall permits SMTP traffic - admin of INT-firewall replaces sendmail with something that spawns a shell. You need to find a system where NO one person/administrator can compromise it. Looks to me to require a lot of thought. Brad Passwaters bjp@nsm.bell-atl.com Network Software Management (BAINET) bf5t0p6@bell-atl.com (OSIN) Voice:301-236-6221 FAX:301-236-1061 ------------------------------------------------------------------------------- "...and he never wondered what was right or wrong, he just knew, he just knew" David Crosby and Phil Collins "HERO" From firewalls-owner Thu Apr 28 14:31:12 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA20555; Thu, 28 Apr 1994 21:19:05 GMT Received: from ALABAMA.CF.CS.YALE.EDU by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA20540; Thu, 28 Apr 1994 14:18:43 -0700 Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU via SMTP; Thu, 28 Apr 1994 17:18:54 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.67b/res.client.cf-3.7) id AA12825; Thu, 28 Apr 1994 17:18:53 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199404282118.AA12825@SPARKY.CF.CS.YALE.EDU> To: firewalls@GreatCircle.COM, namedroppers@nic.ddn.mil Cc: long-morrow@CS.YALE.EDU Subject: Denial of service attacks on Domain Name Servers (DNS) possible? Date: Thu, 28 Apr 94 17:18:51 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm aware that there was a bit of talk recently on improving DNS security by using RSA (or similar) public key technology for authentication. But has any thought (or effort) been given (or are there any current methods) to protect DNS servers from denial of service attacks? I would think (for a number of reasons listed below) that domain nameservers would be particularly vulnerable to such abuse. Let me tell you how I got started thinking about this. I was pondering the problem that has come up recently about how some type of 'peer' [pun] pressure could be put upon a site or access provider who was letting someone run amok on the Internet (ala 'MAKE MONEY FAST' or 'GREEN CARD LOTTERY'). I began to bluesky and thought that the best way was not via the current method of flooding the abuser and their site admins with E-Mail or any other application layer protocol (as these can be filtered out easily) but an attack at the transport or network layer would be the most damaging. It would be best to use a connectionless protocol to be truly devastating (the speed it takes TCP to set up a new connection is probably reason enough to disqualify it). So we are left with ICMP and UDP basically. I've seen systems bombarded by ping on the network before. It is not a pretty sight. But if I wanted to impair (if not totally disable a site) I would want to go for the jugular and strike at a service that would most affect a site, a service that they couldn't do without. Many sites run their nameservers in a DMZ (on a bastion host), or at least behind a screening router protecting them from the Internet. And many of them block most UDP ports. But if they run a nameserver they have to let UDP port 53 in. Also a few sites are totally dependent on their provider (who runs their nameservice for them). It would seem to be fairly trivial to write up a fairly small C program to send UDP messages in rapid succession to port 53 on a machine anywhere on the Internet. Is there any protection against a sheer 'quantity' (ie., a 100MHz PowerPC machine blasting across a LAN->T1->Internet) denial of service attack? And while just filling a 512 byte datagram with junk and aiming it at server port 53 may mildly disrupt a nameserver (until it recognizes it as junk and discards it), filling in the DNS query fields with actual values and making the nameserver do (hopefully somewhat random) make-work is likely to make it churn a lot. I've seen a nameserver really banged into submission before (by accident, not a malicious attack). One obvious method of trying to protect yourself from this type of attack would be to have as many secondary nameservers for a domain as possible. Unfortunately, you can only list a finite number as being authoritative (or the DNS reply message will be too large and will be truncated, right? Which would be an error.) - it appears to be a max around 7 or 8 depending on how many IP (interface) addresses are enclosed as well. You can set up a different set of internal nameservers which users can use on the enterprise network (and you are likely to do this if you have a corporate firewall anyway) so net life could continue reasonably well internally. But, potentially, all havoc could be taking place outside the firewall (no E-Mail and possibly other services coming in) with your nameservers effectively disabled. And obviously you (or your Internet provider) can choke off such messages at an appropriate router once the problem has become known and the site identified. But I'm interested in any defense mechanisms DNS may (or may not) have. Comments? ObDisclaimer: I definitely don't advocate or endorse the use of a net nuisance tool as described above for any purpose. --- H. Morrow Long Long-Morrow@CS.Yale.EDU {harvard,decvax}!yale!Long-Morrow From firewalls-owner Thu Apr 28 15:07:47 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id VAA20767; Thu, 28 Apr 1994 21:51:23 GMT Received: from clark.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id OAA20760; Thu, 28 Apr 1994 14:51:10 -0700 From: farsight@clark.net Received: (from farsight@localhost) by clark.net (8.6.9/8.6.9) id RAA26947; Thu, 28 Apr 1994 17:52:18 -0400 Date: Thu, 28 Apr 1994 17:52:18 -0400 (EDT) Subject: RE: Wanted: firewall manager position description To: John Schnizlein cc: firewalls@GreatCircle.COM, dorian@oxygen.house.gov In-Reply-To: <9404281924.AA19565@oxygen.house.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Thu, 28 Apr 1994, John Schnizlein wrote: > :From dorian Thu Apr 28 11:35:18 1994 > > > highly developed IS infrastructure and very high security needs. Among > > the requirements is "separation of duties"--that is, it should be > > impossible for a single individual, including a firewall manager, to > > subvert the purpose of the firewall. Also, my client requires > > > "Steve" Stephen L. Arnold, Ph.D., Principal, Arnold Consulting > > :But seriously, is that really possible? Without thinking too deeply > :about it, my initial reaction is that it's a bit like trying to > :play yourself in chess: it's fairly difficult to outsmart yourself. > : > :dorian > > I think my colleague has been working within resource limits too long :-) > > The classic solution to this problem is requiring two people to each > perform the same actions before it takes effect. > That is why 2 keys are necessary in an ICBM silo. > Of course, (human) management methods are necessary to prevent collusion. > > For an Internet firewall application, two firewall are necessary in series. > Whatever one person lets through his firewall can only get as far as the next > firewall unless it has been done there also. The more trustworthy person should > be responsible for the internal firewall and monitoring (unsuccessful) attempts > that could only reach that layer if the outside firewall had unauthorized > capabilities enabled. > > I do not endorse this lack of trust of the firewall manager, since so many > other actions (how hard is it to set up a modem, or copy a floppy) could > undermine the security perimeter. Remember, if it is sufficiently inconvenient > just about anybody will subvert the security you put in place. > (Brent says this 20 times a day, so I did it for him this time :-) > This entire argument is interesting and essentially comes to this: a large company need only have in place whatever security they feel comfortable with, and not more -- until a decidedly significant breach occurs. Those individuals closest to temptation (read money, whether it be information they might be able to resell or property or accounts, whatever has monetary value) need continual auditing of their activities yet these same individuals need to be trusted -- somewhat of an uncomfortable situation for such people in the private sector. Treat them like gold? Pay them extremely well? Not too likely a scenario, huh? After all, they are just a programmer who works in the data processing department, right! Recalling my experiences in the Army, working as an EE on a classified site handling nukes, being paid next to nothing and treated as such, I was never tempted in any way -- becuse of the enormous number of checks and balances and audits -- it kept everyone straight, besides the minor fact that we were all soldiers serving our country. But of course that wasn't the private sector, was it? :-) fs. From firewalls-owner Thu Apr 28 16:01:05 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA22908; Thu, 28 Apr 1994 22:54:12 GMT Received: from crl.crl.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA22902; Thu, 28 Apr 1994 15:54:01 -0700 Received: by crl.crl.com id AA27605 (5.65c/IDA-1.5 for firewalls@greatcircle.com); Thu, 28 Apr 1994 15:53:05 -0700 Date: Thu, 28 Apr 1994 15:46:08 -0700 (PDT) From: "Joseph W. Stroup" Subject: Re: Denial of service attacks on Domain Name Servers (DNS) possible? To: H Morrow Long Cc: firewalls@greatcircle.com, namedroppers@nic.ddn.mil, long-morrow@CS.YALE.EDU In-Reply-To: <199404282118.AA12825@SPARKY.CF.CS.YALE.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I understand that there are alot of smart people who get this group but, while you do add a disclaimer - You stimulate people's gray matter on the subject. Some things are just better left alone. Its not up to us to judge who will and who won't conform to what your or my ideas of operation should be. You mention the Green Card Asshole. And thats just what the guy was. But, it was not the fault of the provider. Sort of like selling guns and the holding the merchant liable for the customer doing the crime. I would suggest a more concentrated effort be put forth into writing a "little C program" to deal with the problem as it happens. There are answers to everything - its just that we may not like what we hear. Sooner or later ads will come to the net , along with other things. Defend against it, write code around it or whatever. Otherwise you might have gov't regulation and the phone company as you only provider. I guess it just hits me wrong when you wake up people to the fact that a sites DNS can be shot to hell. Most of us know that, we just don't talk about distructive solutions to shitty problems. Here's to the Green Card Lawyer - Maybe he will be deported - Soon ! Joseph Stroup From firewalls-owner Thu Apr 28 16:10:59 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id WAA22927; Thu, 28 Apr 1994 22:55:25 GMT Received: from wintermute.imsi.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id PAA22921; Thu, 28 Apr 1994 15:55:14 -0700 Received: from relay.imsi.com by wintermute.imsi.com id SAA23785 for ; Thu, 28 Apr 1994 18:55:36 -0400 Received: from snark.imsi.com by relay.imsi.com id SAA21290 for ; Thu, 28 Apr 1994 18:55:36 -0400 Received: from localhost by snark.imsi.com (4.1/SMI-4.1) id AA16340; Thu, 28 Apr 94 18:55:35 EDT Message-Id: <9404282255.AA16340@snark.imsi.com> To: Firewalls@greatcircle.com Subject: RE: Wanted: firewall manager position description In-Reply-To: Your message of "Thu, 28 Apr 1994 14:31:04 PDT." <199404282131.OAA20608@mycroft.GreatCircle.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 28 Apr 1994 18:55:34 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: Stephen.L.Arnold@Arnold.Com > > The position description will be oriented to a large company with a > highly developed IS infrastructure and very high security needs. Among > the requirements is "separation of duties"--that is, it should be > impossible for a single individual, including a firewall manager, to > subvert the purpose of the firewall. 1) Any site that requires a full time firewall administrator either has a grossly misdesigned firewall or a firewall administrator so stupid as to be useless. Even a company with tens of thousands of workstations can have no conceivable need for a full time firewall administrator. Once the machines are in place, there isn't much to do. Whats the guy supposed to do all day long? Going to have a human reading log files instead of a computer doing it? Thats silly. 2) Long ago I learned you cannot solve personel problems with technology. If your firewall administrator isn't trustworthy, he can do lots of things, like cause physical damage to your premises, take out crucial information in his shoe, etc. I can understand the desire to restrict the set of trusted individuals. It is not, however, possible to completely restrict this set. I speak as a person who consults for companies in the financial industry with literally billions of dollars in exposure to technical sabotage. I'm very paranoid about security. However, you do have to realize that some things can't be stopped. Several days ago, a manager at my current client asked me about filtering electronic mail to stop position information from being leaked that way. I pointed out that there was no point in doing that because dozens of phones are available in quiet places in the office. I also noted that the information could be taken out in a dozen other ways, including someone's memory. The trick is to hire trustworthy people and know that you have a recourse with your employees that you don't have with outsiders -- you know who they are and can fire them or even have them jailed if they cause real damage. Perry From firewalls-owner Thu Apr 28 17:21:04 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA23997; Thu, 28 Apr 1994 23:55:16 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA23989; Thu, 28 Apr 1994 16:55:04 -0700 Message-Id: <199404282355.QAA23989@mycroft.GreatCircle.COM> To: "Joseph W. Stroup" cc: H Morrow Long , firewalls@greatcircle.com, namedroppers@nic.ddn.mil Subject: Re: Denial of service attacks on Domain Name Servers (DNS) possible? In-reply-to: Your message of Thu, 28 Apr 1994 15:46:08 -0700 (PDT) Date: Thu, 28 Apr 1994 16:55:00 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can we please avoid a flamewar over this topic or the meta-topic of whether or not to discuss blue-sky potential vulnerabilities in the services we all use? -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Thu Apr 28 17:31:06 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA23939; Thu, 28 Apr 1994 23:50:41 GMT Received: from london.micrognosis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA23931; Thu, 28 Apr 1994 16:50:26 -0700 Received: by london.micrognosis.com (4.1/NAR-Gateway) id AA20616; Fri, 29 Apr 94 00:50:01 BST Received: from zeus.london.micrognosis.com(192.83.165.17) by midas via smap (V1.0mjr) id sma020613; Fri Apr 29 00:49:28 1994 Received: from moria by zeus.london.micrognosis.com (4.1/SMI-4.1) id AA03495; Fri, 29 Apr 94 00:49:24 BST From: nreadwin@london.micrognosis.com (Neil Readwin) Received: by moria (4.1//ident-1.0) id AA08968; Fri, 29 Apr 94 00:49:22 BST Message-Id: <9404282349.AA08968@moria> Subject: Re: Denial of service attacks on Domain Name Servers (DNS) possible? To: nettech@crl.com (Joseph W. Stroup) Date: Fri, 29 Apr 1994 00:49:22 +0100 (BST) Cc: firewalls@GreatCircle.COM In-Reply-To: from "Joseph W. Stroup" at Apr 28, 94 03:46:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1053 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Joseph W. Stroup writes: > I guess it just hits me wrong when you wake up people to the fact that a > sites DNS can be shot to hell. Most of us know that, we just don't talk > about distructive solutions to shitty problems. The problem is not ads on the net, the problem is attacks on the DNS. I think that with sufficient time (and motivation) to write the code, I can defend my site against pretty much any attack that involves sending packets to it. That leaves two obvious holes. The first is an attack on the DNS that prevents people finding out what my IP address is. The second is an attack on the routers that send those packets to me - ie trying to change the routing tables so packets don't get routed to the right place. If anyone has any suggestions on where the defenses against these two can be discussed I would be interested to know. Something tells me that firewalls isn't quite the right place. Neil. -- nreadwin@london.micrognosis.com Phone: +1 718 273 8234 Anything is a cause for sorrow that my mind or body has made From firewalls-owner Thu Apr 28 17:41:00 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id XAA23819; Thu, 28 Apr 1994 23:44:52 GMT Received: from mycroft.GreatCircle.COM by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA23812; Thu, 28 Apr 1994 16:44:42 -0700 Message-Id: <199404282344.QAA23812@mycroft.GreatCircle.COM> To: kevinmac@ll.mit.edu (Kevin McElearney) cc: firewalls@GreatCircle.COM Subject: Re: SUMMARY: Dual Homed Attached Printers (PROBLEMS?) In-reply-to: Your message of Thu, 28 Apr 94 12:56:41 -0400 Date: Thu, 28 Apr 1994 16:44:38 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk kevinmac@ll.mit.edu (Kevin McElearney) writes: # Original Query: # # > Does anyone see security problems in connecting a Apple Laserwriter printer to # > networks both inside a firewall and outside. One connection would be to it's # > ethernet port (outside) and the other would be to it's Appletalk port (inside) # > which in turn connects to a GatorBox. # > # # My real concern was the possibility of routing packets through the printer. # No one was clear whether or not this could be done but given it *is* a computer # with multiple interfaces... better safe than sorry... Several of the current Apple printers (and presumably those from other vendors) let you TELNET into them, and once logged in TELNET out from them. They may have other capabilities that I just haven't stumbled across yet; I haven't looked very hard. -Brent -- Brent Chapman | Great Circle Associates | Call or email for info about Brent@GreatCircle.COM | 1057 West Dana Street | upcoming Internet Security +1 415 962 0841 | Mountain View, CA 94041 | Firewalls Tutorial dates From firewalls-owner Fri Apr 29 03:52:48 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA08568; Fri, 29 Apr 1994 10:06:28 GMT Received: from ecmwf.co.uk by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA08562; Fri, 29 Apr 1994 03:06:14 -0700 Received: from helena.ecmwf.co.uk by ecmwf.co.uk (4.1/SMI-4.1-MHS-7.0) id AA17897; Fri, 29 Apr 94 11:05:14 BST for firewalls@GreatCircle.COM From: syj@ecmwf.co.uk (Jean-Philippe Martin-Flatin) Message-Id: <9404291105.ZM13763@helena> Date: Fri, 29 Apr 1994 11:05:12 +0100 X-Mailer: Z-Mail (2.1.5 20sep93) To: firewalls@GreatCircle.COM Subject: Security aspects of Gopher, WAIS & WWW/Mosaic Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I've got to make a presentation about the security aspects of world wide information servers such as Gopher, WAIS and WWW/Mosaic. I'd be specially interested in the security holes closed over the past year in these products, as well as the known threats still in them. I've got plenty of material for the telnet URL hole in Mosaic 2.2 and lynx 2.2, but very little for the hole closed in Gopher 1.12 last summer or for the use of chroot in Gopher 1.13 or 2.014, and nothing at all for WAIS and freeWAIS. If you have written or read about this recently, I would be most grateful if you could send me a pointer. Please email direct to syj@ecmwf.co.uk. If interest is shown, I'll post a summary. Thanks in advance Jean-Philippe From firewalls-owner Fri Apr 29 04:01:14 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA08159; Fri, 29 Apr 1994 09:39:07 GMT Received: from relay1.pipex.net by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id CAA08153; Fri, 29 Apr 1994 02:38:54 -0700 From: R.P.Handy@ste0411.wins.icl.co.uk X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=GB/; Relayed; Fri, 29 Apr 1994 10:38:46 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Fri, 29 Apr 1994 10:35:12 +0100 Date: Fri, 29 Apr 1994 10:35:12 +0100 X400-Originator: R.P.Handy@ste0411.wins.icl.co.uk X400-Recipients: firewalls@GreatCircle.COM X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0411 0000042100003187] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3187 Message-ID: <"3187*/I=RP/S=Handy/OU=ste0411/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: firewalls@GreatCircle.COM Subject: FIREWALL CONSULTANCY REQUIRED (UK) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk FIREWALL CONSULTANCY REQUIRED (UK) Is anyone interested in providing some firewall consultancy in the UK? World Integrated Network Services Ltd (WINS) has an Internet connection on which we would like a basion-type firewall. The requirements would involve (draft only, subject to change): A bastion system, providing proxy services. The usual services; telnet, ftp, SMTP, news, gopher, mosaic etc. Possibly an anonymous ftp server. Possibly World Wide Web server. The contract would involve the setting up of the firewall, providing full documentation & training to enable WINS staff to administer the service and possibly ongoing support. If you would like to discus this further, please contact: Richard Handy, WINS e-mail: r.p.handy@ste0411.wins.icl.co.uk Tel: 0438 313361 x2019 From firewalls-owner Fri Apr 29 04:11:14 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id KAA08980; Fri, 29 Apr 1994 10:42:59 GMT Received: from gatekeeper.mcimail.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id DAA08965; Fri, 29 Apr 1994 03:42:36 -0700 Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA24915; Fri, 29 Apr 94 05:43:33 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa10702; 29 Apr 94 10:34 GMT Date: Fri, 29 Apr 94 05:39 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Eric Fleischman To: brian To: ipv4 ale To: big internet To: firewalls Subject: Re: NATs Message-Id: <40940429103904/0003858921NA3EM@mcimail.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This was one the ALE list, but really belongs elsewhere... Appologies in advance to those that get multiple copies. Brian said: >>Semantics check: when I write NAT I mean IP-level address translation. >>Application level gateways are different and of course they work >>(they can even do application protocol translation if you want). >>They are however a pain to operate - we used to run a file transfer >>gateway, and we still have to run mail and terminal emulation gateways. Eric said: >Check. We have the same viewpoint once again and the only sticking point >was in wording/communication of that viewpoint. In my own mind I had >written off NATs as being impractical to implement but that the idea was >great. Thus, I had mentally substituted for that term (NAT) an entity >which is somewhat practical to implement (application layer gateways) and >which does the same thing. I prefer the term "NAT" because it represents >what is LOGICALLY happening. When Noel first told me about NATs, I got excited. Something that might be easier than application gateways, read firewalls. But I studied the NATs issues. And I listened in on the FIREWALLS list for a couple of months and came to an important realization: Network level security is worthless as long as there is application insecurity. And thus there will always be application gateways to institute corporate security policies. Yes I am fighting VERY hard to allow all employees to have public EMail, but nFrom firewalls-owner Fri Apr 29 16:33:15 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id QAA11909; Fri, 29 Apr 1994 16:33:15 GMT Received: from uu.psi.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id JAA11901; Fri, 29 Apr 1994 09:33:01 -0700 Received: by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA10229 for ; Fri, 29 Apr 94 12:13:00 -0400 Received: from asgaard.rocket.com (asgaard.ARPA) by earth.rocket.com (4.1/3.2.083191-Olin Aerospace Company - Redmond Wa) id AA23664; Fri, 29 Apr 94 07:40:18 PDT Organization: Olin Aerospace Company Telephone: (206)885-5000 Fax: (206)882-5804 Received: by asgaard.rocket.com (4.1/SMI-4.1) id AA15079; Fri, 29 Apr 94 07:40:17 PDT Date: Fri, 29 Apr 94 07:40:17 PDT Message-Id: <9404291440.AA15079@asgaard.rocket.com> To: 0003858921@mcimail.com Cc: ericf@atc.boeing.com, brian@dxcoms.cern.ch, ipv4-ale@ftp.com, big-internet@munnari.oz.au, firewalls@greatcircle.com In-Reply-To: <40940429103904/0003858921NA3EM@mcimail.com> Subject: Re: NATs From: "Philip J. Nesser" Us-Snail: 15825 Leary Way NE #306, Redmond WA, 98052 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Date: Fri, 29 Apr 94 05:39 EST >From: "Robert G. Moskowitz" <0003858921@mcimail.com> >When Noel first told me about NATs, I got excited. Something that might be >easier than application gateways, read firewalls. >But I studied the NATs issues. And I listened in on the FIREWALLS list for >a couple of months and came to an important realization: >Network level security is worthless as long as there is application >insecurity. I don't think anyone will argue with you on that issue. >So all of you IETFers, continue the network level security work. That has >an important place. But DO NOT DELUDE YOURSELVES! It will not make the >internet secure anymore than C2 has made UNIX secure. The application >writers need to be indoctrinated also. Perhaps after there is a major >security incident at some big university or company that is all C2 UNIX and >IPng authenticated due to an application level attach, then we will raise >our eyes and tackle the last great frontier, the network applications. I don't think anyone is deluding themselves. Security is an issue at all levels. Just because some application writer doesn't take the time to do it right doesn't invalidate the validity of the work on making another layer as secure as possible. People, especially in the IETF, are taking security concerns much more seriously than ever before. Putting a deadbolt lock on your front door doesn't keep burglers out if you have open windows, but that doesn't mean its a bad idea to have one put in. >Bob ---> Phil From firewalls-owner Fri Apr 29 19:05:21 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA17738; Fri, 29 Apr 1994 19:05:21 GMT Received: from ormail.intel.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA17732; Fri, 29 Apr 1994 12:05:15 -0700 Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0pwxrF-000MNUC; Fri, 29 Apr 94 12:04 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 29 Apr 94 12:04:17 PST Date: Fri, 29 Apr 94 12:04:17 PST From: Gary L Morris Message-ID: <940429120417_1@ccm.hf.intel.com> To: firewalls@greatcircle.com Subject: Add to mail list for firewalls. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Text item: Text_1 Please add to mail list for firewalls. From firewalls-owner Fri Apr 29 19:06:40 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA17763; Fri, 29 Apr 1994 19:06:40 GMT Received: from MediaVis.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA17757; Fri, 29 Apr 1994 12:06:33 -0700 Received: from mvimail.mediavis.com by MediaVis.com (Media Vision, Inc.) with SMTP (1.37.109.4/16.2) id AA05340; Fri, 29 Apr 94 12:07:10 -0700 Received: by MVIMAIL.MEDIAVIS.COM with Microsoft Mail id <2DC15AE3@MVIMAIL.MEDIAVIS.COM>; Fri, 29 Apr 94 12:07:15 PDT From: Alan Millar To: firewalls-owner , "Philip J. Zee" Cc: firewalls Subject: Re: What is a firewall Date: Fri, 29 Apr 94 12:06:00 PDT Message-Id: <2DC15AE3@MVIMAIL.MEDIAVIS.COM> Encoding: 28 TEXT X-Mailer: Microsoft Mail V3.0 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > On April 28, Paul Boots wrote: > > > > >Problem is, I don't know what a firewall is!!! > > > > > >Would somebody care to tell me please, what is it, > > >where can you get it, what do you pay for it etc... > > > > I am glad he asked this question. I am new here too. I kinda know what a > > firewall is, but not sure on the true meaning of it. I believe that there > > are more people like me or Paul on this mailing list would like to learn > > the answers too. > > > > Philip > > I hate to be the "RTFM" rain on the parade, but... Did you retrieve and read the FAQ and/or peruse the archives you were informed about when you joined the list? It has a good summary of many of the important terms and concepts. If you didn't read the message you got when you joined the list, send the command "info firewalls" to "majordomo@greatcircle.com" and read the reply. - Alan From firewalls-owner Fri Apr 29 19:31:03 1994 Return-Path: Received: from localhost by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id TAA17854; Fri, 29 Apr 1994 19:31:03 GMT Received: from gatekeeper.mcimail.com by mycroft.GreatCircle.COM (8.6.5/SMI-4.1/Brent-931103) id MAA17848; Fri, 29 Apr 1994 12:30:56 -0700 Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA20281; Fri, 29 Apr 94 14:32:20 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af19704; 29 Apr 94 19:22 GMT Date: Fri, 29 Apr 94 14:26 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: firewalls Subject: Number of processes for TIS TELNET proxy Message-Id: <41940429192614/0003858921NA4EM@mcimail.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk How many processes are involved with TIS's toolkit TELNET proxy? One or One per connected user. Important question for planning for a VERY LARGE firewall... Oh, how much memory per connected user as well. Thanks. Bob Moskowitz Chrysler Corp (313) 758-8212