From Firewalls-Owner Tue Jun 1 02:04:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19995; Tue, 1 Jun 93 02:04:32 GMT Received: from ns.oar.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19988; Mon, 31 May 93 19:04:18 PDT Received: from valhalla.oar.net for kannan@oar.net by ns.oar.net (5.65c+KVa/920824.1144) id AA15315; Mon, 31 May 1993 22:04:44 -0400 Message-Id: <199306010204.AA15315@ns.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: randy@psg.com (Randy Bush) Cc: avalon@coombs.anu.edu.au (Darren Reed), Firewalls@GreatCircle.COM Reply-To: kannan@oar.net Subject: Re: Ciscos as firewall gates, Part 2 In-Reply-To: Your message of Sat, 29 May 1993 13:55:24 -0700. Date: Mon, 31 May 1993 22:04:35 -0400 From: Kannan Varadhan Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>> From: randy@psg.com (Randy Bush) >>> Date: Sat, 29 May 1993 13:55:24 PDT > > Personally, I prefer filters to drop things `quietly', not giving the > > outsider any clue as to whether the host exists, is down or the packet > > was filtered >:) > > Which, the firewalled sites say, is why they give host unreachable. Which is how those of us who debug connectivity problems recognise the existence of a firewall. Very little else gives back host unreachables gratitously. :-) Kannan From Firewalls-Owner Tue Jun 1 02:11:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20018; Tue, 1 Jun 93 02:11:07 GMT Received: from ns.oar.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20011; Mon, 31 May 93 19:11:00 PDT Received: from valhalla.oar.net for kannan@oar.net by ns.oar.net (5.65c+KVa/920824.1144) id AA15494; Mon, 31 May 1993 22:12:40 -0400 Message-Id: <199306010212.AA15494@ns.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: firewalls@GreatCircle.COM Reply-To: kannan@oar.net Subject: Re: (none) In-Reply-To: Your message of Sat, 29 May 1993 13:33:04 -0400.<9305291733.AA09318@relay2.UU.NET> Date: Mon, 31 May 1993 22:12:30 -0400 From: Kannan Varadhan Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Oh gee! Wonder where this packet's headers got munged with Apparently-To headers...sigh! >>> From: uworld!uucp@uunet.uu.net >>> Date: Sat, 29 May 1993 13:33:04 EDT > Date: Sat, 29 May 93 10:11:07 MST > From: crow!rik (Rik Farrow) > To: uworld!uunet!greatcircle.com!firewalls > Subject: PC filtering solutions > > Ken hardy writes > > > I'd appreciate it if > > anyone could forward a copy of that announcement (or anything related) > > either to me or to the mailing list. > > I had kept a couple of references to PC-based filters taken from the firewalls > list, but had cut of the volume number where they appear. Here are portions > of each posting with contact information: I have never been convinced of a lot of these filtering implementations, because a lot of these implementations filter on the *assumed* *syntax* of the packet, not the *defined* *semantics* of the packet. They assume, for instance, that an IP packet header will always be 20 octets long, and the upper layer protocol headers will follow immediately afterwards. I have never been able to convince myself that one could not construct a legal packet and trace with IP options, that could circumvent such an implementation, which my gut feeling tells me is very possible. This becomes especially crucial when doing TCP, UDP, or higher layer protocol filtering. Comments anyone? Kannan From Firewalls-Owner Tue Jun 1 13:18:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21959; Tue, 1 Jun 93 13:18:21 GMT Received: from sc.tamu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21952; Tue, 1 Jun 93 06:18:12 PDT Received: from posaune.tamu.edu by sc.tamu.edu (AA12494); Tue, 1 Jun 93 08:19:13 CDT Message-Id: <9306011319.AA12494@sc.tamu.edu> Received: by posaune.tamu.edu (NX5.67c/NX3.0X) id AA00698; Tue, 1 Jun 93 08:19:04 -0500 Date: Tue, 1 Jun 93 08:19:04 -0500 From: David-Hess@sc.tamu.edu Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Firewalls@GreatCircle.COM Subject: Re: Firewalls Digest V2 #99 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: Kannan Varadhan [...] > I have never been convinced of a lot of these filtering implementations, > because a lot of these implementations filter on the *assumed* *syntax* > of the packet, not the *defined* *semantics* of the packet. They > assume, for instance, that an IP packet header will always be 20 octets > long, and the upper layer protocol headers will follow immediately > afterwards. > > I have never been able to convince myself that one could not construct a > legal packet and trace with IP options, that could circumvent such an > implementation, which my gut feeling tells me is very possible. > > This becomes especially crucial when doing TCP, UDP, or higher layer > protocol filtering. > > Comments anyone? > > Kannan Drawbridge does check for IP options (to prevent tunnelling) and even IP fragments (so packets don't get mistakenly filtered) on every IP packet that is processed. It certainly didn't do this the first time around, but was quickly added. :-) I don't know how/if other implementations handle it. Dave --- David K. Hess Graduate Assistant David-Hess@tamu.edu Supercomputer Center (409) 845-6907 (work) Texas A&M University From Firewalls-Owner Tue Jun 1 15:05:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22161; Tue, 1 Jun 93 15:05:35 GMT Received: from ariel.ncsl.nist.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22154; Tue, 1 Jun 93 08:05:28 PDT Received: by ariel.ncsl.nist.gov (4.1/NIST) id AA16350; Tue, 1 Jun 93 11:07:08 EDT From: John Wack Posted-Date: Tue, 1 Jun 93 11:07:07 EDT Message-Id: <9306011507.AA16350@ariel.ncsl.nist.gov> Subject: router rumors To: Firewalls@GreatCircle.COM Date: Tue, 1 Jun 93 11:07:07 EDT X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello All, We're going to be buying a new router for a research subnet here and I'd like to try to confirm some rumors I've heard about what CISCO will be offering. We already have a CISCO and, despite some of the negative stuff on this list about CISCOs, I'd prefer to stick with what I know. I have heard that CISCO will be offering in future releases a) ability to log rejected packets to some host, and b) ability to filter on source TCP/UDP port. Can anyone confirm this info? Thanks much, John Wack -- John P. Wack Computer Scientist National Institute of Standards and Technology Technology A-216 Gaithersburg, Md. 20899 301-975-3411 301-948-0279 (Fax) JWack@nist.gov From Firewalls-Owner Tue Jun 1 15:09:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22180; Tue, 1 Jun 93 15:09:25 GMT Received: from norman.li.Cubic.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22173; Tue, 1 Jun 93 08:09:16 PDT Received: by norman.li.Cubic.COM (5.67/1.34a) id AA22109; Tue, 1 Jun 93 11:10:46 -0400 Date: Tue, 1 Jun 93 11:10:46 -0400 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9306011510.AA22109@norman.li.Cubic.COM> To: Firewalls@GreatCircle.COM Subject: Re: (none) Cc: mischler@Cubic.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <199306010212.AA15494@ns.oar.net> Kannan Varadhan writes: > I have never been convinced of a lot of these filtering implementations, > because a lot of these implementations filter on the *assumed* *syntax* > of the packet, not the *defined* *semantics* of the packet. They > assume, for instance, that an IP packet header will always be 20 octets > long, and the upper layer protocol headers will follow immediately > afterwards. Phil Karn's KA9Q package parses and processes all of the IP options before my filtering extension gets hold of the packet, and leaves a pointer to the start of the datagram. The code looks right, but I can't say that I've tested it much. > I have never been able to convince myself that one could not construct a > legal packet and trace with IP options, that could circumvent such an > implementation, which my gut feeling tells me is very possible. The only way to settle this is to test the various implementations and report on them separately (instead of lumping them all in the untrustworthy category). Dave Mischler mischler@cubic.com From Firewalls-Owner Tue Jun 1 15:24:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22255; Tue, 1 Jun 93 15:24:36 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22248; Tue, 1 Jun 93 08:24:19 PDT Message-Id: <9306011524.AA22248@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (16.8/16.2) id AA26501; Wed, 2 Jun 93 01:00:53 +1000 From: Darren Reed Subject: Re: Firewalls Digest V2 #99 To: David-Hess@sc.tamu.edu Date: Wed, 2 Jun 1993 01:00:52 +1000 (EST) Cc: Firewalls@GreatCircle.COM In-Reply-To: <9306011319.AA12494@sc.tamu.edu> from "David-Hess@sc.tamu.edu" at Jun 1, 93 08:19:04 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1252 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > From: Kannan Varadhan > [...] > > I have never been convinced of a lot of these filtering implementations, > > because a lot of these implementations filter on the *assumed* *syntax* > > of the packet, not the *defined* *semantics* of the packet. They > > assume, for instance, that an IP packet header will always be 20 octets > > long, and the upper layer protocol headers will follow immediately > > afterwards. > > > I have never been able to convince myself that one could not construct a > > legal packet and trace with IP options, that could circumvent such an > > implementation, which my gut feeling tells me is very possible. > > > This becomes especially crucial when doing TCP, UDP, or higher layer > > protocol filtering. > > > Comments anyone? > > > Kannan > > Drawbridge does check for IP options (to prevent tunnelling) and even IP > fragments (so packets don't get mistakenly filtered) on every IP packet > that is processed. > > It certainly didn't do this the first time around, but was quickly added. :-) > I don't know how/if other implementations handle it. How else would you handle it other than add the header length (as in the IP header) to 'a pointer' to find the other 'header' fields ? Darren From Firewalls-Owner Tue Jun 1 09:21:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22668; Tue, 1 Jun 93 16:00:27 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22640; Tue, 1 Jun 93 09:00:14 PDT Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA06984; Tue, 1 Jun 93 11:01:51 CDT Date: Tue, 1 Jun 93 11:01:51 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9306011601.AA06984@tadpole.tadpole.com> To: Firewalls@GreatCircle.COM Subject: Re: Firewalls Digest V2 #99 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: David-Hess@sc.tamu.edu > > From: Kannan Varadhan > > > I have never been able to convince myself that one could not construct a > > legal packet and trace with IP options, that could circumvent such an > > implementation, which my gut feeling tells me is very possible. > > Drawbridge does check for IP options (to prevent tunnelling) and even IP > fragments (so packets don't get mistakenly filtered) on every IP packet > that is processed. > > It certainly didn't do this the first time around, but was quickly added. :-) > I don't know how/if other implementations handle it. Any quality implementation of this sort of thing *has* to look at the length of the received datagram, and if this datagram is a fragment of some larger, fragmented datagram. Of course, there is no way to filter fragments (other than the first one) if you want to filter based on the port numbers. In the implementation I wrote (for SunOS, soon Solaris), I just let all but the first frag through, where they are eventually dropped, due to timeouts. Jim From Firewalls-Owner Tue Jun 1 16:27:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22838; Tue, 1 Jun 93 16:27:25 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22831; Tue, 1 Jun 93 09:27:13 PDT Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA07203; Tue, 1 Jun 93 11:28:43 CDT Date: Tue, 1 Jun 93 11:28:43 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9306011628.AA07203@tadpole.tadpole.com> To: brent@GreatCircle.COM, lear@yeager.corp.sgi.com Subject: Re: New file transfer protocol: FSP Cc: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > A clarification on one of Brent's old postings: > > "established" keyword that some routers use for TCP filtering. For > > these reasons, I recommend blocking UDP all together, except for > > specific server-to-server conversations for specific protocols (DNS, > > NTP, maybe RIP, etc.). > > RIP is a broadcast protocol- it should not be allowed in. If you send > a unicast to a machine that is stupid enough to believe its > information, you can effect at least a denial of service attack. Except, of course, in the case of non-broadcast media (point to point links). Even then, if you're using RIP (esp routed) as your routing information mechanism, you deserve what you get. (please route all traffic for executive-net to my machine). Jim From Firewalls-Owner Tue Jun 1 17:33:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23155; Tue, 1 Jun 93 17:33:50 GMT Received: from envoy.wl.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23148; Tue, 1 Jun 93 10:33:41 PDT Received: by envoy.wl.com (5.65/allen-042593); id AA03612; Tue, 1 Jun 1993 13:35:08 -0400 Received: by itchy.research.aa.wl.com (5.65/al042593); id AA06755; Tue, 1 Jun 1993 13:35:07 -0400 Message-Id: <9306011735.AA06755@itchy.research.aa.wl.com> From: Allen Leibowitz X-Organization: Warner-Lambert / Parke-Davis Research X-Phone: +1 313 998-3314; FAX: +1 313 996-1690 To: ken@bridge.COM (Ken Hardy) Cc: firewalls@GreatCircle.COM Subject: Re: Ok, so what is a "Good" filtering router? Date: Tue, 01 Jun 93 13:35:07 +28716 X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Yes, a few weeks ago I recall seeing an announcement of a PC-based > filtering bridge or router that looked interesting. Unfortunately, I'm > now unable to find any trace of that announcement. I'd appreciate it if > anyone could forward a copy of that announcement (or anything related) > either to me or to the mailing list. Another PC-based option previously mentioned on this mailing list is the OSU Karlbridge. One thing it could use is the ability to log (via syslog) accept/rejects: ***** cut here ***** Add Security and Cleanup your network by blocking those unwanted packets with The OSU KarlBridge Version 1.33 (now with full SNMP support and more filters) The OSU KarlBridge is a program, that runs on a 286 or 386 clone. It provides a unique and inexpensive Ethernet to Ethernet bridge that performs sophisticated protocol filtering. The bridge can be configured to filter packets based upon ANY Ethernet protocol such as IP, IPX, DECNET, AppleTalk, and etc. In addition it will filter packets based upon IP address, IP network, IP subnet, and socket. It will also filter packets based upon DECNET address, area, Object number and Object name. Also, AppleTalk packets can be filtered based upon server name, printer name, and/or zone name. Some Examples: You can use OSU KarlBridge as a standard medium performance MAC layer Ethernet to Ethernet bridge with SNMP (MIB II, EtherMIB, BridgeMIB & SNMP MIB). You can assemble your own IBM cloan and use the free software or buy the inexpensive pre-assembled and tested commercial version. You can configure OSU KarlBridge to restrict IP traffic from your public computer labs or dial-in-lines to IP addresses and subnets within your campus or enterprise wide network. This will prohibit unauthenticated access to the your machines and/or the Internet in conformance with RFC 1173). You can configure OSU KarlBridge to keep file servers and printers (Apple, Novell, Banyan, LanManager, etc.) on the same network from interacting with each other in undesirable ways. Join thousands of people worldwide who are using the KarlBridge to relieve some of their networking headaches. The OSU KarlBridge is the most flexible and easily configured bridge you have ever seen! Get a copy, read the README file, run the configuration program on your favorite PC, and let me know what you think. The OSU KarlBridge can be obtained via anonymous ftp from: nisca.acs.ohio-state.edu, 128.146.1.7, in /pub/kbridge. Please send e-mail to kbridge@osu.edu with questions and comments. Doug Karl Senior Computer Specialist The Ohio State University ***** cut here ***** ============================================================================== Mark Walters | Internet: mark@university.offices.ox.ac.uk Micro-Computer Support | JANET: mservmrw@uk.ac.ox.vax University Offices | Compuserve 100010,1511 Wellington Square | Tel: +44 (0)865 270246 Oxford OX1 2JD | FAX: +44 (0)865 270708 ============================================================================== PGP2 public key available on request or by fingering mservmrw@black.ox.ac.uk ============================================================================== From Firewalls-Owner Tue Jun 1 18:43:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23627; Tue, 1 Jun 93 18:43:11 GMT Received: from macsch.com (DRACO.MACSCH.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23620; Tue, 1 Jun 93 11:42:54 PDT Received: from [161.34.1.6] by macsch.com (5.61/SMI-4.1-07) id AA01131; Tue, 1 Jun 93 11:43:56 -0700 Received: from canismajor.is.macsch.com by convex.is.macsch.com (5.64/2.0) id AA25780; Tue, 1 Jun 93 11:34:44 -0700 Received: by canismajor.is.macsch.com (4.1/2.0) id AA07333; Tue, 1 Jun 93 11:43:36 PDT Date: Tue, 1 Jun 93 11:43:36 PDT From: todd@macsch.com (Todd Williams) Message-Id: <9306011843.AA07333@canismajor.is.macsch.com> To: firewalls@GreatCircle.COM Subject: Re: what is a GOOD filtering router? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I think some of us are missing the point here. This discussion has devolved into an apples vs. oranges comparison of CISCOs vs. dual-homed PC's as "firewalls". Some new readers of this list might not realize that a "firewall" isn't necessarily a single piece of hardware, but may rather refer to several routers, subnets, hosts, and other hardware. Marcus J. Ranum's paper "Thinking about Firewalls" is a good place for newbies to get an overview of what *types* of firewalls are common, and this is probably a pre-requisite to the question of "which brand of hardware is better". (unless, of course, certain budgetary and/or available hardware issues prevail) Marcus' paper discusses various types of firewalls, including screening routers, bastion hosts, dual homed gateways, screened host gateways, etc. A CISCO may indeed be a bad choice for a "firewall" if it is the sole hardware component; it may be a good choice if the firewall consists of dual-homed hosts plus one or more routers. Brent, for example, likes to use two routers plus a dual-homed host when he creates firewalls, (but his clients have lots of money). I'm sure somebody will tell us where to get Marcus' paper again...I forget. Todd Williams UNIX Systems Supervisor todd@macsch.com (213) 259-4973 MacNeal-Schwendler Corp. ("MSC"), 815 Colorado Blvd., Los Angeles, CA 90041 "Solaris 2.0 -- It's enough to make you leave the company." -Rob Kolstad From Firewalls-Owner Wed Jun 2 13:23:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26222; Wed, 2 Jun 93 13:23:06 GMT Received: from eros.uknet.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26215; Wed, 2 Jun 93 06:22:55 PDT Received: from micrognosis.co.uk by eros.uknet.ac.uk with UUCP id ; Wed, 2 Jun 1993 14:24:01 +0100 Date: Wed, 2 Jun 93 10:47:01 BST From: Neil Readwin To: firewalls@GreatCircle.COM Subject: Re: what is a GOOD filtering router? Message-Id: <9306021047.aa03043@ladon.micrognosis.co.uk> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I'm sure somebody will tell us where to get Marcus' paper again...I forget. If I am thinking about the right paper then I picked it up from: moink.nmsu.edu fwalls.ps.Z fwalls-slides.ps.Z Again, if I am thinking of the right paper then there are 2 older versions of this at decuac. Other papers that may be of interest to people learning about firewalls: crl.dec.com pub/DEC/CRL/tech-reports/93.10.ps.Z (X across the f/w) decuac.dec.com pub/docs/firewall/firewall.ps pub/docs/firewall/SEAL.ps ftp.sage.usenix.org pub/usenix/security.3/pkt_filtering.ps.Z research.att.com dist/smb/pnet.ext.ps.Z dist/internet_security/gateway.ps dist/internet_security/dragon.ps sc.tamu.edu pub/security/NIS_Paper.ps.Z From Firewalls-Owner Wed Jun 2 13:28:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26245; Wed, 2 Jun 93 13:28:43 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26234; Wed, 2 Jun 93 06:28:20 PDT Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA07204; Wed, 2 Jun 93 09:29:50 -0400 Date: Wed, 2 Jun 93 09:29:50 -0400 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9306021329.AA07204@bedrock.cs.UMD.EDU> To: Firewalls@GreatCircle.COM Subject: Maintaining a firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk * From: Tim Guarnieri * * >> I need an opinion about how important it is to know who's banging on * >> the gate -- regardless of whether they get in or not. * * Hmm. Well, if you don't know that somebody has been banging on the * gate, how will you know to look and see if they got in somehow? Additionally, * if it looks like somebody is trying to get it, you can contact the * administrator of the offending machine and start tracing the connection * attempt(s). Well, with the router/gate going to a dual-homed host set up as a firewall, I'd think that an easy way to check for break-ins would be to have the host very stripped down and tightly configured -- and then just check for changes to that configuration. Changes to binary checksums; setuids on scripts; gaps in the event logging; cron and at entries; directory permissions; new files on the system -- looking for all of the items on this non-exhaustive list can be automated, and flags sent up for exceptions that indicate that someone else has been in the cookie jar. Perhaps my original question wasn't clear; I apologize, and let me rephrase it: I can think of two general ways to manage and maintain a firewall setup. One is to actively monitor the traffic and activity, and attempt to directly intervene when you detect a break in attempt. Another approach I can think of is the set up the firewall host in a way that's fairly static, implement a "deep" backup system where you can definitely restore to any pre-break-in state -- and then, if you detect a break in or other unauthorized change of state to the firewall host, determine what happened and plug the holes after restoring the pre-break-in state. The identity or source of the trouble seems largely irrelevant in the second approach. The first approach casts the network admin as a cop protecting the domain or zone, and the second is more passive. My question is, is one approach any more effective, from a security standpoint, than another? All I want is a working firewall. * Without having a log of rejected packets, you're assuming the Cisco is * "doing the right thing" and that there are no flaws in the filters you * have set. * Actually, I'd think that the Cisco IP ACCOUNTING configuration option would indicate pretty well whether or not the packet filtering was working. * >> If we don't care who knocks, then the installation is trivially easy: we * >> can just set up a Cisco IGS as the Internet interface, and filter * >> the packets coming out of the IGS and into the local network ( managed by * >> the AGS+ ). * * Will the AGS+ have filters on outbound traffic that will transit through * the IGS? Or, are you not going to have any outbound filtering at all? * Not having outbound filtering can be a risky proposition as I mentioned in * a previous posting. * Your previous posting about outbound filters was clear enough; yes, the plan is to filter both ways. I certainly intend to run the filtering logic past the members of this mailing list ;-). * Tim The pointing out of my bad assumptions is appreciated. Richard From Firewalls-Owner Wed Jun 2 22:42:45 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28808; Wed, 2 Jun 93 22:42:45 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28801; Wed, 2 Jun 93 15:42:37 PDT Received: by terminus.cs.umb.edu id AA08047 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 2 Jun 1993 18:44:05 -0400 Date: Wed, 2 Jun 1993 18:44:05 -0400 From: "John B. Brown" Message-Id: <199306022244.AA08047@terminus.cs.umb.edu> To: amoss@cs.huji.ac.il, jbb@cs.umb.edu Subject: Re: Ok, so what is a "Good" filtering router? Cc: dean.r.schrimpf@cis.corp.medtronic.com, firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Amos, lars@spectrum.CMC.COM (Lars Poulsen) writes in <1993May31.061728.23235@spectrum.CMC.COM>: > A 3B2/600G with an MNP network package is an okay little router. It is > not cheap, however. And as far as I know, neither WIN/3B nor the MNP > kit support any kind of packet filtering. What I had in mind was more like a 3b2-400 with scci disk and a few 3-COM ethernet cards. The -400 runs the 32100 chip set, has twelve card slots, and as you say, is built like a Mack truck. The Suns we run have a custom inetd which does our filtering, and hooks into a tftpd that specifically filters the ftp connections. Neither of these are kit items. We're also running tripwire because schools are like that. Shalom, JBB. From Firewalls-Owner Thu Jun 3 07:14:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01631; Thu, 3 Jun 93 07:14:30 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01619; Thu, 3 Jun 93 00:14:24 PDT Message-Id: <9306030714.AA01619@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Best of Firewalls, by topic Date: Thu, 03 Jun 93 00:14:22 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I went through the Firewalls archive and sorted all the interesting messages by topic, into about 30 different files. The sorting certainly isn't perfect, but it's a good place to start for folks looking for past discussions on particular topics. I did this as part of the research for my new Firewalls tutorial. I'll probably update the topic files once every few months. The topic files are in pub/firewalls/topics on FTP.GreatCircle.COM. Here are the current topics: admin ethics ka9q portmaster telebit appletalk filtering karlbridge proxy testing archie fsp morningstar routing unix architecture future netblazer sendmail wais cisco gopher nntp smartcards x commercial hardware ntp software dns ident papers tamu Much of the most interesting stuff is in the "architecture" file; that's where I put all the discussions about the whys and wherefores of building a firewalls. I'm tempted to rename that file "wisdom". -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 Jun 3 00:20:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01402; Thu, 3 Jun 93 06:52:45 GMT Received: from norman.li.Cubic.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01389; Wed, 2 Jun 93 23:52:33 PDT Received: by norman.li.Cubic.COM (5.67/1.34a) id AA25957; Thu, 3 Jun 93 02:54:11 -0359 Date: Thu, 3 Jun 93 02:54:11 -0359 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9306030653.AA25957@norman.li.Cubic.COM> To: Firewalls@GreatCircle.COM Subject: Who uses SMTP 'vrfy'? Cc: mischler@Cubic.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Is there any reason I can't just turn off the 'vrfy' command in sendmail? I don't like the fact that on some systems it provides hostnames for users that only have aliases. Dave Mischler mischler@cubic.com From Firewalls-Owner Thu Jun 3 07:47:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01702; Thu, 3 Jun 93 07:47:49 GMT Received: from grasp1.univ-lyon1.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01695; Thu, 3 Jun 93 00:47:41 PDT Received: by grasp1.univ-lyon1.fr (5.67a8/IDA-1.5f) via Rocad id AA26032; Thu, 3 Jun 1993 09:49:14 +0200 From: Christophe Wolfhugel Message-Id: <199306030749.AA26032@grasp1.univ-lyon1.fr> Subject: Re: Who uses SMTP 'vrfy'? To: mischler@Cubic.COM (Dave Mischler) Date: Thu, 3 Jun 1993 09:49:13 +0100 (MEST) Cc: firewalls@GreatCircle.COM In-Reply-To: <9306030653.AA25957@norman.li.Cubic.COM> from "Dave Mischler" at Jun 3, 93 02:54:11 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 624 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk |Is there any reason I can't just turn off the 'vrfy' command in |sendmail? I don't like the fact that on some systems it provides |hostnames for users that only have aliases. Sendmail 6, currently in beta allows to disable the 'expn' command and to have a real 'vrfy' one, ie which will just indicate whether the address is ok or not, without expanding it. I like beeing able to expan aliases, in many situations it is extremely useful particularly to see if there is a chance the remote postmaster mail is read, to and many other cases ! -- Christophe Wolfhugel | Email: Christophe.Wolfhugel@grasp.insa-lyon.fr From Firewalls-Owner Thu Jun 3 11:44:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02198; Thu, 3 Jun 93 11:44:50 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02191; Thu, 3 Jun 93 04:44:41 PDT Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA18861; Thu, 3 Jun 93 07:09:50 EDT Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA03811; Thu, 3 Jun 93 07:23:53 EDT Date: Thu, 3 Jun 93 07:23:53 EDT From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9306031123.AA03811@s.ecc.engr.uky.edu> To: Firewalls@GreatCircle.COM Subject: Re: Who uses SMTP 'vrfy'? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >Is there any reason I can't just turn off the 'vrfy' command in >sendmail? I don't like the fact that on some systems it provides >hostnames for users that only have aliases. > Well, it's certainly your call to make; no one requires you to make it available. However, it is often an *enormous* conveni- ence to other postmasters who have to try to track down problems in mail delivery. It's also used by tools like netfind. Personally, I rather like it, despite its tendency to give more information than required. --Wes From Firewalls-Owner Thu Jun 3 13:08:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02352; Thu, 3 Jun 93 13:08:46 GMT Received: from sci.sci.ccny.cuny.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02345; Thu, 3 Jun 93 06:08:38 PDT Date: Thu, 3 Jun 93 08:55:22 -0400 From: Dan Schlitt Received: by sci.sci.ccny.cuny.edu (5.61/031893-CCNY Science) id AA20376; Thu, 3 Jun 93 08:55:22 -0400 Message-Id: <9306031255.AA20376@sci.sci.ccny.cuny.edu> To: Firewalls@GreatCircle.COM, morgan@engr.uky.edu Subject: Re: Who uses SMTP 'vrfy'? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I, too, like to have vrfy and expn available on remote hosts for mail problem debugging. However, there is someone out there who beats on my poor little workstation with vrfy requests and I wish they would stop. I guess they choose my host name because it appears in the Path: on news that passes through here. But the only mail that should come to that host (it isn't the one in the headers of this mail) is personal mail to me. There are separate mail hosts for the departments in the school of engineering and the science division. It's almost enough to make me want to turn vrfy off. /dan From Firewalls-Owner Thu Jun 3 16:44:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02718; Thu, 3 Jun 93 16:44:20 GMT Received: from soda.berkeley.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02711; Thu, 3 Jun 93 09:44:11 PDT Received: by soda.berkeley.edu (5.65/KAOS-1) id AA28169; Thu, 3 Jun 93 09:42:26 -0700 Received: from localhost.dis.org by merde.dis.org (4.1/SMI-4.2) id AA20582; Thu, 3 Jun 93 09:44:44 PDT Message-Id: <9306031644.AA20582@merde.dis.org> To: Firewalls@GreatCircle.COM Subject: Re: Best of Firewalls, by topic Phone: (510) 849-2230 Snail-Address: 2560 Bancroft way #51;Berkeley CA 94704-1700 In-Reply-To: Your message of Thu, 03 Jun 1993 00:14:22 -0700. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 03 Jun 1993 09:44:44 -0700 From: Peter shipley Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I went through the Firewalls archive and sorted all the interesting >messages by topic, into about 30 different files. The sorting certainly >isn't perfect, but it's a good place to start for folks looking for >past discussions on particular topics. Brent, do you have any intrest in exporting this data tree with gopher? From Firewalls-Owner Thu Jun 3 17:30:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02796; Thu, 3 Jun 93 17:30:55 GMT Received: from isi.com (hopper.isi.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02789; Thu, 3 Jun 93 10:30:43 PDT Received: by isi.com (5.57/Ultrix3.0-C) id AA08984; Thu, 3 Jun 93 10:29:08 -0700 Received: from corina.universe by chief (4.1/inc/isi-1.6s) id AA19359; Thu, 3 Jun 93 10:33:13 PDT Date: Thu, 3 Jun 93 10:33:13 PDT From: langston@isi.com (Richard Langston x247) Message-Id: <9306031733.AA19359@chief> To: Firewalls@GreatCircle.COM, mischler@Cubic.COM Subject: Re: Who uses SMTP 'vrfy'? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Is there any reason I can't just turn off the 'vrfy' command in >sendmail? I don't like the fact that on some systems it provides >hostnames for users that only have aliases. I use it all the time to debug my own mail systems. It's pretty useful. Also a great way to see if a person's email address is legit without wasting time writing an undeliverable message. If you're running a firewall, what difference does it make that they can get a hostname from your server? No one should be able to get there :-) All my names are published in dns.... Richard Langston (langston@isi.com) (w) 408 980 1500 (h) 415 966 8805 "Life my be sweeter for this, I don't know. Seems like it might be alright.." From Firewalls-Owner Thu Jun 3 11:22:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03042; Thu, 3 Jun 93 17:54:52 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03026; Thu, 3 Jun 93 10:54:02 PDT Message-Id: <9306031754.AA03026@mycroft.GreatCircle.COM> To: Peter shipley Cc: Firewalls@GreatCircle.COM Subject: Re: Best of Firewalls, by topic In-Reply-To: Your message of Thu, 03 Jun 1993 09:44:44 -0700 Date: Thu, 03 Jun 93 10:54:01 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # >I went through the Firewalls archive and sorted all the interesting # >messages by topic, into about 30 different files. The sorting certainly # >isn't perfect, but it's a good place to start for folks looking for # >past discussions on particular topics. # # Brent, do you have any intrest in exporting this data tree with gopher? # I certainly have nothing against the idea. I'll look into it. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Fri Jun 4 03:15:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05046; Fri, 4 Jun 93 03:15:42 GMT Received: from miavax.ir.miami.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05039; Thu, 3 Jun 93 20:15:31 PDT Received: by miavax.ir.miami.edu id AA26255 (5.65b+/IDA-1.4.3.1+ for firewalls@greatcircle.com); Thu, 3 Jun 93 23:15:14 -0400 Message-Id: <9306040315.AA26255@miavax.ir.miami.edu> From: aem@symbi1.symbiosis.ahp.com (a.e.mossberg) Date: Thu, 3 Jun 1993 22:47:18 -0400 Sensitivity: 1 Organization: Symbiosis Corporation, Miami, Florida X-Postal: 8600 North West 41 Street 33166-6202 X-Phone: (305) 597-4110 fax: (305) 597-4002 Reply-To: aem@symbi1.symbiosis.ahp.com X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: firewalls@GreatCircle.COM Subject: re: vrfy Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I vaguely recall a tool for checking the existance of all users on a mailing list which used the vrfy command. aem -- andrew mossberg systems specialist symbiosis corporation (305) 597-4110 fax (305) 597-4002 miami, florida 33166-6202 aem@symbiosis.ahp.com uunet!symbi1!aem SPAN: UMIGW::AEM From Firewalls-Owner Fri Jun 4 14:59:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07076; Fri, 4 Jun 93 14:59:55 GMT Received: from usenix.ORG (usenix-gw.mtxinu.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07069; Fri, 4 Jun 93 07:59:43 PDT Received: by usenix.ORG (4.0/1.29-emg890317) id AA25136; Fri, 4 Jun 93 08:02:21 PDT Date: Fri, 4 Jun 93 08:02:21 PDT From: ellie@usenix.org (Ellie Young) Message-Id: <9306041502.AA25136@usenix.ORG> To: firewalls@GreatCircle.COM Subject: Posting to firewalls list Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent, I was wondering if you think it'd be appropriate to post the LISA Call for Papers to the firewalls list. Ches said it generated a lot of interest when our Security Symp. CFP was posted. If you think so, we would appreciate your posting it. Thanks, Ellie ANNOUNCEMENT/CALL FOR PARTICIPATION 7th USENIX SYSTEMS ADMINISTRATION CONFERENCE (LISA VII) November 1-5, 1993 Marriott Hotel Monterey, California The annual USENIX Systems Administration Conference provides a forum in which system administrators meet to share ideas and ex- periences. A growing success for the past six years, the USENIX Systems Administration Conference is the only conference which focuses specifically on the needs of system administrators. Its scope includes system administrators from sites of all sizes and configurations. TUTORIAL PROGRAM Monday and Tuesday, November 1-2, 1993 The two- day tutorial program at the conference is divided into three tracks with a total of twelve half-day tutorials. Attendees may move between tracks, choosing which sections most interest them. Tutorials offer expert instruction in areas of interest to system administrators, novice through experienced. Topics are expected to include Networking, Programming in Perl, X and the Administra- tor, the Domain Name System, Sendmail, and more. TECHNICAL SESSIONS Wednesday through Friday, November 3-5, 1993 "The Human Aspect of UNIX System Administration" is the theme of the first track of the conference technical sessions. Although papers of a more traditional technical content are also very wel- come, the committee is especially seeking papers on areas such as creating policies and procedures, interacting with management and/or users, or which describe and evaluate methods aimed at im- proved communication with users and/or management. We are in- terested in papers which provide freely available or fully described solutions to existing problems. The second track of the conference technical sessions will be split between presentations on very large installation system ad- ministration and presentations of practical, experience-derived material of special interest to new system administrators. No simple measure defines "large installation." It could be number of hosts, number of users, size of network, amount of on- line storage, or some combination of these. The only certainty is that today's large will be tomorrow's standard. We wish to hear from sites which have unique problems and solutions relating to the management of large installations. We seek proposals for papers, panels, mini-workshops, or similar presentations for this track. We also seek papers, mini-workshops, or panel presentations of pragmatic material from experienced system administrators who wish to share their experiences, hardships and solutions. It is hoped that administrators at all levels can leverage this track to solve specific problems at their site. VENDOR DISPLAY Wednesday, November 3, 1993, 3:00 pm - 9:00 pm Well informed vendor representatives will demonstrate products and services useful to systems and network administration at the informal table-top display accompanying the USENIX Systems Ad- ministration Conference. If your company would like to partici- pate, please contact Cynthia Deno at +1 (408) 335-9445; FAX +1 (408) 335-2163; E-mail: cynthia@usenix.org CONFERENCE TOPICS The technical sessions program will include invited talks, panels, Works-In-Progress (WIP) reports, and Birds- Of-a-Feather (BOF) sessions, alongside the refereed paper presentations. The program committee invites you to submit informal proposals, ideas, or suggestions, for the various presentation formats, on any of the following or related topics: % Implementation, usage, and strategies for Policies and Pro- cedures % Effects of improved communication with users and/or management. % Tricks in user education %How to develop Junior System Administrators % System Security Monitoring % Security issues, especially where multiple people are privileged users % Heterogeneous system administration %Human issues of administra- tion % Graphical User Interfaces for system administration % Distributed system administration % Network growth and performance management % Network management % Network monitoring % Wireless LANs % Evaluating performance of high-end workstations and servers % Integration of heterogeneous systems % Usage monitoring and accounting systems % Administration of remote sites REFEREED PAPER SUBMISSIONS The committee requires that an extended abstract be submitted for the paper selection process. (Full-papers are not acceptable for this stage; if you send a full paper, you must also include an extended abstract for evaluation.) Your extended abstract should consist of a tradi- tional abstract which summarizes the content/ideas of the entire paper, followed by a skeletal outline of the full paper. We re- quire electronic (nroff/troff, TeX or ASCII) submission of the extended abstract. Authors of an accepted paper will present their paper and provide a final paper for publication in the Conference Proceedings. Fi- nal papers are limited to 20 pages, including diagrams, figures and appendix. Papers should include a brief description of the site (if applicable), an outline of the problem and issues, and details of the solution. Authors may provide electronic versions or camera-ready copy (instructions will be provided upon request) of final papers. Conference proceedings will be distributed to all conference attendees and will also be available from the USENIX Association after the conference. ADDRESS FOR SUBMISSIONS For submission of all proposals and of extended abstracts of refereed papers, and for program Informa- tion, contact: Program Chair: Bjorn Satdeva /sys/admin, Inc. 2787 Moorpark Avenue San Jose, CA 95128 +1 (408) 241-3111 E-mail: bjorn@sysadmin.com CONFERENCE COMMITTEE Program Chair: Bjorn Satdeva, /sys/admin, Inc. Brent Chapman, Great Circle Associates Lee Damon, Castle PAUS Tina M. Darmohray, Lawrence Livermore National Labs Janet Frazer, UNIX System Laboratories, Inc. Helen Harrison, SAS Institute Dinah McNutt, Tivoli Systems Bryan McDonald, SRI International Arch Mott, Cisco Systems, Inc. Paul Moriarty, Cisco Systems, Inc. Jeff Polk, Berkeley Software Design, Inc. Greg Rose, Australian Computing and Communications Institute Peg Schafer, Bolt Beranek & Newman, Inc. Steve Simmons, Industrial Technology Institute Liza Y. Weissler, RAND Corporation Pat Wilson, Dartmouth College Elizabeth Zwicky, SRI International IMPORTANT DATES DATES FOR REFEREED PAPER SUBMISSIONS Extended Abstract Submission Deadline: July 2, 1993 Notification to Authors: July 23, 1993 Final Papers Receipt Deadline: Sept 7, 1993 Registration Materials Available: August, 1993 FOR REGISTRATION INFORMATION Materials containing all details of the symposium program, symposium registration fees and forms, and hotel discount and reservation information will be mailed and posted to the net beginning August 1993. If you wish to receive registration materials, please contact: USENIX Conference Office 22672 Lambert Street, Suite 613 Lake Forest, CA 92630 USA +1 (714) 588-8649; FAX: +1 (714) 588-9706 E-mail: conference@usenix.org From Firewalls-Owner Sat Jun 5 01:12:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08901; Sat, 5 Jun 93 01:12:44 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08894; Fri, 4 Jun 93 18:12:34 PDT Message-Id: <9306050112.AA08894@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (16.8/16.2) id AA16424; Sat, 5 Jun 93 11:13:59 +1000 From: Mark Subject: Re: vrfy To: aem@symbi1.symbiosis.ahp.com Date: Sat, 5 Jun 1993 11:13:59 +1000 (EST) Cc: firewalls@GreatCircle.COM In-Reply-To: <9306040315.AA26255@miavax.ir.miami.edu> from "a.e.mossberg" at Jun 3, 93 10:47:18 pm Reply-To: mark@cheops.anu.edu.au X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 377 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I vaguely recall a tool for checking the existance of all users >on a mailing list which used the vrfy command. It's called 'telnet'. telnet host 25 vrfy mailing-list quit There is also addrcheck.shar on coombs.anu.edu.au /pub/perl/scripts which does address verification as well. That and the other scripts in the archive might prove useful. Mark mark@coombs.anu.edu.au From Firewalls-Owner Sat Jun 5 02:35:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09090; Sat, 5 Jun 93 02:35:41 GMT Received: from crl.dec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09082; Fri, 4 Jun 93 19:35:34 PDT Received: by crl.dec.com; id AA12992; Fri, 4 Jun 93 22:37:12 -0400 Received: by easynet.crl.dec.com; id AA20272; Fri, 4 Jun 93 22:37:11 -0400 Message-Id: <9306050237.AA13983@aqaba.crl.dec.com> To: firewalls@GreatCircle.COM Subject: xforward release Date: Fri, 04 Jun 93 22:37:10 +28716 From: treese@crl.dec.com X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk xforward, a program for relaying X11 traffic across network boundaries, is now available for anonyomous FTP from crl.dec.com:/pub/DEC/xforward.tar.Z. The design and implementation of xforward are described in Treese, G. Winfield and Alec Wolman X Through the Firewall, and Other Application Relays Proceedings of the USENIX Summer Conference, June, 1993 A preprint of this paper is available as technical report 93/10 from the Cambridge Research Lab of Digital Equipment Corporation, which can be obtained by anonymous FTP from crl.dec.com:/pub/DEC/CRL/tech-reports/93.10.ps.Z, or by sending an electronic mail message with the word "help" in the body to techreports@crl.dec.com. See the file NOTICE in the distribution for distribution information. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp. From Firewalls-Owner Sat Jun 5 22:34:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10988; Sat, 5 Jun 93 22:34:03 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10981; Sat, 5 Jun 93 15:33:56 PDT Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA08939 (5.65c/IDA-1.4.4 for ); Sat, 5 Jun 1993 18:35:10 -0400 Message-Id: <199306052235.AA08939@cs.umb.edu> To: aem@symbi1.symbiosis.ahp.com Cc: firewalls@GreatCircle.COM Subject: Re: vrfy In-Reply-To: Your message of "Thu, 03 Jun 1993 22:47:18 EDT." <9306040315.AA26255@miavax.ir.miami.edu> Date: Sat, 05 Jun 1993 18:35:09 -0400 From: "John P. Rouillard" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9306040315.AA26255@miavax.ir.miami.edu>, a.e.mossberg writes: > I vaguely recall a tool for checking the existance of all users > on a mailing list which used the vrfy command. One such tools is called expn, written in perl, and was on comp.sources.reviewed around 18 May. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 Consulting Systems Programmer Siemens-Nixdorf USA rouilj@sni-usa.com Burlington, MA, (617) 273-2687 x-3498 =============================================================================== My employers don't acknowledge my existence much less my opinions. From Firewalls-Owner Sun Jun 6 14:20:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13654; Sun, 6 Jun 93 21:07:54 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13645; Sun, 6 Jun 93 14:07:49 PDT Message-Id: <9306062107.AA13645@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Firewalls BOF at Summer USENIX Conference Date: Sun, 06 Jun 93 14:07:46 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The Firewalls BOF at the Summer USENIX Conference (scheduled for June 21-25 in Cincinatti, Ohio) will be at 10-11pm on Thursday, June 24, immediately after the CERT BOF. -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 Jun 7 07:04:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15569; Mon, 7 Jun 93 07:04:07 GMT Received: from grasp1.univ-lyon1.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15562; Mon, 7 Jun 93 00:03:55 PDT Received: by grasp1.univ-lyon1.fr (5.67a8/IDA-1.5f) via Rocad id AA10843; Mon, 7 Jun 1993 08:57:20 +0200 Date: Mon, 7 Jun 1993 08:57:20 +0200 From: Christophe Wolfhugel Message-Id: <199306070657.AA10843@grasp1.univ-lyon1.fr> To: firewalls@GreatCircle.COM Subject: Best of Firewalls: Gopher and European access Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The best of is mirrored daily on my node and can be retrieved: anonymous ftp to grasp.insa-lyon.fr pub/doc/english/security/firewalls-topics/ using the ftpmail@grasp.insa-lyon.fr server (same location, send help for instructions) or any ftpmail server closer to your site. gopher server gopher.univ-lyon1.fr Documentation/Firewalls Mailing List (Best Of)/ -- Chris From Firewalls-Owner Mon Jun 7 07:57:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15635; Mon, 7 Jun 93 07:57:18 GMT Received: from elvis.ft.dep.no by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15628; Mon, 7 Jun 93 00:57:11 PDT Message-Id: <9306070757.AA15628@mycroft.GreatCircle.COM> Received: from ft.dep.no by elvis.ft.dep.no id <13945-0@elvis.ft.dep.no>; Mon, 7 Jun 1993 09:59:27 +0000 To: Firewalls@GreatCircle.COM Subject: Crypto boxes Date: Mon, 7 Jun 1993 09:59:27 +0000 From: Erik Jensen Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello Does anybody know if there exists some kind of crypto device that can be put on a ethernet segment between two routers/bridges, without slowing down the traffic too much? Erik Jensen Gov. Admin. Services Oslo, Norway From Firewalls-Owner Mon Jun 7 10:35:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16024; Mon, 7 Jun 93 10:35:26 GMT Received: from pentagon-gw.army.mil ([26.26.0.247]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16017; Mon, 7 Jun 93 03:35:17 PDT Received: by pentagon-gw.army.mil (4.1/SMI-DDN) id AA04418; Mon, 7 Jun 93 06:39:42 EDT Date: Mon, 7 Jun 93 06:39:42 EDT From: Mark Le Vea Message-Id: <9306071039.AA04418@pentagon-gw.army.mil> To: Firewalls@GreatCircle.COM Subject: Re: Crypto boxes Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm using Xerox Encryption Units (XEUs). Talk to a salesdweeb and you'll get the answer: It'll do line speed..... Well, actually you can't expect more than 6Mbit/sec..... But really you might see 1.8Mbit/sec..... or less. These critters actually, in a real environment, single host mode, between 2 Cisco routers, seem to pass 2 Megabytes of IP data per minute between Suns. A regular sloth it the world of high speed data transfer. IMHO Then there's the Motorola solution. They claim .5Mbit/sec through a network wide device. They also have a new box out, but I don't have any specs. Sprint has offered to incorporate an encryption device into their ATM switch .....for a price. Mark From Firewalls-Owner Mon Jun 7 12:19:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16161; Mon, 7 Jun 93 12:19:39 GMT Received: from ll.mit.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16154; Mon, 7 Jun 93 05:19:29 PDT Received: by ll.mit.edu (4.1/LL-1.3) id AA01261; Mon, 7 Jun 93 08:16:22 EDT Date: Mon, 7 Jun 93 08:16:20 -0400 From: Claire Durocher Message-Id: <9306070816.AA03815@LL.MIT.EDU> To: Erik.Jensen@ft.dep.no, Firewalls@GreatCircle.COM Subject: Crypto boxes Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Check with Semaphore Communications Corp in Santa Clara, California. Telephone Number (408) 980-7767. They claim their enrcyption boxes can support full ethernet speeds using public key and DES encryption. If you're not US Govt or businesses overseas, I don't know whether your're eligible for American products using DES or RSA encryption. Claire Durocher MIT Lincoln Laboratory ============================================ Hello Does anybody know if there exists some kind of crypto device that can be put on a ethernet segment between two routers/bridges, without slowing down the traffic too much? Erik Jensen Gov. Admin. Services Oslo, Norway From Firewalls-Owner Mon Jun 7 13:50:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16301; Mon, 7 Jun 93 13:50:57 GMT Received: from cadillac.meteo.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16285; Mon, 7 Jun 93 06:50:47 PDT Received: from zinder.meteo.fr by cadillac.meteo.fr with SMTP id AA26715 (5.65c/IDA-1.4.4 for ); Mon, 7 Jun 1993 13:53:55 GMT Received: by zinder.meteo.fr (4.1/SMI-4.1) id AA14597; Mon, 7 Jun 93 15:53:37 +0100 From: Remy.Giraud@meteo.fr (Remy Giraud) Message-Id: <9306071453.AA14597@zinder.meteo.fr> Subject: screend on SCO Unix ? To: firewalls@GreatCircle.COM Date: Mon, 7 Jun 93 15:53:37 BST X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, We are interested by installing the screend software on a PC with SCO Unix. Is that possible ? Does anyone have experience with this ? Thanks Remy -- +------------------------------------------------------------+ | | | Remy GIRAUD | | METEO FRANCE Tel : 33 61 07 81 14 | | 42 Avenue G.Coriolis Fax : 33 61 07 81 09 | | 31057 Toulouse Cedex Email : Remy.Giraud@meteo.fr | | France | | | +------------------------------------------------------------+ From Firewalls-Owner Mon Jun 7 15:04:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16466; Mon, 7 Jun 93 15:04:21 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16459; Mon, 7 Jun 93 08:04:14 PDT Received: by mail-relay-2.mv.us.adobe.com; id AA07902; Mon, 7 Jun 93 08:06:03 -0700 Received: by mumble.mv.us.adobe.com; id AA00369; Mon, 7 Jun 93 08:06:00 -0700 Message-Id: <9306071506.AA00369@mumble.mv.us.adobe.com> To: firewalls@GreatCircle.COM Subject: Re: screend on SCO Unix ? In-Reply-To: Your message of "Mon, 07 Jun 93 15:53:37 BST." <9306071453.AA14597@zinder.meteo.fr> Date: Mon, 07 Jun 93 08:05:54 -0700 From: Tim Guarnieri X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk As far as I know, screend is only offered on Ultrix. Paul Vixie & I recently finished porting screend to BSD/386 1.0 and are working to get the changes put out on gatekeeper.dec.com in some form. I don't know of anyone that has ported it to SCO Unix. You can get the screend.tar.Z file from gatekeeper.dec.com and try doing the port yourself, if you have the energy and desire... :-). Tim -------- Hi, We are interested by installing the screend software on a PC with SCO Unix. Is that possible ? Does anyone have experience with this ? Thanks Remy -- +------------------------------------------------------------+ | | | Remy GIRAUD | | METEO FRANCE Tel : 33 61 07 81 14 | | 42 Avenue G.Coriolis Fax : 33 61 07 81 09 | | 31057 Toulouse Cedex Email : Remy.Giraud@meteo.fr | | France | | | +------------------------------------------------------------+ -------- From Firewalls-Owner Mon Jun 7 16:19:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16626; Mon, 7 Jun 93 16:19:43 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16618; Mon, 7 Jun 93 09:19:12 PDT Message-Id: <9306071619.AA16618@mycroft.GreatCircle.COM> To: Christophe Wolfhugel Cc: firewalls@GreatCircle.COM Subject: Re: Best of Firewalls: Gopher and European access In-Reply-To: Your message of Mon, 7 Jun 1993 08:57:20 +0200 Date: Mon, 07 Jun 93 09:19:11 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # The best of is mirrored daily on my node and can be retrieved: # # anonymous ftp to grasp.insa-lyon.fr # pub/doc/english/security/firewalls-topics/ # # using the ftpmail@grasp.insa-lyon.fr server (same location, send help for # instructions) or any ftpmail server closer to your site. # # gopher server gopher.univ-lyon1.fr # Documentation/Firewalls Mailing List (Best Of)/ # # -- Chris Fantastic! Thanks! -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Jun 7 17:31:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17152; Mon, 7 Jun 93 17:31:40 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17142; Mon, 7 Jun 93 10:31:34 PDT Message-Id: <9306071731.AA17142@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Who is gatewaying Firewalls into the info.firewalls newsgroup? Date: Mon, 07 Jun 93 10:31:33 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Would the site that's gatewaying the Firewalls mailing list into an info.firewalls newsgroup that's being redistributed, please contact me? I don't really mind (as long as the the gateway works, and as long as the newsgroup is treated as "moderated" so that replies come back to the main mailing list rather than only to the newsgroup), but I wish you would have told me before you did it. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Jun 7 19:35:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17942; Mon, 7 Jun 93 19:35:06 GMT Received: from ocfmail.ocf.llnl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17933; Mon, 7 Jun 93 12:34:51 PDT Received: from [134.9.250.226] (nessett.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA25651; Mon, 7 Jun 93 12:36:19 PDT Message-Id: <9306071936.AA25651@ocfmail.ocf.llnl.gov> Date: Mon, 7 Jun 1993 12:37:14 -0800 To: ietf-announce@ietf.cnri.reston.va.us, Firewalls@GreatCircle.COM, RISKS-Request@csl.sri.com, ;@internauts.mitre.org, isoc-interest@relay.sgi.com From: nessett@ocfmail.ocf.llnl.gov (Dan Nessett) X-Sender: nessett@ocfmail.llnl.gov Subject: 2nd Call for Papers - ISOC Symp. on Net. and Dist. Sys. Security Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security 3-4 February 1994, Catamaran Hotel, San Diego, California The symposium will bring together people who are building software and hardware to provide network or distributed system security services. The symposium is intended for those interested in practical aspects of network and distributed system security, rather than in theory. Symposium proceedings will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: * Design and implementation of services--access control, authentication, availability, confidentiality, integrity, and non-repudiation --including criteria for placing services at particular protocol layers. * Design and implementation of security mechanisms and support services--encipherment and key management systems, authorization and audit systems, and intrusion detection systems. * Requirements and architectures for distributed applications and network functions--message handling, file transport, remote file access, directories, time synchronization, interactive sessions, remote data base management and access, routing, voice and video multicast and conferencing, news groups, network management, boot services, mobile computing, and remote I/O. * Special issues and problems in security architecture, such as -- very large systems like the international Internet, and -- high-speed systems like the gigabit testbeds now being built. * Interplay between security goals and other goals--efficiency, reliability, interoperability, resource sharing, and low cost. GENERAL CHAIR: Dan Nessett, Lawrence Livermore National Laboratory PROGRAM CHAIRS: Russ Housley, Xerox Special Information Systems Rob Shirey, The MITRE Corporation PROGRAM COMMITTEE: Dave Balenson, Trusted Information Systems Tom Berson, Anagram Laboratories Matt Bishop, Dartmouth College Ed Cain, U.S. Defense Information Systems Agency Jim Ellis, CERT Coordination Center Steve Kent, Bolt, Beranek and Newman John Linn, Geer Zolot Associates Clifford Neuman, Information Sciences Institute Michael Roe, Cambridge University Rob Rosenthal, U.S. National Institute of Standards and Technology Jeff Schiller, Massachusetts Institute of Technology Ravi Sandhu, George Mason University Peter Yee, U.S. National Aeronautics and Space Administration SUBMISSIONS: The committee seeks both original technical papers and proposals for panel discussions on technical and other topics of general interest. Technical papers should be 10-20 pages in length. Panels should include three or four speakers. A panel proposal must name the panel chair, include a one-page topic introduction authored by the chair, and also include one-page position summaries authored by each speaker Both the technical papers and the panel papers will appear in the proceedings. Submissions must be made by 16 August 1993. Submissions should be made via electronic mail to 1994symposium@smiley.mitre.org. Submissions may be in either of two formats: ASCII or PostScript. If the committee is unable to read a PostScript submission, it will be returned and ASCII requested. Therefore, PostScript submissions should arrive well before 16 August. If electronic submission is absolutely impossible, submissions should be sent via postal mail to Robert W. Shirey, Mail Stop Z202 The MITRE Corporation McLean, Virginia 22102-3481 USA All submissions must include both an Internet electronic mail address and a postal address. Each submission will be acknowledged through the medium by which it is received. If acknowledgment is not received within seven days, please contact either Rob Shirey or Russ Housley , or telephone Mana Weigand at MITRE in Mclean, 703-883-5397. Authors and panelists will be notified of acceptance by 15 October 1993. Instructions for preparing camera-ready copy for the proceedings will be postal mailed at that time. The camera-ready copy must be received by 15 November 1993. From Firewalls-Owner Mon Jun 7 20:12:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18172; Mon, 7 Jun 93 20:12:16 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18164; Mon, 7 Jun 93 13:12:08 PDT Message-Id: <9306072012.AA18164@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Firewalls archives via Gopher Date: Mon, 07 Jun 93 13:12:06 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Thanks to Bill Manning and Prentiss Riddle of Rice University, there is now an interim Gopher server (until I have time to set up a Gopher server here at GreatCircle.COM) for the Firewalls archives. Thanks, folks! -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 ------- Forwarded Message From: riddle@is.rice.edu (Prentiss Riddle) Message-Id: <9306071922.AA03376@brazos.is.rice.edu> Subject: Re: Best of Firewalls, by topic To: brent@GreatCircle.COM (Brent Chapman) Date: Mon, 7 Jun 93 14:22:46 CDT In-Reply-To: <9306071845.AA17752@mycroft.GreatCircle.COM>; from "Brent Chapman" at Jun 7, 93 11:45 am X-Mailer: ELM [version 2.3 PL11] > From brent@greatcircle.com Mon Jun 7 13:47:45 1993 > To: riddle@is.rice.edu (Prentiss Riddle) > Subject: Re: Best of Firewalls, by topic > From: Brent Chapman > > # A link like this could also go on a Gopher server somewhere (like here > # at Rice, for instance). > > That's the key, I think: getting the pointer into the Gopher > "universe", so that people can find the data when they want it. Okay: I've put a link on our server. Users can do this: gopher to riceinfo.rice.edu port 70 select "Information by Subject Area" select "Computer Networks and Internet Resource Guides" select "Firewalls mailing list archive (from ftp.greatcircle.com)" From Firewalls-Owner Mon Jun 7 13:52:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18328; Mon, 7 Jun 93 20:23:22 GMT Received: from tigger.jvnc.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18321; Mon, 7 Jun 93 13:23:13 PDT Received: by tigger.jvnc.net id AA17986 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 7 Jun 1993 16:25:01 -0400 Date: Mon, 7 Jun 1993 16:25:01 -0400 From: Moodys Investors Service Message-Id: <199306072025.AA17986@tigger.jvnc.net> To: firewalls@GreatCircle.COM Subject: tcpr Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk OK! this is my first one... (was I surprised- but getting large amounts of mail that isn't purely negative because I forgot to edit the header or something in posting is a real treat. Well you can flame me if you want; I'm used to it) tcpr, if you don't know is a perl gateway relay for those who need some sort of transparency and don't want user logins on their gateway. It needs wrapper or secure libs to run or else it defeats the purpose. First problem: There is neat code to use links to determine what you want your client to do, but it does not work. I added these comments to pclient which makes it pftp only #if ($0 eq "pftp") { $Application = $Service = 'ftp'; #} elsif ($0 eq "ptelnet") { # $Application = $Service = 'telnet'; #} else { # print "$0 Second problem: tcprelay seems to be the work horse but outputs this # pftp bandon Connecting to relay server bandon ... Requesting relay ... 230-server[bandon] 230-service[ftp] 230-syntax error in file /usr/etc/tcprelay at line 158, next 2 tokens ")[" 230-syntax error in file /usr/etc/tcprelay at line 195, next 2 tokens ", S" 230-syntax error in file /usr/etc/tcprelay at line 198, next 2 tokens ", C" 230-syntax error in file /usr/etc/tcprelay at line 239, next 2 tokens ")[" 230-syntax error in file /usr/etc/tcprelay at line 352, next 2 tokens "waitpid(" 230-syntax error in file /usr/etc/tcprelay at line 355, next token "}" 230-syntax error in file /usr/etc/tcprelay at line 377, next token "}" 230-syntax error in file /usr/etc/tcprelay at line 382, next token "}" 230-syntax error in file /usr/etc/tcprelay at line 433, next token "}" 230-Execution aborted due to compilation errors. 550 relay failed Error, closing connection I showed the whole shebango but tcprelay run alone has the same problem. So why am I burdening you with this? It seems to be a well thought out application and is well documented and I figure it may become popular. If you know of any other relays ( really ip_forwarders ) I'd be glad to alpha test. Yours- John van Vlaanderen aka moodys@tigger.jvnc.net From Firewalls-Owner Mon Jun 7 21:48:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18573; Mon, 7 Jun 93 21:48:36 GMT Received: from netcom3.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18566; Mon, 7 Jun 93 14:48:29 PDT Received: by netcom3.netcom.com (5.65/SMI-4.1/Netcom) id AA11605; Mon, 7 Jun 93 14:50:56 -0700 Date: Mon, 7 Jun 93 14:50:56 -0700 From: pascal@netcom.com (Richard Childers) Message-Id: <9306072150.AA11605@netcom3.netcom.com> To: Firewalls@GreatCircle.COM Subject: encrypting traffic Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "From: Erik Jensen Date: Mon, 7 Jun 1993 09:59:27 +0000 Subject: Crypto boxes Does anybody know if there exists some kind of crypto device that can be put on a ethernet segment between two routers/bridges, without slowing down the traffic too much? Erik Jensen Gov. Admin. Services Oslo, Norway" I would look at hardware available from Network Equipment Technologies, of Redwood City, CA. As of a few years ago, when I was administering their workstation and server empire and administering the WAN, encrypting proprietary cor- -porate traffic over T1 channels was their bread and butter. ( I have no financial interest in NET. ) -- richard The silliest thing I ever read, richard childers, pascal@netcom.com Was someone saying "God is dead." The simple use of The Word Negates the second, and the third. ( Duke Ellington, _Sacred Concert_ ) From Firewalls-Owner Tue Jun 8 08:22:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20466; Tue, 8 Jun 93 08:22:31 GMT Received: from gw.alantec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20459; Tue, 8 Jun 93 01:22:21 PDT Received: from alantec.alantec.com by gw.alantec.com with SMTP id AA03387 (5.65b/IDA-1.4.3.7 for firewalls@greatcircle.com); Tue, 8 Jun 93 01:23:39 -0700 Received: by alantec.alantec.com id AA06501 (5.65b/IDA-1.4.3.7 for firewalls@greatcircle.com); Tue, 8 Jun 93 01:23:35 -0700 Date: Tue, 8 Jun 93 01:23:35 -0700 From: "G. Paul Ziemba" Message-Id: <9306080823.AA06501@alantec.alantec.com> To: firewalls@GreatCircle.COM Subject: Re: tcpr Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: moodys@tigger.jvnc.net (Moodys Investors Service) > Subject: tcpr To paraphrase a comment I saw on the net the other week (sorry, I don't remember who said it), "My car doesn't work. What's wrong with it?" > There is neat code to use links to determine what you want your > client to do, but it does not work. Sheesh. Folks, if you encounter problems with free software, please consider giving _details_ about your system setup so that the rest of us (or the developer) can have more than a snowball's chance in hell of diagnosing the problem. For all I know, this guy is using RSTS on a pdp-11. CPU: (sun, hp, intel, mips, ... ?) OS: (ms-dos, unix, vms, cms, cp/m?) Perl version: tcpr version: Thanks. We now return you to the regularly-scheduled program(me)... ~!paul From Firewalls-Owner Tue Jun 8 09:53:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21942; Tue, 8 Jun 93 16:33:16 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21934; Tue, 8 Jun 93 09:33:11 PDT Message-Id: <9306081633.AA21934@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Firewalls and newsgroups Date: Tue, 08 Jun 93 09:33:10 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk My posting yesterday asking whoever is gatewaying the Firewalls mailing list into a distributed "info.firewalls" newsgroup has apparently caused some confusion for many Firewalls subscribers who dump Firewalls into a local newsgroup. Folks, I don't care what you do with Firewalls at your site as long as: 1) it only affects your site (it's not distributed) and 2) it doesn't send bogus administrivia back to me (things like news complaints about "more included than original text" or "missing subject line"). >From the reports I've been hearing, though, somewhere out there some site has created an "info.firewalls" newsgroup, and is distributing it (I don't know how widely) over the Internet. I'm not necessarily opposed to this, but I'd like to know who's doing it (so that I know who to talk to when it breaks), and I'd like to have some confidence that it's being done "right" (i.e., that messages posted to the newsgroup make their way back here for distribution to the mailing list, preferably before they appear in the newsgroup). -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Tue Jun 8 18:09:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23094; Tue, 8 Jun 93 18:09:05 GMT Received: from firewall.mc.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23087; Tue, 8 Jun 93 11:08:53 PDT Received: from jericho.mc.com by firewall.mc.com with SMTP id AA01648 (5.65c/IDA-1.4.4 for ); Tue, 8 Jun 1993 14:10:24 -0400 Received: from darkstar by jericho.mc.com (4.1/1.34/indent-1.0) id AA20883; Tue, 8 Jun 93 14:10:23 EDT From: blu@jericho.mc.com (Brian Utterback) Received: by darkstar (4.1//ident-1.0) id AA12265; Tue, 8 Jun 93 14:10:21 EDT Date: Tue, 8 Jun 93 14:10:21 EDT Message-Id: <9306081810.AA12265@darkstar> To: firewalls@GreatCircle.COM Subject: Re: Best of Firewalls: Gopher and European access Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Okay, now what are the chances of getting a keyword search of the archives? The gopher server is great, but we need a way to relate topics to digests. For instance, I just got a message from the list that had comments about tcpr. Now, based on those comments, I might like to get tcpr. Since I currently save the firewall list, I just grep for tcpr. But on the gopher server, my choices are to try to guess the topic, (I guessed software, but that was not it.) or download the entire archive. Of course, I am glad to have the option. Hope this didn't sound like a Longines commercial. (I was hoping for a Longines). Brian Utterback blu@mc.com Manager Technical Networks Mercury Computer Systems, Inc. (508) 256-1300x168 199 Riverneck Road (508) 256-3599 FAX Chelmsford, MA 01824 Always mount a scratch monkey. From Firewalls-Owner Tue Jun 8 18:44:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23320; Tue, 8 Jun 93 18:44:18 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23306; Tue, 8 Jun 93 11:42:36 PDT Message-Id: <9306081842.AA23306@mycroft.GreatCircle.COM> To: blu@jericho.mc.com (Brian Utterback) Cc: firewalls@GreatCircle.COM Subject: Re: Best of Firewalls: Gopher and European access In-Reply-To: Your message of Tue, 8 Jun 93 14:10:21 EDT Date: Tue, 08 Jun 93 11:42:34 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # Okay, now what are the chances of getting a keyword search of the archives? # # The gopher server is great, but we need a way to relate topics to digests. # For instance, I just got a message from the list that had comments about tcpr. # Now, based on those comments, I might like to get tcpr. Since I currently save # the firewall list, I just grep for tcpr. But on the gopher server, my choices # are to try to guess the topic, (I guessed software, but that was not it.) or # download the entire archive. # # Of course, I am glad to have the option. # # Hope this didn't sound like a Longines commercial. (I was hoping for a # Longines). # # Brian Utterback blu@mc.com Manager Technical Networks # Mercury Computer Systems, Inc. (508) 256-1300x168 # 199 Riverneck Road (508) 256-3599 FAX # Chelmsford, MA 01824 Always mount a scratch monkey. # I'm working on proper Gopher and WAIS access to the Firewalls archive, but it may be a while before I get it in place (then again, it may not; it depends on my schedule). The folks at Rice University and elsewhere have set up the basic Gopher/FTP gateway to the "topic" files as an interim service, for which I thank them. -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 Jun 9 14:04:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26765; Wed, 9 Jun 93 14:04:13 GMT Received: from tigger.jvnc.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26758; Wed, 9 Jun 93 07:04:07 PDT Received: by tigger.jvnc.net id AA06226 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Wed, 9 Jun 1993 10:05:57 -0400 Date: Wed, 9 Jun 1993 10:05:57 -0400 From: Moodys Investors Service Message-Id: <199306091405.AA06226@tigger.jvnc.net> To: Firewalls@GreatCircle.COM Subject: info.firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > ...created an "info.firewalls" newsgroup, and is distributing it (I don't know how widely) over the Internet. I'm not necessarily opposed to this... I like the idea of a mailing list because the technology being developed here is so sensitive that we need to be able to know who is involved. The usenet is extreamly wide and is growing at an ever increasing pace. Since I started installing interop equip two years ago I believe ( from a NY Times article ) that our community has grown several fold. At least we're in the right business for a recession. I found out about this group by archie-ing for anything named firewalls or gateways, which was easy enough. -John van Vlaanderen aka moodys@tigger.jvnc.net From Firewalls-Owner Wed Jun 9 15:21:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26956; Wed, 9 Jun 93 15:21:49 GMT Received: from sayshell.umd.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26949; Wed, 9 Jun 93 08:21:25 PDT Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0) id AA02617; Wed, 9 Jun 93 11:22:43 -0400 Message-Id: <9306091522.AA02617@sayshell.umd.edu> To: Moodys Investors Service Cc: Firewalls@GreatCircle.COM From: "Louis A. Mamakos" Subject: Re: info.firewalls In-Reply-To: Your message of "Wed, 09 Jun 1993 10:05:57 EDT." <199306091405.AA06226@tigger.jvnc.net> Date: Wed, 09 Jun 1993 11:22:42 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I like the idea of a mailing list because the technology being developed here > is so sensitive that we need to be able to know who is involved. Security by obscurity, eh? Sorry, I just don't buy it. Now, if you want to argue about the signal-to-noise ratio of a newsgroup vs. a mailing list... Louis A. Mamakos University of Maryland, College Park From Firewalls-Owner Wed Jun 9 15:34:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27001; Wed, 9 Jun 93 15:34:40 GMT Received: from eros.uknet.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA26994; Wed, 9 Jun 93 08:34:19 PDT Received: from micrognosis.co.uk by eros.uknet.ac.uk with UUCP id ; Wed, 9 Jun 1993 16:35:31 +0100 Date: Wed, 9 Jun 93 15:45:52 BST From: Neil Readwin To: Moodys Investors Service Cc: Firewalls@GreatCircle.COM Subject: Re: info.firewalls Message-Id: <9306091545.aa17022@ladon.micrognosis.co.uk> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In your letter dated Wed, 9 Jun 1993 10:05:57 -0400, you wrote: >> ...created an "info.firewalls" newsgroup, and is distributing it (I don't >know how widely) over the Internet. I'm not necessarily opposed to this... > >I like the idea of a mailing list because the technology being developed here >is so sensitive that we need to be able to know who is involved. I don't follow this. Membership of the list appears to be open, and I would guess that many entries on the list are secondary list exploders (I know ours is). I don't think anyone on the list knows who is reading it and I would hope that it doesn't matter. A secure system should not depend on people not knowing about how it is built. Neil. From Firewalls-Owner Wed Jun 9 15:42:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27038; Wed, 9 Jun 93 15:42:24 GMT Received: from rara.ossi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27031; Wed, 9 Jun 93 08:42:18 PDT Received: from nym.ossi.com (nym.ossi.com [192.240.2.13]) by rara.ossi.com (ALPHA-6.54/6.28) id IAA22986; Wed, 9 Jun 1993 08:44:06 -0700 Received: from localhost (aegl@localhost) by nym.ossi.com (ALPHA-6.54/6.27) id IAA23248; Wed, 9 Jun 1993 08:44:05 -0700 Date: Wed, 9 Jun 1993 08:44:05 -0700 From: Tony Luck Message-Id: <199306091544.IAA23248@nym.ossi.com> To: Firewalls@GreatCircle.COM Subject: Re: info.firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk John van Vlaanderen writes: > I like the idea of a mailing list because the technology being developed here > is so sensitive that we need to be able to know who is involved. But I'm a full time professional system cracker. I read the firewalls list to get tips on how to attck systems (particularly from people who post messages that say "Here at XYZ Inc. we use {known buggy h/w or s/w} to protect all our machines). ... Ok, actually I'm just a humble kernel programmer ... but what makes you think that a mailing list is any less likely to be read by "the bad guys" than a newsgroup? Brent places no restrictions on who can subscribe to this list (and has no way to tell the white hats from the black hats). -Tony Luck From Firewalls-Owner Wed Jun 9 09:55:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27133; Wed, 9 Jun 93 16:24:40 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27126; Wed, 9 Jun 93 09:24:33 PDT Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA00029; Wed, 9 Jun 93 11:54:54 EDT Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA09349; Wed, 9 Jun 93 12:08:49 EDT Date: Wed, 9 Jun 93 12:08:49 EDT From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9306091608.AA09349@s.ecc.engr.uky.edu> To: firewalls@GreatCircle.COM Subject: Re: info.firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: "Louis A. Mamakos" >Someone else said: >> I like the idea of a mailing list because the technology being developed here >> is so sensitive that we need to be able to know who is involved. > >Security by obscurity, eh? Sorry, I just don't buy it. Agreed; by the time word gets to us, the ECH (Evil Cracking Hordes (tm)) usually know about it already....... >Now, if you want to argue about the signal-to-noise ratio of a >newsgroup vs. a mailing list... That would be my biggest complaint. I've seen too many lists go down the tubes after gatewaying into Usenet. It may seem a bit elitist, but I appreciate a forum that doesn't generate dozens of "Me, too" and "what do you mean by a process?" submissions. My definition of a quality forum is "a forum that doesn't require a killfile or filter." Some of the lists to which I subscribe are about to be halved by procmail filters. If firewalls is ever considered for a Usenet gateway, I'd *definitely* want to see a real moderator, screening out the crud. I'm willing to bet that several hundred people have tried to post "What's this news- group about?" messages since it leaked from BYU........ --Wes From Firewalls-Owner Thu Jun 10 14:21:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01354; Thu, 10 Jun 93 14:21:01 GMT Received: from nic.cerf.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01347; Thu, 10 Jun 93 07:20:55 PDT Received: from dt.wdc.com (fission.dt.wdc.com) by nic.cerf.net (4.1/CERFnet-1.0) id AA00590; Thu, 10 Jun 93 07:25:33 PDT Received: from wdceng.dt.wdc.com by dt.wdc.com (4.1/SMI-4.1) id AA06874; Thu, 10 Jun 93 07:22:47 PDT Received: by wdceng.dt.wdc.com (4.1/sendmail.cf.sysad1.4) id AA05942; Thu, 10 Jun 93 07:22:46 PDT Date: Thu, 10 Jun 93 07:22:46 PDT From: wyatt@dt.wdc.com (Troy Wyatt (Wyatt) x5457) Message-Id: <9306101422.AA05942@wdceng.dt.wdc.com> To: uunet!ossi.com!aegl Subject: Re: info.firewalls Cc: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tony Luck writes: But I'm a full time professional system cracker. I read the firewalls list to get tips on how to attck systems (particularly from people who post messages that say "Here at XYZ Inc. we use {known buggy h/w or s/w} to protect all our machines). ... Ok, actually I'm just a humble kernel programmer ... but what makes you think that a mailing list is any less likely to be read by "the bad guys" than a newsgroup? Brent places no restrictions on who can subscribe to this list (and has no way to tell the white hats from the black hats). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Tony Luck -------- Should that not be diff. hats of color to be correct! ;-) Hack....Hack....Wheeeze From Firewalls-Owner Fri Jun 11 00:10:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02530; Fri, 11 Jun 93 00:10:04 GMT Received: from norman.li.Cubic.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02521; Thu, 10 Jun 93 17:09:55 PDT Received: by norman.li.Cubic.COM (5.67/1.34a) id AA05001; Thu, 10 Jun 93 20:11:48 -0400 Date: Thu, 10 Jun 93 20:11:48 -0400 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9306110011.AA05001@norman.li.Cubic.COM> To: Firewalls@GreatCircle.COM Subject: CMC Rockwell Nethopper Packet Filtering? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Could someone familiar with the Nethopper describe its packet filtering in detail? Can it log denied and/or permitted packet information? Thanks. Dave Mischler mischler@cubic.com From Firewalls-Owner Sat Jun 12 06:54:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07574; Sat, 12 Jun 93 06:54:11 GMT Received: from Spectrum.CMC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07546; Fri, 11 Jun 93 23:54:01 PDT Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA04314; Fri, 11 Jun 93 23:52:53 PDT Newsgroups: list.firewalls Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: CMC Rockwell Nethopper Packet Filtering? Message-Id: <1993Jun12.065234.4235@spectrum.CMC.COM> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA References: <9306110011.AA05001@norman.li.Cubic.COM> Date: Sat, 12 Jun 93 06:52:34 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In article <9306110011.AA05001@norman.li.Cubic.COM> mischler@Cubic.COM (Dave Mischler) writes: >Could someone familiar with the Nethopper describe its packet filtering >in detail? Can it log denied and/or permitted packet information? Hello Dave, I am one of the NetHopper developers. The NetHopper's IP filters allow you to specify any or all of: source IP address source port destination IP address destination port IP protocol interface direction (in or out) type (allow/deny/allow-but-don't-dial-for-this) Each filter is named, and entries can be added before or after a previously specified filter. Evaluation of each packet continues until it hits a filter and is allowed or denied, or until the end of the list, where there is an implied source any dest any protocol any allow. (I.e. the default is to allow unknown, but it is trivial to change this to deny anything unknown.) For each filter, it is settable whether a denied packet returns an ICMP error. We do not currently trigger SYSLOG messages for denied packets (we were concerned about this turning into a denial-of-service), but we do maintain a count of hits in each filter. The filters are accessible as an enterprise MIB group under SNMP. The main things that we *don't* do that have been mentioned by others here on the list are: - no logging of denied packets (see above) - no RANGE of port numbers - no ESTABLISHED keyword (we don't interpret TCP protocol) - no arbitrary offset/mask/pattern The NetHopper is currently positioned as a low-cost way to interconnect remote IP LANs to the backbone over dial-up V.32bis lines. Our customers have found the security features adequate for this environment. I don't think it would surprise anyone, if we came out with a leased-56kbps line version of the unit, and we feel that these filters would be adequate to protect the average small to medium sized site (25-500 nodes) from the "reaonably believable threat". If and when we implement IPX routing, we plan to include similar filtering capability for IPX routing and SAP advertizements. I will be happy to answer additional questions from this list. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256 From Firewalls-Owner Sat Jun 12 14:03:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00429; Sat, 12 Jun 93 20:16:24 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00422; Sat, 12 Jun 93 13:16:15 PDT Received: from futureworld.advtech.uswest.com.advtech.uswest.com (futureworld.advtech.uswest.com) by uswat.advtech.uswest.com with SMTP id AA23715 (5.65c/IDA-1.4.4 for ); Sat, 12 Jun 1993 14:17:35 -0600 Received: from localhost.uswest.com by futureworld.advtech.uswest.com.advtech.uswest.com (advtech.uswest.com) id AA20908 (4.1/at-generic.18Mar93); Sat, 12 Jun 93 14:17:34 MDT Message-Id: <9306122017.AA20908@futureworld.advtech.uswest.com.advtech.uswest.com> To: firewalls@GreatCircle.COM Subject: flexable firewall wanted Date: Sat, 12 Jun 1993 14:17:33 -0600 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We are currently using cisco's extended access control lists as our Internet firewall but we need something more flexable. Specificly, our users want to use applications like wais for the mac, gopher, and xmosaic (many of which incorporate ftp) from the desktop. I'd be interested in hearing about anyone who has dealt with any of these protocols through a firewall. thanx, brad From Firewalls-Owner Sun Jun 13 03:31:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01030; Sun, 13 Jun 93 03:31:35 GMT Received: from yarra-glen.aaii.oz.au (eden-valley.aaii.oz.AU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01023; Sat, 12 Jun 93 20:31:22 PDT Received: from localhost.aaii.oz.AU by yarra-glen.aaii.oz.au with SMTP (5.65c/SMI-4.0/AAII) id AA16344; Sun, 13 Jun 1993 13:31:58 +1000 Message-Id: <199306130331.AA16344@yarra-glen.aaii.oz.au> To: Brad Huntting Cc: firewalls@GreatCircle.COM Subject: Re: flexable firewall wanted In-Reply-To: Your message of "Sat, 12 Jun 1993 14:17:33 CST." <9306122017.AA20908@futureworld.advtech.uswest.com.advtech.uswest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jun 1993 13:31:57 +1000 From: Anthony Baxter Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brad Huntting writes: > We are currently using cisco's extended access control lists as our > Internet firewall but we need something more flexable. > Specificly, our users want to use applications like wais for the mac, > gopher, and xmosaic (many of which incorporate ftp) from the desktop. > I'd be interested in hearing about anyone who has dealt with any of > these protocols through a firewall. The firewall we use here has the ability to specify a range of ports from which outgoing connections from any host inside the firewall can go to any port on any host outside the firewall. This probably doesnt require you be able to do source port routing - if you pick your range of ports up high enough, the only thing that will use those ports will be your network applications (oooh, someone sent bogus data to my wais client! big deal :) This method generally requires a line or two (just bind()ing to a port in the accepted range) to be added to each of the applications we want to use (eg Xmosaic, gopher, WAIS, archie). So far I havent found anything that cant be made to work with this, although we really only use workstations, so we have source code - this probably wouldnt work with some of the platforms for which there are only binaries of the applications available (eg PC's) Anthony From Firewalls-Owner Wed Jun 16 20:08:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07660; Wed, 16 Jun 93 20:08:29 GMT Received: from nic.cerf.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07652; Wed, 16 Jun 93 13:08:12 PDT Received: from dt.wdc.com (fission.dt.wdc.com) by nic.cerf.net (4.1/CERFnet-1.0) id AA27328; Wed, 16 Jun 93 13:13:02 PDT Received: from wdceng.dt.wdc.com by dt.wdc.com (4.1/SMI-4.1) id AA19774; Wed, 16 Jun 93 13:10:06 PDT Received: by wdceng.dt.wdc.com (4.1/sendmail.cf.sysad1.4) id AA18479; Wed, 16 Jun 93 13:10:05 PDT Date: Wed, 16 Jun 93 13:10:05 PDT From: wyatt@dt.wdc.com (Troy Wyatt (Wyatt) x5457) Message-Id: <9306162010.AA18479@wdceng.dt.wdc.com> To: Firewalls-Digest@GreatCircle.COM Subject: Monitoring outgoing Internet traffic Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I would be interested in this as well. ----- Begin Included Message ----- From linson Wed Jun 16 13:05:27 1993 To: muir, wyatt Subject: Monitoring outgoing Internet traffic Content-Length: 1196 X-Lines: 38 fyi ----- Begin Included Message ----- >From sunkist!delta.eecs.nwu.edu!sun-managers-relay Wed Apr 22 11:40:30 1992 Sender: sunkist!eecs.nwu.edu!sun-managers-relay Newsgroups: brown.sunmanagers Path: cs.brown.edu!dwv Subject: Monitoring outgoing Internet traffic Keywords: internet Organization: Brown Computer Science Dept. Lines: 20 Content-Length: 791 X-Lines: 20 We have noticed on our network recently an increase in the number of people sending job requests out over the Internet from within processes. The most common usage seems to be writing a script to finger at another school for the presence of a friend logged on. These scripts, however, tend to contain fast loops, making MANY remote finger requests, and if the processes run away, the requests increase greatly. Basically, what we would like to do is monitor outgoing packets from our local domain going out on the internet. Does anyone currently do anything like the? Or can someone suggest ways we might monitor such activity? Much thanks, David V. dwv@cs.tufts.edu -I know it says dwv@cs.*brown*.edu, but I'm still at Tufts for now. I'll be coming to Brown after graduation ;-) ----- End Included Message ----- ----- End Included Message ----- From Firewalls-Owner Wed Jun 16 20:41:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07720; Wed, 16 Jun 93 20:41:14 GMT Received: from norman.li.Cubic.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07713; Wed, 16 Jun 93 13:41:02 PDT Received: by norman.li.Cubic.COM (5.67/1.34a) id AA00357; Wed, 16 Jun 93 16:42:58 -0400 Date: Wed, 16 Jun 93 16:42:58 -0400 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9306162042.AA00357@norman.li.Cubic.COM> To: Firewalls-Digest@GreatCircle.COM, wyatt@dt.wdc.com Subject: Re: Monitoring outgoing Internet traffic Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Basically, what we would like to do is monitor outgoing packets from our > local domain going out on the internet. Does anyone currently do anything > like the? Or can someone suggest ways we might monitor such activity? I am doing something like this using a KA9Q-based router that logs packets based on filter entries. I am currently logging all in and outbound TCP SYN packets (the ones that open connections), as well as all denied packets, to the system log on a nearby Unix box. This is fine for my needs, but I only have a V.32bis/V.42bis dialup connection. I have experimented with the software running between two ethernets, but it was not as robust, nor as fast, as I would have liked (this is apparently a KA9Q problem). You can get KA9Q with my packet filtering changes from ftp.demon.co.uk in /pub/ibmpc/dm930319/dm930319.{doc,exe,zip}. The doc file includes sample configuration files. Dave Mischler mischler@cubic.com From Firewalls-Owner Thu Jun 17 00:07:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08015; Thu, 17 Jun 93 00:07:06 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08008; Wed, 16 Jun 93 17:06:54 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA27868; Wed, 16 Jun 93 20:10:01 EDT Date: Wed, 16 Jun 93 20:10:01 EDT From: Marcus J Ranum Message-Id: <9306170010.AA27868@TIS.COM> To: firewalls@GreatCircle.COM Subject: Re: Monitoring outgoing Internet traffic Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Another tool worth looking at is NNStat, by Braden and DeSchon. It runs on Suns or DECs, using the packet filter. NNStat takes a grammar of "things you're interested in storing" and applies it to all the IP packets it sees on the wire. This is interesting because you can set rules to store, for example, ethernet addresses and IP addresses of all machines emitting packets on your LAN that don't have correct IP addresses. In the past this has proven handy for tracking down network numbskulls. [You just set a host route to the offending IP address as being on the local LAN, and telnet to it or whatever, to find out more about it] The description language takes some getting used to but it's pretty neat and it executes fast enough that it won't kill your machine. Here's an example: ># Marcus J. Ranum, 1992. >attach { > > # record customers > if(IP.srcnet isnot eqf ( 198.137.240.0 )) > record IP.srcnet IP.dsthost in local.ingate matrix-all; If the IP source is not on our local network, record the originating network and the system it was talking to. This table gets large, as you'd expect. > # if its ether came from the router but it is a LOCAL address > # we have some cause to suspect that someone is jiggering packets > if(Ether.src is eqf ( 0:0:c:5:15:26 )) { > if(IP.srcnet is eqf ( 198.137.240.0 )) { > record IP.srchost IP.dsthost in local.weird.srcdest matrix-all; > } > > } This one is amusing. We want to log any packets coming IN our router that claim to have been local. This should usually be an empty record, but if it starts to get entries, then someone might be playing games or local routing may be hosed. > # record incoming and outgoing router traffic > if(IP.srcnet isnot eqf ( 198.137.240.0 )) > record IP.length in local.incoming.length freq-all; > if(IP.dstnet isnot eqf ( 198.137.240.0 )) > record IP.length in local.outgoing.length freq-all; This rule records packet sizes, and incidentally counts. All it collects is traffic between our network and anyone else. By summarizing this value I can get an exact byte count of IP traffic for a period, if I need to. Rules like this are useful for justifying shutting down a service (IRC or MUDs, though you'll almost always find NNTP traffic is much greater) or for network tuning. For example, if someone is running something that is really loading things down, it'll show up fast. I had a pair of nameservers go crazy on me once and it was immediately obvious, since NNStat detected millions of packets between them in a very short time. If I hadn't been running NNStat I might have noticed in a week or so... > # record port usage > record TCP.dstport in local.tcpport.ports freq-all; > record UDP.dstport in local.udpport.ports freq-all; >} This just examines traffic by service port. Useful and sometimes interesting. For folks who are firewalled using a screening router, it might be amusing to have rules in place that cross-check your router by flagging any traffic that should not be there (E.g.: ether source is your router, IP source is not local, and port is in the set you don't want to see) Here's some of the output you get: This is from the rule that gathers TCP usage statistics. > >Log created on Mon Jun 14 08:54:06 1993, for host eop.gov. > Sample interval = 5 minutes; checkpoint interval = 60 minutes. > Clear interval = 1440 minutes. > Object name = 'local.tcpport.ports'. > >OBJECT: local.tcpport.ports Class= freq-all [Created: 12:46:12 06-11-93] > ReadTime: 09:01:30 06-14-93, ClearTime: 22:07:26 06-13-93 (@-39244sec) > Total Count= 19766 (+0 orphans) > #bins = 801 > >[25 "smtp"]= 6601 (33.4%) @-24sec >[2222]= 1867 ( 9.4%) @-241sec >[79 "finger"]= 1684 ( 8.5%) @-14sec >[23 "telnet"]= 662 ( 3.3%) @-89sec >[1728]= 285 ( 1.4%) @-89sec >[21 "ftp"]= 244 ( 1.2%) @-948sec >[53 "domain"]= 92 ( 0.5%) @-2749sec >[1723]= 52 ( 0.3%) @-22943sec >[4189]= 43 ( 0.2%) @-786sec >[4188]= 41 ( 0.2%) @-825sec >[3976]= 36 ( 0.2%) @-36321sec >[4656]= 34 ( 0.2%) @-4115sec >[1697]= 31 ( 0.2%) @-19125sec >[4110]= 30 ( 0.2%) @-12461sec > This is the network to network connection data. It's pretty neat. NNStat returns the information all formatted and sorted just like this. There are tools to lookup names and addresses for post-processing the results. >Log created on Fri Jun 11 14:55:04 1993, for host eop.gov. > Sample interval = 5 minutes; checkpoint interval = 60 minutes. > Clear interval = 1440 minutes. > Object name = 'local.ingate'. > >OBJECT: local.ingate Class= matrix-all [Created: 12:46:12 06-11-93] > ReadTime: 15:02:38 06-11-93, ClearTime: 14:07:33 06-11-93 (@-3305sec) > Total Count= 6596 (+0 orphans) > #bins = 219 > >[192.33.112.0 : 198.137.240.100]= 1867 (28.3%) @-0sec >[192.33.112.0 : 198.137.240.101]= 135 ( 2.0%) @-304sec >[192.239.48.0 : 198.137.240.100]= 129 ( 2.0%) @-222sec >[128.32.0.0 : 198.137.240.100]= 117 ( 1.8%) @-282sec >[129.243.0.0 : 198.137.240.100]= 117 ( 1.8%) @-1648sec >[192.48.96.0 : 198.137.240.100]= 111 ( 1.7%) @-3215sec >[129.188.0.0 : 198.137.240.201]= 107 ( 1.6%) @-3184sec >[128.95.0.0 : 198.137.240.100]= 94 ( 1.4%) @-162sec >[192.147.161.0 : 198.137.240.100]= 83 ( 1.3%) @-1356sec >[192.100.81.0 : 198.137.240.100]= 79 ( 1.2%) @-760sec >[144.51.0.0 : 198.137.240.100]= 78 ( 1.2%) @-8sec >[128.229.0.0 : 198.137.240.100]= 77 ( 1.2%) @-701sec >[128.8.0.0 : 198.137.240.100]= 69 ( 1.0%) @-280sec Another really nice thing about it is you can leave the daemon running on one machine and query it over a network from another. You can also interactively attach new rules, so if you are debugging a network problem and want to insert a new query, "Hmmmm, where IS all that NFS traffic coming from!?" you just attach to the statspy daemon and tell it the new rule, then dump that value every so often. There are programs with the package that sleep and automate collecting the data to a file. The idea is that you might have multiple machines on various sides of routers, with a single machine polling them and gathering stats network-wide. Slick stuff. The one part that I really really dislike about NNStat is that there's absolutely no provision for security in it. I solved that by just hacking the statspy server to only talk to my workstation and to ask for a password. Simplistic but sufficient. NNStat can be found all over the net. There's a version with some of my hacks in it on decuac.dec.com in pub/sources nnstat.tar.Z -- the changes I made were minor formatting, a few core dump fixes, and I ripped the server into a daemon that forks and disassociates from its terminal, suitable for putting in rc.local. Warning: Expansive queries eat memory, chew up disk if you store them, and return so much information you can't look at it all. Enjoy! mjr. From Firewalls-Owner Thu Jun 17 00:32:19 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08105; Thu, 17 Jun 93 00:32:19 GMT Received: from diemen.utas.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08098; Wed, 16 Jun 93 17:31:40 PDT Received: from bowen.cc.utas.edu.au by diemen.utas.edu.au with SMTP id AA24909 (5.65c/IDA-1.4.4 for Firewalls-Digest@greatcircle.com); Thu, 17 Jun 1993 10:31:43 +1000 Received: by bowen.cc.utas.edu.au (4.1/SMI-4.1) id AA24196; Thu, 17 Jun 93 10:31:42 EST Date: Thu, 17 Jun 1993 10:26:53 +1000 (EST) From: John Miezitis Subject: Re: Monitoring outgoing Internet traffic To: "Troy Wyatt (Wyatt) x5457" Cc: Firewalls-Digest@GreatCircle.COM In-Reply-To: <9306162010.AA18479@wdceng.dt.wdc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Wed, 16 Jun 1993, Troy Wyatt (Wyatt) x5457 wrote: > I would be interested in this as well. > > > ----- Begin Included Message ----- > > >From linson Wed Jun 16 13:05:27 1993 > To: muir, wyatt > Subject: Monitoring outgoing Internet traffic > Content-Length: 1196 > X-Lines: 38 > > fyi > ----- Begin Included Message ----- > > >From sunkist!delta.eecs.nwu.edu!sun-managers-relay Wed Apr 22 11:40:30 1992 > Sender: sunkist!eecs.nwu.edu!sun-managers-relay > Newsgroups: brown.sunmanagers > Path: cs.brown.edu!dwv > Subject: Monitoring outgoing Internet traffic > Keywords: internet > Organization: Brown Computer Science Dept. > Lines: 20 > Content-Length: 791 > X-Lines: 20 > > We have noticed on our network recently an increase in the number of > people sending job requests out over the Internet from within processes. > The most common usage seems to be writing a script to finger at another > school for the presence of a friend logged on. These scripts, however, > tend to contain fast loops, making MANY remote finger requests, and if > the processes run away, the requests increase greatly. > > Basically, what we would like to do is monitor outgoing packets from our > local domain going out on the internet. Does anyone currently do anything > like the? Or can someone suggest ways we might monitor such activity? We monitor all traffic leaving or entering our network using NNSTAT. Originaly started monitoring this traffic to see how much of it was due to MUDS but have since found it to be invaluable for diagnostics as well as tracing potential intruders. We have had to purchase a 2Gb drive to keep all the data generated. This data is archived yearly to exabyte. Cheers. JohnM. John B Miezitis, University of Tasmania, Information Technology Services. Intl Ph: +61 02 202811, Aus Ph: 002 202811, Email: John.Miezitis@its.utas.edu.au Belgium man Belgium!!! - Z. Beeblebrox _______________________________________________________________________________ From Firewalls-Owner Thu Jun 17 14:10:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10234; Thu, 17 Jun 93 14:10:37 GMT Received: from valhalla.ee.rochester.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10227; Thu, 17 Jun 93 07:10:23 PDT Received: from thermal.ee.rochester.edu by valhalla.ee.rochester.edu (5.0/2.17ee-dk) id AA13631; Thu, 17 Jun 93 10:11:29 EDT From: Del Armstrong Received: by thermal.ee.rochester.edu (4.1/2.1client) id AA06380; Thu, 17 Jun 93 10:12:23 EDT Message-Id: <9306171412.AA06380@thermal.ee.rochester.edu> Subject: Re: Monitoring outgoing Internet traffic To: firewalls@GreatCircle.COM Date: Thu, 17 Jun 1993 10:12:21 -0400 (EDT) X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1008 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Basically, what we would like to do is monitor outgoing packets from our > local domain going out on the internet. Does anyone currently do anything > like the? Or can someone suggest ways we might monitor such activity? Yet another way to monitor packets is to use the "tcplogger" and "extract" programs, which are part of the TAMU (Texas A&M University) security package. Running on Suns, tcplogger will log all the tcp packets on your ethernet, and extract will filter tcplogger output based on things like source network, destination network, source port and destination port. Using these tools, it should be simple to log all finger packets leaving your network for external sites. It's available for anonymous ftp from sc.tamu.edu:pub/security/TAMU. Del --------------------------------------------------------------------- dela@ee.rochester.edu rutgers!ur-valhalla!dela (716)275-5342 Computing and Networking Group, College of Engineering University of Rochester, Rochester, NY From Firewalls-Owner Sun Jun 20 02:36:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17702; Sun, 20 Jun 93 02:36:40 GMT Received: from gsco.com (mach1.gsco.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17695; Sat, 19 Jun 93 19:36:33 PDT Received: from gs.com (postoffice1.gsco.com) by gsco.com (4.1/SMI-4.1) id AA14030; Sat, 19 Jun 93 22:44:14 EDT Received: from moose.wan.gs.com by gs.com (4.1/SMI-4.1) id AA03041; Sat, 19 Jun 93 22:39:44 EDT Received: by moose.wan.gs.com (4.1/SMI-4.1) id AA04676; Sat, 19 Jun 93 22:38:19 EDT Date: Sat, 19 Jun 93 22:38:19 EDT From: safdas@gsco.com (Shabbir J Safdar) Message-Id: <9306200238.AA04676@moose.wan.gs.com> To: firewalls@GreatCircle.COM Subject: Finger daemon for outbound firewall only? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has anyone tried to implement finger (outgoing only) through a firewall yet? I imagine the pieces would involve: -Wietse Venema's tcp_wrapper to restrict access to only internal hosts -A specialty program to parse the input and screen it for ridiculous stuff (like finger bouncing and so forth) It would be a simple proxy service, I suppose. -Shabbir From Firewalls-Owner Sat Jun 19 20:45:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17788; Sun, 20 Jun 93 03:21:25 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17781; Sat, 19 Jun 93 20:21:18 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA01178; Sat, 19 Jun 93 23:25:03 EDT Date: Sat, 19 Jun 93 23:25:03 EDT From: Marcus J Ranum Message-Id: <9306200325.AA01178@TIS.COM> To: firewalls@GreatCircle.COM, safdas@gsco.com Subject: Re: Finger daemon for outbound firewall only? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Has anyone tried to implement finger (outgoing only) through a firewall yet? Trivial. You use log_tcp or something like that to block finger from the outside world and permit it only from the inside, and then just tell folks who want to use finger to: finger user@host.domain@firewall-machine Which can easily enough be aliased in a shell script called "finger" that examines the address and routes nonlocal addresses through the firewall. mjr. From Firewalls-Owner Mon Jun 21 06:02:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21859; Mon, 21 Jun 93 06:02:02 GMT Received: from chulkn.chula.ac.th by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21852; Sun, 20 Jun 93 23:01:08 PDT Received: by chulkn.chula.ac.th (Smail3.1.28.1 #12) id m0o7eqJ-0003WyC; Mon, 21 Jun 93 12:54 BKK Date: Mon, 21 Jun 1993 12:54:15 +0000 (BKK) From: "Bordin Sapsomboon - Fact. of Medicine of Siriraj " Subject: To: Firewalls@GreatCircle.COM In-Reply-To: <9306180800.AA13355@mycroft.GreatCircle.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk signoff firewalls-digest From Firewalls-Owner Mon Jun 21 15:16:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23447; Mon, 21 Jun 93 15:16:54 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23440; Mon, 21 Jun 93 08:16:45 PDT Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA04710; Mon, 21 Jun 93 10:18:58 CDT Date: Mon, 21 Jun 93 10:18:58 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9306211518.AA04710@tadpole.tadpole.com> To: firewalls@GreatCircle.COM, safdas@gsco.com Subject: Re: Finger daemon for outbound firewall only? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > It would be a simple proxy service, I suppose. Acatually, if you're a 'C' programmer, its fairly easy to hack in.fingerd into shape. bind(2) it to the internal interface on your firewall, and let it fly. Users inside the firewall can finger 'out' (finger @somehost.edu@someotherhost.gov@firewall), while the hostile hoards can't get 'in'. I once did this at (name of previous employer deleted), its still in-place, though they've opened up other holes since I left. :-) Jim From Firewalls-Owner Tue Jun 22 05:00:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25772; Tue, 22 Jun 93 05:00:56 GMT Received: from fulton.santec.boston.ma.us (fulton.inset.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25765; Mon, 21 Jun 93 22:00:45 PDT Received: by fulton.santec.boston.ma.us (Sendmail:5.64/Cf:Jr.2.7) id AA13483; Tue, 22 Jun 93 01:07:11 -0400 (EDT) To: firewalls@GreatCircle.COM Subject: Re: Firewalls talk 30 June 7pm @ MIT Date: Tue, 22 Jun 93 01:05:27 EDT From: "JR Oldroyd" X-Face: "gX6V[xK'qr:JesSwLc!moH:3*%(Pf#1^EC$)x/cgaVCB{4R( /IP4$DH'}%/yzsCq:qHQ*DsMv,=do~#+0;3a-H}hYN/hn*\*]6c#O~*4 h`48zPuuKno4sNqs-11Y*3tLwxzKZk+e{0zQ'X0VXrvk]hQs/.XP"tcY@RpY;SH*$8_ZT #,ZL9*N`%8'S:.T1Aca%$w@d`E!w~HEe'KGBsc.W^WecBOl{C|N&kai[ Message-Id: <9306220107.kisad.jr@santec.boston.ma.us> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I thought this may be of interest to folk on this list... -jr --- Forwarded letter from peg@BBN.COM follows: > From owner-bblisa-announce@inset.com Tue Jun 22 00:28:30 1993 > Subject: Firewalls talk 30 June 7pm @ MIT > From: Peg Schafer > Date: Tue, 22 Jun 93 0:17:10 EDT > To: bblisa-announce@inset.com > Message-Id: <9306220423.AA06112@onion.inset.com> > > > > This month BBLISA will host a presentation by Ed Anselmo and John > Curran ("The Near Net Guys") on Firewalls, at MIT Wednesday June 30th > at 7PM. > > "Firewall machines" and packet filtering routers are increasingly > popular tools for improving network security. We'll review some of the > ins and outs of firewall design and filtering strategies, and try to > give you a feel for why firewalls and packet filtering may or may not > be the answer for your site's security needs. > > Directions to the meeting: > > At: MIT > Room 140 > Building E51 > 70 Memorial Drive > Cambridge, MA > > Directions: > Car: For folks driving, they should follow Memorial > Drive, and then turn down Wadsworth St. to get > to the rear of the building. Entrance > and parking are in the rear. > > T: Red Line to Kendall Square stop. > From the T head over toward Au Bon Pain, take > right onto Wadsworth St. The E51 building is > at the corner of Wadsworth and Amherst St. > > > -- > Send mail for the `bblisa-announce' mailing list to `bblisa-announce@inset.com'. > Send list subscription requests to `bblisa-announce-request@inset.com'. --- End of forwarded letter From Firewalls-Owner Tue Jun 22 21:32:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27654; Tue, 22 Jun 93 21:32:12 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27647; Tue, 22 Jun 93 14:32:04 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14438>; Tue, 22 Jun 1993 17:34:16 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA02642 (5.65a/IDA-1.4.2 for safdas@gsco.com); Tue, 22 Jun 93 17:21:59 -0400 Received: by dino.alias.com id AA11815 (5.65a/IDA-1.4.2 for firewalls@GreatCircle.COM); Tue, 22 Jun 93 17:21:57 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9306222121.AA11815@dino.alias.com> Subject: Re: Finger daemon for outbound firewall only? To: safdas@gsco.com (Shabbir J Safdar) Date: Tue, 22 Jun 1993 18:21:52 -0400 Cc: firewalls@GreatCircle.COM In-Reply-To: <9306200238.AA04676@moose.wan.gs.com> from "Shabbir J Safdar" at Jun 19, 93 10:38:19 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 563 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Has anyone tried to implement finger (outgoing only) through a firewall yet? Implementing outgoing finger, while denying incoming fingers, seems *extremely* hypocritical to me. You want to be able to get (useful) information about others, but not give out information yourselves? -- C. Harald Koch, Network Manager | SCARY STATISTICS 101: Alias Research Inc. Toronto, ON | Average monthly number of Toronto Daily Bread chk@alias.com | Food Bank clients who have college or chk@gpu.utcc.utoronto.ca | university educations: 28,200 From Firewalls-Owner Tue Jun 22 21:50:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27681; Tue, 22 Jun 93 21:50:13 GMT Received: from interlock.amoco.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27672; Tue, 22 Jun 93 14:49:59 PDT Received: by interlock.amoco.com id (InterLock SMTP Gateway 1.1 for Firewalls@greatcircle.com); Tue, 22 Jun 1993 16:45:23 -0500 Received: by interlock.amoco.com (Internal Mail Agent-3); Tue, 22 Jun 1993 16:45:23 -0500 Received: by interlock.amoco.com (Internal Mail Agent-2); Tue, 22 Jun 1993 16:45:23 -0500 Received: by interlock.amoco.com (Internal Mail Agent-1); Tue, 22 Jun 1993 16:45:23 -0500 Received: by interlock.amoco.com (Internal Mail Agent-0); Tue, 22 Jun 1993 16:45:23 -0500 Date: Tue, 22 Jun 93 16:10:02 CDT From: dmburns@amoco.com (David Burns) Message-Id: <9306222110.AA07922@pulsar.hou.amoco.com> To: Firewalls@GreatCircle.COM Subject: procedures for handling executables ? Cc: dmburns@amoco.com, wjryan@amoco.com, rwpowell@amoco.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Greetings - We are in the process of implementing an Internet gateway. Our management is *very* concerned about importation of virii, worms, etc. via executables, and has asked me to search for all reasonable ways/methods of mimimizing the exposures. We have a large network, w/ at least one of just about everything. I think that we have a good grasp of the basic issues. I understand that executables can be encoded, that not all binary data is bad, etc. I'm proposing a policy based on user accountability and education. We will be able to enforce it to some extent via filtering, and have audit logs for tracking events after the fact. But I don't want to limit the users unnecessarily. However, management has asked me to (1) query any sources available, to check for best practices among other companies (2) Look for 'virus scrubbers" if such things exist for the unix environment and (3) consider using an intermediate system (just inside the firewall, or as part of it) as a 'sacrificial lamb' or cold storage system. I'm resisting the latter 2, but would like to find out how others are handling the problem. I especially think that (3) would be disdained and avoided by our user community. Note: I'm particularly interested in replies from other commercial interests, and other sysadmins with similar problems and concerns. (This is my first post to this group; forgive me if this is an FAQ somewhere. Also, if there are other, more appropriate groups, feel free to cross-post and/or enlighten me. Flames to /dev/null please.) In advance, thanks to all who respond. David From Firewalls-Owner Tue Jun 22 22:47:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27767; Tue, 22 Jun 93 22:47:04 GMT Received: from gsco.com (mach1.gsco.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27760; Tue, 22 Jun 93 15:46:54 PDT Received: from gs.com (postoffice1.gsco.com) by gsco.com (4.1/SMI-4.1) id AA29283; Tue, 22 Jun 93 18:53:26 EDT Received: from moose.wan.gs.com by gs.com (4.1/SMI-4.1) id AA03324; Tue, 22 Jun 93 18:48:50 EDT Received: by moose.wan.gs.com (4.1/SMI-4.1) id AA22062; Tue, 22 Jun 93 18:47:23 EDT Date: Tue, 22 Jun 93 18:47:23 EDT From: safdas@gsco.com (Shabbir J Safdar) Message-Id: <9306222247.AA22062@moose.wan.gs.com> To: murphy@murphy.gun.com, chk@alias.com Subject: You've got to be kidding me. Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I may be a hypocrite about running finger, but that's due to my paranoia. Paranoia's my job; I wasn't hired to promote the ideals of an open Internet. I'd like to see it as much as the next person, but not at the risk of a break-in at my site. -Shabbir From Firewalls-Owner Tue Jun 22 22:54:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27788; Tue, 22 Jun 93 22:54:21 GMT Received: from rip.psg.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27781; Tue, 22 Jun 93 15:54:14 PDT Received: by rip.psg.com (Smail3.1.28.1 #5) id m0o8HGK-000302C; Tue, 22 Jun 93 15:56 PDT Message-Id: From: randy@psg.com (Randy Bush) Subject: Re: You've got to be kidding me. To: safdas@gsco.com (Shabbir J Safdar) Date: Tue, 22 Jun 1993 15:56:24 -0700 (PDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9306222247.AA22062@moose.wan.gs.com> from "Shabbir J Safdar" at Jun 22, 93 06:47:23 pm Content-Type: text Content-Length: 385 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I may be a hypocrite about running finger, but that's due to my paranoia. > > Paranoia's my job; I wasn't hired to promote the ideals of an open > Internet. I'd like to see it as much as the next person, but not at the > risk of a break-in at my site. But you have no problem exposing the rest of the internet to the crackers at your site. Or do only other sites have crackers? From Firewalls-Owner Tue Jun 22 23:17:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27832; Tue, 22 Jun 93 23:17:30 GMT Received: from lab.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27825; Tue, 22 Jun 93 16:17:16 PDT Received: by lab.cs.umb.edu id AA10801 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Tue, 22 Jun 1993 19:19:21 -0400 Date: Tue, 22 Jun 1993 19:19:21 -0400 From: "John B. Brown" Message-Id: <199306222319.AA10801@lab.cs.umb.edu> To: chk@alias.com, murphy@murphy.gun.com, safdas@gsco.com Subject: Re: You've got to be kidding me. Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Shabbir, On you write: > From: safdas@gsco.com (Shabbir J Safdar) > Message-Id: <9306222247.AA22062@moose.wan.gs.com> > I may be a hypocrite about running finger, but that's due to my paranoia. > Paranoia's my job; I wasn't hired to promote the ideals of an open > Internet. I'd like to see it as much as the next person, but not at the > risk of a break-in at my site. > -Shabbir If every site disallows finger, what use running finger at your site, through the firewall or not?? Shalom, JBB. From Firewalls-Owner Tue Jun 22 23:23:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27958; Tue, 22 Jun 93 23:23:27 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27951; Tue, 22 Jun 93 16:23:20 PDT Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA18442; Tue, 22 Jun 93 18:23:44 CDT Date: Tue, 22 Jun 93 18:23:44 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9306222323.AA18442@tadpole.tadpole.com> To: murphy@murphy.gun.com, chk@alias.com, safdas@gsco.com Subject: Re: You've got to be kidding me. Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I never did belive the arguements about getting access to login names via finger, etc. I still don't. Anyone who really wants to get 'in' will first attempt to guess login/host names. Or they'll get them from mail/news headers, etc. Information hiding isn't very effective against the determined theif. However, one fine night, while employed at (previous-employer-who-shall-remain-nameless), I noticed a very long running finger, with arguements like: finger #/path/to/source/tree/file.c@host.east.foo.COM. comming in from somwwhere.edu. "Very nice.", said I. A finger hack to let you read files. Finger forwarding via the firewall let this user read the files of his (it was a he) choice, from outside the 'wall. Given that the company has a very large number of Suns installed, with automounter running all over the place, this individual (and anyone else he told about the hack) had effective access to some large percentage of files, anywhere on the worl-wide network. (finger #/net/host.eng.foo.COM/...) Shortly thereafter, the modified in.fingerd got installed. Since a huge number of employees inside the firewall would have left nasty messages in my (voice)/mailbox I left outgoing forwarding 'on'. Caught the guy, had him nailed-to-the-wall evidence-wise, but they wouldn't even file a complaint. In fact, he worked for the company again the next summer. Jim From Firewalls-Owner Tue Jun 22 23:40:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28012; Tue, 22 Jun 93 23:40:35 GMT Received: from gsco.com (mach1.gsco.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28005; Tue, 22 Jun 93 16:40:22 PDT Received: from gs.com (postoffice1.gsco.com) by gsco.com (4.1/SMI-4.1) id AA29374; Tue, 22 Jun 93 19:48:11 EDT Received: from moose.wan.gs.com by gs.com (4.1/SMI-4.1) id AA03337; Tue, 22 Jun 93 19:43:34 EDT Received: by moose.wan.gs.com (4.1/SMI-4.1) id AA22128; Tue, 22 Jun 93 19:42:05 EDT Date: Tue, 22 Jun 93 19:42:05 EDT From: safdas@gsco.com (Shabbir J Safdar) Message-Id: <9306222342.AA22128@moose.wan.gs.com> To: safdas@gsco.com, randy@psg.com Subject: Re: You've got to be kidding me. Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From randy%psg.com@mvsemail.wan.gs.com Tue Jun 22 18:57:21 1993 > Date: Tuesday, 22 June 1993 6:57pm > But you have no problem exposing the rest of the internet to the crackers > at your site. Or do only other sites have crackers? I'm not exposing them. If they're concerned about security to the level I am (some have security requirements that high, some don't), then they shouldn't run it. Besides which, if there's a cracker at my site, they should want me to run some form of rfc 931 authentication, not fingerd. If enough people refuse to run it, perhaps we'll have a more secure information service built. However that still won't help sites who have business reasons for not exposing who is working at their site. Imagine for a second a site where the names of your clients are confidential. They're logging into your machine to perform some sort of business, but the fact that they are clients of yours should not be public knowledge. Companies like this are on the net, and they cannot allow this information to get out. You simply can't create, out of nowhere, a law of reciprocation for finger information. If you want to encourage personnel information exchange, go write me a daemon that allows me do some careful selection on a sybase database or something. Then convince me its secure. (ha) Then perhaps I'll run it. Let me say it simply: Sites that have differing security requirements don't all have equal responsibility to run fingerd. -Shabbir From Firewalls-Owner Wed Jun 23 00:18:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28076; Wed, 23 Jun 93 00:18:00 GMT Received: from extra.ucc.su.OZ.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28069; Tue, 22 Jun 93 17:17:41 PDT Received: from extro.ucc.su.OZ.AU by extra.ucc.su.OZ.AU with SMTP id AA25171 (5.65c/IDA-1.4.4 for ); Wed, 23 Jun 1993 10:18:44 +1000 Message-Id: <199306230018.AA25171@extra.ucc.su.OZ.AU> Date: Wed, 23 Jun 93 10:18:28 +1000 From: matth@ucc.su.OZ.AU Subject: Re: You've got to be kidding me. Apparently-To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ------- Blind-Carbon-Copy To: randy@psg.com (Randy Bush) Subject: Re: You've got to be kidding me. In-reply-to: Your message of "Tue, 22 Jun 93 15:56:24 MST." Date: Wed, 23 Jun 93 10:18:28 +1000 > But you have no problem exposing the rest of the internet to the crackers > at your site. Or do only other sites have crackers? This is really silly. Someone wants a solid door on their house. You're saying he shouldn't because other people don't have solid doors. Let me guess. These messages are coming from the new newssgroup? Start of the downward spiral into the level of quality of your average newsgroup. - -- -Matt ------- End of Blind-Carbon-Copy From Firewalls-Owner Wed Jun 23 01:41:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28172; Wed, 23 Jun 93 01:41:06 GMT Received: from erenj.com (ereapp.erenj.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28165; Tue, 22 Jun 93 18:40:56 PDT Received: by erenj.com (5.65/mjr-920806); id AA22963; Tue, 22 Jun 93 21:42:33 -0400 Received: by eredns.erenj.com (5.65/bdb-mailv1.3-erenj); id AA02333; Tue, 22 Jun 93 21:42:32 -0400 Received: by maverick1.erenj.com (5.57/bdb-mailv1.0); id AA19321; Tue, 22 Jun 93 21:42:31 -0400 Posted-Date: Tue, 22 Jun 1993 21:42:30 -0400 From: bdboyle@maverick1.erenj.com (Bryan D. Boyle) Message-Id: <9306222142.ZM19319@maverick1.erenj.com> Date: Tue, 22 Jun 1993 21:42:30 -0400 In-Reply-To: dmburns@amoco.com (David Burns) "procedures for handling executables ?" (Jun 22, 4:10pm) References: <9306222110.AA07922@pulsar.hou.amoco.com> X-Mailer: Z-Mail (2.1.0 10/1/92) To: dmburns@amoco.com (David Burns), Firewalls@GreatCircle.COM Subject: Re: procedures for handling executables ? Cc: wjryan@amoco.com, rwpowell@amoco.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Jun 22, 4:10pm, David Burns wrote: > Subject: procedures for handling executables ? > > Greetings - > > We are in the process of implementing an Internet gateway. Our management > is *very* concerned about importation of virii, worms, etc. via executables, > and has asked me to search for all reasonable ways/methods of mimimizing the > exposures. We have a large network, w/ at least one of just about everything. > > I think that we have a good grasp of the basic issues. I understand that > executables can be encoded, that not all binary data is bad, etc. I'm proposing > a policy based on user accountability and education. We will be able to > enforce it to some extent via filtering, and have audit logs for tracking events > after the fact. But I don't want to limit the users unnecessarily. > > However, management has asked me to (1) query any sources available, to check > for best practices among other companies (2) Look for 'virus > scrubbers" if such things exist for the unix environment and (3) consider > using an intermediate system (just inside the firewall, or as part of it) > as a 'sacrificial lamb' or cold storage system. > > I'm resisting the latter 2, but would like to find > out how others are handling the problem. I especially think that (3) would > be disdained and avoided by our user community. > > Note: I'm particularly interested in replies from other commercial interests, > and other sysadmins with similar problems and concerns. > > (This is my first post to this group; forgive me if this is an FAQ somewhere. > Also, if there are other, more appropriate groups, feel free to cross-post > and/or enlighten me. Flames to /dev/null please.) > > In advance, thanks to all who respond. > > David >-- End of excerpt from David Burns feel free to give me a call over here at exxon (unless there is some anti-trust...:-)); we faced the same things you did, are in the same business (making big $$$ :-)), and have a solution based on dec that provides 1) protection, 2) auditability, and 3) accountability. It works, it is nicely secure, and is a real flexible solution. office is 908 730-3338. (i didn't want to put this on the mailing list, but a good measure of the system we have in place is that it was chosen as the development platform of choice for the whitehouse.gov domain...) -- Bryan D. Boyle <>< |EMAIL: bdboyle@erenj.com #include |Hack first and ask questions later. 908 730-3338 |ER & E Co. Rt. 22 East, Annandale, NJ If "pro" is the opposite of "con", what is the opposite of "congress"? From Firewalls-Owner Wed Jun 23 02:46:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28341; Wed, 23 Jun 93 02:46:32 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28334; Tue, 22 Jun 93 19:46:25 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA21779; Tue, 22 Jun 93 22:49:40 EDT Date: Tue, 22 Jun 93 22:49:40 EDT From: Marcus J Ranum Message-Id: <9306230249.AA21779@TIS.COM> To: firewalls@GreatCircle.COM Subject: Re: Finger daemon for outbound firewall only? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Implementing outgoing finger, while denying incoming fingers, seems >*extremely* hypocritical to me. You want to be able to get (useful) >information about others, but not give out information yourselves? The degree of access which someone wishes to provide between their network and the Internet is their business, not ours. It's not a question of "hypocrisy" or any other value-laden term one cares to use. Internet connections are a tool - a valuable tool, and one that often comes with requirements from upper management or common sense. While it's nice to imagine that the Internet is a neighborly place, I don't think many of the folks on this list share that delusion. mjr. [We at TIS permit ourselves to finger folks on the internet but not vice versa. Just as we permit our machines to telnet out, and deny others the ability to telnet in.] From Firewalls-Owner Wed Jun 23 03:05:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28385; Wed, 23 Jun 93 03:05:18 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28378; Tue, 22 Jun 93 20:05:11 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA22017; Tue, 22 Jun 93 23:08:56 EDT Date: Tue, 22 Jun 93 23:08:56 EDT From: Marcus J Ranum Message-Id: <9306230308.AA22017@TIS.COM> To: firewalls@GreatCircle.COM Subject: Finger/security - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Getting login information's not the ONLY problem with finger. Lots of folks use .plan as a way of storing information about what projects they're working on and whatnot. Stuff that is arguably competitive information. Lots of corporations have written policies about data hiding. For example, at Digital, the corporate phone book is considered "corporate sensitive" information. Whether or not there are sound technical reasons for it, there are some sites where naming information MUST be hidden from the outside, by corporate fiat. If they're paying the bills, that's sufficient justification to overrule the technical arguments. Finger also tells where you last logged on from. That is useful for attacking systems via island-hopping. No, finger's not a big deal. Shutting it off is not a huge security win. The versions of finger with the hole that Morris' worm exploited have been fixed. But it seems like a sensible loophole to close, especially if you can close it only to outsiders. mjr. From Firewalls-Owner Wed Jun 23 03:39:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28436; Wed, 23 Jun 93 03:39:53 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28429; Tue, 22 Jun 93 20:39:42 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA22673; Tue, 22 Jun 93 23:43:25 EDT Date: Tue, 22 Jun 93 23:43:25 EDT From: Marcus J Ranum Message-Id: <9306230343.AA22673@TIS.COM> To: dmburns@amoco.com, firewalls@GreatCircle.COM Subject: Re: procedures for handling executables? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Scanning executables coming in from the Internet is a waste of time, by and large. There are several problems: 1) Stuff can be encoded in any of many formats, including uucp, binhex, and so on. this makes it hard to tell what is an executable being mailed in versus what is an obscene gif, versus what is a compressed uuencoded copy of an important large PostScript file, etc, etc. 2) Stuff that is FTPd has similar problems. 3) Stuff can be brought in for multiple architectures. I.e.: Mac, PC, or whatnot. Virus scanners tend to be architecture specific and look for simple signatures within the executable for that architecture. Most (but not all) virus scanners only run on the architecture they scan. So to scan for Mac virii, you have to unpack the file on the Mac and scan it. Since it's a Mac, it's inherently a manual procedure and thereby impractical for large volumes. DOS has similar problems, ditto Windows. Anything with a GUI. 4) Depending on your internet connection and how you set your firewall up, someone can STILL bring executables in by simply running kermit over telnet. And they will if there's some procedure in place that interferes with the All Important Software Immediate Gratification Factor. (I.e.: "I want to run this RIGHT NOW!") There's another subtle problem with perimeter defenses against virii: everyone gets lax and decides there's no WAY a virus could get on an internal machine. Right - and the world is flat. This is what Bill Cheswick calls the "Crunchy coating around a gooey center" problem. Fighting virii is something that is best done by educating users, making sure everyone has virus scanning software and runs it every so often, making sure that there's an organizational clearinghouse for disseminating virus information, and encouraging people to scan disks of new stuff before they install it. In other words, combine a defence in depth with education. Were it my responsibility to protect a large corporate network against virii (which it isn't, thank goodness) I'd go with the education and defence in depth strategy for the simple pragmatic reason of blame-spreading. Seriously. If virii are everyone's problem, then if a virus gets loose on the corporate net, the natives won't be chasing the firewall administrator through the halls with torches and pitchforks. Firewalls are a useful perimeter defence against intrusion, but I believe the virus problem, by its very nature, requires defence in depth. Putting the burden of virus control on the firewall is like putting a steel door on ONE door of your house. mjr. From Firewalls-Owner Wed Jun 23 16:15:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00699; Wed, 23 Jun 93 16:15:14 GMT Received: from udel.edu (louie.udel.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00692; Wed, 23 Jun 93 09:15:05 PDT Received: from pima.dtcc.edu by louie.udel.edu id aa26103; 23 Jun 93 12:07 EDT Received: by pima.dtcc.edu (5.4.2/5.40/1.0) id AA15596; Wed, 23 Jun 1993 12:07:22 -0400 Date: Wed, 23 Jun 1993 12:07:22 -0400 From: Ken Weaverling Message-Id: <9306231607.AA15596@pima.dtcc.edu> In-Reply-To: Marcus J Ranum "Finger/security -" (Jun 22, 23:08) X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: Marcus J Ranum , firewalls@GreatCircle.COM Subject: Re: Finger/security - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk While I agree that being able to finger corporate sites is a bad idea, I did want to mention one positive aspect of finger. As the systems administrator at a college, my duty not only lies in keeping outside intruders out, but making sure my users don't crack other systems. Whenever I notice one of my users telnet'ing out of the local machines, I determine what site they are logged into, and finger @that.site. Many fingers show where you are logged in from. I can then determine what account on the foreign machine my user is using. If that account isn't either in their own name, or a public account, I will basically crucify the user. My policy is strict. You can only use your own account, whether it is here or at another site. It doesn't matter if the other user has given you permission to use it, it is forbidden. But along those lines, I am fairly liberal at giving out guest accounts. If someone's boyfriend is in town for a month and wants to keep in touch with home, I would much rather assign him a temporary guest account in his own name, then to have him sneak onto his girl friend's student account. I am getting off the topic, as usual for me! :-) -- Ken Weaverling, Sys Admin/Faith Healer Delaware Tech College weave@dtcc.edu From Firewalls-Owner Wed Jun 23 16:41:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00744; Wed, 23 Jun 93 16:41:08 GMT Received: from UAFSYSB.UARK.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00737; Wed, 23 Jun 93 09:40:45 PDT Message-Id: <9306231640.AA00737@mycroft.GreatCircle.COM> Received: from UAFSYSB.UARK.EDU by UAFSYSB.UARK.EDU (IBM VM SMTP V2R2) with BSMTP id 2540; Wed, 23 Jun 93 11:41:50 CDT Received: from UAFSYSB (NJE origin SAMARAK@UAFSYSB) by UAFSYSB.UARK.EDU (LMail V1.1d/1.7f) with BSMTP id 5001; Wed, 23 Jun 1993 11:41:50 -0500 Date: Wed, 23 Jun 93 11:05:20 CDT From: Steve Marak Subject: Procedures for handling executables? To: Firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk David (Burns), I also work for a large company currently setting up an Internet gateway, and face exactly the problems you describe, including the one about executables. (Perhaps we should compare some notes?) Marcus Raman raises some good points, in fact points that people at my company have already raised with me. And I'm unable to argue, because I agree with most of it. I too believe that a knowledgable person who is determined to do so will be able to get an unscanned executable in unless I shut their net access off entirely, and that it is unlikely I will catch all viruses at the firewall. However, I'm determined to make the attempt, for the following reasons: (1) I will be able to catch most DOS viruses at the firewall, therefore I should do so (on the principle that being unable to remove every risk doesn't reduce my obligation to remove the ones I can) (2) many (most) of the ways to import an unscanned executable involve someone in my company deliberately going to some trouble to do so. Now since I'll have made virus scanners available to them both on the UNIX firewall and their DOS LAN (and it's in their interest as well as mine to use them), and anyone who gets external net access will have to sign off on the usage rules, if I catch anyone deliberately importing and running an unscanned executable I'll have their head. It's easier for me at a commercial site than for those at, say, academic institutions, since although we have one of about everything, the overall distribution is heavily skewed in favor of DOS/WINDOWS on one side, and only a couple of UNIX systems on the other. (Plus we seem to get more cooperation from our customers than what my friends in academia tell me they get.) I've done some research into DOS virus scanners for the UNIX environment ... if you're interested, send me a note. Steve Marak SAMARAK@UAFSYSB.BITNET or SAMARAK@UAFSYSB.UARK.EDU From Firewalls-Owner Wed Jun 23 18:40:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01241; Wed, 23 Jun 93 18:40:16 GMT Received: from netcomsv.netcom.com (uucp4.netcom.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01234; Wed, 23 Jun 93 11:40:09 PDT Received: from fabian.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1) id AA17192; Wed, 23 Jun 93 11:42:34 PDT Received: from [192.160.241.2] (skyline) by LAT.COM (4.1/SMI-4.1/Brent-LAT.COM-930611-1) id AA09102; Wed, 23 Jun 93 11:06:42 PDT Date: Wed, 23 Jun 93 11:06:42 PDT Message-Id: <9306231806.AA09102@LAT.COM> From: "Gary Kremen [gary@lat.com]" Reply-To: "Gary Kremen [gary@lat.com]" To: Firewalls@GreatCircle.COM Subject: Re: Subject: procedures for handling executables Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: dmburns@amoco.com (David Burns) > Date: Tue, 22 Jun 93 16:10:02 CDT > Subject: procedures for handling executables ? > > Greetings - > > We are in the process of implementing an Internet gateway. Our management > is *very* concerned about importation of virii, worms, etc. via executables, > and has asked me to search for all reasonable ways/methods of mimimizing the > exposures. We have a large network, w/ at least one of just about everything. > > However, management has asked me to (1) query any sources available, to check > for best practices among other companies (2) Look for 'virus > scrubbers" if such things exist for the unix environment and (3) consider > using an intermediate system (just inside the firewall, or as part of it) > as a 'sacrificial lamb' or cold storage system. A commercial UNIX product for #2 exists using a cryptologically strong checksum. It is called Fortress and we co-developed it with WTI. It is a UNIX World Product of the Month. Fortress has four main modules with a integrated graphical user interface. The modules are: file inoculation, worm protection, Trojan horse detection and password inspection. Fortress currently runs on SUN SPARC systems. We also have several other UNIX security programs - just send me mail for more details. Sorry for the commercial message but it is quite a good product. Of course, your best bet is to have proper and appropriate corporate security policies. _____________________________________________________________________________ Gary Kremen This mail is from either Los Altos Technologies, Inc. gary@lat.com or gary@192.160.241.1 From Firewalls-Owner Wed Jun 23 22:57:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01616; Wed, 23 Jun 93 22:57:23 GMT Received: from bunyip.cc.uq.oz.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01609; Wed, 23 Jun 93 15:57:09 PDT Message-Id: <9306232257.AA01609@mycroft.GreatCircle.COM> Received: from fitmail.fit.qut.edu.au by bunyip.cc.uq.oz.au with SMTP (PP); Thu, 24 Jun 1993 08:58:35 +1000 Received: from sleet.fit.qut.edu.au by fitmail.fit.qut.edu.au with SMTP (16.8/16.2) id AA22261; Thu, 24 Jun 93 08:56:55 +1000 Received: by sleet.fit.qut.edu.au (16.8/16.2) id AA03528; Thu, 24 Jun 93 08:56:40 +1000 From: Mr Brian Meilak Subject: Wellfleet Routers To: Firewalls@GreatCircle.COM Date: Thu, 24 Jun 93 8:56:39 EST X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk hi all, while where all talking about routers, I have a question about Wellfleets. In the wellfleet manual on filtering IP packets, it mentions that the filters are only applied to incoming packets. What do they mean by 'incoming packets'? Are they packets going to the router or packets leaving the router(ie into the network)? ---------- subnet | router | ----------------------| ---------- -> | incoming into subnet? ^ | incoming to | | router? | thanks bjm ======================================================================= Brian Meilak AARnet: meilak@fitmail.fit.qut.edu.au Computer Systems Officer ARPA: meilak@qut.edu.au Phone: +61 7 864-1249 _--_|\ School of Computing Science, / QUT Queensland University of Technology, \_.--._/ Box 2434, Brisbane 4001, AUSTRALIA v Phone: +61 7 864-2132 Fax: 864-1801 ======================================================================= From Firewalls-Owner Thu Jun 24 05:19:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02157; Thu, 24 Jun 93 05:19:58 GMT Received: from das.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02150; Wed, 23 Jun 93 22:19:49 PDT Received: from elf.wang.com by das.wang.com with SMTP id AA03376 (5.65c/IDA-1.5 for ); Thu, 24 Jun 1993 01:21:12 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA15767 (5.65c/IDA-1.5); Thu, 24 Jun 1993 01:21:03 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA18210; Thu, 24 Jun 1993 01:20:59 -0400 From: Tom Fitzgerald Message-Id: <199306240520.AA18210@fnord.wang.com> Subject: Re: Finger daemon for outbound firewall only? To: chk@alias.com (C. Harald Koch) Date: Thu, 24 Jun 93 1:20:58 EDT Cc: safdas@gsco.com, firewalls@GreatCircle.COM In-Reply-To: <9306222121.AA11815@dino.alias.com>; from "C. Harald Koch" at Jun 22, 93 6:21 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Implementing outgoing finger, while denying incoming fingers, seems > *extremely* hypocritical to me. You want to be able to get (useful) > information about others, but not give out information yourselves? It's perfectly reasonable to have a server that allows outgoing fingers transparently but responds to incoming fingers itself with some limited information. The one here lists only full-names and e-mail addresses, but does so for most of the company, not just users who happen to be on the firewall system itself (if any). finger is nice for finding e-mail addresses, which is worth preserving. It's also useful for finding login names, last-logged-in times, and such, which we want to hide. -- Tom Fitzgerald Wang Labs fitz@wang.com "I went to the universe today; 1-508-967-5278 Lowell MA, USA It was closed...." From Firewalls-Owner Thu Jun 24 12:58:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03335; Thu, 24 Jun 93 12:58:20 GMT Received: from sun2.nsfnet-relay.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03328; Thu, 24 Jun 93 05:58:09 PDT Via: uk.ac.cambridge.mrc-biostatistics; Thu, 24 Jun 1993 13:59:20 +0100 Received: from jenny.mrc-bsu.cam.ac.uk by keith.mrc-bsu.cam.ac.uk with UK-Sendmail (4.1/UK-2.1-BSU); Thu, 24 Jun 93 13:58:23 BST From: Calum Mackay Date: Thu, 24 Jun 93 13:58:24 BST Message-Id: <826.9306241258@jenny.mrc-bsu.cam.ac.uk> To: firewalls@GreatCircle.COM Subject: allowing ftp through Cisco router Cc: calum.mackay@mrc-biostatistics.cambridge.ac.uk Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Firewallers, I'm a bit stuck as to something and would appreciate a quick bit of advice. I've been following the ftp debate (*not* fsp) on the firewalls list, and am unsure how to proceed. We would like to allow our firewall machine to initiate ftp requests to an ftp server on the outside of our Cisco router, but due to the FTP-DATA connection being initiated by the ftp server, and Cisco's inability to filter on dest port, I can only acheive a connection by letting in any tcp packets port > 1023, which I am loathe to do. The two suggested workarounds seem to be: 1) hack ftp.c so that the client requests that the server use a port number chosen from a small range, rather than from 1024-65K 2) take advantage of the passive data conection request in the ftp protocol, so that the client can initiate the connection. Of the two 2) seems much better but I cannot find a suitable client (in source form) that accomplishes this, and i dont wish to implement it myself. Of course it may not work with many external servers? Do you have any advice/suggestions/comments on this problem, please? Best Regards, Calum. *_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_* Calum D. Mackay System Administrator Medical Research Council Telephone: 0223 330378 Biostatistics Unit International: +44 223 330378 IPH, University Forvie Site JANET: calum.mackay@uk.ac.cam.mrc-bsu Robinson Way Internet: calum.mackay@mrc-bsu.cam.ac.uk Cambridge CB2 2SR. alternative: cdm12@cus.cam.ac.uk ENGLAND. last resort: cdm12@phx.cam.ac.uk _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From Firewalls-Owner Thu Jun 24 17:26:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03876; Thu, 24 Jun 93 17:26:03 GMT Received: from macsch.com (DRACO.MACSCH.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03867; Thu, 24 Jun 93 10:25:55 PDT Received: from [161.34.1.6] by macsch.com (5.61/SMI-4.1-07) id AA28546; Thu, 24 Jun 93 10:28:08 -0700 Received: from canismajor.is.macsch.com by convex.is.macsch.com (5.64/2.0) id AA13332; Thu, 24 Jun 93 10:27:48 -0700 Received: by canismajor.is.macsch.com (4.1/2.0) id AA23989; Thu, 24 Jun 93 10:28:04 PDT Date: Thu, 24 Jun 93 10:28:04 PDT From: todd@macsch.com (Todd Williams) Message-Id: <9306241728.AA23989@canismajor.is.macsch.com> To: firewalls@GreatCircle.COM Subject: Re: allowing ftp through Cisco router Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 1:58pm on Thu Jun 24 1993, Calum Mackay said: > > We would like to allow our firewall machine to initiate ftp requests to an > ftp server on the outside of our Cisco router, but due to the FTP-DATA > connection being initiated by the ftp server, and Cisco's inability to filter > on dest port, I can only acheive a connection by letting in any tcp > packets port > 1023, which I am loathe to do. I must be missing something here. I think that in order to have SMTP communcations between two machines, you need to allow port 25 and all ports >1023. The CISCO access list looks like this, for two machines, one with an IP address of 1.1.1.1 and the other with 2.2.2.2: access-list 1 permit tcp 1.1.1.1 0.0.0.0 2.2.2.2 0.0.0.0 eq 25 access-list 1 permit tcp 1.1.1.1 0.0.0.0 2.2.2.2 0.0.0.0 gt 1023 But since port 20 is "ftp" and port 21 is "ftp/data", I thought if you just wanted ftp you could just allow those two ports: access-list 1 permit tcp 1.1.1.1 0.0.0.0 2.2.2.2 0.0.0.0 eq 20 access-list 1 permit tcp 1.1.1.1 0.0.0.0 2.2.2.2 0.0.0.0 eq 21 This stuff is not covered well in the CISCO manuals. Does anybody have a good summary of this type of information, which is often discussed here? I think the other way to solve the problem is using something called the "established" keyword, where the return packets are allowed only if there has already been a requested established on a known port. I think you need some fairly recent CISCO software to use this feature. (please, somebody, let me know if this makes sense!) Todd Williams UNIX Systems Supervisor todd@macsch.com (213) 259-4973 MacNeal-Schwendler Corp. ("MSC"), 815 Colorado Blvd., Los Angeles, CA 90041 "Solaris 2.0 -- It's enough to make you leave the company." -Rob Kolstad From Firewalls-Owner Thu Jun 24 19:57:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04134; Thu, 24 Jun 93 19:57:36 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04127; Thu, 24 Jun 93 12:57:24 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA07128 for ; Thu, 24 Jun 93 15:55:47 -0400 Received: from stimpys.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA03702; Thu, 24 Jun 93 15:21:09 EDT Received: from localhost by stimpys.imsi.com (4.1/SMI-4.1) id AA09957; Thu, 24 Jun 93 15:17:32 EDT Message-Id: <9306241917.AA09957@stimpys.imsi.com> To: todd@macsch.com (Todd Williams) Cc: firewalls@GreatCircle.COM, calum.mackay@mrc-bsu.cam.ac.uk Subject: Re: allowing ftp through Cisco router In-Reply-To: Your message of "Thu, 24 Jun 1993 10:28:04 PDT." <9306241728.AA23989@canismajor.is.macsch.com> Reply-To: rens@imsi.com Date: Thu, 24 Jun 1993 15:17:32 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Thu, 24 Jun 93 10:28:04 PDT, todd@macsch.com (Todd Williams) said: todd> At 1:58pm on Thu Jun 24 1993, Calum Mackay said: calum> We would like to allow our firewall machine to initiate ftp calum> requests to an ftp server on the outside of our Cisco router, calum> but due to the FTP-DATA connection being initiated by the ftp calum> server, and Cisco's inability to filter on dest port, I can calum> only acheive a connection by letting in any tcp packets port calum> > 1023, which I am loathe to do. todd> But since port 20 is "ftp" and port 21 is "ftp/data", I todd> thought if you just wanted ftp you could just allow those two todd> ports: todd> I think the other way to solve the problem is using something todd> called the "established" keyword, where the return packets are todd> allowed only if there has already been a requested established todd> on a known port. I think you need some fairly recent CISCO todd> software to use this feature. The problem is not that FTP uses two separate channels, but that the data channel requires an INCOMING connection from port 21 TO a dynamically assigned port on the "safe" side of the firewall. Since these destination ports are always in the dynamic range, blocking access to ports below 1024 keeps would-be attackers from the lower, well-known ports. Unfortunately, this is inadequate, since many crucial services (X11, sybase) wait on sockets in the so-called dynamic range. Thus, this is not really secure. I use one of two approaches to this problem (it is also a problem with rlogin, which similarly does a passive open for the control connection): 1> allow incoming TCP in a range (say 1024 - 5000) and MAKE SURE NOTHING ON THE NETWORK is listening in that range (almost impossible) 2> Same as #1, but only allow icoming connections of this sort to a few machines (the "ftp access machines") More practical, but still a little dangerous. 3> prohibit routed FTP connections, and use a proxy server or application-level gateway ( Sun has a good one which costs $$$, David Koblas' "socks" package is free for the C-literate ) for outbound FTP. I tend to prefer solution #3, since it gives me the most security (basically _no_ incoming connections) and I still get to make outbound connections on all other ports. Note that the FTP data source port, 21, is irrelevant for secure firewalling. Assume the source port and address of all incoming connections to your network are always forged, since at some point that assumption will be true. I hope that was helpful, mail me if I was too confusing! -Rens From Firewalls-Owner Fri Jun 25 13:47:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06733; Fri, 25 Jun 93 13:47:59 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06726; Fri, 25 Jun 93 06:47:53 PDT Received: from otter.TIS.COM.tis.com by TIS.COM (4.1/SUN-5.64) id AA04584; Fri, 25 Jun 93 09:51:49 EDT Received: by otter.TIS.COM.tis.com (5.65/client) id AA00248; Fri, 25 Jun 93 09:40:51 -0400 From: mjr@TIS.COM Date: Fri, 25 Jun 93 09:40:51 -0400 Message-Id: <248.9306251340@otter.TIS.COM> To: firewalls@GreatCircle.COM Subject: Firewall FAQ?? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Is it time for a FAQ for this mailing list/firewalls in general? If there's a strong feeling in favor, I'd be willing to maintain it. Email me if you think it's a good or bad idea, unless you think it's worth discussing in front of the whole list. If there's a sentiment that it's worth doing, I'll accept questions and try to find some folks to write up answers. mjr. From Firewalls-Owner Fri Jun 25 14:57:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06861; Fri, 25 Jun 93 14:57:27 GMT Received: from tigger.jvnc.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06853; Fri, 25 Jun 93 07:57:16 PDT Received: by tigger.jvnc.net id AA14361 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Fri, 25 Jun 1993 10:59:38 -0400 Date: Fri, 25 Jun 1993 10:59:38 -0400 From: Moodys Investors Service Message-Id: <199306251459.AA14361@tigger.jvnc.net> To: firewalls@GreatCircle.COM Subject: socks (was letting ftp...) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ############ rens@imsi.com writes> 3> prohibit routed FTP connections, and use a proxy server or application-level gateway ( Sun has a good one which costs $$$, David Koblas' "socks" package is free for the C-literate... ########### I wonder> How about the C-*semi*-literate: I tried to compile this (and quite a few other insecurity apps) w/o total success (EXCEPT for the North European strain- of course throw in linux.) ^^^^^^ Since I have a sparc env, I figgered that the % of usable apps would be proportional to [explitive-deleted] Sun's market share. I work my butt off (and get paid for it) and, even though I learned turbo-C at the get go- my [our] open networks users use up all of my time and I wind up feeling like an inner-city gym teacher. So I'm going to use my vacation to bone up on C but I'll probably never catch up with, for instance, "black hats" w/ nothing better to do than harrass sys admins. Yours- John van Vlaanderen aka moodys@tigger.jvnc.net From Firewalls-Owner Fri Jun 25 15:19:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06899; Fri, 25 Jun 93 15:19:43 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06892; Fri, 25 Jun 93 08:19:36 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA10496; Fri, 25 Jun 93 11:23:34 EDT Date: Fri, 25 Jun 93 11:23:34 EDT From: Marcus J Ranum Message-Id: <9306251523.AA10496@TIS.COM> To: firewalls@GreatCircle.COM Subject: firewalls FAQ - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Ok, ok, ok... Stop sending mail mail saying "YES!" already.. ;) Everyone seems very much in favor of my starting a FAQ. I'll start gathering questions and suggestions [just mail 'em to me]. This'll not be a single person effort - a few folks have already offered to help maintain stuff. We'll just see where things go from there. mjr. From Firewalls-Owner Fri Jun 25 16:49:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07107; Fri, 25 Jun 93 16:49:41 GMT Received: from macsch.com (DRACO.MACSCH.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07100; Fri, 25 Jun 93 09:49:33 PDT Received: from [161.34.1.6] by macsch.com (5.61/SMI-4.1-07) id AA26782; Fri, 25 Jun 93 09:51:57 -0700 Received: from canismajor.is.macsch.com by convex.is.macsch.com (5.64/2.0) id AA22880; Fri, 25 Jun 93 09:50:50 -0700 Received: by canismajor.is.macsch.com (4.1/2.0) id AA28833; Fri, 25 Jun 93 09:51:54 PDT Date: Fri, 25 Jun 93 09:51:54 PDT From: todd@macsch.com (Todd Williams) Message-Id: <9306251651.AA28833@canismajor.is.macsch.com> To: firewalls@GreatCircle.COM, mjr@TIS.COM Subject: Re: firewalls FAQ - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 11:23am on Fri Jun 25 1993, Marcus J Ranum said: > > Ok, ok, ok... Stop sending mail mail saying "YES!" already.. ;) oops! I'm glad you got such a positive response! > Everyone seems very much in favor of my starting a FAQ. > I'll start gathering questions and suggestions [just mail 'em > to me]. I already did. > This'll not be a single person effort - a few folks have > already offered to help maintain stuff. Like I said, feel free to include me. Todd Williams UNIX Systems Supervisor todd@macsch.com (213) 259-4973 MacNeal-Schwendler Corp. ("MSC"), 815 Colorado Blvd., Los Angeles, CA 90041 "Solaris 2.0 -- It's enough to make you leave the company." -Rob Kolstad From Firewalls-Owner Fri Jun 25 18:44:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07850; Fri, 25 Jun 93 18:44:09 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07843; Fri, 25 Jun 93 11:43:43 PDT Received: from futureworld.advtech.uswest.com.advtech.uswest.com (futureworld.advtech.uswest.com) by uswat.advtech.uswest.com with SMTP id AA25152 (5.65c/IDA-1.4.4 for ); Fri, 25 Jun 1993 12:45:16 -0600 Received: from localhost.uswest.com by futureworld.advtech.uswest.com.advtech.uswest.com (advtech.uswest.com) id AA01651 (4.1/at-generic.18Mar93); Fri, 25 Jun 93 12:44:54 MDT Message-Id: <9306251844.AA01651@futureworld.advtech.uswest.com.advtech.uswest.com> To: rens@imsi.com Cc: todd@macsch.com (Todd Williams), firewalls@GreatCircle.COM, calum.mackay@mrc-bsu.cam.ac.uk Subject: Re: allowing ftp through Cisco router In-Reply-To: Your message of "Thu, 24 Jun 1993 15:17:32 EDT." <9306241917.AA09957@stimpys.imsi.com> Date: Fri, 25 Jun 1993 12:44:53 -0600 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > 3> prohibit routed FTP connections, and use a proxy server or > application-level gateway ( Sun has a good one which costs $$$, > David Koblas' "socks" package is free for the C-literate ) for > outbound FTP. FYI, sells a proxy-ftp gateway (normally they sell this as part of a complete firewall setup). It's compatible with, and works much better than Sun's product (IGATEWAY). brad From Firewalls-Owner Fri Jun 25 19:47:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07930; Fri, 25 Jun 93 19:47:17 GMT Received: from tadpole.tadpole.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07923; Fri, 25 Jun 93 12:47:09 PDT Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA11744; Fri, 25 Jun 93 14:48:51 CDT Date: Fri, 25 Jun 93 14:48:51 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9306251948.AA11744@tadpole.tadpole.com> To: rens@imsi.com, huntting@advtech.uswest.com Subject: Re: allowing ftp through Cisco router Cc: todd@macsch.com, firewalls@GreatCircle.COM, calum.mackay@mrc-bsu.cam.ac.uk Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > and works much better than Sun's product (IGATEWAY). Hmm, shouldn't be too hard. A week's worth of work would be more than IGATEWAY has had. :-) Jim From Firewalls-Owner Fri Jun 25 20:12:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07976; Fri, 25 Jun 93 20:12:13 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07969; Fri, 25 Jun 93 13:12:02 PDT Received: from futureworld.advtech.uswest.com.advtech.uswest.com (futureworld.advtech.uswest.com) by uswat.advtech.uswest.com with SMTP id AA26853 (5.65c/IDA-1.4.4 for ); Fri, 25 Jun 1993 14:14:25 -0600 Received: from localhost.uswest.com by futureworld.advtech.uswest.com.advtech.uswest.com (advtech.uswest.com) id AA02023 (4.1/at-generic.18Mar93); Fri, 25 Jun 93 14:14:23 MDT Message-Id: <9306252014.AA02023@futureworld.advtech.uswest.com.advtech.uswest.com> To: jim@tadpole.com (Jim Thompson), firewalls@GreatCircle.COM Subject: Re: allowing ftp through Cisco router In-Reply-To: Your message of "Fri, 25 Jun 1993 14:48:00 CDT." <9306251948.AA11738@tadpole.tadpole.com> Date: Fri, 25 Jun 1993 14:14:22 -0600 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I write: > FYI, sells a proxy-ftp gateway (normally they sell this as part of a > complete firewall setup). It's compatible with, and works much better > than Sun's product (IGATEWAY). Jim writes: > Who? Oops... DEC, specifically Marcus J Ranum although recent postings to this list doesn't appear to be from dec.com. Marcus? Any ideas how would one get ahold of your telnet/ftp package these days? brad From Firewalls-Owner Fri Jun 25 20:19:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07997; Fri, 25 Jun 93 20:19:21 GMT Received: from volitans.MorningStar.Com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07990; Fri, 25 Jun 93 13:19:07 PDT Received: from remora.MorningStar.Com by volitans.MorningStar.Com (5.65a/93052901) id AA05891; Fri, 25 Jun 93 16:21:16 -0400 Received: by remora.MorningStar.Com (5.65a/93052901) id AA01806; Fri, 25 Jun 93 16:21:14 -0400 Date: Fri, 25 Jun 93 16:21:14 -0400 From: Karl Fox Message-Id: <9306252021.AA01806@remora.MorningStar.Com> To: firewalls@GreatCircle.COM Cc: todd@macsch.com (Todd Williams) In-Reply-To: todd@macsch.com's message of Thu, 24 Jun 1993 17:28:04 GMT Subject: Re: allowing ftp through Cisco router Organization: Morning Star Technologies, Inc. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Todd Williams wrote: I must be missing something here. I think that in order to have SMTP communcations between two machines, you need to allow port 25 and all ports >1023. Be very careful -- if you have any daemons listening on ports above 1023 such a restriction will allow a clever hacker to get through to them past your packet filter. Saying if ((srcport == 25 && destport > 1023) || (destport == 25 && srcport > 1023)) permit; else deny; isn't good enough; it can be spoofed. You need to also block incoming packets that our PPP would log like this: tcp 137.175.2.7/6000 <- nasty.hacker.org/25 44 syn I.e., you can't trust the remote client to use a port > 1023. Use this instead: if ((srcport == 25 && destport > 1023 && established) || (destport == 25 && srcport > 1023)) permit; else deny; where `established' means `this packet does not have the SYN bit on and the ACK bit off', which I suspect is the meaning Cisco uses. From Firewalls-Owner Fri Jun 25 21:02:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08056; Fri, 25 Jun 93 21:02:29 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08049; Fri, 25 Jun 93 14:02:23 PDT Message-Id: <9306252102.AA08049@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Fri Jun 25 17:01:37 EDT 1993 To: Karl Fox Cc: firewalls@GreatCircle.COM, todd@macsch.com (Todd Williams) Subject: Re: allowing ftp through Cisco router Date: Fri, 25 Jun 93 17:01:37 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Let me repeat an earlier note of mine. I hacked the ftp client from ftp.uu.net to issue a PASV command; this has the effect of making the data channel use an outgoing call, which eliminates the whole problem. I can't give my code out, but it's not particularly hard; there was only one subtle point, which I'll be happy to discuss with anyone who can implement a public version. --Steve Bellovin From Firewalls-Owner Sat Jun 26 02:14:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08697; Sat, 26 Jun 93 02:14:25 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08690; Fri, 25 Jun 93 19:14:18 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA05164; Fri, 25 Jun 93 22:18:16 EDT Date: Fri, 25 Jun 93 22:18:16 EDT From: Marcus J Ranum Message-Id: <9306260218.AA05164@TIS.COM> To: firewalls@GreatCircle.COM Subject: Re: allowing ftp through Cisco router Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: Brad Huntting >DEC, specifically Marcus J Ranum although recent postings >to this list doesn't appear to be from dec.com. Marcus? Any ideas how >would one get ahold of your telnet/ftp package these days? DEC SEAL still has some life as a product, despite DEC's recent hard times - I suspect t the contact mailing list seal@pa.dec.com is still active. Note that the sale of the firewall components to Brad was a one-time thing that was arranged because, well, it seemed like a sensible thing to do. Normally SEAL is sold as a complete consulting package. For what it's worth, TIS, as part of a research contract with ARPA, in which we've been doing some firewalls work, is implementing a firewall toolkit that we hope to make parts of widely available. We hope to be talking about it at some USENIX or other. mjr. From Firewalls-Owner Sat Jun 26 20:53:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10530; Sat, 26 Jun 93 20:53:50 GMT Received: from dcsp.llnl.gov (sourcery.tis.llnl.gov) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10523; Sat, 26 Jun 93 13:53:39 PDT Received: by dcsp.llnl.gov (4.1/LLNL-2.0) id AA05434; Sat, 26 Jun 93 13:55:40 PDT Message-Id: <9306262055.AA05434@dcsp.llnl.gov> To: firewalls@GreatCircle.COM Subject: Firewalls and MBONE Date: Sat, 26 Jun 93 13:55:39 -0700 From: Shawn Instenes Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk During the Firewalls BOF at Summer USENIX in Cincinnati, an interesting question came up: "Has anybody got MBONE running behind a firewall?" Since I have been working with MBONE for a couple of months now and in addition I'll soon be working with a firewalled site to connect to MBONE, I thought I'd whip up this introduction to the topic. MBONE stands for "multicast backbone". Multicast IP has been lurking in the RFC's for quite some time; they are class D addresses (classes A-C are the familiar IP ranges we're used to, D is multicast, and E is for experimental IP work.) It is similar to broadcast packets on an ethernet in that there can be more than one receiving machine for each packet; the application programs on those machines inform the multicast-enabled kernel that they wish to be notified of packets coming from a particular multicast address/port pair. It's different from broadcast in that these packets do not bother _everyone_, just those machines (kernels) that have expressed interest in receiving them. I like to describe this process like this: "Your programs are subscribing to an IP newsgroup, read IP news for a while, and unsubscribe when they're done." The three most used multicast applications are _vat_ (Visual Audio Tool), which handles the audio portions of broadcasts, _nv_ (Net Video) which handles the video, and _sd_ (Session Directory) which provides an advertising service so that potential listeners can find multicast IP/port numbers in use, and what they are being used for. Sending audio requires nothing more than a Sparcstation with a microphone, but video requires a frame capture board (several are supported). Receiving broadcasts requires no hardware at all, but may require kernel changes; for example Suns running 4.1.X do not support multicast out of the box, but you can patch the kernel to deal with them properly. To find out more about multicast applications, get more detail of the workings of MBONE, find out how you can start using it yourself, or get more accurate data about the topic so you can correct me later, look in the MBONE FAQ file on venera.isi.edu:mbone/faq.txt. The FAQ file also contains email addresses for discussion lists and FTP pointers to the software. So, a lot of neat stuff is going over this virtual-network-on-a-network. Your users behind a firewall are screaming, "Gimmie! Gimmie!" Now what? The first problem is the fact that most routers do not support multicast packets, therefore don't know what to do when they get one, and tend to drop it on the floor, which soon gets sticky with decomposing packets. Ick. (This problem will go away as router vendors work on implementing MOSPF, a multicast extension to the OSPF routing protocol.) Not all is lost, however, as there is software written to solve this problem. _mrouted_ encapulates multicast IP packets within normal IP packets, which are routed like any other IP packet. These virtual point-to-point links are called _tunnels_. A machine running mrouted routes multicast packets to and from the tunnels it has, so only one machine on a local net (for purposes of multicast, a local net is a net that is not connected by routers, but perhaps by repeaters) has to run mrouted, and the rest of the machines on its net can listen to the "real" multicast packets that the tunnel host forwards onto the ethernet. To set up a tunnel, both hosts involved must put their peer's IP number into a configuration file; therefore to get multicast packets from MBONE you must arrange with someone who is already on MBONE. In that regard it's a lot like UUCP is. Multicast by itself presents no problems in a firewall configuration; you can multicast all you like between your internal hosts. It is only when your users wish to receive external multicasts (or send them!) that you have to be concerned about the security implications. Typically, a hole must be opened in the router filters to allow the encapsulated multicast packets in and out of your firewall. Fortunately, the hosts that the tunnel packets are coming from and going to are both known in advance. Unfortunately, these packets are not UDP or TCP packets, but just IP packets, protocol number 4 (which means the next protocol is IP). If your filtering routers do not support a filter language that allows you to describe filtering on arbitrary byte offsets within the IP header, you may have to open up to ALL kinds of packets between the external tunnel host(s) and your internal tunnel host(s). Limiting the encapsulation tunnels with the filtering routers is the first defense. Next, the mrouted configuration lines for encapsulated tunnels look something like this: tunnel The internal and external IP numbers are self explanatory. The metric field indicates how far the tunnel traverses; a low number means a local network, while higher numbers would indicate transatlantic links. Typical values are 1 for a local net, 3 for a network farther away but perhaps connected via T1, and 5 for real slow/undesirable links. But especially important is the threshold value; it is a byte value that indicates the value that the TTL in the packet must exceed in order to be forwarded through that tunnel. For example, international conferences are sent with TTL values of 192; local conferences (perhaps just at one site or network) might have a TTL value of 16. By setting the threshold value to something in between (32 is commonly used) local traffic is never sent over long-distance tunnels. For most links, the threshold value is set to the same number on BOTH ends of the tunnel; but there is no reason why it must be that way. For a firewall configuration, it may be more appropriate to set the outbound threshold value to 255, so that mrouted (actually the kernel of the machine mrouted runs on) will never forward any packets out through that tunnel. This is just fine for sites wish only to receive multicasts. Potential dangers: 1) "Can an multicast tunnel be fooled into encapsulating other traffic?" Looking at the ip_mroute.c kernel file in the Sun mcast source, the routine multiencap_decap() has code in it to "dump the packet if it's not to a multicast destination or if we don't have an encapsulating tunnel with the source", so this does not seem to be a danger. 2) If firewall tunnel is not threshold 255, it is possible to have internal and external persons cooperate to move data in and out of the firewalled network, just like any other tunnelled service. -- shawni@llnl.gov:Unix Support Team, Distributed Computing Support Program, LLNL From Firewalls-Owner Tue Jun 29 16:36:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18086; Tue, 29 Jun 93 16:36:46 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18079; Tue, 29 Jun 93 09:36:37 PDT Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA14366(telemann.inoc.dl.nec.com); Tue, 29 Jun 93 11:38:40 CDT Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA04100(texas.syl.dl.nec.com); Tue, 29 Jun 93 11:38:38 CDT Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA07439(florida.syl.dl.nec.com); Tue, 29 Jun 93 11:38:33 CDT Date: Tue, 29 Jun 93 11:38:33 CDT From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9306291638.AA07439@florida.syl.dl.nec.com> To: cert-tools@cert.org, firewalls@GreatCircle.COM Subject: SOCKS proxy server with finger/ftp/telnet/xgopher clients Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have been working on David Koblas's SOCKS package, mainly for our own use. It has now reached a state that others may be interested in using as well. So, I am now making it available for anonymous ftp. It is on host ftp.inoc.dl.nec.com (143.101.112.3) in directory pub/security, the file name is socks.cstc.930629.tar.Z. Remember to download it in binary mode. Here are the first two paragraphs in the README.1st file: This is SOCKS, a package conisisting of a proxy server (sockd) and client programs corresponding to finger, whois, ftp, telnet, and xgopher, as well as a library module for adapting other applications into new client programs. The original was written by David Koblas (koblas@netcom.com). I adapted the server code (sockd) to make it run on SunOS4.1.x, added access control accroding to user-ids, corrected the mistakes for using operator 'lt' or 'gt' with port number, and added rtelnet and rxgopher clients. I also modified the Makefiles and supplied man pages that, I hope, will be helpful even to people who don't read the code. The rxgopher client is based on xgopher ver. 1.2 by Allan Tuchman, University of Illinois at Urbana-Champaign, a-tuchman@uiuc.edu. Please note that the package has only been tested on SunOS 4.1.x. I have no way for testing it with other systems, so I won't be able to give you much help on system-dependent problems. But let me know if you run into any problems getting it, building it, or running it anyway. Good luck and enjoy it. Ying-Da Lee (214)518-3490 (214)518-3552 (FAX) Principal Member Technical Staff NEC Systems Laboratory, C&C Software Technology Center / NEC USA, Corporate Network Administration Division ylee@syl.dl.nec.com From Firewalls-Owner Tue Jun 29 17:54:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18376; Tue, 29 Jun 93 17:54:42 GMT Received: from nic.cerf.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18369; Tue, 29 Jun 93 10:54:36 PDT Received: from dt.wdc.com (fission.dt.wdc.com) by nic.cerf.net (4.1/CERFnet-1.0) id AA28833; Tue, 29 Jun 93 11:00:10 PDT Received: from stsun2.wdc.com (stsun2-e7) by dt.wdc.com (4.1/SMI-4.1) id AA00656; Tue, 29 Jun 93 10:57:11 PDT Received: by stsun2.wdc.com (4.1/SMI-4.1) id AA22204; Tue, 29 Jun 93 10:57:10 PDT Date: Tue, 29 Jun 93 10:57:10 PDT From: wyatt@dt.wdc.com (Troy Wyatt (Wyatt)) Message-Id: <9306291757.AA22204@stsun2.wdc.com> To: firewalls@GreatCircle.COM Subject: Need the cisco access lists... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I know it was sent a while ago, but like the dope that I am, I lost it...... I will trade a copy of modo2000 to the first person who sends it to me. YIT - floating desktop man! From Firewalls-Owner Wed Jun 30 23:34:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23924; Wed, 30 Jun 93 23:34:25 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23916; Wed, 30 Jun 93 16:34:21 PDT Message-Id: <9306302334.AA23916@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Firewalls "topic" files updated Date: Wed, 30 Jun 93 16:34:20 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've updated the Firewalls "topic" files. When I originally created them, there was a mistake in the order that messages were placed in the topic files. The script I was using placed the messages into the topic files in lexical order rather than numeric order (i.e., they were in the order "1 10 100 ... 109 11 110 111 ... 12 ... 19 2 20 ...", rather than in the order "1 2 ... 10 11 12 ... 19 20 ... 100 ... 109 110 111 ..."). I've fixed this, and recreated the "topic" files; they're available for anonymous FTP from FTP.GreatCircle.COM, directory pub/firewalls/topics. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041