From Firewalls-Owner Tue May 4 14:02:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22451; Tue, 4 May 93 14:02:27 GMT Received: from lego.gsfc.nasa.gov (lego-f.gsfc.nasa.gov) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22444; Tue, 4 May 93 07:02:21 PDT Received: from lance1.gsfc.nasa.gov by lego.gsfc.nasa.gov (5.61/1.35) id AA13911; Tue, 4 May 93 10:02:41 -0400 Received: by lance1.gsfc.nasa.gov (4.1/SMI-4.1) id AA08361; Tue, 4 May 93 10:07:13 EDT Date: Tue, 4 May 93 10:07:13 EDT From: dagher@lance1.gsfc.nasa.gov (Joe) Message-Id: <9305041407.AA08361@lance1.gsfc.nasa.gov> To: firewalls@GreatCircle.COM Subject: Please add me to list Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk **************************************************************************** * JOSEPH DAGHER * (301) 286-2521 * * BENDIX FIELD ENGINEERING CORP. * dagher@lance1.gsfc.nasa.gov * * GODDARD SPACE FLIGHT CENTER/CODE 543.8* jdagher@zaphod.gsfc.nasa.gov * * BUILDING 1 ROOM 10 * dagher@trust.gsfc.nasa.gov * **************************************************************************** From Firewalls-Owner Wed May 5 13:18:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02524; Wed, 5 May 93 13:18:42 GMT Received: from argos.ims.disa.mil by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02517; Wed, 5 May 93 06:18:08 PDT Received: from jcdbs.2000.disa.mil by argos.ims.disa.mil with SMTP ; Wed, 5 May 93 09:17:19 EST Received: from cdbs8.disa.mil by jcdbs.2000.disa.mil (4.1/SMI-4.1) id AA03928; Wed, 5 May 93 09:21:29 EDT Date: Wed, 5 May 93 09:21:29 EDT From: nolfb@jcdbs.2000.disa.mil (Bill Nolf) Message-Id: <9305051321.AA03928@jcdbs.2000.disa.mil> To: Firewalls-Digest@GreatCircle.COM Subject: setup of firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I need to make sure my network is isolated from the Internet but want to able to get mail, telnet, ftp, etc. I've been reading this list for sometime but most of it goes over my head. Can someone supply me with step-by-step procedure on how I go about setting up the initial firewall and insuring it works. My firewall server/Internet connection is a Sun 1+ running SunOs 4.1.3. The rest of network consists of other Sun's including 2's, ELC's and SLC's. This request is critical, mgmt s threating to physically seperate on Internet server from the rest of the network, unless I can come up with something. I have to insure that other servers are "safe" from the outside. Thanks, in advance. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Bill Nolf nolfb@jcdbs.2000.disa.mil Logicon 703-318-1074 ex-202 1831 Wiehle Ave. Reston, VA 22090 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From Firewalls-Owner Wed May 5 16:21:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03082; Wed, 5 May 93 16:21:47 GMT Received: from info.cren.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03074; Wed, 5 May 93 09:21:36 PDT Received: by info.cren.net (4.1/1.0-BITnet NIC); id AA01754; Wed, 5 May 93 12:16:22 EDT Date: Wed, 5 May 1993 12:15:23 -0400 (EDT) From: "Marco A. Hernandez" Subject: Re: setup of firewall To: Bill Nolf Cc: Firewalls-Digest@GreatCircle.COM In-Reply-To: <9305051321.AA03928@jcdbs.2000.disa.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Greetings: This is an interesting question, also, if anyone can reccomend reference books or texts. Please post replies as I'm sure others (myself for one) are interested .. Cheers, Marco Hernandez From Firewalls-Owner Wed May 5 16:58:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03325; Wed, 5 May 93 16:58:14 GMT Received: from Spectrum.CMC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03318; Wed, 5 May 93 09:58:00 PDT Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA23464; Wed, 5 May 93 09:58:21 PDT Newsgroups: list.firewalls Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: setup of firewall Message-Id: <1993May5.165754.23400@spectrum.CMC.COM> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA References: <9305051321.AA03928@jcdbs.2000.disa.mil> Date: Wed, 5 May 93 16:57:54 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In article <9305051321.AA03928@jcdbs.2000.disa.mil> nolfb@jcdbs.2000.disa.mil (Bill Nolf) writes: >I need to make sure my network is isolated from the Internet but want to able >to get mail, telnet, ftp, etc. I've been reading this list for sometime but >most of it goes over my head. >Can someone supply me with step-by-step procedure >on how I go about setting up the initial firewall and insuring it works. >My firewall server/Internet connection is a Sun 1+ running SunOs 4.1.3. >The rest of network consists of other Sun's including 2's, ELC's and SLC's. >This request is critical, mgmt is threating to physically seperate on >Internet server from the rest of the network, unless I can come up with >something. I have to insure that other servers are "safe" from the outside. Quickly, back to basics. What is the problem that you are trying to solve ? If you aren't very clear about that question, you can run around in circles forever. Each site has unique issues, and there is no universal solution, because the only completely secure site is a disconnected site. For most of us, the problem to be solved is a balance between the benefit of information flow - mail, FTP, news, etc - and the threat of unauthorized logins (FTPs, YP services, remote execution etc) from nodes "on the outside". It is assumed that the people inside are trustworthy (albeit often careless). The common element in the solutions discussed in this forum is a carefully monitored demarcation zone between the inside and the outside networks. In its traditional form, this demarcation zone could take the form of a unix machine with connections to both networks, but configured to NOT act as a router. With such a dual-homed host as the only connection between the "inside" and the "outside" network, you no longer have to worry whether each owner of a PC inside has secured it; that machine is simply not reachable from the outside. This allows you to focus your efforts on securing the dual-homed machine. That task is not trivial, but it sounds like you have some handle on that already. The main update on this technology, is that the DMZ system no longer has to be dual-homed. The isolation function can be put into a router that sits between the site's LAN and the outside WAN. This router needs to have an IP packet filtering feature. If you configure this filter as follows, the configuration is logically equivalent to the diual-homed host mentioned above: allow packets from DMZ.SITE.NET to anywhere allow packets from anywhere to DMZ.SITE.NET discard all other packets. Besides allowing you to temporarily open holes in the firewall for special needs (General Horton is here this week, and he needs to be able to connect to Sugar Mountain, you hear me boy ?) this also allows selective access to other services, such as a name server: allow packets from DMZ.SITE.NET to anywhere allow packets from anywhere to DMZ.SITE.NET allow packets from Horton.PC.SITE.NET to net SUGAR-MOUNTAIN allow packets from net SUGAR-MOUNTAIN to Horton.PC.SITE.NET allow packets from anywhere to NS.SITE.NET port 53 allow packets from NS.SITE.NET port 53 to anywhere discard all other packets. Most modern routers have these features. The least expensive that I know of, is the Rockwell NetHopper, which is $1995 quantity one list price in its basic configuration with one ethernet and one V.32bis/V.42bis async modem (yes, the modem is included). -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256 From Firewalls-Owner Wed May 5 17:30:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03579; Wed, 5 May 93 17:30:22 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03552; Wed, 5 May 93 10:30:00 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA17951; Thu, 6 May 93 03:30:39 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9305051730.AA17951@coombs.anu.edu.au> Subject: Re: setup of firewall To: nolfb@jcdbs.2000.disa.mil (Bill Nolf) Date: Thu, 6 May 93 3:30:37 EST Cc: firewalls@GreatCircle.COM (Firewall Mailing List) In-Reply-To: <9305051321.AA03928@jcdbs.2000.disa.mil>; from "Bill Nolf" at May 5, 93 9:21 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In some email I received from Bill Nolf, Sie wrote: > > > I need to make sure my network is isolated from the Internet but want to able > to get mail, telnet, ftp, etc. I've been reading this list for sometime but > most of it goes over my head. > Can someone supply me with step-by-step procedure > on how I go about setting up the initial firewall and insuring it works. > My firewall server/Internet connection is a Sun 1+ running SunOs 4.1.3. > The rest of network consists of other Sun's including 2's, ELC's and SLC's. > This request is critical, mgmt > s threating to physically seperate on Internet server from the rest of the > network, unless I can come up with something. I have to insure that other > servers are "safe" from the outside. Ok, what needs access needs to the Internet, just the machine you're sitting using as the "firewall" ? If so, you can achieve a reasonable amount of security by NOT running any routed/gated software there and turning IP forwarding off inside the kernel (there was a note posted somewhere about what is required to do this for SunOS but I can't remember where or have it handy). With that done, you use static routes on the firewall and you're fine - some of the time - if your firewall is secure. Darren From Firewalls-Owner Wed May 5 17:52:45 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03718; Wed, 5 May 93 17:52:45 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03711; Wed, 5 May 93 10:52:30 PDT Received: from spool.uu.net (via localhost.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11986; Wed, 5 May 93 13:53:22 -0400 Message-Id: <9305051753.AA11986@relay1.UU.NET> Received: from technet.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 135119.14288; Wed, 5 May 1993 13:51:19 EDT Received: by technet.macom.com (15.11/15.6) id AA00601; Wed, 5 May 93 13:47:41 edt From: Matthew Cilento Subject: Re: setup of firewall To: cren.net!mah@uunet.uu.net (Marco A. Hernandez) Date: Wed, 5 May 93 13:47:40 EDT Cc: nolfb@jcdbs.2000.disa.mil, Firewalls-Digest@GreatCircle.COM In-Reply-To: ; from "Marco A. Hernandez" at May 5, 93 12:15 (noon) Reply-To: mtc@technet.macom.com Mailer: Elm [revision: 64.9] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > This is an interesting question, also, if anyone can reccomend reference > books or texts. Please post replies as I'm sure others (myself for one) > are interested .. I concur! Regards, Matt ______________________________________________________________________________ Matthew Cilento, Corporate R & D, M/S L3 | EMAIL:mtc@technet.macom.com 100 Chelmsford St., P.O. Box 3294 | PHONE:(508) 453 3100 ext 4610 M/A-COM, INC. Lowell, MA 01853-3294 | FAX: (508) 453 3023 From Firewalls-Owner Wed May 5 19:54:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04514; Wed, 5 May 93 19:54:10 GMT Received: from nwnexus.wa.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04506; Wed, 5 May 93 12:53:44 PDT Received: from eldec.com by nwnexus.wa.com with SMTP id AA25651 (5.65c/IDA-1.4.4 for ); Wed, 5 May 1993 12:53:41 -0700 Received: from unix11 by eldec.com (4.1/SMI-4.1) id AA05680; Wed, 5 May 93 12:55:37 PDT Message-Id: <9305051955.AA05680@eldec.com> Received: from corp211 by unix11 with SMTP (16.8/16.2) id AA28806; Wed, 5 May 93 12:52:39 -0700 Received: by corp211 (1.37.109.4/16.2) id AA04220; Wed, 5 May 93 12:52:38 -0700 From: Michael Godsey Subject: Re: setup of firewall To: nolfb@jcdbs.2000.disa.mil (Bill Nolf) (Bill Nolf) Date: Wed, 5 May 93 12:52:38 PDT Cc: Firewalls-Digest@GreatCircle.COM In-Reply-To: <9305051321.AA03928@jcdbs.2000.disa.mil>; from "Bill Nolf" at May 5, 93 9:21 am Phone: (206) 743-8699 Mailer: Elm [revision: 70.85] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > I need to make sure my network is isolated from the Internet but want to able > to get mail, telnet, ftp, etc. I've been reading this list for sometime but > most of it goes over my head. Can someone supply me with step-by-step procedure > on how I go about setting up the initial firewall and insuring it works. My firewall server/Internet connection is a Sun 1+ running SunOs 4.1.3. The rest of network consists of other Sun's including 2's, ELC's and SLC's. This request is critical, mgmt > s threating to physically seperate on Internet server from the rest of the network, unless I can come up with something. I have to insure that other servers are "safe" from the outside. > > Thanks, in advance. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Bill Nolf nolfb@jcdbs.2000.disa.mil > Logicon 703-318-1074 ex-202 > 1831 Wiehle Ave. > Reston, VA 22090 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > When you get this info, can you forward me a copy? I'm in a similar situation - the guy who set up our firewall machine has since left the company, and most of that knowledge went with him in his head! So, nobody left behind has much knowledge of the topic, and the info you receive could halep us a lot... Thanks! -- Mike Godsey ( mgodsey@eldec.com ) (206) 743-8699 From Firewalls-Owner Wed May 5 19:58:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04536; Wed, 5 May 93 19:58:58 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04528; Wed, 5 May 93 12:58:27 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA00671; Wed, 5 May 93 16:00:18 EDT Date: Wed, 5 May 93 16:00:18 EDT From: Marcus J Ranum Message-Id: <9305052000.AA00671@TIS.COM> To: firewalls@GreatCircle.COM Subject: papers on firewalls for FTP - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I recently presented a re-edited version of my overview of firewalls paper at SANS-II in April. The paper and accompanying slides are available for anonymous FTP from moink.nmsu.edu in ~ftp/firewalls: fwalls-slides.ps.Z - slides fwalls.ps.Z - paper All constructive comments/suggestions/criticisms gratefully accepted. mjr. From Firewalls-Owner Wed May 5 20:04:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04611; Wed, 5 May 93 20:04:21 GMT Received: from chsun.eunet.ch (chsun.chuug.ch) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04600; Wed, 5 May 93 13:03:50 PDT Received: by chsun.eunet.ch (5.65c8/1.34) id AA03083; Wed, 5 May 1993 22:04:39 +0200 Date: Wed, 5 May 1993 22:04:39 +0200 From: hn@eunet.ch (Heinz Naef) Message-Id: <199305052004.AA03083@chsun.eunet.ch> To: firewalls@GreatCircle.COM Subject: Re: setup of firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There was a remarkable tutorial article titled "Building Internet Firewalls", written by Smoot Carl-Mitchell and John S. Quarterman, in UnixWorld, February 1992, pp. 93. Regards, Heinz Naef, Nexos AG, Frobenstrasse 66, CH-4053 Basel, Switzerland E-mail: whna@nexos.com - Phone: ++4161 283-5500 - Fax: ++4161 271-9600 From Firewalls-Owner Thu May 6 15:53:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01851; Thu, 6 May 93 15:53:25 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01844; Thu, 6 May 93 08:53:13 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA00307; Fri, 7 May 93 01:54:03 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9305061554.AA00307@coombs.anu.edu.au> Subject: Non-IP firewalling. To: firewalls@GreatCircle.COM (Firewall Mailing List) Date: Fri, 7 May 93 1:54:02 EST Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk While IP might be the most common protocol and cause the most problems for people, does much firewall software provide options for firewalling other protocols such as OSI CLNP, Ethernet, DECNet, AppleTalk, IPX, etc ? Of these, I'm most interested in support for CLNP firewalling since it has some presence on the InterNet and on the NSF backbone. Darren From Firewalls-Owner Thu May 6 16:55:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02204; Thu, 6 May 93 16:55:54 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02197; Thu, 6 May 93 09:55:45 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA16179; Thu, 6 May 93 12:57:45 EDT Date: Thu, 6 May 93 12:57:45 EDT From: Marcus J Ranum Message-Id: <9305061657.AA16179@TIS.COM> To: avalon@coombs.anu.edu.au, firewalls@GreatCircle.COM Subject: Re: Non-IP firewalling. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >While IP might be the most common protocol and cause the most problems >for people, does much firewall software provide options for firewalling >other protocols such as OSI CLNP, Ethernet, DECNet, AppleTalk, IPX, etc ? Depends on how the firewall's done. Lots of the code in the DEC SEAL actually originated from an attempt to make it easier for the DECnet addicts to work in an IP environment. Since the DECnet stack presents a socket to an application, something like a telnet gateway doesn't really care if it's been invoked via IP from inetd or via DECnet from the DECnet listener. The nntp tunnel I posted here a while back was originally done for DECnet news readers to tunnel to IP-running news servers. That being said, some protocols have hidden features in the application layer that are extremely painful (and therefore expensive) to deal with. The DECnet login facility, (dlogind under ULTRIX and "set host" under VMS) does all manner of negotiation like telnetd and rlogind do - but it's not as openly documented, and there aren't source examples lying around to work from. That increases the expense of talking to such applications to a degree that most folks aren't willing to bother - it's cheaper to put IP on your VAX than to write a DECnet login<->telnet gateway from scratch. There do exist firewalls (the SFE, for example) that focus on providing protocol gatewaying - but they're always going to be somewhat limited, since you have to write glue for each protocol you want to talk to. SFE is terminal traffic only. One can only write so much glue. mjr. From Firewalls-Owner Fri May 7 04:49:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04502; Fri, 7 May 93 04:49:44 GMT Received: from access.digex.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04329; Thu, 6 May 93 19:58:19 PDT Received: by access.digex.net id AA29919 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Thu, 6 May 1993 22:53:28 -0400 Date: Thu, 6 May 1993 22:53:28 -0400 From: "Robert B. Reinhardt" Message-Id: <199305070253.AA29919@access.digex.net> To: firewalls@GreatCircle.COM Subject: PAPER: An Architectural Overview of UNIX Network Security (V4) Cc: breinhar%srg@uunet.uu.net Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This is VERSION 4 of my occassional paper on the architecture of UNIX network security and related methods...this will be the final draft posted. (20 pages TEXT). Previous versions of this were posted to security related groups and the firewalls mailing list several times from August - November 1992. I received a good deal of positive response and encouragement to continue work on the paper and to submit it for publication. I have attempted to make some of the recommended improvements to the paper, adding sections 1, 2, and the beginning of section 3--as well as some changes to availability of packages suggested by many of their respective authors. I respectfully submit this final draft to all of you for any constructive comments and suggestions you may have. I intend to submit this work for publication by May 15, 1993. My thanks in advance (and in areers) to all of you who have offered your suggestions to improve this paper, since the original version in August '92. P.S. - My apologies for not including all the most recent stuff such as Tripwire and the TAMU tools release, there wasn't enough time. ---Bob Reinhardt (breinhar@access.digex.com) =======================cut here================================ An Architectural Overview of UNIX Network Security February 18, 1993 Robert B. Reinhardt breinhar@access.digex.com ARINC Research Corporation 2551 Riva Road Annapolis, MD 21401 1. Introduction The goal of this paper is to present my concept of a UNIX network security architecture based on the Internet connectivity model and Firewall approach to implementing security. This paper defines several layers of a firewall, which depict the layers of vulnerability. This paper also provides some subjective comments on some of the most widely known tools and methods available to protect UNIX networks today, plus a brief discussion of the threat and the risk. The list of tools and methods that I present in this paper were chosen loosely on the basis of the following: (a) My attempt to find at least one, maybe several examples of a tool or method designed to address a part of the architectural model (some duplication or overlap is accepted); (b) my preference to discuss tools that are well-known and/or part of the public domain (this is not a strict rule, although I did not purposely seek out commercial products); and (c) I hoped to find tools that had a recent paper written by the tools' author, for the reader to use as detailed reference beyond the scope of this document. Nothing in this paper should be construed as a product endorsement. I apologize in advance to the authors of these tools and methods; since I am only presenting a brief overview, I cannot do justice to a comprehensive description of them. I also apologize to any authors whom I may have left out of this discussion; it was not intentional. The reader should check the availability information that accompanies each tool and obtain additional information prior to proceding with any plans or implementation. Of course, there is no warranty expressed or implied in this paper. 2. Risk, Threat, and Vulnerability This section presents a general overview of the risk and the threat to the security of your network. These are general statements that apply to almost every network. A complete analysis of your network's risk, threat, and vulnerability should be done in order to assess in detail the requirements of your own network. 2.1 Risk The risk is the possibility that an intruder may be successful in attempting to access your local-area network via your wide-area network connectivity. There are many possible effects of such an occurence. In general, the possibility exists for someone to: READ ACCESS. Read or copy information from your network. WRITE ACCESS. Write to or destroy data on your network (including planting trojan horses, viruses, and back-doors). DENIAL OF SERVICE. Deny normal use of your network resources by consuming all of your bandwidth, CPU, or memory. 2.2 Threat The threat is anyone with the motivation to attempt to gain unauthorized access to your network or anyone with authorized access to your network. Therefore it is possible that the threat can be anyone. Your vulnerability to the threat depends on several factors such as: MOTIVATION. How useful access to or destruction of your network might be to someone. TRUST. How well you can trust your authorized users and/or how well trained are your users to understand what is acceptable use of the network and what is not acceptable use, including the consequences of unacceptable use. 2.3 Vulnerability Vulnerability essentially is a definition of how well protected your network is from someone outside of your network that attempts to gain access to it; and how well protected your network is from someone within your network intentionally or accidently giving away access or otherwise damaging the network. Motivation and Trust (see Threat, section 2.2) are two parts of this concern that you will need to assess in your own internal audit of security requirements and policy, later I will describe some references that are available to help you start this process. The rest of this paper is a presentation of my concept of the architectural model of UNIX network security (the focus of this paper). This is geared toward connectivity to the Internet (or Internet Protocol connectivity in general), employing the FIREWALL method of reducing vulnerability to the risks and the threat. 3. UNIX Network Security Architecture For each of the layers in the UNIX Network Security Architecture (UNIX/NSA) model below, there is a subsection that follows that gives a brief description of that layer and some of the most widely used tools and methods for implementing security controls. I am using the ISO/OSI style of model since most people in the UNIX community are familiar with it. This architecture is specifically based on UNIX Internet connectivity, but it is probably general enough to apply to overall security of any network methodology. One could argue that this model applies to network connectivity in general, with or without the specific focus of UNIX network security. Layer Name Functional Description LAYER 7 POLICY POLICY DEFINITION AND DIRECTIVES LAYER 6 PERSONNEL PEOPLE WHO USE EQUIPMENT AND DATA LAYER 5 LAN COMPUTER EQUIPMENT AND DATA ASSETS LAYER 4 INTERNAL-DEMARK CONCENTRATOR - INTERNAL CONNECT LAYER 3 GATEWAY FUNCTIONS FOR OSI 7, 6, 5, 4 LAYER 2 PACKET-FILTER FUNCTIONS FOR OSI 3, 2, 1 LAYER 1 EXTERNAL-DEMARK PUBLIC ACCESS - EXTERNAL CONNECT The specific aim of this model is to illustrate the relationship between the various high and low level functions that collectively comprise a complete security program for wide-area network connectivity. They are layered in this way to depict (a) the FIREWALL method of implementing access controls, and (b) the overall transitive effect of the various layers upon the adjacent layers, lower layers, and the collective model. The following is a general description of the layers and the nature of the relationship between them. After this brief discussion of what each layer is, the next section of this paper will discuss examples of common methods and tools used to implement some of your options at each level, or at least try to tell you where to find out how to get started. Note that there may be some overlap between the definitions of the various levels, this is most likely between the different layers of the FIREWALL itself (layers 2 and 3). The highest layer [ 7 - POLICY ] is the umbrella that the entirety of your security program is defined in. It is this function that defines the policies of the organization, including the high level definition of acceptable risk down to the low level directive of what and how to implement equipment and procedures at the lower layers. Without a complete, effective, and implemented policy, your security program cannot be complete. The next layer [ 6 - PERSONNEL ] defines yet another veil within the bigger umbrella covered by layer 7. The people that install, operate, maintain, use, and can have or do otherwise have access to your network (one way or another) are all part of this layer. This can include people that are not in your organization, that you may not have any administrative control over. Your policy regarding personnel should reflect what your expectations are from your overall security program. Once everything is defined, it is imperitive that personnel are trained and are otherwise informed of your policy, including what is and is not considered acceptable use of the system. The local-area network layer [ 5 - LAN ] defines the equipment and data assets that your security program is there to protect. It also includes some of the monitor and control procedures used to implement part of your security policy. This is the layer at which your security program starts to become automated electronically, within the LAN assets themselves. The internal demarkation layer [ 4 - INTERNAL DEMARK ] defines the equipment and the point at which you physically connect the LAN to the FIREWALL that provides the buffer zone between your local- area network (LAN) and your wide-area network (WAN) connectivity. This can take many forms such as a network concentrator that homes both a network interface for the FIREWALL and a network interface for the LAN segment. In this case, the concentrator is the internal demarkation point. The minimum requirement for this layer is that you have a single point of disconnect if the need should arise for you to spontaneosly separate your LAN from your WAN for any reason. The embedded UNIX gateway layer [ 3 - GATEWAY ] defines the entire platform that homes the network interface coming from your internal demark at layer 4 and the network interface going to your packet filtering router (or other connection equipment) at layer 3. The point of the embedded UNIX gateway is to provide FIREWALL services (as transparent to the user or application as possible) for all WAN services. What this really is must be defined in your policy (refer to layer 1) and illustrates how the upper layers overshadow or are transitive to the layers below. It is intended that the UNIX gateway (or server) at this layer will be dedicated to this role and not otherwise used to provide general network resources (other than the FIREWALL services such as proxy FTP, etc.). It is also used to implement monitor and control functions that provide FIREWALL support for the functions that are defined by the four upper ISO/OSI layers (1-Application, 2-Presentation, 3- Session, 4-Transport). Depending on how this and the device in layer 2 is implemented, some of this might be merely pass-thru to the next level. The configuration of layers 3 and 2 should collectively provide sufficient coverage of all 7 of the functions defined by the ISO/OSI model. This does not mean that your FIREWALL has to be capable of supporting everything possible that fits the OSI model. What this does mean is that your FIREWALL should be capable of supporting all of the functions of the OSI model that you have implemented on your LAN/WAN connectivity. The packet filtering layer [ 2 - FILTER ] defines the platform that homes the network interface coming from your gateway in layer 3 and the network interface or other device such as synchronous or asynchronous serial communication between your FIREWALL and the WAN connectivity at layer 1. This layer should provide both your physical connectivity to layer 1 and the capability to filter inbound and outbound network datagrams (packets) based upon some sort of criteria (what this criteria needs to be is defined in your policy). This is typically done today by a commercial off-the- shelf intelligent router that has these capabilities, but there are other ways to implement this. Obviously there is OSI link-level activity going on at several layers in this model, not exclusively this layer. But, the point is that functionally, your security policy is implemented at this level to protect the overall link- level access to your LAN (or stated more generally; to separate your LAN from your WAN connectivity). The external demarkation layer [ LAYER 1 ] defines the point at which you connect to a device, telephone circuit, or other media that you do not have direct control over within your organization. Your policy should address this for many reasons such as the nature and quality of the line or service itself and vulnerability to unauthorized access. At this point (or as part of layer 2) you may even deploy yet another device to perform point to point data link encryption. This is not likely to improve the quality of the line, but certainly can reduce your vulnerability to unauthorized access. You also need to be concerned about the dissemination of things at this level that are often considered miscellaneous, such as phone numbers or circuit IDs. Illustration of the UNIX/NSA Model ------------------------------------------------------------------ | POLICY | ------------------------------------------------------------------ | | --------------------------------------------------- | PERSONNEL | --------------------------------------------------- | | --------------------------------- | LAN | --------------------------------- Enet | Enet | ----------------- | INTERNAL-D | ----------------- Enet | Enet | ----------------- UNIX server with two Ethernet interfaces and | GATEWAY-SERVER| custom software and configuration to implement ----------------- security policy (proxy services, auditing). Enet | Enet | ----------------- | PACKET-FILTER | cisco IGS router with access lists ----------------- X.25 | | ----------------- | EXTERNAL-D | leased DID line to WAN service ----------------- | | + Public Access + 3.1 PUBLIC or NON-PRIVATE CONNECTIVITY This layer of the model characterizes all external physical connectivity to your network. This normally includes equipment and telephone lines that you do not own or do not have control over. The point of illustrating this is to show this part of the connectivity as part of the overall model. At some point at this layer, equipment that you do own or have control of will connect to the external or public network. Your own policy and implementation must take the dynamics of this connectivity into account. 3.2 ROUTER (FIREWALL PHYSICAL LAYER) This layer of the model depicts the point at which your physical connectivity and your data stream become one. Without going into hysterics about all of what a router is and does; the point is that at this layer, your electrical connectivity, which contains encapsulated data in some form, becomes information. Your router will decode the electrical signals from the physical connectivity and turn it into packets of encapsulated data for any one of various networking protocols. Within this packet of information is contained the source address, destination address, protocol ID, the datagram itself, etc. Many routers available today include the capability to create access control lists (ACL) for either one or both of the outgoing and the incoming data interfaces [1][5]. This normally includes the capability to filter out or allow in packets based upon source address, destination address, protocol (such as TCP, UDP, ICMP, etc.) and specific port numbers (TCP and UDP). This provides you the flexibility to design your own network access control policy, enforced at the router, before access to your internal network resources is required or granted. In this way, routers alone are often used to provide the firewall functionality. While the router ACL capability offers a big advantage, it should not be your only protection because, basically the router only provides protection at the first three levels of the OSI model (Physical, Data Link, and Network layers). The rest of the layers of this firewall model discuss ways to address functional security of the other four OSI layers (Transport, Session, Presentation, and Application). Availability: I only have personal experience with CISCO routers, however I've been told that Wellfleet and Proteon routers also have this feature. There may be other vendors as well, but they probably all implement it a little differently. 3.3 DUAL-HOMED UNIX GATEWAY SERVER (FIREWALL LOGICAL LAYER) This layer of the model illustrated the point at which your various IP packets (to and from the router) are used by the network operating system (such as TCP/IP under UNIX) to provide the services identified in the upper four layers of the OSI model. Of course, this UNIX server is actually doing work at the bottom three OSI layers also, in order to communicate with: (a) the router on one side of the server, and (b) the local-area network on the other side of the server. At this point the router is already implementing your security policy for the bottom three OSI layers, now it's up to your dual- homed [10] UNIX server (acting as a gateway) to implement your security policy relating to functions of the network for the upper four OSI layers. This can mean a lot of things. Depending on what your security policy says you are supposed to enforce, what you do at this point varies. The following tools and methods are example of some of the tools and methods (functionality) available today: 3.3.1 TCP Wrapper The "TCP WRAPPER" tool [2] provides monitoring and control of network services. Essentially, what happens is that you configure inetd on your dual-homed gateway to run the TCP WRAPPER software whenever certain services (ports) are connected to. Depending on how you configure TCP WRAPPER, it will then LOG information about the connection and then actually start the intended SERVER program that the connection was intended for. Since you have the source to the tool, you can modify it to do more depending on what your needs are. For example, you may want TCP WRAPPER to connect the user to a proxy service instead of the actual program, then have your proxy software handle the transaction in whatever way your security requirements demand. Availability: This is available from several sources, but to ensure that you get the most recent copy that CERT has verified, you should use anonymous FTP to retrieve it from cert.org in ~/pub/tools/tcp_wrappers/tcp_wrappers.*. 3.3.2 SOCKS library and sockd The "sockd" and "SOCKS Library" [3] provide another way to implement a "TCP Wrapper." It is not intended to make the system it runs on secure, but rather to centralize ("firewall") all external internet services. The sockd process is started by inetd whenever a connection is requested for certain services, and then only allows connections from approved hosts (listed in a configuration file). The sockd also will LOG information about the connection. You can use the Socks Library to modify the client software to directly utilize the sockd for outgoing connections also, but this is described as very tedious and of course requires you to have the source to those client programs. Availability: The socks package, which in addition to including both the daemon and the library, has a pre-modified FTP client and finger client; it is available via anonymous FTP from s1.gov in ~/pub as socks.tar.Z. Contact the authors for more information. David Koblas (koblas@netcom.com) or Michelle R. Koblas (mkoblas@nas.nasa.gov). 3.3.3 Kernel_Wrap for SunOS RPC via Shared Libraries Essentially this is a wrapper for SunOS daemons that use RPC [4], such as portmap, ypserv, ypbind, ypupdated, mountd, pwdauthd, etc. To utilize this, you must have SunOS 4.1 or higher and must have the capability to rebuild your shared libraries (but, you don't need the source to your entire system). Essentially what happens is that you modify the function calls that the kernel uses to establish RPC connections, such as accept(), recvfrom() and recvmsg(). Since these calls are maintained in the shared libraries, you have access to modify them without rewriting the kernel. Availability: The secured C library package to implement this is available via anonymous FTP from eecs.nwu.edu in ~/pub/securelib. 3.3.4 Swatch Simple WATCHER [6] is really two things, it is a program used to parse through the myriad of LOG data generated by the various security programs, in particular "syslog." But, it's more than that. It is fully configurable with triggers (actions), so that while it is continuously monitoring the LOG in "real-time," it can take actions based upon certain high-priority events that you tell it to watch for. To get full use of this, you will need to modify your network service daemons such as ftpd and telnetd so that enhanced logging is added to syslog, to feed SWATCH. Availability: The SWATCH source and documentation is available via anonymous FTP from sierra.stanford.edu in ~/pub/sources. 3.3.5 Controlled Access Point (CAP) This is more of a method or protocol definition than a specific product. CAP [7] provides a network mechanism intended to reduce the risk of: password guessing, probing for well-known accounts with default passwords, trusted host rlogin, and password capture by network snooping. It is really a design for a variation or enhancement to the general firewall approach to connecting two or more networks. In the paper describing this there is an example of two local nets, one a secure segment with an authentication service, and the other an unsecure segment. Both communicate with each other via a CAP, while there is a router for communication to public networks connected on the unsecure side of the CAP. The CAP is essentially a router with additional functionality to detect incoming connection requests, intercept the user authentication process, and invoke the authentication server. Availability: Unknown. Contact the authors for more information. J. David Thompson (thompsond@orvb.saic.com) and Kate Arndt (karndt@mitre.org). 3.3.6 Mail Gateway This is more of a procedure than a software package (although there are packages designed just to do this). I included this to maintain continuity with what I'm trying to illustrate in this paper. This really should be applied to all network services that require external connectivity (meaning any communication over non-private or non-secure channels). In the simplest implementation of this, you configure your router to filter packets so that all mail traffic (SMTP protocol for example) is only allowed to and from one host, the "Mail Gateway." Likewise, your DNS and MTA software will need to be configured for this as well. 3.3.7 Tty Wrapper This is one of my pet ideas. I have not seen something like this around, and I'll probably never have time to develop it. But, essentially this would be like "TCP Wrapper," only it is designed specifically for serial communications. After that, we will need a "Pseudo-Tty Wrapper," (something more than just filtering out the telnet port) but that is for another day. 3.3.8 HSC-Gatekeeper The HSC-Gatekeeper from Herve' Schauer Consultants [8], is a complete solution to both layers 1 and 2 of this firewall model. It consists of a thorough firewall methodology and authentication server, providing pass-thru FTP and TELNET services. The author (Herve Schauer) noted that HSC-Gatekeeper is alone to be able to offer fully transparent authentication for these services. I have not had personal experience with HSC's products, so I cannot make a conclusive statement about it other than to comment that the description of it in HSC's paper "An Internet Gatekeeper" (available in the USENIX Proceedings) depicts it (IMHO) as a very comprehensive solution. Availability: For more information, contact Herve Schauer via e-mail at Herve.Schauer@hsc-sec.fr. 3.3.9 AT&T Inet Since I discussed HSC's firewall solution, I thought it only fair to mention AT&T's INET Gateway. For a complete description of AT&T's internal solution, you should read Bill Cheswick's paper [9] "The Design of a Secure Internet Gateway." For additional information, contact the author via e-mail at ches@research.att.com. I do not believe that AT&T is in the business of selling this solution to anyone, but the paper describes in good detail how it was done. It should provide the puritan firewaller additional depth to the problems and possible solutions to an Internet firewall approach. 3.4 COMPUTERS ON THE LOCAL-AREA NETWORK This layer of the model depicts the place where you you are potentially at the greatest risk. The previous layers discussed ways to protect access to this layer of the network. This layer includes all of you local-area network, workstations, file servers, data bases, and other network resources. This is also the point at which your user community sits at their desks and use the network. There are several things to be concerned about here, access to this layer in the first place notwithstanding. Just because you think you have protected and may be monitoring access to this layer within the previous layers, does not mean that use of computers and other resources within your local-area network should become a free for all. Again, this depends on what you identify in your own particular security policy but, at this layer you should do some routine checking for possible breaches of your firewall that would leave its mark at this layer and pay close attention to effective password handling, etc. This is also the layer of this model at which you want to concern yourself with training your users, after all this is where they can potentially make their mistakes (and harm your network). 3.4.1 Computer Oracle and Password System (COPS) COPS is a UNIX security status checker. Essentially what it does is check various files and software configurations to see if they have been compromised (edited to plant a trojan horse or back door), and checks to see that files have the appropriate modes and permissions set to maintain the integrity of your security level (make sure that your file permissions don't leave themselves wide open to attack/access). Many vendors of UNIX are now bundling a security status checker with the OS, usually under the nomenclature of a "C2" or "trusted system." You may still find that this package has more features than your canned package. Compare them. Additional Comments: The current version of COPS (1.04) makes a limited attempt to detect bugs that are posted in CERT advisories. Also, it has an option to generate a limited script that can correct various security problems that are discovered. Dan also offers a quick hint that should easily get you started using COPS. After you have unarchived the COPS package, perform the following steps: './reconfig', 'make', and './cops -v -s . - b bit_bucket'. -- There is a lot of README documentation included if you need more help. Availability: COPS can be retrieved via anonymous FTP from cert.org in ~/pub/tools/cops. 3.4.2 Chkacct Chkacct [11] is a COPS for the ordinary user. This tool is made available to the users to run, or it is run for them once per day. It will do an integrity check on the status of files in their own account and then mail them the results (such as "Dear user: Your .rhosts file is unsafe"). This package can help make your users more aware of security controls and raise their level of participation in the program. Availability: Chkacct is distributed with the COPS package (>= COPS 1.04), for additional information contact shabby@mentor.cs.purdue.edu. 3.4.3 Crack Crack helps the security administrator identify weak passwords by checking for various weaknesses and attempting to decrypt them. If Crack can figure out your password, then you must choose a better password. It is very likely that a determined intruder will be able to get the password too (using similar techniques, or the Crack program itself, since it is publicly available). Availability: Crack is available via anonymous FTP from cert.org in ~/pub/tools/crack/crack_4.1-tar.Z. 3.4.4 Shadow The shadow password suite of programs [12] replaces the normal password control mechanisms on your system to remove the encrypted password from the publicly readable file /etc/passwd and hides them in a place that only this program has permission to read. It consists of optional, configurable components, provides password aging to force users to change their passwords once in awhile, adds enhanced syslog logging, and can allow users to set passwords up to a length of sixteen characters. Many vendors of UNIX are now bundling a shadow password suite with the OS, usually under the nomenclature of a "C2" or "trusted system." You may still find that this package has more features than your canned package. Compare them. Availability: Shadow is available from USENET archives which store the comp.sources.misc newsgroup. Distribution is permitted for all non-commercial purposes. For more information contact the author, John F. Haugh III (jfh@rpp386.cactus.org). 3.4.5 Passwd+ Passwd+ is a proactive password checker [13] that replaces /bin/passwd on your system. It is rule-based and easily configurable. It prevents users from selecting a weak password so that programs like "CRACK" can't guess it, and it provides enhanced syslog logging. Many vendors of UNIX are now bundling a proactive password checker with the OS, usually under the nomenclature of a "C2" or "trusted system." You may still find that this package has more features than your canned package. Compare them. Availability: Passwd+ (developed by Matt Bishop) is available via anonymous FTP from dartmouth.edu in ~/pub/passwd+tar.Z. 3.4.6 Audit Audit is a policy-driven security checker for a heterogeneous environment [14]. It is fully configurable so that you can set up Audit to exactly match your site's security policy. This program functionally does what COPS is intended to do, but does not hard-code your policy decisions for you the way that COPS does. Many vendors of UNIX are now bundling an auditing subsystem with the OS, usually under the nomenclature of a "C2" or "trusted system." You may still find that this package has more features than your canned package. Compare them. One particular subject to note is that most (IMHO) vendors auditing subsystems only collect and regurgitate tons of raw data, with no guidance and assistance for using that information. They leave that up to you. The Audit and/or Swatch tools are probably better. Availability: The final version of Audit will eventually be posted to USENET. However, the beta release will only be made available on a limited basis, to larger, heterogeneous sites. If your interested in participating in the beta test, send e-mail to the auther, Bjorn Satdeva (bjorn@sysadmin.com). 3.4.7 Miro Miro [14] is a suite of tools for specifying and checking security contraints (like COPS and Audit), including a couple programming languages. It is general because it is not tied to any particular OS, and it is flexible because security administrators express site policies via a formal specification language. It is easy to extend or modify a policy by simply augmenting or changing the specification of the current policy. Availability: Miro is the product of a large research project, and to understand it you need more than the paragraph I've written above. For more information about the Miro project send e-mail to (miro@cs.cmu.edu), there is even a video available. The authors Ph.D thesis, as well as the sources for the Miro tools, are available via anonymous FTP from ftp.cs.cmu.edu. When you connect there, type "cd /afs/cs/project/miro/ftp" and "get ftp-instructions"; this will explain how to get the thesis and/or software. 3.5 ADDITIONAL SECURITY ENHANCEMENTS The tools described in firewall layers {1...4} (sections 3.1 to 3.4) above, are what I consider part of a "base" set of tools and functional requirements for general security administration. The tools and methods described in this section are additional measures that can be combined with or added to your overall security program at any of the other levels. 3.5.1 One-time Password Key-Card Since reusable passwords can be captured and used/reused by intruders, consider a "one-time password" scheme. One-time passwords can be implemented using software-only solutions or software/hardware solutions, and there are several commercial products available. The following is an example of what CERT uses. Each user is assigned a "Digital Pathways" key-card (approximately $60 per user). When you enter your PIN code, it supplies a password that is good only one time. The only other piece to this, is software that replace the login shell on your "firewall" server. Availability: The source-code for this shell is based on code from the key card vendor and is currently not available to the public domain via anonymous FTP. For additional information about this, send e-mail to (cert@cert.org). 3.5.2 Privacy Enhanced Mail (PEM) PEM is a RSA-based encryption scheme that encrypts sensitive information, but more than that it checks for message integrity and non-repudiation of origin, so that the originator cannot deny having sent the message. PEM is actually a protocol that is designed to allow use of symmetric (private-key) and asymmetric (public-key) cryptography methods. In this example, Trusted Information Systems, Inc. (TIS) has implemented a PEM package using the public-key technique together with the Rand MH Message Handling System (version 6.7.2). TIS/PEM libraries [16] can be adapted for implementation of non-mail applications as well. Availability: TIS/PEM is a commercially available product, for additional information send e-mail to (pem-info@tis.com). 3.5.3 Kerberos Kerberos is a DES-based encryption scheme that encrypts sensitive information, such as passwords, sent via the network from client software to the server daemon process. The network services will automatically make requests to the Kerberos server for permission "tickets." You will need to have the source to your client/server programs so that you can use the Kerberos libraries to build new applications. Since Kerberos tickets are cached locally in /tmp, if there is more than one user on a given workstation, then a possibility for a collision exists. Kerberos also relies upon the system time to operate, therefore it should be enhanced in the future to include a secure time server (timed is not appropriate). There are two versions of Kerberos, one for OSF ported by HP, and one BSD-based developed by the author. Availability: Kerberos is distributed via anonymous FTP from athena-dist.mit.edu in ~/pub/kerberos or ~/pub/kerberos5. 3.5.4 Private-Key Certificates This is not really a product, but rather a design proposal [17] that is an alternative method to PEM for adding network security to applications such as mail. Simply put, it uses the public-key style of implementation with private-key cryptography. It can be adapted to different types of applications and it is boilerplate so that you can essentially plug-in any encryption algorithm. This is designed so that public-key protocols no longer have to rely on public-key encryption. Availability: Unknown. For more information, contact Don Davis, at Geer Zolot Assoc., Boston, MA (formerly of Project Athena at MIT). His paper "Network Security via Private-Key Certificates" better describes this techique. 3.5.5 Multilevel Security (MLS) After you've done everything else (above) to make your network secure, then MLS will probably be one of your next logical steps. That doesn't mean you have to wait until you've done everything else before implementing MLS, it's just (IMHO) that you would be wasting your time to go to the n'th degree before covering the fundamentals. However, if you are just now deciding to which variant of the UNIX operating system to buy, consider buying an MLS variant now. After you configure it to manage your security policy, go back through layers {1...4} to see what you might add to make it more secure in a networked environment. Many UNIX vendors are now shipping or preparing to ship a MLS version. A couple examples that immediately come to mind is SecureWare CMW+ 2.2 (based on A/UX or SCO ODT 1.1) and AT&T USL System V-Release 4-Version 2-Enhanced Security (SVR4.2ES). For additional information regarding MLS implementations within the Department of Defense (DoD), contact Charles West at (703) 696-1891, Multilevel Security Technology Insertion Program (MLS TIP), Defense Information Systems Agency (DISA). For additional information regarding SecureWare CMW+, send e-mail to info@sware.com. For additional information regarding AT&T USL SVR4.2ES, send e-mail to fate@usl.com. 3.5.6 File Encryption Users should get into the habit of encrypting sensitive files whenever they are stored in a public place or transmitted via public communication circuits. File encryption isn't bulletproof, but it is better than clear text for sensitive information. The UNIX crypt utility is the least secure of these tools, since it can be broken using well-known decryption techniques. The UNIX des utility (US export restriction apply) is more secure. It has not been known to be broken, however DoD does not sanction its use for transmitting classified material. A new UNIX tool PGP 2.2 is available (uses RSA encryption), however there may be licensing issues to be concerned with. 3.5.7 Secure Programming Methods Programmers can assist in the effort of security by reducing the chance that a potential intruder can exploit a hole or bug that is coded into locally developed software. There is probably a lot that can be said about this, and their are probably many books on the subject somewhere. But, here are some common recommendations: (a) Never create a SETUID shell script. There are well-known techniques used by intruders to gain access to a shell program that is running as root; (b) List the complete file name, including the full path in any system() or popen() call; and (c) Since there is no reason for users to have read access to a SETUID file (or any exectuble for that matter), set permissions to 4711 (SETUID) or 711 (Non-SETUID). 3.5.8 Counterintelligence To extend your security program to seek out, identify, and locate intruders; you may want to modify some of the security tools (especially those proxy service daemons and event-driven auditors) to trace intruders back to their source, and otherwise maintain logs of data on intrusion attempts. This information can prove vital in taking an offensive stance against security break-in's and can help prosecute offenders. 3.5.9 Other Possibilities Depending on your requirements you might look into specialized solutions such as Compartmented Mode Workstations (CMW), end-to-end Data Link Encryption (STU-III, Motorola NES, and XEROX XEU are examples), and TEMPEST. The NCSC (Rainbow Series) and ITSEC specifications can help you define what level of need you have for security and help lead you to additional types of solutions. 3.6 SECURITY POLICY Everything discussed in layers {1...5} (sections 3.1 to 3.5) above involve specific things you can do, tools and techniques to implement, to address a particular area or "hole" in security. Your SECURITY POLICY is what ties all of that together into a cohesive and effective SECURITY PROGRAM. There are many diverse issues to consider when formulating your policy, which alone is one of the biggest reasons why you must have one: What are the functional requirements of your network? How secure do you need to be? What needs to be protected? How will you handle incident reporting and prosecution? What does the law require you to do? What about privacy? Since break-ins often occur via multiple hops on computers throughout the US and the rest of the world, you will need to consider a variation of federal, state, local, as well as foreign laws. Make security a dedicated and deliberate effort. User training and security awareness. What is considered acceptable use for users? Do the users understand what it is they are permitted to do and what it is they are not permitted to do? What is considered acceptable use for system administration staff? Is using Crack to test passwords okay? Is giving friends outside the organization accounts okay? Maintain a working relationship with the Computer Emergency Response Team (CERT) at Carnegie Mellon University (CMU) and your Forum of Incident Response and Security Teams (FIRST) regional representative "CERT" team. PLUS a myriad of different issues too numerous to go into in a summary paper. By answering these questions you determine what packages and methods in layers {1...5} (or their equivalent) that you want to implement, and in what ways you want to modify or configure them. "A security policy is a formal specification of the rules by which people are given access to a computer and its resources." (and to extend that to say...a network and its resources). Whatever tools you install to help you maintain the security of your network and monitor it, they must be configured to implement YOUR POLICY, or else they are not doing the whole job that needs to be done. Therefore, you must first have a POLICY. For additional help in the area of policy development, contact cert@cert.org. They can direct you to useful documentation on the subject and guide you to your FIRST regional CERT team representative. A good starting point is Request For Comments (RFC) 1244 "Site Security Handbook" (96 pages), which is available via anonymous FTP from numerous RFC archive sites (for example: nic.ddn.mil). 4. SUMMARY OF AVAILABILITY Section Name Availability 3.2 Router Cisco, Wellfleet, Proteon 3.3.1 Tcp_wrapper cert.org:/pub/tools/tcp_wrappers 3.3.2 Socks s1.gov:/pub/socks.tar.Z 3.3.3 Kernel_wrap eecs.nwu.edu:/pub/securelib 3.3.4 Swatch sierra.stanford.edu:/pub/sources 3.3.5 CAP e-mail to thompsond@orvb.saic.com 3.3.6 Mail Gateway 3.3.7 Tty_wrapper 3.3.8 HSC-Gatekeeper e-mail to Herve.Schauer@hsc-sec.fr 3.3.9 AT&T INET e-mail to ches@research.att.com 3.4.1 COPS cert.org:/pub/tools/cops 3.4.2 Chkacct cc.perdue.edu:/pub/chkacctv1.1.tar.Z 3.4.3 Crack cert.org:/pub/tools/crack/crack_4.1-tar.Z 3.4.4 Shadow comp.sources.misc (jfh@rpp386.cactus.org). 3.4.5 Passwd+ dartmouth.edu:/pub/passwd+tar.Z 3.4.6 Audit e-mail to bjorn@sysadmin.com 3.4.7 Miro e-mail to miro@cs.cmu.edu 3.5.1 Key-card e-mail to cert@cert.org 3.5.2 TIS/PEM e-mail to pem-info@tis.com 3.5.3 Kerberos athena-dist.mit.edu:/pub/kerberos5 3.5.4 Private-key contact Don Davis, at Geer Zolot Assoc. 3.5.5 MLS contact your UNIX vendor 3.5.6 File encrypt contact your UNIX vendor 3.5.7 Programming 3.5.8 Counter-Intel 3.5.9 Other Poss. research and contact various vendors 3.6 Policy RFC 1244 and cert@cert.org 5. ADDITIONAL SOURCES OF INFORMATION There are several primary sources of information that you can tap into (and correspond with) to keep up to date with current happenings in the general network security and in specific the "firewall" community. I recommend subscribing to the following mailing lists: (a) cert-advisory-request@cert.org; (b) cert-tools- request@cert.org, and (c) firewalls@greatcircle.com. In addition to that read and participate in the following USENET newsgroups: (a) comp.security.announce (which echos the CERT advisory mailing list); (b) comp.security.misc; (c) alt.security (frequently dissolves into "flame wars"); (d) comp.risks; and (e) comp.virus (almost exclusively for discussing PC and MAC viruses). Also, you can copy files from the CERT USENET Clipping Archive via anonymous FTP from cert.org. CERT Contact Information: Emergencies: +1 412 268-7090 FAX: +1 412 268-6989 E-mail: cert@cert.org U.S. Mail: CERT Coordination Center Software Engineering Institute Carnegie Mellon University 4500 Fifth Avenue Pittsburgh, PA 15213-3890, USA USENIX Papers are available directly from USENIX: The USENIX Association 2560 Ninth Street, Suite 215 Berkeley, CA 94710, USA 6. Acknowledgements The author extends thanks to several of the authors of the tools discussed in this paper and others for providing feedback that effected several changes in the first couple drafts of this paper. This includes but, is not limited to the following: Ed DeHart (CERT), Jim Ellis (CERT), David and Michelle Koblas (SOCKS), Herve Schauer (Gatekeeper), Dan Farmer (COPS), D. Brent Chapman (firewalls@greatcircle.com), and Matt Bishop (Editor). 7. References [1] S. Carl-Mitchell and John S. Quarterman, Building Internet Firewalls. UnixWorld; February, 1992; pp 93-102. [2] Wietse Venema. TCP Wrapper: Network Monitoring, Access Control and Booby Traps. USENIX Proceedings, UNIX Security Symposium III; September 1992. [3] David and Michelle Koblas. SOCKS. USENIX Proceedings, UNIX Security Symposium III; September 1992. [4] William LeFebvre. Restricting Access to System Daemons Under SunOS. USENIX Proceedings, UNIX Security Symposium III; September 1992. [5] D. Brent Chapman. Network (In)Security Through IP Packet Filtering. USENIX Proceedings, UNIX Security Symposium III; September 1992. [6] Stephen E. Hansen and E. Todd Atkins. Centralized System Monitoring with Swatch. USENIX Proceedings, UNIX Security Symposium III; September 1992. [7] J. David Thompson and Kate Arndt. A Secure Public Network Access Mechanism. USENIX Proceedings, UNIX Security Symposium III; September 1992. [8] Herve Schauer. An Internet Gatekeeper. USENIX Proceedings, UNIX Security Symposium III; September 1992. [9] William Cheswick. The Design of a Secure Internet Gateway. Murray Hill, NJ: AT&T Bell Laboratories. [10] Garfinkel, Simson, and Gene Spafford. Firewall Machines. Practical UNIX Security. Sabastopol, CA: O'Reilly and Associates, Inc., 1991. [11] Shabbir J. Safdar. Giving Customers the Tools to Protect Themselves. USENIX Proceedings, UNIX Security Symposium III; September 1992. [12] John F. Haugh, II. Introduction to the Shadow Password Suite. USENIX Proceedings, UNIX Security Symposium III; September 1992. [13] Matt Bishop. Anatomy of a Proactive Password Checker. USENIX Proceedings, UNIX Security Symposium III; September 1992. [14] Bjorn Satdeva. Audit: A Policy Driven Security Checker for a Heterogeneous Environment. USENIX Proceedings, UNIX Security Symposium III; September 1992. [15] Allan Heydon and J.D. Tygar. Specifying and Checking UNIX Security Constraints. USENIX Proceedings, UNIX Security Symposium III; September 1992. [16] James M. Galvin and David M. Balenson. Security Aspects of a UNIX PEM Implementation. USENIX Proceedings, UNIX Security Symposium III; September 1992. [17] Don Davis. Network Security Via Private-Key Certificates. USENIX Proceedings, UNIX Security Symposium III; September 1992. ------------------------NOTICE---DISCLAIMER------------------------ The contents of this paper do not necessarily reflect the opinions of my employer or anyone else that I know. Nothing in this paper should be construed as a product endorsement. No warranty is expressed or implied. Any comments? Please send me e-mail. ------------------------------------------------------------------- ------------------------NOTICE---COPYRIGHT------------------------- (c) Copyright 1992,1993 Robert B. Reinhardt. This paper may be distributabed freely as long as the paper is not modified in any way, includes this notice, and is provided without guarantee or warranty expressed or implied. E-mail comments to breinhar@access.digex.com ------------------------------------------------------------------- From Firewalls-Owner Fri May 7 05:54:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04757; Fri, 7 May 93 05:54:50 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04741; Thu, 6 May 93 22:54:38 PDT Message-Id: <9305070554.AA04741@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: New file transfer protocol: FSP Date: Thu, 06 May 93 22:54:37 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There's apparently a new file transfer system, called FSP, gaining acceptance on the Internet as an alternative to anonymous FTP. The salient characteristics from a Firewalls point of view are that it is a connectionless service (it uses UDP rather than TCP), and that there is apparently no single widely-used well known port for FSP servers. The software is available for anonymous FTP on ftp.uu.net, file "networking/archival/fsp.25.tar.Z". I've appended the "INFO" file for review. Has anybody had any experience with this yet, particularly from a Firewalls and network security point of view? -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 Interested party please email wen-king@vlsi.cs.caltech.edu What is the purpose of FSP (V2.5): FSP is a set of programs that implements a public-access archive similar to an anonymous-FTP archive. It is not meant to be a replacement for ftp; it is only meant to do what anonymous-ftp does, but in a manner more acceptible to the provider of the service and more friendly to the clients. Providing anonymous-FTP service can be costly --- each active session consumes one process slot in the OS and one stream socket entry in the network sub-system. The servers can also run concurrently, adding to the system load. A popular archive site can easily be overwhelmed as a result. Some were forced to shutdown or and some impose inconvienent access restrictions. Unlike FTP, FSP is connection-less and virtually state-less. One server handles requests from all clients machines. Each active client machine takes up 16-bytes in a dynamically extensible table. Since only one server runs at any time, the load added to the server machine is no more than one. In exchange for allowing site operators to keep their sites open and do away with cumbersome access restrictions, this is what the clients accept with FSP: 1) Lower transfer rate. The maximum rate is 1 kbyte per UDP message round-trip time between the client and the server. In addition to the potential for more abundant sites and more accessible sites, this is what the clients gain with FSP: 1) Robustness. Since FSP is connectionless, flucturations in the network will not abort a FSP transaction. Furthermore, the 16-bytes of data for each client can be regenerated at any point during any transaction. Thus, if the server goes down at any point during a transaction, the transaction will resume when the server is restarted. (like NFS) 2) Friendlier user interface. FSP does not have its own command interpretor like FTP. Since it is connectionless, there is no reason to carry much information from one command to the next, and the commands can all be made into individual unix programs. For instance, there is one program you run to list the directory and another you run to download a file. 3) Client protection. FSP oversees a directory structure similar to that of an anonymous-FTP. However, a directory created via FSP transaction is owned by the client machine that issued the creation request. The client can create and delete files and subdirectories in that directory. In addition, the client can enable any of the two attributes for that directory: A) Give all other clients the permission to create files and subdirectries. B) Give all other clients the permission to delete files and subdirectories. Note: A subdirectory can be deleted if it is empty and the client owns the subdirectory. 4) Server protection. FSP server does not spawn sub-programs. It will accept only paths that are downward relative to its designated working directory. On systems with symbolic links, the server will follow symbolic links, but it does not follow uplinks (".."). Clients cannot create symbolic links and care should be taken so that other users on the server machine cannot create symbolic links in the server's work space. It is also fairly difficult to formuate an attack to force a shutdown of a FSP site by actions of a rogue site. About the only way to distrupt a FSP service is to flood the FSP site with network packets. FSP server prevents itself from 'counter-flooding' by filtering for legitimate requests using the following method: A) Each request message contains a key. For each client, server database contains the keys to be used for the next client request and for the previous client request. B) If the next request does not contain a key that matches either of the two keys, it is accepted only if at least one minute has elapsed since the last time a request is accepted. If the key does match the old key (retransmit) it is accepted if the elapse time is greater than 3 seconds. C) Every request message accepted is acknowledged with one reply message. The reply message contains a new key to used for the next request. The new key is computed by the server with a pseudo-random number generator. Flooding is a ballant violation of network etiquette because a site can be subjected to flooding attack whether it has FSP running or not, and flooding congests every link and gateway between the rogue client and the server. As a further measure of protection, the server loads a table of rogue clients on startup. The server will not respond to requests from any of those clients. The software set: common_def.h This C header file contains definitions common to both the server code and the client code. client_def.h This C header file contains definitions for the client code. server_def.h This C header file contains definitions for the server code. udp_io.c This file contains the lowest level routines that deal with the unix inet sockets. This file is used by both the server code and the client code. server_main.c Main routine and dispatch loop for the server. server_host.c Routines for maintaining client database. server_file.c Routines for file i/o. server_lib.c Routines for inet socket i/o. client_lib.c Core routines of the client library. client_util.c Supplementry routines of the client library. client_lock.c udp packet multiplexing mechanism. bsd_src/ Directory containing additional sources derived from those in public archive on uunet.uu.net. It contains a BSD random/srandom routine, a modified BSD globbing routine, a modified "ls" source. fcdcmd.c These compiles into individual client utilities. fgetcmd.c Those with a "cmd" in their name will do their flscmd.c own globbing on their argv base on directory fprocmd.c information obtained from the server. frmcmd.c frmdircmd.c fcatcmd.c fmkdir.c fput.c fver.c fgrab.c Compilation: FSP has been compiled and tested on a SS-2 running SunOs 4.1.1, a HP-9000 running HP UNIX, a VAX-780 running 4.3-tahoe, and a 386 box running system-V UNIX with old Excelan ethernet interface. It has also been compiled on a variety of machines by over a hundred users across the net. To compile the software, you must first successfully complete a "make" in the bsd_src directory. You may have to change a few files. In particular, you may have to edit "Makefile" and "tweak.h" in bsd_src directory. When that is done, you can edit the Makefile on the top directory and run "make" in the top directory. You may have to read through the rest of this document first before making changes to the Makefile. Server Administration: The only things you need for setting up a FSP server is a work directory for the service and and the FSP server itself (fspd). fspd can run independently or it can be run under inetd. When running independently, fspd waits for messages through a UDP socket whoes port number is defined in the Makefile. When running under inetd, fspd is involked as in.fspd. inetd will spawn fspd when a message arrives for the FSP socket. The fspd process will take over and stick around to wait on additional messages. After it has become idle for 2 minutes, fspd will exit and return control to inetd. Sample setup for inetd operation: In /etc/services file: fsp 21/udp fspd In /etc/inetd.conf file: fsp dgram udp wait ftp /usr/etc/fspd in.fspd In this sample, the same port number for ftp is used for the fsp socket. There will not be a conflict because ftp uses stream protocol, and fsp uses UDP protocol. The fspd program in this example is ran under user 'ftp'. In addition, fspd will accept these flags: -h absolute_path Set fsp work directory. Overrides the compiled-in default. -p udp_port_number Set UDP port number. Overrides the compiled-in default. -u uid_number Assume this uid after startup. If present, fspd will attempt a setuid() to this uid number. It will exit if setuid() fails. -d Turn on debug mode. The stdio files will remain open in debugging mode. When fspd starts, it chdir to its work directory where it looks for (and reads in if found) a list of internet numbers in the standard 4-part form: ddd.ddd.ddd.ddd in the file ".ROGUE_HOSTS". This file is prepared by the FSP maintainer, and is used to indicate that fspd should not respond to any requests from these machines. After that, it begins to service any requests it gets on the UDP socket. If a file .OWN.XXXXXXXX, where XXXXXXXX is an 8-digit hex number, exists in a directory in fspd's work space, the directory is owned by the machine whoes inet number is XXXXXXXX, where the number is printed as a hexadecimal number. If no such file exists, the directory has no owner. (Note, the 'dot' files are hidden from clients). If the file .FSP_OK_DEL does not exists in a directory, only the owner is allowed to remove items from that directory. If the file .FSP_OK_ADD does not exists in a directory, only the owner is allowed to add items into that directory. Thus, you typically want to protect the top directory by leaving out the .FSP_OK_DEL, .FSP_OK_ADD files, and .OWN.XXXXXXXX files in the top directory. Clients do not get to read the directory information directly. Instead, fspd maintains a directory listing in the file .FSP_CONTENT in each directory. When a client requests information for a directory, the .FSP_CONTENT file is created if it doesn't exist, and it is rebuilt if it is out of date. The information is accessed by having the client read the directory listing file. Care is taken so that the client will not get corrupted entries when the directory is changed while the listing is being read. Files being uploaded are first written to a temporary file in the work directory: .TXXXXXXXXYYYY where XXXXXXXX is the inet number of the client, and YYYY is the port number of the client program. When upload is compelete, the file is moved into the intended location. An 'alarm' interrupt will cause fspd to dump its current client database into the file .HTAB_DUMP in the work directory. This can be useful for debugging and for catching rogue clients. Client utilities: All inter-command states are kept in these four shell environment variables. FSP_PORT Port number of the fspd you wish to contact. FSP_HOST Host name or number of the fspd. FSP_DIR Your current working directory in the archive. When multiple client utilities are run at the same time on the same client machine, packet multiplexing mechanisms can be used to enable concurrent access to the same fsp database. If none of the mechanisms are selected at compile time, FSP_LOCALPORT can be used to ensure that only once client utility can run at any time. In this case, FSP_LOCALPORT can be set to any port number not current used on the client machine. FSP_TRACE can be set if you want status reports be printed while files are being transferred. FSP_DELAY variable can be used to set the retransmit interval for client utilities (in thousandth of a second). The retransmit rate is adjusted in an exponential manner, until the retry rate reaches 5 mintes per retry. FSP_BUF_SIZE can be set to a positive number less than or equal to 1024. When set, it determines the size of data to be send for each request during file and directory information transfer. The default is 1024. Some sites are connected via links that cannot transmit buffers containing 1024 bytes of data in addition to the header information. Setting FSP_BUF_SIZE to a lower value will allow these sites to access fsp archives. A typical setup looks like this: setenv FSP_PORT 21 setenv FSP_HOST 131.215.131.97 setenv FSP_DIR / setenv FSP_TRACE setenv FSP_DELAY 3000 setenv FSP_BUF_SIZE 1024 (All examples will be in csh. However, it is assumed that similar things can be done with other shells) For commands that do globbing using remote directory info, normal shell globbing needs to be turned off. In csh, it can be done with a set of aliases: alias fcd setenv FSP_DIR \`\(set noglob\; exec fcdcmd \!\*\)\` alias fls \(set noglob\; exec flscmd \!\*\) alias fget \(set noglob\; exec fgetcmd \!\*\) alias fgrab \(set noglob\; exec fgrabcmd \!\*\) alias fcat \(set noglob\; exec fcatcmd \!\*\) alias frm \(set noglob\; exec frmcmd \!\*\) alias frmdir \(set noglob\; exec frmdircmd \!\*\) alias fpro \(set noglob\; exec fprocmd \!\*\) In addtion, this alias is useful: alias fpwd echo \$FSP_DIR on \$FSP_HOST port \$FSP_PORT Commands: fver display server's version number. fcd change current remote directory, like cd. fls list directory. works like ls. fget get the named files. fgrab get the named file and delete it from remote directory. fput put the named files. fcat get the named files and send them to stdout. fmkdir make named directories. frm delete named files. frmdir delete named directories. fpro no arg: display directory protection modes. +c: give others permission to create new items. -c: deny others permission to create new items. +d: give others permission to delete old items. -d: deny others permission to delete old items. *********************************************************************** This is a free software. Be creative; make your own macros and tools and let me know of any bugs and suggestions. From Firewalls-Owner Fri May 7 15:19:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06388; Fri, 7 May 93 15:19:49 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06379; Fri, 7 May 93 08:19:38 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14467>; Fri, 7 May 1993 11:19:27 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA18195 (5.65a/IDA-1.4.2 for brent@GreatCircle.COM); Fri, 7 May 93 10:48:08 -0400 Received: by dino.alias.com id AA07727 (5.65a/IDA-1.4.2 for firewalls@greatcircle.com); Fri, 7 May 93 10:48:05 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9305071448.AA07727@dino.alias.com> Subject: Re: New file transfer protocol: FSP To: brent@GreatCircle.COM (Brent Chapman) Date: Fri, 7 May 1993 11:48:03 -0400 Cc: firewalls@GreatCircle.COM In-Reply-To: <9305070554.AA04741@mycroft.GreatCircle.COM> from "Brent Chapman" at May 7, 93 01:54:37 am X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1233 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > There's apparently a new file transfer system, called FSP, gaining > acceptance on the Internet as an alternative to anonymous FTP. b 1) FSP has mainly been used for 'underground' purposes, i.e. GIFs, pirated software, and so on. (That may have changed). Many sites disallow it on this basis. 2) The major design issue of FSP, namely that it uses UDP instead of TCP, is flawed. UDP doesn't have any of the congestion control or avoidance systems that have been placed into TCP over the years. FTP is just fine on modern IP systems, since network transients don't tear down a TCP connection anymore (That was a BSD bug, and has slowly been eradicated). Apparently, FSP has started causing problems already on some slower IP links, since it doesn't do any congestion control. It's only a matter of time before the larger network providers notice it, and take steps. >From a security point of view, it's like any other UDP service, i.e. impossible to control. :-) -- C. Harald Koch, Network Manager | "Procrastination is just another technique Alias Research Inc. Toronto, ON | for planning ahead!" chk@alias.com | chk@gpu.utcc.utoronto.ca | -Steve Seargeant From Firewalls-Owner Fri May 7 11:21:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11409; Fri, 7 May 93 18:04:45 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11384; Fri, 7 May 93 11:04:25 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA17912; Sat, 8 May 93 04:05:26 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9305071805.AA17912@coombs.anu.edu.au> Subject: Re: New file transfer protocol: FSP To: chk@alias.com (C. Harald Koch) Date: Sat, 8 May 93 4:05:25 EST Cc: brent@GreatCircle.COM, firewalls@GreatCircle.COM In-Reply-To: <9305071448.AA07727@dino.alias.com>; from "C. Harald Koch" at May 7, 93 11:48 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In some email I received from C. Harald Koch, Sie wrote: [...] > systems that have been placed into TCP over the years. FTP is just fine > on modern IP systems, since network transients don't tear down a TCP > connection anymore (That was a BSD bug, and has slowly been eradicated). Ahem. Of all the Unixes I know, NetBSD has it fixed. Everything based on 4.3BSD is flawed (there being a patch for SunOS to help) and this includes a very large range of Unix variants. Also there is a bug in NET-2 (fixed for NetBSD). > Apparently, FSP has started causing problems already on some slower IP > links, since it doesn't do any congestion control. It's only a matter of > time before the larger network providers notice it, and take steps. > > >From a security point of view, it's like any other UDP service, i.e. > impossible to control. :-) But also impossible to monitor...how can a network provider determine what portion of traffic is being used for FSP if there is no fixed port number ? And then, what effective action can they take ? If you run FSP on a NFSless machine you can use port 2049, what now ? Darren From Firewalls-Owner Fri May 7 20:27:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12614; Fri, 7 May 93 20:27:17 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12605; Fri, 7 May 93 13:27:11 PDT Message-Id: <9305072027.AA12605@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP Date: Fri, 07 May 93 13:27:09 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Everything I've heard about FSP so far (particularly about how it seems to be being used) leads me to the conclusion that it's yet another reason to sharply limit UDP (except for server-to-server DNS and NTP) through a firewall. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Fri May 7 20:57:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12732; Fri, 7 May 93 20:57:25 GMT Received: from kahala.soest.hawaii.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12725; Fri, 7 May 93 13:57:16 PDT Date: Fri, 7 May 93 10:58:14 HST From: "Bob Cunningham" Message-Id: <9305072058.AA06993@kahala.soest.hawaii.edu> Received: by kahala.soest.hawaii.edu (4.1/kahala-MX-3.3) id AA06993; Fri, 7 May 93 10:58:14 HST To: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There may be benign uses of fsp, but personally I've not seen it used EXCEPT by crackers. It appears to be their tool of choice for transferring file in a relatively untraceable manner. One person who has "visited" some of the systems around here has about 12MBytes of compressed tar files containing virtually all the cracking tools you could imagine (and more) that he transfers all around using fsp. From Firewalls-Owner Fri May 7 21:53:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13009; Fri, 7 May 93 21:53:26 GMT Received: from lbl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12995; Fri, 7 May 93 14:52:54 PDT Received: from ccsun.unicamp.br (obelix.unicamp.br) by lbl.gov (4.1/1.39) id AA21988; Fri, 7 May 93 14:54:55 PDT Received: from dcc.unicamp.br by ccsun.unicamp.br (4.1/SMI-4.0) id AA14535; Fri, 7 May 93 18:35:34 BSC Received: from iguacu (iguacu-gw) by dcc.unicamp.br (4.1/SMI-4.1) id AA15438; Fri, 7 May 93 18:40:33 EST Date: Fri, 7 May 93 18:40:33 EST From: paulo@dcc.unicamp.br (Paulo Licio de Geus) Message-Id: <9305072140.AA15438@dcc.unicamp.br> Received: by iguacu (4.1/SMI-4.1) id AA25559; Fri, 7 May 93 18:40:31 EST To: "Bob Cunningham" Cc: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP References: <9305072058.AA06993@kahala.soest.hawaii.edu> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Bob Cunningham" writes: > There may be benign uses of fsp, but personally I've not seen it used > EXCEPT by crackers. It appears to be their tool of choice for > transferring file in a relatively untraceable manner. > > One person who has "visited" some of the systems around here has about > 12MBytes of compressed tar files containing virtually all the cracking > tools you could imagine (and more) that he transfers all around using fsp. Correction. We live on a very low speed link to the rest of the world, where ftp usually never finishes for anything >500KBytes. In that situation FSP is the only thing that allows us to transfer data when anyone else would just do ftp. There are very few sites supporting the protocol, but these sometimes saves your day. Facts: this country relies on two 64Kbits/s links to the rest of the world, and this place is connected to the main country backbone through a combo of 9.6+4.8 kbits/s. And, surprise, we maintain everything here up to date. Yes, *there are* benign uses of FSP. Just remember that. -- postmaster/manager Paulo Licio de Geus INTERNET: paulo@dcc.unicamp.br Depto de Ciencia da Computacao voice: +55 192 39-3115/8695/8442 DCC - IMECC - UNICAMP fax: +55 192 39-7470/5808 caixa postal: 6065 13081 Campinas SP Brazil From Firewalls-Owner Fri May 7 22:55:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13407; Fri, 7 May 93 22:55:16 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13399; Fri, 7 May 93 15:55:07 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) for brent@GreatCircle.COM id AA16212; Fri, 7 May 93 15:56:06 -0700 Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI) for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA06944; Fri, 7 May 93 15:56:06 -0700 Date: Fri, 7 May 93 15:56:05 PDT From: Eliot Lear To: chk@alias.com (C. Harald Koch) Cc: brent@GreatCircle.COM (Brent Chapman), firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Fri, 7 May 1993 11:48:03 -0400 Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > 2) The major design issue of FSP, namely that it uses UDP instead of TCP, is > flawed. UDP doesn't have any of the congestion control or avoidance > systems that have been placed into TCP over the years. FTP is just fine > on modern IP systems, since network transients don't tear down a TCP > connection anymore (That was a BSD bug, and has slowly been eradicated). UDP is extremely useful if an individual is sending TCP resets to your FTP server/and or/client. FSP conveniently gets around such bit watchers, and is likely the result of overly draconian usage enforcement policies. Eliot Lear [lear@sgi.com] From Firewalls-Owner Mon May 10 02:09:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18692; Mon, 10 May 93 02:09:15 GMT Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18682; Sun, 9 May 93 19:09:07 PDT Received: from fabian.lat.com by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA26888; Sun, 9 May 93 19:09:46 PDT Received: from [192.160.241.2] (skyline.lat.com) by lat.com (4.1/SMI-4.1) id AA18936; Sun, 9 May 93 18:04:41 GMT Date: Sun, 9 May 93 18:04:41 GMT Message-Id: <9305091804.AA18936@lat.com> From: "Gary Kremen [gary@lat.com]" Reply-To: "Gary Kremen [gary@lat.com]" To: brent@GreatCircle.COM, firewalls@GreatCircle.COM, Firewalls-Owner@GreatCircle.COM Subject: Please add me to the digest format and take me off the Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk individual message format - thanks! _____________________________________________________________________________ Gary Kremen This mail is from either Los Altos Technologies, Inc. gary@lat.com or gary@192.160.241.1 From Firewalls-Owner Mon May 10 13:11:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20312; Mon, 10 May 93 13:11:47 GMT Received: from NSSDCA.GSFC.NASA.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20305; Mon, 10 May 93 06:11:41 PDT Date: Mon, 10 May 1993 9:12:41 -0400 (EDT) From: TENCATI@NSSDCA.GSFC.NASA.GOV (Ron Tencati +1-301-513-1625) Message-Id: <930510091241.202010f2@NSSDCA.GSFC.NASA.GOV> Subject: RE: Firewalls Digest V2 #79 To: Firewalls@GreatCircle.COM X-Vmsmail-To: SMTP%"Firewalls@GreatCircle.COM" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Firewalls Moderator: Please provide screening so that messages such as the following (and THIS ONE) are read by a human, and not included and passed along to all the readers of the Firewalls digest. The following 'digest' should not have been published. Thank you, Ron Tencati -------------------------------------------------------------------------- Hughes STX Corporation | +1-301-513-1625 (tele) NASA/Goddard Space Flight Center | +1-301-513-1608 (fax) Code 630 | 1-800-759-7243/Pin: 5460866(pager) Greenbelt, MD. 20771 | tencati@nssdca.gsfc.nasa.gov -------------------------------------------------------------------------- >Firewalls Digest Monday, 10 May 1993 Volume 02 : Number 079 > >In this issue: > > Please add me to the digest format and take me off the > >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: "Gary Kremen [gary@lat.com]" >Date: Sun, 9 May 93 18:04:41 GMT >Subject: Please add me to the digest format and take me off the > >individual message format - thanks! > >_____________________________________________________________________________ >Gary Kremen This mail is from either >Los Altos Technologies, Inc. gary@lat.com or gary@192.160.241.1 > > >------------------------------ > >End of Firewalls Digest V2 #79 >****************************** From Firewalls-Owner Mon May 10 14:03:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20448; Mon, 10 May 93 14:03:36 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20441; Mon, 10 May 93 07:03:27 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14407>; Mon, 10 May 1993 10:04:18 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA25399 (5.65a/IDA-1.4.2 for paulo@dcc.unicamp.br); Mon, 10 May 93 10:00:02 -0400 Received: by dino.alias.com id AA17886 (5.65a/IDA-1.4.2 for firewalls@GreatCircle.COM); Mon, 10 May 93 10:00:00 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9305101400.AA17886@dino.alias.com> Subject: Re: New file transfer protocol: FSP To: paulo@dcc.unicamp.br (Paulo Licio de Geus) Date: Mon, 10 May 1993 10:59:59 -0400 Cc: firewalls@GreatCircle.COM In-Reply-To: <9305072140.AA15438@dcc.unicamp.br> from "Paulo Licio de Geus" at May 7, 93 07:40:33 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1268 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Yes, *there are* benign uses of FSP. Just remember that. Hmm. I suspect this is going to end up just like the pay-phones argument in the U.S.: 1) Many payphones in downtown areas in U.S. cities are being removed or severely disabled, because their main use was by drug-trafficers. This often removes the only telephones accessible by people in those neighbourhoods who can't afford their own phones. 2) Many payphones (esp. in airports) are no longer able to make calling-card calls to many foreign nations, because most of the calls to those places were being made using stolen cards. This also impacts people who are legitimately calling those countries using credit cards. The question is, is it 'right' to disable a useful tool just because most of that tools common usage is anti-social? Should we ban FSP just because it's most commonly a cracker's tool? (Y'all know already that my answer is a firm "Yes!"...) -- C. Harald Koch, Network Manager | "Cable is not a luxury, since many areas have Alias Research Inc. Toronto, ON | poor TV reception". - Mayor, Tucson AZ, 1989 chk@alias.com | [ apparently, good TV reception is a basic chk@gpu.utcc.utoronto.ca | necessity -- at least in Tucson -kl ] From Firewalls-Owner Mon May 10 08:51:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20600; Mon, 10 May 93 15:47:09 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20592; Mon, 10 May 93 08:46:11 PDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA11204; Mon, 10 May 93 11:14:19 EDT Received: from lehman.com by shearson.com (4.1/LB-0.6) id AA13613; Mon, 10 May 93 11:08:11 EDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA11173; Mon, 10 May 93 11:08:09 EDT Received: from snark.shearson.com by shearson.com (4.1/LB-0.6) id AA13609; Mon, 10 May 93 11:07:33 EDT Received: by snark.shearson.com (4.1/SMI-4.1) id AA14651; Mon, 10 May 93 11:07:31 EDT Message-Id: <9305101507.AA14651@snark.shearson.com> To: paulo@dcc.unicamp.br (Paulo Licio de Geus) Cc: "Bob Cunningham" , firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of "Fri, 07 May 1993 18:40:33 EST." <9305072140.AA15438@dcc.unicamp.br> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Mon, 10 May 1993 11:07:31 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Paulo Licio de Geus says: > "Bob Cunningham" writes: > > There may be benign uses of fsp, but personally I've not seen it used > > EXCEPT by crackers. It appears to be their tool of choice for > > transferring file in a relatively untraceable manner. > > > > One person who has "visited" some of the systems around here has about > > 12MBytes of compressed tar files containing virtually all the cracking > > tools you could imagine (and more) that he transfers all around using fsp. > > Correction. We live on a very low speed link to the rest of the > world, where ftp usually never finishes for anything >500KBytes. In > that situation FSP is the only thing that allows us to transfer data > when anyone else would just do ftp. There are very few sites > supporting the protocol, but these sometimes saves your day. > Facts: this country relies on two 64Kbits/s links to the rest of the > world, and this place is connected to the main country backbone > through a combo of 9.6+4.8 kbits/s. And, surprise, we maintain > everything here up to date. This sounds dubious. FSP doesn't do proper backoff on a link because it uses udp, so its probably far worse for a slow unreliable link than FTP. Furthermore, you can get FTP clients that will properly restart aborted transfers where you left off -- its all part of the FTP protocol. Furthermore, even if the line is slow, FTP shouldn't be dropping things -- I suspect you have a buggy system if it is. Everything should just transfer very slowly, thats all -- in practice the line shouldn't be going down. Seems to me that using FSP can only make things worse, not better, by clogging the line. Perry Metzger From Firewalls-Owner Mon May 10 17:38:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20949; Mon, 10 May 93 17:38:13 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20941; Mon, 10 May 93 10:38:00 PDT Message-Id: <9305101738.AA20941@mycroft.GreatCircle.COM> To: TENCATI@NSSDCA.GSFC.NASA.GOV (Ron Tencati +1-301-513-1625) Cc: Firewalls@GreatCircle.COM Subject: Re: Firewalls Digest V2 #79 In-Reply-To: Your message of Mon, 10 May 1993 9:12:41 -0400 (EDT) Date: Mon, 10 May 93 10:37:59 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # Dear Firewalls Moderator: # # Please provide screening so that messages such as the following (and # THIS ONE) are read by a human, and not included and passed along to # all the readers of the Firewalls digest. The following 'digest' should # not have been published. Whoever said Firewalls or Firewalls-Digest was moderated? It's digestified so that folks who desire can get a day's traffic in one batch, but it is NOT moderated. The posting software I use catches MOST bogus administrivia that folks ignorantly send to the posting address, but occasionally one is worded such that it slips past the filters. If somebody wants Firewalls or Firewalls-Digest to be moderated, please contact me to discuss my standard consulting rates and terms; when somebody cuts me a purchase order, I'll start moderating it... -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon May 10 17:47:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21000; Mon, 10 May 93 17:47:10 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20992; Mon, 10 May 93 10:47:04 PDT Message-Id: <9305101747.AA20992@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Mon, 10 May 1993 10:59:59 -0400 Date: Mon, 10 May 93 10:47:03 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk chk@alias.com (C. Harald Koch) writes: # > Yes, *there are* benign uses of FSP. Just remember that. # # The question is, is it 'right' to disable a useful tool just because most of # that tools common usage is anti-social? Should we ban FSP just because it's # most commonly a cracker's tool? # # (Y'all know already that my answer is a firm "Yes!"...) I think so. I think it's the responsibility of the folks promoting a tool to take at least simple steps to limit its susceptibility to misuse. Any cracker with a moderate knowledge of C and UNIX networking could have created the functional equivalent of FSP. Fortunately, it seems that most crackers either don't have the requisite knowledge, or are too lazy to use it (there are too many other easier targets to choose from). The problem is, this tool has made it trivial to bypass established packet filtering mechanisms. Even the simple step of hard-coding a well-known-port into the software would have improved the security. Sure, it's trivial to edit the source and change the port, but I think most crackers wouldn't even go to that much effort. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon May 10 18:33:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21539; Mon, 10 May 93 18:33:11 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21528; Mon, 10 May 93 11:33:01 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AB18241 for ; Mon, 10 May 93 14:07:41 -0400 Received: from stimpys.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA14492; Mon, 10 May 93 13:57:36 EDT Received: from localhost by stimpys.imsi.com (4.1/SMI-4.1) id AA07274; Mon, 10 May 93 13:54:53 EDT Message-Id: <9305101754.AA07274@stimpys.imsi.com> To: pmetzger@lehman.com Cc: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of "Mon, 10 May 1993 11:07:31 EDT." <9305101507.AA14651@snark.shearson.com> Reply-To: rens@imsi.com Date: Mon, 10 May 1993 13:54:51 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Mon, 10 May 1993 11:07:31 -0400, "Perry E. Metzger" said: pmetzger> This sounds dubious. FSP doesn't do proper backoff on a pmetzger> link because it uses udp, so its probably far worse for a pmetzger> slow unreliable link than FTP. Furthermore, you can get Perry- Actually, FSP uses a rather agressive exponential backoff scheme. I have ascertained this by asking around quite a bit -- it would seem that most FSP users are pretty ignorant of how it works -- see below. But it seems designed to avoid NFS-style meltdowns under congestion. Of course, TCP is better at this, since it uses an adaptive retransmission scheme and not crude exponentiation. pmetzger> FTP clients that will properly restart aborted transfers pmetzger> where you left off -- its all part of the FTP protocol. [ Wasn't this the subject of a mini flamewar on the ietf list? It would seem restarting FTPs are not very widely distributed, or particularly well understood by the public.] pmetzger> to me that using FSP can only make things worse, not pmetzger> better, by clogging the line. I agree with the prognosis, but not the diagnosis. FSP seems to handle congestion fine. It's got a lot of other problems, IMHO. These center around - who is using it (lots of fairly ignorant cracker types (c.f. the discussion in alt.comp.fsp) who don't even know how to register an assigned port number) and - why do we need another protocol which gives no real added value over FTP, whose implementations are devoid of logging and security features, and which suffers from an architecture apparently designed to resist the inclusion thereof. -Rens -- o===============================================================o | J. Laurens Troost - UNIX Systems | At Work: rens@imsi.com | | Investment Management Svcs, Inc. | At Play: rens@century.com | | 12 East 49th Street, 35th floor | Phone: (212) 339-2823 | | New York, New York 10017 | Fax: (212) 444-1980 | o===============================================================o -- IMS is unlikely to share any of the above opinions -- From Firewalls-Owner Mon May 10 21:11:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22262; Mon, 10 May 93 21:11:21 GMT Received: from cruskit.aarnet.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22255; Mon, 10 May 93 14:10:51 PDT Received: by cruskit.aarnet.edu.au id AA13584 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Tue, 11 May 1993 07:04:37 +1000 From: Geoff Huston Message-Id: <199305102104.AA13584@cruskit.aarnet.edu.au> Subject: Re: New file transfer protocol: FSP To: pmetzger@lehman.com Date: Tue, 11 May 1993 07:04:36 +1000 (EST) Cc: paulo@dcc.unicamp.br, bob@kahala.soest.hawaii.edu, firewalls@GreatCircle.COM In-Reply-To: <9305101507.AA14651@snark.shearson.com> from "Perry E. Metzger" at May 10, 93 11:07:31 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: 619 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'd have to agree with Perry Metzger from a perspective of operational experience.... FSP does not perform effective backoff within a congested environment, causing increased router load through forcing the routers to undertake extensive packet discards. The damage caused effects all sessions through the congested link as the imposed load from FSP causes increased variation of TCP round trip timers which in turn throws the TCP sessions into a mode of extremely poor performance. As a network operator, the perspective on FSP is that the currently deployed versions of FSP are simply a pain! Geoff Huston AARnet From Firewalls-Owner Tue May 11 14:59:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25673; Tue, 11 May 93 14:59:14 GMT Received: from heifetz.msen.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25666; Tue, 11 May 93 07:59:07 PDT Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11) id ; Tue, 11 May 93 10:36 EDT Received: by lokkur.dexter.mi.us (5.65c/IDA-1.2.8) id AA02319; Tue, 11 May 1993 10:24:06 -0400 From: Steve Simmons Message-Id: <199305111424.AA02319@lokkur.dexter.mi.us> Subject: Re: New file transfer protocol: FSP To: lokkur!greatcircle.com!firewalls Date: Tue, 11 May 1993 10:24:06 -0400 (EDT) In-Reply-To: <9305101754.AA07274@stimpys.imsi.com> from "Rens Troost" at May 10, 93 01:54:51 pm X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 147 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk If restart/recovery has been implemented in some generally available FTP clients, I'd love get my hands on one. Perry, you made the statement.... From Firewalls-Owner Tue May 11 15:56:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25776; Tue, 11 May 93 15:56:21 GMT Received: from nic.near.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25769; Tue, 11 May 93 08:56:12 PDT Received: from IRON.BBN.COM by nic.near.net id aa07097; 11 May 93 11:57 EDT To: Steve Simmons Cc: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Tue, 11 May 1993 10:24:06 EDT. Date: Tue, 11 May 1993 11:56:22 -0400 Message-Id: <1317.737135782@nic.near.net> From: Ed Anselmo Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > If restart/recovery has been implemented in some generally available > FTP clients, I'd love get my hands on one. Perry, you made the > statement.... the ftp client on ftp.uu.net (networking/ftp/ftp.tar.Z) supports Rick Adams' / CSRG restart code (see recent postings on the IETF list). the ftpd in the same directory supports the restart command, as does the wuarchive ftpd. -- Ed Anselmo (anselmo@nic.near.net) From Firewalls-Owner Tue May 11 17:10:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25963; Tue, 11 May 93 17:10:03 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25954; Tue, 11 May 93 10:09:52 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA22122 for ; Tue, 11 May 93 12:56:42 -0400 Received: from stimpys.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA29761; Tue, 11 May 93 12:41:47 EDT Received: from localhost by stimpys.imsi.com (4.1/SMI-4.1) id AA20717; Tue, 11 May 93 12:39:04 EDT Message-Id: <9305111639.AA20717@stimpys.imsi.com> To: Steve Simmons Cc: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of "Tue, 11 May 1993 10:24:06 EDT." <199305111424.AA02319@lokkur.dexter.mi.us> Reply-To: rens@imsi.com Date: Tue, 11 May 1993 12:39:03 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Tue, 11 May 1993 10:24:06 -0400 (EDT), Steve Simmons said: scs> If restart/recovery has been implemented in some generally available FTP scs> clients, I'd love get my hands on one. Perry, you made the statement.... I believe Rick Adams (rick@uunet.uu.net) has an FTPD that will do the trick. -Rens From Firewalls-Owner Tue May 11 18:40:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26286; Tue, 11 May 93 18:40:15 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26277; Tue, 11 May 93 11:40:06 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) for brent@GreatCircle.COM id AA16124; Tue, 11 May 93 11:40:44 -0700 Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI) for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA18320; Tue, 11 May 93 11:40:43 -0700 Date: Tue, 11 May 93 11:40:42 PDT From: Eliot Lear To: Brent Chapman Cc: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Mon, 10 May 93 10:47:03 -0700 Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I think it's the responsibility of the folks promoting a > tool to take at least simple steps to limit its susceptibility to misuse. Were this the attitude long held to by society, we would have never allowed the use of round wheels, rocks, or forks. > The problem is, this tool has made it trivial to bypass established > packet filtering mechanisms. Even the simple step of hard-coding a > well-known-port into the software would have improved the security. > Sure, it's trivial to edit the source and change the port, but I think > most crackers wouldn't even go to that much effort. The point was to bypass a recalcitrant administrator who went overboard, snooping at people's packets. The tool wouldn't be useful if the normal mechanisms were allowed to function for the desired transfers. Eliot Lear [lear@sgi.com] From Firewalls-Owner Tue May 11 22:41:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26937; Tue, 11 May 93 22:41:51 GMT Received: from lokkur.dexter.mi.us (dexter-gw.dexter.msen.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26930; Tue, 11 May 93 15:41:25 PDT Received: by lokkur.dexter.mi.us (5.65c/IDA-1.2.8) id AA01101; Tue, 11 May 1993 18:39:35 -0400 From: Steve Simmons Message-Id: <199305112239.AA01101@lokkur.dexter.mi.us> Subject: Re: New file transfer protocol: FSP To: lear@yeager.corp.sgi.com (Eliot Lear) Date: Tue, 11 May 1993 18:39:35 -0400 (EDT) Cc: brent@GreatCircle.COM, firewalls@GreatCircle.COM In-Reply-To: from "Eliot Lear" at May 11, 93 11:40:42 am X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 743 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I know Eliot didn't mean it this way, but conversations about this item seem to have gone around both end and are meeting in the middle. Eliot says: >The point [of using FSP] was to bypass a recalcitrant administrator who went >overboard, snooping at people's packets. The tool wouldn't be useful >if the normal mechanisms were allowed to function for the desired >transfers. While someone else claims that we should consider banning it because it is a common hackers tool. What we have here is a tool developed to bypass the misuse of other tools which is now itself being used for misuse. We should keep it because it can bypass the misuse of the other tools, but should ban it because it is primarily used for misuse. I need a beer. From Firewalls-Owner Tue May 11 23:21:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27133; Tue, 11 May 93 23:21:27 GMT Received: from Solbourne.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27126; Tue, 11 May 93 16:21:19 PDT Received: from havoc.Solbourne.COM by Solbourne.COM (4.1/Solbourne-4.1) id AA21139; Tue, 11 May 93 17:22:52 MDT Received: by havoc.Solbourne.COM (4.1/SMI-4.1) id AA00572; Tue, 11 May 93 17:19:55 MDT Date: Tue, 11 May 93 17:19:55 MDT From: ericr@Solbourne.COM (Eric Robison) Message-Id: <9305112319.AA00572@havoc.Solbourne.COM> To: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk suscribe Firewalls-Digest ericr@solbourne.com From Firewalls-Owner Tue May 11 23:45:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27354; Tue, 11 May 93 23:45:21 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27341; Tue, 11 May 93 16:45:07 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) for brent@GreatCircle.COM id AA05445; Tue, 11 May 93 16:46:11 -0700 Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI) for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA19408; Tue, 11 May 93 16:46:10 -0700 Date: Tue, 11 May 93 16:46:10 PDT From: Eliot Lear To: Steve Simmons Cc: lear@yeager.corp.sgi.com (Eliot Lear), brent@GreatCircle.COM, firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Tue, 11 May 1993 18:39:35 -0400 (EDT) Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I know Eliot didn't mean it this way, but conversations about this item > seem to have gone around both end and are meeting in the middle. Regrettably, this is exactly what I am trying to point out. [...] > What we have here is a tool developed to bypass the misuse of other tools > which is now itself being used for misuse. We should keep it because it > can bypass the misuse of the other tools, but should ban it because it > is primarily used for misuse. Please consider wisely what a firewall is for, and what it is not for. If a firewall is for keeping the bad guys out, then depending on how concerned you are with the exposed machines, you may well need to turn off UDP, because it can effect an attack on random UDP ports including, I might add, NTP, WAIS, talk, and DNS, just to name a few. This will keep things `safe', albeit less useful. However, if your goal is to prevent naughty bits from cutting across your network, give up now. A new mechanism that circumvents best efforts to turn off FSP will be along in a few weeks if people find that they can't get their porn fix. I can see it now- FSP to FTP application gateways. FSP is a prime example of what happens when one implements a tyrranical policy ``in code'', when it is best implemented in management. Remember, just because you *can* do it in code, doesn't mean that you *should*. Eliot Lear [lear@sgi.com] From Firewalls-Owner Tue May 11 16:51:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27296; Tue, 11 May 93 23:38:16 GMT Received: from rip.psg.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27281; Tue, 11 May 93 16:38:06 PDT Received: by rip.psg.com (Smail3.1.28.1 #5) id m0nt3uc-00030rC; Tue, 11 May 93 16:39 PDT Message-Id: From: randy@psg.com (Randy Bush) Subject: Re: New file transfer protocol: FSP To: scs@lokkur.dexter.mi.us (Steve Simmons) Date: Tue, 11 May 1993 16:39:06 -0700 (PDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <199305112239.AA01101@lokkur.dexter.mi.us> from "Steve Simmons" at May 11, 93 06:39:35 pm Content-Type: text Content-Length: 414 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > What we have here is a tool developed to bypass the misuse of other tools > which is now itself being used for misuse. Maybe a tool which was developed in response to what was perceived as a overly restrictive choice on the service/security tradeoff of firewall design. And now that it is here, do we continue the escalation, or find some way to solve the underlying problem(s) to everyone's perceived benefit? From Firewalls-Owner Tue May 11 17:21:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27295; Tue, 11 May 93 23:38:16 GMT Received: from tfs.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27282; Tue, 11 May 93 16:38:05 PDT Received: from ts2.tfs.com by tfs.COM (5.61/1.00 (TRP - gateway)) id AA17986; Tue, 11 May 93 16:39:10 -0700 Received: by ts2.TFS.COM (5.51/1.00 (TRP - mailsrv)) id AA04247; Tue, 11 May 93 16:39:08 PDT Received: by tbbs0.TFS (5.51/cf-0.0/02/10-88) id AA01740; Tue, 11 May 93 16:39:02 PDT Date: Tue, 11 May 93 16:39:02 PDT From: jeff@tfs.COM (Jeff Houston (Yo Eddy)) Message-Id: <9305112339.AA01740@tbbs0.TFS> To: lear@yeager.corp.sgi.com, scs@lokkur.dexter.mi.us Subject: Re: New file transfer protocol: FSP Cc: brent@GreatCircle.COM, firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > What we have here is a tool developed to bypass the misuse of other tools > which is now itself being used for misuse. We should keep it because it > can bypass the misuse of the other tools, but should ban it because it > is primarily used for misuse. > > I need a beer. Would somebody please FSP everyone involved a beer? Jeff ---- Jeff Houston email: jeff@tfs.com System Admin Manager TRW Financial Systems Berkeley, Ca, 94704 (510) 704-3359 From Firewalls-Owner Wed May 12 01:29:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28688; Wed, 12 May 93 01:29:25 GMT Received: from lokkur.dexter.mi.us (dexter-gw.dexter.msen.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28681; Tue, 11 May 93 18:28:57 PDT Received: by lokkur.dexter.mi.us (5.65c/IDA-1.2.8) id AA01956; Tue, 11 May 1993 21:28:27 -0400 From: Steve Simmons Message-Id: <199305120128.AA01956@lokkur.dexter.mi.us> Subject: Re: New file transfer protocol: FSP To: firewalls@GreatCircle.COM Date: Tue, 11 May 1993 21:28:27 -0400 (EDT) In-Reply-To: from "Randy Bush" at May 11, 93 04:39:06 pm X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1610 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Thank you, I now have a beer. (Ah, the glories of UDP. That's an acronym for Urqueller/Deutcher/Pilsner, right?) Having a beer under the belt, I'm now more relaxed and willing to talk about fuzzy issues. Please, nobody take any comments personally, OK? I realize that a lot of things said here have been hearsay or repetition of things heard elsewhere, and am not blaming the messanger for the message. Re the conflict between capability and restriction, didn't Eliot say FSP was implemented because an admin was snooping packets? Not quite the same thing as claiming FSP was a way of working around restrictions on ftp. I have real problems with the characterization of restrictive admins used as justification for implementing a file transfer protocol that is antisocial (no flow control) and deliberately designed to avoid the restrictions that the network owner attempts to put on it. If the owner decides "no ftp", it's the owners right. Much better to try and get the policy changed by pointing out the futility of permitting email but denying ftp on security grounds. It's also worth pointing out that until fairly recently we had little except rather brutal packet filtering methods to cover security. Attacking the problem with a club wasn't pretty, but it was the only tool we had. Now we've got broadswords, are designing sabres, and envisioning scalpels. [[We all eagerly await the end of this metaphor.]] Blaming the admins and building anti-social tools is both incorrect aim and incorrect response. But this takes us pretty far beyond the topic of firewalls, so I'll shut up now. From Firewalls-Owner Wed May 12 02:13:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28847; Wed, 12 May 93 02:13:30 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28840; Tue, 11 May 93 19:13:22 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA24576; Tue, 11 May 93 22:15:47 EDT Date: Tue, 11 May 93 22:15:47 EDT From: Marcus J Ranum Message-Id: <9305120215.AA24576@TIS.COM> To: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk FSP isn't for us to ban or not ban. It's something to understand and be aware of in the context of whatever network security policy each of us is tasked with enforcing. Clearly, if you're at one end of the spectrum, and are concerned with unauthorized and untraceable export of data, then FSP's probably something you want to block. If you're not too concerned about data control it's less of a problem. Most of the firewalls I've done in the past fell farther towards the "control everything" side of the spectrum. To me "control everything" implies "block everything" and that tends to lead towards non-routed firewalls. Stuff like FSP and IP-over-IP tunnelling are general problems with the screening router approach to firewall building. I'm not saying there's anything wrong with screening routers; it all depends on what you are trying to accomplish. FSP is a non-issue. The issue is whether your firewall somehow permits users to send data directly between networks. Implementing a simple, inefficient reliable stream protocol on top of another packet oriented service is left as an exercise to the reader - FSP is just an example of one such. It happens to be an arguably *useful* example. mjr. From Firewalls-Owner Wed May 12 02:45:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28906; Wed, 12 May 93 02:45:40 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28899; Tue, 11 May 93 19:45:32 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA25463; Tue, 11 May 93 22:47:57 EDT Date: Tue, 11 May 93 22:47:57 EDT From: Marcus J Ranum Message-Id: <9305120247.AA25463@TIS.COM> To: firewalls@GreatCircle.COM Subject: Re: FSP and tyranny Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Eliot Lear writes: >FSP is a prime example of what happens when one >implements a tyrranical policy ``in code'', when it is best >implemented in management. Remember, just because you *can* do it in >code, doesn't mean that you *should*. Leaving out the value-laden terminology, this is an issue I summarize as "you can't solve social problems with software." It's not a question of can/can't or should/shouldn't, it's a question of what policy you are tasked with enforcing or have chosen to enforce. For example, one company I worked for was deeply concerned that data might leak out through a firewall. Corporate policy was enlightened enough to realize that it's hard to prevent a stubborn individual from exporting data, but required that data at least be logged and outgoing traffic be summarized. That's not entirely an unreasonable policy, IMHO. So, the firewall summarized outgoing mail by volume, FTP traffic, etc, etc. Unless the policy was met, there would have been no firewall, so by meeting the policy, all were happy and the light of the internet showed upon a famished land. An employee could still mail out corporate secrets, but now, if they did it in such a way as to spoof the logs, they were clearly making an effort to violate corporate policy. In other words, the technical problem was *NOT* solved but the management/policy problem was solved. In the DOD, if you're dealing with a classified secret document, the system is such that you shouldn't be able to see the document unless you are cleared for that level of information. If you're cleared for it, there's nothing to stop you from memorizing the document, going home, and posting it to USENET - except for the fact that you have clearly violated a policy with a mechanism that makes a best effort to limit such violations. It comes down to trust - sooner or later you have to trust someone. As a firewall administrator, you may or may not be presented with an existing corporate data security policy to enforce. It may or may not assume that the user population is trustworthy. If the policy you are enforcing assumes your user population is trustworthy, then arguably, you could permit outgoing telnet with an 'established' keyword through a screening router from any host on your network to anyone on the internet. Because you trust your users not to use that outgoing telnet to tunnel IP-over-IP. If they violate that trust, then you get to flay them alive, or whatever you can do within your limits. It's my belief that as your network's size increases, it should become increasingly hard to trust all the nodes on your internal network. At that point you may have to stop trusting your users and assume that the firewall is bi-directional - it may not only stop people on the outside from breaking in, it may have to stop someone who has broken in into the *inside* (via an unsecured modem or whatever) from breaking out. Depending on how you've configured your firewall, it may or may not give any protection whatsoever against attack from the inside. That's worth considering as you develop your firewall's policy, or implement the policy your superiors give you. Sometimes a policy handed down from above may seem "tyrrannical"[sic] - but as long as I'm taking someone's paycheck I'll provide my best technical feedback into the policy and implement it to the best of my ability. mjr. From Firewalls-Owner Wed May 12 17:46:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00955; Wed, 12 May 93 17:46:36 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00948; Wed, 12 May 93 10:46:28 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) for firewalls@GreatCircle.COM id AA02926; Wed, 12 May 93 10:46:58 -0700 Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI) for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA21099; Wed, 12 May 93 10:46:57 -0700 Date: Wed, 12 May 93 10:46:57 PDT From: Eliot Lear To: Steve Simmons Cc: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Tue, 11 May 1993 21:28:27 -0400 (EDT) Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Re the conflict between capability and restriction, didn't Eliot say > FSP was implemented because an admin was snooping packets? Not quite > the same thing as claiming FSP was a way of working around restrictions > on ftp. Sorry. He was not only snooping packets, but was also sending TCP RESETs to offending sites. > I have real problems with the characterization of restrictive admins > used as justification for implementing a file transfer protocol that is > antisocial (no flow control) and deliberately designed to avoid the > restrictions that the network owner attempts to put on it. If the > owner decides "no ftp", it's the owners right. No doubt. But that won't quench people's drive for sex or money. Thus FSP, and whatever may follow. How much is this battle worth to you? Eliot Lear [lear@sgi.com] From Firewalls-Owner Wed May 12 18:07:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01026; Wed, 12 May 93 18:07:08 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01019; Wed, 12 May 93 11:07:00 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) for firewalls@GreatCircle.COM id AA04296; Wed, 12 May 93 11:07:54 -0700 Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI) for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA21158; Wed, 12 May 93 11:07:53 -0700 Date: Wed, 12 May 93 11:07:53 PDT From: Eliot Lear To: Marcus J Ranum Cc: firewalls@GreatCircle.COM Subject: Re: FSP and tyranny In-Reply-To: Your message of Tue, 11 May 93 22:47:57 EDT Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Leaving out the value-laden terminology, this is an issue I > summarize as "you can't solve social problems with software." Fair enough. I think, however, that it's important for a firewall administrator to not take an ``Ours is to do or die'' attitude. When your paycheck source asks you to do something stupid, it's your responsibility to ask, ``Are you sure?'' If said source insists, there is the consultant's curse (I always raise my rates in such cases). Eliot Lear [lear@sgi.com] From Firewalls-Owner Wed May 12 21:49:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01593; Wed, 12 May 93 21:49:29 GMT Received: from Esy.COM (ZEUS.ESY.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01586; Wed, 12 May 93 14:49:19 PDT Received: by Esy.COM (4.1/SMI-4.1) id AA13757; Wed, 12 May 93 16:48:32 CDT From: whitener@Esy.COM (STSX - Rob Whitener) Message-Id: <9305122148.AA13757@Esy.COM> Subject: Mailing List? To: Firewalls-Digest@GreatCircle.COM Date: Wed, 12 May 93 16:48:31 CDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I was told that this is a mailing list for Internet Firewall administrators, is this true? Please send me some info. Thanks, Rob -- Robert Whitener Email: whitener@Esy.COM E-Systems, Garland Division Voice: (214) 205-8089 1200 S. Jupiter Road, Garland, Texas 75042 FAX: (214) 272-8144 From Firewalls-Owner Wed May 12 22:02:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01659; Wed, 12 May 93 22:02:30 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01649; Wed, 12 May 93 15:02:09 PDT Message-Id: <9305122202.AA01649@mycroft.GreatCircle.COM> To: whitener@Esy.COM (STSX - Rob Whitener) Cc: Firewalls-Digest@GreatCircle.COM Subject: Re: Mailing List? In-Reply-To: Your message of Wed, 12 May 93 16:48:31 CDT Date: Wed, 12 May 93 15:02:08 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # I was told that this is a mailing list for Internet Firewall administrators, # is this true? Please send me some info. No, it's a mailing list for animal trainers teaching lions and tigers and bears (oh, my!) to jump through walls of flame... To find out more about Firewalls or Firewalls-Digest, send the command "info firewalls" or "info firewalls-digest" in the body of a message (not the "Subject:" line) to Majordomo@GreatCircle.COM. I've been getting quite a few misdirected administrivia messages lately, so let me take this opportunity to remind everyone how pretty much EVERY Internet mailing list works. If you want to post something to everybody on the list, send it to the list address (in our case, Firewalls@GreatCircle.COM or Firewalls-Digest@GreatCircle.COM). If, on the other hand, your message is administrivia (i.e., you want on or off the list, or you have a question for the list owner, or whatever), you should send it to -request@ (in our case, that would be Firewalls-Request@GreatCircle.COM or Firewalls-Digest-Request@GreatCircle.COM). We now return you to your regularly scheduled ethics debate (honestly, I didn't mean to kick that ant hill when I brought up FSP)... -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Wed May 12 23:36:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01788; Wed, 12 May 93 23:36:17 GMT Received: from diemen.utas.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01781; Wed, 12 May 93 16:35:59 PDT Received: from bowen.cc.utas.edu.au by diemen.utas.edu.au with SMTP id AA05280 (5.65b/IDA-1.4.3 for Firewalls@greatcircle.com); Thu, 13 May 93 09:36:20 +1000 Received: by bowen.cc.utas.edu.au (4.1/SMI-4.1) id AA02813; Thu, 13 May 93 09:36:19 EST Date: Thu, 13 May 1993 09:12:59 +1000 (EST) From: John Miezitis Subject: Re: New file transfer protocol: FSP To: Firewalls@GreatCircle.COM In-Reply-To: <9305122202.AA01649@mycroft.GreatCircle.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Wed, 12 May 1993, Brent Chapman wrote: > [ Irrelevant stuff deleted. (Irrelevant to my reply I mean) ] > > We now return you to your regularly scheduled ethics debate (honestly, I > didn't mean to kick that ant hill when I brought up FSP)... Brent, I am very pleased that you did kick this ant hill. At this University we have a problem with a handfull of students using FSP to gain copies of pirated software. One student was found with a number of pirated games in his account. The University is concerned about possible action that could be taken against it and the image it presents by allowing this type of behaviour. The student in question had his account suspended but has since been observed using other peoples accounts. So much for that approach. In desperation myself and a Systems Programmer have been discussing what could be done about this. Suggestions have ranged from denying Internet access to all students, to blocking all UDP traffic except for essential services. So far no further action has been taken until we can come up with something that will be effective. Any suggestions? For me the most troubling aspect of FSP is that I can't monitor the traffic to see how much of a problem it really is. Currently I use NNStat to keep statistics of all traffic to and from our network from which I can get a breakdown of how much is FTP, SMTP etc. FSP reduces the usefulness of this data. Cheers. JohnM. John B Miezitis, University of Tasmania, Information Technology Services. Intl Ph: +61 02 202811, Aus Ph: 002 202811, Email: John.Miezitis@cc.utas.edu.au Belgium man Belgium!!! - Z. Beeblebrox _______________________________________________________________________________ From Firewalls-Owner Thu May 13 01:02:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01945; Thu, 13 May 93 01:02:14 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01938; Wed, 12 May 93 18:02:03 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) for Firewalls@GreatCircle.COM id AA29385; Wed, 12 May 93 18:02:36 -0700 Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI) for @sgigate.sgi.com:Firewalls@GreatCircle.COM id AA23123; Wed, 12 May 93 18:02:35 -0700 Date: Wed, 12 May 93 18:02:35 PDT From: Eliot Lear To: John Miezitis Cc: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Thu, 13 May 1993 09:12:59 +1000 (EST) Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk My suggestion is that you deal with the student, and those whose accounts he borrows, using your administrative process. For example, you might consider stronger sanctions such as separation from the university. Denying students UDP access ``except for essential services'' is likely to cause people to start hiding FSP servers on ``essential services'' ports. Eliot Lear [lear@sgi.com] From Firewalls-Owner Thu May 13 04:41:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02383; Thu, 13 May 93 04:41:34 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02376; Wed, 12 May 93 21:40:41 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA08545; Thu, 13 May 93 14:14:45 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9305130414.AA08545@coombs.anu.edu.au> Subject: Re: New file transfer protocol: FSP To: lear@yeager.corp.sgi.com (Eliot Lear) Date: Thu, 13 May 93 14:14:44 EST Cc: johnm@cc.utas.edu.au, Firewalls@GreatCircle.COM In-Reply-To: ; from "Eliot Lear" at May 12, 93 6:02 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In some email I received from Eliot Lear, Sie wrote: > > My suggestion is that you deal with the student, and those whose accounts > he borrows, using your administrative process. For example, you might > consider stronger sanctions such as separation from the university. > > Denying students UDP access ``except for essential services'' is likely > to cause people to start hiding FSP servers on ``essential services'' ports. How many ``essential services'' live on ports over 1024 ? Port 2049, for NFS, is the only UDP port above 1024 which you might want to let through (so you can NFS mount things like wuarchive or whatever else) but at the same time can be quite risky. How many FSP servers are likely to be run (or able to be run!) on ports below 1024 ? Most of the ``essential services'' that use UDP are best used locally, such as DNS & RPC. Banning UDP totally and setting up a small window for these services coming from hosts where they really exist seems like a good solution. Are there are any other well-known and used services which use UDP *AND* operate on the inter-domain or inter-network level ? By this I mean useful to all users, not just the local NTP, DNS, etc servers. Darren From Firewalls-Owner Thu May 13 05:33:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02561; Thu, 13 May 93 05:33:35 GMT Received: from yarra-glen.aaii.oz.au (eden-valley.aaii.oz.AU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02544; Wed, 12 May 93 22:33:15 PDT Received: from harlie.aaii.oz.AU by yarra-glen.aaii.oz.au with SMTP (5.65c/SMI-4.0/AAII) id AA18171; Thu, 13 May 1993 15:33:40 +1000 Message-Id: <199305130533.AA18171@yarra-glen.aaii.oz.au> To: avalon@coombs.anu.edu.au Cc: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of "Thu, 13 May 1993 14:14:44 EST." <9305130414.AA08545@coombs.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 May 1993 15:33:11 +1000 From: Anthony Baxter Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9305130414.AA08545@coombs.anu.edu.au>you write: > Are there are any other well-known and used services which use UDP *AND* > operate on the inter-domain or inter-network level ? By this I mean > useful to all users, not just the local NTP, DNS, etc servers. An obvious one I can think of is Prospero, used by archie clients. It uses port 1525. A decent filter would allow you to only allow connections on that port to the various archie servers that exist. Anthony From Firewalls-Owner Thu May 13 16:03:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04083; Thu, 13 May 93 16:03:55 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04076; Thu, 13 May 93 09:03:47 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14408>; Thu, 13 May 1993 12:04:44 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA21956 (5.65a/IDA-1.4.2 for johnm@cc.utas.edu.au); Thu, 13 May 93 11:29:01 -0400 Received: by dino.alias.com id AA04722 (5.65a/IDA-1.4.2 for Firewalls@GreatCircle.COM); Thu, 13 May 93 11:28:27 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9305131528.AA04722@dino.alias.com> Subject: Re: New file transfer protocol: FSP To: lear@yeager.corp.sgi.com (Eliot Lear) Date: Thu, 13 May 1993 12:28:25 -0400 Cc: johnm@cc.utas.edu.au, Firewalls@GreatCircle.COM In-Reply-To: from "Eliot Lear" at May 12, 93 09:02:35 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 958 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > My suggestion is that you deal with the student, and those whose accounts > he borrows, using your administrative process. For example, you might > consider stronger sanctions such as separation from the university. I agree with this 100%. Don't keep looking for technical solutions; this guy is always going to be several steps ahead of you (you have a full time job, while he's a student). Besides, if you've denied him access, and he's on the computers anyway, he's illegally using your resources. I think your liability concerns go away in this scenario. Finally, don't punish all the rest of your students just because of one or two bad apples. -- C. Harald Koch, Network Manager | "There is no problem, no matter how large or Alias Research Inc. Toronto, ON | small, that cannot be solved by a suitable chk@alias.com | amount of high explosives." chk@gpu.utcc.utoronto.ca | -Leo Graf, USS LaFarge, 2298 From Firewalls-Owner Thu May 13 16:22:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04108; Thu, 13 May 93 16:22:35 GMT Received: from spock.retix.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04101; Thu, 13 May 93 09:22:28 PDT Received: from mproj.retix.com by spock.retix.com (ALPHA-6.56/6.28) id JAA20373; Thu, 13 May 1993 09:23:36 -0700 Received: by mproj.retix.com (5.65a/smail2.5/9-30-90) id AA05422; Thu, 13 May 93 09:24:22 -0700 Date: Thu, 13 May 93 09:24:22 -0700 From: dspencer@mproj.retix.com (David Spencer) Message-Id: <9305131624.AA05422@mproj.retix.com> To: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > On Wed, 12 May 1993, Brent Chapman wrote: > > ... > > Suggestions have ranged from denying Internet access to all students, to > blocking all UDP traffic except for essential services. So far no further > action has been taken until we can come up with something that will be > effective. Any suggestions? Yeah you can block UDP traffic but then 'v2' of FSP will be developed which you use a non-hardcoded TCP port and then won't you be back in the same boat? Or a cloaking version of FSP which uses multiple TCP ports... From Firewalls-Owner Thu May 13 16:35:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04288; Thu, 13 May 93 16:35:05 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04276; Thu, 13 May 93 09:34:40 PDT Message-Id: <9305131634.AA04276@mycroft.GreatCircle.COM> To: dspencer@mproj.retix.com (David Spencer) Cc: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Thu, 13 May 93 09:24:22 -0700 Date: Thu, 13 May 93 09:34:39 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # > On Wed, 12 May 1993, Brent Chapman wrote: # > # > ... # > # > Suggestions have ranged from denying Internet access to all students, to # > blocking all UDP traffic except for essential services. So far no further # > action has been taken until we can come up with something that will be # > effective. Any suggestions? No I didn't; that was somebody else. Let's be careful with those attributions, folks... -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu May 13 16:37:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04319; Thu, 13 May 93 16:37:14 GMT Received: from spock.retix.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04311; Thu, 13 May 93 09:37:06 PDT Received: from mproj.retix.com by spock.retix.com (ALPHA-6.56/6.28) id JAA20741; Thu, 13 May 1993 09:38:15 -0700 Received: by mproj.retix.com (5.65a/smail2.5/9-30-90) id AA05965; Thu, 13 May 93 09:39:00 -0700 Date: Thu, 13 May 93 09:39:00 -0700 From: dspencer@mproj.retix.com (David Spencer) Message-Id: <9305131639.AA05965@mproj.retix.com> To: brent@GreatCircle.COM Cc: Firewalls@GreatCircle.COM In-Reply-To: Brent Chapman's message of Thu, 13 May 93 09:34:39 -0700 <9305131634.AA04276@mycroft.GreatCircle.COM> Subject: New file transfer protocol: FSP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Date: Thu, 13 May 93 09:34:39 -0700 > From: Brent Chapman > > # > On Wed, 12 May 1993, Brent Chapman wrote: > # > > # > ... > # > > # > Suggestions have ranged from denying Internet access to all students, to > # > blocking all UDP traffic except for essential services. So far no further > # > action has been taken until we can come up with something that will be > # > effective. Any suggestions? > > No I didn't; that was somebody else. Let's be careful with those > attributions, folks... > Opps - sorry Brent and folks - all the blame is me! From Firewalls-Owner Thu May 13 17:01:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04462; Thu, 13 May 93 17:01:22 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04455; Thu, 13 May 93 10:01:06 PDT Received: from shuldig.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA26172 (5.65b/HUJI 4.114); Thu, 13 May 93 20:04:38 +0300 Received: from localhost by shuldig.cs.huji.ac.il with SMTP id AA09191 (5.65c/HUJI 4.1 for firewalls@greatcircle.com); Thu, 13 May 1993 20:04:39 +0300 Message-Id: <199305131704.AA09191@shuldig.cs.huji.ac.il> To: firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Thu, 13 May 93 09:24:22 -0700 . <9305131624.AA05422@mproj.retix.com> From: Amos Shapira Date: Thu, 13 May 1993 20:04:32 +0300 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk dspencer@mproj.retix.com (David Spencer) writes: | | |> On Wed, 12 May 1993, Brent Chapman wrote: |> |> ... |> |> Suggestions have ranged from denying Internet access to all students, to |> blocking all UDP traffic except for essential services. So far no further |> action has been taken until we can come up with something that will be |> effective. Any suggestions? | | Yeah you can block UDP traffic but then 'v2' of FSP will | be developed which you use a non-hardcoded TCP port and | then won't you be back in the same boat? Or a cloaking | version of FSP which uses multiple TCP ports... | | I think not. While it is true that tracking random TCP ports isn't going to be easy the entire point in using FSP over UDP is to make it connectionless and thus avoid detection from within the machine with netstat(8). With TCP there might still be a problem to nail down such a connection just from sniffing the cable but you still have an open connection that the sysadmin can see. Correct me if I'm missing something. --Amos --Amos Shapira (Jumper Extraordinaire) | "It is true that power corrupts, C.S. System Group, Hebrew University, | but absolute power is better!" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- the Demon to his son From Firewalls-Owner Thu May 13 17:56:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04588; Thu, 13 May 93 17:56:33 GMT Received: from Sdsc.Edu (sds.sdsc.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04581; Thu, 13 May 93 10:56:24 PDT Received: from logiconultra.com by Sdsc.Edu (sds.sdsc.edu STMG) via INTERNET; Thu, 13 May 93 17:44:27 GMT Received: from wile.logiconultra.com (wile) by logiconultra.com (4.1/SMI-4.1) id AA04999; Thu, 13 May 93 10:45:42 PDT Message-Id: <9305131745.AA04999@logiconultra.com> Received: by wile.logiconultra.com (NX5.67c/NeXT-2.0) id AA01096; Thu, 13 May 93 10:43:11 -0700 Date: Thu, 13 May 93 10:43:11 -0700 From: stine@logiconultra.com Received: by NeXT.Mailer (1.87.1.RR) Received: by NeXT Mailer (1.87.1.RR) To: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Is there a standard list of port numbers to allow and deny for a standard firewall configuration? I see a lot of people suggesting different port numbers to allow but it sure would be nice to have a list (maybe generated by concensus) of the ports. Thanks jim From Firewalls-Owner Thu May 13 19:03:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04828; Thu, 13 May 93 19:03:29 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04821; Thu, 13 May 93 12:03:22 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14417>; Thu, 13 May 1993 15:04:27 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA24673 (5.65a/IDA-1.4.2 for dspencer@mproj.retix.com); Thu, 13 May 93 14:58:26 -0400 Received: by dino.alias.com id AA07807 (5.65a/IDA-1.4.2 for Firewalls@GreatCircle.COM); Thu, 13 May 93 14:58:24 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9305131858.AA07807@dino.alias.com> Subject: Re: New file transfer protocol: FSP To: dspencer@mproj.retix.com (David Spencer) Date: Thu, 13 May 1993 15:58:23 -0400 Cc: Firewalls@GreatCircle.COM In-Reply-To: <9305131624.AA05422@mproj.retix.com> from "David Spencer" at May 13, 93 12:24:22 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 889 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Yeah you can block UDP traffic but then 'v2' of FSP will > be developed which you use a non-hardcoded TCP port and > then won't you be back in the same boat? Or a cloaking > version of FSP which uses multiple TCP ports... spread-spectrum TCP/IP. What a scary concept... (spread-spectrum is a technique for encoding a radio signal on a large number of frequencies, using either many individual carriers at extremely low power, or using rapid synchronized frequency shifts. In both cases the design goals are a) reduce interference and b) avoid detection.) -- C. Harald Koch, Network Manager | "Cable is not a luxury, since many areas have Alias Research Inc. Toronto, ON | poor TV reception". - Mayor, Tucson AZ, 1989 chk@alias.com | [ apparently, good TV reception is a basic chk@gpu.utcc.utoronto.ca | necessity -- at least in Tucson -kl ] From Firewalls-Owner Thu May 13 20:08:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05065; Thu, 13 May 93 20:08:08 GMT Received: from pluto.sm.dsi.unimi.it (c700-3.sm.dsi.unimi.it) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05058; Thu, 13 May 93 13:07:56 PDT Received: by pluto.sm.dsi.unimi.it (16.7/16.2) id AA09368; Thu, 13 May 93 22:10:43 +0200 Message-Id: <9305132010.AA09368@pluto.sm.dsi.unimi.it> From: vince@dsi.unimi.it (David Vincenzetti) Date: Thu, 13 May 1993 22:10:42 +0000 In-Reply-To: dspencer@mproj.retix.com (David Spencer) "Re: New file transfer protocol: FSP" (May 13, 9:24am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On May 13, 9:24am, David Spencer wrote: } Subject: Re: New file transfer protocol: FSP } } } > On Wed, 12 May 1993, Brent Chapman wrote: } > } > ... } > } > Suggestions have ranged from denying Internet access to all students, to } > blocking all UDP traffic except for essential services. So far no further } > action has been taken until we can come up with something that will be } > effective. Any suggestions? } } Yeah you can block UDP traffic but then 'v2' of FSP will } be developed which you use a non-hardcoded TCP port and } then won't you be back in the same boat? Or a cloaking } version of FSP which uses multiple TCP ports... } } }-- End of excerpt from David Spencer What do you mean by ``cloaking version of FSP''? Do you think it is possible to fool up a firewall by just changing a port number? If so then any nasty hacker just have to set up a non-standard telnet daemon which binds to port 37672 and you won't notice he's accessing your system. Regards, David -- David Vincenzetti, system administrator DSI, Department of Computer Science, email: vince@ghost.dsi.unimi.it via Comelico 39, 20135 Milan, ITALY phone: ++39 2 55006 391 **public key available by finger(1)** fax: ++39 2 55006 373 From Firewalls-Owner Thu May 13 20:47:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05132; Thu, 13 May 93 20:47:08 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05125; Thu, 13 May 93 13:47:01 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA11699; Thu, 13 May 93 16:49:27 EDT Date: Thu, 13 May 93 16:49:27 EDT From: Marcus J Ranum Message-Id: <9305132049.AA11699@TIS.COM> To: Firewalls@GreatCircle.COM, vince@dsi.unimi.it Subject: Re: New file transfer protocol: FSP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk If you're really torqued off about FSP, stop using screening router based firewalls and/or put a system with ipforwarding turned off between them. That'll solve the problem by putting a bullet through it. Before anyone flames me: Yes, I think this is reasonable, depending on what your policy is. If, as a firewall administrator, you have a requirement to block obnoxious traffic, the best way to do so is to block ALL traffic and force traffic to run through proxies with logging and authentication. It's draconian, but like many draconian solutions, it's effective. mjr. From Firewalls-Owner Thu May 13 22:00:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05352; Thu, 13 May 93 22:00:05 GMT Received: from gateway.Ameritech.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05338; Thu, 13 May 93 14:59:55 PDT Received: from [144.148.16.1] by gateway.Ameritech.COM with SMTP (5.65/25-eef) id AA04837; Thu, 13 May 93 16:56:11 -0500 Received: by nast0.bdy.wi.ameritech.com (5.65/25-eef) id AA02873; Thu, 13 May 93 21:58:44 GMT From: Andrew D. Kailhofer Message-Id: <9305132158.AA02873@nast0.bdy.wi.ameritech.com> Subject: packet forwarding To: firewalls@GreatCircle.COM Date: Thu, 13 May 93 16:58:43 CDT X-Zippy: My haircut is totally traditional! X-Mailer: ELM [version 2.3 PL8] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Mr. and Ms. Firewall: ;-) Sorry if this has just come up, but I saw a reference to "turning packet forwarding off." It really torques me off to admit to ignorance, but I thought that you had to be running something like gated for packet forwarding to occur. Is this not true? Even though I have a pair of very draconian routers restricting many things for me I still don't want something nasty like packet forwarding to be going on. Can someone clue me in to the real answer? At least for a Sun 3 running SunOS 4.1.1, that is... Thanks. -- Andy Kailhofer Ameritech Services, Inc. 414/678-7793 a907932@nast0.bdy.wi.ameritech.com FAX: 414/678-6335 740 N Broadway, Room 430, Milwaukee, WI 53202 Member: League for uwm.edu!gus!a907932 postmaster@ameritech.com Programming Freedom From Firewalls-Owner Thu May 13 22:57:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05463; Thu, 13 May 93 22:57:09 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05456; Thu, 13 May 93 15:57:02 PDT Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA20422; Thu, 13 May 93 17:57:38 CDT Date: Thu, 13 May 93 17:57:38 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9305132257.AA20422@tadpole.tadpole.com> To: firewalls@GreatCircle.COM, a907932@nast0.bdy.wi.ameritech.com Subject: Re: packet forwarding Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk echo "ip_forwarding/W 0" | adb -k -w /vmunix /dev/mem In previous versions of SunOS 'ip_forwarding' is 'ipforwarding'. Change the '/' to a '?' and reboot if you want a permanent change, or don't want to be exposed until rc.foo runs the command for you. Jim From Firewalls-Owner Fri May 14 00:57:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06810; Fri, 14 May 93 00:57:56 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06803; Thu, 13 May 93 17:57:47 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA21931; Thu, 13 May 93 20:57:38 EDT Date: Thu, 13 May 93 20:57:38 EDT From: Marcus J Ranum Message-Id: <9305140057.AA21931@TIS.COM> To: a907932@nast0.bdy.wi.ameritech.com, firewalls@GreatCircle.COM Subject: Re: packet forwarding Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Sorry if this has just come up, but I saw a reference to "turning >packet forwarding off." It really torques me off to admit to >ignorance, but I thought that you had to be running something like >gated for packet forwarding to occur. Packet forwarding's the default in every version of UNIX I can think of. Basically it means that the kernel will try to route traffic. In IP, the kernel routes packets towards the destination, based on its internal routing tables. Most systems are 'end nodes' and only get packets destined for them, so it's not an issue - the routing table just tells it where to send stuff that's going to systems off the immediate local network. Gated/routed and so on, manage routing tables. The management of routing tables is outside of the kernel, in applications that talk various routing protocols, and then manipulate the in-kernel routing tables using kernel calls. This is a pretty clever design decision, because it means your routing table management rules are outside of the kernel - the kernel doesn't have to know RIP, EGP, BGP, etc, etc, etc. So, don't confused gated/routed with routing. The kernel handles the routing, and gated/routed handle the routing tables. If ipforwarding is off, if the kernel gets a packet IN, which the routing tables tell it it should send OUT, it doesn't. This is one of the earliest forms of firewall: you just have a machine with 2 network interfaces and ipforwarding turned off. Both sides can talk *to* it, but neither can talk *across* it. The side effect is that no traffic is directly routed between networks - so stuff like FSP (in fact anything that doesn't go through a proxy forwarder or doesn't work in store-and-forward mode) doesn't work. mjr. From Firewalls-Owner Fri May 14 01:38:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06950; Fri, 14 May 93 01:38:58 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06940; Thu, 13 May 93 18:38:19 PDT Message-Id: <9305140138.AA06940@mycroft.GreatCircle.COM> To: vince@dsi.unimi.it (David Vincenzetti) Cc: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Thu, 13 May 1993 22:10:42 +0000 Date: Thu, 13 May 93 18:38:18 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk vince@dsi.unimi.it (David Vincenzetti) writes: # What do you mean by ``cloaking version of FSP''? Do you think it is # possible to fool up a firewall by just changing a port number? If so # then any nasty hacker just have to set up a non-standard telnet daemon # which binds to port 37672 and you won't notice he's accessing your system. What makes you think it _isn't_ possible? There has to be something listening at that port on your internal system, that's all. If your firewall allows outbound TELNET (internal TELNET client talking to external TELNET server), then it allows TCP packets from internal ports at or above 1024 to external ports 23, and from external ports 23 to internal ports above 1024. Unless your filtering implementation has an "established" check that you are using (most don't, and the ones that do usually can't be used anyway because they interfere with FTP), then somebody on the outside can start up a client at port 23 at their end (which is normally the TELNET server port), and talk to any TCP server above 1024 on your internal system. What TCP servers might be listening above 1024 on your internal systems, you ask? Oh, how about X and OpenWindows, for starters; the mischief to be found there ought to keep the crackers busy for months or years. How about Sybase, or Oracle, or any other TCP-based service that doesn't necessarily run as root (and even quite a few that do)? A cracker might not know exactly what port your Sybase server uses (it's a site-configurable option), but if he suspects you have a Sybase server, he can just try all the ports until he finds it. This is why I strongly recommend blocking the TCP ports where you know you've got servers listening internally. This especially includes 2000 to 2000+N for OpenWin and 6000 to 6000+N for X; each uses x000+N for the Nth display on a given machine, so you need to block as many ports as the greatest number of displays on any machine. It also include any known internal TCP servers such as database servers. UDP is even trickier, because there's more stuff listening above 1024 (NFS, YP, etc.), you can't tell just where much of it is listening (RPC-based services use essentially random UDP port numbers; the only well-known-port related to RPC is the portmapper port; an RPC client connects to that port to find out exactly what UDP port the RPC service it's interested in is living on at the moment on that particular machine), and there's no way to implement anything like the "established" keyword that some routers use for TCP filtering. For these reasons, I recommend blocking UDP all together, except for specific server-to-server conversations for specific protocols (DNS, NTP, maybe RIP, etc.). -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu May 13 19:21:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07096; Fri, 14 May 93 01:59:40 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07089; Thu, 13 May 93 18:59:31 PDT Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA20895; Thu, 13 May 93 20:58:04 CDT Date: Thu, 13 May 93 20:58:04 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9305140158.AA20895@tadpole.tadpole.com> To: a907932@nast0.bdy.wi.ameritech.com, firewalls@GreatCircle.COM, mjr@TIS.COM Subject: Re: packet forwarding Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >Sorry if this has just come up, but I saw a reference to "turning > >packet forwarding off." It really torques me off to admit to > >ignorance, but I thought that you had to be running something like > >gated for packet forwarding to occur. > > Packet forwarding's the default in every version of UNIX > I can think of. Basically it means that the kernel will try to > route traffic. Just to be clear, most systems should *NOT* forward packets. Only machines with more than one interface (other than the loopback interface), should forward IP datagrams. To do otherwise is to invite broadcast storms and other such ilk that will bring your once stable network to its knees. Jim From Firewalls-Owner Thu May 13 21:55:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07688; Fri, 14 May 93 04:42:27 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07524; Thu, 13 May 93 21:41:31 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA18665; Fri, 14 May 93 14:15:37 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9305140415.AA18665@coombs.anu.edu.au> Subject: Re: New file transfer protocol: FSP To: dspencer@mproj.retix.com (David Spencer) Date: Fri, 14 May 93 14:15:35 EST Cc: Firewalls@GreatCircle.COM In-Reply-To: <9305131624.AA05422@mproj.retix.com>; from "David Spencer" at May 13, 93 9:24 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In some email I received from David Spencer, Sie wrote: > > > > > On Wed, 12 May 1993, Brent Chapman wrote: > > > > ... > > > > Suggestions have ranged from denying Internet access to all students, to > > blocking all UDP traffic except for essential services. So far no further > > action has been taken until we can come up with something that will be > > effective. Any suggestions? > > Yeah you can block UDP traffic but then 'v2' of FSP will > be developed which you use a non-hardcoded TCP port and > then won't you be back in the same boat? Or a cloaking > version of FSP which uses multiple TCP ports... This would at least partially solve the problem of FSP `flooding' network connections. Darren From Firewalls-Owner Fri May 14 07:58:19 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08707; Fri, 14 May 93 07:58:19 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08700; Fri, 14 May 93 00:56:39 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA22375 for ; Thu, 13 May 93 18:55:29 -0400 Received: from stimpys.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA16636; Thu, 13 May 93 18:09:52 EDT Received: from localhost by stimpys.imsi.com (4.1/SMI-4.1) id AA07074; Thu, 13 May 93 18:07:06 EDT Message-Id: <9305132207.AA07074@stimpys.imsi.com> To: vince@dsi.unimi.it (David Vincenzetti) Cc: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of "Thu, 13 May 1993 22:10:42 -0000." <9305132010.AA09368@pluto.sm.dsi.unimi.it> Reply-To: rens@imsi.com Date: Thu, 13 May 1993 18:07:05 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Thu, 13 May 1993 22:10:42 +0000, vince@dsi.unimi.it (David Vincenzetti) said: vince> What do you mean by ``cloaking version of FSP''? Do you think vince> it is possible to fool up a firewall by just changing a port vince> number? If so then any nasty hacker just have to set up a vince> non-standard telnet daemon which binds to port 37672 and you vince> won't notice he's accessing your system. Exactly, assuming you are not filtering incoming SYN packets (in which case, say goodbye to FTP.) The bottom line - anyone on the inside will be able to compromise your most elaborate security measures. In security, there are no technical solutions to personnel problems. -Rens -- o===============================================================o | J. Laurens Troost - UNIX Systems | At Work: rens@imsi.com | | Investment Management Svcs, Inc. | At Play: rens@century.com | | 12 East 49th Street, 35th floor | Phone: (212) 339-2823 | | New York, New York 10017 | Fax: (212) 444-1980 | o===============================================================o -- IMS is unlikely to share any of the above opinions -- From Firewalls-Owner Fri May 14 10:03:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09009; Fri, 14 May 93 10:03:46 GMT Received: from pluto.sm.dsi.unimi.it by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09002; Fri, 14 May 93 03:03:35 PDT Received: by pluto.sm.dsi.unimi.it (16.7/16.2) id AA24275; Fri, 14 May 93 11:44:03 +0200 Message-Id: <9305140944.AA24275@pluto.sm.dsi.unimi.it> From: vince@dsi.unimi.it (David Vincenzetti) Date: Fri, 14 May 1993 11:44:03 +0000 In-Reply-To: Brent Chapman "Re: New file transfer protocol: FSP" (May 13, 6:38pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Brent Chapman Subject: Re: New file transfer protocol: FSP Cc: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On May 13, 6:38pm, Brent Chapman wrote: } Subject: Re: New file transfer protocol: FSP } vince@dsi.unimi.it (David Vincenzetti) writes: } } # What do you mean by ``cloaking version of FSP''? Do you think it is } # possible to fool up a firewall by just changing a port number? If so } # then any nasty hacker just have to set up a non-standard telnet daemon } # which binds to port 37672 and you won't notice he's accessing your system. } } What makes you think it _isn't_ possible? There has to be something } listening at that port on your internal system, that's all. } } If your firewall allows outbound TELNET (internal TELNET client } talking to external TELNET server), then it allows TCP packets from } internal ports at or above 1024 to external ports 23, and from } external ports 23 to internal ports above 1024. Unless your filtering } implementation has an "established" check that you are using (most } don't, and the ones that do usually can't be used anyway because they } interfere with FTP), then somebody on the outside can start up a } client at port 23 at their end (which is normally the TELNET server } port), and talk to any TCP server above 1024 on your internal system. }-- End of excerpt from Brent Chapman Suppose you have the following masks: deny ip 0.0.0.0 255.255.255.255 143.191.19.67 0.0.0.0 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 then I suppose that all inbound traffic is blocked while outgoing traffic is all right. A little exception for the ftp protocol: since the daemon establishes a connection on a random port above 1024 ftp won't work. Anyway this scheme seems to me quite secure (although very brutal). Am I missing something? From Firewalls-Owner Fri May 14 17:22:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09997; Fri, 14 May 93 17:22:53 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09989; Fri, 14 May 93 10:22:16 PDT Message-Id: <9305141722.AA09989@mycroft.GreatCircle.COM> To: vince@dsi.unimi.it (David Vincenzetti) Cc: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Fri, 14 May 1993 11:44:03 +0000 Date: Fri, 14 May 93 10:22:14 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk vince@dsi.unimi.it (David Vincenzetti) writes # Suppose you have the following masks: # # deny ip 0.0.0.0 255.255.255.255 143.191.19.67 0.0.0.0 # permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 # # then I suppose that all inbound traffic is blocked while outgoing traffic # is all right. A little exception for the ftp protocol: since the daemon # establishes a connection on a random port above 1024 ftp won't work. # Anyway this scheme seems to me quite secure (although very brutal). # # Am I missing something? You're confusing inbound and outbound at the service level with inbound and outbound at the packet level. An "outbound" service, such as using TELNET from an internal client to an external server, involves both outbound packets (what you type, from the client to the server) and inbound packets (what the server responds with). Packet filters work at the packet level, not the service level. Implementing the filters you list above would mean that I could get packets out, but nobody could get packets back in; I wouldn't be able to use TELNET, for example, because the remote server wouldn't be able to get anything back to me. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Fri May 14 18:27:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10882; Fri, 14 May 93 18:27:47 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10875; Fri, 14 May 93 11:27:28 PDT Message-Id: <9305141827.AA10875@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Fri May 14 14:24:43 EDT 1993 To: Firewalls@GreatCircle.COM Subject: Liability (was: Re: New file transfer protocol: FSP ) Date: Fri, 14 May 93 14:24:43 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Besides, if you've denied him access, and he's on the computers anyway, he's illegally using your resources. I think your liability concerns go away in this scenario. I've lost the context of what is meant here by liability; however, I've found an interesting court case, from 1932. It concerns liability for the cargo of a barge lost in a storm -- a loss that likely would have been avoided if the tugboat had been equipped with a radio receiver to hear a weather forecast. But here there was no custom at all as to receiving sets; some had them, some did not; the most that can be urged is that they had not yet become general. Certainly in such a case we need not pause; when some have thought a device necessary, at least we may say that they were right, and the others too slack. ... We hold [against] the tugs therefore because [if] they had been properly equipped, they would have got the Arlington reports. The injury was a direct consequence of this unseaworthiness. (The T.J. Hooper, 60 F.2d 737 (2d Cir. 1932)) That is, the tugboat owners were held liable for not taking a precaution that, though reasonable, wasn't even customary in their industry. (Only one tugboat line equipped its ships with radios.) I wonder what level of security a court would hold to be necessary if a third party suffered some losses because of the actions of a hacker. --Steve Bellovin From Firewalls-Owner Fri May 14 18:58:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10985; Fri, 14 May 93 18:58:04 GMT Received: from whistler.sfu.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10978; Fri, 14 May 93 11:57:50 PDT Received: from kits.sfu.ca by whistler.sfu.ca (5.65/SFU-2.0) id AA15044; Fri, 14 May 93 11:58:52 -0700 Received: by kits.sfu.ca (4.1/SMI-4.1) id AA17161; Fri, 14 May 93 11:56:29 PDT From: chowes@sfu.ca (Charles Howes) Message-Id: <9305141856.AA17161@kits.sfu.ca> Subject: Proxy Xwindows? To: Firewalls@GreatCircle.COM Date: Fri, 14 May 93 11:56:28 BST In-Reply-To: <9305140800.AA08739@mycroft.GreatCircle.COM>; from "Firewalls-Digest-Owner@GreatCircle.COM" at May 14, 93 1:00 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Speaking of proxy services, is there such a thing as proxy Xwindows? I've got three machines. I sit at the first one (a Next), and can telnet to the second one, and from the second one I can telnet to the third. Xwindows has been installed on all of the machines. I can use xwindow clients on the second machine, but I find that I can't use xwindow clients on the third machine, because on this network, 'you can't get there from here'. The 'obvious' solution is to modify routing tables, but that becomes very messy very fast, and destroys the 'firewallness' of the second machine. I'd much rather just run a proxy xwindow client on the second machine, which behaves like a server to the third machine and a client to the first. Needless to say, it would log everything, as do all other proxy services. Does a beast like this exist? Where would I find it? Thank you for your time. Charles Howes -- chowes@sfu.ca From Firewalls-Owner Fri May 14 20:55:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11381; Fri, 14 May 93 20:55:37 GMT Received: from gatekeeper.es.dupont.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11374; Fri, 14 May 93 13:55:30 PDT Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991); id AA14933; Fri, 14 May 93 16:56:40 -0400 Received: from fallst.es.dupont.com by eplrx7.es.duPont.com (4.1/kdm-082991-main) id AA08481; Fri, 14 May 93 16:54:32 EDT Received: by fallst.es.dupont.com (Smail3.1.28.1 #1) id m0nu6mv-000GLaC; Fri, 14 May 93 16:55 EDT Message-Id: From: tkevans@fallst.es.dupont.com (Tim Evans) Subject: DNS in Firewalled Environment To: firewalls@GreatCircle.COM Date: Fri, 14 May 1993 16:55:28 -0400 (EDT) Phone: (410) 877-7890; (302) 695-9353 Reply-To: tkevans@eplrx7.es.duPont.com X-Mailer: ELM [version 2.4 PL22beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 477 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'd like to hear peoples' views on appropriate ways to set up DNS in firewalled environments, particularly with respect to preventing information about hosts inside the firewall from being broadcast to the world at large via DNS, while at the same time providing info about the world outside to all the internal hosts. Thanks. -- UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans INTERNET: tkevans@fallst.es.dupont.com Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047 From Firewalls-Owner Fri May 14 21:18:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11424; Fri, 14 May 93 21:18:02 GMT Received: from hal.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11417; Fri, 14 May 93 14:17:53 PDT Received: from gorn.hal.com by hal.com (4.1/SMI-4.1.1) id AA20678; Fri, 14 May 93 14:18:39 PDT Received: by gorn.hal.com (4.1/SMI-4.1.2) id AA24449; Fri, 14 May 93 14:18:38 PDT Date: Fri, 14 May 93 14:18:38 PDT From: jonl@hal.com (frederick smythe, esquire) Message-Id: <9305142118.AA24449@gorn.hal.com> To: Firewalls@GreatCircle.COM, chowes@sfu.ca Subject: Re: Proxy Xwindows? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk there is a program called "xmx" which i use occasionally in an environment exactly like you describe. it doesn't offer much in the ways of security for itself, but allows you to only have an x port up for limited periods of time. here's a bit of info from the README: The Computer Science Department at Brown University distributes XMX under the following Copyright: Copyright 1988, 1989, 1990, Brown University, Providence, RI. Permission to use, copy, modify and distribute this software and its documentation for any purpose other than its incorporation into a commercial product, is hereby granted, provided that this copyright notice appears on all copies and the distribution is only within the organization represented by the person receiving the software from Brown. Brown requests notification of any important modifications to this software or its documentation. Please note that we explicity prohibit you from distributing this outside of your organization. Tell them to get it from us. XMX was written by John Bazik Dept. of Computer Science, Box 1910 Brown University Providence, RI 02912 (401) 863-7600 jsb@cs.brown.edu uunet!brunix!jsb jsb@browncs.bitnet From Firewalls-Owner Sun May 16 21:10:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17367; Sun, 16 May 93 21:10:41 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17356; Sun, 16 May 93 14:10:34 PDT Message-Id: <9305162110.AA17356@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Firewalls Calendar of Events Date: Sun, 16 May 93 14:10:33 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Firewalls Calendar of Events 15 May 1993 ============================ =========== This document is a calendar of upcoming events of interest to the Firewalls community. It is updated as needed, published to the Firewalls mailing list monthly, and always available for anonymous FTP from FTP.GreatCircle.COM, file "pub/firewalls/calendar". If you have an event that you would like to have added to this calendar, please send me the details by Email, FAX, or US Mail (in that order of preference). Any upcoming event relevant to Firewalls is welcome, including local seminars and meetings. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street Phone: +1 415 962 0841 Mountain View, CA 94041 FAX: +1 415 962 0842 Events (see below for Deadlines and Details) ============================================ June 21-25, 1993 USENIX Summer 1993 Technical Conference Cincinnati, Ohio, USA July 7-9, 1993 SAGE-AU'93 Conference (System Administrators Guild, Australia) Melbourne, Australia October 4-7, 1993 Fourth USENIX Security Symposium Santa Clara, California, USA November 1-5, 1993 Seventh USENIX Systems Administration Conference (LISA VII) Monterey, California, USA Deadlines ========= June 4, 1993 Extended abstracts for Fourth USENIX Security Symposium July 2, 1993 Extended abstracts due for LISA VII August 15, 1993 Final papers for Fourth USENIX Security Symposium September 7, 1993 Final papers for LISA VII Details ======= June 21-25, 1993 USENIX Summer 1993 Technical Conference Cincinnati, Ohio, USA 6/22/93 "Achieving Security in an Internet Environment" One-day tutorial by Tina Darmohray (Lawrence Livermore National Laboratories) and Rob Kolstad (Berkeley Software Design, Inc.) "Five Years of Gateways and Hackers" Invited talk by Bill Cheswick (AT&T Bell Laboratories) "X Through the Firewall, and Other Application Relays" Paper by Win Treese (MIT LCS and Digital Equipment Corporation) and Alec Wolman (University of Washington and Digital Equipment Corporation) 6/24/93 "Highlights from the 3rd USENIX UNIX Security Symposium" Session chaired by Ed DeHart (CERT) offering selected papers, including: "Network (In)Security Through IP Packet Filtering" Brent Chapman (Great Circle Associates) Firewalls Birds-of-a-Feather (BOF) session Informal discussion of firewalls-related topics, following the CERT BOF. Moderated by Brent Chapman (Great Circle Associates) Conference registration: Package Before 6/1/93 After 6/1/93 ======= ============= ============ One full-day tutorial $275 $325 Conference - USENIX member $295 $345 Conference - non-member $360 $410 Conference - student $ 75 $ 75 To register, or for more info: Contact: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA USA 92630 Phone: +1 (714) 588-8649 FAX: +1 (714) 588-9706 Email: conference@usenix.org Check the "comp.org.usenix" newsgroup -------- July 7-9, 1993 SAGE-AU'93 Melbourne, Australia Details and program being finalized. Probably a Firewalls tutorial by Brent Chapman (Great Circle Associates). Probably a Firewalls BOF. Registration (not including tutorials) $100 for SAGE-AU members $150 for non-members For further information, contact: Peter Gray Professional Officer Dept. of Computer Science University of Wollongong N.S.W. 2500 Australia Email: pdg@cs.uow.edu.au Phone: +61 42 213770 FAX: +61 42 213262 -------- October 4-7, 1993 Fourth USENIX Security Symposium Santa Clara, California, USA One day of tutorials Two and one half days of technical sessions Probably a Firewalls BOF Call for Papers has been issued Extended abstracts due June 4, 1993 Program committee decisions due June 30, 1993 Final papers due August 15, 1993 Program and registration materials to be available July, 1993 For program information (including for prospective authors), contact: Bill Cheswick AT&T Bell Laboratories Room 2c416 600 Mountain Ave. Murry Hill, NJ 07974 Email: ches@research.att.com For registration information (available July, 1993), contact: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA USA 92630 Phone: +1 (714) 588-8649 FAX: +1 (714) 588-9706 Email: conference@usenix.org -------- November 1-5, 1993 Seventh USENIX Systems Administration Conference (LISA VII) Monterey, California, USA Two days of tutorials Three days of technical sessions Conference theme is "The Human Aspect of UNIX System Administration" Probably a Firewalls BOF Call for Papers has been issued Extended abstracts due July 2, 1993 Notification to authors due July 23, 1993 Final papers due September 7, 1993 Program and registration materials to be available August, 1993. For program information (including for prospective authors), contact Bjorn Satdeva (Program Chair) /sys/admin, Inc. 2787 Moorpark Ave San Jose, CA USA 95128 Phone: +1 (408) 241-3111 Email: bjorn@sysadmin.com For registration information (available August, 1993), contact: USENIX Conference Office 22672 Lambert St., Suite 613 Lake Forest, CA USA 92630 Phone: +1 (714) 588-8649 FAX: +1 (714) 588-9706 Email: conference@usenix.org From Firewalls-Owner Sun May 16 23:06:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17895; Sun, 16 May 93 23:06:48 GMT Received: from antares.mcs.anl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17888; Sun, 16 May 93 16:06:38 PDT Received: from skeeve.mcs.anl.gov by antares.mcs.anl.gov with SMTP id AA07223 (5.65c/IDA-1.4.4 for ); Sun, 16 May 1993 18:07:17 -0500 Message-Id: <199305162307.AA07223@antares.mcs.anl.gov> To: firewalls@GreatCircle.COM Subject: To go with the discussion of FSP and version 2++ Date: Sun, 16 May 1993 18:07:15 -0500 From: Gene Rackow Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I just found this on the comp.sources.testers news group. Granted he makes it sound like a good reason to have a "repeater" for fsp, but merging that with the comments from this list, watch out... --gene ------- Forwarded Message > From: pete@sst.icl.co.uk (Pete Bevin) > Newsgroups: alt.comp.fsp,comp.sources.testers > Subject: Testers wanted for FSP Repeater Daemon > Summary: Quick way to get famous > Message-ID: <1993May16.220329.17540@sst.icl.co.uk> > Date: 16 May 93 21:06:28 GMT > Sender: news@dsbc.icl.co.uk > Followup-To: alt.comp.fsp > Organization: Bracknell Lonely Hearts Club (Society Flirt) > Lines: 82 > Nntp-Posting-Host: sst.icl.co.uk > Originator: pete@jura > > [If you're reading comp.sources.testers and you don't know what FSP is, > then stop reading now!] > > I'm looking for people to test a repeater daemon for FSP. Its purpose > in life is to relay FSP packets between a client and a remote server. > (There are very good reasons why you might want to do this -- see > below). > > [Someone put some code out last week called fsprep0.1.tar.Z. This code > has nothing to do with it.] > > The code is currently pre-alpha, meaning that it may well not work on a > wide variety of systems. But the more people who test it, the better... > > Please don't volunteer to test the code, unless: > > - You're confident hacking C > - You're prepared not to pass the code on to anyone. > > Thanks in advance to all testers! > > Pete. > > > > >From the README file: > - ------------------------------------------------------------------------- > FSP repeater daemon version 0.0-a (pre-alpha) > (C) 1993 Pete Bevin. All rights reserved. You are expressly forbidden > from giving away copies of this code without the author's permission. > > > The FSP Repeater Daemon > ======================= > > I wrote this program because my local machine (alice) isn't on the > internet, but I have an account on another machine (bobby) that is. > Before I wrote this, to get hold of a file from (say) wuarchive, I'd > have to get it in two stages: from wuarchive to bobby, and then from > bobby to alice. Using the repeater daemon, I can fire FSP packets at > bobby, and have it relay them to and from remote sites. > > You could also use this code to hide the real address of an FSP site. > You'd run the repeater daemon on the site whose address you give out, > and have it relay packets to the `real' FSP daemon. > > The repeater daemon can route to and from multiple FSP sites. I > currently bag about ten ports on bobby, each corresponding to a > different site. The daemon reads in a file called ".reprc" on startup, > which might look a bit like this: > > 2000 146.169.2.1 21 # src.doc.ic.ac.uk > 2001 128.2.206.138 30 # seismo.soar.cs.cmu.edu > 2002 192.76.144.75 2001 # ftp.Germany.EU.net > > Each line has three entries (the comments are ignored because they form > the 4th, 5th, ... fields). The second and third field are the remote > site's IP address and port number, and the first field is the port > number on the local machine which will pretend to be the remote site. > So connecting to bobby:2000 will get me to the Imperial College archive, > bobby:2001 will get me to Joseph Traub's site at CMU, and so on. > > > > > Bugs, problems, future enhancements, etc > ======================================== > > The daemon needs two ports per remote site: one to communicate with the > remote site, and one to communicate with the client. The port it uses > for the remote site is arbitrary, but at the moment, it gets it in a > badly hacked way. > > The daemon won't properly handle two clients on the same port. ("I've > just got a packet from seismo. Now which client do I send it back to?") > But there isn't any problem with multiple clients on different ports. > > Would be nice to have a `configuration' port allowing the daemon to add > new remote sites dynamically. > > Pete Bevin > 16-May-93 > > ------- End of Forwarded Message From Firewalls-Owner Mon May 17 05:49:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19121; Mon, 17 May 93 05:49:21 GMT Received: from hunts.x.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19114; Sun, 16 May 93 22:49:12 PDT Message-Id: <9305170549.AA19114@mycroft.GreatCircle.COM> Received: by hunts.x.co.uk with v1.37.109.4; Mon, 17 May 93 06:50:56 +0100 From: clive@x.co.uk (Clive Feather) Subject: Re: Proxy Xwindows? To: chowes@sfu.ca (Charles Howes) (Charles Howes) Date: Mon, 17 May 93 6:50:55 BST Cc: Firewalls@GreatCircle.COM In-Reply-To: <9305141856.AA17161@kits.sfu.ca>; from "Charles Howes" at May 14, 93 11:56 am Mailer: Elm [revision: 70.85] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Speaking of proxy services, is there such a thing as proxy Xwindows? [...] > I'd much rather just run a proxy xwindow client on the second > machine, which behaves like a server to the third machine and a client > to the first. Needless to say, it would log everything, as do all > other proxy services. I've got the framework for one put together (it doesn't log, but it does ask the server owner for permission to connect each connection attempt). It's got some bugs in the UI still. I'm away for a week or so, but I'll go into it when I get back. -- Clive D.W. Feather | IXI Ltd (an SCO company) | If you lie to the compiler, clive@x.co.uk | Vision Park | it will get its revenge. Phone: +44 223 236 555 | Cambridge CB4 4ZR | - Henry Spencer Fax: +44 223 236 466 | United Kingdom | From Firewalls-Owner Mon May 17 12:20:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20603; Mon, 17 May 93 12:20:12 GMT Received: from rs (rs.internic.net) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20596; Mon, 17 May 93 05:20:06 PDT Received: from ceco.com (firewall.ceco.com) by rs (4.1/SMI-4.1) id AA15791; Mon, 17 May 93 08:17:16 EDT Received: from ceco.ceco.com ([130.197.8.140]) by ceco.com (4.1/SMI-4.1) id AA12831; Mon, 17 May 93 07:20:15 CDT Received: from condor.pcs_4.1 by ceco.ceco.com (4.1/SMI-4.1) id AA12539; Mon, 17 May 93 07:20:33 CDT Date: Mon, 17 May 93 07:20:33 CDT From: lyle@ceco.ceco.com (Lyle M. Holman) Message-Id: <9305171220.AA12539@ceco.ceco.com> To: firewalls@GreatCircle.COM Subject: Public domain version of igateway Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am trying to set up our firewall to act as a relay host for telnet and ftp clients and I am looking for a public domain software that is similar to Sun's igateway. Someone on the Internet suggested that someone here might know the name and location of such software. Thanks in advance. Lyle Holman Engineer Commonwealth Edison 125 South Clark Room 422 Chicago, IL 60603 312 394 - 8572 312 394 - 3361 FAX lyle@ceco.com From Firewalls-Owner Mon May 17 15:40:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20937; Mon, 17 May 93 15:40:58 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20930; Mon, 17 May 93 08:40:49 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14424>; Mon, 17 May 1993 11:41:14 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA20811 (5.65a/IDA-1.4.2 for rackow@mcs.anl.gov); Mon, 17 May 93 11:27:00 -0400 Received: by dino.alias.com id AA06458 (5.65a/IDA-1.4.2 for firewalls@GreatCircle.COM); Mon, 17 May 93 11:26:57 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9305171526.AA06458@dino.alias.com> Subject: Re: To go with the discussion of FSP and version 2++ To: rackow@mcs.anl.gov (Gene Rackow) Date: Mon, 17 May 1993 12:26:54 -0400 Cc: firewalls@GreatCircle.COM In-Reply-To: <199305162307.AA07223@antares.mcs.anl.gov> from "Gene Rackow" at May 16, 93 07:07:15 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 927 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I just found this on the comp.sources.testers news group. Granted he > makes it sound like a good reason to have a "repeater" for fsp, but > merging that with the comments from this list, watch out... Heh. the number two reason for the FSP repeater was site-address hiding... :-) > You could also use this code to hide the real address of an FSP site. > You'd run the repeater daemon on the site whose address you give out, > and have it relay packets to the `real' FSP daemon. Overall, it definitely sounds like these guys are re-inventing TCP/IP (session control/routing) over UDP, badly, for 'nebulous' reasons... -- C. Harald Koch, Network Manager | "There is no problem, no matter how large or Alias Research Inc. Toronto, ON | small, that cannot be solved by a suitable chk@alias.com | amount of high explosives." chk@gpu.utcc.utoronto.ca | -Leo Graf, USS LaFarge, 2298 From Firewalls-Owner Mon May 17 15:50:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20961; Mon, 17 May 93 15:50:35 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20954; Mon, 17 May 93 08:50:29 PDT Message-Id: <9305171550.AA20954@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Mon, 17 May 93 11:48:03 EDT To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Folks, The extended abstract deadline is looming for the security symposium. The work done by the people on this list is certainly relevant, and I invite you to submit papers. Bill Cheswick Bell Labs From Firewalls-Owner Mon May 17 16:41:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21536; Mon, 17 May 93 16:41:51 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20961; Mon, 17 May 93 15:50:35 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20954; Mon, 17 May 93 08:50:29 PDT Message-Id: <9305171550.AA20954@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Mon, 17 May 93 11:48:03 EDT To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Folks, The extended abstract deadline is looming for the security symposium. The work done by the people on this list is certainly relevant, and I invite you to submit papers. Bill Cheswick Bell Labs From Firewalls-Owner Mon May 17 09:51:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21236; Mon, 17 May 93 16:22:19 GMT Received: from rs (rs.internic.net) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20596; Mon, 17 May 93 05:20:06 PDT Received: from ceco.com (firewall.ceco.com) by rs (4.1/SMI-4.1) id AA15791; Mon, 17 May 93 08:17:16 EDT Received: from ceco.ceco.com ([130.197.8.140]) by ceco.com (4.1/SMI-4.1) id AA12831; Mon, 17 May 93 07:20:15 CDT Received: from condor.pcs_4.1 by ceco.ceco.com (4.1/SMI-4.1) id AA12539; Mon, 17 May 93 07:20:33 CDT Date: Mon, 17 May 93 07:20:33 CDT From: lyle@ceco.ceco.com (Lyle M. Holman) Message-Id: <9305171220.AA12539@ceco.ceco.com> To: firewalls@GreatCircle.COM Subject: Public domain version of igateway Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am trying to set up our firewall to act as a relay host for telnet and ftp clients and I am looking for a public domain software that is similar to Sun's igateway. Someone on the Internet suggested that someone here might know the name and location of such software. Thanks in advance. Lyle Holman Engineer Commonwealth Edison 125 South Clark Room 422 Chicago, IL 60603 312 394 - 8572 312 394 - 3361 FAX lyle@ceco.com From Firewalls-Owner Mon May 17 10:21:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21425; Mon, 17 May 93 16:30:47 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21417; Mon, 17 May 93 09:30:42 PDT Message-Id: <9305171630.AA21417@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Apologies for duplicate messages Date: Mon, 17 May 93 09:30:41 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk My apologies for the duplicate messages that some of you may be seeing from the Firewalls mailing list this morning. There was a problem with the mailing list last night, and messages sent within the last few hours got forwarded to some but not all Firewalls subscribers. I'll take care of reforwarding the affected messages from here; please don't resubmit anything. Thanks! -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon May 17 10:51:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21308; Mon, 17 May 93 16:27:38 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20930; Mon, 17 May 93 08:40:49 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14424>; Mon, 17 May 1993 11:41:14 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA20811 (5.65a/IDA-1.4.2 for rackow@mcs.anl.gov); Mon, 17 May 93 11:27:00 -0400 Received: by dino.alias.com id AA06458 (5.65a/IDA-1.4.2 for firewalls@GreatCircle.COM); Mon, 17 May 93 11:26:57 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9305171526.AA06458@dino.alias.com> Subject: Re: To go with the discussion of FSP and version 2++ To: rackow@mcs.anl.gov (Gene Rackow) Date: Mon, 17 May 1993 12:26:54 -0400 Cc: firewalls@GreatCircle.COM In-Reply-To: <199305162307.AA07223@antares.mcs.anl.gov> from "Gene Rackow" at May 16, 93 07:07:15 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 927 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I just found this on the comp.sources.testers news group. Granted he > makes it sound like a good reason to have a "repeater" for fsp, but > merging that with the comments from this list, watch out... Heh. the number two reason for the FSP repeater was site-address hiding... :-) > You could also use this code to hide the real address of an FSP site. > You'd run the repeater daemon on the site whose address you give out, > and have it relay packets to the `real' FSP daemon. Overall, it definitely sounds like these guys are re-inventing TCP/IP (session control/routing) over UDP, badly, for 'nebulous' reasons... -- C. Harald Koch, Network Manager | "There is no problem, no matter how large or Alias Research Inc. Toronto, ON | small, that cannot be solved by a suitable chk@alias.com | amount of high explosives." chk@gpu.utcc.utoronto.ca | -Leo Graf, USS LaFarge, 2298 From Firewalls-Owner Mon May 17 22:29:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22735; Mon, 17 May 93 22:29:57 GMT Received: from muse.microunity.com (muse1.microunity.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22728; Mon, 17 May 93 15:29:43 PDT Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA18769; Mon, 17 May 93 15:30:26 PDT Received: from angst.microunity.com by gaea.microunity.com (4.1/muse1.3) id AA29551; Mon, 17 May 93 15:29:29 PDT Received: by angst.microunity.com (5.61/muse.mw-1) id AA08879; Mon, 17 May 93 15:29:53 -0700 From: ericm@angst.MicroUnity.com (Eric Murray) Message-Id: <9305172229.AA08879@angst.microunity.com> Subject: Re: New file transfer protocol: FSP To: brent@GreatCircle.COM (Brent Chapman) Date: Mon, 17 May 93 15:29:51 MDT Cc: Firewalls@GreatCircle.COM In-Reply-To: <9305140138.AA06940@mycroft.GreatCircle.COM>; from "Brent Chapman" at May 13, 93 6:38 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent Chapman wrote: [..] > UDP is even trickier, because there's more stuff listening above 1024 > (NFS, YP, etc.), you can't tell just where much of it is listening > (RPC-based services use essentially random UDP port numbers; the only > well-known-port related to RPC is the portmapper port; an RPC client > connects to that port to find out exactly what UDP port the RPC > service it's interested in is living on at the moment on that > particular machine), and there's no way to implement anything like the > "established" keyword that some routers use for TCP filtering. For > these reasons, I recommend blocking UDP all together, except for > specific server-to-server conversations for specific protocols (DNS, > NTP, maybe RIP, etc.). Along those lines, has anyone build a version of socks that supports proxy UDP services? I'm gonna start on it, but if there's already one out there then I'd use that. -- ericm ericm@microunity.com From Firewalls-Owner Tue May 18 17:33:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25429; Tue, 18 May 93 17:33:35 GMT Received: from sun2.nsfnet-relay.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25422; Tue, 18 May 93 10:33:25 PDT Via: uk.ac.buckscollege; Tue, 18 May 1993 16:33:39 +0100 From: "A.Bygrave" Date: Tue, 18 May 93 16:35:50 BST Message-Id: <2423.9305181535@buckscol.ac.uk> To: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have heard that there is some software which can sit on your server and allow one to operate an internal addressing scheme and communicate with the internet on another addressing scheme. I was told this was known as 'Firewalling' but I am not sure whether this is the correct term for it. If you have any information on this can you please let me know. Thanks. From Firewalls-Owner Tue May 18 22:47:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26694; Tue, 18 May 93 22:47:39 GMT Received: from cs.uchicago.edu (gargoyle.uchicago.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26686; Tue, 18 May 93 15:47:22 PDT Received: by cs.uchicago.edu (4.1/2.0) id AA03692; Tue, 18 May 93 17:48:28 CDT Date: Tue, 18 May 93 17:48:28 CDT From: Chris Johnston Message-Id: <9305182248.AA03692@cs.uchicago.edu> To: Firewalls@GreatCircle.COM Subject: Re: To go with the discussion of FSP and version 2++ Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello All, Let me see if I've got this right. FTP proxy servers are good. FSP repeaters are bad. :) IMHO Since neither FTP or FSP use cryptographic authentication, you can never know who is at the far end. :) Could the FBI wire tap spread spectrum FSP repeaters? :) Do the available TCP proxy servers require one side of the connection be inside the firewall and the other outside? If both the client and daemon FSP ports were "well known" would it be secure? Allegedly FSP presents a lighter load to the server and a heavier load to the network. Can it be fixed? Packet filtering "established" FTP connections is impossible since it uses two channels. FTP requires a separate server process for each connection. Clearly both FTP and FSP have drawbacks, perhaps it really is time to reinvent this service. How about a new file transfer service that only uses one channel, behaves well on slow links, has high throughput, presents a light load to the server, authenticates the user and encrypts the payload. regards, cj 312-786-4889 From Firewalls-Owner Tue May 18 23:40:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27041; Tue, 18 May 93 23:40:18 GMT Received: from csn.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27033; Tue, 18 May 93 16:40:11 PDT Received: from mhinfo.UUCP by csn.org with UUCP id AA11772 (5.65c/IDA-1.4.4 for greatcircle.com!firewalls); Tue, 18 May 1993 17:41:25 -0600 Subject: Turning off packet forwarding on SCO Unix V.3.2.4 To: firewalls@GreatCircle.COM Date: Tue, 18 May 1993 17:21:18 -0600 (MDT) From: Tony Carrato Reply-To: carrato@mhinfo.com X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 568 Message-Id: <9305181721.aa14650@mhinfo.mhinfo.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We've got SCO's TCP/IP, which is really the Lachman TCP/IP. I'd like to turn off IP forwarding. It looks like I can uncomment three lines from /etc/conf/pack.d/ip/space.c and rebuild TCP/IP. Does anyone know if this is correct? Tony ---------------------------------------------------------------------------- Tony Carrato Mile-High Information Services, Inc. carrato@mhinfo.com 9101 E. Kenyon Ave, Suite 3400 fax (303) 721-0281 Denver, CO 80237 voice (303) 721-0851 U.S.A. ---------------------------------------------------------------------------- From Firewalls-Owner Wed May 19 00:04:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27241; Wed, 19 May 93 00:04:14 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27234; Tue, 18 May 93 17:04:00 PDT Message-Id: <9305190004.AA27234@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Tue, 18 May 93 20:01:04 EDT To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've had several people express interest in submitting a paper to the security conference, and asking for details. Here is the conference announcement. We are fortunate to have Robert Morris Sr. giving the keynote. ANNOUNCEMENT/CALL FOR PAPERS 4th USENIX UNIX SECURITY SYMPOSIUM October 4-7, 1993 Santa Clara Marriott Hotel Santa Clara, California Sponsored by the USENIX Association In cooperation with: The Computer Emergency Response Team (CERT) and the Association for Computer Machinery (pending) The goal of this symposium is to bring together security practitioners, system administrators, system programmers, and others with an interest in computer security as it relates to networks and the UNIX operating system. This will be a three and one-half day, single-track symposium. The symposium will consist of tutorials, refereed and invited technical presentations, and panel sessions. The first day will be devoted to tutorial presentations, followed by two and one-half days of technical sessions. There will also be two evenings available for Birds-of-a-Feather sessions and Work-in-Progress sessions. TUTORIALS October 4, 1993 This one-day tutorial program will feature two tutorials, designed to address the needs of both management and technical attendees. The tutorials will supply overviews of various security mechanisms and policies. Each will provide specifics to the system and site administrator for implementing numerous local and network security precautions, firewalls, and monitoring systems. TECHNICAL SESSIONS October 5-7, 1993 In addition to refereed paper presentations, the program will include invited talks and panel sessions. The program committee invites you to submit proposals, ideas, or suggestions for these presentations Papers that have been formally reviewed and accepted will be presented during the symposium and published in the symposium proceedings. Symposium proceedings will be distributed free to technical sessions attendees during the symposium and after will be available for purchase from the USENIX Association. SYMPOSIUM TOPICS Papers are being solicited in areas including but not limited to: o User/system authentication o File system security o Network security o Security and system management o Security-enhanced versions of the UNIX operating system o Security tools o Network intrusions (including case studies and intrusion detection efforts) o Security on high-bandwidth networks DATES FOR REFEREED PAPER SUBMISSIONS Extended abstracts due: June 4, 1993 Program Committee decisions made: June 30, 1993 Camera-ready final papers due: August 15, 1993 REFEREED PAPER SUBMISSIONS: Send ASCII or Postscript submissions to: ches@research.att.com Send hard copy submissions to the program chair: Bill Cheswick AT&T Bell Laboratories Room 2c416 600 Mountain Ave. Murray Hill, NJ 07974 PROGRAM COMMITTEE Bill Cheswick, AT&T Bell Laboratories, Program Chair Steve Bellovin, AT&T Bell Laboratories Matt Bishop, Dartmouth College Ed DeHart, CERT, Carnegie Mellon University Jim Ellis, CERT, Carnegie Mellon University Marcus Ranum, Trusted Information Systems FOR REGISTRATION INFORMATION Materials containing all details of the symposium program, symposium registration fees and forms, and hotel discount and reservation information will be mailed beginning July 1993. If you wish to receive registration materials, please contact: USENIX Conference Office 22672 Lambert Street, Suite 613 El Toro, CA 92630 USA (714) 588-8649; FAX: (714) 588-9706 E-mail: conference@usenix.org USENIX The UNIX and Advanced Computing Systems Professional and Technical Association From Firewalls-Owner Wed May 19 00:35:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27545; Wed, 19 May 93 00:35:58 GMT Received: from alpha.xerox.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27538; Tue, 18 May 93 17:35:49 PDT Received: from vertigo.parc.xerox.com ([13.1.136.17]) by alpha.xerox.com with SMTP id <11866>; Tue, 18 May 1993 17:36:45 PDT Received: from 13.1.248.3 ([13.1.248.3]) by vertigo.parc.xerox.com with SMTP id <65925>; Tue, 18 May 1993 17:36:26 -0700 Date: Tue, 18 May 1993 18:41:12 PDT To: firewalls@GreatCircle.COM From: John Larson X-Sender: jlarson@vertigo.parc.xerox.com Subject: Firewall on dual-interface Sun running Solaris 2.x ? Cc: JLarson@parc.xerox.com Message-Id: <93May18.173626pdt.65925@vertigo.parc.xerox.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has anyone successfully installed a dual-interface type firewall on a Sun running Solaris 2.x ? (Including the usual suite of services: DNS, NTP, SMTP gateway, proxy gatway, anonymous ftp server, etc.) >From what I'm hearing so far, it may be premature for a site to attempt doing this. (eg. sluggish speed, and software compatibility issues) John From Firewalls-Owner Tue May 18 18:51:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27756; Wed, 19 May 93 01:28:57 GMT Received: from crl.dec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27749; Tue, 18 May 93 18:28:48 PDT Received: by crl.dec.com; id AA13947; Tue, 18 May 93 21:29:56 -0400 Received: by easynet.crl.dec.com; id AA14643; Tue, 18 May 93 21:29:55 -0400 Message-Id: <9305190129.AA01035@aqaba.crl.dec.com> To: chowes@sfu.ca (Charles Howes) Cc: Firewalls@GreatCircle.COM, wolman@cs.washington.edu Subject: Re: Proxy Xwindows? In-Reply-To: chowes@sfu.ca's message of Fri, 14 May 93 11:56:28 BST Date: Tue, 18 May 93 21:29:54 +28716 From: treese@crl.dec.com X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The code will be released shortly. A new CRL technical report is available: CRL Technical Report 93/10 X Through the Firewall, and Other Application Relays G. Winfield Treese Alec Wolman 3 May 1993 Organizations often impose an administrative security policy when they connect to other organizations on a public network such as the Internet. Many applications have their own notions of security, or they simply rely on the security of the underlying protocols. Using the X Window System as a case study, we describe some techniques for building application-specific ``relays'' that allow the use of applications across organizational boundaries. In particular, we focus on analyzing administrative and application-specific security policies to construct solutions that satisfy the security requirements while providing the necessary functions of the applications. This is a preprint of a paper to appear in the Proceedings of the USENIX Summer Conference, June, 1993. To retrieve the abstract for any report or note, send a message saying (for example) "send abstract 90/3" or "send abstract 90/3 90/2", using the number of the desired technical report to: techreports@crl.dec.com (Internet) crl::techreports (DECnet) To retrieve the PostScript for any report or note, send a message saying (for example) "send postscript 90/3" or "send postscript 90/3 90/2", using the number of the desired technical report to: techreports@crl.dec.com (Internet) crl::techreports (DECnet) Abstracts and PostScript versions of the CRL technical reports are also available via anonymous FTP to crl.dec.com, in the directory /pub/DEC/CRL/{abstracts,tech-reports}. To be added to the mailing list for announcements of CRL technical reports, send mail to techreports-interest-request@crl.dec.com (Internet) crl::techreports-interest-request (DECnet) Michelle Gillespie Cambridge Research Lab michelle@crl.dec.com Digital Equipment Corp. From Firewalls-Owner Tue May 18 19:21:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27729; Wed, 19 May 93 01:28:04 GMT Received: from tardis (netserv.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27721; Tue, 18 May 93 18:27:54 PDT Received: by tardis (5.0/netserv-1.0) id AA24544; Tue, 18 May 93 18:28:48 PDT Date: Tue, 18 May 93 18:28:48 PDT From: Scott M. Hinnrichs Message-Id: <9305190128.AA24544@tardis> To: firewalls@GreatCircle.COM, jlarson@parc.xerox.com Subject: Re: Firewall on dual-interface Sun running Solaris 2.x ? Cc: JLarson@parc.xerox.com X-Sun-Charset: US-ASCII Content-Length: 2481 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This is just what I would like to do. My main problem is unknown security holes. I have been able to get most software to work on 2.1 with some varying amounts of effort. The Sun iftp/itelnet bin works on 2.1, but haven't tried the proxy agents. I am going to give it a shot this weekend. DNS is a problem to watch out for. My config worked, but in.named dumped core with several request types. My solution was to pull over Solaris 1.1 in.named, and that works great. My sendmail.cf change amounted to substituting the local parsing lines from Sun's main.cf with mine (2 lines), all the other rules moved intact. You should note that /usr/ucb/install may be needed by some software; a symlink from true to ranlib, and noting ar differences will be useful. One other helpful hint is to use the -Xs option to cc with SparcWorks C 2.01, it relaxes checking and allows traditional C contructs you will find with most pre-SysV4 Sun code. Look for SysV4 defines and turn them on if things still don't work. Speed is actually better for compiles and exe's I have created. The only problem seems to be interactive tuning. When I have the machine loaded the screen redraws are visable and I sometimes wait for keystrokes. I never see this when booted on the same machine for Solaris 1.1. The machine is a SS10-41/192MB with SCSI-2 disks. Disk I/O seems about the same, maybe quicker. Solaris 1.1 does wierd swapping with my config, under Solaris 2.1 my swapping/paging is reduced. Anyone know of a place discussing Solaris 2.X transition issues? I couldn't see anything other than comp.sys.sun.* and nothing useful has come across there for 2.1. Solaris 2.1 is not as bad as I had heard, but I am anxious for 2.2 (due next week) for performance/tuning improvements. Scott > From Firewalls-Owner@GreatCircle.COM Tue May 18 18:12 PDT 1993 > Date: Tue, 18 May 1993 18:41:12 PDT > To: firewalls@GreatCircle.COM > From: John Larson > X-Sender: jlarson@vertigo.parc.xerox.com > Subject: Firewall on dual-interface Sun running Solaris 2.x ? > Cc: JLarson@parc.xerox.com > > > Has anyone successfully installed a dual-interface type firewall on a Sun > running Solaris 2.x ? (Including the usual suite of services: DNS, NTP, > SMTP gateway, proxy gatway, anonymous ftp server, etc.) > > From what I'm hearing so far, it may be premature for a site to attempt > doing this. (eg. sluggish speed, and software compatibility issues) > > John > > From Firewalls-Owner Wed May 19 15:40:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00635; Wed, 19 May 93 15:40:21 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00628; Wed, 19 May 93 08:40:12 PDT Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA15786; Wed, 19 May 93 10:41:23 CDT Date: Wed, 19 May 93 10:41:23 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9305191541.AA15786@tadpole.tadpole.com> To: firewalls@GreatCircle.COM, jlarson@parc.xerox.com, smh@netserv.com Subject: Re: Firewall on dual-interface Sun running Solaris 2.x ? Cc: JLarson@parc.xerox.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Solaris 2.1 is not as bad as I had heard, but I am anxious for 2.2 (due > next week) for performance/tuning improvements. Solaris 2.2 is slower on uniprocessor machines. At least, 2.2EA2 is slower. Jim From Firewalls-Owner Wed May 19 19:48:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01593; Wed, 19 May 93 19:48:18 GMT Received: from UACSC2.ALBANY.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01586; Wed, 19 May 93 12:48:09 PDT Message-Id: <9305191948.AA01586@mycroft.GreatCircle.COM> Received: from ALBNYDH2 by UACSC2.ALBANY.EDU (IBM VM SMTP V2R2) with BSMTP id 4034; Wed, 19 May 93 15:49:53 EDT Received: from ALBNYDH2 (JPH11) by ALBNYDH2 (Mailer R2.07) with BSMTP id 6408; Wed, 19 May 93 15:49:25 EDT Date: 19 May 93 15:49:24 EDT From: To: Subject: DNS and Firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tim Evans recently posted a request to this list asking for people's views on using DNS to set up a firewalled environment. I too would appreciate information on this topic. Thanks in advance. From Firewalls-Owner Wed May 19 22:45:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02029; Wed, 19 May 93 22:45:09 GMT Received: from gatekeeper.es.dupont.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02020; Wed, 19 May 93 15:44:58 PDT Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991); id AA10382; Wed, 19 May 93 18:46:13 -0400 Received: from fallst.es.dupont.com by eplrx7.es.duPont.com (4.1/kdm-082991-main) id AA21216; Wed, 19 May 93 18:44:02 EDT Received: by fallst.es.dupont.com (Smail3.1.28.1 #1) id m0nvwfM-000GMIC; Wed, 19 May 93 18:31 EDT Message-Id: From: tkevans@fallst.es.dupont.com (Tim Evans) Subject: SUMMARY: DNS in Firewalled Environment To: firewalls@GreatCircle.COM Date: Wed, 19 May 1993 18:31:15 -0400 (EDT) Phone: (410) 877-7890; (302) 695-9353 Reply-To: tkevans@eplrx7.es.duPont.com X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2189 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Last week, I wrote: >I'd like to hear peoples' views on appropriate ways to set up >DNS in firewalled environments, particularly with respect to >preventing information about hosts inside the firewall from >being broadcast to the world at large via DNS, while at the >same time providing info about the world outside to all the >internal hosts. > Paul Sangster (sangster@reston.ans.ne) wrote me about a commercial hardware/software combination called The InterLock. He wrote: >The InterLock is a commercial security service (leasable includes hardware/ >software/7x24 support). It provides a security-enhanced AIX kernel and >versions of FTP, TELNET, SMTP, X, NNTP and other security tools. The >InterLock falls into the category of ipforwarding turned off (which is >being discussed on the list currently), although its not a screening >router firewall. Instead it provides real application layer security with >user authentication, user-level restrictions, user-level auditing and >other functions at a higher level (like control over get vs put in ftp). > >If you are interested in more information let me know we have a white >paper available. I received one other reply, which I could not figure out whether it was serious or smartass, so won't mention the sender's name. The suggestion was to "not register my domain". Perhaps I missed something, but I thought one had to register one's domain to be on the Internet and to use DNS. How I could do what I wanted with an unregistered domain is beyond me. If the sender wants to elaborate, I'd appreciate it, and I apologize in advance if I've offended him/her with my ignorance, if that's what turns out to be the case. Meanwhile, I've been studying the new O'Reilly book _DNS and Bind_ and believe the solution to what I'm after is to use "internal root DNS servers," which know only about the internals of my network and about a "normal" DNS server on the firewall machine, which knows only about itself and the outside world. This is discussed in Chapter 14 of the book. -- UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans INTERNET: tkevans@fallst.es.dupont.com Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047 From Firewalls-Owner Wed May 19 23:38:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02172; Wed, 19 May 93 23:38:27 GMT Received: from macsch.com (DRACO.MACSCH.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02165; Wed, 19 May 93 16:38:07 PDT Received: from [161.34.1.6] by macsch.com (5.61/SMI-4.1-07) id AA25192; Wed, 19 May 93 16:39:17 -0700 Received: from canismajor.is.macsch.com by convex.is.macsch.com (5.64/2.0) id AA02473; Wed, 19 May 93 16:37:08 -0700 Received: by canismajor.is.macsch.com (4.1/2.0) id AA05070; Wed, 19 May 93 16:39:00 PDT Date: Wed, 19 May 93 16:39:00 PDT From: todd@macsch.com (Todd Williams) Message-Id: <9305192339.AA05070@canismajor.is.macsch.com> To: firewalls@GreatCircle.COM Subject: Re: SUMMARY: DNS in Firewalled Environment Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 6:31pm on Wed May 19 1993, tkevans@fallst.es.dupont.com (Tim Evans) said: > Last week, I wrote: > > >I'd like to hear peoples' views on appropriate ways to set up > >DNS in firewalled environments, particularly with respect to > >preventing information about hosts inside the firewall from > >being broadcast to the world at large via DNS, while at the > >same time providing info about the world outside to all the > >internal hosts. > > I received one other reply, which I could not figure out whether it was > serious or smartass, so won't mention the sender's name. The suggestion > was to "not register my domain". Perhaps I missed something, but I thought > one had to register one's domain to be on the Internet and to use DNS. > How I could do what I wanted with an unregistered domain is beyond me. Right. If you're on the internet, your DNS must be using a registered name. > Meanwhile, I've been studying the new O'Reilly book _DNS and Bind_ > and believe the solution to what I'm after is to use "internal > root DNS servers," which know only about the internals of my network > and about a "normal" DNS server on the firewall machine, which knows > only about itself and the outside world. Well, I'm surprisingly disappointed that you didn't get an adequate response. Maybe nobody understood the question. I haven't tackled this problem at my site yet, so let me give you my blind-leading-the-blind reply: Smoot Carl-Mitchell of Texas Internet Consulting has developed something that will do exactly what you want, I think. I think they are hacks to DNS which allow you to run DNS out to the Internet from one side of your firewall, while running a slightly different DNS internal to your firewall. This is a common problem for people who want to hide internal host names, etc. His address is smoot@tic.com, or you can just get the package via FTP from tic.com, I think. Here's some of the previous discussion about this topic: At 11:56am on Tue Dec 22 1992, Donald R. Proctor (510/596-3828) said: > > Previously, avalon@coombs.anu.edu.au (Darren Reed) said: > > It has often been said that when setting up a firewall to allow DNS > > packets with both source and dest. of port 53 through. There seems > > to be an obvious flaw with this - what is to stop crackers using > > this 'hole' ? I don't recall if this was allowed just as far as the > > 'DMZ' or all the way through... > > The best approach is probably to set up an "internal" DNS domain and > an "external" DNS domain. The internal domain servers would talk to > internal root servers, and the external domain servers would talk to > the "real" root servers. > > That way you don't need to open up port 53 from the DMZ to the internal > network(s). > > Also, you may not have a need to advertise the name of every host on > your network to the outside world. In this case, the "external" DNS > server can operate with a very minimal DNS database configuration. Todd Williams UNIX Systems Supervisor todd@macsch.com (213) 259-4973 MacNeal-Schwendler Corp. ("MSC"), 815 Colorado Blvd., Los Angeles, CA 90041 "Solaris 2.0 -- It's enough to make you leave the company." -Rob Kolstad From Firewalls-Owner Wed May 19 21:37:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02968; Thu, 20 May 93 04:08:45 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02959; Wed, 19 May 93 21:08:39 PDT Message-Id: <9305200408.AA02959@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: [bjorn@netcom.com (Bjorn Satdeva): Bay-LISA March May: Tina Darmohray: Internet Firewalls] Date: Wed, 19 May 93 21:08:38 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Those of you here in the San Francisco Bay Area might be interested in attending. My apologies to those elsewhere, and to everyone for the short notice; I just got this yesterday. Please note that this meeting is TOMORROW (TODAY, if you're reading this at work on Thursday morning)... Should be fun! -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 ------- Forwarded Message Message-Id: From: bjorn@netcom.com (Bjorn Satdeva) Subject: Bay-LISA March May: Tina Darmohray: Internet Firewalls To: bay-lisa@sysadmin.com Date: Tue, 18 May 1993 16:15:06 -40962758 (PDT) X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1704 X-Sequence-Number: 71 Precedence: bulk Originally from: bjorn (Bjorn Satdeva) Bay-LISA May 20th Securing a Modern TCP/IP Network: Firewalls Most sites have a need to communicate electronically within and beyond their own borders. Frequently, the success of an enterprise depends heavily on digital communications, however, the techniques and tools required to design a secure internet connection are often illusive. This month at Bay LISA, we'll dicuss issues and solutions surrounding the design and implementation of a secure internetwork connection. Video tapes of previous meetings available to Bay-LISA members. General Meeting Information: Date: Thursday, May 20th, 7:30 PM (Third Thursday of every month) Please do not arrive before 7 PM. Place: Silicon Graphics, Inc. Building 5 (SGI Cafeteria) 2025 North Shoreline Boulevard Mountain View From 101 take Shoreline East. Turn right onto Steirlin Court at the big red metal sculpture. Go almost to the end, and building 5 is on the right. Info: Send e-mail to baylisa-info@sysadmin.com, or you may contact: Bjorn Satdeva (408) 241-3111 bjorn@sysadmin.com The Bay-LISA group meets monthly to discuss topics of interest for administration of sites with more than 100 users and/or computers. The meetings are free and open to the public. - -- Bjorn Satdeva -- email: bjorn@sysadmin.com /sys/admin, inc. The Unix System Management Experts (408) 241 3111 Send requests to the SysAdmin mailing list to sysadm-list-request@sysadmin.com - -- ------- End of Forwarded Message From Firewalls-Owner Thu May 20 13:04:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04637; Thu, 20 May 93 13:04:50 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04628; Thu, 20 May 93 06:04:14 PDT Received: from otter.tis.com by TIS.COM (4.1/SUN-5.64) id AA10230; Thu, 20 May 93 09:06:37 EDT Date: Thu, 20 May 93 09:06:37 EDT From: Marcus J Ranum Message-Id: <9305201306.AA10230@TIS.COM> To: Firewalls@GreatCircle.COM, brent@GreatCircle.COM Subject: Re: [bjorn@netcom.com (Bjorn Satdeva): Bay-LISA March May: Tina Darmohray: Internet Firewalls] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Most sites have a need to communicate electronically within and > beyond their own borders. Frequently, the success of an enterprise > depends heavily on digital communications, however, the techniques > and tools required to design a secure internet connection are > often illusive. ^^^^^^^^ I recommend designing one's secure internet connections using substantial tools, rather than ones that are illusions. ;) ;) mjr. From Firewalls-Owner Thu May 20 13:46:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04724; Thu, 20 May 93 13:46:28 GMT Received: from erenj.com (ereapp.erenj.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04717; Thu, 20 May 93 06:46:03 PDT Received: by erenj.com (5.65/mjr-920806); id AA13345; Thu, 20 May 93 09:47:04 -0400 Received: by eredns.erenj.com (5.65/bdb-mailv1.2-erenj-gw); id AA21007; Thu, 20 May 93 09:47:03 -0400 Received: by maverick1.erenj.com (5.57/bdb-mailv1.0); id AA03466; Thu, 20 May 93 09:47:02 -0400 Posted-Date: Thu, 20 May 1993 09:47:02 -0400 From: bdboyle@maverick1.erenj.com (Bryan D. Boyle) Message-Id: <9305200947.ZM3464@maverick1.erenj.com> Date: Thu, 20 May 1993 09:47:02 -0400 In-Reply-To: Marcus J Ranum "Re: [bjorn@netcom.com (Bjorn Satdeva): Bay-LISA March May: Tina Darmohray: Internet Firewalls]" (May 20, 9:06am) References: <9305201306.AA10230@TIS.COM> X-Mailer: Z-Mail (2.1.0 10/1/92) To: Firewalls@GreatCircle.COM, Marcus J Ranum Subject: Re: [bjorn@netcom.com (Bjorn Satdeva): Bay-LISA March May: Tina Darmohray: Internet Firewalls] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On May 20, 9:06am, Marcus J Ranum wrote: > Subject: Re: [bjorn@netcom.com (Bjorn Satdeva): Bay-LISA March May: Tina > > Most sites have a need to communicate electronically within and > > beyond their own borders. Frequently, the success of an enterprise > > depends heavily on digital communications, however, the techniques > > and tools required to design a secure internet connection are > > often illusive. > ^^^^^^^^ > > I recommend designing one's secure internet connections using > substantial tools, rather than ones that are illusions. > > ;) ;) > > mjr. Or at least as substantial as _anything_ is on these machines. ObOldQuote: "If builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization..." (excepting your efforts, marcus...:-)) -- Bryan D. Boyle <>< |EMAIL: bdboyle@erenj.com #include |Hack first and ask questions later. 908 730-3338 |ER & E Co. Rt. 22 East, Annandale, NJ From Firewalls-Owner Thu May 20 15:18:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04895; Thu, 20 May 93 15:18:12 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04877; Thu, 20 May 93 08:17:46 PDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA02877; Thu, 20 May 93 11:18:34 EDT Received: from lehman.com by shearson.com (4.1/LB-0.6) id AA03209; Thu, 20 May 93 11:18:31 EDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA02874; Thu, 20 May 93 11:18:29 EDT Received: from snark.shearson.com by shearson.com (4.1/LB-0.6) id AA03206; Thu, 20 May 93 11:18:28 EDT Received: by snark.shearson.com (4.1/SMI-4.1) id AA11170; Thu, 20 May 93 11:18:27 EDT Message-Id: <9305201518.AA11170@snark.shearson.com> To: tkevans@eplrx7.es.dupont.com Cc: firewalls@GreatCircle.COM Subject: Re: SUMMARY: DNS in Firewalled Environment In-Reply-To: Your message of "Wed, 19 May 1993 18:31:15 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 20 May 1993 11:18:26 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tim Evans says: > Last week, I wrote: > > >I'd like to hear peoples' views on appropriate ways to set up > >DNS in firewalled environments, particularly with respect to > >preventing information about hosts inside the firewall from > >being broadcast to the world at large via DNS, while at the > >same time providing info about the world outside to all the > >internal hosts. I'm sorry no one really answered you. I suspect everyone assumed someone else would. Here at Lehman, we have an internal and external DNS server. Externally, we just show a wildcard MX for our domain and the records for the firewall machine. Internally, we "do the right thing". Setting this up was quite trivial. > Paul Sangster (sangster@reston.ans.ne) wrote me about a commercial > hardware/software combination called The InterLock. He wrote: > > >The InterLock is a commercial security service (leasable includes hardware/ ANS basically leases you an RS/6000 with their firewall software. You can do everything they do for you for free with your own hardware using software available fro free from the net. Personally, I wouldn't touch their product with a long pole. They are very agressive about pushing the stuff to whomever sends out inquiries anywhere on the net, but I've never seen the utility of leasing an RS/6000 from them with their proprietary software other than the fact that being an IBM affiliate this helps them improve IBM's lackluster workstation sales. > Meanwhile, I've been studying the new O'Reilly book _DNS and Bind_ > and believe the solution to what I'm after is to use "internal > root DNS servers," which know only about the internals of my network > and about a "normal" DNS server on the firewall machine, which knows > only about itself and the outside world. This is discussed in > Chapter 14 of the book. A pretty good idea. Perry Metzger From Firewalls-Owner Thu May 20 17:17:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05602; Thu, 20 May 93 17:17:20 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05593; Thu, 20 May 93 10:17:14 PDT Message-Id: <9305201717.AA05593@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 10:17:13 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Just noticed that somewhere along the line during this debate, "Firewalls-Owner" got substituted for "Firewalls", and most of you haven't been seeing this exchange. I'll ferret out the other messages that got sent to the wrong address, and forward them. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 ------- Forwarded Message Return-Path: brent@GreatCircle.COM Return-Path: Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05506; Thu, 20 May 93 10:09:41 PDT Message-Id: <9305201709.AA05506@mycroft.GreatCircle.COM> To: rmdupont@irsc.gmeds.com (R. Michael Dupont) Cc: tkevans@eplrx7.es.duPont.com, Firewalls-Owner@GreatCircle.COM Subject: Re: DNS in Firewalled Environment In-Reply-To: Your message of Thu, 20 May 93 10:11:13 EST Date: Thu, 20 May 93 10:09:40 -0700 From: Brent Chapman Regarding the suggestion of using a bogus domain name as a way of ensuring that outsiders can't get at your DNS data... Don't. Everybody who does that (or similar things, like inventing IP addresses out of the blue, rather than registering them) because "WE'll never connect to the Internet" has come to regret it, and it's a major project to fix it a couple of years down the road. You might as well do things "right", right from the start. It will save you untold time and trouble later. There are other ways to hide your internal DNS data from prying eyes, one of which I've described before and will again shortly in a separate message. - -Brent - -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 ------- End of Forwarded Message From Firewalls-Owner Thu May 20 17:19:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05634; Thu, 20 May 93 17:19:32 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05624; Thu, 20 May 93 10:19:24 PDT Message-Id: <9305201719.AA05624@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 10:19:23 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Here's the only other misdirected message that I could find. -Brent ------- Forwarded Message Return-Path: rmdupont@irsc.gmeds.com Return-Path: Received: from irsc.gmeds.com ([192.57.20.10]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04840; Thu, 20 May 93 08:10:06 PDT Received: by irsc.gmeds.com (4.1/EDS-1.0) id AA06861; Thu, 20 May 93 10:11:13 EST Date: Thu, 20 May 93 10:11:13 EST From: rmdupont@irsc.gmeds.com (R. Michael Dupont) Message-Id: <9305201511.AA06861@irsc.gmeds.com> To: tkevans@eplrx7.es.duPont.com, Firewalls-Owner@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Cc: rmdupont@irsc.gmeds.com >From the SERIOUS SMARTASS . . . > From tkevans@fallst.es.dupont.com Wed May 19 17:46:31 1993 > From: tkevans@fallst.es.dupont.com (Tim Evans) > Subject: Re: DNS in Firewalled Environment > To: rmdupont@irsc.gmeds.com (R. Michael Dupont) > Date: Wed, 19 May 1993 18:35:40 -0400 (EDT) > In-Reply-To: <9305142141.AA17179@irsc.gmeds.com> from "R. Michael Dupont" at May 14, 93 04:41:17 pm > Phone: (410) 877-7890; (302) 695-9353 > Reply-To: tkevans@eplrx7.es.duPont.com > > Quoth R. Michael Dupont: > > > >> I'd like to hear peoples' views on appropriate ways to set up > >> DNS in firewalled environments, particularly with respect to > >> preventing information about hosts inside the firewall from > >> being broadcast to the world at large via DNS, while at the > >> same time providing info about the world outside to all the > >> internal hosts. > >> > >> Thanks. > >> > >How about not registering your domain? > > > I'm not sure I understand what you mean. If you're being sarcastic, > I guess I'm too dumb to appreciate the sarcasm. If you have a substantive > response, please send it. > > -- > UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans > INTERNET: tkevans@fallst.es.dupont.com > Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047 > I am serious, but I guess my response needs a little more substance to it. By not registering a domain, the ROOT servers cannot resolve any unregistered HOST.DOMAIN.OF.MY.CHOICE because they do not know where the SOA resides. You (as the Source-Of-Authority) do, and can provide proper resolution for hosts within your domain. You can also resolve any registered domains because you are able to access the ROOT server, then the SOA servers containing the info desired. Yes, this could be creating conflicts if Ed's Drywall Supplies wanted to use an unregistered EDS.com domain. Mail from those users would (probably) never get to users at Electronic Data Systems, and vice-versa. If you were to use an unregistered domain, I would suggest not ending it with an acronym of less than three letters, so that there is no conflict with true registered domains (i.e. those in COM, EDU, GOV, MIL, ORG, NET, US, AZ, etc.) You might set up (using yourself as an example) a domain such as DUPONT, with a sub-domain of ES, and a host named FALLST, so that your internal email would be sent to tkevans@fallst.es.dupont. I might set up my own domain, and have my internal mail addressed to mike@smartass.dupont. Want to know about my host addresses? You have to find my SOA nameserver, and I'm not telling! You MUST apply for an address range that is registered prior to interconnecting to the Internet, so that there are no duplications. The address is not equal to a domain name, but is a separate issue for "NAME <--> ADDRESS" resolutions. No registered domain name ===> no address resolution for users in the Internet. Heresy!?! I am not suggesting this to create anarchy within the network, but as a "ONE-WAY MIRROR" method of Internet connectivity. The fact that there is no resolution could cause you problems with Anybody know of hitches to this type of a setup? Tim: No blood, no foul, no offense taken. - -- Mike +----------------------------------RMD19------------------------------------+ | R. Michael Dupont, Indiana Regional Support Cntr, Electronic Data Systems | | Data Networks Manager, Monday - Friday, 0800 - 1700 EST (1300 - 2200 GMT) | | Voice: (317)240-5823, GM: 8*360-5823, Pager: 928-1361, FAX: (317)240-5622 | | Paper: 2601 Fortune Circle East, Suite 100C, Indianapolis, IN 46241-5513 | | Internet: rmdupont@irsc.gmeds.com, DECUServe: dupont@Eisner.DECUS.Org | +---------------------------------------------------------------------------+ ------- End of Forwarded Message From Firewalls-Owner Thu May 20 17:36:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05718; Thu, 20 May 93 17:36:52 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05704; Thu, 20 May 93 10:36:45 PDT Message-Id: <9305201736.AA05704@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 10:36:44 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Here's a brief overview of how I set up DNS for my Internet-connected clients that don't want to advertise all their internal hosts. Basicly, the key realization is that the DNS clients on a machine don't have to talk to the DNS server on that same machine. In other words, just because there's a DNS server on a machine, there's nothing wrong with (and often advantages to) redirecting that machine's DNS client activity to a DNS server on another machine. Here's how I use that little factoid to my advantage... First, you set up a DNS server that the outside world can talk to. You set this server up so that it claims to be authoritative for your domains. In fact, all this server knows is what you want the outside world to know; the names and addresses of your gateways, your wildcard MX records, and so forth. This is the "public" server. Then, you set up a DNS server on an internal machine. This server also claims to be authoritiative for your domains; unlike the public server, this one is telling the truth. This is your "normal" nameserver, into which you put all your "normal" DNS stuff. You also set this server up to forward queries that it can't resolve to the public server (using a "forwarders" line in /etc/named.boot on a UNIX machine, for example). Finally, you set up all your DNS clients (the /etc/resolv.conf file on a UNIX box, for instance), including the ones on the machine with the public server, to use the INTERNAL server. This is the key. This is how it works... An internal client asking about an internal host asks the internal server, and gets an answer; an internal client asking about an external host asks the internal server, which asks the public server, which asks the Internet, and the answer is relayed back. A client on the public server works just the same way. An external client, however, asking about an internal host gets back the "restricted" answer from the public server. I'm assuming that there's a packet filtering firewall between these two servers that will allow them to talk DNS to each other, but that's it, but restricts DNS between other hosts. If you don't have a packet filtering firewall, then this whole scheme is kind of pointless; somebody can contact your internal name server (all they have to do is find it) and get all the "real" data. There's another trick that's useful in this scheme: wildcard PTR records (bet you didn't know you could do that! :-) in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for any of your non-public hosts to return something like "unknown.YOUR.DOMAIN" (i.e., "unknown.GreatCircle.COM") rather than an error. This satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu May 20 17:50:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05777; Thu, 20 May 93 17:50:34 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05766; Thu, 20 May 93 10:50:03 PDT Message-Id: <9305201750.AA05766@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu May 20 13:49:47 EDT 1993 To: Brent Chapman Cc: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 13:49:46 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There's another trick that's useful in this scheme: wildcard PTR records (bet you didn't know you could do that! :-) in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for any of your non-public hosts to return something like "unknown.YOUR.DOMAIN" (i.e., "unknown.GreatCircle.COM") rather than an error. This satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. No, it won't necessarily satisfy such sites. Many machines validate the results of gethostbyaddr() by doing a gethostbyname() call; if the latter doesn't return the actual IP address, the value returned by the gethostbyaddr() call isn't believed. For your idea to work, unknown.YOUR.DOMAIN would have to have an A record for every machine you own that could possibly talk to the outside world. Apart from the fact that you might not want to give out that information, you'll break lots of machines that can't handle that many A records coming back at them. From Firewalls-Owner Thu May 20 17:52:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05800; Thu, 20 May 93 17:52:41 GMT Received: from rara.ossi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05793; Thu, 20 May 93 10:52:13 PDT Received: from nym.ossi.com (nym.ossi.com [192.240.2.13]) by rara.ossi.com (ALPHA-6.54/6.27) id KAA16654; Thu, 20 May 1993 10:53:16 -0700 Received: from localhost (aegl@localhost) by nym.ossi.com (ALPHA-6.54/6.27) id KAA23870; Thu, 20 May 1993 10:53:15 -0700 Date: Thu, 20 May 1993 10:53:15 -0700 From: Tony Luck Message-Id: <199305201753.KAA23870@nym.ossi.com> To: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk R. Michael Dupont writes: > By not registering a domain, the ROOT servers cannot resolve any unregistered > HOST.DOMAIN.OF.MY.CHOICE because they do not know where the SOA resides. You > (as the Source-Of-Authority) do, and can provide proper resolution for hosts > within your domain. ... > Anybody know of hitches to this type of a setup? At least one problem ... several of the anonymous ftp servers are already set up to reject connections if they can't do a reverse lookup on the address that your connection comes from (and some then convert the name back to an address again to make sure that they match). This kind of autentication of connections is becoming more common as the number of bad guys on the net goes up, resulting in a decrease in the overall level of trust. If you don't have a registered domain, then you can't access the services that do this kind of checking. -Tony Luck From Firewalls-Owner Thu May 20 12:12:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06062; Thu, 20 May 93 18:41:31 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06053; Thu, 20 May 93 11:40:11 PDT Message-Id: <9305201840.AA06053@mycroft.GreatCircle.COM> To: smb@research.att.com Cc: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment In-Reply-To: Your message of Thu, 20 May 93 13:49:46 EDT Date: Thu, 20 May 93 11:40:09 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # There's another trick that's useful in this scheme: wildcard # PTR records (bet you didn't know you could do that! :-) in # your IN-ADDR.ARPA domains. These cause an an address-to-name # lookup for any of your non-public hosts to return something # like "unknown.YOUR.DOMAIN" (i.e., "unknown.GreatCircle.COM") # rather than an error. This satisfies anonymous FTP sites like # ftp.uu.net that insist on having a name for the machines they # talk to. # # No, it won't necessarily satisfy such sites. Many machines validate # the results of gethostbyaddr() by doing a gethostbyname() call; if # the latter doesn't return the actual IP address, the value returned # by the gethostbyaddr() call isn't believed. For your idea to work, # unknown.YOUR.DOMAIN would have to have an A record for every machine # you own that could possibly talk to the outside world. Apart from # the fact that you might not want to give out that information, you'll # break lots of machines that can't handle that many A records coming # back at them. I have yet to encounter one of these sites. Every anonymous FTP site I've run into so far wanted (at most) a name; they didn't care if that name mapped back to the address you were coming from. So yes, in theory, this is a problem. In practice, it doesn't seem to be a problem. This is the "double reverse lookup" argument from early in the history of the Firewalls mailing list. I really didn't mean to start it up again; anybody who's interested should go back through the archives to find the old discussions on the subject. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu May 20 21:05:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06910; Thu, 20 May 93 21:05:21 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06901; Thu, 20 May 93 14:05:06 PDT Message-Id: <9305202105.AA06901@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu May 20 17:04:23 EDT 1993 To: Brent Chapman Cc: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 17:04:22 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have yet to encounter one of these sites. Every anonymous FTP site I've run into so far wanted (at most) a name; they didn't care if that name mapped back to the address you were coming from. So yes, in theory, this is a problem. In practice, it doesn't seem to be a problem. I confess that I'm surprised. SunOS's gethostbyaddr() call will return NULL if the cross-check fails. Perhaps folks sophisticated enough to have replaced their ftp daemons have also replaced their resolver libraries without being aware of the division of labor? From Firewalls-Owner Fri May 21 15:25:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09922; Fri, 21 May 93 15:25:17 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09913; Fri, 21 May 93 08:25:09 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA04952; Fri, 21 May 93 11:25:10 -0400 Received: by cobalt.house.gov (AA03617); Fri, 21 May 93 11:26:59 -0700 Date: Fri, 21 May 93 11:26:59 -0700 From: Dorian Deane Message-Id: <9305211826.AA03617@cobalt.house.gov> To: brent@GreatCircle.COM, Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk rmdupont@irsc.gmeds.com writes: > By not registering a domain, the ROOT servers cannot resolve any unregistered > HOST.DOMAIN.OF.MY.CHOICE because they do not know where the SOA resides. You > (as the Source-Of-Authority) do, and can provide proper resolution for hosts > within your domain. You can also resolve any registered domains because you > are able to access the ROOT server, then the SOA servers containing the info > desired. ... > You have to find my SOA nameserver, and I'm not telling! ... > Anybody know of hitches to this type of a setup? The minor hitches have already been addressed by others. I just want to point out that there is only minor value in security by obscurity. Just because there is no _name_ associated with your network doesn't mean you're not reachable. In fact, adding that kind of secrecy might make the "target" just that much more attractive. Dorian Deane House Information Systems ddeane@cobalt.house.gov From Firewalls-Owner Mon May 24 03:31:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18489; Mon, 24 May 93 03:31:48 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18481; Sun, 23 May 93 20:31:32 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14847; Sun, 23 May 93 23:33:03 -0400 Date: Sun, 23 May 93 23:33:03 -0400 From: uworld!uucp@uunet.uu.net Message-Id: <9305240333.AA14847@relay2.UU.NET> Received: from uworld.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 233103.15229; Sun, 23 May 1993 23:31:03 EDT Apparently-To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From rik Sun May 23 18:06:10 1993 remote from crow Reply-To: crow!rik Received: by crow.spirit.com (4.1/SMI-4.1) id AA06602; Sun, 23 May 93 18:06:10 MST Date: Sun, 23 May 93 18:06:10 MST From: crow!rik (Rik Farrow) Message-Id: <9305240106.AA06602@crow.spirit.com> To: uworld!uunet!greatcircle.com!firewalls Subject: IP Ports and services On may 13, Jim Stine wrote: > From: stine@logiconultra.com > Date: Thu, 13 May 93 10:43:11 -0700 > Subject: Re: New file transfer protocol: FSP > > Is there a standard list of port numbers to allow and deny for a standard > firewall configuration? I see a lot of people suggesting different port > numbers to allow but it sure would be nice to have a list (maybe generated > by concensus) of the ports. > Thanks > > jim This is something I have long been interested in, and except for examples of access control lists for different routers, I haven't seen such a list in this mailing list. So I am going to post what I have and hope to be able to post an augmented and corrected list sometime in the near future. First, a couple of notes. We are mainly concerned with two of the protocol TCP/IP types, TCP and UDP. TCP is used to establish a connection between a client and a server (like a telephone call) which remains in existence until the termination of the client program. UDP is used for "lighter" services, doesn't provide a connection, and is also unreliable (no guarantees that packets reached their destination, something which TCP provides). Also, after a TCP connection has been made form client to a server, some routers can check for an connection "established" flag. Ports on UNIX systems are divided between "privileged" and user ports. Privileged ports have port numbers less than 1024, and can only be connected to by root-owned processes. On a Macintosh, a PC, or a system where someone has "broken root", this level of privilege means very little. Essential Services This list includes "essential services"-- those which most people expect and demand for Internet connectivity. NAME CLIENT SERVER TYPE DESCRIPTION PORT PORT FTP >1024 21 TCP File Transfer Protocol (control) >1024 20 TCP (data back from server) TELNET >1024 23 TCP terminal emulation SMTP 25 25 TCP Simple Mail Transport Protocol DNS 53 53 UDP Domain Name Service One common problem in setting up a screening router is to be unaware of the data connection that a remote FTP server will make back to the client. Useful Services These services, especially netnews, are often desired. NAME CLIENT SERVER TYPE DESCRIPTION PORT PORT NNTP 119 119 TCP Network News Transport Protocol NTP 123 123 TCP Network Time Protocol UUCP 540 540 TCP non-SMTP mail transport Information Services Depending on your site, you may either want to offer to be an information provider, or have users who want to use client software. These services include WAIS, Archie, and Gopher. I believe that an Archie server uses port 1525, but am really unclear about these services and the ports required. Dangerous Services These services include known problems. For example, many of the 'r' commands are designed for convenience only--they only function using the equivalenced hosts mechanism and never prompt for passwords. The exception is rlogin, but individual users can create ~/.rhosts files which can open a system up for passwordless logins. Tftp is only required for boot diskless workstations or X terminals--something you shouldn't expect to be doing across a firewall. NAME CLIENT SERVER TYPE DESCRIPTION PORT PORT TFTP >1024 69 UDP Trivial FTP (no authentication) REXEC >1024 512 TCP remote execution of commands RSH >1024 513 TCP remote shell The list of dangerous services must be extended to include RPC (remote procedure calls) services, which all use the UDP protocol. A recently developed file transfer program, FSP, seems designed to bypass firewall controls and also uses UDP. Blocking all UDP except for specific allowed services (such as DNS) appears customary. Other dangerous services to block? Two Ways There are two ways to go about permitting or denying these services. The first follows the dictum "everything which is not permitted is denied" appears to be the safest and uses a "dual-homed host" as a firewall. A dual-homed host must have IP forwarding disabled (by setting the ip_forwarding variable in the kernel to 0) so that the firewall will NOT route packets. There no longer is a direct connection between the Internet (or untrusted network) and the internal network. The firewall host allows connections for services on its Internet side, for example, by receiving mail via SMTP and distributing it internally, and relaying internal mail to the outside world. Or the dual-homed host doesn't provide the service itself, but runs a "proxy server" which permits connection between internal clients, such as ftp or telnet, and the Internet, more or less transparently to the user. Marcus Ranum, a frequent firewalls contributer and author of DEC's SEAL firewall product, is a champion of this approach. The other (and apparently much more popular) way is to "allow everything which is not specifically denied". This is a more dangerous approach, but also generally more transparent to users. A router is set up to perform "screening", that is, denying certain services, passing other services through with no restrictions, or only allowing certain services to an internal host. This internal host, the firewall, handles SMTP, DNS, and perhaps NNTP and NTP. This second approach to firewalls is more concerned with source and destination ports, protocol types, source and destination IP addresses. In the dual-homed host approach, if there isn't a server or proxy running on the firewall (and no one breaks into the firewall), there is no way to penetrate to the internal network via the Internet connection. The second approach requires a lot of care in setting up the screening router so that 1) it works correctly (you don't break anything), 2) you actually deny dangerous services. The best approach here appears to be to deny everything and carefully open "windows" for known-safe services. Rik Farrow rik@uworld.com From Firewalls-Owner Mon May 24 16:11:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20629; Mon, 24 May 93 16:11:50 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20622; Mon, 24 May 93 09:11:42 PDT Message-Id: <9305241611.AA20622@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by bigbird.zoo.att.com; Mon May 24 12:11:09 EDT 1993 To: firewalls@GreatCircle.COM Subject: ftp through a firewall Date: Mon, 24 May 93 12:11:07 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've built a prototype ftp that can (usually) get through a firewall. It works by using the PASV command to tell the server to do a passive open, and reply with its host address and port number. Thus, the call from the client is an active open, which is easy to get through firewalls without serious security headaches. That's the good news... The bad news is that some ftp servers out there don't understand PASV. If you wanted to talk to them badly enough, you could stick a host of yours in the DMZ, open a parallel ftp session to it, tell it to go passive, then send the real server you want to talk to a PORT command specifying the PASV port that your server is listening on. (Yah, I know that that's a confusing sentence....) That will get the file to your gateway machine, from which you can pick it up. No, I didn't write that version. No, I don't plan to. But some versions of ftp have a ``proxy'' mode that can be used to talk on more than one session at once, to implement just that sort of third-party transfer. Oh yeah -- my code isn't released, since I just wrote it this morning. If there's really a lot of interest, I could try, but I suspect that there are dozens of others on this list who could reimplement this idea much faster than I could maneuver through the paperwork. It's not hard; I spent more time picking up all the little pieces from uunet that I needed to find to make ftp compile on SunOS. There's only one tricky part. The way the code works now, ftp calls dataconn() after picking up the code 150 intermediate response. That doesn't work in PASV mode; you have to do the active open (mine's in a routine called pasvconn()) before sending the command. (Btw -- it's possible that that strategy won't work with some servers. It does work with ftpd.) --Steve Bellovin From Firewalls-Owner Mon May 24 19:16:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21445; Mon, 24 May 93 19:16:02 GMT Received: from NMSU.Edu (dns1.NMSU.Edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21438; Mon, 24 May 93 12:15:55 PDT From: amolitor@NMSU.Edu Received: from emmy (emmy.NMSU.Edu) by NMSU.Edu (4.1/NMSU-1.18) id AA13680; Mon, 24 May 93 13:17:15 MDT Date: Mon, 24 May 93 13:17:15 MDT Message-Id: <9305241917.AA13680@NMSU.Edu> Received: by emmy (4.1/NMSU) id AA20388; Mon, 24 May 93 13:17:10 MDT To: firewalls@GreatCircle.COM Subject: A general remark - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk With all this discussion of how to get services through a firewall, I wonder if some have perhaps lost a bit of focus. A firewall is supposed to prevent things from getting through it. It's hardly worthwhile to build a wall, and then replace almost all of it with a variety of gates of varying strength. Folks who want to be protected from the bad guys, but also want a full service Internet connection might look in to ditching the firewall, and taking other measures (securing internal machines, very good backup/recovery/damage control procedures, and so forth). Andrew Molitor From Firewalls-Owner Tue May 25 02:27:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22763; Tue, 25 May 93 02:27:11 GMT Received: from yarra-glen.aaii.oz.au (eden-valley.aaii.oz.AU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22756; Mon, 24 May 93 19:26:44 PDT Received: from chook.aaii.oz.AU by yarra-glen.aaii.oz.au with SMTP (5.65c/SMI-4.0/AAII) id AA14978; Tue, 25 May 1993 12:25:49 +1000 Message-Id: <199305250225.AA14978@yarra-glen.aaii.oz.au> To: amolitor@nmsu.edu Cc: firewalls@GreatCircle.COM Subject: Re: A general remark - In-Reply-To: Your message of "Mon, 24 May 1993 13:17:15 MDT." <9305241917.AA13680@NMSU.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 May 1993 12:25:17 +1000 From: Anthony Baxter Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9305241917.AA13680@NMSU.Edu>you write: > With all this discussion of how to get services through a firewall, > I wonder if some have perhaps lost a bit of focus. A firewall is supposed > to prevent things from getting through it. I would say that a firewall is meant to block the things that you dont want getting through to your network. After all, what use is a fence around your house if it doesnt allow you to bring your groceries in because you have to climb a wobbly old ladder to get inside? > It's hardly worthwhile to > build a wall, and then replace almost all of it with a variety of > gates of varying strength. Folks who want to be protected from the bad > guys, but also want a full service Internet connection might look in > to ditching the firewall, and taking other measures (securing internal > machines, very good backup/recovery/damage control procedures, and > so forth). Securing (n) machines, where (n) is large (say, a pile of workstations) so that they are very secure is _much_, _much_ harder than securing one firewall up to the level you are happy with. I'm not saying you shouldnt _also_ have internal security, but its much easier to secure one point of access than your entire network. In general, it will cause less problems for the legitimate users, too. If I can say 'block everything' and _then_ open small holes to allow the services I want through, that is a better situation than continually trying stopgap measures to fix umpteen different holes on upteen different machines. (That is, of course, assuming that the vendor even lets you _know_ about a security hole that they have provided you with when you bought their operating system.) Anthony From Firewalls-Owner Tue May 25 17:37:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25220; Tue, 25 May 93 17:37:52 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25213; Tue, 25 May 93 10:37:44 PDT Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA13483; Tue, 25 May 93 13:38:08 -0400 Date: Tue, 25 May 93 13:38:08 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9305251738.AA13483@bedrock.cs.UMD.EDU> To: firewalls@GreatCircle.COM Subject: ICMP Redirects Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Perhaps a stupid question: I'm configuring a Cisco serial interface attached to the Internet to deny all UDP packets excepting those on port 53. All IP in general, except that directed to the DNS machine, will also be denied -- and the DNS facing Internet will not have internal network information. Should I, as well, turn off ICMP Redirects on that interface? ( Or, turn off/leave on anything else ? ). Thanks, Richard Huddleston From Firewalls-Owner Wed May 26 20:54:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29947; Wed, 26 May 93 20:54:16 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29940; Wed, 26 May 93 13:53:57 PDT Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA19644; Wed, 26 May 93 16:55:21 -0400 Date: Wed, 26 May 93 16:55:21 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9305262055.AA19644@bedrock.cs.UMD.EDU> To: Firewalls@GreatCircle.COM Subject: Cisco AGS+ as gate Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Any pointers or suggestions related to setting up a serial interface on an AGS+ as a Internet firewall gate would be deeply appreciated. Specifically, I am interested in filtering both inbound and outbound packets on that interface; the access-group / extended IP access-list only seems to provide outbound traffic filtering. Running 8.2 -- is *that* the problem? Thanks Richard Huddleston From Firewalls-Owner Wed May 26 21:14:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00189; Wed, 26 May 93 21:14:04 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00169; Wed, 26 May 93 14:13:32 PDT Message-Id: <9305262113.AA00169@mycroft.GreatCircle.COM> To: reh@cs.UMD.EDU (Richard Huddleston) Cc: Firewalls@GreatCircle.COM Subject: Re: Cisco AGS+ as gate In-Reply-To: Your message of Wed, 26 May 93 16:55:21 -0400 Date: Wed, 26 May 93 14:13:30 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk reh@cs.UMD.EDU (Richard Huddleston) writes: # Any pointers or suggestions related to setting up a serial interface on an # AGS+ as a Internet firewall gate would be deeply appreciated. # # Specifically, I am interested in filtering both inbound and outbound packets # on that interface; the access-group / extended IP access-list only seems to # provide outbound traffic filtering. Running 8.2 -- is *that* the problem? I'm not aware of any release of Cisco code that allows inbound filters; that's been one of my two major complaints about their otherwise-good filtering (the other is that they don't let you look at TCP or UDP source port). -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Wed May 26 22:14:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00411; Wed, 26 May 93 22:14:29 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00404; Wed, 26 May 93 15:14:19 PDT Received: by mail-relay-2.mv.us.adobe.com; id AA00107; Wed, 26 May 93 15:15:45 -0700 Received: by guardi.mv.us.adobe.com; id AA02607; Wed, 26 May 93 15:15:41 -0700 Message-Id: <9305262215.AA02607@guardi.mv.us.adobe.com> To: reh@cs.umd.edu (Richard Huddleston) Cc: Firewalls@GreatCircle.COM Subject: Re: Cisco AGS+ as gate In-Reply-To: Your message of "Wed, 26 May 93 16:55:21 EDT." <9305262055.AA19644@bedrock.cs.UMD.EDU> Date: Wed, 26 May 93 15:15:40 MDT From: Tim Guarnieri Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> Any pointers or suggestions related to setting up a serial interface on an >> AGS+ as a Internet firewall gate would be deeply appreciated. Be careful using Cisco routers for filtering packets. Specifically, there are two things to be aware of: (1) Cisco routers do not log packets they have blocked. So, you never know who has been "knocking at your door". (2) The filtering syntax does not allow you to filter on source port, only destination port. This makes rules for some types of connections (i.e. ftp) a bit more "open" than you might like them to be. >> Specifically, I am interested in filtering both inbound and outbound packets >> on that interface; the access-group / extended IP access-list only seems to >> provide outbound traffic filtering. Running 8.2 -- is *that* the problem? The filter rules are only applied in the "transmit" direction. To filter in both directions, you'll need to put rules on your other interfaces(s) and that may cause performance degradation. Tim P.S. As a quick aside, you might look at Jeff Mogul's screend code (available on gatekeeper.dec.com and called screend.tar.Z. I don't remember the exact path). It logs the headers of the packets it rejects and allows you to filter on source port. From Firewalls-Owner Thu May 27 04:49:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01375; Thu, 27 May 93 04:49:02 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01368; Wed, 26 May 93 21:48:53 PDT Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA20441; Thu, 27 May 93 00:49:56 -0400 Date: Thu, 27 May 93 00:49:56 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9305270449.AA20441@bedrock.cs.UMD.EDU> To: Firewalls@GreatCircle.COM Subject: re: AGS+ as firewall gate Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I recently asked: >> Any pointers or suggestions related to setting up a serial interface on an >> AGS+ as a Internet firewall gate would be deeply appreciated. And got some surprisingly bad news. Let me ask a different question: There's an AGS+ with a serial interface hooked to a live Internet gateway. There's a Sun set up as the DNS on an Ethernet interface, also on the AGS+ and I would like for traffic from the serial interface to be directed ONLY ONLY to the DNS machine. I would also like to deny dangerous packets and probes a priori -- on the serial interface, if possible ( although it looks like that it NOT possible, much to my disbelief. An AGS+ is such an EXPENSIVE piece of equipment... ). My access list would, ideally, have looked like this: permit udp eq 53 permit tcp eq 20 permit tcp eq 21 permit tcp eq 23 permit tcp eq 25 With everything else denied. The primary name server has nothing on the internal network configuration; there's a local NS that handles inside name resolution. The primary NS *is* handling mail for the network, and is the sole out/in telnet and ftp host. It's stripped down, doesn't run NIS, doesn't forward packets, is dual-homed ( the second ethernet interface is attached to a different interface and network segment ), and has most of /etc/services and /etc/inetd.conf stripped. Nobody logs in to the machine except admin types, who do the ftp for the users, and who monitor the logs and activity on the machine constanty. Directory and file permissions are set up so that it's almost impossible to move without a privileged shell, and there are no root logins permitted. That serial interface bugs me, though. I expected that I could have just defined the inbound response of that interface, and all would have been right with the world. If there are any suggestions as to how the AGS+ could be set up to move inbound packets from that serial interface ONLY to the primary DNS, I would really appreciate hearing them. I'm starting to get the feeling that I'll have to turn off IP routing, and bridge IP -- just so I can get input-type-list and output-type-list capabilities on the danged interfaces. Since I'd probably have to do protocol filtering at that point, Tim is right about the performance hits. I'd even consider setting up a cheap PC as a go-between. I'm THAT open to suggestions! Tim: > Be careful using Cisco routers for filtering packets. > The filter rules are only applied in the "transmit" direction. To filter > in both directions, you'll need to put rules on your other interfaces(s) and > that may cause performance degradation. Brent: > I'm not aware of any release of Cisco code that allows inbound > filters; that's been one of my two major complaints about their > otherwise-good filtering (the other is that they don't let you look at > TCP or UDP source port). Richard From Firewalls-Owner Thu May 27 07:19:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02081; Thu, 27 May 93 07:19:57 GMT Received: from cadillac.meteo.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02074; Thu, 27 May 93 00:19:42 PDT Received: from zinder.meteo.fr by cadillac.meteo.fr with SMTP id AA20393 (5.65c/IDA-1.4.4 for ); Thu, 27 May 1993 07:22:27 GMT Received: by zinder.meteo.fr (4.1/SMI-4.1) id AA12548; Thu, 27 May 93 09:22:23 +0100 From: Remy.Giraud@meteo.fr (Remy Giraud) Message-Id: <9305270822.AA12548@zinder.meteo.fr> Subject: re: AGS+ as firewall gate To: reh@cs.UMD.EDU (Richard Huddleston) Date: Thu, 27 May 93 9:22:22 BST Cc: Firewalls@GreatCircle.COM In-Reply-To: <9305270449.AA20441@bedrock.cs.UMD.EDU>; from "Richard Huddleston" at May 27, 93 12:49 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > I'm starting to get the feeling that I'll have to turn off IP routing, and > bridge IP -- just so I can get input-type-list and output-type-list > capabilities on the danged interfaces. Since I'd probably have to do > protocol filtering at that point, Tim is right about the performance hits. > > I'd even consider setting up a cheap PC as a go-between. I'm THAT open to > suggestions! Hello, Here at the French Meteo office, we have almost the same requirements. And 6 months ago, we choose a Network Systems router to do filtering. Before that we were using only cisco as Ethernet to FDDI router. We choose a Network Systems router with 2 Ethernet and 2 serial, our access to the outside wolrd is a 1 Mbit/s link. We choose that box because : - easier manageable filtering capabilities - possibility to be informed either locally ( console ) or remotly ( via something equivalent to syslog ) for dropped packets - more pattern selection source address, destination @, ports... - 5 points of filtering ( incoming, outcoming, first, last and in the middle of the router ) - possibility to select an alternate gateway for some packets - ... We are very happy with that, it works fine. Finally the price is almost the same than a cisco CGS. So... Hope this help Regards Remy -- +------------------------------------------------------------+ | | | Remy GIRAUD | | METEO FRANCE Tel : 33 61 07 81 14 | | 42 Avenue G.Coriolis Fax : 33 61 07 81 09 | | 31057 Toulouse Cedex Email : Remy.Giraud@meteo.fr | | France | | | +------------------------------------------------------------+ From Firewalls-Owner Thu May 27 08:04:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02179; Thu, 27 May 93 08:04:52 GMT Received: from hunts.x.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02172; Thu, 27 May 93 01:04:39 PDT Message-Id: <9305270804.AA02172@mycroft.GreatCircle.COM> Received: by hunts.x.co.uk with v1.37.109.4; Thu, 27 May 93 09:06:16 +0100 From: clive@x.co.uk (Clive Feather) Subject: Re: Cisco AGS+ as gate To: timg@mv.us.adobe.com (Tim Guarnieri) Date: Thu, 27 May 93 9:06:15 BST Cc: reh@cs.umd.edu, Firewalls@GreatCircle.COM In-Reply-To: <9305262215.AA02607@guardi.mv.us.adobe.com>; from "Tim Guarnieri" at May 26, 93 3:15 pm Mailer: Elm [revision: 70.85] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Be careful using Cisco routers for filtering packets. Specifically, > there are two things to be aware of: > (2) The filtering syntax does not allow you to filter on > source port, only destination port. This makes rules > for some types of connections (i.e. ftp) a bit more > "open" than you might like them to be. We solved this by modifying ftp slightly to only use ports 65000 upwards for the data connection (as specified in the PORT command). The Cisco filters can be set to allow connections only to ports >= 65000 If your source is anything like mine, then all that's needed is, in function initconn in ftp.c, to make the following change: < if (sendport) < data_addr.sin_port = htons (0); /* let system pick one */ ---- > if (sendport) > data_addr.sin_port = htons (65535 - getpid () % 256 > - time (NULL) % 256); -- Clive D.W. Feather | IXI Ltd (an SCO company) | If you lie to the compiler, clive@x.co.uk | Vision Park | it will get its revenge. Phone: +44 223 236 555 | Cambridge CB4 4ZR | - Henry Spencer Fax: +44 223 236 466 | United Kingdom | From Firewalls-Owner Thu May 27 15:33:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03150; Thu, 27 May 93 15:33:03 GMT Received: from hermes.athena.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03135; Thu, 27 May 93 08:32:37 PDT Received: from dionysus.ATHENA.COM by hermes.athena.com (5.67/1.37) id AA18760; Thu, 27 May 93 11:27:32 -0400 From: benji@athena.com (Benjamin Cline) Message-Id: <9305271527.AA18760@hermes.athena.com> Received: by dionysus. (NX5.67c/NX3.0X) id AA06391; Thu, 27 May 93 11:32:04 -0400 Date: Thu, 27 May 93 11:32:04 -0400 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: firewalls@GreatCircle.COM Subject: Looking for old Usenix Papers Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm looking for some of the papers presented at previous Usenix Security Symposiums. Are there any anonymous ftp sites that have these papers? benji --- Benjamin Cline benji@athena.com Systems Administrator NeXTmail cheerfully accepted! Athena Design, Inc. "Happiness is a warm puppy." From Firewalls-Owner Thu May 27 16:02:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03435; Thu, 27 May 93 16:02:22 GMT Received: from alpha.xerox.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03428; Thu, 27 May 93 09:02:15 PDT Received: from avalon.parc.xerox.com ([13.1.101.241]) by alpha.xerox.com with SMTP id <12176>; Thu, 27 May 1993 09:03:06 PDT Received: by avalon.parc.xerox.com id <2439>; Thu, 27 May 1993 09:01:52 -0700 From: Mark Verber To: firewalls@GreatCircle.COM, benji@athena.com Subject: Re: Looking for old Usenix Papers Message-Id: <93May27.090152pdt.2439@avalon.parc.xerox.com> Date: Thu, 27 May 1993 09:01:50 PDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Some of the papers from the USENIX 3rd Security Symposium can be found on ftp.sage.usenix.org:/pub/usenix/security.3. I haven't started trying to track down the rest of the papers for the archive. If someone on this list has papers that were presented at a USENIX conference or workshop that they would like to be added to the repository, please send me mail. --mark From Firewalls-Owner Thu May 27 16:49:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03566; Thu, 27 May 93 16:49:42 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03559; Thu, 27 May 93 09:49:36 PDT Received: by mail-relay-2.mv.us.adobe.com; id AA02547; Thu, 27 May 93 09:50:36 -0700 Received: by guardi.mv.us.adobe.com; id AA03152; Thu, 27 May 93 09:50:31 -0700 Message-Id: <9305271650.AA03152@guardi.mv.us.adobe.com> To: reh@cs.umd.edu (Richard Huddleston) Cc: Firewalls@GreatCircle.COM, vixie@vix.com Subject: Re: AGS+ as firewall gate In-Reply-To: Your message of "Thu, 27 May 93 00:49:56 EDT." <9305270449.AA20441@bedrock.cs.UMD.EDU> Date: Thu, 27 May 93 09:50:30 MDT From: Tim Guarnieri Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Richard says: >> I'd even consider setting up a cheap PC as a go-between. I'm THAT open to >> suggestions! Well, I just finished porting Jeff Mogul's screend to BSD/386 1.0 on a 486/50 PC (with much help from Paul Vixie). The box has two ethernet interfaces and routing/screening between them works as expected and desired. Unfortunately, the LICENSE agreement that is part of the screend.tar.Z file on gatekeeper.dec.com prohibits third party redistribution of the code or any modifications to it. Basically, all changes need to be given back to DEC WRL. We (Paul & I) are currently in the process of giving the diffs back to the DEC WRL folks. We are hoping to get the diffs incorporated into the screend.tar.Z file on gatekeeper.dec.com, or, at a minimum, to have the diffs be made available on gatekeeper so other folks can apply them if they so desire. When I have more information on the outcome of our endeavor, I'll post it here. The point of bringing this up in this forum at all is that a cheap PC running BSD/386 and a good packet screen (at least what I consider good) would make an ideal screening router solution for those that don't have lots o' bucks to throw at the problem - IMHO. Tim From Firewalls-Owner Thu May 27 16:55:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03592; Thu, 27 May 93 16:55:01 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03585; Thu, 27 May 93 09:54:54 PDT Received: by mail-relay-2.mv.us.adobe.com; id AA02591; Thu, 27 May 93 09:56:26 -0700 Received: by guardi.mv.us.adobe.com; id AA03164; Thu, 27 May 93 09:56:18 -0700 Message-Id: <9305271656.AA03164@guardi.mv.us.adobe.com> To: clive@x.co.uk (Clive Feather) Cc: reh@cs.umd.edu, Firewalls@GreatCircle.COM Subject: Re: Cisco AGS+ as gate In-Reply-To: Your message of "Thu, 27 May 93 09:06:15 BST." <9305270805.AA01537@mail-relay-2.mv.us.adobe.com> Date: Thu, 27 May 93 09:56:17 MDT From: Tim Guarnieri Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Clive says: >> We solved this by modifying ftp slightly to only use ports 65000 upwards >> for the data connection (as specified in the PORT command). The Cisco >> filters can be set to allow connections only to ports >= 65000 True enough. There's a bit of a philosopy difference, here, though. My belief is that you shouldn't need to modify the behavior of your client or server code to compensate for deficiencies in the packet screening mechanism. Granted, sometimes there is no choice. But, in the general case, the ability to use "out of the box" clients is preferable whenever possible. Tim From Firewalls-Owner Thu May 27 17:00:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03627; Thu, 27 May 93 17:00:59 GMT Received: from muse.microunity.com (muse1.microunity.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03620; Thu, 27 May 93 10:00:38 PDT Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA20528; Thu, 27 May 93 10:01:57 PDT Received: from angst.microunity.com by gaea.microunity.com (4.1/muse1.3) id AA05884; Thu, 27 May 93 10:00:33 PDT Received: by angst.microunity.com (5.61/muse.mw-1) id AA03926; Thu, 27 May 93 09:54:45 -0700 From: ericm@angst.MicroUnity.com (Eric Murray) Message-Id: <9305271654.AA03926@angst.microunity.com> Subject: re: AGS+ as firewall gate To: reh@cs.UMD.EDU (Richard Huddleston) Date: Thu, 27 May 93 9:54:44 MDT Cc: Firewalls@GreatCircle.COM In-Reply-To: <9305270449.AA20441@bedrock.cs.UMD.EDU>; from "Richard Huddleston" at May 27, 93 12:49 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Richard Huddleston wrote: > > > There's an AGS+ with a serial interface hooked to a live Internet gateway. > There's a Sun set up as the DNS on an Ethernet interface, also on the AGS+ > and I would like for traffic from the serial interface to be directed ONLY > ONLY to the DNS machine. I would also like to deny dangerous packets and > probes a priori -- on the serial interface, if possible ( although it looks > like that it NOT possible, much to my disbelief. An AGS+ is such an > EXPENSIVE piece of equipment... ). > > My access list would, ideally, have looked like this: > > permit udp eq 53 > permit tcp eq 20 > permit tcp eq 21 > permit tcp eq 23 > permit tcp eq 25 You also need tcp port 53 to/from . The tcp service is needed for zone transfers. If the secondaries can't do zone transfers from you, their record of you gets deleted when it times out. Then all mail to you bounces. Guess how I discovered this? -- ericm ericm@microunity.com From Firewalls-Owner Thu May 27 21:11:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04399; Thu, 27 May 93 21:11:46 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04392; Thu, 27 May 93 14:11:36 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03084; Thu, 27 May 93 17:13:04 -0400 Received: from medtron.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 171201.6853; Thu, 27 May 1993 17:12:01 EDT Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA20619 (5.65c/IDA-1.4.4 for ); Thu, 27 May 1993 15:20:57 -0500 Received: from triton.cis.corp.medtronic.COM ([144.15.69.10]) by medtron.medtronic.COM with SMTP id AA20615 (5.65c/IDA-1.4.4 for ); Thu, 27 May 1993 15:20:55 -0500 Received: by triton.cis.corp.medtronic.COM id AA25403 (5.65c/IDA-1.4.4 for firewalls@GreatCircle.COM); Thu, 27 May 1993 15:21:15 -0500 From: "Dean R. Schrimpf" Message-Id: <199305272021.AA25403@triton.cis.corp.medtronic.COM> Subject: Ok, so what is a "Good" filtering router? To: firewalls@GreatCircle.COM Date: Thu, 27 May 93 15:21:14 CDT Cc: dean.schrimpf@cis.corp.medtronic.com X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, We are sloooowly moving towards an internet connection and were taking for granted that we were going to use a Cisco Router as our firewall router. However with this recent thread regarding the Cisco AGS+ and limitations regarding filtering, we are taking another look at that assumption. We are currently using Cisco Routers and Telebit NetBlazers as our routers of choice. I have also evaluated a 3Com NetBuilder II about 9 months ago, but that evaluation was for use as a bridge not as a router. I would greatly appreciated it, if any of you have evaluated several routers for your opinions regarding which routers work well for firewalls. Cisco? WellFleet? NetBlazer? 3Com? Hughs? Ungerman-Bass? PC based solution? Security will be a major concern, and justification for our move or no move unto the Internet. Dean -- Dean Schrimpf Corporate Information Services (CIS) ============================================================================== Internet: dean.schrimpf@medtronic.com Medtronic, Inc. UUCP: uunet!medtron!dean.schrimpf B100 AT&T: (612) 574-3581 7000 Central Avenue NE FAX: (612) 574-4954 Minneapolis, MN 55432 ============================================================================== From Firewalls-Owner Thu May 27 21:31:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04439; Thu, 27 May 93 21:31:02 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04432; Thu, 27 May 93 14:30:51 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14435>; Thu, 27 May 1993 17:32:10 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA18135 (5.65a/IDA-1.4.2 for benji@athena.com); Thu, 27 May 93 17:10:59 -0400 Received: by dino.alias.com id AA01675 (5.65a/IDA-1.4.2 for firewalls@GreatCircle.COM); Thu, 27 May 93 17:10:58 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9305272110.AA01675@dino.alias.com> Subject: Re: Looking for old Usenix Papers To: benji@athena.com (Benjamin Cline) Date: Thu, 27 May 1993 18:10:57 -0400 Cc: firewalls@GreatCircle.COM In-Reply-To: <9305271527.AA18760@hermes.athena.com> from "Benjamin Cline" at May 27, 93 11:32:04 am X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 523 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I'm looking for some of the papers presented at previous Usenix > Security Symposiums. Are there any anonymous ftp sites that have these > papers? The best thing to do is support USENIX by ordering the conference proceedings; you can have all three for $50 + shipping. -- C. Harald Koch, Network Manager | "You are at wit's end. Passages lead off in Alias Research Inc. Toronto, ON | all directions ... " chk@alias.com | chk@gpu.utcc.utoronto.ca | -Bryan Manske, 13-Aug-92 From Firewalls-Owner Fri May 28 01:09:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05070; Fri, 28 May 93 01:09:12 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05063; Thu, 27 May 93 18:09:04 PDT Received: by mail-relay-2.mv.us.adobe.com; id AA05259; Thu, 27 May 93 17:57:35 -0700 Received: by guardi.mv.us.adobe.com; id AA03596; Thu, 27 May 93 17:57:31 -0700 Message-Id: <9305280057.AA03596@guardi.mv.us.adobe.com> To: firewalls@GreatCircle.COM Subject: Re: Ok, so what is a "Good" filtering router? In-Reply-To: Your message of "Thu, 27 May 93 15:21:14 CDT." <199305272021.AA25403@triton.cis.corp.medtronic.COM> Date: Thu, 27 May 93 17:57:12 MDT From: Tim Guarnieri Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dean R. Schrimpf asks: >> I would greatly appreciated it, if any of you have evaluated several routers >> for your opinions regarding which routers work well for firewalls. I did extensive evaluation of Cisco AGS+ routers as possible firewall gateways. We decided not to go with them here. Here are my conclusions: (1) Cisco does not log rejected packets. We wanted to know when someone was "knocking at our door". (2) Cisco does not provide source port level filtering. We wanted to have that feature on our firewall. Note that there has been religious debate on this issue in several newsgroups. I don't want to start those debates again here. Suffice it to say that, in general, the more flexible your filtering language is, the better off you are. (3) To filter in both directions on a Cisco, you need to use extended access lists on the "Internet side" as well as the "Local Net" side. This causes performance degradation. There is a school of thought that says you only need to filter inbound traffic; traffic initiated from internal hosts to the Internet is "O.K." thus you do not need filters for outbound traffic. This is a risky position at best. If there are any other means of accessing your network (i.e. via dialup modem), and a cracker breaks in to an internal host, they have carte blanche access to the Internet at whatever speed you are running. The company "crown jewels" can be taken quite quickly and, unless you have fairly extensive logging of outbound connections, you may never know it happened. (4) Lastly, Cisco has the notion of an "established" keyword to make decisions on whether or not a connection attempt should be allowed. There have been several problems with this feature as noted in a few CERT advisories. I believe Cisco has fixed these problems, but it is something you should be aware of. In general, I like Cisco routers a lot. They are very good at routing packets fast. We use them all over our internal networks. I'm just not sure they're the best solution for an Internet packet screen. I don't have any firsthand experience with the NetBlazer, but have seen various postings on the net expressing concern about their filtering language and what order their routers parse through the filtering rules. I seem to recall that some behavior was seen that was not expected due to order in which the rules were processed. Hope this helps. Tim From Firewalls-Owner Fri May 28 09:47:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06444; Fri, 28 May 93 09:47:12 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06437; Fri, 28 May 93 02:47:01 PDT Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA06082 (5.65b/HUJI 4.114); Fri, 28 May 93 12:48:12 +0300 Received: from localhost.huji.ac.il by picton.cs.huji.ac.il with SMTP id AA08636 (5.65c/HUJI 4.121); Fri, 28 May 1993 12:52:37 +0300 Message-Id: <199305280952.AA08636@picton.cs.huji.ac.il> To: "Dean R. Schrimpf" Cc: firewalls@GreatCircle.COM Subject: Re: Ok, so what is a "Good" filtering router? In-Reply-To: Your message of Thu, 27 May 93 15:21:14 CDT . <199305272021.AA25403@triton.cis.corp.medtronic.COM> From: Amos Shapira Date: Fri, 28 May 1993 12:52:34 +0300 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <199305272021.AA25403@triton.cis.corp.medtronic.COM> you write: |Hi, | |We are sloooowly moving towards an internet connection and were taking |for granted that we were going to use a Cisco Router as our firewall |router. However with this recent thread regarding the Cisco AGS+ and |limitations regarding filtering, we are taking another look at that |assumption. We are currently using Cisco Routers and Telebit NetBlazers |as our routers of choice. I have also evaluated a 3Com NetBuilder II |about 9 months ago, but that evaluation was for use as a bridge not as |a router. We have here Cisco routers and I have to do my filtering with them, which I'm not happy with. How about sites having one link to the outside world have the Cisco do the routing and put a dual-homed PC between the Cisco and the outside world? Recently there have been announcment of pretty nice PC-based routers which should be able to do this work without affecting the throughput too much. This solution would be hard to implement for sites like us where we have about 4 links to outside the campus. Any comments about how usefull is such a solution? Cheers, --Amos --Amos Shapira (Jumper Extraordinaire) | "It is true that power corrupts, C.S. System Group, Hebrew University, | but absolute power is better!" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- the Demon to his son From Firewalls-Owner Fri May 28 16:11:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07129; Fri, 28 May 93 16:11:20 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07122; Fri, 28 May 93 09:11:13 PDT Received: by mail-relay-2.mv.us.adobe.com; id AA06890; Fri, 28 May 93 09:12:44 -0700 Received: by mumble.mv.us.adobe.com; id AA00368; Fri, 28 May 93 09:12:41 -0700 Message-Id: <9305281612.AA00368@mumble.mv.us.adobe.com> To: firewalls@GreatCircle.COM Subject: Re: Ok, so what is a "Good" filtering router? In-Reply-To: Your message of "Fri, 28 May 93 12:52:34 +0300." <199305280952.AA08636@picton.cs.huji.ac.il> Date: Fri, 28 May 93 09:12:38 -0700 From: Tim Guarnieri X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> How about sites having one link to the outside world have the Cisco >> do the routing and put a dual-homed PC between the Cisco and the outside >> world? Recently there have been announcment of pretty nice PC-based >> routers which should be able to do this work without affecting the >> throughput too much. If the connection to the outside world is at T1 speed or less, this shouldn't be much of a problem. You could have an ethernet interface on the Cisco attached to a "border" subnet and on that subnet you could have a PC-based router with two ethernet cards (one on the "border" net; one on an "internal" net). Since ethernet is 10MB/s and T1 is 1.54MB/s you shouldn't have any performance problems on the PC-based screening router. If your link to the Internet is 10MB/s or greater, then you may have some throughput issues with a PC-based screening router w/ ether cards. In this case, if higher speed cards are available for the PC you could potentially use those. Or, you could use a workstation with two ethernet interfaces (or higher speed interfaces, if available). Once you get above 10MB/s there are fewer options that fit this model and they will depend on the structure of your internal network at the "connection point" to the Internet. >> This solution would be hard to implement for sites like us where we have >> about 4 links to outside the campus. Well, maybe not. Can you have those four links connect to the same "border" net? If so, the model I described above would still work. Tim From Firewalls-Owner Fri May 28 19:19:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08098; Fri, 28 May 93 19:19:28 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08091; Fri, 28 May 93 12:19:18 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09111; Fri, 28 May 93 15:20:35 -0400 Received: from racerx.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 151819.25229; Fri, 28 May 1993 15:18:19 EDT Received: by racerx (4.1/SMI-4.0) id AA12681; Fri, 28 May 93 12:59:54 CDT Date: Fri, 28 May 93 12:59:54 CDT From: ken@bridge.COM (Ken Hardy) Message-Id: <9305281759.AA12681@racerx> To: firewalls@GreatCircle.COM Subject: Re: Ok, so what is a "Good" filtering router? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In Message <199305280952.AA08636@picton.cs.huji.ac.il> Amos Shapira wrote: >and the outside world? Recently there have been announcment of pretty nice >PC-based routers which should be able to do this work without affecting the >throughput too much. ... >Any comments about how usefull is such a solution? Yes, a few weeks ago I recall seeing an announcement of a PC-based filtering bridge or router that looked interesting. Unfortunately, I'm now unable to find any trace of that announcement. I'd appreciate it if anyone could forward a copy of that announcement (or anything related) either to me or to the mailing list. -KH From Firewalls-Owner Sat May 29 16:19:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11927; Sat, 29 May 93 16:19:48 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11920; Sat, 29 May 93 09:19:03 PDT Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA28393; Sat, 29 May 93 12:18:52 -0400 Date: Sat, 29 May 93 12:18:52 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9305291618.AA28393@bedrock.cs.UMD.EDU> To: Firewalls@GreatCircle.COM Subject: Ciscos as firewall gates, Part 2 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk First, thanks to everyone for the education. I've learned more about Cisco access lists, and setting up firewalls in general, over the past week than I have over the past year. I need an opinion about how important it is to know who's banging on the gate -- regardless of whether they get in or not. What we're considering setting up at the site in question waxes between an installation where we can record the headers of all packets refused, and one where we don't. If we don't care who knocks, then the installation is trivially easy: we can just set up a Cisco IGS as the Internet interface, and filter the packets coming out of the IGS and into the local network ( managed by the AGS+ ). If we *do* care, then (1) won't IP ACCOUNTING record source and destination addresses of packets, if we, say, leave ICMP replies on? and (2) if we have to do something more complicated than just setting up an IGS, what options are there? We'd prefer not to not have to kiss a resource like a Sun workstation goodbye -- which we'd have to do if we were going to run the Internet interface into one. But, there's already been a decision not to dedicate a PC to the task; it's the machine of choice, somehow, for the user community. We'd either have to toss a Sun to the task, or an IGS. If we decide to care who is trying to get in, what has to be done to set up a filtering router on it so that we can capture headers ? Thanks again, Richard Huddleston From Firewalls-Owner Sat May 29 16:37:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11968; Sat, 29 May 93 16:37:42 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11961; Sat, 29 May 93 09:36:54 PDT Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA12554 (5.65b/HUJI 4.114); Sat, 29 May 93 19:36:50 +0300 Received: from localhost.huji.ac.il by picton.cs.huji.ac.il with SMTP id AA09814 (5.65c/HUJI 4.121 for ); Sat, 29 May 1993 19:41:26 +0300 Message-Id: <199305291641.AA09814@picton.cs.huji.ac.il> To: firewalls@GreatCircle.COM Subject: Using a PC for filtering, the package name is.... From: Amos Shapira Date: Sat, 29 May 1993 19:41:18 +0300 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello again, I mentioned that I saw an announcment about a package which could be used to filter packets as a firewall but couldn't remember its name. I think the name is "Beholder, the Next Generation" (aliased "btng"?) or its companion "gobbler". I don't remember the exact function of each of these (one of them is a network snooper, that's for sure) but I think they can also filter and route packets. Hope this helps, --Amos --Amos Shapira (Jumper Extraordinaire) | "It is true that power corrupts, C.S. System Group, Hebrew University, | but absolute power is better!" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- the Demon to his son From Firewalls-Owner Sat May 29 17:32:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12042; Sat, 29 May 93 17:32:11 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12035; Sat, 29 May 93 10:31:39 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09318; Sat, 29 May 93 13:33:05 -0400 Date: Sat, 29 May 93 13:33:04 -0400 From: uworld!uucp@uunet.uu.net Message-Id: <9305291733.AA09318@relay2.UU.NET> Received: from uworld.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 133114.23247; Sat, 29 May 1993 13:31:14 EDT Apparently-To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From rik Sat May 29 10:11:07 1993 remote from crow Reply-To: crow!rik Received: by crow.spirit.com (4.1/SMI-4.1) id AA01382; Sat, 29 May 93 10:11:07 MST Date: Sat, 29 May 93 10:11:07 MST From: crow!rik (Rik Farrow) Message-Id: <9305291711.AA01382@crow.spirit.com> To: uworld!uunet!greatcircle.com!firewalls Subject: PC filtering solutions Ken hardy writes > I'd appreciate it if > anyone could forward a copy of that announcement (or anything related) > either to me or to the mailing list. I had kept a couple of references to PC-based filters taken from the firewalls list, but had cut of the volume number where they appear. Here are portions of each posting with contact information: --- The OSU KarlBridge is a program, that runs on a 286 or 386 clone. It provides a unique and inexpensive Ethernet to Ethernet bridge that performs sophisticated protocol filtering. The bridge can be configured to filter packets based upon ANY Ethernet protocol such as IP, IPX, DECNET, AppleTalk, and etc. In addition it will filter packets based upon IP address, IP network, IP subnet, and socket. It will also filter packets based upon DECNET address, area, Object number and Object name. Also, AppleTalk packets can be filtered based upon server name, printer name, and/or zone name. The OSU KarlBridge can be obtained via anonymous ftp from: nisca.acs.ohio-state.edu, 128.146.1.7, in /pub/kbridge. Please send e-mail to kbridge@osu.edu with questions and comments. Doug Karl Senior Computer Specialist The Ohio State University --- From: mischler@Cubic.COM (Dave Mischler) Date: Fri, 15 Jan 93 13:43:19 -0500 Subject: Cheap Packet Filtering I have added a packet filtering implementation to Phil Karn's KA9Q software (930104 version) based on many of the ideas in Brent Chapman's paper, "Network (In)Security Through IP Packet Filtering". I want to make this software generally available both because I think it is useful and because I want beta testers and/or better ideas. I will place no restrictions on the code, but the copyrights of Phil Karn and other authors of the KA9Q software may not be infringed. The last time I looked the shareware fee for commercial sites was $50 for the KA9Q package (it is free to schools and ham radio operators, or for evaluation purposes). I would like an anonymous FTP site on which to put the source and executables, as well as some feedback from testers. ... [no site given in this posting] --- Rik Farrow rik@uworld.com From Firewalls-Owner Sat May 29 19:13:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12428; Sat, 29 May 93 19:13:50 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12420; Sat, 29 May 93 12:13:39 PDT Message-Id: <9305291913.AA12420@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (16.8/16.2) id AA17565; Sun, 30 May 93 05:14:37 +1000 From: Darren Reed Subject: Re: Ciscos as firewall gates, Part 2 To: reh@cs.UMD.EDU (Richard Huddleston) Date: Sun, 30 May 1993 05:14:37 +1000 (EST) Cc: Firewalls@GreatCircle.COM In-Reply-To: <9305291618.AA28393@bedrock.cs.UMD.EDU> from "Richard Huddleston" at May 29, 93 12:18:52 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: 842 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On the issue of having ICMP replies issued for packets that become blocked, is this the correct way to have a router respond ? One problem that quickly comes to mind is when using a cisco as a firewall, allowing certain services out such as rlogin, ftp, etc and then have the other end of the service try to perform an ident query (while ident's port is blocked) resulting in an ICMP unreachable and the connection being dropped due to the kernel not handling the error correctly. I recall reading somewhere that ICMP port unreachables are *only* to be generated in response to UDP packets to 'unattached' ports; there being the means within TCP to handle this condition. Personally, I prefer filters to drop things `quietly', not giving the outsider any clue as to whether the host exists, is down or the packet was filtered >:) Darren From Firewalls-Owner Sat May 29 20:54:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12842; Sat, 29 May 93 20:54:18 GMT Received: from rip.psg.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12835; Sat, 29 May 93 13:54:10 PDT Received: by rip.psg.com (Smail3.1.28.1 #5) id m0nzXw5-000305C; Sat, 29 May 93 13:55 PDT Message-Id: From: randy@psg.com (Randy Bush) Subject: Re: Ciscos as firewall gates, Part 2 To: avalon@coombs.anu.edu.au (Darren Reed) Date: Sat, 29 May 1993 13:55:24 -0700 (PDT) Cc: Firewalls@GreatCircle.COM In-Reply-To: <9305291913.AA12420@mycroft.GreatCircle.COM> from "Darren Reed" at May 30, 93 05:14:37 am Content-Type: text Content-Length: 796 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > One problem that quickly comes to mind is when using a cisco as a firewall, > allowing certain services out such as rlogin, ftp, etc and then have the > other end of the service try to perform an ident query (while ident's port > is blocked) resulting in an ICMP unreachable and the connection being > dropped due to the kernel not handling the error correctly. This problem is sufficiently prevalent that one has to stop issuing the ident query, rendering ident effectively dead. The bug in the net1 kernel which causes the disconnect is a real pain. > Personally, I prefer filters to drop things `quietly', not giving the > outsider any clue as to whether the host exists, is down or the packet > was filtered >:) Which, the firewalled sites say, is why they give host unreachable. randy From Firewalls-Owner Sat May 29 22:31:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13166; Sat, 29 May 93 22:31:38 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13158; Sat, 29 May 93 15:31:27 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03316; Sat, 29 May 93 18:33:08 -0400 Date: Sat, 29 May 93 18:33:08 -0400 From: uworld!uucp@uunet.uu.net Message-Id: <9305292233.AA03316@relay2.UU.NET> Received: from uworld.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 183101.29451; Sat, 29 May 1993 18:31:01 EDT Apparently-To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From rik Sat May 29 15:05:38 1993 remote from crow Reply-To: crow!rik Received: by crow.spirit.com (4.1/SMI-4.1) id AA01468; Sat, 29 May 93 15:05:38 MST Date: Sat, 29 May 93 15:05:38 MST From: crow!rik (Rik Farrow) Message-Id: <9305292205.AA01468@crow.spirit.com> To: uworld!uunet!greatcircle.com!firewalls Subject: Another PC filter solution Cc: uworld!uunet!bridge.com!ken In an earlier posting, I left out drawbridge, another PC filtering package available from Texas A&M. It comes with a package including the PC software, TIGER, apparently a COPS-like package but with at least some of the cryptographic features of tripwire, and NETLOG, a logging and query tool for tcp/udp connection attempts (find out if someone has been knocking at your door. I can't say that I have looked at this one yet, but it sounds good. This package is available via anonymous ftp in sc.tamu.edu:pub/security/TAMU CONTACT: Comments and questions are most welcome. Please address them to: drawbridge@sc.tamu.edu rik@uworld.com From Firewalls-Owner Sat May 29 23:05:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13268; Sat, 29 May 93 23:05:05 GMT Received: from sc.tamu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13259; Sat, 29 May 93 16:04:54 PDT Received: from posaune.tamu.edu by sc.tamu.edu (AA01441); Sat, 29 May 93 18:06:21 CDT Message-Id: <9305292306.AA01441@sc.tamu.edu> Received: by posaune.tamu.edu (NX5.67c/NX3.0X) id AA01414; Sat, 29 May 93 18:06:18 -0500 Date: Sat, 29 May 93 18:06:18 -0500 From: David-Hess@sc.tamu.edu Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Firewalls@GreatCircle.COM Subject: Re: Firewalls Digest V2 #96 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Yes, a few weeks ago I recall seeing an announcement of a PC-based > filtering bridge or router that looked interesting. Unfortunately, I'm > now unable to find any trace of that announcement. I'd appreciate it if > anyone could forward a copy of that announcement (or anything related) > either to me or to the mailing list. > > - -KH We will be putting out an update on this package in a few days and it will be posted to a few Usenet groups and this mailing list. If you can't wait, send me a note and I will send you a copy of our original announcement. The whole thing is available via anonymous ftp from: sc.tamu.edu:pub/security/TAMU Dave --- David K. Hess Graduate Assistant David-Hess@tamu.edu Supercomputer Center (409) 845-6907 (work) Texas A&M University From Firewalls-Owner Sun May 30 00:48:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13455; Sun, 30 May 93 00:48:31 GMT Received: from bunyip.cc.uq.oz.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13448; Sat, 29 May 93 17:48:19 PDT Message-Id: <9305300048.AA13448@mycroft.GreatCircle.COM> Received: from [130.102.4.22] (actually ethernet_mac2.vthrc.uq.oz.au) by bunyip.cc.uq.oz.au with SMTP (PP); Sun, 30 May 1993 10:49:02 +1000 Date: Sun, 30 May 1993 10:49:03 +1000 To: firewalls@GreatCircle.COM From: vthrc@mailbox.uq.oz.au (Danny Thomas) Subject: Re: Using a PC for filtering, the package name is.... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Amos Shapiro writes: >I mentioned that I saw an announcment about a package which could be used to >filter packets as a firewall but couldn't remember its name. I think the >name is "Beholder, the Next Generation" (aliased "btng"?) or its companion >"gobbler". I don't remember the exact function of each of these (one of them >is a network snooper, that's for sure) but I think they can also filter and >route packets. these packages, available from dnpap.et.tudelft.nl, are concerned with packet monitoring and network management. The relevant parts of the index file are: Beholder The newest Network Monitor with SNMP! DnpapTools Various tools by the DNPAP group. Gobbler Packet catcher, writting by the DNPAP group. Full featured packet catcher with many filters, extended packet viewer. NetCure The Network Monitoring package developed by the DNPAP Group. Hardware requirements: A fast PC (286 or 386 will do) and a ethernet card (such as the 3com or wd cards). A color display is not requirement, but netmon is very beautiful in colors. Sage SNMP query language based on Scheme, from the famous DNPAP group. Spectre Host profiling, measures activity and type of activity of a number of specified hosts on a network. I'm not aware of PD PC-based routers with filtering (PCRoute doesn't, and I've never heard what happened with its' commercialization, anyone know?), but there are at least two bridges with filtering capabilities: KarlBridge nisca.acs.ohio-state.edu /pub/kbridge Drawbridge sc.tamu.edu pub/security/TAMU I'll be interested to see if Novell include filtering capabilities in the next release of their multi-protocol routing software package; runs on a PC with multiple interfaces and handles IPX, TCP/IP, AppleTalk & OSI. cheers, Danny Thomas. From Firewalls-Owner Sun May 30 04:44:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13780; Sun, 30 May 93 04:44:43 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13773; Sat, 29 May 93 21:44:36 PDT Received: by terminus.cs.umb.edu id AA02461 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Sun, 30 May 1993 00:45:15 -0400 Date: Sun, 30 May 1993 00:45:15 -0400 From: "John B. Brown" Message-Id: <199305300445.AA02461@terminus.cs.umb.edu> To: amoss@cs.huji.ac.il, dean.r.schrimpf@cis.corp.medtronic.com Subject: Re: Ok, so what is a "Good" filtering router? Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Amos, What would be wrong with a USED 3b2 and a couple of ethernet cards? The NI software package allows 10 cards on the box, and you can use the appropriate firewall software to create an entirely separate net for your internal machines. There cheap too, a lot cheaper than a new Cisco/PC combination. They run standard ethernet, so their plenty fast, at least good enough for T1. Shalom, JBB. From Firewalls-Owner Sun May 30 05:18:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13827; Sun, 30 May 93 05:18:51 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13815; Sat, 29 May 93 22:18:41 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA17423; Sun, 30 May 93 01:21:14 EDT Date: Sun, 30 May 93 01:21:14 EDT From: Marcus J Ranum Message-Id: <9305300521.AA17423@TIS.COM> To: firewalls@GreatCircle.COM Subject: cheap screening routers - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At DEC I used to build all my routers from MicroVAXIIs running ULTRIX and screend. Even a lowly MicroVAX with 4mb of memory running ULTRIX, gated, screend, and syslogd could keep up pretty well. It imposed about a 2ms routing delay ether to ether, but I could and did live with that. Talk about cheap hardware. :) At least at DEC there were folks whose eyes would light up when I asked if they wanted to donate a MicroVAX... :) mjr. From Firewalls-Owner Sat May 29 23:50:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14353; Sun, 30 May 93 06:45:04 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14125; Sat, 29 May 93 23:37:21 PDT Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA15168 (5.65b/HUJI 4.114); Sun, 30 May 93 09:15:12 +0300 Received: from localhost.huji.ac.il by picton.cs.huji.ac.il with SMTP id AA10365 (5.65c/HUJI 4.121); Sun, 30 May 1993 09:19:51 +0300 Message-Id: <199305300619.AA10365@picton.cs.huji.ac.il> To: "John B. Brown" Cc: firewalls@GreatCircle.COM, dean.r.schrimpf@cis.corp.medtronic.com Subject: Re: Ok, so what is a "Good" filtering router? In-Reply-To: Your message of Sun, 30 May 1993 00:45:15 -0400 . <199305300445.AA02461@terminus.cs.umb.edu> From: Amos Shapira Date: Sun, 30 May 1993 09:19:47 +0300 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <199305300445.AA02461@terminus.cs.umb.edu> you write: |Dear Amos, | | What would be wrong with a USED 3b2 and a couple of ethernet cards? |The NI software package allows 10 cards on the box, and you can use the |appropriate firewall software to create an entirely separate net for your |internal machines. There cheap too, a lot cheaper than a new Cisco/PC |combination. They run standard ethernet, so their plenty fast, at least |good enough for T1. | | Shalom, | | JBB. John, I'm sure others on the list can give you much more accurate data but I think a potential bottleneck to watch for might be the PC's bus, which I suspect will present a big delay (everything is relative, of course, and you should decide if you care about this delay). Is there such a thing as two or more ethernet interfaces on one PC card? (I find it hard to believe, but who knows). This is how our Cisco routes all our packets among our network segments practically faster than the ether speed (but I guess that's why it costs us more than most of our workstations :). Would anyone care to comment about the expected speed of the above-suggested configuration? Cheers, --Amos --Amos Shapira (Jumper Extraordinaire) | "It is true that power corrupts, C.S. System Group, Hebrew University, | but absolute power is better!" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- the Demon to his son From Firewalls-Owner Sun May 30 02:53:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14909; Sun, 30 May 93 09:29:38 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14900; Sun, 30 May 93 02:29:24 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) id AA09606; Sun, 30 May 93 02:26:32 -0700 Received: by yeager.corp.sgi.com (930416.SGI/911001.SGI) for @sgigate.sgi.com:Firewalls@GreatCircle.COM id AA11282; Sun, 30 May 93 02:26:31 -0700 Date: Sun, 30 May 93 2:26:31 PDT From: Eliot Lear To: Brent Chapman Cc: Firewalls@GreatCircle.COM Subject: Re: New file transfer protocol: FSP In-Reply-To: Your message of Thu, 13 May 93 18:38:18 -0700 Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A clarification on one of Brent's old postings: > "established" keyword that some routers use for TCP filtering. For > these reasons, I recommend blocking UDP all together, except for > specific server-to-server conversations for specific protocols (DNS, > NTP, maybe RIP, etc.). RIP is a broadcast protocol- it should not be allowed in. If you send a unicast to a machine that is stupid enough to believe its information, you can effect at least a denial of service attack. Eliot Lear [lear@sgi.com] From Firewalls-Owner Mon May 31 01:28:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16710; Mon, 31 May 93 01:28:27 GMT Received: from norman.li.Cubic.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16699; Sun, 30 May 93 18:28:16 PDT Received: by norman.li.Cubic.COM (5.67/1.34a) id AA19542; Sun, 30 May 93 21:29:46 -0400 Date: Sun, 30 May 93 21:29:46 -0400 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9305310129.AA19542@norman.li.Cubic.COM> To: uworld!uucp@uunet.uu.net Cc: firewalls@GreatCircle.COM, mischler@Cubic.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9305291711.AA01382@crow.spirit.com> Rik Farrow quoted part of my initial message announcing the availability of my packet filtering modifications to KA9Q, and notes that no site name was provided. This package now supports filtering by packet type (any, icmp, icmp redirect, icmp except redirect, tcp, tcp with syn, tcp except with syn, udp) source and destination address, and source and destination port ranges. Filter entry matches are counted, and messages that can be easily logged by Unix syslogd can be generated based upon filter entries for permitted and/or denied packets. At present, the best site to get this software from is ftp.demon.co.uk in directory /pub/ibmpc/dm930319. The file dm930319.doc describes the commands added to KA9Q, and provides sample configuration files. I would be interested in hearing from any sites that may want to provide anonymous FTP access to this software, or anyone who wishes to apply my changes to another version of KA9Q. I have never used this package with 2 ethernet cards, but I would be interested in hearing from anybody who wants to use it that way. I know of no technical reasons why it shouldn't work. Dave Mischler mischler@cubic.com From Firewalls-Owner Mon May 31 06:17:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17506; Mon, 31 May 93 06:17:09 GMT Received: from Spectrum.CMC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17499; Sun, 30 May 93 23:17:00 PDT Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA23279; Sun, 30 May 93 23:17:37 PDT Newsgroups: list.firewalls Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: Ok, so what is a "Good" filtering router? Message-Id: <1993May31.061728.23235@spectrum.CMC.COM> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA References: <199305300619.AA10365@picton.cs.huji.ac.il> Date: Mon, 31 May 93 06:17:28 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >In message <199305300445.AA02461@terminus.cs.umb.edu> someone writes: >| What would be wrong with a USED 3b2 and a couple of ethernet cards? >|The NI software package allows 10 cards on the box, and you can use the >|appropriate firewall software to create an entirely separate net for your >|internal machines. There cheap too, a lot cheaper than a new Cisco/PC >|combination. They run standard ethernet, so their plenty fast, at least >|good enough for T1. In article <199305300619.AA10365@picton.cs.huji.ac.il> amoss@cs.huji.ac.il (Amos Shapira) writes: >I'm sure others on the list can give you much more accurate data but I think >a potential bottleneck to watch for might be the PC's bus, which I suspect >will present a big delay (everything is relative, of course, and you should >decide if you care about this delay). The AT&T 3B2 is NOT a PC. It is a PDP-11 class minicomputer (built around a processor chipset called WE-32000) which is rather limited by a slow I/O bus. Just before AT&T shut down most of the old AT&T computer division, they had come out with a respectable processor upgrade with a MIPS-3000 processor on it. The 3B2 would have been but a quaint footnote in computer history had it not been for two outstanding features: (1) It was the host for the System V release 3 Unix reference implementation, so everyone who wanted to port System V to some better machine had to buy one whether they liked it or not. (2) It was built like an old Mack truck and had that 15-year-MTBF robustness. I know people from the US Department of Agriculture that claim to have driven them out to miserable rural outposts ion Western Montana in the back of a pickup truck and plugged them in to the regular office outlet and neither heatwaves, dust storms nor twisters ever took them down for longer than it took to reboot after the power came back. This kind of reliabilty also made it a favorite of the US Air force for many "general small computer applications." The original disk controller was very slow, but somewhere along the line they picked up a decent SCSI controller. They were not well sutited for networking. You could get 200 KB/sec of TCP transfers out of it under the stock WIN/3B TCP/IP networking package, but there would not be any processor left ... My team did a better networking package, based on an embedded MC68000 with a maximum configuration of 4 ethernets and an X.25 line. It worked quite well. You can run the same 200 KB/sec of FTP though our package and still have 95% of your CPU available to run applications on the 3B2. Unfortunately, you have to go through AT&T Federal Systems to buy it. Amos Shapira also writes: >Is there such a thing as two or more ethernet interfaces on one PC card? (I >find it hard to believe, but who knows). This is how our Cisco routes all >our packets among our network segments practically faster than the ether speed >(but I guess that's why it costs us more than most of our workstations :). A 3B2/600G with an MNP network package is an okay little router. It is not cheap, however. And as far as I know, neither WIN/3B nor the MNP kit support any kind of packet filtering. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256