From Firewalls-Owner@GreatCircle.COM Thu Oct 1 03:00:38 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA29882; Thu, 1 Oct 92 03:00:38 PDT Received: from grasp1.univ-lyon1.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA29869; Thu, 1 Oct 92 03:00:29 PDT Received: by grasp1.univ-lyon1.fr (5.67a8/IDA-1.5) via Rocad id AA38643; Thu, 1 Oct 1992 10:59:43 +0100 Date: Thu, 1 Oct 1992 10:59:43 +0100 From: Christophe Wolfhugel Message-Id: <199210010959.AA38643@grasp1.univ-lyon1.fr> Reply-To: Christophe.Wolfhugel@grasp.insa-lyon.fr To: firewalls@GreatCircle.COM Subject: Adresses compilation X-Charset: ASCII X-Char-Esc: 29 Sender: Firewalls-Owner@GreatCircle.COM It would be nice to have a compilation of the several companies furnishing products which might be needed for firewalls (such as those who sell the SecureNet keys and other similar stuff). I'll summarize and send to the list in a few days (end of next week) the received information. Be as precise as possible, and include fax, phone, email when available, as well as other stuff that might be of interest. Chris From Firewalls-Owner@GreatCircle.COM Thu Oct 1 08:17:36 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA00540; Thu, 1 Oct 92 08:17:36 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA00534; Thu, 1 Oct 92 08:17:31 PDT Message-Id: <9210011517.AA00534@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Thu, 1 Oct 92 11:01:34 EDT To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM >A good part of a secure system is the ability to see "who's knocking" >as well as leaving an audit trail. > >This is a nice feature of Jeff Moguls screend (and BPF). Does anyone >know with certainty what a Cisco will do? We have suggested to Cisco that they provide a means of forwarding all rejected packets to a specified machine and port. This would allow logging, plus implementation of some solid, high-performance gateways with the connection policies determined by a user program. Bill Cheswick AT&T Bell Laboratories From Firewalls-Owner@GreatCircle.COM Thu Oct 1 09:37:49 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA00640; Thu, 1 Oct 92 09:37:49 PDT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA00634; Thu, 1 Oct 92 09:37:38 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA23659; Thu, 1 Oct 92 12:37:11 -0400 Received: from mercomp.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 123509.720; Thu, 1 Oct 1992 12:35:09 EDT Received: from darkstar.merc.comp by mercomp (4.0/SMI-4.0) id AA17524; Thu, 1 Oct 92 11:36:43 EDT Date: Thu, 1 Oct 92 11:36:43 EDT From: blu@mc.com (Brian Utterback) Message-Id: <9210011536.AA17524@mercomp> To: firewalls@GreatCircle.COM Subject: Logging IP traffic Sender: Firewalls-Owner@GreatCircle.COM I am currently deciding between two distributed network analysis tools, namely the Network General SniffMaster system and the Concord Communications Trakker system. One advantage of the Trakker however, is that it manintains a log of all TCP/IP connections. I was thinking that putting one of these on our bastion segment would be useful in that it would sit quietly, recording all the connections and then once every couple hours a script could download the info and log it to a file. In fact, Concord has plans to add out-of-band serial backup, so when this is available, the download could take place entirely without any netwrok traffic. So what do you think? Sound like something workable, or am I missing something? Brian Utterback blu@mc.com Network Manager Mercury Computer Lowell, MA 01854 From Firewalls-Owner@GreatCircle.COM Thu Oct 1 14:19:03 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA01114; Thu, 1 Oct 92 14:19:03 PDT Received: from interlock.reston.ans.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA01108; Thu, 1 Oct 92 14:18:55 PDT Received: by interlock.reston.ans.net id AA11962 (InterLock SMTP Gateway 1.1 for firewalls@greatcircle.com); Thu, 1 Oct 1992 17:18:44 -0500 Received: by interlock.reston.ans.net (Internal Mail Agent-1); Thu, 1 Oct 1992 17:18:44 -0500 Date: Thu, 1 Oct 92 17:10:29 -0400 From: root@reston.ans.net Message-Id: <9210012110.AA17464@hoops.reston.ans.net> To: firewalls@GreatCircle.COM Subject: Updated InterLock Product Summary (long) Sender: Firewalls-Owner@GreatCircle.COM Due to the amount of replies to my previous post and the interest in commercial firewalls, I decided to post an updated product summary. This summary includes a discussion of the upcoming release of the InterLock. This message is not meant to be an official announcement, but rather an early discussion of things to come later this year. The summary of the current version (1.1) is included for completeness, and is basically a rewording of the previous post. INTERLOCK VERSION 1.1 SUMMARY No IP Packet Forwarding The InterLock does not allow for the automatic forwarding of IP packets between the public network (e.g. Internet) and a private network. This means that the InterLock (which is an IBM RS/6000 320H) is the only visible machine to the public network from the private network and vice versa. SMTP, FTP, and TELNET Support In order for users to cross the private/public network boundary, they must utilize one of the InterLock provided security-enhanced application gateways. Version 1.1 includes security-enhanced versions of SMTP, FTP, and TELNET. These security enhancements include the rewriting of SMTP headers to hide internal host information, additional level of password protection between the networks, and logging of security relevant events. The FTP and TELNET daemons have been rewritten to provide increased end to end transparency after connection establishment through the InterLock. This supports file transfer and telnet option negotiation from source to destination transparently through the InterLock. InterLock Accounts The InterLock supports a special security administrator account with commands for configuring of the available services to reflect the desired security policy. The InterLock also provides a restricted login shell for authorized users. These restricted logins allow users to perform functions such as ping and finger, and more importantly telnet to remote hosts. Users are given no local disk space, nor access to most local files. Only the administrator can manipulate the local filesystem. Remote root access is only permitted under very controlled circumstances. NEW FEATURE GROUPS FOR VERSION 2.0 Access Control Rule Base Version 2.0 of the InterLock contains a versatile access control rule base which supports the definition of the allowable usage of the application gateways. These rules restrict the access to SMTP, FTP, TELNET, NNTP, and X based on the following criteria: requesting user, time of day, day of week, and (host or network) source and destination addresses. Each rule also defines the associated degree of access allowed: no access, unidirectional in or out only, or bidirectional access. Additionally, control over whether the optional hardware or software encryption is employed. This access control rule base is a central control point for administrators to define their company's ADP security policy. The access controls defined within the rule base specify all of the capabilities available to the public network as wells as the those of the private network's users. X Window System The InterLock includes support for the passage of the X Window System protocol between the public and private network. When X is desired, this support coupled with the rule base, allows administrators to configure in a single location which hosts, users and days/times when X may be used. Since, the InterLock does not allow for a direct connection between the server and client, the destination X server only needs to "xhost +" the Interlock not any client's host. Network New Transfer Protocol (NNTP) Private network users can now post and receive USENET news articles through the Interlock using the new NNTP support. The header of each posted article will be rewritten to remove any private network information, while still allowing for SMTP replies to be received by the poster. Control over who may post, read or not participate in news can also be accomplished using the InterLock. Optional Encryption Version 2.0 has an optional DES, packet encryption scheme. This allows pairs of InterLock-protected sites to pass sensitive information across a public network without fear of disclosure. Using the rule base, this service can be configured to only encrypt particular protocols (e.g. FTP, TELNET) between InterLock-protected networks, while using unencrypted protocols with other public network sites. ____________________________________________________________________________ Paul Sangster Advanced Network & Services Software Engineer 1875 Campus Commons Dr. sangster@reston.ans.net Suite 220, Reston VA 22091 (703) 758-7706 ____________________________________________________________________________ From Firewalls-Owner@GreatCircle.COM Thu Oct 1 14:44:16 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA01234; Thu, 1 Oct 92 14:44:16 PDT Received: from vanilla.lcs.mit.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA01228; Thu, 1 Oct 92 14:44:10 PDT Received: by vanilla.lcs.mit.edu id AA05106; Thu, 1 Oct 92 17:44:24 -0400 Message-Id: <9210012144.AA05106@vanilla.lcs.mit.edu> To: Firewalls@GreatCircle.COM Subject: Re: Packet Filter vs. Packet Screen In-Reply-To: Message from mulligan@pa.dec.com of 29 Sep 92 17:49:18 PDT Date: Thu, 01 Oct 92 17:44:24 -0400 From: treese@vanilla.lcs.mit.edu X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM > Brent writes: > >> I don't know of anyone other than DEC which uses the terminology > >> "packet screen". Geoff replies: > Except the "Berkeley Packet Filter". > > I agree the the terms are confusing and I think that "packet filter" > sounds like what the intention is, ie to filter what packets are > forwarded. But, if people are talking about using the Berkeley Packet > Filter or referencing Jeff's paper on the "Packet Filter" in the > context of IP packet forwarding determination they are mistaken. Give Jeff a break. He had named some software the "packet filter" quite a few years ago, before filtering (or screening) packets came into vogue. Win Treese MIT Laboratory for Computer Science treese@lcs.mit.edu From Firewalls-Owner@GreatCircle.COM Thu Oct 1 15:03:37 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA01314; Thu, 1 Oct 92 15:03:37 PDT Received: from tfs.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA01308; Thu, 1 Oct 92 15:03:32 PDT Received: from ts2.tfs.com by tfs.COM (5.61/1.00 (TRP - gateway)) id AA25996; Thu, 1 Oct 92 15:03:25 -0700 Received: by ts2.TFS.COM (5.51/1.00 (TRP - mailsrv)) id AA16084; Thu, 1 Oct 92 15:03:23 PDT Received: by edev0.TFS (5.51/cf-0.0/02/10-88) id AA03522; Thu, 1 Oct 92 15:03:09 PDT Posted-Date: Thu, 01 Oct 92 15:02:56 -0700 Message-Id: <9210012203.AA03522@edev0.TFS> To: howesb@sfu.ca Cc: firewalls@GreatCircle.COM, shipley%edev0.Tfs.COM@gateway.Tfs.COM Subject: Re: So what is vulnerable? A list.. Phone: (510) 849-2230 Snail-Address: 2560 Bancroft way #51;Berkeley CA 94704-1700 Precedence: special-delivery In-Reply-To: Your message of Tue, 29 Sep 92 09:21:30 -0800. Date: Thu, 01 Oct 92 15:02:56 -0700 From: Peter Shipley Sender: Firewalls-Owner@GreatCircle.COM >snmp 161/udp # can wreak havok on network services if snmp > # is not configured in a secure mannor. >domain 53/tcp # can add fake enteries domain db cache >domain 53/udp # can add fake enteries domain db cache >printer 515/tcp # Cancel jobs? overwrile system files. >NeWS 144/tcp # can upload postscript threads into your NeWS server # thus can spy on you or gain access a shell. >bootp 67/udp # get info on you system configuration. >X11 6000/tcp # can spy on on you, wreak havok etc.. From Firewalls-Owner@GreatCircle.COM Fri Oct 2 07:57:09 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA03955; Fri, 2 Oct 92 07:57:09 PDT Received: from brahms.udel.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA03949; Fri, 2 Oct 92 07:57:04 PDT Received: by brahms.udel.edu (5.65c/IDA-1.2.8) id AA03251; Fri, 2 Oct 1992 10:57:20 -0400 Date: Fri, 2 Oct 1992 10:57:20 -0400 From: Cristy Message-Id: <199210021457.AA03251@brahms.udel.edu> To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM root@beaner.ans.net says: > Version 2.0 of the InterLock contains a versatile access control rule > base which supports the definition of the allowable usage of the > application gateways. These rules restrict the access to SMTP, FTP, > TELNET, NNTP, and X based on the following criteria: requesting user, > time of day, day of week, and (host or network) source and destination > addresses... This access control rule base is a central control point > for administrators to define their company's ADP security policy... A principal of Raptor Systems asked me to post this. Direct comments to Raptor Systems, not me, at (302) 996-3331. Thank you for recognizing the importance of the features you are going to incorporate at some future date in Intralock (rule base, X and NNTP filter). Raptor Systems has been delivering these features in out Eagle product to corporations, universities, and government agencies for the last year. Our customers have found these features to be essential to securing their networks. Your announcements underscores the importance of network security and demonstrates the necessity to go beyond routers as security devices. From Firewalls-Owner@GreatCircle.COM Fri Oct 2 16:27:09 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA05692; Fri, 2 Oct 92 16:27:09 PDT Received: from udel.edu (louie.udel.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA05686; Fri, 2 Oct 92 16:27:04 PDT Received: from dewey.udel.edu by louie.udel.edu id aa24374; 2 Oct 92 19:21 EDT Date: Fri, 2 Oct 92 19:21:34 EDT X-Mailer: Mail User's Shell (6.5 4/17/89) From: "Douglas B. McKillip" To: firewalls@GreatCircle.COM Message-Id: <9210021921.aa17032@dewey.udel.edu> Sender: Firewalls-Owner@GreatCircle.COM A response to the announcement of Interlock by the founder of Raptor Systems: (not myself; however, inquiries can be directed to me) Raptor Systems is indeed flattered and honored that ANS will be incorporating into Interlock a subset of the features that have been in our Eagle Network Isolator since 1991. It is not ofter that a little company can influence so large a company so quickly. But this not a case of competition between companies, it is a struggle between people who have systems and data that they wish to protect and those who would tamper and destroy. The ultimate winner of the friendly competition between ANS and Raptor will be the users of the protected systems. We invite anyone who is interested to examine the current Eagle family and evaluate, for themselves, our comprehensive auditing facilities, intrusion detection capabilities and "backdoor protection". From Firewalls-Owner@GreatCircle.COM Fri Oct 2 16:34:41 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA05708; Fri, 2 Oct 92 16:34:41 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA05702; Fri, 2 Oct 92 16:34:36 PDT Message-Id: <9210022334.AA05702@mycroft.GreatCircle.COM> Received: by inet; Fri Oct 2 19:34 EDT 1992 From: smb@ulysses.att.com To: "Douglas B. McKillip" Cc: firewalls@GreatCircle.COM Date: Fri, 02 Oct 92 19:34:21 EDT Sender: Firewalls-Owner@GreatCircle.COM Umm -- we all want information on different protection systems, but we also agreed that advertising wasn't appropriate for this list. In my opinion -- and I'm speaking only for myself -- the last two notes about Raptor have gone far across that line. From Firewalls-Owner@GreatCircle.COM Fri Oct 2 17:23:48 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA05814; Fri, 2 Oct 92 17:23:48 PDT Received: from noc2.dccs.upenn.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA05808; Fri, 2 Oct 92 17:23:42 PDT Received: from GYNKO.CIRC.UPENN.EDU by noc2.dccs.upenn.edu id AA26581; Fri, 2 Oct 92 20:23:30 -0400 Received: by gynko.circ.upenn.edu id AA07021; Fri, 2 Oct 92 20:24:48 EDT From: rsk@gynko.circ.upenn.edu (Rich Kulawiec) Posted-Date: Fri, 2 Oct 92 20:24:47 EDT Message-Id: <9210030024.AA07021@gynko.circ.upenn.edu> Subject: Re: your mail To: smb@ulysses.att.com Date: Fri, 2 Oct 92 20:24:47 EDT Cc: mckillip@udel.edu, firewalls@GreatCircle.COM In-Reply-To: <9210022334.AA05702@mycroft.GreatCircle.COM>; from "smb@ulysses.att.com" at Oct 2, 92 7:34 pm Organization: Cardiothoracic Imaging Research Center X-Queued-Mail: 990 pending mail messages (1872998 characters) X-Last-River: Codorus X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM >Umm -- we all want information on different protection systems, but >we also agreed that advertising wasn't appropriate for this list. >In my opinion -- and I'm speaking only for myself -- the last two >notes about Raptor have gone far across that line. I fully agree; if any of us really need to read Raptor's marketroid hype, we need only open a copy of "Unix Today", oops, sorry, "Open Systems Today" and we will be able to read our fill. ---Rsk From Firewalls-Owner@GreatCircle.COM Fri Oct 2 18:38:13 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA05911; Fri, 2 Oct 92 18:38:13 PDT Received: from grebyn.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA05905; Fri, 2 Oct 92 18:38:04 PDT Received: by grebyn.com (5.57/SMI-4.1/kan.8.19.92) id AA11074; Fri, 2 Oct 92 21:36:33 -0400 Received: by genesis.grebyn.com (4.1/SMI-4.1) id AA24772; Fri, 2 Oct 92 21:36:29 EDT Date: Fri, 2 Oct 92 21:36:29 EDT From: karl@grebyn.com (Karl A. Nyberg) Message-Id: <9210030136.AA24772@genesis.grebyn.com> Politics: Republican - Bush-Quayle in 92 To: firewalls@GreatCircle.COM Subject: Repeat offer: collect literature, etc Sender: Firewalls-Owner@GreatCircle.COM Last week I offered to reduce traffic with this message. Perhaps this week I can reduce marketing overhead. Keep those cards and letters coming! Thanks to all those people who have sent in material and all those who have offered to help review. (Note to marketing [ht]ypes - I may not have collected all the firewalls mail, so if you don't send me something and you aren't in the FAQ, know who's fault it's going to be? :-)) -- Karl -- From brent@GreatCircle.COM Sat Oct 3 00:14:38 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA06333; Sat, 3 Oct 92 00:14:38 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA06324; Sat, 3 Oct 92 00:14:35 PDT Message-Id: <9210030714.AA06324@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: How I deal with bounced Firewalls messages Reply-To: Brent@GreatCircle.COM Date: Sat, 03 Oct 92 00:14:34 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM If you have email problems, then find that you aren't getting Firewalls or Firewalls-Digest any more after you get the problems solved, I've probably dropped you from the list because of the problems. In order to maintain my own sanity and ability to get any work done, if a given email address bounces for more than a day or so, I typically simply drop it from the list. Getting the problem fixed, resubscribing to the list, and retrieving the archive to catch up on what you missed are up to you. Sorry for the hard-nosed policy, but my mailbox has been filled with an incredible amount of bounced Firewalls mail lately, and I need to do something about it. Having the bounced messages go to a different mailbox isn't a solution; my schedule being what it is, I'd never take the time to look at that other mailbox. The solution is to reduce the number of bounced messages, and that means aggressively pruning the list. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Sat Oct 3 11:21:17 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07069; Sat, 3 Oct 92 11:21:17 PDT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07063; Sat, 3 Oct 92 11:20:58 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA04170; Sun, 4 Oct 92 04:20:53 +1000 Date: Sun, 4 Oct 92 04:20:53 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9210031820.AA04170@coombs.anu.edu.au> To: Firewalls@GreatCircle.COM Subject: Filters and interfaces. Sender: Firewalls-Owner@GreatCircle.COM From documentation presented here on this list and available for products such as screend for Ultrix and SGI's packet filter daemon, its seems that most filters have one set of rules through which all packets must pass. While fair, this would seemingly slow down the network traffic which is never going to be filtered and even more so if the host which is acting as the filter is routing more than two network connections. To reduce both the size of filter rulesets as well as increasing throughput of non-filtered traffic, it would seem better to be able to setup a different filter rule set for each interface connected to the host. Are there any working packet filters which are able to operate in this way or does anyone know of any texts which discuss this ? With this approach, you could more easily block packets from outside which were trying to be internal hosts. cheers, Darren. From Firewalls-Owner@GreatCircle.COM Sat Oct 3 12:09:15 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07137; Sat, 3 Oct 92 12:09:15 PDT Received: from flare.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07131; Sat, 3 Oct 92 12:08:55 PDT Received: by flare.cs.umb.edu id AA01264 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Sat, 3 Oct 1992 15:08:34 -0400 Date: Sat, 3 Oct 1992 15:08:34 -0400 From: "John B. Brown" Message-Id: <199210031908.AA01264@flare.cs.umb.edu> To: rsk@gynko.circ.upenn.edu, smb@ulysses.att.com Subject: Re: your mail Cc: firewalls@GreatCircle.COM, mckillip@udel.edu Sender: Firewalls-Owner@GreatCircle.COM >>Umm -- we all want information on different protection systems, but >>we also agreed that advertising wasn't appropriate for this list. >>In my opinion -- and I'm speaking only for myself -- the last two >>notes about Raptor have gone far across that line. > >I fully agree; if any of us really need to read Raptor's marketroid hype, >we need only open a copy of "Unix Today", oops, sorry, "Open Systems Today" >and we will be able to read our fill. I suppose the blatant hype from the sales department employees at Dec hadn't already done that, or was that particular hype classified as `technical details'? JBB. From Firewalls-Owner@GreatCircle.COM Sat Oct 3 18:50:35 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07427; Sat, 3 Oct 92 18:50:35 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07421; Sat, 3 Oct 92 18:50:29 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA09791; Sat, 3 Oct 92 21:50:19 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA22767; Sat, 3 Oct 92 21:50:18 -0400 Date: Sat, 3 Oct 92 21:50:18 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210040150.AA22767@hussar.dco.dec.com> To: firewalls@GreatCircle.COM Subject: Re: paper in progress Sender: Firewalls-Owner@GreatCircle.COM I apologise for my inappropriate posting. I assumed that everyone who was on the mailing list had *asked* to be. :) I did actually put a fair bit of thought into deciding if I should send it in PostScript or not, and concluded that PostScript is as close to a reasonable document interchange standard as exists today, and that I was not utterly out of line. Possibly I was, and I apologise. If someone feels they have suffered undue hardship on their phone bill, they can contact me personally and we'll work things out. Considering the traffic in this mailing list, what's another 60Kb anyhow? :) (Nothing like coming back from vacation to hundreds of mail messages about firewalls!) My reasoning in blasting that chunk of text out to all and sundry was to get it in the archive and on the table early, since I think it's worth trying to at least vaguely classify what the hell a "firewall" is and what various breeds of them do. I realize it's incomplete and is far from definitive, but I like to think it's useful - I wrote it more for myself, as a means of keeping my wits about me when trying to explain firewalls to execs who may not be concerned with the technology as much as those of us on the implementation end. I will make ASCII and PostScript versions available for FTP when I get in to my office. Again, I apologise. Chalk it up to enthusiasm. mjr. From Firewalls-Owner@GreatCircle.COM Sat Oct 3 19:29:33 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07482; Sat, 3 Oct 92 19:29:33 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07476; Sat, 3 Oct 92 19:29:29 PDT Message-Id: <9210040229.AA07476@mycroft.GreatCircle.COM> Received: by inet; Sat Oct 3 22:29 EDT 1992 From: smb@ulysses.att.com To: "John B. Brown" Cc: firewalls@GreatCircle.COM Subject: Re: your mail Date: Sat, 03 Oct 92 22:28:52 EDT Sender: Firewalls-Owner@GreatCircle.COM I suppose the blatant hype from the sales department employees at Dec hadn't already done that, or was that particular hype classified as `technical details'? Yes, I'd classify what I saw from DEC as technical details. Ditto what I saw from Sun and SGI and some of the earlier postings about Raptor. What irritated me about this particular message -- and why I started these thread in the first place -- was the bit about ``well, we're glad they're copying us, since we've been doing that for N time units''. Plus, of course, the part about how the users are the real winners -- that's pure hype. Look -- we know that users benefit from firewalls; that's why we're on this list. We're walking a thin line here. We all want information about different options. And that, in turn, means that we want, desire, and even need participation by vendors. But they, in turn, are obligated to present material appropriate for this forum -- which includes acknowledging deficiencies if appropriate in context. --Steve Bellovin From Firewalls-Owner@GreatCircle.COM Sat Oct 3 19:31:48 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07498; Sat, 3 Oct 92 19:31:48 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07492; Sat, 3 Oct 92 19:31:42 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA10407; Sat, 3 Oct 92 22:31:58 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA22959; Sat, 3 Oct 92 22:31:51 -0400 Date: Sat, 3 Oct 92 22:31:51 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210040231.AA22959@hussar.dco.dec.com> To: firewalls@GreatCircle.COM Subject: filtering mail (was Re: coversion to digest) Sender: Firewalls-Owner@GreatCircle.COM >P.S. "Just read it all at the end of the day" is not really an option >if you are constantly monitoring your mail for security alerts and other >"need to know right now" things. Being a longtime armchair military historian, I tend to see too many things in terms of grand strategy and tactics. ;) Running a firewall can be looked on as a simple intelligence problem. Consider that what you are trying to do is "leverage" a huge amount of important security-related stuff into a small area that you can get a handle on. It stands to reason that you should have some kinds of mechanisms in place that let you quickly and effectively deal with important information as soon as it comes in - but not *TOO* *MUCH* important information (I mean, who really reads their VMS console's inance beepings?). This is the "boy who cried wolf" scenario with a vengeance.. One example is that I once configured my tftpd to log all tftp accesses to wherever I was logged in at the time. I had to fix that in a hurry when someone started trying to boot a misconfigured router... Signals intelligence is the art of knowing what to ignore, and knowing what to flag as information that must be followed-up-upon. My firewall logs perhaps 1Mb of stuff a day. I *sometimes* get an email message at night with a summary of anything interesting, *if* it occurred that day, and if I'm logged in while the interesting thing occurs I am notified immediately. Obviously, if I'm not logged in, screaming at me isn't going to help, so my software tries to preserve as much useful bits as it can, and summarizes them every night. If you're still operating in a "read every message subject header to see if it's important" mode for security, you can't be very serious about security, or email, or getting work done. I know this for a fact, since I have a lot of problems in the latter area myself, due to email interrupts. ;) mjr. From Firewalls-Owner@GreatCircle.COM Sat Oct 3 23:41:47 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07793; Sat, 3 Oct 92 23:41:47 PDT Received: from gate.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07787; Sat, 3 Oct 92 23:41:40 PDT Received: from demon.demon.co.uk by gate.demon.co.uk id aj03640; 4 Oct 92 7:37 BST Received: from cellnet.uucp by demon.demon.co.uk id aa11028; 4 Oct 92 4:51 BST From: Steve Kennedy Message-Id: <6083.9210040025@marvin.gbnet.org> Subject: Filters and interfaces To: greatcircle.com!firewalls@gbnet.org Date: Sun, 4 Oct 92 0:25:31 GMT X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Most bridges will filter selectively. The algorithms should be set out so that packets are 'progressively' filtered, i.e. if it meets the criteria it passes to the next stage. The approach can be parallelised to get faster throughput. Steve -- Steve Kennedy _____ ___ ___ \\| / / / / \ \\\ \| Flat 2 / --- | ` oo 43 Howitt Rd __/_ / \ \___/ C ) London NW3 4LU (freak) \'/~~ |>o<| Tel +44 71 483 1169 Voice //////V\\\\ Data: 44 71 483 2454 Trailblazer T2500 PEP/V32/V42(bis) \\\|||o|\\\\ O data: 44 72 483 2455 Miracom Courier HST/DS+ V32bis/HST \\\|||||\\\// \\\|o|||||| Email steve@gbnet.org (home) .|||||||| steve@marvin.demon.co.uk (SMTP Internet) stevek@cellnet.co.uk (work) From Firewalls-Owner@GreatCircle.COM Sun Oct 4 09:33:22 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA08354; Sun, 4 Oct 92 09:33:22 PDT Received: from erenj.com (ereapp.erenj.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA08348; Sun, 4 Oct 92 09:33:01 PDT Received: by erenj.com (5.65/mjr-920806); id AA17630; Sun, 4 Oct 92 12:33:03 -0400 Received: by eredns.erenj.com (5.65/ml-mailv1.1); id AA07876; Sun, 4 Oct 92 12:33:02 -0400 Received: by maverick1.erenj.com (5.57/bdb-mailv1.0); id AA07396; Sun, 4 Oct 92 12:33:01 -0400 Date: Sun, 4 Oct 92 12:33:01 -0400 From: bdboyle@maverick1.erenj.com (Bryan D. Boyle) Posted-Date: Sun, 4 Oct 92 12:33:01 -0400 Message-Id: <9210041633.AA07396@maverick1.erenj.com> To: smb@ulysses.att.com Subject: advertising Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM I feel the same way. "Speeds and Feeds" isn't what we are discussing here, if the commercial vendors want to talk, then talk to the problem instead of product-pushing drivel. Bryan D. Boyle From Firewalls-Owner@GreatCircle.COM Sun Oct 4 10:10:14 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA08405; Sun, 4 Oct 92 10:10:14 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA08399; Sun, 4 Oct 92 10:10:09 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA02357; Sun, 4 Oct 92 13:10:19 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA26072; Sun, 4 Oct 92 13:10:18 -0400 Date: Sun, 4 Oct 92 13:10:18 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210041710.AA26072@hussar.dco.dec.com> To: firewalls@GreatCircle.COM, howesb@sfu.ca Subject: Re: So what is vulnerable? A list.. Sender: Firewalls-Owner@GreatCircle.COM >Has anybody just listed the known ports on Unix machines and which ones are >vulnerable, thus indicating which ones should be disabled, selectively >disabled, or monitored? It's a trickier problem than it seems at first glance. Consider that "vulnerable" with respect to a server needs to take into account (at least) several factors: a) The operating system: even if it's just unix - whose? b) The service: is it a service that might inherently be a security problem. Rdist is an example of such a service. c) The implementation: can you trust the actual version of the software to do what it's supposed to do? Early versions of finger and sendmail are examples. d) The installation: sometimes software that should be set up a certain way isn't. An example of this is Sun's /etc/hosts.equiv file - even if we assume for the sake of argument that Sun's rlogind/rshd are perfect, the security of the system as a whole is weakened. I'm afraid my answer is "I don't *KNOW*" and I believe that a good firewall administrator's fear of the unknown should encourage him or her to disable or kill as much of the unknown as possible. (This is easy, really, since it seems a pretty basic human response) Being paranoid, one should pretend that EVERY port is vulnerable, and then limit services as much as possible in response, carefully vetting the few services that one does provide. This isn't practical in real life, but I find that if you *think* that way, and then think in terms of making specific exceptions, it increases your level of awareness of what those exceptions are, and why they are justified. mjr. From Firewalls-Owner@GreatCircle.COM Sun Oct 4 15:27:56 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA08648; Sun, 4 Oct 92 15:27:56 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA08642; Sun, 4 Oct 92 15:27:51 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA06479; Sun, 4 Oct 92 18:27:41 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA27931; Sun, 4 Oct 92 18:27:37 -0400 Date: Sun, 4 Oct 92 18:27:37 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210042227.AA27931@hussar.dco.dec.com> To: firewalls@GreatCircle.COM Subject: Re: SUMMARY: internet addresses Sender: Firewalls-Owner@GreatCircle.COM Fred writes: (about masking improperly addressed networks with a firewall) >If you, say, use network 16 as your internal network, how will you tell >your gateway to get packets to the real network 16 (Digital Equipment Corp.)? >How will you ensure that you can get to both your network 16 and ours? You can't. That's one problem with the scheme. So if my machine is addressed as though it's in University of Fubar's network, and it's really on DEC's network - I'm stuck. But then I was stuck/stupid to begin with. ;) The times when I've seen this work is when a network is being "cut over" from an improperly addressed network to a NIC-sanctioned network. It's still a win because it means that the network "cut over" needn't be all-or-nothing, and it's a huge win because the firewall provides an important service that people are willing to reconfigure their machines to use. Inside of Digital, we configure our FTP proxy to reject all hosts that don't have a reverse address mapping. This way, if a subnet isn't set up right, they don't get to use the FTP proxy. It is amazing how quickly people will fix things if you give them a reason to. mjr. From Firewalls-Owner@GreatCircle.COM Sun Oct 4 18:37:31 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA08919; Sun, 4 Oct 92 18:37:31 PDT Received: from gossip.pyramid.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA08912; Sun, 4 Oct 92 18:37:27 PDT Received: from shield.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA29296; Sun, 4 Oct 92 18:37:20 -0700 Received: by shield.eng.pyramid.com (5.67/DC/OSx1.1) id AA05384; Sun, 4 Oct 92 18:37:43 -0700 From: mfrost@shield.eng.pyramid.com (Mark Frost) Message-Id: <9210041837.ZM5382@shield.eng.pyramid.com> Date: Sun, 4 Oct 1992 18:37:42 -0700 X-Mailer: Z-Mail (2.1b.23 9/2/92) To: firewalls@GreatCircle.COM Subject: How to do proxy ftp? Sender: Firewalls-Owner@GreatCircle.COM Pardon my ignorance but how exactly does on to proxy ftp? If I understand what it is correctly it allows one to do ftp "through" a host. (Please correct me if I'm wrong). Somehow I haven't got the sense of what's involved to set this up from the ftp man page. Thanks for your help -m----------- Mark "Hoek" Frost (mfrost@pyramid.com) ---mmm--------- R&D Lab Manager Group -----mmmmm------- Pyramid Technology Corporation -------mmmmmmm----- 3860 North First Street ---------mmmmmmmmm--- San Jose, California 95134 (408) 428-8163 From brent@GreatCircle.COM Sun Oct 4 20:17:10 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09289; Sun, 4 Oct 92 20:17:10 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09277; Sun, 4 Oct 92 20:16:37 PDT Message-Id: <9210050316.AA09277@mycroft.GreatCircle.COM> To: mfrost@shield.eng.pyramid.com (Mark Frost) Cc: firewalls@GreatCircle.COM Subject: Re: How to do proxy ftp? In-Reply-To: Your message of Sun, 4 Oct 1992 18:37:42 -0700 Reply-To: Brent@GreatCircle.COM Date: Sun, 04 Oct 92 20:16:36 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM mfrost@shield.eng.pyramid.com (Mark Frost) writes: # Pardon my ignorance but how exactly does on to proxy ftp? If I understand # what it is correctly it allows one to do ftp "through" a host. (Please # correct me if I'm wrong). Somehow I haven't got the sense of what's # involved to set this up from the ftp man page. You understand correctly. The reason you can't find anything on it in the standard FTP man page is that it's not a standard feature of FTP. To do proxy FTP, you run a custom FTP client on your internal machines. This custom client has been modified so that, no matter where you tell it you want to connect to, it connects to your proxy machine, and tells the proxy machine where you want to connect to. The proxy machine then connects to the ultimate destination, and plays pass-through on the data. Sort of like making a long-distance phone call in the days before direct long-distance dialing. Proxy TELNET works much the same way: you run a custom client, it connects to your proxy server and tells it who you really want to talk to, the proxy server connects to the ultimate destination and plays pass-through. I'm not a big fan of proxy TELNET and FTP systems for several reasons. The first is what you've already hit upon: they're not a standard part of the operating system. This means you've got to install custom client programs (replacements for "ftp" and "telnet" that know how to talk to the proxy server) on all your internal machines that want to use the net. If proxy version of your client programs aren't available (which is usually the case for Mac and PC client programs), you're just out of luck. The second reason I'm not a big fan of proxy systems is that they add complexity and give you more exposure to single-point-failures (the proxy server going down), unless they're smart to know about multiple servers (I doubt most of them are, but I don't know). Finally, I've yet to have anybody ask for anything both reasonable and significant that can be done with a proxy telnet/ftp setup that can't be done with a carefully and properly constructed packet filtering setup. I'm sure that there _are_ examples, but in the several firewall systems I've built for clients in the last couple of years and the several more I'm currently building, the advantages of packet filtering have far outweighed the advantages of proxy services. There are several proxy services that work, and work to such a degree that folks don't even think of them as proxy services; I'm talking about things like SMTP, NNTP, NTP, and DNS. People _expect_ servers running these protocols to proxy for other servers and clients (though most of them don't do it synchronously). I'm not opposed to proxy systems per se, just proxy systems for protocols that weren't designed for such use, and for which appropriate clients aren't widely available. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From brent@GreatCircle.COM Sun Oct 4 20:55:40 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09421; Sun, 4 Oct 92 20:55:40 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09405; Sun, 4 Oct 92 20:55:07 PDT Message-Id: <9210050355.AA09405@mycroft.GreatCircle.COM> To: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Cc: firewalls@GreatCircle.COM Subject: Reverse and double-reverse IP address lookups as service prerequisites In-Reply-To: Your message of Sun, 4 Oct 92 18:27:37 -0400 Reply-To: Brent@GreatCircle.COM Date: Sun, 04 Oct 92 20:55:06 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) writes: # Inside of Digital, we configure our FTP proxy to reject all # hosts that don't have a reverse address mapping. This way, if a # subnet isn't set up right, they don't get to use the FTP proxy. It # is amazing how quickly people will fix things if you give them a # reason to. A variety of implementations of a number of services, particularly SMTP and FTP servers, do this. I find it mildly annoying, but not really a problem. One sticky issue is: what if I desire to hide the internal naming structure of my network? I think this is a valid goal, given that project information can sometimes be inferred simply by knowing what the machines are named, and that any such handle you get is something that "the bad guys" can for "social engineering" their way past an unwitting receptionist or security staff. I resolve this by using a wildcard PTR record in my DNS data so that all but hosts with explicit PTR records (the gateway/firewall hosts, for instance) return "unknown" (actually "unknown.domain.net", for whatever the appropriate "domain.net" is) when you do an address-to-name translation through DNS. This satisfies the service provider's desire to know who they're talking to (they know what domain it is, at least), and satisfies my desire to to keep my internal network structure and naming private. The thing I _really_ think is a problem is so-called "double reverse" lookups. In a double reverse lookup, after you do the address-to-name translation to find the name of the host that's calling you, you then do a name-to-address translation on that name to see if the address you get back matches the address that's calling you. If the two addresses don't match, you disallow the connection. I don't know what that's really supposed to provide in the way of security, but it sure screws up systems which hide internal hostnames as descirbed above, and systems where machines with multiple network interfaces appear to be separate machines in the DNS databases (I know this _shouldn't_ be necessary, but it often _is_ necessary to work around routing and configuration limitations in today's software). If you look up "unknown.MyDomain.COM", which IP address from a hidden internal machine should I give you? And what if you look up 143.191.19.66 and get back "nb.MyDomain.COM", and then look up "nb.MyDomain.COM" and get back 143.191.20.66 (because that's the _other_ interface on nb.MyDomain.COM)? What we've got here is a dilemna: on the one hand, we've got the desire of the service provider to know exactly who they're talking to. On the other hand, we've got the desire of the service user to hide their internal network naming and structure. Whose desire should win out? In the long run, I think double-reverse is going to go away. I don't see that it really buys you any security as a service provider; it just trips you up over everybody else's buggy DNS databases and security measures. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Mon Oct 5 00:14:52 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09635; Mon, 5 Oct 92 00:14:52 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09629; Mon, 5 Oct 92 00:14:47 PDT Message-Id: <9210050714.AA09629@mycroft.GreatCircle.COM> Received: by inet; Mon Oct 5 03:12 EDT 1992 From: smb@ulysses.att.com To: Brent@GreatCircle.COM Cc: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites Date: Mon, 05 Oct 92 03:12:19 EDT Sender: Firewalls-Owner@GreatCircle.COM The thing I _really_ think is a problem is so-called "double reverse" lookups. In a double reverse lookup, after you do the address-to-name translation to find the name of the host that's calling you, you then do a name-to-address translation on that name to see if the address you get back matches the address that's calling you. If the two addresses don't match, you disallow the connection. I don't know what that's really supposed to provide in the way of security, but it sure screws up systems which hide internal hostnames as descirbed above, and systems where machines with multiple network interfaces appear to be separate machines in the DNS databases (I know this _shouldn't_ be necessary, but it often _is_ necessary to work around routing and configuration limitations in today's software). It's very necessary. Since the forward and reverse trees are entirely separate, if I control a reverse tree for my address space -- either legitimately or because I've subverted a machine -- I can change the reverse mapping to name a machine I know you trust. The multiple interface case isn't a problem. Here's how I set things up. The real name of the machine maps to multiple addresses. If I need more than one, I'll have additional names that map to each individual address. The inverse map generally maps back to the major name; since the code checks the entire list of addresses, it's not a problem. Ultimately, that whole notion may go away, but that won't happen until a real (i.e., cryptographic) authentication system is deployed. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 02:19:25 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09814; Mon, 5 Oct 92 02:19:25 PDT Received: from percy.rain.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09808; Mon, 5 Oct 92 02:19:05 PDT Received: by percy.rain.com (/\==/\ Smail3.1.25.1 #25.8) id ; Mon, 5 Oct 92 02:18 PDT Received: by escargot.RAIN.COM (/\==/\ Smail3.1.20.1 #20.1) id ; Mon, 5 Oct 92 02:19 PDT Message-Id: To: mfrost@shield.eng.pyramid.com (Mark Frost) Cc: firewalls@GreatCircle.COM Subject: Re: How to do proxy ftp? In-Reply-To: Your message of "Sun, 04 Oct 92 18:37:42 PDT." <9210041837.ZM5382@shield.eng.pyramid.com> Date: Mon, 05 Oct 92 02:19:13 PDT From: Marc Frajola Sender: Firewalls-Owner@GreatCircle.COM In <9210041837.ZM5382@shield.eng.pyramid.com>, Mark Frost writes: > Pardon my ignorance but how exactly does on to proxy ftp? If I understand > what it is correctly it allows one to do ftp "through" a host. (Please > correct me if I'm wrong). Somehow I haven't got the sense of what's > involved to set this up from the ftp man page. If I understood the question, you're asking specifically about the 'proxy' command available in later versions of ftp (like those distributed with 4.3bsd). Brent (below) answered your question about how to setup a true proxy feature to ftp through a firewall. If you were referring to the 'proxy' command noted in the ftp man page: The proxy feature already built into ftp is not a "true" proxy -- it requires that the two endpoints (the primary and secondary FTP servers you have open) be able to send IP packets directly to EACH OTHER. Most firewall setups do not allow FTP packets to pass through on the standard FTP ports, so this proxy feature is useless to most sites that are truly firewalled. Most site administrators have realized this, and have done some degree of router filter hacking, FTP client or server hacking, or some combination of those to allow users to FTP out from their site. While I'm here, I have a point or two to add to Brent's reply... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Then in <9210050316.AA09277@mycroft.GreatCircle.COM>, Brent Chapman replies: > mfrost@shield.eng.pyramid.com (Mark Frost) writes: > > # Pardon my ignorance but how exactly does on to proxy ftp? If I understand > # what it is correctly it allows one to do ftp "through" a host. (Please > # correct me if I'm wrong). Somehow I haven't got the sense of what's > # involved to set this up from the ftp man page. > > You understand correctly. The reason you can't find anything on it in > the standard FTP man page is that it's not a standard feature of FTP. > > To do proxy FTP, you run a custom FTP client on your internal > machines. This custom client has been modified so that, no matter > where you tell it you want to connect to, it connects to your proxy > machine, and tells the proxy machine where you want to connect to. > The proxy machine then connects to the ultimate destination, and plays > pass-through on the data. Sort of like making a long-distance phone > call in the days before direct long-distance dialing. While there are advantages to a custom FTP client, it's also an option to run a proxy FTP server that will work with a standard FTP client. In fact, after working within a firewalled environment for several months, I finally got the hacking urge to do just that. After a few months of testing, user feedback has been very positive. From the user's point of view, here's how it looks: $ ftp -n proxy_server proxy_port [FTP connects to the Proxy Server, which is sitting on a different TCP port number than a regular FTP server. The FTP client thinks it's talking to a real FTP server at this point, but it's not. The -n is to tell it not to authenticate since it's not talking to a real server yet.] ftp> quote open real.internet.host.domain [The Proxy Server connects to 'real.internet.host.domain', and then enters a total pass-through mode. At this point, the client thinks it is directly connected with the server, and the server thinks it is directly connected with the client.] ftp> user ftp [The user must authenticate now that a real server is connected.] Password: [The user enters the password, and is then finally connected and ready to issue FTP commands.] ftp> dir, get, put, etc. [Standard FTP interchange of commands such as dir, get, put.] ftp> quit [The Proxy Server sees the final QUIT and closes connection to the server.] I've even developed an 'expect' wrapper that will proxy out to a host and log me in as anonymous. This means I can run one easy command on a machine behind the firewall and get connected/logged-in to an FTP server. Rather convenient, eh? In the next round of changes I'm going to make, I think I can even work around the need to use 'ftp -n' making it much more convenient without the expect wrapper. > I'm not a big fan of proxy TELNET and FTP systems for several reasons. > The first is what you've already hit upon: they're not a standard part > of the operating system. This means you've got to install custom > client programs (replacements for "ftp" and "telnet" that know how to > talk to the proxy server) on all your internal machines that want to > use the net. If proxy version of your client programs aren't > available (which is usually the case for Mac and PC client programs), > you're just out of luck. This problem is the biggie fixed by setting up a proxy server that will work with a stock (standard) FTP client. > The second reason I'm not a big fan of proxy systems is that they add > complexity and give you more exposure to single-point-failures (the > proxy server going down), unless they're smart to know about multiple > servers (I doubt most of them are, but I don't know). Agreed. And as long as we have firewalls, the machines that have access behind and in front of the firewall will be a scarce resource, and loading is certainly a hot issue there. > Finally, I've yet to have anybody ask for anything both reasonable and > significant that can be done with a proxy telnet/ftp setup that can't > be done with a carefully and properly constructed packet filtering > setup. I'm sure that there _are_ examples, but in the several > firewall systems I've built for clients in the last couple of years > and the several more I'm currently building, the advantages of packet > filtering have far outweighed the advantages of proxy services. The security people where I work have never had the least bit of interest in allowing TCP connections from the outside world all the way through the firewall to end-user nodes. Period. In our environment, this completely rules out packet filtering on a router since (if I'm not mistaken) FTP requires the server to make a TCP connection back on a port that the FTP client determines dynamically. The only way I could think of to make this work via a packet filter would be to somehow tell the FTP client to have the server always connect back on a (single) predetermined port, and get the networking folks to permit connections on that one TCP port through the firewall. If anybody has any ideas on this or how secure outgoing proxy FTP via router packet filters might be accomplished, I'd like to hear it. > There are several proxy services that work, and work to such a degree > that folks don't even think of them as proxy services; I'm talking > about things like SMTP, NNTP, NTP, and DNS. People _expect_ servers > running these protocols to proxy for other servers and clients (though > most of them don't do it synchronously). I'm not opposed to proxy > systems per se, just proxy systems for protocols that weren't designed > for such use, and for which appropriate clients aren't widely available. Most of the users I've worked with on my proxy FTP service felt that FTP was the only highly used remaining "popular" protocol that needed to be proxy-ized. BTW, I'm still testing, and am not quite ready for a widespread release of the software yet. It currently looks like a typical net software package (a shar containing a couple C files, Makefile, README, and man page). Installation is simply adding the pftp service to /etc/services, and adding the code to invoke it in /etc/inetd.conf. If any of you have issues with the potential ramifications of making Proxy FTP widely available, please let me know so I can factor that in. Please note that regular users will be able to compile and run this code themselves on a firewall and use it without needing any privs. I would like to apply for a "standardized" reserved TCP port number (<1024) for proxy FTP, but I don't know where to apply. Can somebody point me in the right direction? ...Marc... -- Marc Frajola, marc@escargot.rain.com | Work: Mentor Graphics, Inc. Phone: (503) 244-5499 [Portland, OR] (Home) | (503) 685-4817 From Firewalls-Owner@GreatCircle.COM Mon Oct 5 04:14:50 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09991; Mon, 5 Oct 92 04:14:50 PDT Received: from noc2.dccs.upenn.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09985; Mon, 5 Oct 92 04:14:45 PDT Received: from GYNKO.CIRC.UPENN.EDU by noc2.dccs.upenn.edu id AA29169; Mon, 5 Oct 92 07:14:31 -0400 Received: from aspen.circ.upenn.edu by gynko.circ.upenn.edu id AA13526; Mon, 5 Oct 92 07:15:47 EDT From: rsk@gynko.circ.upenn.edu (Richard Kulawiec) Posted-Date: Mon, 5 Oct 92 7:14:29 EDT Message-Id: <9210051115.AA13526@gynko.circ.upenn.edu> Subject: Re: your mail To: jbb@flare.cs.umb.edu (John B. Brown) Date: Mon, 5 Oct 92 7:14:29 EDT Cc: rsk@gynko.circ.upenn.edu, smb@ulysses.att.com, firewalls@GreatCircle.COM, mckillip@udel.edu In-Reply-To: <199210031908.AA01264@flare.cs.umb.edu>; from "John B. Brown" at Oct 3, 92 3:08 pm Organization: Cardiothoracic Imaging Research Center X-Queued-Mail: 1006 pending mail messages (1850697 characters) X-Last-River: Codorus X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM >I suppose the blatant hype from the sales department employees at Dec >hadn't already done that, or was that particular hype classified as >`technical details'? I didn't belong to the list when that traffic came across; I just joined a few days ago. ---Rsk From Firewalls-Owner@GreatCircle.COM Mon Oct 5 04:54:52 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10090; Mon, 5 Oct 92 04:54:52 PDT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10084; Mon, 5 Oct 92 04:54:14 PDT Received: from falafel.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA17444 (5.65b/HUJI 4.27 for firewalls@greatcircle.com); Mon, 5 Oct 92 13:53:37 +0200 Received: from localhost by falafel.cs.huji.ac.il with SMTP id AA05182 (5.65b/HUJI 4.14 for firewalls@greatcircle.com); Mon, 5 Oct 92 13:53:26 +0200 Message-Id: <9210051153.AA05182@falafel.cs.huji.ac.il> To: Marc Frajola Cc: firewalls@GreatCircle.COM Subject: Re: How to do proxy ftp? In-Reply-To: Your message of Mon, 05 Oct 92 02:19:13 PDT . From: Amos Shapira Date: Mon, 05 Oct 92 13:53:24 +0200 Sender: Firewalls-Owner@GreatCircle.COM In message you write: |> mfrost@shield.eng.pyramid.com (Mark Frost) writes: |> Finally, I've yet to have anybody ask for anything both reasonable and |> significant that can be done with a proxy telnet/ftp setup that can't |> be done with a carefully and properly constructed packet filtering |> setup. I'm sure that there _are_ examples, but in the several |> firewall systems I've built for clients in the last couple of years |> and the several more I'm currently building, the advantages of packet |> filtering have far outweighed the advantages of proxy services. | | The security people where I work have never had the least bit of |interest in allowing TCP connections from the outside world all the way |through the firewall to end-user nodes. Period. In our environment, |this completely rules out packet filtering on a router since (if I'm |not mistaken) FTP requires the server to make a TCP connection back on |a port that the FTP client determines dynamically. The only way I could |think of to make this work via a packet filter would be to somehow tell |the FTP client to have the server always connect back on a (single) |predetermined port, and get the networking folks to permit connections |on that one TCP port through the firewall. I have good news for you. The FTP protocol (RFC 959) specifies the PASV (passive) commands, which tells the FTP server to select a port on it's side and send the info about this port to the client. This, with a filtering which allows the "inside" hosts to connect to any port on an "outside" host, will let you do just the same without breaching(sp?) your security (at list in this point). Here is an excerpt from the RFC (from Page 28): ---------------------------------------------------------------------- PASSIVE (PASV) This command requests the server-DTP to "listen" on a data port (which is not its default data port) and to wait for a connection rather than initiate one upon receipt of a transfer command. The response to this command includes the host and port address this server is listening on. ---------------------------------------------------------------------- Hope this answers your doubts, unless I'm completly mistaken. Cheers, --Amos Shapira CS System Group, Hebrew University, Jerusalem, Israel amoss@cs.huji.ac.il From Firewalls-Owner@GreatCircle.COM Mon Oct 5 06:19:43 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10210; Mon, 5 Oct 92 06:19:43 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10204; Mon, 5 Oct 92 06:19:24 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA27924; Mon, 5 Oct 92 09:19:14 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA01335; Mon, 5 Oct 92 09:18:55 -0400 Date: Mon, 5 Oct 92 09:18:55 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210051318.AA01335@hussar.dco.dec.com> To: firewalls@GreatCircle.COM Subject: Re: How to do proxy ftp? Sender: Firewalls-Owner@GreatCircle.COM >Pardon my ignorance but how exactly does on to proxy ftp? If I understand >what it is correctly it allows one to do ftp "through" a host. (Please >correct me if I'm wrong). Somehow I haven't got the sense of what's >involved to set this up from the ftp man page. The DEC proxy FTP daemon (ftpxd) is a standalone program that understands the FTP protocol, and runs on a different port from the real ftpd. (typically 1555). When you connect to it, and send FTP commands, it examines them and then either forwards them to the remote machine, or rejects them. It's a pretty straightforward bit of code, except for the gookey bits where it handles the PORT command, and what happens when a user hits the interrupt key. Other stuff that ftpxd does is permits you to specify on a host:destination matching what operations are allowed. I can, for example, configure it so that my workstation can only put files out to ftp.uu.net, but can copy files in from anyplace. There's hooks for logging just about anything. When I wrote it, I considered just taking a copy of the existing ftpd and hammering away at it, but then I realized that if I did that, I would have to worry about any and all bugs in or problems with the existing ftpd. Here again, I believe that for security important software, it is important that the code to implement a service be as minimal as possible, to help ensure correctness and maintainability. There's some kind of hooks (it seems) in the ftpd for doing proxy stuff, but it looks half-completed, and undocumented, so I tend to doubt it works. mjr. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 06:38:29 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10235; Mon, 5 Oct 92 06:38:29 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10229; Mon, 5 Oct 92 06:38:08 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA28196; Mon, 5 Oct 92 09:38:19 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA01420; Mon, 5 Oct 92 09:38:00 -0400 Date: Mon, 5 Oct 92 09:38:00 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210051338.AA01420@hussar.dco.dec.com> To: firewalls@GreatCircle.COM Subject: Proxy FTP Sender: Firewalls-Owner@GreatCircle.COM >To do proxy FTP, you run a custom FTP client on your internal >machines. This custom client has been modified so that, no matter >where you tell it you want to connect to, it connects to your proxy >machine, and tells the proxy machine where you want to connect to. >The proxy machine then connects to the ultimate destination, and plays >pass-through on the data. This isn't the case with all proxy ftp servers. Mine doesn't require a modification of the client, as long as you have a reasonably decent client. The only requirement to make ftpxd work is that you need to be able to ftp to a specified port, *or* you have to run the ftp gateway on the standard ftpd port, which prevents you from serving ftp. Most decent ftp clients have no problem with this, but a few PC and Mac ones do. I've made a few mods to a version of the BSD ftp client, that make it do a handshake with the server if it's invoked as "gate-ftp" instead of "ftp". So if I'm at my desk and type: hussar-> gate-ftp ftp.uu.net it goes through the ftp gateway (using an environement variable) and connects me automatically to the remote machine. If I just invoke: hussar-> ftp localmachine it does the usual ftp thing. For folks who don't want to use the client (to tell the truth I usually don't bother), you just connect to the server: hussar-> ftp decuac 1555 Connected to decuac.dec.com. 220-FTP passthrough server (V1.0mjr) 220-To connect to a remote FTP server give your login as: 220-user@server.serverdomain (EG: anonymous@host.cs.mumble.edu) 220- 220-Prior to FTPing through the gateway, please conserve valuable network 220-bandwidth if possible by checking on gatekeeper.dec.com (DECWRL::) for 220-any publicly available FTP archives. 220- 220-If using Digital Pathways cryptokeys, authorize yourself by sending 220-"authorize " and respond to challenge using "response <##>" 220-If your FTP client doesn't support authorization, use 220-"quote authorize " and "quote response <##>" 220-If your connection is not authorized, you can still copy data inbound. 220- 220 Contact mjr@dco.dec.com for bug reports Name (decuac:mjr): anonymous@ftp.uu.net 331 Guest login ok, send e-mail address as password. Password: 230- 230- Welcome to the UUNET archive. 230- A service of UUNET Technologies Inc, Falls Church, Virginia 230- For information about UUNET, call +1 703 204 8000, or see the files 230- in /uunet-info Note where I told it my user name was "anonymous@ftp.uu.net" I have no idea why the folks who wrote other ftp proxies haven't thought of this approach, but that's not my problem. ;) I suppose we'll see them all doing it in the next release. ;) The glop in the message header about the Digital Pathways is because inside DEC (for data security reasons) we don't allow export of files from the company, *unless* we know exactly who did it and when. So I can pull files in to my heart's content, but I have to prove who I am to send them out: ftp> put .profile 200 PORT command successful. 530 Operation denied by FTP gateway ftp> A look at syslog shows the following: Oct 5 09:35:40 decuac.dec.com 28189 ftpxd: connected to remote server ftp.UU.NE T Oct 5 09:35:51 decuac.dec.com 28189 ftpxd: DENY urc.dco.dec.com STOR .profile Oct 5 09:36:11 decuac.dec.com 28189 ftpxd: server closed connection Oct 5 09:36:11 decuac.dec.com 28189 ftpxd: EXIT urc.dco.dec.com ftp.UU.NET recv =0 trans=0 cmds=7 Note, as part of the SEAL software/consulting offering, we include source as well as binaries to all programs, including the FTP gateway. mjr. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 07:00:21 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10313; Mon, 5 Oct 92 07:00:21 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10305; Mon, 5 Oct 92 07:00:03 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA28541; Mon, 5 Oct 92 10:00:13 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA01527; Mon, 5 Oct 92 09:59:54 -0400 Date: Mon, 5 Oct 92 09:59:54 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210051359.AA01527@hussar.dco.dec.com> To: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites Sender: Firewalls-Owner@GreatCircle.COM >One sticky issue is: what if I desire to hide the internal naming >structure of my network? I think this is a valid goal, given that >project information can sometimes be inferred simply by knowing what >the machines are named, and that any such handle you get is something >that "the bad guys" can for "social engineering" their way past an >unwitting receptionist or security staff. Usually, I like to take the approach that hiding host names is "security through obscurity" and as such should not be respected as improving your situation noticeably. There are just too many ways to get host information - I'd rather try to secure my network than hide it. Consider that many sendmails put Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); kind of crud in messages as they fly by. You need to strip all that out at the firewall, and soon you're finding yourself back in an "arms race". Another way of looking at it is to realize that concern about "social engineering" should be across the board. If you're afraid that I might find a hostname in your network and call your help desk and say "I forgot my password on 'mumble'" you also need to take into account the staff members who will ignorantly give out their address as "joe@mumble.bar.com" -- the information is GOING to leak out. Worry about how to secure mumble.bar.com and make sure that people don't name their machines "top-secret-project.bar.com" and you're better off. mjr. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 09:44:08 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10554; Mon, 5 Oct 92 09:44:08 PDT Received: from mail.Germany.EU.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10548; Mon, 5 Oct 92 09:43:52 PDT Received: from gate.muc.ibm.DE by mail.Germany.EU.net with SMTP (5.65c/EUnetD-2.2.0.i) via EUnet for greatcircle.com id AA18293; Mon, 5 Oct 1992 17:43:26 +0100 Received: by gate.muc.ibm.de; Mon, 5 Oct 92 17:59:20 +0100 Received: by g6150e; Mon, 5 Oct 92 17:37:24 +0100 Received: by barolo.ak.munich.ibm.com (AIX 3.2/UCB 5.64/4.03afx1.4) id AA14092; Mon, 5 Oct 1992 17:38:58 +0200 From: afx@muc.ibm.de (Andreas Siegert) Message-Id: <9210051538.AA14092@barolo.ak.munich.ibm.com> Subject: Filters and interfaces. To: Firewalls@GreatCircle.COM Date: Mon, 5 Oct 92 17:38:58 DFT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Darren Reed wrote: ... > To reduce both the size of filter rulesets as well as increasing > throughput of non-filtered traffic, it would seem better to be able > to setup a different filter rule set for each interface connected to > the host. Are there any working packet filters which are able to > operate in this way or does anyone know of any texts which discuss > this ? With this approach, you could more easily block packets from > outside which were trying to be internal hosts. Is't that the method the CISCO routers use? afx -- Andreas Siegert / Postmaster IBM Deutschland GmbH | Never grep a yacc AIX Field Support Center Pocci Strasse 11 | by the i-node! Internet: afx@ibm.de D-8000 Muenchen 2 | Opinions are my own, VNET: SIEGERT@MUNIVM4 Voice: (49)-(89)-7670-509 not IBM's. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 09:46:03 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10570; Mon, 5 Oct 92 09:46:03 PDT Received: from flare.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10564; Mon, 5 Oct 92 09:45:55 PDT Received: by flare.cs.umb.edu id AA01903 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 5 Oct 1992 12:46:11 -0400 Date: Mon, 5 Oct 1992 12:46:11 -0400 From: "John B. Brown" Message-Id: <199210051646.AA01903@flare.cs.umb.edu> To: smb@ulysses.att.com Subject: Re: your mail Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Dear Steve, Algorithms, code fragments, daemon dependencies, and such are what I consider as technical details. How Joe Blows' security code works on Joe Blows' boxes is sales hype. So far, the sales hype scores 99 44/100% and the technical details score 66/100%. Pure Ivory Snow. Shalom, JBB. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 09:58:35 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10636; Mon, 5 Oct 92 09:58:35 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10630; Mon, 5 Oct 92 09:58:31 PDT Message-Id: <9210051658.AA10630@mycroft.GreatCircle.COM> Received: by inet; Mon Oct 5 12:57 EDT 1992 From: smb@ulysses.att.com To: afx@muc.ibm.de (Andreas Siegert) Cc: Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. Date: Mon, 05 Oct 92 12:54:52 EDT Sender: Firewalls-Owner@GreatCircle.COM Darren Reed wrote: ... > To reduce both the size of filter rulesets as well as increasing > throughput of non-filtered traffic, it would seem better to be able > to setup a different filter rule set for each interface connected to > the host. Are there any working packet filters which are able to > operate in this way or does anyone know of any texts which discuss > this ? With this approach, you could more easily block packets from > outside which were trying to be internal hosts. Is't that the method the CISCO routers use? Cisco routers filter on output, not input, a serious disadvantage for security purposes. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 10:11:01 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10758; Mon, 5 Oct 92 10:11:01 PDT Received: from macsch.com (DRACO.MACSCH.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10752; Mon, 5 Oct 92 10:10:57 PDT Received: from [72.1.1.6] by macsch.com (5.61/SMI-4.1-07) id AA09304; Mon, 5 Oct 92 10:11:11 -0700 Received: from canismajor.is.macsch.com by convex.is.macsch.com (5.64/2.0) id AA00438; Mon, 5 Oct 92 10:09:43 -0700 Received: by canismajor.is.macsch.com (4.1/2.0) id AA16616; Mon, 5 Oct 92 10:10:55 PDT Date: Mon, 5 Oct 92 10:10:55 PDT From: todd@macsch.com (Todd Williams) Message-Id: <9210051710.AA16616@canismajor.is.macsch.com> To: firewalls@GreatCircle.COM Subject: Re: your mail Sender: Firewalls-Owner@GreatCircle.COM Hey! Please use appropriate Subject: lines! If there's anything more annoying than a mailing-list with high traffic, it's getting mail from it with "Re: your mail" in the header! From Firewalls-Owner@GreatCircle.COM Mon Oct 5 10:17:29 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10831; Mon, 5 Oct 92 10:17:29 PDT Received: from chaos.aoc.nrao.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10825; Mon, 5 Oct 92 10:17:24 PDT Received: by chaos.aoc.nrao.edu (4.1/1.3pmg) id AA06448; Mon, 5 Oct 92 11:17:23 MDT Message-Id: <9210051717.AA06448@chaos.aoc.nrao.edu> To: smb@ulysses.att.com Cc: pgreen@aoc.nrao.edu, Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. In-Reply-To: Your message of "Mon, 05 Oct 92 12:54:52 EDT." <9210051658.AA10630@mycroft.GreatCircle.COM> Date: Mon, 05 Oct 92 11:17:21 -0600 From: Phil Green Sender: Firewalls-Owner@GreatCircle.COM > Darren Reed wrote: > ... > > To reduce both the size of filter rulesets as well as increasing > > throughput of non-filtered traffic, it would seem better to be able > > to setup a different filter rule set for each interface connected to > > the host. Are there any working packet filters which are able to > > operate in this way or does anyone know of any texts which discuss > > this ? With this approach, you could more easily block packets from > > outside which were trying to be internal hosts. > > Is't that the method the CISCO routers use? > > Cisco routers filter on output, not input, a serious disadvantage for > security purposes. Why is filtering on output a serious disadvantage? Phil From Firewalls-Owner@GreatCircle.COM Mon Oct 5 10:22:22 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10872; Mon, 5 Oct 92 10:22:22 PDT Received: from leigh.s1.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10866; Mon, 5 Oct 92 10:22:17 PDT Received: from nightfall.s1.gov by leigh.s1.gov (4.1/TMD1.4) id AA08121; Mon, 5 Oct 92 10:22:31 PDT From: lkn@s1.gov (Leland K. Neely) Received: by nightfall.s1.gov (4.1/TMD1.4) id AA07475; Mon, 5 Oct 92 10:22:27 PDT Message-Id: <9210051722.AA07475@nightfall.s1.gov> Subject: Re: Filters and interfaces. To: smb@ulysses.att.com Date: Mon, 5 Oct 92 10:22:24 PDT Cc: afx@muc.ibm.de, Firewalls@GreatCircle.COM In-Reply-To: <9210051658.AA10630@mycroft.GreatCircle.COM>; from "smb@ulysses.att.com" at Oct 6, 92 12:54:52 pm X-Mailer: ELM [version 2.4dev PL32] Sender: Firewalls-Owner@GreatCircle.COM smb@ulysses.att.com writes: > > Darren Reed wrote: > ... > Is't that the method the CISCO routers use? > > Cisco routers filter on output, not input, a serious disadvantage for > security purposes. > Hang on- The cisco filters on output of each interface--- SO, you filter the output to the network you are protecting - no big deal. (The cisco still filters..) Lee Neely PS I could have swarn that you could filter in either direction... From Firewalls-Owner@GreatCircle.COM Mon Oct 5 10:24:08 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10886; Mon, 5 Oct 92 10:24:08 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10880; Mon, 5 Oct 92 10:24:02 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA01917; Mon, 5 Oct 92 13:24:06 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA02732; Mon, 5 Oct 92 13:23:43 -0400 Date: Mon, 5 Oct 92 13:23:43 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210051723.AA02732@hussar.dco.dec.com> To: firewalls@GreatCircle.COM Subject: Re: So what is vulnerable? A list.. Sender: Firewalls-Owner@GreatCircle.COM jbb@flare.Cs.umb.edu writes: > This space should be devoted to enlightenment, not >encouraging fear of the unknown. The problem is a technical one, >not attitudinal. Technical answers are what I welcome, not the >waving of dead chickens. Excuse me? I have a technical question: "I would like to jump off this building, will my knees be driven through the top of my head when I land, or not?" This can be answered simply in terms of a yes/no answer, but in real life, it's sometimes worth discussing the *question* rather than just replying with a "technical answer" in a vacuum. In the example above, someone might raise the issue of the existance of stairs or elevators in the context of my question abovE, and save me a lot of trouble and pain. I'm sorry if my response wasn't valuable. Certainly, even if my response was "waving dead chickens" it took more thought and effort to generate than the message I am replying to here. Perhaps if John Brown (jbb) has strong feelings about what kind of responses and discussion is "welcome" in this mailing list, we should re-open the question of whether commercial product blurbs should be blocked, as I originally suggested, and should discuss what constitutes an appropriate or contributory mail message. Certainly a mail message that says, in effect, "I don't like your answer and it is unwelcome" isn't a huge contribution, either. Sometimes just giving a flat answer to a question serves to obscure the problem. The only "correct" answer I know of to "which ports are 'safe'" is "none." That's a useless answer, so let's try to deal with the roots of the problem. At the very least, it is vendor dependent, and even (arguably) machine dependent. mjr. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 10:34:57 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10952; Mon, 5 Oct 92 10:34:57 PDT Received: from nadia.ircam.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10939; Mon, 5 Oct 92 10:34:03 PDT Received: from vaslav.ircam.fr by nadia.ircam.fr, Mon, 5 Oct 1992 18:32:33 +0100 Received: by vaslav.ircam.fr, Mon, 5 Oct 1992 18:32:33 +0100 Date: Mon, 5 Oct 1992 18:32:33 +0100 From: Michel Fingerhut Message-Id: <199210051732.AA12953@vaslav.ircam.fr> To: Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. Sender: Firewalls-Owner@GreatCircle.COM smb@ulysses.att.com writes: > Cisco routers filter on output, not input, a serious disadvantage for > security purposes. Yes, but since they filter on both interfaces, the internal and external ones, "filtering on input" on one interface is achieved by "filtering on output" on the other one. This is feasible and that's how we do it. From brent@GreatCircle.COM Mon Oct 5 11:00:53 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11143; Mon, 5 Oct 92 11:00:53 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11121; Mon, 5 Oct 92 11:00:34 PDT Message-Id: <9210051800.AA11121@mycroft.GreatCircle.COM> To: Marc Frajola Cc: firewalls@GreatCircle.COM Subject: Re: How to do proxy ftp? In-Reply-To: Your message of Mon, 05 Oct 92 02:19:13 PDT Reply-To: Brent@GreatCircle.COM Date: Mon, 05 Oct 92 11:00:33 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Marc Frajola writes: # While there are advantages to a custom FTP client, it's also an # option to run a proxy FTP server that will work with a standard FTP # client. In fact, after working within a firewalled environment for # several months, I finally got the hacking urge to do just that. After a # few months of testing, user feedback has been very positive. # # From the user's point of view, here's how it looks: # # $ ftp -n proxy_server proxy_port # # [FTP connects to the Proxy Server, which is sitting on a # different TCP port number than a regular FTP server. The FTP # client thinks it's talking to a real FTP server at this point, # but it's not. The -n is to tell it not to authenticate since # it's not talking to a real server yet.] # # ftp> quote open real.internet.host.domain There's the problem... You're assuming a "traditional" UNIX-style FTP client, where the FTP protocol is pretty much directly accessible to the user. What about Mac and PC GUI-based FTP clients, where the "quote" command is NOT easily accessible, or is a pain in the ass to use? I've seen a lot of those... -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Mon Oct 5 11:14:22 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11307; Mon, 5 Oct 92 11:14:22 PDT Received: from gatekeeper.es.dupont.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11301; Mon, 5 Oct 92 11:14:16 PDT Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991); id AA09586; Mon, 5 Oct 92 14:14:33 -0400 Received: by esds01.es.dupont.com (5.65/ULTRIX-mjr-063191); id AA22055; Mon, 5 Oct 92 14:11:15 -0400 Date: Mon, 5 Oct 92 14:11:15 -0400 Message-Id: <9210051811.AA22055@esds01.es.dupont.com> From: rogerskm@esvax.dnet.dupont.com To: "Firewalls@GreatCircle.COM"@ESDS01.dnet.dupont.com Subject: Commercial Product Request Sender: Firewalls-Owner@GreatCircle.COM We have had some unsuccessful attempts to connect to one of our machines on the Internet. I am interested in finding out what commercial products exist for improving the security of my network. My set up is a small with a handful of Unix workstations attached to the network. We want to allow restricted incoming traffic to the network. (For example, logins from the outside only permitted from specific locations) Thanks for your help. Karen Rogers Dupont Company rogerskm@esvax.dnet.dupont.com (302) 695-1423 From brent@GreatCircle.COM Mon Oct 5 11:17:10 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11330; Mon, 5 Oct 92 11:17:10 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11323; Mon, 5 Oct 92 11:17:07 PDT Message-Id: <9210051817.AA11323@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites In-Reply-To: Your message of Mon, 5 Oct 92 09:59:54 -0400 Reply-To: Brent@GreatCircle.COM Date: Mon, 05 Oct 92 11:17:06 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) writes: # Usually, I like to take the approach that hiding host names is # "security through obscurity" and as such should not be respected as # improving your situation noticeably. I agree that it's security through obscurity, and should not be counted on to protect anything, BUT every little bit helps. Why give folks ammunition, in the way of host names that can be used for "social engineering" or password attempts or anything else? Sure, not making the host names trivially available doesn't solve much, but it's one more piece of the puzzle. Now, all that said, only a couple of the firewalls I've worked on bother to do that. Most of my clients feel the way Marcus does about hiding host names: why bother? My point is, it's possible IF you think it's valuable, and some folks think it's valuable. # There are just too many ways to get host information - I'd # rather try to secure my network than hide it. I was definitely NOT suggesting hiding it rather than securing it. I was suggesting hiding it AFTER you've done your best to secure it; that gives you one more layer (perhaps trivial) that someone has to work their way through to get to you. I don't believe in absolute security; I don't believe that it's possible. I believe that it's a worthy _GOAL_, but I don't have any illusions that I'm going to actually ACHIEVE the goal. Therefore, I do every little thing I can to tighten up security on the firewall systems I build. Some are big things, like setting up packet filtering in the routers. Some are little things, like hiding internal host names. They all matter, to a greater or lesser degree. Hiding host names is way down on my list of what steps are important to take in securing a network, but it IS on the list. Some of my clients, for whatever reason, never get that far down the list, but some do. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Mon Oct 5 11:17:34 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11338; Mon, 5 Oct 92 11:17:34 PDT Received: from atlantic.nprdc.navy.mil by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11331; Mon, 5 Oct 92 11:17:27 PDT Received: from kara.nprdc.navy.mil by atlantic.nprdc.navy.mil (4.1/SMI-4.0) id AA13331; Mon, 5 Oct 92 11:17:15 PDT Received: by kara.nprdc.navy.mil (4.1/SMI-4.0) id AA09958; Mon, 5 Oct 92 11:17:16 PDT From: stanonik@nprdc.navy.mil (Ron Stanonik) Message-Id: <9210051817.AA09958@kara.nprdc.navy.mil> Date: 5 October 1992 1117-PDT (Monday) To: Firewalls@GreatCircle.COM Subject: : Re: Filters and interfaces. Reply-To: stanonik@nprdc.navy.mil Sender: Firewalls-Owner@GreatCircle.COM Regarding cisco's and whether you filter packets to your local network or packets to the outside, the former (as I misunderstand ciscos) would return icmp unreachable messages to folks outside. Sounds like good net citizenship? Is there no requirement in the RFCs for a gateway to return icmp unreachable messages? Ron Stanonik stanonik@nprdc.navy.mil From Firewalls-Owner@GreatCircle.COM Mon Oct 5 11:22:31 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11409; Mon, 5 Oct 92 11:22:31 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11403; Mon, 5 Oct 92 11:22:26 PDT Message-Id: <9210051822.AA11403@mycroft.GreatCircle.COM> Received: by inet; Mon Oct 5 14:22 EDT 1992 From: smb@ulysses.att.com To: lkn@s1.gov (Leland K. Neely) Cc: afx@muc.ibm.de, Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. Date: Mon, 05 Oct 92 14:21:57 EDT Sender: Firewalls-Owner@GreatCircle.COM Hang on- The cisco filters on output of each interface--- SO, you filter the output to the network you are protecting - no big deal. (The cisco still filters..) Lee Neely PS I could have swarn that you could filter in either direction... Nope, though the output filters can react to source or destination IP addresses (but only to destination port, not source port). Anyway, let me show what the problem is. Suppose I have two input nets, A and B, and an outside net X, all connected to one router. I want to allow full connectivity between A and B, but severely restrict what can come in from X. What do I do? The obvious answer, given output-only filtering, is to put a filter on A saying ``only B gets through'' (plus, perhaps, a gateway service reachable from X), and the complement on B. But an attacker at X can send in packets destined for A that purport to be from B. Sure, he or she may not get any output back, but there are still attacks possible. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 11:22:41 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11416; Mon, 5 Oct 92 11:22:41 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11410; Mon, 5 Oct 92 11:22:33 PDT Message-Id: <9210051822.AA11410@mycroft.GreatCircle.COM> Received: by inet; Mon Oct 5 14:22 EDT 1992 From: smb@ulysses.att.com To: Phil Green Cc: Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. Date: Mon, 05 Oct 92 14:14:42 EDT Sender: Firewalls-Owner@GreatCircle.COM Why is filtering on output a serious disadvantage? Because you've thrown away valuable information, to wit, the physical wire the packet arrived on. In most cases, you can hack around this if you're willing to dedicate a two-port router to your gateway, but it's often useful -- and more economical -- to use a single port on a multi-port router as your link to the outside. Note that I'm not just talking about the Internet! There are groups here at Bell Labs which have a strong (and in my opinion, justified) need to erect a firewall between themselves and the rest of the company, because what they do is so sensitive. If they have more than one LAN of their own, they'd be forced to buy a separate router just for the isolation. I should note that there are attacks possible where the attacker spoofs the IP address of a machine the target trusts. I described a number of such examples in my paper on TCP/IP security holes, a few years ago. --Steve Bellovin From Firewalls-Owner@GreatCircle.COM Mon Oct 5 11:23:58 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11454; Mon, 5 Oct 92 11:23:58 PDT Received: from leigh.s1.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11442; Mon, 5 Oct 92 11:23:50 PDT Received: from random.s1.gov by leigh.s1.gov (4.1/TMD1.4) id AA08206; Mon, 5 Oct 92 11:23:40 PDT From: tmd@s1.gov (Tina M. Darmohray) Received: by random.s1.gov (4.1/TMD1.4) id AA14081; Mon, 5 Oct 92 11:23:36 PDT Date: Mon, 5 Oct 92 11:23:36 PDT Message-Id: <9210051823.AA14081@random.s1.gov> To: marc@escargot.rain.com Subject: Re: How to do proxy ftp? Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM >Subject: Re: How to do proxy ftp? >From: Marc Frajola > > While I'm here, I have a point or two to add to Brent's reply... > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > >Then in <9210050316.AA09277@mycroft.GreatCircle.COM>, Brent Chapman replies: >> mfrost@shield.eng.pyramid.com (Mark Frost) writes: >> >> # Pardon my ignorance but how exactly does on to proxy ftp? If I understand >> # what it is correctly it allows one to do ftp "through" a host. (Please >> # correct me if I'm wrong). Somehow I haven't got the sense of what's >> # involved to set this up from the ftp man page. >> > >> Finally, I've yet to have anybody ask for anything both reasonable and >> significant that can be done with a proxy telnet/ftp setup that can't >> be done with a carefully and properly constructed packet filtering >> setup. I'm sure that there _are_ examples, but in the several >> firewall systems I've built for clients in the last couple of years >> and the several more I'm currently building, the advantages of packet >> filtering have far outweighed the advantages of proxy services. > > The security people where I work have never had the least bit of >interest in allowing TCP connections from the outside world all the way >through the firewall to end-user nodes. Period. In our environment, >this completely rules out packet filtering on a router since (if I'm >not mistaken) FTP requires the server to make a TCP connection back on >a port that the FTP client determines dynamically. The only way I could >think of to make this work via a packet filter would be to somehow tell >the FTP client to have the server always connect back on a (single) >predetermined port, and get the networking folks to permit connections >on that one TCP port through the firewall. > > If anybody has any ideas on this or how secure outgoing proxy FTP >via router packet filters might be accomplished, I'd like to hear it. > I'm also interested in how to secure outgoing FTP using router packet filters. Is the router doing packet filtering on all packets except those that provide the functionality that the site wants (and therefore has decided that it is willing to live with as a "necessary potential security problem")? __________ __________ <-- ftp --> router <-- ftp --> clients __________ __________ Or, is there a dual-hop for the users involved? They login to the bastion host, ftp, and then ftp again back to the local machine? __________ ____________ __________ <-- ftp --> router <-- ftp --> bastion host <-- ftp --> clients __________ ____________ __________ Or are their 2 routers involved? __________ ____________ ______ _______ <-- ftp --> router <--> bastion host <--> router <---> clients __________ ____________ ______ _______ Tina tmd@s1.gov From brent@GreatCircle.COM Mon Oct 5 11:33:05 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11502; Mon, 5 Oct 92 11:33:05 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11494; Mon, 5 Oct 92 11:33:01 PDT Message-Id: <9210051833.AA11494@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. In-Reply-To: Your message of Mon, 5 Oct 92 17:38:58 DFT Reply-To: Brent@GreatCircle.COM Date: Mon, 05 Oct 92 11:33:00 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM afx@muc.ibm.de (Andreas Siegert) writes: # Darren Reed wrote: # ... # > To reduce both the size of filter rulesets as well as increasing # > throughput of non-filtered traffic, it would seem better to be able # > to setup a different filter rule set for each interface connected to # > the host. Are there any working packet filters which are able to # > operate in this way or does anyone know of any texts which discuss # > this ? With this approach, you could more easily block packets from # > outside which were trying to be internal hosts. # # Is't that the method the CISCO routers use? Well, sort of. Cisco routers let you specify a different filter set for each interface, but the filters only apply to packets going out on that interface (not packets coming in on that interface). Thus, if you have a 2-interface Cisco between your internal net (say 123.45.x.y) and your exposed net (which needs to have a different number for reasons that will become apparent momentarily; say 192.9.200.y), you can set up filters on the 123.45 (internal) interface that say in effect "if source address is 123.45.*.*, reject the packet, because it must be bogus". If you've got multiple interfaces on this Cisco tied to different parts of the 123.45.*.* network (either because your external subnet also uses a 123.45.*.* network number, or because you have a Cisco with more than 2 interfaces that connects various pieces of your internal net to each other, as well as to your external net), this won't work; the rule above would keep valid internal-to-internal or gateway-to-internal traffic from being routed. If you've got a router (such as a Telebit NetBlazer, or others) that allows you to specify filters on inbound packets on an interface, you can simply block these bogus packets (packets whose headers say they come from an internal machine, but in fact come from the outside world) with an inbound rule on the interface to the outside world. My packet filtering paper (available for anonymous FTP from FTP.GreatCircle.COM; file "pub/pkt_filtering.ps.Z"; aren't you guys tired of hearing about this yet? :-) talks about this and other packet filtering issues. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Mon Oct 5 11:35:44 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11538; Mon, 5 Oct 92 11:35:44 PDT Received: from ash.cisco.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11532; Mon, 5 Oct 92 11:35:40 PDT Received: by ash.cisco.com; Mon, 5 Oct 92 11:35:20 -0700 From: Roland Acra Message-Id: <9210051835.AA23803@ash.cisco.com> Subject: Re: Filters and interfaces. To: afx@muc.ibm.de (Andreas Siegert) Date: Mon, 5 Oct 92 11:35:20 MDT Cc: Firewalls@GreatCircle.COM In-Reply-To: <9210051538.AA14092@barolo.ak.munich.ibm.com>; from "Andreas Siegert" at Oct 5, 92 5:38 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Yes, indeed. Filters on Cisco routers are interface-specific. A collection of filtering statements is defined as an "access-list", which can then be applied to one or more interfaces. Distinct interfaces on a given router can be configured with distinct access lists. Note that these access lists affect outgoing (as opposed to incoming) traffic on the interfaces they are applied upon. Roland Acra Cisco Systems Europe acra@cisco.com > > Darren Reed wrote: > ... > > To reduce both the size of filter rulesets as well as increasing > > throughput of non-filtered traffic, it would seem better to be able > > to setup a different filter rule set for each interface connected to > > the host. Are there any working packet filters which are able to > > operate in this way or does anyone know of any texts which discuss > > this ? With this approach, you could more easily block packets from > > outside which were trying to be internal hosts. > > Is't that the method the CISCO routers use? > > afx > -- > Andreas Siegert / Postmaster IBM Deutschland GmbH | Never grep a yacc > AIX Field Support Center Pocci Strasse 11 | by the i-node! > Internet: afx@ibm.de D-8000 Muenchen 2 | Opinions are my own, > VNET: SIEGERT@MUNIVM4 Voice: (49)-(89)-7670-509 not IBM's. > From brent@GreatCircle.COM Mon Oct 5 11:40:45 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11634; Mon, 5 Oct 92 11:40:45 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11626; Mon, 5 Oct 92 11:40:42 PDT Message-Id: <9210051840.AA11626@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. In-Reply-To: Your message of Mon, 05 Oct 92 11:17:21 -0600 Reply-To: Brent@GreatCircle.COM Date: Mon, 05 Oct 92 11:40:41 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Phil Green writes: # > Cisco routers filter on output, not input, a serious disadvantage for # > security purposes. # # Why is filtering on output a serious disadvantage? I don't think Steve was clear: filtering on output is not a serious disadvantage. Filtering ONLY on output, and not also on input, is a serious disadvantage. If you can't filter on input, you can't protect your router with your packet filtering; the router is totally exposed (for whatever that's worth). On a router with more than 2 interfaces, it's much easier to filter some things on 1 input interface, than on (n - 1) output interfaces. Depending on the configuration of your network, it might not even be possible to do equivalent filtering on the output interfaces (see my last message concerning faked internal host addresses for an example). -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From brent@GreatCircle.COM Mon Oct 5 11:43:47 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11669; Mon, 5 Oct 92 11:43:47 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11661; Mon, 5 Oct 92 11:43:44 PDT Message-Id: <9210051843.AA11661@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. In-Reply-To: Your message of Mon, 5 Oct 1992 18:32:33 +0100 Reply-To: Brent@GreatCircle.COM Date: Mon, 05 Oct 92 11:43:43 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Michel Fingerhut writes: # smb@ulysses.att.com writes: # # > Cisco routers filter on output, not input, a serious disadvantage for # > security purposes. # # Yes, but since they filter on both interfaces, the internal and # external ones, "filtering on input" on one interface is achieved # by "filtering on output" on the other one. This is feasible and # that's how we do it. No, they are equivalent ONLY if your Cisco has ONLY two interfaces. And even then, they aren't equivalent; if your router can only filter outgoing packets, you can't make the router appear to be "behind" the packet filtering fence, and must leave it exposed to the outside world. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Mon Oct 5 12:04:40 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11931; Mon, 5 Oct 92 12:04:40 PDT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11924; Mon, 5 Oct 92 12:04:27 PDT Received: from falafel.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA19635 (5.65b/HUJI 4.27 for firewalls@greatcircle.com); Mon, 5 Oct 92 21:05:40 +0200 Received: from localhost by falafel.cs.huji.ac.il with SMTP id AA06345 (5.65b/HUJI 4.14 for firewalls@greatcircle.com); Mon, 5 Oct 92 21:05:28 +0200 Message-Id: <9210051905.AA06345@falafel.cs.huji.ac.il> To: stanonik@nprdc.navy.mil Cc: firewalls@GreatCircle.COM Subject: Re: : Re: Filters and interfaces. In-Reply-To: Your message of 5 October 1992 1117-PDT (Monday) . <9210051817.AA09958@kara.nprdc.navy.mil> From: Amos Shapira Date: Mon, 05 Oct 92 21:05:25 +0200 Sender: Firewalls-Owner@GreatCircle.COM In message <9210051817.AA09958@kara.nprdc.navy.mil> you write: |Regarding cisco's and whether you filter packets to your local network |or packets to the outside, the former (as I misunderstand ciscos) would |return icmp unreachable messages to folks outside. Sounds like good net |citizenship? Is there no requirement in the RFCs for a gateway to return |icmp unreachable messages? >From my experience and answers by people from Cisco, the router will keep sending ICMP unreachable only if you disable some caching, a big performance hit. So I guess this is not the issue (i.e. it won't send ICMP unreachable most of the time anyway, and I don't know anyone who's going to hit his performance severly (something like 10-20% if I remember right) in order to be a good citizen in relatively rare cases). Cheers, --Amos Shapira CS System Group, Hebrew University, Jerusalem, Israel amoss@cs.huji.ac.il From Firewalls-Owner@GreatCircle.COM Mon Oct 5 12:13:18 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12030; Mon, 5 Oct 92 12:13:18 PDT Received: from flare.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12024; Mon, 5 Oct 92 12:13:13 PDT Received: by flare.cs.umb.edu id AA02018 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 5 Oct 1992 15:13:29 -0400 Date: Mon, 5 Oct 1992 15:13:29 -0400 From: "John B. Brown" Message-Id: <199210051913.AA02018@flare.cs.umb.edu> To: firewalls@GreatCircle.COM, mjr@decuac.DEC.COM Subject: Re: Sales Hype and Defenestrated Dead Chickens Sender: Firewalls-Owner@GreatCircle.COM Dear Marcus: You write: Date: Mon, 5 Oct 92 13:23:43 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) I have a technical question: "I would like to jump off this building, will my knees be driven through the top of my head when I land, or not?" ============================================================== Seems your favorite subject is dead chickens. Why not elaborate the algorithms of the ftp server code you wrote, rather than flogging fears and offering SEAL as the ideal adjunct to your solution? Shalom, JBB. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 12:16:45 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12047; Mon, 5 Oct 92 12:16:45 PDT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12040; Mon, 5 Oct 92 12:16:27 PDT Received: from falafel.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA19701 (5.65b/HUJI 4.27 for firewalls@greatcircle.com); Mon, 5 Oct 92 21:17:39 +0200 Received: from localhost by falafel.cs.huji.ac.il with SMTP id AA06365 (5.65b/HUJI 4.14 for firewalls@greatcircle.com); Mon, 5 Oct 92 21:17:27 +0200 Message-Id: <9210051917.AA06365@falafel.cs.huji.ac.il> To: Michel Fingerhut Cc: firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. In-Reply-To: Your message of Mon, 5 Oct 1992 18:32:33 +0100 . <199210051732.AA12953@vaslav.ircam.fr> From: Amos Shapira Date: Mon, 05 Oct 92 21:17:17 +0200 Sender: Firewalls-Owner@GreatCircle.COM In message <199210051732.AA12953@vaslav.ircam.fr> you write: |smb@ulysses.att.com writes: | |> Cisco routers filter on output, not input, a serious disadvantage for |> security purposes. | |Yes, but since they filter on both interfaces, the internal and |external ones, "filtering on input" on one interface is achieved |by "filtering on output" on the other one. This is feasible and |that's how we do it. You clame you are using it so I guess you can testify about this: Wouldn't it be easier for you in some cases to filter packets at one concentrated point on arrival rather than checking for them separatly on each and every interface before sending them away? Not only the configuration might be simpler but also I think you gain some performance since the router won't waste cycles deciding about a route for a packet it's going to discard anyway. Brad Chapman describes in his (excellant, IMO) paper about the advantages of packet filtering how this could help. There must be better places to fetch it from but if you want a copy is available on ftp.huji.ac.il directory pub/doc/firewalls file pkt_filtering.ps.Z (this site is in Israel, so please!) To give you a specific example: our net is 132.65.x.x and we have a Cisco as a gateway. It's Ethernet Interface 2 is the fiber link to outside. Any packet coming on this link claiming to be originating from 132.65.x.x is certainly false, if I could check this on Interface 2 then I don't need to check for this on the other interfaces, get the idea? Of course you can say this is a little gain but I guess people can come up with more convincing examples. Chirio --Amos Shapira CS System Group, Hebrew University, Jerusalem, Israel amoss@cs.huji.ac.il From Firewalls-Owner@GreatCircle.COM Mon Oct 5 12:25:27 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12107; Mon, 5 Oct 92 12:25:27 PDT Received: from alpha.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12100; Mon, 5 Oct 92 12:25:22 PDT Received: from sentinel.CES.CWRU.Edu by alpha.CES.CWRU.Edu with SMTP (5.64+/ane.07.08.91.01) id AA13982; Mon, 5 Oct 92 15:25:34 -0400 From: Aydin Edguer Message-Id: <9210051925.AA13982@alpha.CES.CWRU.Edu> Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites To: Brent@GreatCircle.COM Date: Mon, 5 Oct 92 15:21:22 EDT In-Reply-To: <9210051817.AA11323@mycroft.GreatCircle.COM>; from "Brent Chapman" at Oct 5, 92 11:17 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM > I agree that it's security through obscurity, and should not be > counted on to protect anything, BUT every little bit helps. Why give > folks ammunition, in the way of host names that can be used for > "social engineering" or password attempts or anything else? Sure, > not making the host names trivially available doesn't solve much, but > it's one more piece of the puzzle. But the point is that if "I" am trying to break into "your" hosts, then "I" don't really care about the hostname, all "I" need is the IP address. Unless you are going to hide your IP addresses, then hiding the hostnames seems rather pointless (except for mail). If you do hide IP addresses then I fully agree that hiding your hostnames is important and useful. The point of doing a "double reverse" name lookup is security/authentication. It helps to prevent spoofing of the nameserver by people forging PTR records in their nameservers. Thus I think that a "double reverse" name lookup is under normal usage [with or without firewall] going to help cut down on "forgeries" more than hiding only the names is going to help. Aydin Edguer From Firewalls-Owner@GreatCircle.COM Mon Oct 5 12:27:12 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12174; Mon, 5 Oct 92 12:27:12 PDT Received: from flare.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12168; Mon, 5 Oct 92 12:27:00 PDT Received: by flare.cs.umb.edu id AA02028 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Mon, 5 Oct 1992 15:27:02 -0400 Date: Mon, 5 Oct 1992 15:27:02 -0400 From: "John B. Brown" Message-Id: <199210051927.AA02028@flare.cs.umb.edu> To: Firewalls@GreatCircle.COM, Michel.Fingerhut@ircam.fr Subject: Re: Filters and interfaces on Cisco boxes. Sender: Firewalls-Owner@GreatCircle.COM Dear Michel, Thank you for that illuminating note that Cisco boxes filter both interfaces. >Date: Mon, 5 Oct 1992 18:32:33 +0100 >From: Michel Fingerhut >smb@ulysses.att.com writes: >> Cisco routers filter on output, not input, a serious disadvantage for >> security purposes. >Yes, but since they filter on both interfaces, the internal and >external ones, "filtering on input" on one interface is achieved >by "filtering on output" on the other one. This is feasible and >that's how we do it. It's very helpful to realize a piece of equipment we use for terminal access can help us protect the rest of the internet from experimenting students inside our domain. Shalom, JBB. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 12:51:44 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12251; Mon, 5 Oct 92 12:51:44 PDT Received: from relay.nswc.navy.mil by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12245; Mon, 5 Oct 92 12:51:39 PDT Received: from galaxy.nswc.navy.mil by relay.nswc.navy.mil (4.1/SMI-4.1) id AA11587; Mon, 5 Oct 92 15:47:28 EDT Received: by galaxy.nswc.navy.mil (4.1/SMI-4.1) id AA03002; Mon, 5 Oct 92 15:51:51 EDT Date: Mon, 5 Oct 92 15:51:51 EDT From: rhott%galaxy@relay.nswc.navy.mil (Bob Hott - K31) Message-Id: <9210051951.AA03002@galaxy.nswc.navy.mil> To: Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. Sender: Firewalls-Owner@GreatCircle.COM smb@ulysses.att.com writes: > Cisco routers filter on output, not input, a serious disadvantage for > security purposes. I agree with the above comment, to some extent. I don't think I would say that Cisco's filtering only on output is a serious disadvantage, but it can present the opportunity for some more difficult filtering. When the router only has two interfaces, so what.... But when the number of interfaces increase, the limitation to only out going interfaces can make for much more difficult (and lengthy filters) than if the routers could filter for incoming and outgoing packets. That said, it is a router being used to do other functions, and I, personally, am glad that they can do as much as they can do. I do remember the previous generation of routers, and they we much less capable. Bob Hott ====================== #include ========================= Bob Hott, NSWCDD, Networks Branch (Code K41) |"If man were not meant to play Dahlgren, Virginia 22448 (703) 663 - 8305 | volleyball, why are there so rhott@relay.nswc.navy.mil | many beaches?" - Bob Hott - From Firewalls-Owner@GreatCircle.COM Mon Oct 5 12:58:20 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12275; Mon, 5 Oct 92 12:58:20 PDT Received: from linus.mitre.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12269; Mon, 5 Oct 92 12:58:14 PDT Received: from bede.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA06836; Mon, 5 Oct 92 15:58:29 -0400 Posted-Date: Mon, 5 Oct 92 15:58:27 -0400 Received: by bede.mitre.org (5.61/RCF-4C) id AA17893; Mon, 5 Oct 92 15:58:27 -0400 Date: Mon, 5 Oct 92 15:58:27 -0400 From: bede@linus.mitre.org Message-Id: <9210051958.AA17893@bede.mitre.org> To: Firewalls@GreatCircle.COM In-Reply-To: Ron Stanonik's message of 5 October 1992 1117-PDT (Monday) <9210051817.AA09958@kara.nprdc.navy.mil> Subject: RE: Filters and interfaces. Sender: Firewalls-Owner@GreatCircle.COM From: stanonik@nprdc.navy.mil (Ron Stanonik) Date: 5 October 1992 1117-PDT (Monday) Regarding cisco's and whether you filter packets to your local network or packets to the outside, the former (as I misunderstand ciscos) would return icmp unreachable messages to folks outside. Sounds like good net citizenship? Is there no requirement in the RFCs for a gateway to return icmp unreachable messages? Ron Stanonik stanonik@nprdc.navy.mil On Ciscos, I believe you can switch off the "ICMP x Unreachable" replies if they become a problem. For example, there used to be (still are?) OS implementations which, when an Unreachable message was returned for a given destination, would forcibly terminate *all* existing local connections to that destination. Under normal circumstances, this is a reasonable tactic, but when there is filtering going on, the Unreachable may have been returned for a blocked protocol (e.g. NNTP) while the other existing connection(s) were for unblocked protocol(s) to/from the same firewall host. A cursory look at RFC 1009 indicates there is no *requirement* that gateways return an ICMP x Unreachable in the case at hand. In any case, both the network and the host are reachable --- just not for all applications. There is no ICMP message defined specifically for this case, although there is always the catch-all Parameter Problem message. -Bede McCall MITRE Corp, Bedford. MA From Firewalls-Owner@GreatCircle.COM Mon Oct 5 13:28:52 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12437; Mon, 5 Oct 92 13:28:52 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12431; Mon, 5 Oct 92 13:28:47 PDT Message-Id: <9210052028.AA12431@mycroft.GreatCircle.COM> Received: by inet; Mon Oct 5 16:28 EDT 1992 From: smb@ulysses.att.com To: bede@linus.mitre.org Cc: Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. Date: Mon, 05 Oct 92 16:28:33 EDT Sender: Firewalls-Owner@GreatCircle.COM A cursory look at RFC 1009 indicates there is no *requirement* that gateways return an ICMP x Unreachable in the case at hand. In any case, both the network and the host are reachable --- just not for all applications. There is no ICMP message defined specifically for this case, although there is always the catch-all Parameter Problem message. 1009 is fairly out of date; I should check the drafts directories for a new router requirements document. Anyway, the right code is Destination Unreachable, code 10. That value is defined by RFC1122 for ``administratively prohibited''. Unfortunately, 4.3bsd, and likely many of its descendants, will ignore any ICMP message with a code value they consider invalid. Thus, Cisco routers send back ``host unreachable''. --Steve Bellovin From brent@GreatCircle.COM Mon Oct 5 14:07:40 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12858; Mon, 5 Oct 92 14:07:40 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12850; Mon, 5 Oct 92 14:07:37 PDT Message-Id: <9210052107.AA12850@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. In-Reply-To: Your message of Mon, 05 Oct 92 21:17:17 +0200 Reply-To: Brent@GreatCircle.COM Date: Mon, 05 Oct 92 14:07:36 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM # Brad Chapman describes in his (excellant, IMO) paper about the advantages # of packet filtering how this could help. There must be better places to # fetch it from but if you want a copy is available on ftp.huji.ac.il directory # pub/doc/firewalls file pkt_filtering.ps.Z (this site is in Israel, so please!) It's also available for anonymous ftp from FTP.GreatCircle.COM, file "pub/pkt_filtering.ps.Z". It was published in the Proceedings of the Third UNIX Security Symposium, co-sponsored by CERT and USENIX last month in Baltimore, MD. By the way, Brad Chapman is an uncle of mine who raises cattle in Arizona; I'm sure he'd be greatly amused to learn he's now writing papers on network security as well... :-) I'm glad you liked the paper, though; it was a bitch to write. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From brent@GreatCircle.COM Mon Oct 5 14:15:45 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12995; Mon, 5 Oct 92 14:15:45 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12986; Mon, 5 Oct 92 14:15:42 PDT Message-Id: <9210052115.AA12986@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites Reply-To: Brent@GreatCircle.COM Date: Mon, 05 Oct 92 14:15:40 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Aydin Edguer writes: # > I agree that it's security through obscurity, and should not be # > counted on to protect anything, BUT every little bit helps. Why give # > folks ammunition, in the way of host names that can be used for # > "social engineering" or password attempts or anything else? Sure, # > not making the host names trivially available doesn't solve much, but # > it's one more piece of the puzzle. # # But the point is that if "I" am trying to break into "your" hosts, then # "I" don't really care about the hostname, all "I" need is the IP address. # Unless you are going to hide your IP addresses, then hiding the hostnames # seems rather pointless (except for mail). If you do hide IP addresses then # I fully agree that hiding your hostnames is important and useful. Some people (including some but not most of my clients) consider host names to be useful information in and of themselves, regardless of what IP address the host maps to. The host names might give outsiders a clue about projects inside the company, they give outsiders more ammunition for their password cracking programs, and they let outsiders appear to be knowledgable about the site if they try to engage in social engineering to get past human security measures (i.e., if somebody who looks like a repair tech shows up at your receptionist's desk and says "I'm here to work on and it's an emergency; they're waiting for me in the machine room", what's your receptionist going to do? # The point of doing a "double reverse" name lookup is security/authentication. # It helps to prevent spoofing of the nameserver by people forging PTR records # in their nameservers. Thus I think that a "double reverse" name lookup is # under normal usage [with or without firewall] going to help cut down on # "forgeries" more than hiding only the names is going to help. I don't think knowing the name that goes with an IP address really tells you any more than the IP address itself, which you've got regardless. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Mon Oct 5 14:40:40 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13305; Mon, 5 Oct 92 14:40:40 PDT Received: from alpha.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13275; Mon, 5 Oct 92 14:40:20 PDT Received: from sentinel.CES.CWRU.Edu by alpha.CES.CWRU.Edu with SMTP (5.64+/ane.07.08.91.01) id AA14553; Mon, 5 Oct 92 17:40:22 -0400 From: Aydin Edguer Message-Id: <9210052140.AA14553@alpha.CES.CWRU.Edu> Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites To: Firewalls@GreatCircle.COM Date: Mon, 5 Oct 92 17:40:13 EDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM > (i.e., if somebody who looks like a repair tech shows up at your > receptionist's desk and says "I'm here to work on machine name> and it's an emergency; they're waiting for me in the > machine room", what's your receptionist going to do? [your examples of why to protect hostnames are very good. I guess I would just want to point out that even with no hostnames, you are still at risk from similar attacks] Well, I realize that the "right" answer is not always the "practical" or "realistic" answer but IMHO the receptionist better call in first... or else. First, because the repair tech will not be able to get through the security stops within the building without an escort and secondly because they will not be able to get into the machine room without the presence of a staff member. If physical security is any more lax then hostnames are not going to save you once the intruder gets physical access to one machine. At one company where I consult, you do not get in without an employee accompanying you. Period. Unless you are the fire department and in that case security is already on the scene. Furthermore, how many receptionists really know the names and locations of all computers in the company? If they really do know the names and locations, does the gateway hostname change internally? If not, then the intruder can just use the gateway hostname to get in. > # It helps to prevent spoofing of the nameserver by people forging PTR records > # in their nameservers. Thus I think that a "double reverse" name lookup is > # under normal usage [with or without firewall] going to help cut down on > # "forgeries" more than hiding only the names is going to help. > > I don't think knowing the name that goes with an IP address really > tells you any more than the IP address itself, which you've got regardless. Well, when tracking things down _after_ the fact, you are correct. But for screening I disagree. Many sites are now using FQDN's for configuration purposes to help prevent problems when machines are changed [e.g. contact SMTP.do.main or NNTP.do.main]. Without verifying the PTR lookup with a further A lookup, the PTR lookup can take place on a remote [cracked] system and return a valid FQDN, that will not be detected until much later. Aydin Edguer From Firewalls-Owner@GreatCircle.COM Mon Oct 5 15:35:17 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13773; Mon, 5 Oct 92 15:35:17 PDT Received: from ra.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13767; Mon, 5 Oct 92 15:35:12 PDT Received: by ra.cs.umb.edu id AA09931 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Mon, 5 Oct 1992 18:35:20 -0400 From: "John P. Rouillard" Message-Id: <199210052235.AA09931@ra.cs.umb.edu> Subject: RE: Filters and interfaces. To: bede@linus.mitre.org Date: Mon, 5 Oct 92 18:35:19 EDT Cc: Firewalls@GreatCircle.COM In-Reply-To: <9210051958.AA17893@bede.mitre.org>; from "bede@linus.mitre.org" at Oct 5, 92 3:58 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM bede@linus.mitre.org writes: > On Ciscos, I believe you can switch off the "ICMP x Unreachable" replies > if they become a problem. For example, there used to be (still are?) > OS implementations which, when an Unreachable message was returned for > a given destination, would forcibly terminate *all* existing local > connections to that destination. Still are. Ultsux/Bugtrix/Ultrix 4.2, or 4.1 for example. Three weeks later, DEC still hasn't escalated the problem beyond the local office. I would figure this was a bug fixed by a patch already existant, but noo. OB firewalls warning: So all of you people with Ultrix boxes out there, look out if you run against sites with firewalls, or if you use the rfc931 feature of the wuarchive ftp server. There may be people who can't and never will be able to get through to you for ftp or telnet service. This same warning applies to using the log_tcp daemons with rfc931 enabled on these buggy machines 8-(. Sigh some useful software rendered less potent because of an old kernel bug. Does anybody else know what other boxes I should avoid that exhibit this bug? I know SunOS 4.1.1 doesn't since I moved my services to that box. -- John From Firewalls-Owner@GreatCircle.COM Mon Oct 5 15:44:00 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13835; Mon, 5 Oct 92 15:44:00 PDT Received: from rain.psg.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13829; Mon, 5 Oct 92 15:43:56 PDT Received: by rain.psg.com (/\==/\ Smail3.1.25.1 #25.2) id ; Mon, 5 Oct 92 15:43 PDT Message-Id: From: randy@psg.com (Randy Bush) Subject: RE: Filters and interfaces. To: bede@linus.mitre.org Date: Mon, 5 Oct 92 15:43:57 PDT Cc: Firewalls@GreatCircle.COM In-Reply-To: <9210051958.AA17893@bede.mitre.org>; from "bede@linus.mitre.org" at Oct 5, 92 3:58 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM > On Ciscos, I believe you can switch off the "ICMP x Unreachable" replies > if they become a problem. For example, there used to be (still are?) > OS implementations which, when an Unreachable message was returned for > a given destination, would forcibly terminate *all* existing local > connections to that destination. Under normal circumstances, this is > a reasonable tactic, but when there is filtering going on, the > Unreachable may have been returned for a blocked protocol (e.g. NNTP) > while the other existing connection(s) were for unblocked protocol(s) > to/from the same firewall host. This hit folk with log_tcp trying to use TAP's authd. Firewalls would send unreachable to the authd request, and Net/1 based releases would then drop the telnet session. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 15:45:49 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13851; Mon, 5 Oct 92 15:45:49 PDT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13845; Mon, 5 Oct 92 15:45:44 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27755; Mon, 5 Oct 92 18:46:08 -0400 Message-Id: <9210052246.AA27755@relay2.UU.NET> Received: from msdrl.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 184413.5509; Mon, 5 Oct 1992 18:44:13 EDT From: msdrl!ajs@uunet.UU.NET (Anthony Starks) Subject: Quality of Wellfleet IP filtering To: uunet!greatcircle.com!firewalls@uunet.UU.NET (Firewalls mailing list) Date: Mon, 5 Oct 92 18:34:22 EDT X-Mailer: ELM [version 2.2 PL0] Sender: Firewalls-Owner@GreatCircle.COM Anyone care to comment on the quality of the IP filtering available on Wellfleets? Comparisons to Ciscos and NetBlazers, et. al are fine. I'm looking for: * ease of configuration * Types of filtering offered * How well Wellfleets stack up in the light of the issues raised in Brent Chapman's paper, namely: -- filter syntax -- Available header fields -- Inbound and Outbound filtering -- Testing tools -- Anthony Starks Merck Research Laboratories ajs@msdrl.com From Firewalls-Owner@GreatCircle.COM Mon Oct 5 16:56:04 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14239; Mon, 5 Oct 92 16:56:04 PDT Received: from flare.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14233; Mon, 5 Oct 92 16:56:00 PDT Received: by flare.cs.umb.edu id AA02352 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Mon, 5 Oct 1992 19:56:15 -0400 Date: Mon, 5 Oct 1992 19:56:15 -0400 From: "John B. Brown" Message-Id: <199210052356.AA02352@flare.cs.umb.edu> To: Firewalls@GreatCircle.COM, edguer@alpha.CES.CWRU.Edu Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites Sender: Firewalls-Owner@GreatCircle.COM Dear Folks, There are some interesting papers of a generally helpful content residing on research.att.com in the ftp directory dist/internet_security. Possibly Steve was to shy to mention them. Shalom, JBB. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 17:24:26 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14430; Mon, 5 Oct 92 17:24:26 PDT Received: from sgi.sgi.com (SGI.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14424; Mon, 5 Oct 92 17:24:21 PDT Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for Firewalls@GreatCircle.COM id AA17802; Mon, 5 Oct 92 17:23:56 -0700 Received: from yeager.corp.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:smb@ulysses.att.com id AA23492; Mon, 5 Oct 92 16:46:05 -0700 Received: by yeager.corp.sgi.com (920330.SGI/911001.SGI) for @sgi.com:Firewalls@GreatCircle.COM id AA03693; Mon, 5 Oct 92 16:46:04 -0700 Date: Mon, 5 Oct 92 16:46:04 PDT From: Eliot Lear To: smb@ulysses.att.com Cc: lkn@s1.gov (Leland K. Neely), afx@muc.ibm.de, Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. In-Reply-To: Your message of Mon, 05 Oct 92 14:21:57 EDT Message-Id: Sender: Firewalls-Owner@GreatCircle.COM You can turn off source routing in Ciscos. Not a good thing, but it helps in certain instances... Eliot Lear [lear@sgi.com] From Firewalls-Owner@GreatCircle.COM Mon Oct 5 18:18:58 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14823; Mon, 5 Oct 92 18:18:58 PDT Received: from ray.lloyd.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14817; Mon, 5 Oct 92 18:18:52 PDT Received: from harry.lloyd.com. by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA14669; Mon, 5 Oct 92 18:18:42 PDT Date: Mon, 5 Oct 92 18:18:42 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210060118.AA14669@ray.lloyd.com> Received: by harry.lloyd.com. (4.1/SMI-4.1) id AA02698; Mon, 5 Oct 92 18:18:41 PDT To: firewalls@GreatCircle.COM Subject: filtering on input or output Reply-To: brian@lloyd.com Sender: Firewalls-Owner@GreatCircle.COM >> Cisco routers filter on output, not input, a serious disadvantage for >> security purposes. >Yes, but since they filter on both interfaces, the internal and >external ones, "filtering on input" on one interface is achieved >by "filtering on output" on the other one. This is feasible and >that's how we do it. There is a difference when filtering on input or output. If you have a router with just two interfaces, filtering on output is just fine because you know that the packets that come in on interface A are going to go out on interface B. If you have a router with upteen interfaces it makes a big difference whether you filter on input or output. For example, let's assume that I have a cisco router with a 56K serial port and 6 ethernet ports. I was fast routing on the ethernet ports and do not want to incur the performance penalty of turning on the filters for the ethernet ports. If I could filter in both directions on the 56K port, I would take the penalty there where it really doesn't cost my anything. Another plus: filtering on the aforementioned 56K port would also put the router itself inside the firewall, thus potentially "hardening" it against undesired access attempts. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442 From Firewalls-Owner@GreatCircle.COM Mon Oct 5 18:26:53 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14841; Mon, 5 Oct 92 18:26:53 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14835; Mon, 5 Oct 92 18:26:45 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA09435; Mon, 5 Oct 92 21:26:37 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA05415; Mon, 5 Oct 92 21:26:06 -0400 Date: Mon, 5 Oct 92 21:26:06 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210060126.AA05415@hussar.dco.dec.com> To: firewalls@GreatCircle.COM, jbb@flare.cs.umb.edu Subject: Re: Sales Hype and Defenestrated Dead Chickens Sender: Firewalls-Owner@GreatCircle.COM John Brown writes: > Seems your favorite subject is dead chickens. Why not elaborate >the algorithms of the ftp server code you wrote, rather than flogging >fears and offering SEAL as the ideal adjunct to your solution? Look, John - I'm interested in security not what you think is marketing hype or not. I believe that the issues I am raising are serious, and apply to most firewalls and not specifically to DEC's solution. In fact I can't seem to recall that I mentioned DEC's offering in either of the two messages you have taken exception with. The FTP gateway is not a particularly complex product, and I don't think it requires extensive elaboration. I have in fact already described some of the tricks I play to make it work with non-modified ftp clients. That was "value added" to the discussion that our competitors can use. What do you expect me to do, post the source? I'm sorry I can't do that because DEC owns it and DEC pays me a salary and it cost DEC money (and me time) to develop it, and out here in the real world that's how things work. The internals of the beast are pretty darned simple. Now, if everyone in the mailing list agrees to make John the self-appointed arbiter of what is "marketing hype" that's fine, I'll shut up. Otherwise, why don't you lighten up a little? mjr. From Firewalls-Owner@GreatCircle.COM Mon Oct 5 18:58:49 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14948; Mon, 5 Oct 92 18:58:49 PDT Received: from egret.cc.wwu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA14942; Mon, 5 Oct 92 18:58:40 PDT Received: by egret.cc.wwu.edu (4.1/SMI-4.1) id AA02803; Mon, 5 Oct 92 19:00:11 PDT Date: Mon, 5 Oct 92 19:00:11 PDT From: jdw@egret.cc.wwu.edu (Jeff Wandling) Message-Id: <9210060200.AA02803@egret.cc.wwu.edu> To: firewalls@GreatCircle.COM Subject: cisco router & "interfaces used":"subnet" ratio Sender: Firewalls-Owner@GreatCircle.COM This is hard to explain so bear with me please. We have one router for our campus. Our net address is 140.160. We have several subnets (5 total at last count). We are only using 2 interfaces on the router. One subnet (cs.wwu.edu) uses one interface and all of the other subnets are on the other interface. This includes two subnets that are connected via a mixture of utp, coax and fiber-optics to the router. These are are {cc|geol|math|physics}.wwu.edu. Net traffic is getting really high. Packets are being dropped and through-put is falling. There is room physically to add more interfaces if needed. question is: should so many subnets be on one interface? Additional inforamation: The person resonsible for this set up has the router configured with a netmask of 0xffffff00. The netmasks on all machines on the subnets geol,math, and physics are 0xffff0000 -- With the router netmask of 0xffffff00 and netmasks on the hosts in geol, math, and physics subnets of 0xffff0000 and 4 subnetss connected in parallel off one interface seems silly! As I see it, there should be fewer subnets per interface, if not only one per interface. But, I don't know much about routers. What do you folks do? Do you try to cram as many subnets as possible one one interface or do you spread them out a little... Email to me please and I'll summarize if interest. If I didn't explain it with the proper terms or lingo, don't flame me to death. I have unique opportunities to see things with respect to our net, but my studies prevent me from "living and breathing" this stuff. Thanks in advance, -jeff From Firewalls-Owner@GreatCircle.COM Tue Oct 6 05:17:16 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA15836; Tue, 6 Oct 92 05:17:16 PDT Received: from cellar.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA15830; Tue, 6 Oct 92 05:17:03 PDT Date: Tue, 06 Oct 92 10:53:09 GMT Message-Id: <560@cellar.demon.co.uk> From: ash@cellar.demon.co.uk (Andrew Hardie) To: firewalls@GreatCircle.COM Subject: ACS4100 brouter; info please Lines: 5 X-Mailer: PCElm 3.01 (1.3 gt) Sender: Firewalls-Owner@GreatCircle.COM Anyone have experience of an ACC ACS4100 brouter, especially in a filtering / firewall context? Any info or user experiences welcome. Thanks Andrew From Firewalls-Owner@GreatCircle.COM Tue Oct 6 07:16:20 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA16069; Tue, 6 Oct 92 07:16:20 PDT Received: from cayman.Cayman.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA16063; Tue, 6 Oct 92 07:16:03 PDT Received: from cuba.engineering (cuba.cayman.com) by cayman.Cayman.COM (4.1/SMI-4.0) id AA01730; Tue, 6 Oct 92 10:16:34 EDT Received: from cancun.engineering by cuba.engineering (4.1/SMI-4.1) id AA08208; Tue, 6 Oct 92 10:16:32 EDT From: whitney@Cayman.COM (Nancy Whitney) Message-Id: <9210061416.AA08208@cuba.engineering> Subject: To: firewalls@GreatCircle.COM Date: Tue, 6 Oct 92 10:15:23 EDT X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM how do I get off of this mailing list? From Firewalls-Owner@GreatCircle.COM Tue Oct 6 08:45:50 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA16367; Tue, 6 Oct 92 08:45:50 PDT Received: from gatekeeper.oracle.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA16361; Tue, 6 Oct 92 08:45:44 PDT Received: from rchilder.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA19316; Tue, 6 Oct 92 08:46:01 PDT Received: by rchilder.us.oracle.com (5.59.10/37.6) id AA26375; Tue, 6 Oct 92 08:41:31 PDT Message-Id: <9210061541.AA26375@rchilder.us.oracle.com> Date: Tue, 6 Oct 92 08:41:31 PDT From: Richard Childers To: Firewalls@GreatCircle.COM Subject: subnet-to-interface ratios Sender: Firewalls-Owner@GreatCircle.COM >From: jdw@egret.cc.wwu.edu (Jeff Wandling) >Date: Mon, 5 Oct 92 19:00:11 PDT >Subject: cisco router & "interfaces used":"subnet" ratio > >As I see it, there should be fewer subnets per interface, if not only >one per interface. But, I don't know much about routers. > >What do you folks do? Do you try to cram as many subnets as possible >one one interface or do you spread them out a little... Generally, there are two boundaries constraining configurations options. The first is, of course, what is physically and logically possible. But, usually well within the first boundary is the second ... what's affordable. When the traffic one has does not justify the cost of separate interfaces, one might choose to make one piece of hardware serve multiple requirements. But if the cost - which can be measured by estimating how many people are suffering how much delay per increment of time ( a tricky business, subject to overestimation by the parties involved but easily calculable if you've kept logs of traffic levels, IE, statistical data ), and how much that is costing your site, it _can_ be established that it would be cost-effective to purchase additional interfaces. Also, some marketing enters the picture. If the company has come out with a device which is bigger and better, or uses the latest generation of chip, say, your router uses a 68020 and they just came out with a 68030 version, the 68020 price drops ... so you were better off not buying all four right then, when you bought the brouter, and instead waiting until you needed to buy them. Summary : it's nice to have everything neat, with one-to-one corresponences between devices and logical subnets ... but not always cost-effective, unless you expect to quadruple usage in the next couple of months or year. -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From Firewalls-Owner@GreatCircle.COM Tue Oct 6 12:49:28 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17441; Tue, 6 Oct 92 12:49:28 PDT Received: from flare.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17435; Tue, 6 Oct 92 12:49:23 PDT Received: by flare.cs.umb.edu id AA02961 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Tue, 6 Oct 1992 15:49:14 -0400 Date: Tue, 6 Oct 1992 15:49:14 -0400 From: "John B. Brown" Message-Id: <199210061949.AA02961@flare.cs.umb.edu> To: firewalls@GreatCircle.COM, mjr@decuac.DEC.COM Subject: Re: Sales Hype and Defenestrated Dead Chickens Sender: Firewalls-Owner@GreatCircle.COM Dear Marcus, Accepted! JBB. From Firewalls-Owner@GreatCircle.COM Tue Oct 6 13:26:31 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17637; Tue, 6 Oct 92 13:26:31 PDT Received: from ash.cisco.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17627; Tue, 6 Oct 92 13:26:23 PDT Received: by ash.cisco.com; Tue, 6 Oct 92 13:26:29 -0700 From: Roland Acra Message-Id: <9210062026.AA17509@ash.cisco.com> Subject: Re: cisco router & "interfaces used":"subnet" ratio To: jdw@egret.cc.wwu.edu (Jeff Wandling) Date: Tue, 6 Oct 92 13:26:28 MDT Cc: firewalls@GreatCircle.COM In-Reply-To: <9210060200.AA02803@egret.cc.wwu.edu>; from "Jeff Wandling" at Oct 5, 92 7:00 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Jeff, Here's what is happening to your network, in all likelihood. You have configured things such that your hosts are not aware that your class B network is subnetted (mask 0xffff0000), while your router is aware of that (mask 0xffffff00). H1 H2 -----------+-------------//Router//---------+-------+------ H3 Let's suppose hosts H2 and H3 are on different subnets. When H2 wants to communicate with H3, it sends an ARP request to get H3's Ethernet (or whatever your LAN is) address. H3 will respond to that, but also the router will step in and respond by giving H2 its own Ethernet address. This is called "proxy-ARP" and is done by the router when it sees that H2 and H3 are on different subnets. The end result is that packets between H2 and H3 are duplicated by the router and switched over the same cable. This causes: 1. Your hosts to flip-flop between the true other host's Ethernet address and the router's Ethernet address in their ARP cache. 2. The router to do be loaded with useless work switching packets that were getting to their destination anyway, without its help. "Proxy-ARPing" can be disabled on the router, but then H2 and H3 wouldn't be able to talk to H1. Indeed, "proxy-ARP" was designed to solve exactly this case: An end-station (e.g., H2), unaware of any routing and unaware of any subnetting can talk to another station (here H1) which is on a different cable and a different subnet: the router answers H2's ARP request for H1's Ethernet address by giving its own Ethernet address. From that point on, H2 will form packets destined for H1 by putting H1's IP address and the router's Ethernet address (unaware that it isn't H1's Ethernet address but rather the router's). Everything happens, from H2's perspective, as if H1 was on the same cable. Changing the scheme to what you propose (i.e., mapping subnets to actual physical networks) will indeed make things cleaner. You still have 2 choices in that scenario: 1. Either you keep your hosts' subnet mask to 0xffff0000 and the router will be proxy-ARPing their requests (this won't be useless, though, because hosts from different subnets will be on different cables). 2. Or you change your hosts' mask to 0xffffff00, but then you need to make them aware of routing by having them point to the router. Indeed, in this case, when H2 tries to contact H3, it will be cogniscent of the fact that H3 is on a different subnet (its mask tells it so), and will need to turn to some router to switch the packets for it. Approach 1 above is obviously the path of least work as no software reconfiguration is needed on your host, only moving them around on separate cables. Hope this wasn't too long. Roland Acra Cisco Systems, Europe > > This is hard to explain so bear with me please. > > We have one router for our campus. Our net address is 140.160. > We have several subnets (5 total at last count). We are only using > 2 interfaces on the router. One subnet (cs.wwu.edu) uses one > interface and all of the other subnets are on the other interface. > This includes two subnets that are connected via a mixture > of utp, coax and fiber-optics to the router. These are are > {cc|geol|math|physics}.wwu.edu. Net traffic is getting really high. > Packets are being dropped and through-put is falling. There is > room physically to add more interfaces if needed. > > question is: should so many subnets be on one interface? > > Additional inforamation: The person resonsible for this set up has > the router configured with a netmask of 0xffffff00. The netmasks on > all machines on the subnets geol,math, and physics are 0xffff0000 -- > With the router netmask of 0xffffff00 and netmasks on the hosts in > geol, math, and physics subnets of 0xffff0000 and 4 subnetss connected > in parallel off one interface seems silly! > > As I see it, there should be fewer subnets per interface, if not only > one per interface. But, I don't know much about routers. > > What do you folks do? Do you try to cram as many subnets as possible > one one interface or do you spread them out a little... > > Email to me please and I'll summarize if interest. > > If I didn't explain it with the proper terms or lingo, don't flame me > to death. I have unique opportunities to see things with respect to > our net, but my studies prevent me from "living and breathing" this > stuff. > > Thanks in advance, > > -jeff > From brent@GreatCircle.COM Tue Oct 6 13:29:25 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17690; Tue, 6 Oct 92 13:29:25 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17678; Tue, 6 Oct 92 13:29:21 PDT Message-Id: <9210062029.AA17678@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: More on bouncing email and mail-to-news gateways Reply-To: Brent@GreatCircle.COM Date: Tue, 06 Oct 92 13:29:21 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Kenton Hoover of IntelliGenetics (shibumi@presto.ig.com) suggested a cool way of dealing with bouncing email addresses on mailing lists, which I've gone ahead and implemented for Firewalls. If you don't care how I intend to handle bounced messages (secure in the knowledge that mail to _you_ is never going to bounce... :-) and you don't run a mail-to-news gateway for Firewalls, don't bother reading the rest of this message. Basicly, if an address starts bouncing, and it doesn't look like an obviously transient problem (for instance, I was getting back "host unknown" for every host in Italy yesterday), then that address gets moved from the main "Firewalls" mailing list to a "Firewalls-Bounces" mailing list, with a message to the address explaining what happened. The Firewalls-Bounces mailing list will get a message either daily or weekly (I haven't decided yet) saying essentially "you were on Firewalls, but your mail started bouncing, so you've been moved to Firewalls-Bounces; here's how you get off of Firewalls-Bounces and back on Firewalls once you've got the problem fixed". The Firewalls-Bounces list is rigged so that I never get error messages back from it; they go straight to /dev/null. If an address is still on Firewalls-Bounces after a month or so, it gets dropped and I forget about it. The other "bounces" that have been annoying me lately are the ones from mail-to-news gateways of various sorts. Usually they complain because a message that's being gatewayed has no "Subject:" line, or more quoted than original text. Folks, I really don't CARE, and I wish those of you running gateways would take care that I _don't_ get such bogus messages back. We now return you to your regularly scheduled mailing list... -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Tue Oct 6 13:42:54 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17753; Tue, 6 Oct 92 13:42:54 PDT Received: from cmcl2.NYU.EDU ([192.76.177.18]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17747; Tue, 6 Oct 92 13:42:49 PDT Received: by cmcl2.NYU.EDU (5.61/1.34) id AA23879; Tue, 6 Oct 92 16:43:03 -0400 Received: from shaw.UUCP by modem2.deshaw.com (4.1/SMI-4.1) id AA27297; Tue, 6 Oct 92 16:36:33 EDT Received: from fs2 by deshaw.com (4.1/SMI-4.1) id AA25744 for cmcl2!greatcircle.com!firewalls; Tue, 6 Oct 92 16:36:24 EDT Message-Id: <9210062036.AA25744@deshaw.com> To: firewalls@GreatCircle.COM (Firewalls mailing list) Subject: Re: Quality of Wellfleet IP filtering Date: Tue, 06 Oct 92 16:36:21 -0400 From: Mark Moraes Sender: Firewalls-Owner@GreatCircle.COM | * ease of configuration Wellfleet filtering seems to work pretty well, but was a bit hard to discover -- several features that are very powerful/useful seem to have been added in some minor release to which we've either misplaced the docs, or weren't documented... (also, the "now you see it, now you don't" aspects of the user interface drive me crazy). Netblazer configuration was easier. In addition, since one can trivially edit the cnf file, I found it easier to create new filters on the Netblazer than with the Wellfleet screen-oriented user interface. (But then, I usually prefer control file or command line interfaces for configuration) | * Types of filtering offered Wellfleets (at least Link Nodes running 5.72) support multiple filters with different levels of precedence per network interface. Filters can specify IP source or destination network/host addresses, source or destination port ranges for UDP/TCP and user defined fields (specified by offset, length and value ranges). No test or monitoring facility that I can find, short of watching the dropped packet count rise... Mark. From brent@GreatCircle.COM Tue Oct 6 13:52:15 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17800; Tue, 6 Oct 92 13:52:15 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA17793; Tue, 6 Oct 92 13:52:12 PDT Message-Id: <9210062052.AA17793@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: Quality of Wellfleet IP filtering In-Reply-To: Your message of Tue, 06 Oct 92 16:36:21 -0400 Reply-To: Brent@GreatCircle.COM Date: Tue, 06 Oct 92 13:52:10 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Mark Moraes writes: # Netblazer configuration was easier. In addition, since one can trivially # edit the cnf file, I found it easier to create new filters on the Netblazer # than with the Wellfleet screen-oriented user interface. (But then, I usually # prefer control file or command line interfaces for configuration) One of the things you have to be careful of on NetBlazers is that it does NOT apply filters in the order you specify them; it reorders them in some funky way that I can never remember by number of significant bits in the source and/or destination mask. This is especially tricky when you're trying to modify existing filter sets. It's hard to see in advance just what effect your changes will have. What I do on NetBlazers is put all the filter commands in a separate file called "filters.cnf". This file begins with the statement "filter flush", which flushes all the filters. When I want to change the filters, I edit this file, FTP it over to the NetBlazer's disk, and "source" it. It zaps the current filter set and recreates a new set from the directives in the file. After I take a look at it and satisfy myself that it's doing what I want, I do a "save" to write these filters out to the disk (along with everything else about the current configuration). It's important to note that the "filters.cnf" is NOT read automaticly by the NetBlazer; it's read only when I explicitly do "source filters.cnf", which is why I have to make sure I do a "save" when I'm done so that the filters I've just added will still be in effect after the next reboot. Similar techniques (i.e., flush the current filters, and rebuild from scratch) have also worked well for me on other platforms, like Ciscos. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Fri Oct 9 14:13:23 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26003; Fri, 9 Oct 92 14:13:23 PDT Received: from SCS.SLAC.STANFORD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA25997; Fri, 9 Oct 92 14:13:15 PDT Received: from SCSW5.SLAC.STANFORD.EDU by SCS.SLAC.STANFORD.EDU with PMDF#10283; Fri, 9 Oct 1992 14:12 PDT Received: from SCSW5.SLAC.STANFORD.EDU by SCSW5.SLAC.STANFORD.EDU (PMDF #2896 ) id <01GPQXAS580M9LUY05@SCSW5.SLAC.STANFORD.EDU>; Fri, 9 Oct 1992 14:12:10 PST Date: 09 Oct 1992 14:12:10 -0800 (PST) From: "Mike Sullenberger (415) 926-2294" Subject: Re: cisco router & "interfaces used":"subnet" ratio To: jdw@egret.cc.wwu.edu Cc: acra@cisco.com, firewalls@GreatCircle.COM Message-Id: <01GPQXAS8PEW9LUY05@SCSW5.SLAC.STANFORD.EDU> X-Envelope-To: firewalls@GreatCircle.COM X-Vms-To: in%"jdw@egret.cc.wwu.edu" X-Vms-Cc: IN%"acra@cisco.com,firewalls@GreatCircle.COM" Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM > H1 H2 >-----------+-------------//Router//---------+-------+------ > H3 > >Let's suppose hosts H2 and H3 are on different subnets. >When H2 wants to communicate with H3, it sends an ARP >request to get H3's Ethernet (or whatever your LAN is) address. > >H3 will respond to that, but also the router will step in and >respond by giving H2 its own Ethernet address. This is called >"proxy-ARP" and is done by the router when it sees that H2 and >H3 are on different subnets. The end result is that packets >between H2 and H3 are duplicated by the router and switched >over the same cable. I hate to contradict someone from cisco, but we do this here and have no such problems. What I think needs to be understood is exactly how to configure the router correctly. H1 (1) H2 (2) -----------+-------------/[a]/R1/[b]/---------+-------+------ H3 (3) Using the above diagram, R1 is a cisco router with interfaces a and b. H1 is in subnet (1) H2 is in subnet (2) H3 is in subnet (3) In order for "proxy-ARP" to function correctly, R1 interface [a] has a "primary" address in subnet (1) and R1 interface [b] has a "primary" address in subnet (2) AND a "secondary" address in subnet (3). This last is very important. If H3 wants to talk with H2, H3 will ARP directly on the Ethernet for H2, H2 will answer and the router will keep quiet since it "knows" that both subnet (2) and subnet (3) are on its [b] interface. If H3 wants to talk with H1, H3 will ARP directly on the Ethernet for H1, R1 will answer with its ethernet address for interface [b], and then will forward packets between H1 and H3. I don't necessarily recommend setting up your network this way, we are in the process of converting from a bridged ethernet to a routed ethernet, and this "feature" is allowing us to convert on piece at a time. Mike Sullenberger Stanford Linear Accelerator Center. From brent@GreatCircle.COM Fri Oct 9 15:10:36 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26134; Fri, 9 Oct 92 15:10:36 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26124; Fri, 9 Oct 92 15:10:31 PDT Message-Id: <9210092210.AA26124@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: which services ? (was Re: none + some VS all - some) In-Reply-To: Your message of Mon, 28 Sep 1992 18:03:41 -0400 Date: Fri, 09 Oct 92 15:10:30 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM [ Ah, finally a slow afternoon and I can catch up on some of the back traffic on Firewalls... :-] David Bolen writes: # sidney@borland.com (Sidney Markowitz) writes: # # >The problem I have is how do you tell when a port is being used for a # >callback for a service initiated from the inside? I would be happy to # >filter out everything initiated from outside except for SMTP and NNTP, # >but after eliminating port numbers less than some n, and 6000 for X # >and 2000 for OpenWin and so on, how do I know whether a packet coming # >in to port m is responding to an ftp connection that someone has # >opened or is going to wake up some service I don't know about that is # >listening on that port? # # IMHO, This is a fundamental problem with a single level of traffic # filtering. All you have is some data in the packet header in the form of # port numbers that may or may not correspond to the actual data (in terms of # the data being what you think the port number implies). I like to think of # it in terms of not having enough "state" information to make the # appropriate choice as to whether or not that packet should be forwarded. There's one other useful piece of state that _is_ in TCP packets, that some routers will pay attention to: whether or not the "SYN" bit is set (i.e., whether or not this is the first packet of a new connection). If you filter packets with "SYN" set, you've pretty effectively blocked that connection. Steve Bellovin can talk about the problems posed by people spoofing TCP connections, though. # Now this method doesn't work for all protocols (UDP-based or stateless # protocols may be especially difficult), so you may still need to allow some # packet forwarding with filters in some cases, but I think the more popular # protocols can be handled through application-layer gateways. I haven't found it necessary to allow any UDP packets except DNS through most of the firewall filters I've built. # An alternative that I've known some people to use (that still just involves # packet filtering) is to have two filtering routers with a host in between, # and to set up the filters to only allow each side of the routers to reach # that single host. That way, the host handles FTP, SMTP forwarding, and can # be your news server, but you don't allow random IP connections between # internal and external hosts. Of course, this does require stuff like # FTPing first to that host, and then a second time to get the file # internally, but I think it's a little safer than just a single level of # filtering. I really HATE schemes like that; I feel that they're often much less secure than they might appear at first glance. The reason is that, if you've got a machine with a large and very transient population (i.e., 1000 people in the company have accounts on the machine, but only 10 or so might be using them at any given time), you never develop a feel for the "normal" usage patterns of the machine and its users, and you end up not noticing suspicious activity. In the firewalls I build, if a gateway machine is involved (and it usually is, to be the DNS, SMTP, FTP, and NNTP server that the rest of the world can talk to), I strongly encourage my clients NOT to allow user logins on that machine. With no users, the machine becomes much easier to profile and monitor. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Fri Oct 9 16:15:19 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26535; Fri, 9 Oct 92 16:15:19 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26265; Fri, 9 Oct 92 15:28:55 PDT Message-Id: <9210092228.AA26265@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites In-Reply-To: Your message of Mon, 05 Oct 92 03:12:19 EDT Date: Fri, 09 Oct 92 15:28:54 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Steve Bellovin writes, in response to one of my earlier postings: # The thing I _really_ think is a problem is so-called "double reverse" # lookups. In a double reverse lookup, after you do the address-to-name # translation to find the name of the host that's calling you, you then # do a name-to-address translation on that name to see if the address # you get back matches the address that's calling you. If the two # addresses don't match, you disallow the connection. # # I don't know what that's really supposed to provide in the way of # security, but it sure screws up systems which hide internal hostnames # as descirbed above, and systems where machines with multiple network # interfaces appear to be separate machines in the DNS databases (I know # this _shouldn't_ be necessary, but it often _is_ necessary to work # around routing and configuration limitations in today's software). # # It's very necessary. Since the forward and reverse trees are entirely # separate, if I control a reverse tree for my address space -- either # legitimately or because I've subverted a machine -- I can change the # reverse mapping to name a machine I know you trust. Ah, but I don't trust anything based on name. All of my packet filters are set up to filter by address, not name. None of the services on my gateway machines (the one that provides the SMTP, FTP, NNTP, and DNS servers that the outside world can see) do any sort of authentication by name (except for NNTP, which I'm not real concerned about anyway; if I was, I could do it by IP address as well). Here's another way to look at the double reverse issue: what does useful information knowing the name, and being sure of the name, get you that knowing simply the IP address (which you can read directly from the packet) doesn't? I contend that you can't trust the names you get from DNS even if you do a double-reverse lookup, so why should services be obnoxious about it and disallow connections if the double-reverse lookup fails? Certainly you should probably log the failed double-reverse lookups, and perhaps you should warn the client, but is it really reasonable to disallow the connection based on information you can't trust anyway? -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Fri Oct 9 16:15:21 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26538; Fri, 9 Oct 92 16:15:21 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26379; Fri, 9 Oct 92 16:00:42 PDT Message-Id: <9210092300.AA26379@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: Filters and interfaces. In-Reply-To: Your message of Sun, 4 Oct 92 04:20:53 +1000 Date: Fri, 09 Oct 92 16:00:41 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM avalon@coombs.anu.edu.au (Darren Reed) writes: # To reduce both the size of filter rulesets as well as increasing # throughput of non-filtered traffic, it would seem better to be able # to setup a different filter rule set for each interface connected to # the host. Are there any working packet filters which are able to # operate in this way or does anyone know of any texts which discuss # this ? With this approach, you could more easily block packets from # outside which were trying to be internal hosts. You are absolutely right. Most of the more useful filtering products in fact work this way. The best ones also let you specify both filters for both incoming and outgoing packets on each interface. See my paper (available for anonymous FTP as pub/pkt_filtering.ps.Z on FTP.GreatCircle.COM) for a more in-depth discussion. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Fri Oct 9 16:15:24 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26541; Fri, 9 Oct 92 16:15:24 PDT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26409; Fri, 9 Oct 92 16:07:42 PDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16804; Fri, 9 Oct 92 19:07:18 -0400 Message-Id: <9210092307.AA16804@relay2.UU.NET> Received: from tron.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 190632.24721; Fri, 9 Oct 1992 19:06:32 EDT Date: Fri, 9 Oct 92 17:46:31 -0400 From: tron!plaza.dnet!adkins@uunet.UU.NET (Marty Adkins, (W) ESG Distributed Systems, MS 1615, WIN 285-1479) To: "firewalls@GreatCircle.COM"@uunet.UU.NET Cc: ADKINS@uunet.UU.NET Subject: Re: cisco router & interfaces used:subnet ratio Sender: Firewalls-Owner@GreatCircle.COM >From: TRON::"uunet!GreatCircle.COM!Firewalls-Owner" 6-OCT-1992 19:16:46.29 >To: jdw@egret.cc.wwu.edu (Jeff Wandling) >CC: firewalls@GreatCircle.COM >Subj: Re: cisco router & "interfaces used":"subnet" ratio > >Jeff, > >Here's what is happening to your network, in all likelihood. > >You have configured things such that your hosts are not aware >that your class B network is subnetted (mask 0xffff0000), while >your router is aware of that (mask 0xffffff00). > > > H1 H2 >-----------+-------------//Router//---------+-------+------ > H3 > >Let's suppose hosts H2 and H3 are on different subnets. >When H2 wants to communicate with H3, it sends an ARP >request to get H3's Ethernet (or whatever your LAN is) address. > >H3 will respond to that, but also the router will step in and >respond by giving H2 its own Ethernet address. This is called >"proxy-ARP" and is done by the router when it sees that H2 and >H3 are on different subnets. The end result is that packets >between H2 and H3 are duplicated by the router and switched >over the same cable. This certainly isn't my understanding of how Cisco implements proxy arp! The documentation and our observation indicates that the router will only respond to an ARP when it believes it has the *best* route to that destination. So in the case described with two hosts in different subnets on the same cable, the Cisco should not reply. > >This causes: > >1. Your hosts to flip-flop between the true other host's Ethernet > address and the router's Ethernet address in their ARP cache. [deleted...] > >Hope this wasn't too long. > >Roland Acra >Cisco Systems, Europe [rest deleted] Marty Adkins Distributed Systems Westinghouse Electronic Systems Group Internet: Adkins@plaza.wec.com From brent@GreatCircle.COM Fri Oct 9 16:50:13 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26800; Fri, 9 Oct 92 16:50:13 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26791; Fri, 9 Oct 92 16:50:08 PDT Message-Id: <9210092350.AA26791@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: How to do proxy ftp? In-Reply-To: Your message of Mon, 5 Oct 92 11:23:36 PDT Date: Fri, 09 Oct 92 16:50:07 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM tmd@s1.gov (Tina M. Darmohray) writes: # I'm also interested in how to secure outgoing FTP using router packet filters. # # Is the router doing packet filtering on all packets except those that # provide the functionality that the site wants (and therefore has decided # that it is willing to live with as a "necessary potential security problem")? # Or, is there a dual-hop for the users involved? They login to the bastion # host, ftp, and then ftp again back to the local machine? # Or are their 2 routers involved? All of these are possible configurations. The system I usually set up basicly follows the first pattern: a filtering router between the "internal" nets and the rest of the world that allows only certain things (one of them being FTP) in certain directions (usually from the inside to the outside). If your router doesn't let you make filtering decisions based on source port (only based on destination port), here are the rules you need: Rule SrcAddr DstAddr Protcl. DstPort Action A intern extern TCP 21 permit # FTP command channel B intern extern TCP 20 permit # FTP data channel C extern intern TCP >1024 permit # return packets for both D DEFAULT deny Now, the problem here is that someone can attack anything you've got that lives on TCP above port 1024 if they use port 20 or 21 on their end. This means that you should explicitly deny access to TCP services that live above port 1024 that you don't want the outside world to talk to. What services might those be, you ask? Well, let's see... X lives at port 6000 (actually, "6000 + ", so if you have multiple X displays on your host, you might also be using port 6001, 6002, ...). Openwin pulls a similar trick at port 2000 (I think). Third-party packages that include server components are often configured to use ports above 1024 (databases like Sybase, communications programs like IRC, etc.). And who knows what your users might be running as a server above port 1024? The only good news is that if you don't know, the bad guys might not either, though they could always try every port above 1024 and see what the come up with. Whether that's an "acceptable exposure" is up to you. -Brent From Firewalls-Owner@GreatCircle.COM Sat Oct 10 03:25:42 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27686; Sat, 10 Oct 92 03:25:42 PDT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27680; Sat, 10 Oct 92 03:25:32 PDT Received: from falafel.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA09411 (5.65b/HUJI 4.27 for firewalls@greatcircle.com); Sat, 10 Oct 92 12:26:13 +0200 Received: from localhost by falafel.cs.huji.ac.il with SMTP id AA21282 (5.65b/HUJI 4.14 for firewalls@greatcircle.com); Sat, 10 Oct 92 12:26:04 +0200 Message-Id: <9210101026.AA21282@falafel.cs.huji.ac.il> To: firewalls@GreatCircle.COM Subject: Re: How to do proxy ftp? In-Reply-To: Your message of Fri, 09 Oct 92 16:50:07 -0700 . <9210092350.AA26791@mycroft.GreatCircle.COM> From: Amos Shapira Date: Sat, 10 Oct 92 12:26:02 +0200 Sender: Firewalls-Owner@GreatCircle.COM In message <9210092350.AA26791@mycroft.GreatCircle.COM> Brent Chapman (brent@greatcircle.com) writes: |If your router doesn't let you make filtering decisions based on |source port (only based on destination port), here are the rules you |need: | |Rule SrcAddr DstAddr Protcl. DstPort Action |A intern extern TCP 21 permit # FTP command channel |B intern extern TCP 20 permit # FTP data channel |C extern intern TCP >1024 permit # return packets for both |D DEFAULT deny | |Now, the problem here is that someone can attack anything you've got |that lives on TCP above port 1024 if they use port 20 or 21 on their end. | |This means that you should explicitly deny access to TCP services that |live above port 1024 that you don't want the outside world to talk to. | |What services might those be, you ask? Well, let's see... X lives at |port 6000 (actually, "6000 + ", so if you have multiple X displays |on your host, you might also be using port 6001, 6002, ...). Openwin pulls The answer seems too trivial so I hope I'm not missing anything. What about adding something like: Rule SrcAddr DstAddr Protcl. DstPort Action C1 extern intern TCP >5999 <6100 deny # avoid X11 spoofing I admit this is not as general as source-port filtering can be, but can answer the particular problem you described above. |Whether that's an "acceptable exposure" is up to you. Even though I don't consider myself a paranoid in this area, I think that the "allow everything as a default" approach can potentially defeat most firewalls configurations (I mean, you'll have to work pretty hard to make sure nothing "illegal" passes through the wall). Chirio, --Amos Shapira CS System Group, Hebrew University, Jerusalem, Israel amoss@cs.huji.ac.il From Firewalls-Owner@GreatCircle.COM Sat Oct 10 03:33:55 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27702; Sat, 10 Oct 92 03:33:55 PDT Received: from grasp1.univ-lyon1.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27696; Sat, 10 Oct 92 03:33:50 PDT Received: by grasp1.univ-lyon1.fr (5.67a8/IDA-1.5) via Rocad id AA26354; Sat, 10 Oct 1992 11:34:04 +0100 Date: Sat, 10 Oct 1992 11:34:04 +0100 From: Christophe Wolfhugel Message-Id: <199210101034.AA26354@grasp1.univ-lyon1.fr> To: firewalls@GreatCircle.COM Subject: Re: which services ? X-Charset: ASCII X-Char-Esc: 29 Sender: Firewalls-Owner@GreatCircle.COM Brent Chapman writes: > If you filter packets with "SYN" set, you've pretty effectively > blocked that connection. Steve Bellovin can talk about the problems > posed by people spoofing TCP connections, though. Just filtering the SYN/FIN segments is fully equivalent to authorizing the UDP traffic on the defined ports, except if one can ensure that the machine on the internal network does not have a modified TCP/IP layer. Chris From Firewalls-Owner@GreatCircle.COM Sat Oct 10 04:59:14 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27827; Sat, 10 Oct 92 04:59:14 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27821; Sat, 10 Oct 92 04:58:58 PDT Message-Id: <9210101158.AA27821@mycroft.GreatCircle.COM> Received: by inet; Sat Oct 10 07:59 EDT 1992 From: smb@ulysses.att.com To: Christophe Wolfhugel Cc: firewalls@GreatCircle.COM Subject: Re: which services ? Date: Sat, 10 Oct 92 07:58:49 EDT Sender: Firewalls-Owner@GreatCircle.COM Just filtering the SYN/FIN segments is fully equivalent to authorizing the UDP traffic on the defined ports, except if one can ensure that the machine on the internal network does not have a modified TCP/IP layer. If someone on the inside is playing games, the whole party is over. It's much easier to use some sort of ``tunnel driver'' to establish communications with a friend on the outside than to play that sort of game with TCP. (Someone who really wants to get information out of the company would use something like an 8 mm tape; they hold a few gigabytes, and fit nicely in a pocket, which is why I wouldn't bother with DEC's fancy ftp filters.) Incidentally, we regularly use SNMP to scan our routing tables for new or unknown networks. We're more concerned with some organization setting up a private link to a partner of theirs than we are about deliberate attempts to bypass our firewall, though we're well aware that that can happen. In fact, I recall hearing someone posting a similar story to comp.protocols.tcp-ip a few months ago. --Steve Bellovin From Firewalls-Owner@GreatCircle.COM Sat Oct 10 05:40:26 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27873; Sat, 10 Oct 92 05:40:26 PDT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27865; Sat, 10 Oct 92 05:40:06 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA03741; Sat, 10 Oct 92 22:40:04 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9210101240.AA03741@coombs.anu.edu.au> Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites To: firewalls@GreatCircle.COM Date: Sat, 10 Oct 92 22:40:03 EST In-Reply-To: <9210092228.AA26265@mycroft.GreatCircle.COM>; from "Brent Chapman" at Oct 9, 92 3:28 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM In some email I received from Brent Chapman, Sie wrote: [...] > Ah, but I don't trust anything based on name. All of my packet > filters are set up to filter by address, not name. None of the > services on my gateway machines (the one that provides the SMTP, FTP, > NNTP, and DNS servers that the outside world can see) do any sort of > authentication by name (except for NNTP, which I'm not real concerned > about anyway; if I was, I could do it by IP address as well). [...] Your lack of trust in DNS replies is well founded, but it may well be useful for you to know who is trying to spoof DNS records if you do an IP#->name lookup (from a DNS server) and get a 'local' machine name which has a different IP# to that which you're doing a lookup on. In this area, I think it is DNS libraries which are a bit on the deficient side; it would be nice to be able to set the a preference of /etc/hosts or a DNS server for each lookup AND also know from which the answer came. Then at least you can depend on local mappings (from /etc/hosts) and start asking questions when you see a clash. Darren. From Firewalls-Owner@GreatCircle.COM Sat Oct 10 08:48:55 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA28076; Sat, 10 Oct 92 08:48:55 PDT Received: from seas.smu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA28070; Sat, 10 Oct 92 08:48:40 PDT Received: by seas.smu.edu (/\==/\ Smail3.1.25.1 #25.1) id ; Sat, 10 Oct 92 10:48 EDT Message-Id: From: doug@seas.smu.edu (Doug Davis) Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites To: avalon@coombs.anu.edu.au Date: Sat, 10 Oct 92 10:48:30 EDT Cc: firewalls@GreatCircle.COM In-Reply-To: <9210101240.AA03741@coombs.anu.edu.au>; from "Darren Reed" at Oct 10, 92 10:40 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM > > In this area, I think it is DNS libraries which are a bit on the deficient > side; it would be nice to be able to set the a preference of /etc/hosts or > a DNS server for each lookup AND also know from which the answer came. Ultrix 4.xx provides this thru the svc config file. It allows you to specifiy one of "local", "yp", and "bind" for resolution of distributed "services" databases. Where the databases are one of aliases, auth, group, hosts, netgroup, networks, passwd, protocols, rpc, or services. The local resolution would be the representitive file on the local machine, such as /etc/hosts for the hosts database. doug From Firewalls-Owner@GreatCircle.COM Sat Oct 10 12:16:08 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA28293; Sat, 10 Oct 92 12:16:08 PDT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA28287; Sat, 10 Oct 92 12:15:43 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA11656; Sun, 11 Oct 92 05:15:46 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9210101915.AA11656@coombs.anu.edu.au> Subject: Re: DNS lookups To: firewalls@GreatCircle.COM Date: Sun, 11 Oct 92 5:15:45 EST Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM In some email I received from Doug Davis, Sie wrote: > > > In this area, I think it is DNS libraries which are a bit on the deficient > > side; it would be nice to be able to set the a preference of /etc/hosts or > > a DNS server for each lookup AND also know from which the answer came. > > Ultrix 4.xx provides this thru the svc config file. It allows > you to specifiy one of "local", "yp", and "bind" for resolution > of distributed "services" databases. Where the databases are one of > aliases, auth, group, hosts, netgroup, networks, passwd, protocols, rpc, > or services. > > The local resolution would be the representitive file on the local > machine, such as /etc/hosts for the hosts database. The Ultrix style configuration is also available if you replace your native resolve library with resolv+ (by Bill Wisner) which lets you choose the order of lookup. However, even with either the Ultrix approach or resolv+, what is really needed is to be able to look "local" and then (optionally) continue to do a "bind" lookup OR the other way around. Even still, its only worth doing a lookup on an IP# if it hasn't been faked, which is where the using packet screens/filters come into things by removing (obviously) bogus packets. Although mobile hosts could cause some interesting problems in the future for firewalls. Darren. From Firewalls-Owner@GreatCircle.COM Sun Oct 11 04:25:19 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA00550; Sun, 11 Oct 92 04:25:19 PDT Received: from eurogate.bnr.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA00544; Sun, 11 Oct 92 04:25:12 PDT Received: from bnr.co.uk by eurogate.bnr.co.uk with SMTP (PP) id <17832-0@eurogate.bnr.co.uk>; Sun, 11 Oct 1992 12:24:45 +0100 Received: from bnr.co.uk by innergate.bnr.co.uk with SMTP (PP) id <01518-0@innergate.bnr.co.uk>; Sun, 11 Oct 1992 12:24:40 +0100 To: avalon@coombs.anu.edu.au Cc: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites In-Reply-To: Message from Darren Reed on Sat, 10 Oct 92 22:40:03 -0500. Organisation: BNR Europe, HARLOW, Essex CM17 9NA, GB Phone: +44 279 402423 Date: Sun, 11 Oct 92 12:24:37 +0100 Message-Id: <14297.718802677@alder2.bnr.co.uk> From: Andrew Macpherson (Postmaster) Sender: Firewalls-Owner@GreatCircle.COM Darren Reed wrote: | Your lack of trust in DNS replies is well founded, but it may well be | useful for you to know who is trying to spoof DNS records if you do an | IP#->name lookup (from a DNS server) and get a 'local' machine name | which has a different IP# to that which you're doing a lookup on. | | In this area, I think it is DNS libraries which are a bit on the deficient | side; it would be nice to be able to set the a preference of /etc/hosts or | a DNS server for each lookup AND also know from which the answer came. | | Then at least you can depend on local mappings (from /etc/hosts) and start | asking questions when you see a clash. On a simmilar vein, I've a (yet another) version of libresolv which allows one to chose any order of `/etc/hosts' `DNS-internal' `DNS-global' and `NIS' which works well for `gethostby...' but has slight problems for direct res_ calls (you get whichever last succeeded of `DNS-(in|ex)ternal' which is usually appropriate, but...) This lives in libc on the gateway to which my users log on to access the Internet. It doesn't address the `where did I get this info from?' question, but could easily --- I havn't felt the need yet. If there is sufficient interest I could make a file available for FTP (sufficient > 4) From Firewalls-Owner@GreatCircle.COM Tue Oct 13 17:10:48 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07078; Tue, 13 Oct 92 17:10:48 PDT Received: from noc.B10.Ingr.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA07072; Tue, 13 Oct 92 17:10:37 PDT Received: by noc.B10.Ingr.com (5.65c/1.920611) id AA18881; Tue, 13 Oct 1992 19:08:35 -0500 Message-Id: <199210140008.AA18881@noc.B10.Ingr.com> Subject: Re: How to do proxy ftp? To: brent@GreatCircle.COM (Brent Chapman) Date: Tue, 13 Oct 92 19:08:32 CDT Cc: firewalls@GreatCircle.COM In-Reply-To: <9210092350.AA26791@mycroft.GreatCircle.COM>; from "Brent Chapman" at Oct 9, 92 4:50 pm X-Mailer: ELM [version 06.05.01.04 (2.3 PL11)] From: Don_Jarmon@ingr.com Sender: Firewalls-Owner@GreatCircle.COM INTERGRAPH CORPORATION ----------------------------------------------------------------------------- NETWORK OPERATIONS CENTER Folks: I am looking for help with a 3COM Netbuilder setting up this type of rule base. Thanks... All of these are possible configurations. The system I usually set up basicly follows the first pattern: a filtering router between the "internal" nets and the rest of the world that allows only certain things (one of them being FTP) in certain directions (usually from the inside to the outside). If your router doesn't let you make filtering decisions based on source port (only based on destination port), here are the rules you need: Rule SrcAddr DstAddr Protcl. DstPort Action A intern extern TCP 21 permit # FTP command channel B intern extern TCP 20 permit # FTP data channel C extern intern TCP >1024 permit # return packets for both D DEFAULT deny Now, the problem here is that someone can attack anything you've got that lives on TCP above port 1024 if they use port 20 or 21 on their end. This means that you should explicitly deny access to TCP services that live above port 1024 that you don't want the outside world to talk to. What services might those be, you ask? Well, let's see... X lives at port 6000 (actually, "6000 + ", so if you have multiple X displays on your host, you might also be using port 6001, 6002, ...). Openwin pulls a similar trick at port 2000 (I think). Third-party packages that include server components are often configured to use ports above 1024 (databases like Sybase, communications programs like IRC, etc.). And who knows what your users might be running as a server above port 1024? The only good news is that if you don't know, the bad guys might not either, though they could always try every port above 1024 and see what the come up with. Whether that's an "acceptable exposure" is up to you. Don Jarmon ...uunet!ingr!noc!don (UUCP) (205) 730-2010 FAX (205) 730-3805 don@noc.b10.ingr.com (INTERNET) * Intergraph Corporation, Mail Stop HQ1008, Huntsville, Ala, 35894-0001 * From Firewalls-Owner@GreatCircle.COM Thu Oct 15 07:06:31 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10277; Thu, 15 Oct 92 07:06:31 PDT Received: from usav01.glaxo.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10271; Thu, 15 Oct 92 07:06:14 PDT Message-Id: <9210151406.AA10271@mycroft.GreatCircle.COM> Date: 15 Oct 92 09:52:00 EST From: "USA::JMA21624" Subject: Xceptions to filter rules To: "firewalls" Sender: Firewalls-Owner@GreatCircle.COM As some have pointed out, we have to compromise security with users' needs, and in some cases this means allowing X sessions with outside nodes. Hopefully, this means making specific exceptions in the filter rules, specifying both source and destination node. What are the hidden gotchas in doing that? I talked with someone at Usenix who is using a modified su that does not work if other hosts have access to the x server, so that you don't give away the root password to xkey users. Sudo, dosu, su, and other utilities all should test the state of the x server before prompting for a password. Are there such modified sources available? If not, how difficult is it to add the xhost check? Is there a forum for X security? (or is it down the hall from Military Intelligence?) - Mac Allen From Firewalls-Owner@GreatCircle.COM Thu Oct 15 10:14:02 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10699; Thu, 15 Oct 92 10:14:02 PDT Received: from mail.Germany.EU.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10693; Thu, 15 Oct 92 10:13:53 PDT Received: from gate.muc.ibm.DE by mail.Germany.EU.net with SMTP (5.65c/EUnetD-2.2.0.i) via EUnet for greatcircle.com id ]A03220; Thu, 15 Oct 1992 18:13:27 +0100 Received: by gate.muc.ibm.de; Thu, 15 Oct 92 18:28:51 +0100 Received: by g6150e; Thu, 15 Oct 92 18:10:00 +0100 Received: by barolo.ak.munich.ibm.com (AIX 3.2/UCB 5.64/4.03afx1.4) id AA21314; Thu, 15 Oct 1992 18:11:29 +0100 From: afx@muc.ibm.de (Andreas Siegert) Message-Id: <9210151711.AA21314@barolo.ak.munich.ibm.com> Subject: Source routing on Ciscos To: firewalls@GreatCircle.COM (Firewall mailing list) Date: Thu, 15 Oct 1992 18:11:29 +0100 (NFT) X-Mailer: ELM [version 2.4 PL2] Content-Type: text Content-Length: 537 Sender: Firewalls-Owner@GreatCircle.COM Do ciscos do source routing on IP, can it be disabled? (I know it is configurabel for token-ring, but that doesn't apply here) cheers afx P.S.: I am looking for more info on proxy agents and comments from users of ANS InterLock -- Andreas Siegert / Postmaster IBM Deutschland GmbH | Never grep a yacc AIX Field Support Center Pocci Strasse 11 | by the i-node! Internet: afx@ibm.de D-8000 Muenchen 2 | Opinions are my own, VNET: SIEGERT@MUNIVM4 Voice: (49)-(89)-7670-509 not IBM's. From Firewalls-Owner@GreatCircle.COM Thu Oct 15 10:56:28 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10805; Thu, 15 Oct 92 10:56:28 PDT Received: from sgi.sgi.com (SGI.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10799; Thu, 15 Oct 92 10:56:23 PDT Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for firewalls@GreatCircle.COM id AA21453; Thu, 15 Oct 92 10:56:28 -0700 Received: from yeager.corp.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:afx@muc.ibm.de id AA16888; Thu, 15 Oct 92 10:56:26 -0700 Received: by yeager.corp.sgi.com (920330.SGI/911001.SGI) for @sgi.com:firewalls@GreatCircle.COM id AA19358; Thu, 15 Oct 92 10:55:25 -0700 Date: Thu, 15 Oct 92 10:55:24 PDT From: Eliot Lear To: afx@muc.ibm.de (Andreas Siegert) Cc: firewalls@GreatCircle.COM (Firewall mailing list) Subject: Re: Source routing on Ciscos In-Reply-To: Your message of Thu, 15 Oct 1992 18:11:29 +0100 (NFT) Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Yes, ciscos support source routing. Yes, it can be disabled. Yes, there are some checks against access lists (even with source routes). No, the last time I checked they were insufficient, because they only tested the adjacent hops or some such, and did not check the entire source route. Eliot Lear [lear@sgi.com] From Firewalls-Owner Fri Oct 16 14:53:23 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14997; Fri, 16 Oct 92 14:53:23 PDT Received: from ray.lloyd.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14991; Fri, 16 Oct 92 14:53:17 PDT Received: from harry.lloyd.com. by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01957; Fri, 16 Oct 92 14:53:09 PDT Date: Fri, 16 Oct 92 14:53:09 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210162153.AA01957@ray.lloyd.com> Received: by harry.lloyd.com. (4.1/SMI-4.1) id AA00169; Fri, 16 Oct 92 14:53:08 PDT To: Firewalls@GreatCircle.COM In-Reply-To: Firewalls-Digest-Owner@GreatCircle.COM's message of Fri, 16 Oct 92 14:31:33 PDT <9210162131.AA14904@mycroft.GreatCircle.COM> Subject: Dealing with RPC Reply-To: brian@lloyd.com Sender: Firewalls-Owner@GreatCircle.COM Due to the insecurity of RPC I have adopted the tack of advising my clients to filter all UDP-based services with the exception of port 53 (DNS/bind) and port 123 (NTP). Since the port numbers for server/server interactions are symetrical, it is very easy to create filters that have no other side effects. This seems to work pretty well and is transparent to most users. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From brent Fri Oct 16 14:58:40 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15043; Fri, 16 Oct 92 14:58:40 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15035; Fri, 16 Oct 92 14:58:37 PDT Message-Id: <9210162158.AA15035@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: Dealing with RPC In-Reply-To: Your message of Fri, 16 Oct 92 14:53:09 PDT Date: Fri, 16 Oct 92 14:58:36 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Brian Lloyd writes: # Due to the insecurity of RPC I have adopted the tack of advising my # clients to filter all UDP-based services with the exception of port 53 # (DNS/bind) and port 123 (NTP). Since the port numbers for # server/server interactions are symetrical, it is very easy to create # filters that have no other side effects. This seems to work pretty # well and is transparent to most users. One caveat is that internal hosts (those behind a packet filtering screen such as this) need to be clients of internal name servers (through the /etc/resolv.conf file on UNIX, or equivalent configuration info on other systems). Internal name servers can talk to external name servers through the peephole Brian describes above, but internal clients can't. Conversations between servers use 53 for both source and destination port; conversations between servers and clients use 53 at the server end and something "random" above 1024 at the client end. -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 Oct 21 07:59:37 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22793; Wed, 21 Oct 92 07:59:37 PDT Received: from ic.delmarva.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22787; Wed, 21 Oct 92 07:59:20 PDT Received: from blackhole.delmarva.com by trojan.delmarva.COM. id aa05018; 21 Oct 92 10:59 EDT Received: from mercury.delmarva.com by blackhole.delmarva.COM. id aa15748; 21 Oct 92 10:58 EDT Subject: New mailing list for Raptor Systems' firewall discussion To: net-ops@pa.dec.com, firewalls@GreatCircle.COM Date: Wed, 21 Oct 92 10:58:42 EDT X-Mailer: ELM [version 2.3 PL11] From: scoggin@blackhole.delmarva.COM Message-Id: <9210211058.aa03423@mercury.delmarva.COM.> Sender: Firewalls-Owner@GreatCircle.COM Raptor Systems Mailing List This is an announcement of a mailing list for users and prospective users of network security products manufactured by Raptor Systems. These include the Eagle and Eaglet systems. To be added or removed from this list, send mail to : raptor-request@delmarva.com Mail to the mailing list should be directed to: raptor@delmarva.com - John +---------------------------------------------------------------------+ | John K. Scoggin, Jr. Email: scoggin@delmarva.com | | Supervisor, Network Operations Phone: (302) 451-5200 | | Delmarva Power & Light Company Fax: (302) 451-5321 | | 500 N. Wakefield Drive | | Newark, DE 19714-6066 | +---------------------------------------------------------------------+ From Firewalls-Owner Thu Oct 22 11:20:31 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24758; Thu, 22 Oct 92 11:20:31 PDT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24752; Thu, 22 Oct 92 11:20:27 PDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA07344; Thu, 22 Oct 92 14:19:44 EDT Message-Id: <9210221819.AA07344@TIS.COM> To: firewalls@GreatCircle.COM Subject: TCP server query Date: Thu, 22 Oct 92 14:19:41 -0400 From: "David I. Dalva" Sender: Firewalls-Owner@GreatCircle.COM OK network experts, I have a tough (for me) question: what is the general way to determine what program is listening on a particular TCP port? These ports are unprivileged, and are not well-known network ports, as far as I can tell. I specifically would like to find out the rest of the servers in this table. Port Service --------------- 1024 YPBIND 1027 1028 1033 Dave Dalva Trusted Information Systems, Inc. Glenwood, MD 21738 (301) 854-6889 (301) 854-5363 FAX From Firewalls-Owner Thu Oct 22 12:17:20 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24868; Thu, 22 Oct 92 12:17:20 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24862; Thu, 22 Oct 92 12:17:15 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA29816; Thu, 22 Oct 92 15:17:06 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA09677; Thu, 22 Oct 92 15:17:04 -0400 Date: Thu, 22 Oct 92 15:17:04 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Will do TCP/IP for clues" Ranum) Message-Id: <9210221917.AA09677@hussar.dco.dec.com> To: firewalls@GreatCircle.COM Subject: Re: TCP server query Sender: Firewalls-Owner@GreatCircle.COM You do a netstat -A to get the address of the socket PCB, then Use ofiles to map it back. IE: nsl 7 #netstat -A Active Internet connections PCB Proto Recv-Q Send-Q Local Address Foreign Address (state) c5984400 tcp 0 0 nsl.smtp inet-gw-1.3414 ESTABLISHED c5967c00 tcp 0 187 nsl.login hussar.dco.d.1021 ESTABLISHED c586a700 tcp 0 0 nsl.3609 gatekeeper.d.6000 ESTABLISHED nsl 10 #ofiles -n c586a700 file 8030c320 of socket c597de00 of INPCB c5979a00 of PCB c586a700 USER PID TYPE FD CMD ed 24559 sock 3 xbiff nsl 11 # mjr. From Firewalls-Owner Thu Oct 22 12:33:17 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24908; Thu, 22 Oct 92 12:33:17 PDT Received: from linus.mitre.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24902; Thu, 22 Oct 92 12:33:13 PDT Received: from bede.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA14571; Thu, 22 Oct 92 15:33:27 -0400 Posted-Date: Thu, 22 Oct 92 15:33:24 -0400 Received: by bede.mitre.org (5.61/RCF-4C) id AA26239; Thu, 22 Oct 92 15:33:24 -0400 Date: Thu, 22 Oct 92 15:33:24 -0400 From: bede@linus.mitre.org Message-Id: <9210221933.AA26239@bede.mitre.org> To: dave@TIS.COM Cc: firewalls@GreatCircle.COM In-Reply-To: "David I. Dalva"'s message of Thu, 22 Oct 92 14:19:41 -0400 <9210221819.AA07344@TIS.COM> Subject: RE: TCP server query Sender: Firewalls-Owner@GreatCircle.COM Date: Thu, 22 Oct 92 14:19:41 -0400 From: "David I. Dalva" OK network experts, I have a tough (for me) question: what is the general way to determine what program is listening on a particular TCP port? These ports are unprivileged, and are not well-known network ports, as far as I can tell. I specifically would like to find out the rest of the servers in this table. Port Service --------------- 1024 YPBIND 1027 1028 1033 I suspect you're looking at ports assigned dynamically by `portmap'. These RPC port mappings are not fixed, being determined at boot time. You can use (on Suns) `rpcinfo -p' to find out which ports are currently assigned to the various RPC services (e.g. portmapper, ypbind, keyserv, ...). - Bede B. McCall MITRE Corporation Bedford, Massachusetts From Firewalls-Owner Fri Oct 23 06:45:08 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26403; Fri, 23 Oct 92 06:45:08 PDT Received: from usav01.glaxo.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26395; Fri, 23 Oct 92 06:44:51 PDT Message-Id: <9210231344.AA26395@mycroft.GreatCircle.COM> Date: 23 Oct 92 09:42:00 EST From: "USA::JMA21624" Subject: Proxy ftp & directional filtering To: "firewalls" Sender: Firewalls-Owner@GreatCircle.COM I have a general question about proxy ftp... For those who have PCs and Macs with gui-ftp implementations that cannot handle the "login script" required to use proxy ftp, why not filter only incoming ftp? - Mac Allen jma21624@usav01.glaxo.com From Firewalls-Owner Fri Oct 23 07:26:12 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26456; Fri, 23 Oct 92 07:26:12 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26450; Fri, 23 Oct 92 07:25:58 PDT Message-Id: <9210231425.AA26450@mycroft.GreatCircle.COM> Received: by inet; Fri Oct 23 10:25 EDT 1992 From: smb@ulysses.att.com To: "USA::JMA21624" Cc: "firewalls" Subject: Re: Proxy ftp & directional filtering Date: Fri, 23 Oct 92 10:25:40 EDT Sender: Firewalls-Owner@GreatCircle.COM I have a general question about proxy ftp... For those who have PCs and Macs with gui-ftp implementations that cannot handle the "login script" required to use proxy ftp, why not filter only incoming ftp? - Mac Allen jma21624@usav01.glaxo.com Two reasons... First, some places, such as DEC, want to monitor and limit outbound file transfers. Second, because the data channel is normally an incoming call to a random port number, it's somewhat dangerous to permit unrestricted use of it. Along those lines -- which implementations of the ftp *server* don't support the PASV command? I know of at least one -- the WIN TCP/IP for System V Release 3 -- but I haven't done extensive tests. From Firewalls-Owner Fri Oct 23 11:02:32 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26774; Fri, 23 Oct 92 11:02:32 PDT Received: from sgi.sgi.com (SGI.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26768; Fri, 23 Oct 92 11:02:24 PDT Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for firewalls@GreatCircle.COM id AA07941; Fri, 23 Oct 92 11:02:11 -0700 Received: from yeager.corp.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:dave@TIS.COM id AA13355; Fri, 23 Oct 92 11:02:09 -0700 Received: by yeager.corp.sgi.com (920330.SGI/911001.SGI) for @sgi.com:firewalls@GreatCircle.COM id AA04583; Fri, 23 Oct 92 11:02:08 -0700 Date: Fri, 23 Oct 92 11:02:07 PDT From: Eliot Lear To: "David I. Dalva" Cc: firewalls@GreatCircle.COM Subject: Re: TCP server query In-Reply-To: Your message of Thu, 22 Oct 92 14:19:41 -0400 Message-Id: Sender: Firewalls-Owner@GreatCircle.COM With SGI's you can determine what is running on what port by using the fuser command. Run it with tcp/port# as the argument on any port in a listen state and it will return a PID, which you can then look up by using ps. Eliot Lear [lear@sgi.com] From Firewalls-Owner Fri Oct 23 12:54:45 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26933; Fri, 23 Oct 92 12:54:45 PDT Received: from uu.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26927; Fri, 23 Oct 92 12:54:35 PDT Received: by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA04367; Fri, 23 Oct 92 15:45:35 -0400 Date: Fri, 23 Oct 92 13:32:34 EDT From: sra@bethesda.com (S. Richard Andrews) Received: by bethesda.com (NeXT-1.0 (From Sendmail 5.52)/3.2.083191-Bethesda Computers) id AA01506; Fri, 23 Oct 92 13:32:34 EDT Message-Id: <9210231732.AA01506@bethesda.com> Received: by NeXT Mailer (1.63) To: firewalls@GreatCircle.COM Subject: please release me...let me go Sender: Firewalls-Owner@GreatCircle.COM Please take me off your mailing list Thank you SRA From Firewalls-Owner Sun Oct 25 19:37:29 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01298; Sun, 25 Oct 92 19:37:29 PST Received: from grebyn.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01292; Sun, 25 Oct 92 19:37:22 PST Received: by grebyn.com (5.57/SMI-4.1/kan.8.19.92) id AA24274; Sun, 25 Oct 92 22:37:10 -0500 Received: by genesis.grebyn.com (4.1/SMI-4.1) id AA21983; Sun, 25 Oct 92 22:37:07 EST Date: Sun, 25 Oct 92 22:37:07 EST From: karl@grebyn.com (Karl A. Nyberg) Message-Id: <9210260337.AA21983@genesis.grebyn.com> To: firewalls@GreatCircle.COM Subject: Firewalls (non) FAQ. Sender: Firewalls-Owner@GreatCircle.COM Several weeks ago I offered to suffer the slings of marketing types and collect literature on available products, free software, FTP sites, books, papers, whatever, to reduce the marketing traffic on Firewalls. I received three e-mail submissions (some stuff from DEC's and AT&Ts FTP, and one product literature) and three offers to review. Nothing in the paper mail. Maybe somebody's trying to tell me something... :-) I'm declaring the exercise a success (it MAY have helped reduce traffic on firewalls at least a little) and moving on. Thanks to those who provided both kinds of support. -- Karl -- From Firewalls-Owner Sun Oct 25 20:49:34 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02917; Sun, 25 Oct 92 20:49:34 PST Received: from ns.oar.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02909; Sun, 25 Oct 92 20:49:28 PST Received: from valhalla.oar.net for kannan@oar.net by ns.oar.net (5.65c+KVa/920824.1144) id AA09089; Sun, 25 Oct 1992 23:49:19 -0500 Message-Id: <199210260449.AA09089@ns.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: firewalls@GreatCircle.COM Reply-To: kannan@oar.net Subject: Re: Firewalls (non) FAQ. In-Reply-To: Your message of Sun, 25 Oct 92 22:37:07 -0500.<9210260337.AA21983@genesis.grebyn.com> Date: Sun, 25 Oct 92 23:54:49 -0500 From: Kannan Varadhan Sender: Firewalls-Owner@GreatCircle.COM >>> From: karl@grebyn.com (Karl A. Nyberg) >>> Date: Sun, 25 Oct 92 22:37:07 EST > I received three e-mail submissions (some stuff from DEC's and AT&Ts FTP, > and one product literature) and three offers to review. Karl, Could you put these somewhere where we can pick them up? Thanks. A couple of other points: On OARnet, we have had to address the security concerns of our new customers. With this in mind, I had a paper written up describing options and procedures, and pointers for such people. If anyone is interested, it is in ftp.oar.net:/pub/OARnet/doc/oarsec.PS.Z. Even better, if anyone has comments or suggestions, very many thanks. ;-) While on the topic, I have a couple of questions: It was mentioned on the list, that for any box that offers packet filtering capabilities for use as a firewall, it is better if the box offers such capabilities, both on the inbound and outbound interfaces. Why? Most firewalls I have seen involve a dual router scheme. Given a box that does implement comprehensive packet filtering, what do the dual router scheme buy you that a single one does not? Please reply by mail, and I'll summarise. Thanks, Kannan -- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From brent Sun Oct 25 21:02:05 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02977; Sun, 25 Oct 92 21:02:05 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02970; Sun, 25 Oct 92 21:02:02 PST Message-Id: <9210260502.AA02970@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: Firewalls (non) FAQ. In-Reply-To: Your message of Sun, 25 Oct 92 23:54:49 -0500 Date: Sun, 25 Oct 92 21:02:01 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Kannan Varadhan writes: # While on the topic, I have a couple of questions: # It was mentioned on the list, that for any box that offers # packet filtering capabilities for use as a firewall, it is better if # the box offers such capabilities, both on the inbound and outbound # interfaces. Why? # Most firewalls I have seen involve a dual router scheme. # Given a box that does implement comprehensive packet filtering, what # do the dual router scheme buy you that a single one does not? # # Please reply by mail, and I'll summarise. While I appreciate the sentiment of summarizing, I'd rather people responded to the list. It's been kind of quiet on Firewalls lately (for a while, though, I was tempted to rename it Fireballs! :-), and questions like these (which are both excellent questions, by the way) are a great way to kick off discussions that we can all benefit from. I'll be kicking in my two cents' worth on these particular questions as soon as I get unburied from the mail that came in while I was at the LISA conference (OUTSTANDING conference, by the way, just like always!) and get another mailing list (I now manage 23 of them... this latest one is for mailing list managers) set up. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Oct 26 10:31:42 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05834; Mon, 26 Oct 92 10:31:42 PST Received: from gatekeeper.oracle.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05828; Mon, 26 Oct 92 10:31:37 PST Received: from rchilder.us.oracle.com by gatekeeper.oracle.com (Oracle 1.12/37.7) id AA16067; Mon, 26 Oct 92 10:31:56 PST Received: by rchilder.us.oracle.com (5.59.10/37.6) id AA23179; Mon, 26 Oct 92 11:21:16 PDT Message-Id: <9210261821.AA23179@rchilder.us.oracle.com> Date: Mon, 26 Oct 92 11:21:16 PDT From: Richard Childers To: Firewalls@GreatCircle.COM Subject: inbound/outbound filtering Sender: Firewalls-Owner@GreatCircle.COM " It was mentioned on the list, that for any box that offers packet filtering capabilities for use as a firewall, it is better if the box offers such capabilities, both on the inbound and outbound interfaces. Why?" Because the danger exists on both sides of the router ... 'crackers' breaking in, and employees transferring data out. -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From Firewalls-Owner Mon Oct 26 10:53:45 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05971; Mon, 26 Oct 92 10:53:45 PST Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05965; Mon, 26 Oct 92 10:53:39 PST Message-Id: <9210261853.AA05965@mycroft.GreatCircle.COM> Received: by inet; Mon Oct 26 13:53 EST 1992 From: smb@ulysses.att.com To: Richard Childers Cc: Firewalls@GreatCircle.COM Subject: Re: inbound/outbound filtering Date: Mon, 26 Oct 92 13:53:22 EST Sender: Firewalls-Owner@GreatCircle.COM " It was mentioned on the list, that for any box that offers packet filtering capabilities for use as a firewall, it is better if the box offers such capabilities, both on the inbound and outbound interfaces. Why?" Because the danger exists on both sides of the router ... 'crackers' breaking in, and employees transferring data out. -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 5 06 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. Your quote is quite appropriate for this question... Anyway, I disagree with your assessment. In a world of multi-gigabyte 8 mm tapes, I think that trying to shut the electronic door that way is futile. I dislike inbound-only filtering because you've lost information -- what wire the packet actually entered on -- and that's important in multi-port routers. From Firewalls-Owner Mon Oct 26 11:50:25 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06338; Mon, 26 Oct 92 11:50:25 PST Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06332; Mon, 26 Oct 92 11:50:16 PST Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA26503; Mon, 26 Oct 92 14:50:33 -0500 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA16259; Mon, 26 Oct 92 14:50:32 -0500 Date: Mon, 26 Oct 92 14:50:32 -0500 From: mjr@decuac.DEC.COM (Marcus J. "Will do TCP/IP for clues" Ranum) Message-Id: <9210261950.AA16259@hussar.dco.dec.com> To: Firewalls@GreatCircle.COM Subject: Re: inbound/outbound filtering Sender: Firewalls-Owner@GreatCircle.COM Steve Bellovin writes: >Anyway, I disagree with your assessment. In a world of multi-gigabyte >8 mm tapes, I think that trying to shut the electronic door that way is >futile. Unfortunately, Steve's answer is that of the technologist. I doubt that any of us will argue that he's wrong, but there are LOADS of corporate data security cops who CANNOT accept that as an argument. This is because if I sneak out a tape, they can explain to their boss that I stole a tape. If I sneak out data over the network, they have to explain to their boss (who most likely won't know beans about networking or even computers*) how it happened. The technical problems are usually dwarfed by the political ones. :( mjr. *Speaking in principle, not about any organization in particular. From Firewalls-Owner Mon Oct 26 14:30:33 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06985; Mon, 26 Oct 92 14:30:33 PST Received: from ns.oar.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06979; Mon, 26 Oct 92 14:30:20 PST Received: from valhalla.oar.net for kannan@oar.net by ns.oar.net (5.65c+KVa/920824.1144) id AA00574; Mon, 26 Oct 1992 17:28:03 -0500 Message-Id: <199210262228.AA00574@ns.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: smb@ulysses.att.com Cc: Richard Childers , Firewalls@GreatCircle.COM Reply-To: kannan@oar.net Subject: Re: inbound/outbound filtering In-Reply-To: Your message of Mon, 26 Oct 92 13:53:22 -0500.<9210261853.AA05965@mycroft.GreatCircle.COM> Date: Mon, 26 Oct 92 17:33:34 -0500 From: Kannan Varadhan Sender: Firewalls-Owner@GreatCircle.COM >>> From: smb@ulysses.att.com >>> Date: Mon, 26 Oct 92 13:53:22 EST > " It was mentioned on the list, that for any box that offers > packet filtering capabilities for use as a firewall, it is better if > the box offers such capabilities, both on the inbound and outbound > interfaces. Why?" > > Because the danger exists on both sides of the router ... 'crackers' > breaking in, and employees transferring data out. > > Your quote is quite appropriate for this question... I was just explaining to Richard that I had phrased the question incorrectly. (Actually, when you think about it, the question, as asked makes no sense ;-). The question is ``why does one need both inbound and outbound filtering on each port? Would it not be sufficient if the box only filtered all packets inbound to it, prior to forwarding?'' > Anyway, I disagree with your assessment. In a world of multi-gigabyte > 8 mm tapes, I think that trying to shut the electronic door that way is > futile. I dislike inbound-only filtering because you've lost information -- > what wire the packet actually entered on -- and that's important in > multi-port routers. Inbound filtering tells me which wire the packet entered on. So, what additional information do I need that outbound packet filtering per interface give me? Having seen the cisco, and netblazer filter capabilities, I am assuming that any single filter statement is a 4-tuple of source, dest IP address, and source, dest port number. Kannan From Firewalls-Owner Mon Oct 26 15:16:26 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07411; Mon, 26 Oct 92 15:16:26 PST Received: from sematech1.SEMATECH.ORG by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07403; Mon, 26 Oct 92 15:16:18 PST Received: by sematech1.SEMATECH.ORG (AIX 1.3/1.1); Mon, 26 Oct 92 18:17:13 -0500 From: quentin_fennessy@SEMATECH.ORG Received: by gatev2.SEMATECH.ORG (5.57/1.15); Mon, 26 Oct 92 17:17:20 CST Message-Id: <9210262317.AA06714@gatev2.SEMATECH.ORG> Date: Mon, 26 Oct 92 17:17:07 CST To: Firewalls@GreatCircle.COM Subject: Secure, shared network idea Sender: Firewalls-Owner@GreatCircle.COM From: NAME: Quentin Fennessy FUNC: 360 TEL: To: "Firewalls@GreatCircle.com"@INTERNET I have an idea for a shared network that I would appreciate thoughts and comments on. The idea is, my company wants to work with others on development projects. The developers want to share access to data. However, we have invested time and money in an Internet gateway that is not appropriate for allowing more access. And, most companies are similarly blocked off of the Internet. The scheme I have drawn here shows two networks, Company A and Company B, with network connections to the Shared Network. I want to configure the shared net so that no connections initiated from within the shared net can get to either Company A or Company B. For Routers 2 and 3 I will probably use Netblazers. I don't know if I have a Cisco around for Router 1 yet. Would it be possible to install a node on SHARENET, that could be accessed via telnet, ftp, and X, from some set of nodes on Company A's net? And, could we control access similarly through router 2 and 3 for source nodes at Company B? ---+ +---+ | +--+ +------------+ | +----------+ | Shared | +-----------+ Company A +-----+ Router 1 |---+ Network +-----+ Router 2 | | +----------+ | | +-----+-----+ ----------+ +------------+ | | | +-----+-----+ | Router 3 | +-----+-----+ | | +-----+-----+ | Company B | | | +-----------+ I do not understand how you can filter connections by where they are initiated. Is this possible? I would like to put a shared node in the Shared network that can't get out, but is accessible to the other networks. I hope I have given enough detail. Thanks, Quentin Fennessy quentin_fennessy@sematech.org From Firewalls-Owner Mon Oct 26 15:30:06 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07521; Mon, 26 Oct 92 15:30:06 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07508; Mon, 26 Oct 92 15:29:57 PST Message-Id: <9210262329.AA07508@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: Firewalls (non) FAQ. In-Reply-To: Your message of Sun, 25 Oct 92 23:54:49 -0500 Date: Mon, 26 Oct 92 15:29:57 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Kannan Varadhan writes: # It was mentioned on the list, that for any box that offers # packet filtering capabilities for use as a firewall, it is better if # the box offers such capabilities, both on the inbound and outbound # interfaces. Why? Several reasons. If the router doesn't offer "inbound" filtering, you can't make the router itself appear to be "behind" the packet filtering fence; from either side, the router itself is "outside" the fence. If the router has more than 2 ports, it's much more convenient and efficient to be able to specify 1 set of inbound filters than N-1 (where N is the number of ports) set of outbound filters. # Most firewalls I have seen involve a dual router scheme. # Given a box that does implement comprehensive packet filtering, what # do the dual router scheme buy you that a single one does not? The key to the dual-router schemes is that there is a service host between the two routers providing all the services that the external world sees (SMTP, NNTP, DNS, and so forth). The router between this service host and the outside world protects the service host and the internal hosts from the outside world. The router between the service host and the internal hosts protects the internal hosts from both the service host and the outside world. Here's a diagram: +-------+ | World | +---*---+ | +---*------+ +--------------+ | Router 1 | | Service Host | +-----*----+ +------*-------+ | | ======*=======*========*============ Exposed subnet | +----*-----+ | Router 2 | +-----*----+ | ====*==========*====*=============== Internal networks | | +---*----+ +---*----+ | Host 1 | | Host 2 | +--------+ +--------+ Router 1 protects the service host and the internal hosts (host 1 and host 2) from the outside world. Router 2 protects the internal hosts from the outside world and the service host. -Brent From Firewalls-Owner Tue Oct 27 01:17:05 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09465; Tue, 27 Oct 92 01:17:05 PST Received: from mhs-relay.cs.wisc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09458; Tue, 27 Oct 92 01:16:59 PST X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Tue, 27 Oct 1992 03:15:44 +0000 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Tue, 27 Oct 1992 03:05:52 +0000 Date: Tue, 27 Oct 1992 03:05:52 +0000 X400-Originator: Jon.Olnes@nr.no X400-Recipients: Firewalls@GreatCircle.com X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;921027100552] X400-Content-Type: P2-1984 (2) Content-Identifier: 377 Conversion: Prohibited From: Jon Olnes Message-Id: <"377*/G=Jon/S=Olnes/O=nr/PRMD=uninett/ADMD= /C=no/"@MHS> To: Firewalls Subject: Re: inbound/outbound filtering Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk smb@ulysses.att.com (Steve Bellovin) wrote: > Anyway, I disagree with your assessment. In a world of multi-gigabyte > 8 mm tapes, I think that trying to shut the electronic door that way is > futile. If employees exporting data illegally is a serious threat in your environment, you won't have 8 mm tape stations accessible to everybody. Neither will you have local floppy drives in your workstations, and you may even want to avoid local disks completely. Thus, filtering of outbound network traffic may be desired, but only if (and I guess that's Steve's point as well) other, more important security mea- sures are in place. Jon Olnes, Norwegian Computing Centre, Oslo, Norway E-mail: Jon.Olnes@nr.no From Firewalls-Owner Tue Oct 27 05:22:19 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09702; Tue, 27 Oct 92 05:22:19 PST Received: from iti.org (hela.iti.org) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09695; Tue, 27 Oct 92 05:21:58 PST Received: by iti.org (5.65b/IDA-1.2.8) id AA13494; Tue, 27 Oct 92 08:23:20 -0500 Received: by lokkur.dexter.mi.us (4.1/SMI-4.1) id AA27952; Tue, 27 Oct 92 07:24:56 EST From: scs@lokkur.dexter.mi.us (Steve Simmons) Message-Id: <9210271224.AA27952@lokkur.dexter.mi.us> Subject: Re: inbound/outbound filtering To: Jon.Olnes@nr.no (Jon Olnes) Date: Tue, 27 Oct 1992 07:24:56 -0500 (EST) Cc: Firewalls@GreatCircle.COM In-Reply-To: <"377*/G=Jon/S=Olnes/O=nr/PRMD=uninett/ADMD= /C=no/"@MHS> from "Jon Olnes" at Oct 27, 92 03:05:52 am X-Mailer: ELM [version 2.4beta PL11] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 1078 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >If employees exporting data illegally is a serious threat in your environment, >you won't have 8 mm tape stations accessible to everybody. Neither will you >have local floppy drives in your workstations, and you may even want to >avoid local disks completely. It has been my experience that companies which are concerned to that level physically examine purses, briefcases, etc, as the employees depart. At Bell Northern Research (a descendant of Bell Labs) I used to bring stuff from the net into the building on floppies. Rather than go thru the hassle of trying to get them back out, BNR just bought them from me. There are other companies which do avoid local disks altogether. A quick glance thru the UNIX trade zines will show lots of quick-remove hard disks. At some plants the security guards lock them up in a vault at close of business, and you get them back out the next morning. IMHO, it wouldn't be hard to beat any of these precautions -- but the employers who try that level of security will certianly try to restrict people from putting files with ftp. From Firewalls-Owner Wed Oct 28 07:10:25 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12133; Wed, 28 Oct 92 07:10:25 PST Received: from crdgw1.ge.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12126; Wed, 28 Oct 92 07:10:18 PST Received: by crdgw1.ge.com (5.57/GE 1.141) id AA00632; Wed, 28 Oct 92 09:37:46 EST Received: from grymoire.crd.Ge.Com by alydar.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA06731; Wed, 28 Oct 92 09:37:05 EST Date: Wed, 28 Oct 92 09:37:05 EST From: barnett@alydar.crd.ge.com (Bruce Barnett) Message-Id: <9210281437.AA06731@alydar.crd.Ge.Com> To: Firewalls@GreatCircle.COM Subject: Source Routing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I read that the new version of telnet supports source routing. I was curious - could source routing be used to get thru a firewall? Bruce Barnett uunet!crdgw1!barnett From Firewalls-Owner Wed Oct 28 07:47:22 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12196; Wed, 28 Oct 92 07:47:22 PST Received: from ns.oar.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12185; Wed, 28 Oct 92 07:47:16 PST Received: from valhalla.oar.net for kannan@oar.net by ns.oar.net (5.65c+KVa/920824.1144) id AA09106; Wed, 28 Oct 1992 10:46:33 -0500 Message-Id: <199210281546.AA09106@ns.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: barnett@alydar.crd.ge.com (Bruce Barnett) Cc: Firewalls@GreatCircle.COM Reply-To: kannan@oar.net Subject: Re: Source Routing In-Reply-To: Your message of Wed, 28 Oct 92 09:37:05 -0500.<9210281437.AA06731@alydar.crd.Ge.Com> Date: Wed, 28 Oct 92 10:52:05 -0500 From: Kannan Varadhan Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>> From: barnett@alydar.crd.ge.com (Bruce Barnett) >>> Date: Wed, 28 Oct 92 09:37:05 EST > I read that the new version of telnet supports source routing. > I was curious - could source routing be used to get thru a firewall? Not if your firewall explicitly drops IP packets with IP source route options in them. Most routers do allow you to do that, if they allow good filtering capabilities. Kannan From Firewalls-Owner Wed Oct 28 10:46:30 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13093; Wed, 28 Oct 92 10:46:30 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13084; Wed, 28 Oct 92 10:46:26 PST Message-Id: <9210281846.AA13084@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: inbound/outbound filtering In-Reply-To: Your message of Mon, 26 Oct 92 17:33:34 -0500 Date: Wed, 28 Oct 92 10:46:25 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Kannan Varadhan writes: # Inbound filtering tells me which wire the packet entered on. So, # what additional information do I need that outbound packet filtering # per interface give me? Sometimes your filtering decisions for a packet will depend on what interface the packet came in on (for instance, if it's your Internet interface); other times, your filtering decisions will depend more on what interface the packet is going out on (for instance, if it's going out to an extra secure internal net). The reasons for not doing inbound-only filtering are pretty much the same as the reasons for not doing outbound-only filtering: it keeps you from having to replicate filtering rules that could be done as an outbound (or inbound) interface onto N-1 inbound (or outbound) interfaces, where N is how many interfaces your router has. A good router should let you do either inbound or outbound filtering, or both; whatever suits your particular application. # Having seen the cisco, and netblazer filter capabilities, I am # assuming that any single filter statement is a 4-tuple of # source, dest IP address, and source, dest port number. No, interface is included there as well on both the Cisco and the NetBlazer. The NetBlazer also includes direction-of-travel of the packet through the interface (Cisco is outbound-only). And yes, that's the way both boxes are currently implemented, but as I've expounded before (retrieve and read pub/pkt_filtering.ps.Z by anonymous FTP from FTP.GreatCircle.COM to hear my arguments), I think it's a serious shortcoming that many vendors (including Cisco and Telebit) omit TCP/UDP source port from consideration in filtering rules. -Brent From Firewalls-Owner Wed Oct 28 15:50:55 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14429; Wed, 28 Oct 92 15:50:55 PST Received: from nkosi.well.sf.ca.us by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14422; Wed, 28 Oct 92 15:50:47 PST Received: from well.sf.ca.us by nkosi.well.sf.ca.us (5.65c/SMI-4.1/nkosi-920918-2) id AA14462; Wed, 28 Oct 1992 15:49:55 -0800 Received: by well.sf.ca.us (5.65c/SMI-4.1/well-921015-1) id AA09087; Wed, 28 Oct 1992 15:47:45 -0800 Date: Wed, 28 Oct 1992 15:47:45 -0800 From: Jane Hirshfield Message-Id: <199210282347.AA09087@well.sf.ca.us> To: Firewalls@GreatCircle.COM, barnett@alydar.crd.ge.com Subject: Re: Source Routing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I think I'm getting the wrong e-mail on this stuff.... do you want someone else? From Firewalls-Owner Thu Oct 29 04:20:28 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15734; Thu, 29 Oct 92 04:20:28 PST Received: from hp4at.eunet.co.at by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15727; Thu, 29 Oct 92 04:20:16 PST Received: by hp4at.eunet.co.at id AA00215 (5.65c8/IDA-1.4.4 for Firewalls@greatcircle.com); Thu, 29 Oct 1992 13:19:51 +0100 From: Georg Chytil Message-Id: <199210291219.AA00215@hp4at.eunet.co.at> Subject: icmp considered dangerous ? To: Firewalls@GreatCircle.COM Date: Thu, 29 Oct 92 13:19:51 MEZ Reply-To: chytil@eunet.co.at X-Organization: EUnet Austria X-Phone: (+43) (0)222 346184 X-Home-Phone: (+43) (0)222 3718445 X-Fax: (+43) (0)222 3104462 Read-Receipt-To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk When establishing the filters on our cisco I use to block out icmp too, due to tradition & habit. Thinking about this I could not come up with an explanation beside some possible icmp-redirects which may be forged. Is there any other gain in blocking icmp on a firewall-router ? Georg <---------------------------------------------------------------------------> Chytil Georg EUnet EDV-Dienstleistungs-Gesellschaft (m.b.H. !) chytil@eunet.co.at chytil@vlsivie.tuwien.ac.at Phone : 0043/(0)222/346184 Fax : 0043/(0)222/3104462 Home : 0222/3718445 From Firewalls-Owner Thu Oct 29 05:16:38 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15831; Thu, 29 Oct 92 05:16:38 PST Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15824; Thu, 29 Oct 92 05:16:19 PST Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA09180; Thu, 29 Oct 92 07:16:24 CST Date: Thu, 29 Oct 92 07:16:24 CST From: jim@tadpole.com (Jim Thompson) Message-Id: <9210291316.AA09180@tadpole.tadpole.com> To: Firewalls@GreatCircle.COM, chytil@eunet.co.at Subject: Re: icmp considered dangerous ? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk It (icmp, via ICMP_ECHO (request) and ICMP_ECHOREPLY) could be used to 'probe' your network. A 'badguy' seding lots of SOURCEQUENCH packets could provoke denial of service conditions. To say nothing of the number of Sun machines that still crash given any packet with options in it, or covert channels that could be constructed out of icmp messages. Jim From Firewalls-Owner Thu Oct 29 06:14:44 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15919; Thu, 29 Oct 92 06:14:44 PST Received: from usav01.glaxo.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15912; Thu, 29 Oct 92 06:14:20 PST Message-Id: <9210291414.AA15912@mycroft.GreatCircle.COM> Date: 29 Oct 92 09:06:00 EST From: "USA::JMA21624" Subject: liabilities of ports >1023 To: "Firewalls" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Thanks to Marcus Ranum for clarifying some details about DECs' proxy FTP. I didn't ask my previous question very well, so I thought I would try again! Knowing DECs' position, I am curious about how others feel. One valuable thing about DEC's proxy services is the authentication of outside users... without that, it doesn't make sense to use proxy services for incoming users. My question was meant to discover the gotchas (define the risks so I can weigh them against the costs) related to allowing internal nodes use of telnet and ftp without going through a proxy service. In other words, how bad is it to allow all incoming packets destined for ports greater than 1023? (...so the ftp data channel will work.) That is the bottom line when you look at the pros and cons of proxy services. Firewalls using proxy services can filter *everything* except what is specifically desired. Those that don't use proxy services must allow all incoming packets destined for ports greater than 1023 (except 6000 and, using Brent's advice, all UDP except DNS). Doesn't this vastly increase the risk of compromise? What kind of mean, nasty things can intruders do if you let them probe your network using all those TCP ports? What kind of things can internal users do (inadvertantly or intentionally) to expose a network that allows incoming TCP packets destined for ports >1023? Can an intruder get in without inside help (either inadvertant or intentional)? I hope I have expressed my question better this time! Thanks! - Mac Allen jma21624@usav01.glaxo.com From Firewalls-Owner Thu Oct 29 07:43:59 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16081; Thu, 29 Oct 92 07:43:59 PST Received: from leigh.s1.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16074; Thu, 29 Oct 92 07:43:48 PST Received: from terminus.s1.gov by leigh.s1.gov (4.1/TMD1.4) id AA03144; Thu, 29 Oct 92 08:43:35 PPE Received: by terminus.s1.gov (4.1/TMD1.4) id AA04443; Thu, 29 Oct 92 07:43:32 PST From: Leland K. Neely Message-Id: <9210291543.AA04443@terminus.s1.gov> Subject: Re: liabilities of ports >1023 To: JMA21624%USA.decnet@usav01.glaxo.com (USA::JMA21624) Date: Thu, 29 Oct 92 7:43:30 PST Cc: Firewalls@GreatCircle.COM In-Reply-To: <9210291414.AA15912@mycroft.GreatCircle.COM>; from "USA::JMA21624" at Oct 30, 92 09:06:00 am X-Mailer: ELM [version 2.4dev PL32] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk USA::JMA21624 writes: > What kind of things can internal users do (inadvertantly or intentionally) > to expose a network that allows incoming TCP packets destined for ports >1023? > > Can an intruder get in without inside help (either inadvertant or intentional)? > I heard a story this week. It seemed that one site setup filters to permit port>1023 access, excepting X and openwin, and thought they were ok. One user decided that he "REALLY" had to have access so he reset telnet (or rlogin, I am not sure) to listen to a port equal to his phone extention. (eg 4532.) This worked so well, that his buddies all had him do the same for them. Now, each machine listened on a different port... Need I say more? Lee BTW I talked to ANS about their solution for a firewall for X. When you don't have DES encryption at both ends, their secure system for X isn't. They don't like me anymore. ;-) From Firewalls-Owner Thu Oct 29 08:45:45 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16234; Thu, 29 Oct 92 08:45:45 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16226; Thu, 29 Oct 92 08:45:41 PST Message-Id: <9210291645.AA16226@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: icmp considered dangerous ? In-Reply-To: Your message of Thu, 29 Oct 92 13:19:51 MEZ Date: Thu, 29 Oct 92 08:45:40 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Georg Chytil writes: # When establishing the filters on our cisco I use to block out icmp too, # due to tradition & habit. # Thinking about this I could not come up with an explanation # beside some possible icmp-redirects which may be forged. # Is there any other gain in blocking icmp on a firewall-router ? I consider most of the ICMP messages harmless from a security standpoint, and allow them through. The only one I routinely block is ICMP redirect. Some programs get confused if they can "ping" a host behind the gateway, but not open an IP connection to it. I think that's poor design of the programs; they should use an in-band equivalent to "ping" for their connectivity test. For instance, many RPC-based services (including NFS) define a "null" procedure, which simply takes no arguments and always returns "succeed" without actually doing anything; programs trying to determine connectivity can thus send a "null" command to the particular service they're interested in. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu Oct 29 09:11:57 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16453; Thu, 29 Oct 92 09:11:57 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16445; Thu, 29 Oct 92 09:11:54 PST Message-Id: <9210291711.AA16445@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: liabilities of ports >1023 In-Reply-To: Your message of Thu, 29 Oct 92 7:43:30 PST Date: Thu, 29 Oct 92 09:11:53 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Leland K. Neely writes: # I heard a story this week. It seemed that one site setup filters to # permit port>1023 access, excepting X and openwin, and thought they were ok. # One user decided that he "REALLY" had to have access so he reset telnet # (or rlogin, I am not sure) to listen to a port equal to his phone # extention. (eg 4532.) This worked so well, that his buddies all had him do # the same for them. Now, each machine listened on a different port... I firmly believe that ANY security mechanism can be compromised with insider help. The problem described above is a people problem, not a technical problem. You can't do effective security as an "add-on" at the border of your site; it requires the explicit or implicit cooperation (or at least the lack of active opposition) of the folks you're nominally trying to protect. If you don't have that, it's hopeless. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu Oct 29 10:00:50 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16746; Thu, 29 Oct 92 10:00:50 PST Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16734; Thu, 29 Oct 92 10:00:40 PST Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA00214; Thu, 29 Oct 92 13:00:32 -0500 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA10445; Thu, 29 Oct 92 13:00:31 -0500 Date: Thu, 29 Oct 92 13:00:31 -0500 From: mjr@decuac.DEC.COM (Marcus J. "Will do TCP/IP for clues" Ranum) Message-Id: <9210291800.AA10445@hussar.dco.dec.com> To: Firewalls@GreatCircle.COM Subject: Re: liabilities of ports >1023 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I firmly believe that ANY security mechanism can be compromised with >insider help. The problem described above is a people problem, not a >technical problem. I suspect that a lot of site security officers at various government agencies would like to disagree with that statement. Also, the DEC approach is pretty hard to subvert, even with insider help. I say "pretty hard" because I suppose it's possible, but I don't know how. There are always a few channels for data to get out, but we log them, which satisfies our requirements. It is *NOT* possible with our configuration for a user (even the systems manager) of an internal system to launch some kind of service that will compromise the net. A user on the gateway machines themselves could - but we don't allow "normal" users on the gateways. Even using something like our FTP application gateway as a channel by, for example, encoding a terminal session over the FTP control connection, won't work, since there are rate-limiters that will fire off alarms if a preset throughput is exceeded. The ULTRIX packet screen can also generate logs of attempts to do IP through the packet screen - useful for noticing insider attempts. You can go a long way to keep insiders from compromising you. Nothing's impossible - but you can make things real hard. mjr. From Firewalls-Owner Thu Oct 29 10:03:50 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16773; Thu, 29 Oct 92 10:03:50 PST Received: from world.std.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16766; Thu, 29 Oct 92 10:03:43 PST Received: from localhost by world.std.com (5.65c/Spike-2.0) id AA06844; Thu, 29 Oct 1992 13:04:02 -0500 Message-Id: <199210291804.AA06844@world.std.com> To: Brent Chapman Cc: Firewalls@GreatCircle.COM Subject: Re: liabilities of ports >1023 In-Reply-To: Your message of "Thu, 29 Oct 92 09:11:53 PST." <9210291711.AA16445@mycroft.GreatCircle.COM> Date: Thu, 29 Oct 92 13:03:58 -0500 From: Dan Geer Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Leland K. Neely writes: > > # I heard a story this week. It seemed that one site setup filters to > # permit port>1023 access, excepting X and openwin, and thought they were > # ok. One user decided that he "REALLY" had to have access so he reset > # telnet (or rlogin, I am not sure) to listen to a port equal to his phone > # extention. (eg 4532.) This worked so well, that his buddies all had him > # do the same for them. Now, each machine listened on a different port... > > I firmly believe that ANY security mechanism can be compromised with > insider help. The problem described above is a people problem, not a > technical problem. You can't do effective security as an "add-on" at > the border of your site; it requires the explicit or implicit > cooperation (or at least the lack of active opposition) of the folks > you're nominally trying to protect. If you don't have that, it's > hopeless. i'll go one further - lack of comprehensive internal security is 99.44% of the "external access" security problem. (excepting denial of service, which admits only palliative, ad hoc solutions.) --dan From Firewalls-Owner Thu Oct 29 10:35:17 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16963; Thu, 29 Oct 92 10:35:17 PST Received: from leigh.s1.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16956; Thu, 29 Oct 92 10:35:10 PST Received: from terminus.s1.gov by leigh.s1.gov (4.1/TMD1.4) id AA03547; Thu, 29 Oct 92 11:35:00 PPE Received: by terminus.s1.gov (4.1/TMD1.4) id AA07150; Thu, 29 Oct 92 10:34:57 PST From: Leland K. Neely Message-Id: <9210291834.AA07150@terminus.s1.gov> Subject: Re: liabilities of ports >1023 To: Firewalls@GreatCircle.COM Date: Thu, 29 Oct 92 10:34:52 PST In-Reply-To: <199210291804.AA06844@world.std.com>; from "Dan Geer" at Oct 30, 92 01:03:58 pm X-Mailer: ELM [version 2.4dev PL32] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dan Geer writes: > > > > Leland K. Neely writes: > > > > # I heard a story this week. It seemed that one site setup filters to > > # permit port>1023 access, excepting X and openwin, and thought they were > > # ok. One user decided that he "REALLY" had to have access so he reset > > # telnet (or rlogin, I am not sure) to listen to a port equal to his phone > > # extention. (eg 4532.) This worked so well, that his buddies all had him > > # do the same for them. Now, each machine listened on a different port... > > > > I firmly believe that ANY security mechanism can be compromised with > > insider help. The problem described above is a people problem, not a > > technical problem. You can't do effective security as an "add-on" at > > the border of your site; it requires the explicit or implicit > > cooperation (or at least the lack of active opposition) of the folks > > you're nominally trying to protect. If you don't have that, it's > > hopeless. > > i'll go one further - lack of comprehensive internal > security is 99.44% of the "external access" security > problem. (excepting denial of service, which admits > only palliative, ad hoc solutions.) > > --dan > OK guys. I should have mentioned that I know that this is an example of other problems. The initial question was one of "is this secure??" Now, I also wish to point out that making perl daemons that can listen to ports and then do things is easy too. In support of the IDIOT that moved the daemon and circumvented the firewall, I would guess that he thought he was doing something he needed "to do his job." If I'm not carefull, I will sound like an advocate of proxy services or other limited access setups. Not that I don't like them, they wrok. I just think that rigging your access controlls to allow known services to connect is cool. (outbound) I have engauged in a few interesting discussions of how to break security schemes. Unless you can absoulutely guarantee both people and technical cooperation, there is going to be holes in any scheme. Hell, I've heard of people setting up uucp feeds around firewalls too. I guess I want to have the front door so secure that the only way to break it is with out-of-bandwidth communication. I also want upper management support of the security so that I can enforce internal compliance. This could be a tall order, but, it is better than reading your name on the front of the paper or in alt.sites.cracked!! Thats all, Lee From Firewalls-Owner Thu Oct 29 10:56:22 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17064; Thu, 29 Oct 92 10:56:22 PST Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17056; Thu, 29 Oct 92 10:56:14 PST Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA10699; Thu, 29 Oct 92 12:56:34 CST Date: Thu, 29 Oct 92 12:56:34 CST From: jim@tadpole.com (Jim Thompson) Message-Id: <9210291856.AA10699@tadpole.tadpole.com> To: Firewalls@GreatCircle.COM, mjr@decuac.DEC.COM Subject: Re: liabilities of ports >1023 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Even using something like our FTP application gateway as a > channel by, for example, encoding a terminal session over the FTP > control connection, won't work, since there are rate-limiters that > will fire off alarms if a preset throughput is exceeded. The ULTRIX > packet screen can also generate logs of attempts to do IP through > the packet screen - useful for noticing insider attempts. Ah yes, but can I pass IP over a FTP-data connection? I doubt there are rate-limiters on that portion. Jim From Firewalls-Owner Thu Oct 29 11:03:04 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17103; Thu, 29 Oct 92 11:03:04 PST Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17096; Thu, 29 Oct 92 11:02:58 PST Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA01367; Thu, 29 Oct 92 14:03:12 -0500 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA11039; Thu, 29 Oct 92 14:03:10 -0500 Date: Thu, 29 Oct 92 14:03:10 -0500 From: mjr@decuac.DEC.COM (Marcus J. "Will do TCP/IP for clues" Ranum) Message-Id: <9210291903.AA11039@hussar.dco.dec.com> To: Firewalls@GreatCircle.COM, jim@tadpole.com Subject: Re: liabilities of ports >1023 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Ah yes, but can I pass IP over a FTP-data connection? I doubt there >are rate-limiters on that portion. The firewall administrator can configure the FTP application gateway to selectively block the ability to send data in, or out, on a host/network:source/destination basis. Failed attempts are logged. So at DEC, we allow all data to come in over the FTP data connection, and none to go out. If you needed to allow one machine (or user with a cryptographic smart card) to export data to a specific other machine or network on the internet, it could be configured to pass data only to them. mjr. (PS - note - I don't make the stupid policies. enforcing them is the price some of us have to pay to be on the net.) From Firewalls-Owner Thu Oct 29 12:01:07 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17306; Thu, 29 Oct 92 12:01:07 PST Received: from usav01.glaxo.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17299; Thu, 29 Oct 92 12:00:56 PST Message-Id: <9210292000.AA17299@mycroft.GreatCircle.COM> Date: 29 Oct 92 14:47:00 EST From: "USA::JMA21624" Subject: Re: liabilities of ports >1023 To: "Firewalls" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk So, it sounds like no one feels that an intruder can compromise a network protected by a firewall that allows incoming TCP packets destined for ports greater than 1023 *without insider help*, whether inadvertant or intentional. If this is true, it means that it is ok to allow incoming TCP packets destined for ports greater than 1023 (except X, etc) as long as you are confident that there are no services available on non-privileged ports, and never will be any such services. I thought the statistics always said the most likely attacks come from the inside. Doesn't that mean we should make sure the outbound channels are at least logged, so we will find out about new services on non-privileged ports? - Mac Allen jma21624@usav01.glaxo.com From Firewalls-Owner Thu Oct 29 12:10:06 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17326; Thu, 29 Oct 92 12:10:06 PST Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17317; Thu, 29 Oct 92 12:10:00 PST Message-Id: <9210292010.AA17317@mycroft.GreatCircle.COM> Received: by inet; Thu Oct 29 15:10 EST 1992 From: smb@ulysses.att.com To: "USA::JMA21624" Cc: "Firewalls" Subject: Re: liabilities of ports >1023 Date: Thu, 29 Oct 92 15:09:08 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk So, it sounds like no one feels that an intruder can compromise a network protected by a firewall that allows incoming TCP packets destined for ports greater than 1023 *without insider help*, whether inadvertant or intentional. If this is true, it means that it is ok to allow incoming TCP packets destined for ports greater than 1023 (except X, etc) as long as you are confident that there are no services available on non-privileged ports, and never will be any such services. Umm -- I think the main reason I disagree with you is the ``etc'' in your parenthetical remark. Today it's X11 on port 6000 and up, and openwin on 2000. What's next? Maybe there will be a NFS variant on TCP 2049, or a database system on some random port. My /etc/services file shows ``ingreslock'' on 1524. Is that important? Dunno; we don't run ingres. But I also don't know if anyone has ever audited it. From Firewalls-Owner Thu Oct 29 15:15:06 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18471; Thu, 29 Oct 92 15:15:06 PST Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18462; Thu, 29 Oct 92 15:14:56 PST Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU (5.65c/res.host.cf-3.5) with SMTP id AA22476; Thu, 29 Oct 1992 18:14:39 -0500 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.65c/res.client.cf-3.5) id AA06085; Thu, 29 Oct 1992 17:48:29 -0500 From: long-morrow@CS.YALE.EDU ("H. Morrow Long") Message-Id: <199210292248.AA06085@SPARKY.CF.CS.YALE.EDU> To: cert-tools@cert.org, Firewalls@GreatCircle.COM Subject: probe_tcp_ports program, was Re: liabilities of ports >1023 In-Reply-To: Your message of Thu, 29 Oct 92 13:00:31 EST. Date: Thu, 29 Oct 92 17:48:28 -0500 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I wrote the following small program which you might find helpful if you are worried about users running their own servers (which may be insecure) - such as WKSes, perl scripts, tinyMUDs, and home grown servers - possibly circumventing router filters which have been set up for security. I kept forgetting what TCP ports people were running various nifty servers on remote hosts where I had not login access (so I couldn't run 'cat' or 'ypcat' on a services file nor run 'netstat -a' on the remote host. This program will report on what TCP ports on the remote hosts have servers listening for connections. With verbose mode (command line option '-v') turned on it will list both active and inactive TCP ports. With 'hack' mode (command line option '-h') it will invoke a telnet session to the newly discovered port on the remote host. For those concerned about insecure services run by users opening up host security or those who want to tighten up router filter firewalls you might want to run probe_tcp_ports periodically from cron or a cron script (As well as other security audit s/w such as cops and crack!). Here is sample output: % probe_tcp_ports x Host x.y.yale.edu, Port 13 ("daytime" service) connection ... open. Host x.y.yale.edu, Port 21 ("ftp" service) connection ... open. Host x.y.yale.edu, Port 23 ("telnet" service) connection ... open. Host x.y.yale.edu, Port 25 ("smtp" service) connection ... open. Host x.y.yale.edu, Port 37 ("time" service) connection ... open. Host x.y.yale.edu, Port 43 ("whois" service) connection ... open. Host x.y.yale.edu, Port 53 ("domain" service) connection ... open. Host x.y.yale.edu, Port 70 connection ... open. Host x.y.yale.edu, Port 79 ("finger" service) connection ... open. Host x.y.yale.edu, Port 109 ("pop" service) connection ... open. Host x.y.yale.edu, Port 110 ("pop3" service) connection ... open. Host x.y.yale.edu, Port 111 ("sunrpc" service) connection ... open. ... Here is the probe_tcp_ports program source : --------------------------------------------------------------------------- /* * probe_tcp_ports */ #include #include #include #include #include #include #include #define RETURN_ERR -1 #define RETURN_FAIL 0 #define RETURN_SUCCESS 1 int Debug; int Hack; int Verbose; main(ArgC, ArgV) int ArgC; char **ArgV; { int Index; int SubIndex; for (Index = 1; (Index < ArgC) && (ArgV[Index][0] == '-'); Index++) for (SubIndex = 1; ArgV[Index][SubIndex]; SubIndex++) switch (ArgV[Index][SubIndex]) { case 'd': Debug++; break; case 'h': Hack++; break; case 'v': Verbose++; break; default: (void) fprintf(stderr, "Usage: probe_tcp_ports [-dhv] [hostname [hostname ...] ]\n"); exit(1); } for (; Index < ArgC; Index++) (void) Probe_TCP_Ports(ArgV[Index]); exit(0); } Probe_TCP_Ports(Name) char *Name; { unsigned Port; char *Host; struct hostent *HostEntryPointer; struct sockaddr_in SocketInetAddr; struct hostent TargetHost; struct in_addr TargetHostAddr; char *AddressList[1]; char NameBuffer[128]; extern int inet_addr(); extern char *rindex(); if (Name == NULL) return (RETURN_FAIL); Host = Name; if (Host == NULL) return (RETURN_FAIL); HostEntryPointer = gethostbyname(Host); if (HostEntryPointer == NULL) { TargetHostAddr.s_addr = inet_addr(Host); if (TargetHostAddr.s_addr == -1) { (void) printf("unknown host: %s\n", Host); return (RETURN_FAIL); } (void) strcpy(NameBuffer, Host); TargetHost.h_name = NameBuffer; TargetHost.h_addr_list = AddressList, TargetHost.h_addr = (char *) &TargetHostAddr; TargetHost.h_length = sizeof(struct in_addr); TargetHost.h_addrtype = AF_INET; TargetHost.h_aliases = 0; HostEntryPointer = &TargetHost; } SocketInetAddr.sin_family = HostEntryPointer->h_addrtype; bcopy(HostEntryPointer->h_addr, (char *) &SocketInetAddr.sin_addr, HostEntryPointer->h_length); for (Port = 1; Port < 65536; Port++) (void) Probe_TCP_Port(Port, HostEntryPointer, SocketInetAddr); return (RETURN_SUCCESS); } Probe_TCP_Port(Port, HostEntryPointer, SocketInetAddr) unsigned Port; struct hostent *HostEntryPointer; struct sockaddr_in SocketInetAddr; { char Buffer[BUFSIZ]; int SocketDescriptor; struct servent *ServiceEntryPointer; SocketInetAddr.sin_port = Port; SocketDescriptor = socket(AF_INET, SOCK_STREAM, 6); if (SocketDescriptor < 0) { perror("socket"); return (RETURN_ERR); } if (Verbose) { (void) printf("Host %s, Port %d ", HostEntryPointer->h_name, Port); if ((ServiceEntryPointer = getservbyport(Port, "tcp")) != (struct servent *) NULL) (void) printf(" (\"%s\" service) ", ServiceEntryPointer->s_name); (void) printf("connection ... "); (void) fflush(stdout); } if (connect(SocketDescriptor, (char *) &SocketInetAddr, sizeof(SocketInetAddr)) < 0) { if (Verbose) (void) printf("NOT open.\n"); if (Debug) perror("connect"); } else { if (!Verbose) { (void) printf("Host %s, Port %d ", HostEntryPointer->h_name, Port); if ((ServiceEntryPointer = getservbyport(Port,"tcp")) != (struct servent *) NULL) (void) printf(" (\"%s\" service) ", ServiceEntryPointer->s_name); (void) printf("connection ... "); (void) fflush(stdout); } (void) printf("open.\n"); if (Hack) { (void) sprintf(Buffer, "/usr/ucb/telnet %s %d", HostEntryPointer->h_name, Port); (void) system(Buffer); } } (void) close(SocketDescriptor); return (RETURN_SUCCESS); } ---------------------------------------------------------------------------------- _ _ __ _ __ (/_ / (/ \/ \ _ __ __ ____ _ __ (/ _ __ _) / / . / )_(_)_/ (_/ (_(_) (_(_( /___(_)_/ )_(_) ( ( ( _) H. Morrow Long Manager of Development Yale Univ. Comp Sci Dept. Computing Facility Mail Stop 2158, UUCP: yale!Long-Morrow Yale Station, ARPA: Long-Morrow@CS.Yale.EDU New Haven, CT 06520-2158 BITNET: Long-Morrow@YaleCS.BITNET (203)-432-{1248,1254} FAX: (203)-432-0593 From Firewalls-Owner Thu Oct 29 15:36:48 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18546; Thu, 29 Oct 92 15:36:48 PST Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18539; Thu, 29 Oct 92 15:36:43 PST Message-Id: <9210292336.AA18539@mycroft.GreatCircle.COM> Received: by inet; Thu Oct 29 18:37 EST 1992 From: smb@ulysses.att.com To: long-morrow@CS.YALE.EDU ("H. Morrow Long") Cc: cert-tools@cert.org, Firewalls@GreatCircle.COM Subject: Re: probe_tcp_ports program, was Re: liabilities of ports >1023 Date: Thu, 29 Oct 92 18:36:40 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Of course, someone ran a similar program *against* us a few days ago... As Salvor Hardin said, ``it's a poor atom blaster that won't point both ways''. --Steve Bellovin From Firewalls-Owner Thu Oct 29 17:06:29 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18834; Thu, 29 Oct 92 17:06:29 PST Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18750; Thu, 29 Oct 92 16:35:24 PST Received: from access.digex.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11420; Thu, 29 Oct 92 19:34:23 -0500 Received: by access.digex.com id AA06875 (5.65b/IDA-1.4.3 for firewalls@GreatCircle.COM); Thu, 29 Oct 92 19:34:06 -0500 Date: Thu, 29 Oct 92 19:34:06 -0500 From: "Robert B. Reinhardt" Message-Id: <9210300034.AA06875@access.digex.com> To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk **************NEW VERSION---SEVERAL CHANGES************* NOTE: This paper is offered as a summary of some light research I've done into UNIX network security architecture and availability of some tools and techniques that can be used. This post introduces some corrections to the first version that I posted on comp.security.misc on 09/19/92. I don't intend to keep updating and reposting this on a regular basis since, I really don't have the time. ========================cut here======================== SUMMARY PAPER: An Architectural Overview of UNIX Network Security (Specifically oriented toward Internet connectivity) Version 2 By Robert B. Reinhardt, October 8, 1992 (breinhar%srg@uunet.uu.net) - work (breinhar@access.digex.com) - home Nothing in this paper should be construed as a product endorsement. The contents herein are the a result of light research and some prototype implementation that I've done over the past nine months. I don't know if this will help you or not. This is basically just a digest of information that a lot of people already know. This is for those of you who don't already know. For each of the FIREWALL layers (sections) below, there is a subsection that follows that gives a brief description of some of the most widely used tools and techniques for implementing security controls and their availability. ================================================================= | | | PUBLIC (or) NON-PRIVATE NETWORK ACCESS Y | | O | ======================================================== U | | | R Y SECTION A --------------- | O | Router | F N U | | I E R --------------- R T | E W P ====================================================== W O O | A R L SECTION B --------------- L K I | Dual-homed | L C | UNIX Gateway| | A Y --------------- | N | | D A ======================================================== N | E D SECTION C --------------- Q | Hosts on | U P | Local Net | I E --------------- P R =========================================================== M S E O SECTION D Additional Measures to Enhance Security N N T N ============================================================= E L SECTION E Functional Requirements and Security Policy | | ================================================================== Before starting into a description of the various elements of each of the above layers I feel I should reiterate the need for first developing a local security policy. Each organization or site needs to have an effective security policy. There are many tools and techniques available to implement security controls, but you should first conduct a thorough analysis of what your needs are, in order to design and implement an efficient operational environment. You need to determine what your requirements for network services and features are, what level of security you require, and what risks you are willing to accept. Sometimes the benefit outweighs the risk, sometimes not. But, those decisions differ for each organization. The "firewall" concept for creating a security demarkation point between your local net and the outside, as well as the various methods for enhancing security may not be appropriate for everyone, and in some cases may not go far enough. But I believe this a good starting point for almost anyone with a general concern for UNIX network security. Let me apologize right now to the authors of these tools and designs. Since I am just giving a brief overview, I cannot do justice to a complete description of them. To the reader let me say that you should check the availability section and whenever possible obtain a README or other information before making your decisions. In many cases there is at least one paper (in most cases probably several) that have been published that describe these things in better detail. I'll try to list at least one source for each. Papers describing most if not all of these packages and techniques can be found in the SYMPOSIUM PROCEEDINGS of the USENIX Third UNIX Security Symposium (c) 1992 by the USENIX Association. Some of the functionality of these tools overlap. Since you have the source to these tools, you can modify them or customize them to add new features. SECTION A - Physical Access to your Network A1. Packet filtering. Several internet protocol routers provide the capability to filter packets. Packet filtering allows you to program the router to make a decision whether or not traffic can pass to or from your network based on several criteria such as: source ip address, destination ip address, protocol, tcp or udp port, etc. Availability: I only have 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. Read: Smoot Carl-Mitchell and John S. Quarterman, "Building Internet Firewalls"; UnixWorld; February, 1992; pp 93-102. NOTE: This layer of your security firewall also includes other methods of access between networks such as CALL-BACK MODEMS. SECTION B - Logical Access to your Network B1. TCP_WRAPPER. The "TCP_WRAPPER" tool 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.*. B2. SOCKS Library and sockd. The "sockd" and "SOCKS Library" 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: Unknown. Contact the authors for more information. David Koblas (koblas@netcom.com) or Michelle R. Koblas (mkoblas@nas.nasa.gov). B3. Kernel_Wrap for SunOS/RPC via Shared Libraries. Essentially this is a wrapper for SunOS daemons that use RCP, 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. B4. SWATCH. Simple WATCHER 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. B5. Controlled Access Point (CAP). This is more of a method or protocol definition than a specific product. CAP 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). B6. 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. B7. 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," but that's for another day. SECTION C - Physical and Logical Access to Hosts on your Network C1. 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). NOTE: 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. C2. Chkacct. Chkacct 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. C3. 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. C4. SHADOW. The shadow password suite of programs 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. NOTE: 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). C5. PASSWD+. Passwd+ is a proactive password checker 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. NOTE: 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+ is available via anonymous FTP from dartmouth.edu in ~/pub/passwd+tar.Z. C6. AUDIT. Audit is a policy-driven security checker for a heterogeneous environment. 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. NOTE: 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). C7. MIRO. Miro 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. SECTION D - Additional Security Enhancements The tools described in sections {A...C} 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 {A...C}. D1. 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). D2. 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 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). D3. 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. D4. Private-Key Certificates. This is not really a product, but rather a design proposal 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. D5. Multi-Level Security (MLS). I don't have any particular product in mind here, rather to point out that 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 Nth degree before covering the fundamentals. Many UNIX vendors are now shipping or preparing to ship a MLS version. An example that immediately comes to mind is AT&T System V/Release 4/MLS (SVR4/MLS). I don't have any firsthand experience with this to offer you, but I do have some secondhand comments. Basically, you can buy MLS as part of your OS, but all you've really bought are the tools to build your MLS security program with. From what I have heard, it takes considerable effort in software development to develop a set of programs and procedures in order to use MLS UNIX effectively as an MLS environment. If anyone has any further information to dispute or expand this claim I would be very interested in hearing it. D6. 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 (available in US only) 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.0 is available (uses RSA encryption), however there may be licensing issues to be concerned with. D7. 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. (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). D8. 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. D9. Other Possibilities. Depending on your requirements you might look into specialized solutions such as Compartmented Mode Workstations (CMW), end-to-end Data Link Encryption, 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. SECTION E - Security Policy Everything discussed in sections {A...D} 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 sections {A...D} 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, and they can probably lead 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). SUMMARY OF AVAILABILITY Section Name Availability A1 Router Cisco, Wellfleet, Proteon B1 Tcp_wrapper cert.org:/pub/tools/tcp_wrappers B2 Socks e-mail to koblas@netcom.com B3 Kernel_wrap eecs.nwu.edu:/pub/securelib B4 Swatch sierra.stanford.edu:/pub/sources B5 CAP e-mail to thompsond@orvb.saic.com B6 Mail Gateway NOT APPLICABLE B7 Tty_wrapper NOT APPLICABLE C1 COPS cert.org:/pub/tools/cops C2 Chkacct cc.perdue.edu:/pub/chkacctv1.1.tar.Z C3 Crack cert.org:/pub/tools/crack/crack_4.1-tar.Z C4 Shadow comp.sources.misc (jfh@rpp386.cactus.org). C5 Passwd+ dartmouth.edu:/pub/passwd+tar.Z C6 Audit e-mail to bjorn@sysadmin.com C7 Miro e-mail to miro@cs.cmu.edu D1 Key-card e-mail to cert@cert.org D2 TIS/PEM e-mail to pem-info@tis.com D3 Kerberos athena-dist.mit.edu:/pub/kerberos5 D4 Private-key contact Don Davis, at Geer Zolot Assoc. D5 MLS contact your UNIX vendor D6 File encrypt contact your UNIX vendor D7 Programming NOT APPLICABLE D8 Counter-Intel NOT APPLICABLE D9 Other Poss. research and contact various vendors E* Policy RFC 1244 and cert@cert.org Additional Sources of Information Subscribe to the following mailing lists: cert-advisory-request@cert.org cert-tools-request@cert.org Read the following USENET newsgroups: comp.security.announce (echos the CERT advisory mailing list) comp.security.misc alt.security (frequently dissolves into "flame wars") comp.risks comp.virus (almost exclusively for discussing PC and MAC viruses) 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 READ: The SYMPOSIUM PROCEEDINGS of the USENIX Third UNIX Security Symposium (September 14-16, 1992). It is 330+ pages, containing papers describing in better detail a lot of the packages and security techniques I briefly described in this paper. ------------------------SUMMARY OF CHANGES------------------------- Version 2 (10/08/92): Paragraph B2 (Socks) - Correction to e-mail address, submitted by Ed DeHart at CERT. Paragraph C1 (COPS) - Additional Comments and Hints submitted by Dan Farmer, the author of COPS. Paragraph C2 (Chkacct) - Correction to availability, the package is distributed with COPS (versions >= 1.04). Paragraph D1 (KeyCard) - Correction to availability, source code is not in public domain, submitted by Jim Ellis at CERT. ------------------------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, Robert B. Reinhardt. This paper is freely distributable 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 Thu Oct 29 17:08:22 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18873; Thu, 29 Oct 92 17:08:22 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18862; Thu, 29 Oct 92 17:08:17 PST Message-Id: <9210300108.AA18862@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Long posting Date: Thu, 29 Oct 92 17:08:16 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I decided to go ahead and forward Robert Reinhardt's paper to Firewalls, despite its length, because it was relevant and because it was in text format (not PostScript). If you have a problem with that decision, direct your criticisms to me, not to Robert. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Fri Oct 30 05:51:04 1992 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19786; Fri, 30 Oct 92 05:51:04 PST Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19779; Fri, 30 Oct 92 05:50:44 PST Received: from pleiku.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AB08496; Fri, 30 Oct 92 06:48:16 PPE Date: Fri, 30 Oct 92 06:48:16 PPE From: pleiku!kelly@netcom.com Message-Id: <9210301348.AB08496@netcomsv.netcom.com> To: "Robert B. Reinhardt" , GreatCircle.COM!firewalls@netcom.com Subject: MLS etc Content-Type: text Content-Length: 1281 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Well actually I am going to take you on about MLS and Levels C2-B1-... MLS at least for the version I worked on(MLS1.1.2 on SYS5.3.2 on 68040) was fully functional, MLS basically gives you a set of tools to determine and enforce security policy on your host, Dont get me wrong, the interfaces are pretty raw and have room for improvement in many areas. MLS will secure your baseos to a large degree , it will build audits of user actions and trails of data usage, It will not prevent people breaches at the trusted levels, it is vunerable on many levels... and it is considerably tighter than normal UNIX... most security tables are easily coverted to ascii via the filter set supplied edited and then reconverted(it would be a pain to administer a fairly sizable set of users under MLS) I am also looking for MLS routines in PERL for such mundane tasks.. combined with the more public domain tools such as the ones mentioned on this list MLS can indeed be utilized for Firewall design.(I am currently working on such an implementation. BTW your paper was quite good, except for the style in which I am implementing the packet-filtering router, it is very close what I have already been implementing for customers of mine. cheers kelly goen ISS Inc.