From Firewalls-Owner Sun Jan 3 22:22:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09236; Sun, 3 Jan 93 22:22:32 PST Received: from sc.tamu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09229; Sun, 3 Jan 93 22:22:09 PST Received: from posaune.tamu.edu by sc.tamu.edu (AA05314); Sun, 3 Jan 93 22:49:57 CST Message-Id: <9301040449.AA05314@sc.tamu.edu> Received: by posaune.tamu.edu (NX5.67c/NX3.0X) id AA04736; Sun, 3 Jan 93 22:49:51 -0600 Date: Sun, 3 Jan 93 22:49:51 -0600 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: IPFORWARD Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: jim@tadpole.com (Jim Thompson) > Date: Tue, 22 Dec 92 23:42:44 CST > Subject: Re: IPFORWARD > > I've received a couple email requests (and one phone call) > for a citation of the paper I referenced earlier today. > > "A Unix Network Protocol Security Study: Network Information Service" > David K. Hess, David R. Safford and Udo W. Pooch > Texas A&M University > dhess@cs.tamu.edu > > referenced > > I found it in "Computer Communication Review", Volume 22 Number 5, > October 1992. This is the ACM "SIGCOMM" publication. > > Jim I received a couple of e-mail requests for a copy of this paper. It's available in PostScript via anonymous ftp from sc.tamu.edu in pub/security as NIS_Paper.ps and NIS_Paper.ps.Z. Dave --- David K. Hess Graduate Assistant David-Hess@tamu.edu Supercomputer Center Texas A&M University From Firewalls-Owner Mon Jan 4 09:42:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10719; Mon, 4 Jan 93 09:42:47 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10709; Mon, 4 Jan 93 09:42:42 PST Message-Id: <9301041742.AA10709@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Why the sudden upswing in subscriptions? Date: Mon, 04 Jan 93 09:42:41 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There have been 10 new subscriptions to Firewalls so far this morning. That's only about 1% of the total number of subscriptions to Firewalls, but it's still a pretty spectacular jump. Did we get mentioned in print or on the Net recently or something? -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 Jan 4 09:45:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10764; Mon, 4 Jan 93 09:45:49 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10753; Mon, 4 Jan 93 09:45:42 PST Message-Id: <9301041745.AA10753@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Firewalls BOF at USENIX Date: Mon, 04 Jan 93 09:45:41 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk By the way, for those of you going to the USENIX conference in San Diego later this month, there will probably be a Firewalls BOF (Birds of a Feather) session. Details haven't been finalized yet, but it will probably be immediately after the CERT (Computer Emergency Response Team) BOF in the same room. CERT traditionally holds their BOF on Thursday evening after the USENIX Reception. I'll let you know more details when they've been finalized. Check the BOF board at the conference for room assignments and last minute changes. Could somebody who's going to be there please volunteer to take notes and send them to the Firewalls mailing list afterwards? -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 Jan 4 10:38:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11236; Mon, 4 Jan 93 10:38:43 PST Received: from copper.Denver.Colorado.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11229; Mon, 4 Jan 93 10:38:35 PST Received: by copper.Denver.Colorado.EDU (cudenver.ether) Date: Mon, 4 Jan 93 11:41:42 -0700 From: s3surgui@copper.Denver.Colorado.EDU (Scott A Surguine) Message-Id: <9301041841.AA03103@copper.Denver.Colorado.EDU> To: Firewalls@GreatCircle.COM Subject: Needed: Proxy Agent for Multinet TCP/IP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am looking for a solution which will allow us to run Proxy on Multinet TCP/IP I would ideally like to be able to block anyone from getting past a choke ma machine ( our Vax ) via TCP/IP. In other words I want to block someone from being able to access machines on our net via IP addressing. Any Ideas?? All suggestions are appreciated. Will summarize responses. Thanks, --Scott From Firewalls-Owner Wed Jan 6 03:42:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15820; Wed, 6 Jan 93 03:42:58 PST Received: from volitans.MorningStar.Com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15813; Wed, 6 Jan 93 03:42:50 PST Received: from roughy.morningstar.com by volitans.MorningStar.Com (5.65a/92122901) id AA01923; Wed, 6 Jan 93 06:42:37 -0500 From: Bob Sutterfield Received: by roughy.MorningStar.Com (5.65a/910712902) id AA03444; Wed, 6 Jan 93 06:42:30 -0500 Date: Wed, 6 Jan 93 06:42:30 -0500 Message-Id: <9301061142.AA03444@roughy.MorningStar.Com> To: firewalls@GreatCircle.COM Subject: Proxy FTP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Do proxy FTP connections use the FTP command socket (21/tcp), or only the FTP data socket (20/tcp)? We've been in the habit of controlling FTP access by filtering the command socket, on the theory that if you can't open the command stream then you also can't open the data stream. But it just occurred to me that, if proxy FTP connections have no command stream between the two 3rd-party hosts, then my habits have been seriously in error. Or maybe I just haven't had enough coffee yet this morning... From Firewalls-Owner Wed Jan 6 17:50:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17238; Wed, 6 Jan 93 17:50:16 PST Received: from halon.sybase.com ([192.138.151.10]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17229; Wed, 6 Jan 93 17:50:09 PST Received: from sybase.com (sybgate.sybase.com) by halon.sybase.com (5.0/SMI-4.1/SybFW3.1) id AA00607; Wed, 6 Jan 93 17:49:50 PST Received: from ubu.sybgate.sybase.com by sybase.com (4.1/SMI-4.1/SybH3.1) id AA24947; Wed, 6 Jan 93 17:49:36 PST Received: from localhost by ubu.sybgate.sybase.com (4.1/SMI-4.1/SybEC3.1) id AA26558; Wed, 6 Jan 93 17:49:37 PST Message-Id: <9301070149.AA26558@ubu.sybgate.sybase.com> To: firewalls@GreatCircle.COM Subject: Sun's itelnet and iftp? Date: Wed, 06 Jan 93 17:49:36 -0800 From: Donald R. Proctor (510/596-3828) Content-Length: 340 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can anyone tell me how Sun's itelnet and iftp are distributed? Aside from the fact that these "proxy" applications are largely unavailable for non-Sun platforms, it seems to me that they provide a more secure approach than allowing user accounts on the firewall host. Any opinions? Don Proctor Sybase Computer Systems From Firewalls-Owner Wed Jan 6 21:45:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17409; Wed, 6 Jan 93 21:45:36 PST Received: from uvt.utc.cs by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17402; Wed, 6 Jan 93 21:45:28 PST Message-Id: <9301070545.AA17402@mycroft.GreatCircle.COM> From: zia@uvt.utc.cs Subject: To: firewalls@GreatCircle.COM Date: Thu, 7 Jan 1993 06:44:42 -0500 (EST) Content-Type: text Content-Length: 18 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk SUB Beata Ziakova From Firewalls-Owner Thu Jan 7 02:54:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17861; Thu, 7 Jan 93 02:54:12 PST Received: from gateway.sequent.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17854; Thu, 7 Jan 93 02:53:59 PST Received: from crg8.sequent.com by gateway.sequent.com (5.61/1.34) id AA02360; Thu, 7 Jan 93 02:55:11 -0800 Received: from uksqnt.uk.sequent.com by crg8.sequent.com (5.65/1.34) id AA28072; Thu, 7 Jan 93 02:54:07 -0800 Received: from uksvc700.uk.sequent.com by uksqnt.uk.sequent.com (5.65/1.34) id AA09725; Thu, 7 Jan 93 10:30:37 GMT Received: by uksvc700.uk.sequent.com (5.65/1.34) id AA15019; Thu, 7 Jan 93 10:53:07 GMT Date: Thu, 7 Jan 93 10:53:07 GMT From: Phill Everson Message-Id: <9301071053.AA15019@uksvc700.uk.sequent.com> In-Reply-To: Donald R. Proctor (510/596-3828)'s message as of Jan 6, 5:49pm X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Donald R. Proctor (510/596-3828) Subject: Re: Sun's itelnet and iftp? Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk iftp & itelnet were distributed as part of the Sun Consulting Special IGateway package last time I looked. The actual modifications made to the base daemons was fairly simple though. Hope this helps Phill Everson Sequent UK On Jan 6, 5:49pm, Donald R. Proctor (510/596-3828) wrote: } Subject: Sun's itelnet and iftp? > Can anyone tell me how Sun's itelnet and iftp are distributed? > > Aside from the fact that these "proxy" applications are largely > unavailable for non-Sun platforms, it seems to me that they provide > a more secure approach than allowing user accounts on the firewall > host. > > Any opinions? > > Don Proctor > Sybase Computer Systems > }-- End of excerpt from Donald R. Proctor (510/596-3828) -- From Firewalls-Owner Thu Jan 7 07:13:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18317; Thu, 7 Jan 93 07:13:10 PST Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18310; Thu, 7 Jan 93 07:13:05 PST Message-Id: <9301071513.AA18310@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Thu, 7 Jan 93 10:10:01 EST To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Aside from the fact that these "proxy" applications are largely >unavailable for non-Sun platforms, it seems to me that they provide >a more secure approach than allowing user accounts on the firewall >host. I suppose it is time for me to try to get a General Release for my proxy stuff. In any case, there was a nice paper on roughly equivalent software in the last Usenix Security Conference. I think it is publically available. From Firewalls-Owner Thu Jan 7 07:36:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18405; Thu, 7 Jan 93 07:36:07 PST Received: from leigh.s1.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18398; Thu, 7 Jan 93 07:35:59 PST Received: from terminus.s1.gov by leigh.s1.gov (4.1/TMD1.4) id AA01301; Thu, 7 Jan 93 07:36:21 PST Received: by terminus.s1.gov (4.1/TMD1.4) id AA29115; Thu, 7 Jan 93 07:36:17 PST From: Leland K. Neely Message-Id: <9301071536.AA29115@terminus.s1.gov> Subject: Re: Sun Igateway To: ches@research.att.com Date: Thu, 7 Jan 93 7:36:16 PST Cc: firewalls@GreatCircle.COM In-Reply-To: <9301071513.AA18310@mycroft.GreatCircle.COM>; from "ches@research.att.com" at Jan 7, 93 10:10:01 am X-Mailer: ELM [version 2.4dev PL32] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ches@research.att.com writes: > > >Aside from the fact that these "proxy" applications are largely > >unavailable for non-Sun platforms, it seems to me that they provide > >a more secure approach than allowing user accounts on the firewall > >host. > > I suppose it is time for me to try to get a General Release for my > proxy stuff. In any case, there was a nice paper on roughly > equivalent software in the last Usenix Security Conference. > I think it is publically available. > This is a good idea. I wanted to point out that it is possible for non-sun ftp & telnet clients to use the proxy daemons. I will admit that you have to do more work, and NCSA Telnet doesn't work, but if you have the sun stuff and a user that doesn't have a sun, you have a way to give them functionality until you install a solution that works with their system. (IE socks) Lee Neely (Exploring the dangers of posting before consuming my first cup of coffee...) PS you can anon ftp socks from s1.gov, 128.15.32.7, /pub/socks.tar.Z From Firewalls-Owner Thu Jan 7 09:58:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18797; Thu, 7 Jan 93 09:58:30 PST Received: from bcars567 (CORPGATE.NT.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18790; Thu, 7 Jan 93 09:58:22 PST X400-Received: by mta bcars567 in /PRMD=NT/ADMD=MCI/C=US/; Relayed; Thu, 7 Jan 1993 11:57:54 -0600 X400-Received: by /PRMD=NT/ADMD=MCI/C=US/; Relayed; Thu, 7 Jan 1993 11:56:56 -0600 X400-Received: by /PRMD=NT/ADMD=MCI/C=US/; Relayed; Thu, 7 Jan 1993 06:56:00 -0600 Date: Thu, 7 Jan 1993 12:56:00 +0000 X400-Originator: /DD.ID=mpjlp01/G=Julia/I=JL/S=Piggott/@nt.com X400-Mts-Identifier: [/PRMD=NT/ADMD=MCI/C=US/;bcars567.n.711:07.00.93.17.56.55] X400-Content-Type: P2-1984 (2) Content-Identifier: Secure Gateways From: "Julia (J.L.) Piggott" Message-Id: <"2737 Thu Jan 7 12:57:25 1993"@nt.com> To: firewalls@GreatCircle.COM Subject: Secure Gateways Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've just recently joined this Firewalls group and have only managed to get my hands on a small portion of the correspondance since Sept/92. I'm also particularly interested in what's available to secure a wide area network for interactive traffic between external organizations. I saw a bit of information on DEC's SEAL product and Raptor's Eagle. Has anyone who has used these products, have any comments- good and bad? Any other products available? Thanks........Julia From Firewalls-Owner Fri Jan 8 03:50:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21116; Fri, 8 Jan 93 03:50:52 PST Received: from ensta.ensta.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21109; Fri, 8 Jan 93 03:50:41 PST Received: from itesec.hsc-sec.fr by ensta.ensta.fr with BSMTP id AA25301 (5.67a8/IDA-1.5 for ); Fri, 8 Jan 1993 12:50:21 +0100 Received: by itesec.hsc-sec.fr id AA15803 (5.65d8/IDA-1.5 for ensta!greatcircle.com!firewalls); Fri, 8 Jan 1993 11:07:20 +0100 From: Christophe Wolfhugel Message-Id: <199301081007.AA15800@itesec.hsc-sec.fr> X-Filter: Mail approved by HSC-Gateway Subject: Re: Sun's itelnet and iftp? To: firewalls@GreatCircle.COM Date: Fri, 8 Jan 93 11:07:15 +0100 Organization: Herve Schauer Consultants, Paris, France X-How-To-Reach-Us: Voice: + 33 1 46388990 / Fax: + 33 1 46380505 X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Donald R. Proctor: > Aside from the fact that these "proxy" applications are largely > unavailable for non-Sun platforms, it seems to me that they provide > a more secure approach than allowing user accounts on the firewall > host. Most people seem to agree that having real accounts on the firewall is just un-handlable in good conditions. Bill Cheswick: > In any case, there was a nice paper on roughly equivalent software in > the last Usenix Security Conference. > I think it is publically available. The paper is available, the software not :). Just send me mail for more information. Another paper, somewhat more detailled that the Usenix proceedings is also ready (available in french) and soon to be translated in english. Will be made available by anonymous FTP and mail-server. Chris From Firewalls-Owner Fri Jan 15 10:43:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03460; Fri, 15 Jan 93 10:43:15 PST Received: from norman.li.cubic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03453; Fri, 15 Jan 93 10:42:58 PST Received: by norman.li.cubic.com (5.67/1.34a) id AA01395; Fri, 15 Jan 93 13:43:19 -0500 Date: Fri, 15 Jan 93 13:43:19 -0500 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9301151843.AA01395@norman.li.cubic.com> To: mischler@Cubic.COM, FireWalls@GreatCircle.COM Subject: Cheap Packet Filtering Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have added a packet filtering implementation to Phil Karn's KA9Q software (930104 version) based on many of the ideas in Brent Chapman's paper, "Network (In)Security Through IP Packet Filtering". I want to make this software generally available both because I think it is useful and because I want beta testers and/or better ideas. I will place no restrictions on the code, but the copyrights of Phil Karn and other authors of the KA9Q software may not be infringed. The last time I looked the shareware fee for commercial sites was $50 for the KA9Q package (it is free to schools and ham radio operators, or for evaluation purposes). I would like an anonymous FTP site on which to put the source and executables, as well as some feedback from testers. I use this software to provide a demand-dial router between an extended LAN and an Internet service provider on a SLIP link with a V.32bis/V.42bis modem at a DTE speed of 57600 Kbps. My target hardware is a PC clone with a 16 MHz 286 CPU, a serial card with NS16550As, and an ethernet card. I compiled the software with Borland C++ V3.1. I have tested the code and it seems to behave. I am using it for my Internet connection right now. There may be bugs, and it may be possible to improve the performance by coding changes. I WILL NOT BE RESPONSIBLE FOR ANY PROBLEMS YOU MAY HAVE WITH THIS SOFTWARE, OR AS A CONSEQUENCE OF USING THIS SOFTWARE, NOR WILL I BE RESPONSIBLE FOR FIXING OR IMPROVING THE SOFTWARE. The forms of the IP filter command are ip filter delete ip filter list ip filter deny ip filter permit The is the name of the interface that was assigned when it was attached. The "delete" command will delete the entire filter set for an interface. The "list" command will display the entire filter set for an interface. The "deny" command will append a filter entry to the filter set for an interface. The direction of the packet to be disallowed is from the perspective of the router running the filtering process (i.e. "in" implies that the packet arrived on the specified interface). The type field specifies the packet category to be disallowed. The source and destination allow IP addresses, address masks, and ports to be specified. The "permit" command is identical to the "deny" command except that it causes packets that meet the specified criteria to be allowed. The legal packet types are shown in the following table. TYPE MEANING * Any IP packet. icmp Any ICMP packet. icmprd An ICMP REDIRECT packet. icmpxrd Any ICMP packet except a REDIRECT. tcp Any TCP packet. tcpsyn A TCP packet with the SYN bit set and the ACK bit clear. This implies an attempt to open a new TCP connection. tcpxsyn Any TCP packet that has the SYN bit clear or the ACK bit set. This implies a packet on an existing connection. udp Any UDP packet. A source or destination specification takes the form [!]address[/bits][:port], where address is an IP address in dotted octet form, or a resolvable domain name, or "*". The use of "*" for the address implies both an address and address mask of all zeroes. If you specify "/bits" on an address you are specifying how many of the high order bits of the address are significant. For example, to compare only the network part of a class B address one could use /16. The use of "!" before an address means that all addresses except those specified by the address and mask match the specification. Finally, if a port number is specified then the filter entry will only match packets with the appropriate port numbers (this is only meaningful if one of the tcp, tcpsyn, tcpxsyn or udp packet types is specified). The list of filter entries is scanned in the order they were entered until a match is reached, then the action specified in the filter entry (i.e. deny or permit) will be taken. If a packet does not match any filter entries then it will be denied by default. Note that the input and output filter sets are independent and that, for example, if no output entries exist, then all outgoing packets would be permitted. If an IP datagram is fragmented then filters only apply to the first fragment (all subsequent fragments are permitted). Incoming and outgoing filters are checked even if source routing is specified. Here is a filter set that I made up for a SLIP link to the Internet from my company's class B network. The line numbers are only for reference purposes. 1 ip filter sl0 permit in tcpxsyn !cubic.com/16 cubic.com/16 2 ip filter sl0 permit in tcpsyn !cubic.com/16 cubic.com/16:25 3 ip filter sl0 permit in tcpsyn ns2.psi.net ns.cubic.com:53 4 ip filter sl0 permit in tcpsyn !cubic.com/16 cubic.com:79 5 ip filter sl0 permit in udp !cubic.com/16:53 cubic.com/16:53 6 ip filter sl0 permit in udp !cubic.com/16:123 cubic.com/16:123 7 ip filter sl0 permit in icmpxrd !cubic.com/16 cubic.com/16 8 ip filter sl0 permit out * cubic.com/16 !cubic.com/16 Line 1 permits TCP packets for established connections. It disallows attempts to spoof internal addresses from outside (the other filter entries that allow arbitrary hosts also do this). There is probably a performance benefit from putting this rule first. Line 2 permits new SMTP connections to be opened on any internal machine. Line 3 permits ns2.psi.net to perform DNS zone transfers from ns.cubic.com. Line 4 permits new FINGER connections to cubic.com. Line 5 permits UDP packets for DNS. Line 6 permits UDP packets for NTP. Line 7 permits ICMP packets except redirects. Line 8 prevents packets destined to subnets for which there are no routes from cycling between our router and the Internet provider's until the time-to-live expires. Dave Mischler mischler@cubic.com From Firewalls-Owner Sun Jan 17 22:49:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06594; Sun, 17 Jan 93 22:49:28 PST Received: from nthu.edu.tw by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06587; Sun, 17 Jan 93 22:49:19 PST Received: from Uz.nthu.edu.tw ([140.114.66.200]) by nthu.edu.tw with SMTP id <77500>; Mon, 18 Jan 1993 14:52:22 +0800 Received: by Uz.nthu.edu.tw (th3.5r) id AA21711; Mon, 18 Jan 93 14:50:22 CST From: chiawei@Uz.nthu.edu.tw (C.W.Teng) Subject: sub To: firewalls@GreatCircle.COM Date: Mon, 18 Jan 1993 14:50:21 +0800 X-Mailer: ELM [version 2.3 PL0] Message-Id: <93Jan18.145222cst.77500@nthu.edu.tw> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk sub chiawei Teng From Firewalls-Owner Mon Jan 18 16:11:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08689; Mon, 18 Jan 93 16:11:27 PST Received: from norman.li.cubic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA08666; Mon, 18 Jan 93 16:11:05 PST Received: by norman.li.cubic.com (5.67/1.34a) id AA01235; Mon, 18 Jan 93 19:11:04 -0500 Date: Mon, 18 Jan 93 19:11:04 -0500 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9301190011.AA01235@norman.li.cubic.com> To: FireWalls@GreatCircle.COM, mischler@Cubic.COM Subject: Re: Cheap Packet Filtering Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Thanks to Jim Stine, my packet filtering modifications to KA9Q are available for anonymous FTP from stealth.logiconultra.com in /pub/dm930118.*. An updated description, an executable, and a zip file with all needed sources are included. I would love to receive bug reports, success stories, questions and constructive criticism. Dave Mischler mischler@cubic.com From Firewalls-Owner Tue Jan 19 09:44:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10554; Tue, 19 Jan 93 09:44:42 PST Received: from oxmail.ox.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10547; Tue, 19 Jan 93 09:44:28 PST Received: from nw-gateway.offices.ox.ac.uk by oxmail.ox.ac.uk with SMTP (PP) id <14366-0@oxmail.ox.ac.uk>; Tue, 19 Jan 1993 17:43:01 +0000 Received: From UNIVERSITY_OFFICES/WORKQUEUE by nw-gateway.offices.ox.ac.uk via Charon-4.0-VROOM with IPX id 100.930119174351.416; 19 Jan 93 17:40:27 +500 Message-Id: To: firewalls@GreatCircle.COM From: Mark Walters Organization: University of Oxford Date: 19 Jan 93 17:43:44 GMT Subject: Packet filtering Priority: normal X-Mailer: Pegasus Mail v2.3 (R5). Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi!, I've been looking at what's available for providing packet filtering between a LAN and a campus network. The requirement is slightly unusual because I need to be able to filter/bridge protocols other than IP, ie IPX and AppleTalk. Most of the software that I've found so far only seems geared up for IP, only the dedicated routers seem to be able to handle multiple protocols. If anybody has any information about software that might be able to help I'd appreciate hearing about it! We're part of an academic setup so cost is a big factor... :-( I have heard of one thing that might also be of interest to other people, I've included the README file below. Thanks! Mark Walters ***** 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 Jan 26 10:06:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23554; Tue, 26 Jan 93 10:06:11 PST Received: from ic.co.at by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23547; Tue, 26 Jan 93 10:05:53 PST Received: by ic.co.at id AA12527 (5.65c/hp4at for firewalls@greatcircle.com); Tue, 26 Jan 1993 19:06:27 +0100 Message-Id: <199301261806.AA12527@ic.co.at> Subject: IP access list streams module available To: firewalls@GreatCircle.COM Date: Tue, 26 Jan 1993 19:06:25 +0100 (MET) Cc: fuer@siemens.co.at From: Michael Haberler Reply-To: mah@ic.co.at Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 476 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Gerhard Fuernkranz of fuer@siemens.co.at has written a SVR4 STREAMS module which implements access lists very nicely. I've not tried it yet but it looks very good. Comes under Gnu GPL. I put it up for anonymous ftp on eunet.co.at:pub/network/ipacl/ipacl.[shar|tar.Z] Mirrors welcome. Michael Haberler -- Michael Haberler mah@eunet.co.at EUnet Austria Ltd A-1010 Vienna, Austria, Schottenring 33 Tel: +43 (1) 346184 fax: +43 (1) 3104462 From Firewalls-Owner Thu Jan 28 09:54:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29036; Thu, 28 Jan 93 09:54:12 PST Received: from netcomsv.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA13413; Wed, 20 Jan 93 18:00:19 PST Received: from livingston.com ([149.198.1.1]) by netcomsv.netcom.com (4.1/SMI-4.1) id AA26877; Wed, 20 Jan 93 17:58:13 PST Received: from moremips.livinston.com by livingston.com (4.1/SMI-4.1) id AA23818; Wed, 20 Jan 93 17:57:08 PST Received: by moremips.livinston.com (4.1/SMI-4.1) id AA07658; Wed, 20 Jan 93 17:56:33 PST Date: Wed, 20 Jan 93 17:56:33 PST From: steve@livingston.com (Steve Willens) Message-Id: <9301210156.AA07658@moremips.livinston.com> To: firewalls@GreatCircle.COM Subject: Livingston Packet Filtering Sender: Firewalls-Owner@GreatCircle.COM [ My apologies for holding this message up for so long; it tripped one of the administrivia filters (it's more than 10k bytes long) on my relay software, and languished in my inbox for a while. If you have any complaints about whether this message is appropriate or "too commercial", direct them to me, not to Steve Willens or the list as a whole; I urged him to submit this message because I thought it would be of interest to a significant number of people on the list. -Brent ] Several people on this list have requested information about the new packet filtering features which have just been beta released for the Livingston Routers and Communications Servers. I have included a description of these features in this message. Feel free to post comments or questions to the firewalls mailing list or directly to me. Steve Willens steve@livingston.com ---------------------------------- Cut Here ---------------------------------- Packet Filtering for the Livingston PortMaster Communications Server & Internetwork Router Introduction ------------ Packet filters are used primarily as a security mechanism in networks which cross organizational or corporate boundaries. They are useful in limiting certain kinds of inter-network communications by specifically permitting or denying the passage of packets through network interfaces. By designing appropriate filters, administrators can control access to specific computers, networks, and network services. Packet filters require the analysis of the header information contained in each packet sent or received through a network interface. This header information is evaluated against a set of rules which allow the packet to pass freely through the interface (and on to its destination in the network) or cause the packet to be discarded without forwarding. The Livingston packet filtering mechanism is designed around two primary objectives. First maximum flexibility is required to allow the administrator to achieve the desired results without compromising security. Second efficiency is desirable to maximize network performance. Specific features which support these objectives are: * Input and Output Filters - Each interface can be assigned both an input packet filter as well as an output packet filter. This is especially useful in routers with more than two network interfaces and it simplifies the design task. The administrator can evaluate each interface, where its destination is, and the mix of traffic both inbound and outbound desired for the interface. This capability also has the potential to decrease the number of rules contained in the filter because fewer network numbers need to be included. * Source and Destination Address Filtering - Both the source and destination IP addresses can be evaluated in the rule list. In addition, the number of significant bits to use in the address comparison can be set. This allows filtering based on specific hosts, subnets, or network numbers. * Protocol Filtering - Specific protocols can be handled separately in the packet filters. These include TCP, UDP, and ICMP. * Source and Destination Port Filtering - The source and destination port numbers can be used in the rule set to control availability of specific network services. This includes evaluation base on whether the port number is less than, equal to, or greater than a specific value. * Established Session Filtering - The status of TCP connections can be used as part of the rule set. This allows users in a network to open connections to external networks without allowing external users access to the local network. * Unlimited Number of Rules - Each filter can have a large number of rules specified. This is only limited by available memory within the router. * Simple Rule Creation - The command syntax for creating specific rules allows the administrator to specify only as much information as is necessary to specify the rule. For example if the rule is not based on specific source and destination IP address, these addresses can be omitted from the specification of the rule. * In-line Rule Processing - Rules are processed in the order in which they are specified in the rule set. This eliminates ambiguity about how a specific packet would be handled, and allows more flexibility in the creation of a packet filter. Filter Organization ------------------- The PortMaster maintains a table of packet filters in its permanent configuration memory. These filters can be created or modified at any time and are independent of any active packet filters. Each filter is assigned a name of up to 15 characters in length. Each packet filter is made up of a list of rules which are numbered starting at 1. A packet filter when initially created contains no rules. Packet filters are "attached" to interfaces as either input filters or output filters. For serial interfaces, the packet filter is enabled at the time it transitions to the UP state (ie. after a reset on the physical port). The ethernet interface filter is enabled as soon as the name of the input or output filter is specified. Managing the Filter Table ------------------------- The PortMaster packet filter features are currently only accessible through the command line interface. This interface is accessible via telnet or directly through one of the PortMaster serial ports. Filter Creation --------------- New packet filters are created with the "add filter" command. It is recommended that a specific naming convention be used to differentiate the uses of various filters. For example, the following names could be used: internet.in - The input filter to be used for the link to the Internet. internet.out - The output filter to be used for the link to the Internet. s1.in - The input filter for serial port S1. ether.out - The output filter for the ethernet interface. project1.out - The output filter to be used during a special project. The syntax of the "add filter" command is: add filter Filter_Name Where Filter_Name is the name to be assigned to a filter. Setting Filter Rules -------------------- Once a filter has been created, the "set filter" command is used to add, modify or delete specific rules. The syntax of this command is: set filter Filter_Name Rule_no [ permit|deny ] [ Source_Addr/Source_Bits Dest_Addr/Dest_Bits ] [ Protocol [ src lt|eq|gt Value ] [ dst lt|eq|gt Value ] ] [ established ] Where: Filter_Name - is the name of an existing filter. Rule_no - is a number up to the highest previously set Rule_no plus 1 (ie. if there are 4 existing rules, Rule_no can be from 1 to 5). If an existing rule number is specified, it is replaced by the new rule. If no parameters are specified for the rule, that rule is deleted. permit|deny - indicates whether the packet should be forwarded (permit) or discarded (deny). Source_Addr - The Source Address to look for in the Packet's IP header. Source_Bits - The number of bits to use when comparing the Source_Addr to the actual address in the packet. Valid values are from 0 to 32. Dest_Addr - The Destination Address to look for in the Packet's IP header. Dest_Bits - The number of bits to use when comparing the Dest_Addr to the actual address in the packet. Valid values are from 0 to 32. Protocol - The protocol to look for in the packet's IP header. Valid values are: tcp, udp, and icmp. src - Evaluate the Source Port in TCP or UDP packets. lt|eq|gt - The type of comparison to perform with the TCP or UDP port number. Where "lt" means Less-Than, "eq" means Equal-To and "gt" means Greater-Than. Value - The decimal value to use in the TCP or UDP port number comparison. dst - Evaluate the Destination Port in TCP or UDP packets. established - Evaluates whether the packet is for an established TCP connection. Deleting Filters ---------------- The "delete filter" command is used to remove a packet filter from the table. The syntax of the command is: delete filter Filter_Name Where: Filter_Name - is the name of an existing filter. Viewing Filters --------------- THe "show" command can be used to view the list of packet filters and the contents of each filter. To view the list of all packet filters use the command: show table filter To view the contents of a specific filter use the command: show filter Filter_Name Saving Filters -------------- To save the table of packet filters use the command: save filter Filter names for specific interfaces are saved through the normal configuration save commands (ie. "save all" or "save s1"). Packet Processing ----------------- When packets are received on an interface the active input filter for that interface is evaluated before forwarding the packet through the PortMaster. Before packets are transmitted on an interface the active output filter for that interface is evaluated before transmitting. Each rule is evaluated in the order the rules are specified. As soon as the packet matches one rule, that rules action is immediately taken and no further processing is performed on the packet. If no rules match the specific packet, the packet is "denied" and it is discarded. Whenever a packet is discarded, the PortMaster automatically generates and ICMP Host Unreachable message back to the originator. It is recommended that packets which represent the highest volume of traffic through an interface be specified early in the list of rules. This will decrease the overhead of processing these packets and therefore increase overall performance. Setting Packet Filters ---------------------- Ethernet Interface Filters -------------------------- The "set" command is used to establish specific input and output packet filters for the Ethernet interface. To set an input filter use the command: set ifilter Filter_Name Where Filter_Name is the name of an entry in the filter table. To set an output filter use the command: set ofilter Filter_Name If no name is specified, or if the named filter does not exist, packet filtering is disabled. Packet filtering is enabled or disabled on the ethernet interface immediately after executing the above set command. Serial Interface Filters ------------------------ The "set" command is used to establish specific input and output packet filters for the serial ports. To set an input filter use the command: set Port_Name ifilter Filter_Name Where: Port_name - is the name of a port on the PortMaster (ie. S1, S2,...) Filter_Name - is the name of an entry in the filter table. To set an output filter use the command: set Port_Name ofilter Filter_Name If no name is specified, or if the named filter does not exist, packet filtering is disabled. Packet filtering is enabled or disabled on serial interfaces when the port is reset, and the network connection is re-established. Dial-In Filters --------------- For the PortMaster Communications Servers which support dial-up SLIP and PPP access, input and output filters are assigned to the "user" rather than to the serial port. When a user establishes a PPP or SLIP connection with the PortMaster the designated filters are attached to the port through which the user is attached. The "set user" command is used to assign filters to specific users. To set an input filter for a user use the following command: set user User_Name ifilter Filter_Name User_Name - is the name of a user in the PortMaster passwords table Filter_Name - is the name of an entry in the filter table. To set an output filter for a user use the following command: set user User_Name ofilter Filter_Name User_Name - is the name of a user in the PortMaster passwords table Filter_Name - is the name of an entry in the filter table. Examples -------- Because of the flexibility provided through the PortMaster packet filtering system, it is possible to specify filters which do not achieve the desired results. Great care should be taken to evaluate the types of traffic which a specific filter allow to pass through an interface. If possible, testing should be performed from both sides of the filtering interface to verify that the filter is operating correctly. The following example could be used at a site which has an Internet connection and wishes to gain access to the Internet through a PortMaster serial port without exposing their site (and its network) to outside people and organizations. This filter would designate one system on the local network for all Electronic Mail communications with the Internet. It would also designate one system for all FTP access from the Internet. In addition, it will allow local users to Telnet and FTP to remote sites. Finally, it will allow DNS (Domain Name Service) to work between the Internet and the local site. For the purposes of this example, the local site will use network number 192.9.200.0, the E-mail server will be at address 192.9.200.1 and the FTP server will be at address 192.9.200.2. *** *** Note: The following packet filter is still under test. Do not *** use this filter without verifying all values. *** # # Allow our users to open Telnet sessions with the Internet # set filter s1.in 1 permit tcp src eq 23 estab set filter s1.out 1 permit tcp dst eq 23 # # Allow our users to open an FTP session with the Internet # set filter s1.in 2 permit tcp src eq 21 estab set filter s1.out 2 permit tcp dst eq 21 set filter s1.in 3 permit tcp src eq 20 estab set filter s1.out 3 permit tcp dst eq 20 # # Allow DNS to pass through # set filter s1.in 4 permit udp dst eq 53 set filter s1.out 4 permit udp dst eq 53 # # Allow the Internet to open an SMTP session with our server # set filter s1.in 5 permit 0.0.0.0/0 192.9.200.1/32 tcp dst eq 25 set filter s1.out 5 permit 192.9.200.1/32 0.0.0.0/0 tcp src eq 25 estab # # Allow our server to open an SMTP session with the Internet # set filter s1.in 6 permit 0.0.0.0/0 192.9.200.1/32 tcp src eq 25 estab set filter s1.out 6 permit 192.9.200.1/32 0.0.0.0/0 tcp dst eq 25 # # Allow the Internet to open an FTP and FTP-data session with our server # set filter s1.in 7 permit 0.0.0.0/0 192.9.200.2/32 tcp dst eq 21 set filter s1.out 7 permit 192.9.200.2/32 0.0.0.0/0 tcp src eq 21 estab set filter s1.in 8 permit 0.0.0.0/0 192.9.200.2/32 tcp dst eq 20 set filter s1.out 8 permit 192.9.200.2/32 0.0.0.0/0 tcp src eq 20 estab # # Allow ICMP for debugging # set filter s1.in 9 permit icmp set filter s1.out 9 permit icmp # # # Save It and Set It # # save filter set s1 ifilter s1.in set s1 ofilter s1.out save s1 reset s1 From Firewalls-Owner Thu Jan 28 17:24:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00586; Thu, 28 Jan 93 17:24:25 PST Received: from rara.ossi.com ([192.240.4.50]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00579; Thu, 28 Jan 93 17:24:18 PST Received: from nym.ossi.com ([192.240.2.13]) by rara.ossi.com; Thu, 28 Jan 93 17:24:20 PST From: Tony Luck Date: Thu, 28 Jan 93 17:24:29 PST Message-Id: <19671.9301290124@nym.ossi.com> To: Firewalls@GreatCircle.COM Subject: e-mail behind a firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We've almost got our internet connection ... but the question of how to make e-mail work is puzzling some of us. We are using filters in a router to block undesirable packets from reaching our local net from the big bad world. Most of our systems are Sun4's of various vintages mostly running SunOS 4.1.2. My question is on how to set up DNS. Currently we don't care if the outside world can see our local hostnames ... in fact some parts of the company seem to think that it is a neat idea for their workstation name to appear on e-mail headers ... this means that we have to support incoming mail with addresses like: If we ran separate name servers for internal and external consumption, we could support this by advertising MX records on the internet for all local machines pointing them at our two mail servers ... while internally the MX records for each host would point at themselves. But, we don't think that we want separate name servers. So currently we are planning on advertising 3 MX records for each host. The highest priority will point to itself, the next two point to each of the mail gateways. Thus from inside the firewall, people will choose the first MX record and deliver directly. From outside, machines will first try direct delivery and get bounced by the filter in the router with ICMP_UNREACHABLE ... and so they should fall back to one of the other MX records and deliver to one of our gateways. Is this an OK plan? Will it even work!? Should we really go for different internal and external name servers? Has anyone ever ``fixed'' named to give different answers depending on who is asking the questions? -Tony Luck From Firewalls-Owner Thu Jan 28 17:48:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00630; Thu, 28 Jan 93 17:48:06 PST Received: from Spectrum.CMC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00623; Thu, 28 Jan 93 17:47:59 PST Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA25395; Thu, 28 Jan 93 17:46:31 PST Newsgroups: list.firewalls Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: e-mail behind a firewall Message-Id: <1993Jan29.014617.25357@spectrum.CMC.COM> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA References: <19671.9301290124@nym.ossi.com> Date: Fri, 29 Jan 93 01:46:17 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In article <19671.9301290124@nym.ossi.com> aegl@ossi.com (Tony Luck) writes: [How do we make our machines inside the firewall reachable for email addressed to even if that machine is blocked by the firewall ?] >planning on advertising 3 MX records for each host. machine MX 0 machine machine MX 10 mailgate1 machine MX 20 mailgate2 > >Is this an OK plan? Will it even work!? Works like a charm (this is what we do here). >Has anyone ever ``fixed'' named to give >different answers depending on who is asking the questions? Actually, what you do is you run two different name servers on different hosts. The root nameservers point to the servers with the "outside view" zone. Your internal machines have resolver configurations pointing to the "inside view" server. It is a lot of hassle, though, and should not be necessary. -- / 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 Thu Jan 28 19:52:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00797; Thu, 28 Jan 93 19:52:39 PST Received: from norman.li.cubic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00784; Thu, 28 Jan 93 19:51:48 PST Received: by norman.li.cubic.com (5.67/1.34a) id AA00116; Thu, 28 Jan 93 22:48:43 -0500 Date: Thu, 28 Jan 93 22:48:43 -0500 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9301290348.AA00116@norman.li.cubic.com> To: firewalls@GreatCircle.COM, steve@livingston.com Subject: Re: Livingston Packet Filtering Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9301210156.AA07658@moremips.livinston.com>, Steve Willens wrote: ># ># Allow our users to open an FTP session with the Internet ># >set filter s1.in 2 permit tcp src eq 21 estab >set filter s1.out 2 permit tcp dst eq 21 >set filter s1.in 3 permit tcp src eq 20 estab >set filter s1.out 3 permit tcp dst eq 20 I just wanted to point out that the FTP server establishes the data connection back to the client, and that the client sets up a listener on a "random" port for this purpose. I found this out the hard way when I first set up my company's packet filter (based on KA9Q). If I am reading the rules above correctly then the SYN packet for the data connection will be dropped. ># ># Allow the Internet to open an FTP and FTP-data session with our server ># >set filter s1.in 7 permit 0.0.0.0/0 192.9.200.2/32 tcp dst eq 21 >set filter s1.out 7 permit 192.9.200.2/32 0.0.0.0/0 tcp src eq 21 estab >set filter s1.in 8 permit 0.0.0.0/0 192.9.200.2/32 tcp dst eq 20 >set filter s1.out 8 permit 192.9.200.2/32 0.0.0.0/0 tcp src eq 20 estab I believe that you have the same problem here. The software you describe sounds like a good and flexible packet filter. I would be interested in hearing how the software treats source routing, IP fragments, and ICMP redirects. Dave Mischler mischler@cubic.com From Firewalls-Owner Sun Jan 31 13:55:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07054; Sun, 31 Jan 93 13:55:36 PST Received: from rara.ossi.com ([192.240.4.50]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07047; Sun, 31 Jan 93 13:55:29 PST Received: from nym.ossi.com ([192.240.2.13]) by rara.ossi.com; Sun, 31 Jan 93 13:55:32 PST From: Tony Luck Date: Sun, 31 Jan 93 13:55:55 PST Message-Id: <7798.9301312155@nym.ossi.com> To: Firewalls@GreatCircle.COM Subject: Re: e-mail behind a firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This is a public "thank you" for all the responses to my question about setting up MX records in DNS. I think that only one of them was posted to the firewalls list, so here is a summary for anyone else out there in netland who wants to know: My proposed idea for MX records for machines behind a firewall was: MX 10 MX 20 MX 30 Where our filters prevent access to the machine directly from the internet, but connection to the gateways are permitted. This will work (and in fact is what *lots* of people are using already). Several people remined me of the non-desirability of making internal machine names visible: 1) It may be a security problem ("sensitive" information may be embedded in hostnames, or the information may be used for "social engineering" be a bad-guy with a silver tongue to talk their way into places that they shouldn't be). 2) Its a dumb idea for users to embed their hostname in their e-mail address (because then, they'll have a heck of a time telling everyone when they move/rename machines). I agree with you all, but for political reasons we will continue to have the machine name visible in out-going mail headers from certain departments (just don't ask ... if those people want to hang themselves, they can, I'm fed up with the arguments). I did take a look at our current set of machine names, and I don't think we are giving anything away (but if a psychiatrist gets hold of them and does some analysis, we may get a visit from some men wearing white coats offering to let us wear some of their "special" jackets :-) Finally I asked if anyone knew of a modified name server that would provide different answers depending on who was asking. Everyone who replied to this part of my question advised me to just run the internal and external name servers on different machines. -Tony Luck